diff options
Diffstat (limited to 'doc/rfc/rfc3520.txt')
| -rw-r--r-- | doc/rfc/rfc3520.txt | 1683 |
1 files changed, 1683 insertions, 0 deletions
diff --git a/doc/rfc/rfc3520.txt b/doc/rfc/rfc3520.txt new file mode 100644 index 0000000..3056c35 --- /dev/null +++ b/doc/rfc/rfc3520.txt @@ -0,0 +1,1683 @@ + + + + + + +Network Working Group L-N. Hamer +Request for Comments: 3520 B. Gage +Category: Standards Track Nortel Networks + B. Kosinski + Invidi Technologies + H. Shieh + AT&T Wireless + April 2003 + + + Session Authorization Policy Element + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + This document describes the representation of a session authorization + policy element for supporting policy-based per-session authorization + and admission control. The goal of session authorization is to allow + the exchange of information between network elements in order to + authorize the use of resources for a service and to co-ordinate + actions between the signaling and transport planes. This document + describes how a process on a system authorizes the reservation of + resources by a host and then provides that host with a session + authorization policy element which can be inserted into a resource + reservation protocol (e.g., the Resource ReSerVation Protocol (RSVP) + PATH message) to facilitate proper and secure reservation of those + resources within the network. We describe the encoding of session + authorization information as a policy element conforming to the + format of a Policy Data object (RFC 2750) and provide details + relating to operations, processing rules and error scenarios. + + + + + + + + + + +Hamer, et al. Standards Track [Page 1] + +RFC 3520 Session Authorization Policy Element April 2003 + + +Table of Contents + + 1. Conventions used in this document..............................3 + 2. Introduction...................................................3 + 3. Policy Element for Session Authorization.......................4 + 3.1 Policy Data Object Format..................................4 + 3.2 Session Authorization Policy Element.......................4 + 3.3 Session Authorization Attributes...........................4 + 3.3.1 Authorizing Entity Identifier..........................6 + 3.3.2 Session Identifier.....................................7 + 3.3.3 Source Address.........................................7 + 3.3.4 Destination Address....................................9 + 3.3.5 Start time............................................10 + 3.3.6 End time..............................................11 + 3.3.7 Resources Authorized..................................11 + 3.3.8 Authentication data...................................12 + 4. Integrity of the AUTH_SESSION policy element..................13 + 4.1 Shared symmetric keys.....................................13 + 4.1.1 Operational Setting using shared symmetric keys.......13 + 4.2 Kerberos..................................................14 + 4.2.1. Operational Setting using Kerberos...................15 + 4.3 Public Key................................................16 + 4.3.1. Operational Setting for public key based + authentication.......................................16 + 4.3.1.1 X.509 V3 digital certificates.....................17 + 4.3.1.2 PGP digital certificates..........................17 + 5. Framework.....................................................18 + 5.1 The coupled model.........................................18 + 5.2 The associated model with one policy server...............18 + 5.3 The associated model with two policy servers..............19 + 5.4 The non-associated model..................................19 + 6. Message Processing Rules......................................20 + 6.1 Generation of the AUTH_SESSION by the authorizing entity..20 + 6.2 Message Generation (RSVP Host)............................20 + 6.3 Message Reception (RSVP-aware Router).....................20 + 6.4 Authorization (Router/PDP)................................21 + 7. Error Signaling...............................................22 + 8. IANA Considerations...........................................22 + 9. Security Considerations.......................................24 + 10. Acknowledgments..............................................24 + 11. Normative References.........................................25 + 12. Informative References.......................................27 + 13. Intellectual Property Statement..............................27 + 14. Contributors.................................................28 + 15. Authors' Addresses...........................................29 + 16. Full Copyright Statement.....................................30 + + + + + +Hamer, et al. Standards Track [Page 2] + +RFC 3520 Session Authorization Policy Element April 2003 + + +1. Conventions used in this document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14, RFC 2119 + [RFC-2119]. + +2. Introduction + + RSVP [RFC-2205] is one example of a resource reservation protocol + that is used by a host to request specific services from the network + for particular application data streams or flows. RSVP requests will + generally result in resources being reserved in each router along the + data path. RSVP allows users to obtain preferential access to + network resources, under the control of an admission control + mechanism. Such admission control is often based on user or + application identity [RFC-3182], however, it is also valuable to + provide the ability for per-session admission control. + + In order to allow for per-session admission control, it is necessary + to provide a mechanism for ensuring use of resources by a host has + been properly authorized before allowing the reservation of those + resources. In order to meet this requirement, there must be + information in the resource reservation message which may be used to + verify the validity of the reservation request. This can be done by + providing the host with a session authorization policy element which + is inserted into the resource reservation message and verified by the + network. + + This document describes the session authorization policy element + (AUTH_SESSION) used to convey information about the resources + authorized for use by a session. The host must obtain an + AUTH_SESSION element from an authorizing entity via a session + signaling protocol such as SIP [RFC-3261]. The host then inserts the + AUTH_SESSION element into the resource reservation message to allow + verification of the network resource request; in the case of RSVP, + this element MUST be encapsulated in the Policy Data object [RFC- + 2750] of an RSVP PATH message. Network elements verify the request + and then process the resource reservation message based on admission + policy. + + [RFC-3521] describes a framework in which a session authorization + policy element may be utilized to contain information relevant to the + network's decision to grant a reservation request. + + + + + + + +Hamer, et al. Standards Track [Page 3] + +RFC 3520 Session Authorization Policy Element April 2003 + + +3. Policy Element for Session Authorization + +3.1 Policy Data Object Format + + The Session Authorization policy element conforms to the format of a + POLICY_DATA object which contains policy information and is carried + by policy based admission protocols such as RSVP. A detailed + description of the POLICY_DATA object can be found in "RSVP + Extensions for Policy Control" [RFC-2750]. + +3.2 Session Authorization Policy Element + + In this section we describe a policy element (PE) called session + authorization (AUTH_SESSION). The AUTH_SESSION policy element + contains a list of fields which describe the session, along with + other attributes. + + +-------------+-------------+-------------+-------------+ + | Length | P-Type = AUTH_SESSION | + +-------------+-------------+-------------+-------------+ + // Session Authorization Attribute List // + +-------------------------------------------------------+ + + Length: 16 bits + The length of the policy element (including the Length and P-Type) + is in number of octets (MUST be in multiples of 4) and indicates + the end of the session authorization information block. + + P-Type: 16 bits (Session Authorization Type) + AUTH_SESSION = 0x04 + The Policy element type (P-type) of this element. The Internet + Assigned Numbers Authority (IANA) acts as a registry for policy + element types as described in [RFC-2750]. + + Session Authorization Attribute List: variable length + The session authorization attribute list is a collection of + objects which describes the session and provides other information + necessary to verify the resource reservation request. An initial + set of valid objects is described in Section 3.3. + +3.3 Session Authorization Attributes + + A session authorization attribute may contain a variety of + information and has both an attribute type and subtype. The + attribute itself MUST be a multiple of 4 octets in length, and any + attributes that are not a multiple of 4 octets long MUST be padded to + a 4-octet boundary. All padding bytes MUST have a value of zero. + + + + +Hamer, et al. Standards Track [Page 4] + +RFC 3520 Session Authorization Policy Element April 2003 + + + +--------+--------+--------+--------+ + | Length | X-Type |SubType | + +--------+--------+--------+--------+ + | Value ... + +--------+--------+--------+--------+ + + Length: 16 bits + The length field is two octets and indicates the actual length of + the attribute (including Length, X-Type and SubType fields) in + number of octets. The length does NOT include any bytes padding + to the value field to make the attribute a multiple of 4 octets + long. + + X-Type: 8 bits + Session authorization attribute type (X-Type) field is one octet. + IANA acts as a registry for X-Types as described in section 7, + IANA Considerations. Initially, the registry contains the + following X-Types: + + 1 AUTH_ENT_ID The unique identifier of the entity which + authorized the session. + + 2 SESSION_ID Unique identifier for this session. + + 3 SOURCE_ADDR Address specification for the session + originator. + + 4 DEST_ADDR Address specification for the session + end-point. + + 5 START_TIME The starting time for the session. + + 6 END_TIME The end time for the session. + + 7 RESOURCES The resources which the user is authorized + to request. + + 8 AUTHENTICATION_DATA Authentication data of the session + authorization policy element. + + SubType: 8 bits + Session authorization attribute sub-type is one octet in length. + The value of the SubType depends on the X-Type. + + Value: variable length + The attribute specific information. + + + + + +Hamer, et al. Standards Track [Page 5] + +RFC 3520 Session Authorization Policy Element April 2003 + + +3.3.1 Authorizing Entity Identifier + + AUTH_ENT_ID is used to identify the entity which authorized the + initial service request and generated the session authorization + policy element. The AUTH_ENT_ID may be represented in various + formats, and the SubType is used to define the format for the ID. The + format for AUTH_ENT_ID is as follows: + + +-------+-------+-------+-------+ + | Length |X-Type |SubType| + +-------+-------+-------+-------+ + | OctetString ... + +-------+-------+-------+-------+ + + Length + Length of the attribute, which MUST be > 4. + + X-Type + AUTH_ENT_ID + + SubType + The following sub-types for AUTH_ENT_ID are defined. IANA acts as + a registry for AUTH_ENT_ID sub-types as described in section 7, + IANA Considerations. Initially, the registry contains the + following sub-types of AUTH_ENT_ID: + + 1 IPV4_ADDRESS IPv4 address represented in 32 bits + + 2 IPV6_ADDRESS IPv6 address represented in 128 bits + + 3 FQDN Fully Qualified Domain Name as defined in + RFC 1034 as an ASCII string. + + 4 ASCII_DN X.500 Distinguished name as defined in RFC + 2253 as an ASCII string. + + 5 UNICODE_DN X.500 Distinguished name as defined in RFC + 2253 as a UTF-8 string. + + 6 URI Universal Resource Identifier, as defined + in RFC 2396. + + 7 KRB_PRINCIPAL Fully Qualified Kerberos Principal name + represented by the ASCII string of a + principal followed by the @ realm name as + defined in RFC 1510 (e.g., + principalX@realmY). + + + + +Hamer, et al. Standards Track [Page 6] + +RFC 3520 Session Authorization Policy Element April 2003 + + + 8 X509_V3_CERT The Distinguished Name of the subject of + the certificate as defined in RFC 2253 as a + UTF-8 string. + + 9 PGP_CERT The PGP digital certificate of the + authorizing entity as defined in RFC 2440. + + OctetString + Contains the authorizing entity identifier. + +3.3.2 Session Identifier + + SESSION_ID is a unique identifier used by the authorizing entity to + identify the request. It may be used for a number of purposes, + including replay detection, or to correlate this request to a policy + decision entry made by the authorizing entity. For example, the + SESSION_ID can be based on simple sequence numbers or on a standard + NTP timestamp. + + +-------+-------+-------+-------+ + | Length |X-Type |SubType| + +-------+-------+-------+-------+ + | OctetString ... + +-------+-------+-------+-------+ + + Length + Length of the attribute, which MUST be > 4. + + X-Type + SESSION_ID + + SubType + No subtypes for SESSION_ID are currently defined; this field MUST + be set to zero. The authorizing entity is the only network entity + that needs to interpret the contents of the SESSION_ID therefore + the contents and format are implementation dependent. + + OctetString + Contains the session identifier. + +3.3.3 Source Address + + SOURCE_ADDR is used to identify the source address specification of + the authorized session. This X-Type may be useful in some scenarios + to make sure the resource request has been authorized for that + particular source address and/or port. + + + + + +Hamer, et al. Standards Track [Page 7] + +RFC 3520 Session Authorization Policy Element April 2003 + + + +-------+-------+-------+-------+ + | Length |X-Type |SubType| + +-------+-------+-------+-------+ + | OctetString ... + +-------+-------+-------+-------+ + + Length + Length of the attribute, which MUST be > 4. + + X-Type + SOURCE_ADDR + + SubType + The following sub types for SOURCE_ADDR are defined. IANA acts as + a registry for SOURCE_ADDR sub-types as described in section 7, + IANA Considerations. Initially, the registry contains the + following sub types for SOURCE_ADDR: + + 1 IPV4_ADDRESS IPv4 address represented in 32 bits + + 2 IPV6_ADDRESS IPv6 address represented in 128 bits + + 3 UDP_PORT_LIST list of UDP port specifications, + represented as 16 bits per list entry. + + 4 TCP_PORT_LIST list of TCP port specifications, + represented as 16 bits per list entry. + + OctetString + The OctetString contains the source address information. + + In scenarios where a source address is required (see Section 5), at + least one of the subtypes 1 through 2 (inclusive) MUST be included in + every Session Authorization Data Policy Element. Multiple + SOURCE_ADDR attributes MAY be included if multiple addresses have + been authorized. The source address field of the resource + reservation datagram (e.g., RSVP PATH) MUST match one of the + SOURCE_ADDR attributes contained in this Session Authorization Data + Policy Element. + + At most, one instance of subtype 3 MAY be included in every Session + Authorization Data Policy Element. At most, one instance of subtype + 4 MAY be included in every Session Authorization Data Policy Element. + Inclusion of a subtype 3 attribute does not prevent inclusion of a + subtype 4 attribute (i.e., both UDP and TCP ports may be authorized). + + If no PORT attributes are specified, then all ports are considered + valid; otherwise, only the specified ports are authorized for use. + + + +Hamer, et al. Standards Track [Page 8] + +RFC 3520 Session Authorization Policy Element April 2003 + + + Every source address and port list must be included in a separate + SOURCE_ADDR attribute. + +3.3.4 Destination Address + + DEST_ADDR is used to identify the destination address of the + authorized session. This X-Type may be useful in some scenarios to + make sure the resource request has been authorized for that + particular destination address and/or port. + + +-------+-------+-------+-------+ + | Length |X-Type |SubType| + +-------+-------+-------+-------+ + | OctetString ... + +-------+-------+-------+-------+ + + Length + Length of the attribute, which MUST be > 4. + + X-Type + DEST_ADDR + + SubType + The following sub types for DEST_ADDR are defined. IANA acts as a + registry for DEST_ADDR sub-types as described in section 7, IANA + Considerations. Initially, the registry contains the following + sub types for DEST_ADDR: + + 1 IPV4_ADDRESS IPv4 address represented in 32 bits + + 2 IPV6_ADDRESS IPv6 address represented in 128 bits + + 3 UDP_PORT_LIST list of UDP port specifications, + represented as 16 bits per list entry. + + 4 TCP_PORT_LIST list of TCP port specifications, + represented as 16 bits per list entry. + + OctetString + The OctetString contains the destination address specification. + + In scenarios where a destination address is required (see Section 5), + at least one of the subtypes 1 through 2 (inclusive) MUST be included + in every Session Authorization Data Policy Element. Multiple + DEST_ADDR attributes MAY be included if multiple addresses have been + authorized. The destination address field of the resource + + + + + +Hamer, et al. Standards Track [Page 9] + +RFC 3520 Session Authorization Policy Element April 2003 + + + reservation datagram (e.g., RSVP PATH) MUST match one of the + DEST_ADDR attributes contained in this Session Authorization Data + Policy Element. + + At most, one instance of subtype 3 MAY be included in every Session + Authorization Data Policy Element. At most, one instance of subtype + 4 MAY be included in every Session Authorization Data Policy Element. + Inclusion of a subtype 3 attribute does not prevent inclusion of a + subtype 4 attribute (i.e., both UDP and TCP ports may be authorized). + + If no PORT attributes are specified, then all ports are considered + valid; otherwise, only the specified ports are authorized for use. + + Every destination address and port list must be included in a + separate DEST_ADDR attribute. + +3.3.5 Start time + + START_TIME is used to identify the start time of the authorized + session and can be used to prevent replay attacks. If the + AUTH_SESSION policy element is presented in a resource request, the + network SHOULD reject the request if it is not received within a few + seconds of the start time specified. + + +-------+-------+-------+-------+ + | Length |X-Type |SubType| + +-------+-------+-------+-------+ + | OctetString ... + +-------+-------+-------+-------+ + + Length + Length of the attribute, which MUST be > 4. + + X-Type + START_TIME + + SubType + The following sub types for START_TIME are defined. IANA acts as + a registry for START_TIME sub-types as described in section 7, + IANA Considerations. Initially, the registry contains the + following sub types for START_TIME: + + 1 NTP_TIMESTAMP NTP Timestamp Format as defined in + RFC 1305. + + OctetString + The OctetString contains the start time. + + + + +Hamer, et al. Standards Track [Page 10] + +RFC 3520 Session Authorization Policy Element April 2003 + + +3.3.6 End time + + END_TIME is used to identify the end time of the authorized session + and can be used to limit the amount of time that resources are + authorized for use (e.g., in prepaid session scenarios). + + +-------+-------+-------+-------+ + | Length |X-Type |SubType| + +-------+-------+-------+-------+ + | OctetString ... + +-------+-------+-------+-------+ + + Length + Length of the attribute, which MUST be > 4. + + X-Type + END_TIME + + SubType + The following sub types for END_TIME are defined. IANA acts as a + registry for END_TIME sub-types as described in section 7, IANA + Considerations. Initially, the registry contains the following + sub types for END_TIME: + + 1 NTP_TIMESTAMP NTP Timestamp Format as defined in + RFC 1305. + + OctetString + The OctetString contains the end time. + +3.3.7 Resources Authorized + + RESOURCES is used to define the characteristics of the authorized + session. This X-Type may be useful in some scenarios to specify the + specific resources authorized to ensure the request fits the + authorized specifications. + + +-------+-------+-------+-------+ + | Length |X-Type |SubType| + +-------+-------+-------+-------+ + | OctetString ... + +-------+-------+-------+-------+ + + Length + Length of the attribute, which MUST be > 4. + + X-Type + RESOURCES + + + +Hamer, et al. Standards Track [Page 11] + +RFC 3520 Session Authorization Policy Element April 2003 + + + SubType + The following sub-types for RESOURCES are defined. IANA acts as a + registry for RESOURCES sub-types as described in section 7, IANA + Considerations. Initially, the registry contains the following + sub types for RESOURCES: + + 1 BANDWIDTH Maximum bandwidth (kbps) authorized. + + 2 FLOW_SPEC Flow spec specification as defined in RFC 2205. + + 3 SDP SDP Media Descriptor as defined in RFC 2327. + + 4 DSCP Differentiated services codepoint as defined in + RFC 2474. + + OctetString + The OctetString contains the resources specification. + + In scenarios where a resource specification is required (see Section + 5), at least one of the subtypes 1 through 4 (inclusive) MUST be + included in every Session Authorization Data Policy Element. + Multiple RESOURCE attributes MAY be included if multiple types of + resources have been authorized (e.g., DSCP and BANDWIDTH). + +3.3.8 Authentication data + + The AUTHENTICATION_DATA attribute contains the authentication data of + the AUTH_SESSION policy element and signs all the data in the policy + element up to the AUTHENTICATION_DATA. If the AUTHENTICATION_DATA + attribute has been included in the AUTH_SESSION policy element, it + MUST be the last attribute in the list. The algorithm used to + compute the authentication data depends on the AUTH_ENT_ID SubType + field. See Section 4 entitled Integrity of the AUTH_SESSION policy + element. + + A summary of AUTHENTICATION_DATA attribute format is described below. + + +-------+-------+-------+-------+ + | Length |X-Type |SubType| + +-------+-------+-------+-------+ + | OctetString ... + +-------+-------+-------+-------+ + + Length + Length of the attribute, which MUST be > 4. + + X-Type + AUTHENTICATION_DATA + + + +Hamer, et al. Standards Track [Page 12] + +RFC 3520 Session Authorization Policy Element April 2003 + + + SubType + No sub types for AUTHENTICATION_DATA are currently defined. This + field MUST be set to 0. + + OctetString + The OctetString contains the authentication data of the + AUTH_SESSION. + +4. Integrity of the AUTH_SESSION policy element + + This section describes how to ensure the integrity of the policy + element is preserved. + +4.1 Shared symmetric keys + + In shared symmetric key environments, the AUTH_ENT_ID MUST be of + subtypes: IPV4_ADDRESS, IPV6_ADDRESS, FQDN, ASCII_DN, UNICODE_DN or + URI. An example AUTH_SESSION policy element is shown below. + + +--------------+--------------+--------------+--------------+ + | Length | P-type = AUTH_SESSION | + +--------------+--------------+--------------+--------------+ + | Length |SESSION_ID | zero | + +--------------+--------------+--------------+--------------+ + | OctetString (The session identifier) ... + +--------------+--------------+--------------+--------------+ + | Length | AUTH_ENT_ID | IPV4_ADDRESS | + +--------------+--------------+--------------+--------------+ + | OctetString (The authorizing entity's Identifier) ... + +--------------+--------------+--------------+--------------+ + | Length |AUTH DATA. | zero | + +--------------+--------------+--------------+--------------+ + | KEY_ID | + +--------------+--------------+--------------+--------------+ + | OctetString (Authentication data) ... + +--------------+--------------+--------------+--------------+ + +4.1.1 Operational Setting using shared symmetric keys + + This assumes both the Authorizing Entity and the Network router/PDP + are provisioned with shared symmetric keys and with policies + detailing which algorithm to be used for computing the authentication + data along with the expected length of the authentication data for + that particular algorithm. + + Key maintenance is outside the scope of this document, but + AUTH_SESSION implementations MUST at least provide the ability to + manually configure keys and their parameters locally. The key used + + + +Hamer, et al. Standards Track [Page 13] + +RFC 3520 Session Authorization Policy Element April 2003 + + + to produce the authentication data is identified by the AUTH_ENT_ID + field. Since multiple keys may be configured for a particular + AUTH_ENT_ID value, the first 32 bits of the AUTH_DATA field MUST be a + key ID to be used to identify the appropriate key. Each key must + also be configured with lifetime parameters for the time period + within which it is valid as well as an associated cryptographic + algorithm parameter specifying the algorithm to be used with the key. + At a minimum, all AUTH_SESSION implementations MUST support the + HMAC-MD5-128 [RFC-2104], [RFC-1321] cryptographic algorithm for + computing the authentication data. New algorithms may be added by + the IETF standards process. + + It is good practice to regularly change keys. Keys MUST be + configurable such that their lifetimes overlap allowing smooth + transitions between keys. At the midpoint of the lifetime overlap + between two keys, senders should transition from using the current + key to the next/longer-lived key. Meanwhile, receivers simply accept + any identified key received within its configured lifetime and reject + those that are not. + +4.2 Kerberos + + In a Kerberos environment, the AUTH_ENT_ID MUST be of the subtype + KRB_PRINCIPAL. The KRB_PRINCIPAL field is defined as the Fully + Qualified Kerberos Principal name of the authorizing entity. + Kerberos [RFC-1510] authentication uses a trusted third party (the + Kerberos Distribution Center - KDC) to provide for authentication of + the AUTH_SESSION to a network server. It is assumed that a KDC is + present and both host and verifier of authentication information + (authorizing entity and router/PDP) implement Kerberos + authentication. + + An example of the Kerberos AUTH_DATA policy element is shown below. + + +--------------+--------------+--------------+--------------+ + | Length | P-type = AUTH_SESSION | + +--------------+--------------+--------------+--------------+ + | Length |SESSION_ID | zero | + +--------------+--------------+--------------+--------------+ + | OctetString (The session identifier) ... + +--------------+--------------+--------------+--------------+ + | Length | AUTH_ENT_ID | KERB_P. | + +--------------+--------------+--------------+--------------+ + | OctetString (The principal@realm name) ... + +--------------+--------------+--------------+--------------+ + + + + + + +Hamer, et al. Standards Track [Page 14] + +RFC 3520 Session Authorization Policy Element April 2003 + + +4.2.1. Operational Setting using Kerberos + + An authorizing entity is configured to construct the AUTH_SESSION + policy element that designates use of the Kerberos authentication + method (KRB_PRINCIPAL) as defined in RFC 1510. Upon reception of the + resource reservation request, the router/PDP contacts the local KDC, + with a KRB_AS_REQ message, to request credentials for the authorizing + entity (principal@realm). In this request, the client (router/PDP) + sends (in cleartext) its own identity and the identity of the server + (the authorizing entity taken from the AUTH_ENT_ID field) for which + it is requesting credentials. The local KDC responds with these + credentials in a KRB_AS_REP message, encrypted in the client's key. + The credentials consist of 1) a "ticket" for the server and 2) a + temporary encryption key (often called a "session key"). The + router/PDP uses the ticket to access the authorizing entity with a + KRB_AP_REQ message. The session key (now shared by the router/PDP + and the authorizing entity) is used to authenticate the router/PDP, + and is used to authenticate the authorizing entity. The session key + is an encryption key and is also used to encrypt further + communication between the two parties. The authorizing entity + responds by sending a concatenated message of a KRB_AP_REP and a + KRB_SAFE. The KRB_AP_REP is used to authenticate the authorizing + entity. The KRB_SAFE message contains the authentication data in the + safe-body field. The authentication data must be either a 16 byte + MD5 hash or 20 byte SHA-1 hash of all data in the AUTH_SESSION policy + element up to the AUTHENTICATION_DATA (note that when using Kerberos + the AUTH_SESSION PE should not include AUTHENTICATION_DATA as this is + sent in the KRB_SAFE message). The router/PDP independently computes + the hash, and compares it with the received hash in the user-data + field of the KRB-SAFE-BODY [RFC-1510]. + + At a minimum, all AUTH_SESSION implementations using Kerberos MUST + support the Kerberos des-cbc-md5 encryption type [RFC-1510] (for + encrypted data in tickets and Kerberos messages) and the Kerberos + rsa-md5-des checksum type [RFC-1510] (for the KRB_SAFE checksum) + checksum. New algorithms may be added by the IETF standards process. + Triple-DES encryption is supported in many Kerberos implementations + (although not specified in [RFC-1510]), and SHOULD be used over + single DES. + + For cases where the authorizing entity is in a different realm (i.e., + administrative domain, organizational boundary), the router/PDP needs + to fetch a cross-realm Ticket Granting Ticket (TGT) from its local + KDC. This TGT can be used to fetch authorizing entity tickets from + the KDC in the remote realm. Note that for performance + considerations, tickets are typically cached for extended periods. + + + + + +Hamer, et al. Standards Track [Page 15] + +RFC 3520 Session Authorization Policy Element April 2003 + + +4.3 Public Key + + In a public key environment, the AUTH_ENT_ID MUST be of the subtypes: + X509_V3_CERT or PGP_CERT. The authentication data is used for + authenticating the authorizing entity. An example of the public key + AUTH_SESSION policy element is shown below. + + +--------------+--------------+--------------+--------------+ + | Length | P-type = AUTH_SESSION | + +--------------+--------------+--------------+--------------+ + | Length |SESSION_ID | zero | + +--------------+--------------+--------------+--------------+ + | OctetString (The session identifier) ... + +--------------+--------------+--------------+--------------+ + | Length | AUTH_ENT_ID | PGP_CERT | + +--------------+--------------+--------------+--------------+ + | OctetString (Authorizing entity Digital Certificate) ... + +--------------+--------------+--------------+--------------+ + | Length |AUTH DATA. | zero | + +--------------+--------------+--------------+--------------+ + | OctetString (Authentication data) ... + +--------------+--------------+--------------+--------------+ + +4.3.1. Operational Setting for public key based authentication + + Public key based authentication assumes the following: + + - Authorizing entities have a pair of keys (private key and + public key). + + - Private key is secured with the authorizing entity. + + - Public keys are stored in digital certificates and a trusted + party, certificate authority (CA) issues these digital + certificates. + + - The verifier (PDP or router) has the ability to verify the + digital certificate. + + Authorizing entity uses its private key to generate + AUTHENTICATION_DATA. Authenticators (router, PDP) use the + authorizing entity's public key (stored in the digital certificate) + to verify and authenticate the policy element. + + + + + + + + +Hamer, et al. Standards Track [Page 16] + +RFC 3520 Session Authorization Policy Element April 2003 + + +4.3.1.1 X.509 V3 digital certificates + + When the AUTH_ENT_ID is of type X509_V3_CERT, AUTHENTICATION_DATA + MUST be generated following these steps: + + - A Signed-data is constructed as defined in section 5 of CMS + [RFC-3369]. A digest is computed on the content (as specified in + section 6.1) with a signer-specific message-digest algorithm. The + certificates field contains the chain of authorizing entity's + X.509 V3 digital certificates. The certificate revocation list is + defined in the crls field. The digest output is digitally signed + following section 8 of RFC 3447, using the signer's private key. + + When the AUTH_ENT_ID is of type X509_V3_CERT, verification MUST be + done following these steps: + + - Parse the X.509 V3 certificate to extract the distinguished name + of the issuer of the certificate. + - Certification Path Validation is performed as defined in section 6 + of RFC 3280. + - Parse through the Certificate Revocation list to verify that the + received certificate is not listed. + - Once the X.509 V3 certificate is validated, the public key of the + authorizing entity can be extracted from the certificate. + - Extract the digest algorithm and the length of the digested data + by parsing the CMS signed-data. + - The recipient independently computes the message digest. This + message digest and the signer's public key are used to verify the + signature value. + + This verification ensures integrity, non-repudiation and data origin. + +4.3.1.2 PGP digital certificates + + When the AUTH_ENT_ID is of type PGP_CERT, AUTHENTICATION_DATA MUST be + generated following these steps: + + - AUTHENTICATION_DATA contains a Signature Packet as defined in + section 5.2.3 of RFC 2440. In summary: + + - Compute the hash of all data in the AUTH_SESSION policy element + up to the AUTHENTICATION_DATA. + - The hash output is digitally signed following section 8 of + RFC 3447, using the signer's private key. + + + + + + + +Hamer, et al. Standards Track [Page 17] + +RFC 3520 Session Authorization Policy Element April 2003 + + + When the AUTH_ENT_ID is of type PGP_CERT, verification MUST be done + following these steps: + + - Validate the certificate. + - Once the PGP certificate is validated, the public key of the + authorizing entity can be extracted from the certificate. + - Extract the hash algorithm and the length of the hashed data by + parsing the PGP signature packet. + - The recipient independently computes the message digest. This + message digest and the signer's public key are used to verify the + signature value. + + This verification ensures integrity, non-repudiation and data origin. + +5. Framework + + [RFC-3521] describes a framework in which the AUTH_SESSION policy + element may be utilized to transport information required for + authorizing resource reservation for media flows. [RFC-3521] + introduces 4 different models: + + 1- the coupled model + 2- the associated model with one policy server + 3- the associated model with two policy servers + 4- the non-associated model. + + The fields that are required in an AUTH SESSION policy element + dependent on which of the models is used. + +5.1 The coupled model + + In the Coupled Model, the only information that MUST be included in + the policy element is the SESSION_ID; it is used by the Authorizing + Entity to correlate the resource reservation request with the media + authorized during session set up. Since the End Host is assumed to + be untrusted, the Policy Server SHOULD take measures to ensure that + the integrity of the SESSION_ID is preserved in transit; the exact + mechanisms to be used and the format of the SESSION_ID are + implementation dependent. + +5.2 The associated model with one policy server + + In this model, the contents of the AUTH_SESSION policy element MUST + include: + + - A session identifier - SESSION_ID. This is information that the + authorizing entity can use to correlate the resource reservation + request with the media authorized during session set up. + + + +Hamer, et al. Standards Track [Page 18] + +RFC 3520 Session Authorization Policy Element April 2003 + + + - The identity of the authorizing entity - AUTH_ENT_ID. This + information is used by the Edge Router to determine which + authorizing entity (Policy Server) should be used to solicit + resource policy decisions. + + In some environments, an Edge Router may have no means for + determining if the identity refers to a legitimate Policy Server + within its domain. In order to protect against redirection of + authorization requests to a bogus authorizing entity, the + AUTH_SESSION MUST also include: + + - AUTHENTICATION_DATA. This authentication data is calculated over + all other fields of the AUTH_SESSION policy element. + +5.3 The associated model with two policy servers + + The content of the AUTH_SESSION Policy Element is identical to the + associated model with one policy server. + +5.4 The non-associated model + + In this model, the AUTH_SESSION MUST contain sufficient information + to allow the Policy Server to make resource policy decisions + autonomously from the authorizing entity. The policy element is + created using information about the session by the authorizing + entity. The information in the AUTH_SESSION policy element MUST + include: + + - Calling party IP address or Identity (e.g., FQDN) - SOURCE_ADDR + X-TYPE + - Called party IP address or Identity (e.g., FQDN) - DEST_ADDR + X-TYPE + - The characteristics of (each of) the media stream(s) authorized + for this session - RESOURCES X-TYPE + - The authorization lifetime - START_TIME X-TYPE + - The identity of the authorizing entity to allow for validation of + the token in shared symmetric key and Kerberos schemes - + AUTH_ENT_ID X-TYPE + - The credentials of the authorizing entity in a public-key + scheme - AUTH_ENT_ID X-TYPE + - Authentication data used to prevent tampering with the + AUTH_SESSION policy element - AUTHENTICATION_DATA + + + + + + + + + +Hamer, et al. Standards Track [Page 19] + +RFC 3520 Session Authorization Policy Element April 2003 + + + Furthermore, the AUTH_SESSION policy element MAY contain: + + - The lifetime of (each of) the media stream(s) - END_TIME X-TYPE + - Calling party port number - SOURCE_ADDR X-TYPE + - Called party port number - DEST_ADDR X-TYPE + + All AUTH_SESSION fields MUST match with the resource request. If a + field does not match, the request SHOULD be denied. + +6. Message Processing Rules + +6.1 Generation of the AUTH_SESSION by the authorizing entity + + 1. Generate the AUTH_SESSION policy element with the appropriate + contents as specified in section 5. + + 2. If authentication is needed, the entire AUTH_SESSION policy + element is constructed, excluding the length, type and subtype + fields of the AUTH_SESSION field. Note that the message MUST + include either a START_TIME or a SESSION_ID (See Section 9), to + prevent replay attacks. The output of the authentication + algorithm, plus appropriate header information, is appended to the + AUTH_SESSION policy element. + +6.2 Message Generation (RSVP Host) + + An RSVP message is created as specified in [RFC-2205] with the + following modifications. + + 1. RSVP message MUST contain at most one AUTH_SESSION policy element. + + 2. The AUTH SESSION policy element received from the authorizing + entity (Section 3.2) MUST be copied without modification into the + POLICY DATA object. + + 3. POLICY_DATA object (containing the AUTH_SESSION policy element) is + inserted in the RSVP message in the appropriate place. + +6.3 Message Reception (RSVP-aware Router) + + RSVP message is processed as specified in [RFC-2205] with following + modifications. + + 1. If router is policy aware then it SHOULD send the RSVP message to + the PDP and wait for response. If the router is policy unaware + then it ignores the policy data objects and continues processing + the RSVP message. + + + + +Hamer, et al. Standards Track [Page 20] + +RFC 3520 Session Authorization Policy Element April 2003 + + + 2. Reject the message if the response from the PDP is negative. + + 3. Continue processing the RSVP message. + +6.4 Authorization (Router/PDP) + + 1. Retrieve the AUTH_SESSION policy element. Check the PE type field + and return an error if the identity type is not supported. + + 2. Verify the message integrity. + + - Shared symmetric key authentication: The Network router/PDP + uses the AUTH_ENT_ID field to consult a table keyed by that + field. The table should identify the cryptographic + authentication algorithm to be used along with the expected + length of the authentication data and the shared symmetric key + for the authorizing entity. Verify that the indicated length + of the authentication data is consistent with the configured + table entry and validate the authentication data. + + - Public Key: Validate the certificate chain against the trusted + Certificate Authority (CA) and validate the message signature + using the public key. + + - Kerberos Ticket: If the AUTH_ENT_ID is of subtype + KRB_PRINCIPAL, Request a ticket for the authorizing entity + (principal@realm) from the local KDC. Use the ticket to access + the authorizing entity and obtain authentication data for the + message. + + 3. Once the identity of the authorizing entity and the validity of + the service request has been established, the authorizing + router/PDP MUST then consult its local policy tables (the contents + of which are a local matter) in order to determine whether or not + the specific request is authorized. To the extent to which these + access control decisions require supplementary information, + routers/PDPs MUST ensure that supplementary information is + obtained securely. An example of insecure access control + decisions would be if the authorizing party relies upon an + insecure database (such as DNS or a public LDAP directory) and + authorizes with a certificate or an FQDN. + + 4. Verify the requested resources do not exceed the authorized QoS. + + + + + + + + +Hamer, et al. Standards Track [Page 21] + +RFC 3520 Session Authorization Policy Element April 2003 + + +7. Error Signaling + + If a PDP fails to verify the AUTH_SESSION policy element then it MUST + return a policy control failure (Error Code = 02) to the PEP. The + error values are described in [RFC-2205] and [RFC-2750]. Also the + PDP SHOULD supply a policy data object containing an AUTH_DATA Policy + Element with A-Type=POLICY_ERROR_CODE containing more details on the + Policy Control failure [RFC-3182]. If RSVP is being used, the PEP + MUST include this Policy Data object in the outgoing RSVP Error + message. + +8. IANA Considerations + + Following the policies outlined in [IANA-CONSIDERATIONS], Standard + RSVP Policy Elements (P-type values) are assigned by IETF Consensus + action as described in [RFC-2750]. + + P-Type AUTH_SESSION is assigned the value 0x04. + + Following the policies outlined in [IANA-CONSIDERATIONS], session + authorization attribute types (X-Type)in the range 0-127 are + allocated through an IETF Consensus action; X-Type values between + 128-255 are reserved for Private Use and are not assigned by IANA. + + X-Type AUTH_ENT_ID is assigned the value 1. + X-Type SESSION_ID is assigned the value 2. + X-Type SOURCE_ADDR is assigned the value 3. + X-Type DEST_ADDR is assigned the value 4. + X-Type START_TIME is assigned the value 5. + X-Type END_TIME is assigned the value 6. + X-Type RESOURCES is assigned the value 7. + X-Type AUTHENTICATION_DATA is assigned the value 8. + + Following the policies outlined in [IANA-CONSIDERATIONS], + AUTH_ENT_ID SubType values in the range 0-127 are allocated through + an IETF Consensus action; SubType values between 128-255 are + reserved for Private Use and are not assigned by IANA. + + AUTH_ENT_ID SubType IPV4_ADDRESS is assigned the value 1. + SubType IPV6_ADDRESS is assigned the value 2. + SubType FQDN is assigned the value 3. + SubType ASCII_DN is assigned the value 4. + SubType UNICODE_DN is assigned the value 5. + SubType URI is assigned the value 6. + SubType KRB_PRINCIPAL is assigned the value 7. + SubType X509_V3_CERT is assigned the value 8. + SubType PGP_CERT is assigned the value 9. + + + + +Hamer, et al. Standards Track [Page 22] + +RFC 3520 Session Authorization Policy Element April 2003 + + + Following the policies outlined in [IANA-CONSIDERATIONS], + SOURCE_ADDR SubType values in the range 0-127 are allocated through + an IETF Consensus action; SubType values between 128-255 are + reserved for Private Use and are not assigned by IANA. + + SOURCE_ADDR SubType IPV4_ADDRESS is assigned the value 1. + SubType IPV6_ADDRESS is assigned the value 2. + SubType UDP_PORT_LIST is assigned the value 3. + SubType TCP_PORT_LIST is assigned the value 4. + + Following the policies outlined in [IANA-CONSIDERATIONS], + DEST_ADDR SubType values in the range 0-127 are allocated through an + IETF Consensus action; SubType values between 128-255 are reserved + for Private Use and are not assigned by IANA. + + DEST_ADDR SubType IPV4_ADDRESS is assigned the value 1. + SubType IPV6_ADDRESS is assigned the value 2. + SubType UDP_PORT_LIST is assigned the value 3. + SubType TCP_PORT_LIST is assigned the value 4. + + Following the policies outlined in [IANA-CONSIDERATIONS], + START_TIME SubType values in the range 0-127 are allocated through an + IETF Consensus action; SubType values between 128-255 are + reserved for Private Use and are not assigned by IANA. + + START_TIME SubType NTP_TIMESTAMP is assigned the value 1. + + Following the policies outlined in [IANA-CONSIDERATIONS], + END_TIME SubType values in the range 0-127 are allocated through an + IETF Consensus action; SubType values between 128-255 are reserved + for Private Use and are not assigned by IANA. + + END_TIME SubType NTP_TIMESTAMP is assigned the value 1. + + Following the policies outlined in [IANA-CONSIDERATIONS], + RESOURCES SubType values in the range 0-127 are allocated through an + IETF Consensus action; SubType values between 128-255 are reserved + for Private Use and are not assigned by IANA. + + RESOURCES SubType BANDWIDTH is assigned the value 1. + SubType FLOW_SPEC is assigned the value 2. + SubType SDP is assigned the value 3. + SubType DSCP is assigned the value 4. + + + + + + + + +Hamer, et al. Standards Track [Page 23] + +RFC 3520 Session Authorization Policy Element April 2003 + + +9. Security Considerations + + The purpose of this document is to describe a mechanism for session + authorization to prevent theft of service. + + Replay attacks MUST be prevented. In the non-associated model, the + AUTH_SESSION policy element MUST include a START_TIME field and the + Policy Servers MUST support NTP to ensure proper clock + synchronization. Failure to ensure proper clock synchronization will + allow replay attacks since the clocks of the different network + entities may not be in-synch. The start time is used to verify that + the request is not being replayed at a later time. In all other + models, the SESSION_ID is used by the Policy Server to ensure that + the resource request successfully correlates with records of an + authorized session. If a AUTH_SESSION is replayed, it MUST be + detected by the policy server (using internal algorithms) and the + request MUST be rejected. + + To ensure that the integrity of the policy element is preserved in + untrusted environments, the AUTHENTICATION_DATA attribute MUST be + included. + + In environments where shared symmetric keys are possible, they should + be used in order to keep the AUTH_SESSION policy element size to a + strict minimum. This is especially true in wireless environments + where the AUTH_SESSION policy element is sent + over-the-air. The shared symmetric keys authentication option MUST + be supported by all AUTH_SESSION implementations. + + If shared symmetric keys are not a valid option, the Kerberos + authentication mechanism is reasonably well secured and efficient in + terms of AUTH_SESSION size. The AUTH_SESSION only needs to contain + the principal@realm name of the authorizing entity. This is much + more efficient than the PKI authentication option. + + PKI authentication option provides a high level of security and good + scalability, however it requires the presence of credentials in the + AUTH_SESSION policy element which impacts its size. + +10. Acknowledgments + + We would like to thank Francois Audet, Don Wade, Hamid Syed, Kwok Ho + Chan and many others for their valuable comments. Special thanks to + Eric Rescorla who provided numerous comments and suggestions that + improved this document. + + In addition, we would like to thank S. Yadav, et al., for their + efforts on RFC 3182, as this document borrows from their work. + + + +Hamer, et al. Standards Track [Page 24] + +RFC 3520 Session Authorization Policy Element April 2003 + + +11. Normative References + + [ASCII] Coded Character Set -- 7-Bit American Standard + Code for Information Interchange, ANSI X3.4- + 1986. + + [X.509-ITU] ITU-T (formerly CCITT) Information technology + Open Systems Interconnection - The Directory: + Authentication Framework Recommendation X.509 + ISO/IEC 9594-8 + + [RFC-1034] Mockapetris, P., "Domain names - concepts and + facilities", STD 13, RFC 1034, November 1987. + + [RFC-1305] Mills, D., "Network Time Protocol (Version 3) + Specification, Implementation, and Analysis", + RFC 1305, March 1992. + + [RFC-1321] Rivest, R., "The MD5 Message-Digest Algorithm", + RFC 1321, April 1992. + + [RFC-1510] Kohl, J. and C. Neuman, "The Kerberos Network + Authentication Service (V5)", RFC 1510, + September 1993. + + [RFC-2104] Krawczyk, H., Bellare, M. and R. Canetti, + "HMAC: Keyed-Hashing for Message + Authentication", RFC 2104, February 1997. + + [RFC-2119] Bradner, S., "Key words for use in RFCs to + Indicate Requirement Levels", BCP 14, RFC 2119, + March 1997. + + [RFC-2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, + S. and S. Jamin, "Resource ReSerVation Protocol + (RSVP) - Version 1 Functional Specification", + RFC 2205, September 1997. + + [RFC-2209] Braden, R. and L. Zhang, "Resource ReSerVation + Protocol (RSVP) - Version 1 Message Processing + Rules", RFC 2209, September 1997. + + [RFC-2253] Wahl, M., Kille, S. and T. Howes , "UTF-8 + String Representation of Distinguished Names", + RFC 2253, December 1997. + + [RFC-2279] Yergeau, F., "UTF-8, a transformation format of + ISO 10646", RFC 2279, January 1998. + + + +Hamer, et al. Standards Track [Page 25] + +RFC 3520 Session Authorization Policy Element April 2003 + + + [RFC-2327] Handley, M. and V. Jacobson, "SDP: Session + Description Protocol", RFC 2327, October 1998. + + [RFC-2396] Berners-Lee, T., Fielding, R., Masinter, L., + "Uniform Resource Identifiers (URI): Generic + Syntax", RFC 2396, August 1998. + + [RFC-2440] Callas, J., Donnerhacke, L., Finney, H. and R. + Thayer, "OpenPGP Message Format", RFC 2440, + November 1998. + + [RFC-2474] Nichols, K., Blake, S., Baker, F. and D. Black, + "Definition of the Differentiated Services + Field (DS Field) in the IPv4 and IPv6 Headers", + RFC 2474, December 1998. + + [RFC-2750] Herzog, S., "RSVP Extensions for Policy + Control", RFC 2750, January 2000. + + [RFC-2753] Yavatkar, R., Pendarakis, D. and R. Guerin, "A + Framework for Policy-based Admission Control + RSVP", RFC 2753, January 2000. + + [RFC-3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., + Moore, T., Herzog, S. and R. Hess, "Identity + Representation for RSVP", RFC 3182, October + 2001 + + [RFC-3280] Housley, R., Polk, W., Ford, W. and D. Solo, + "Internet X.509 Public Key Infrastructure + Certificate and Certificate Revocation List + (CRL) Profile", RFC 3280, April 2002. + + [RFC-3369] Housley, R., "Cryptographic Message Syntax", + RFC 3369, August 2002. + + [RFC-3447] Jonsson, J. and B. Kaliski, "Public-Key + Cryptography Standards (PKCS) #1: RSA + Cryptography Specifications Version 2.1", RFC + 3447, February 2003. + + [RFC-3521] Hamer, L.-N., Gage, B. and H. Shieh, "Framework + for Session Setup with Media Authorization", + RFC 3521, April 2003. + + + + + + + +Hamer, et al. Standards Track [Page 26] + +RFC 3520 Session Authorization Policy Element April 2003 + + +12. Informative References + + [IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for + Writing an IANA Considerations Section in + RFCs", BCP 26, RFC 2434, October 1998. + + [RFC-3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., + Johnston, A., Peterson, J., Sparks, R., + Handley, M. and E. Schooler, "SIP: Session + Initiation Protocol", RFC 3261, June 2002. + +13. Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + + + + + + + + + + + + + + + + + + +Hamer, et al. Standards Track [Page 27] + +RFC 3520 Session Authorization Policy Element April 2003 + + +14. Contributors + + Matt Broda + Nortel Networks + + EMail: mbroda@nortelnetworks.com + + + Louis LeVay + Nortel Networks + + EMail: levay@nortelnetworks.com + + + Dennis Beard + Nortel Networks + + EMail: beardd@nortelnetworks.com + + + Lawrence Dobranski + Nortel Networks + + EMail: ldobran@nortelnetworks.com + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hamer, et al. Standards Track [Page 28] + +RFC 3520 Session Authorization Policy Element April 2003 + + +15. Authors' Addresses + + Louis-Nicolas Hamer + Nortel Networks + PO Box 3511 Station C + Ottawa, Ontario + Canada K1Y 4H7 + + Phone: +1 613.768.3409 + EMail: nhamer@nortelnetworks.com + + + Brett Kosinski + Invidi Technologies + Edmonton, Alberta + Canada T5J 3S4 + + EMail: brettk@invidi.com + + + Bill Gage + Nortel Networks + PO Box 3511 Station C + Ottawa, Ontario + Canada K1Y 4H7 + + Phone: +1 613.763.4400 + EMail: gageb@nortelnetworks.com + + + Hugh Shieh + AT&T Wireless + 7277 164th Avenue NE + Redmond, WA + USA 98073-9761 + + Phone: +1 425.580.6898 + EMail: hugh.shieh@attws.com + + + + + + + + + + + + + +Hamer, et al. Standards Track [Page 29] + +RFC 3520 Session Authorization Policy Element April 2003 + + +16. Full Copyright Statement + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Hamer, et al. Standards Track [Page 30] + |