Network Working Group S. Yadav Request for Comments: 3182 R. Yavatkar Obsoletes: 2752 Intel Category: Standards Track R. Pabbati P. Ford T. Moore Microsoft S. Herzog PolicyConsulting.Com R. Hess Intel October 2001 Identity Representation for RSVP 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 (2001). All Rights Reserved.
AbstractThis document describes the representation of identity information in POLICY_DATA object for supporting policy based admission control in the Resource ReSerVation Protocol (RSVP). The goal of identity representation is to allow a process on a system to securely identify the owner and the application of the communicating process (e.g., user id) and convey this information in RSVP messages (PATH or RESV) in a secure manner. We describe the encoding of identities as RSVP policy element. We describe the processing rules to generate identity policy elements for multicast merged flows. Subsequently, we describe representations of user identities for Kerberos and Public Key based user authentication mechanisms. In summary, we describe the use of this identity information in an operational setting. This memo corrects an RSVP POLICY_DATA P-Type codepoint assignment error and a field size definition error in ErrorValue in RFC 2752.
RFC 2119]. RFC 2205] is a resource reservation setup protocol designed for an integrated services Internet [RFC 1633]. RSVP is used by a host to request specific quality of service (QoS) from the network for particular application data streams or flows. RSVP is also used by routers to deliver QoS requests to all nodes along the path(s) of the flows and to establish and maintain state to provide the requested service. RSVP requests will generally result in resources being reserved in each node along the data path. RSVP allows particular users to obtain preferential access to network resources, under the control of an admission control mechanism. Permission to make a reservation is based both upon the availability of the requested resources along the path of the data and upon satisfaction of policy rules. Providing policy based admission control mechanism based on user identity or application is one of the prime requirements. In order to solve these problems and implement identity based policy control it is required to identify the user and/or application making a RSVP request. This document proposes a mechanism for sending identification information in the RSVP messages and enables authorization decisions based on policy and identity. We describe the authentication policy element (AUTH_DATA) contained in the POLICY_DATA object. User process can generate an AUTH_DATA policy element and gives it to RSVP process (service) on the originating host. RSVP service inserts AUTH_DATA into the RSVP message to identify the owner (user and/or application) making the request for network resources. Network elements, such as routers, authenticate request using the credentials presented in the AUTH_DATA and admit the RSVP message based on admission policy. After a request has been authenticated, first hop router installs the RSVP state and forwards the new policy element returned by the Policy Decision Point (PDP) [POL-FRAME].
POL- EXT]. POL-EXT]. Initially, the registry contains the following P-Types for identity: 2 AUTH_USER Authentication scheme to identify users 3 AUTH_APP Authentication scheme to identify applications Authentication Attribute List Authentication attributes contain information specific to authentication method and type of AUTH_DATA. The policy element provides the mechanism for grouping a collection of authentication attributes.
section 8, IANA Considerations. Initially, the registry contains the following A-Types: 1 POLICY_LOCATOR Unique string for locating the admission policy (such as X.500 DN described in [RFC 1779]). 2 CREDENTIAL User credential such as Kerberos ticket, or digital certificate. Application credential such as application ID. 3 DIGITAL_SIGNATURE Digital signature of the authentication data policy element. 4 POLICY_ERROR_OBJECT Detailed information on policy failures. SubType Authentication attribute sub-type field is one octet. Value of SubType depends on A-type. Value: The value field contains the attribute specific information.
section 8, IANA Considerations. Initially, the registry contains the following sub types for POLICY_LOCATOR: 1 ASCII_DN OctetString contains the X.500 DN as described in the RFC 1779 as an ASCII string. 2 UNICODE_DN OctetString contains the X.500 DN described in the RFC 1779 as an UNICODE string. 3 ASCII_DN_ENCRYPT OctetString contains the encrypted X.500 DN. The Kerberos session key or digital certificate private key is used for encryption. For Kerberos encryption the format is the same as returned from gss_seal [RFC 1509]. 4 UNICODE_DN_ENCRYPT OctetString contains the encrypted UNICODE X.500 DN. The Kerberos session key or digital certificate private key is used for encryption. For Kerberos encryption the format is the same as returned from gss_seal [RFC 1509]. OctetString The OctetString field contains the DN.
section 8, IANA Considerations. Initially, the registry contains the following sub types for CREDENTIAL: 1 ASCII_ID OctetString contains user or application identification in plain ASCII text string. 2 UNICODE_ID OctetString contains user or application identification in plain UNICODE text string. 3 KERBEROS_TKT OctetString contains Kerberos ticket. 4 X509_V3_CERT OctetString contains X.509 V3 digital certificate [X.509]. 5 PGP_CERT OctetString contains PGP digital certificate. OctetString The OctetString contains the user or application credential.
+----------+----------+----------+----------+ | Length | A-Type | SubType | +----------+----------+----------+----------+ | 0 (Reserved) | ErrorValue | +----------+----------+----------+----------+ | OctetString ... +----------+----------+----------+----------+ Length Length of the attribute, which MUST be >= 8. A-Type POLICY_ERROR_CODE SubType No sub types for POLICY_ERROR_CODE are currently defined. This field MUST be set to 0. ErrorValue A 16-bit bit code containing the reason that the policy decision point failed to process the policy element. IANA acts as a registry for ErrorValues as described in section 8, IANA Considerations. Following values have been defined. 1 ERROR_NO_MORE_INFO No information is available. 2 UNSUPPORTED_CREDENTIAL_TYPE This type of credentials is not supported. 3 INSUFFICIENT_PRIVILEGES The credentials do not have sufficient privilege. 4 EXPIRED_CREDENTIAL The credential has expired. 5 IDENTITY_CHANGED Identity has changed. OctetString The OctetString field contains information from the policy decision point that MAY contain additional information about the policy failure. For example, it may include a human-readable message in the ASCII text.
RFC 1510] authentication uses a trusted third party (the Kerberos Distribution Center - KDC) to provide for authentication of the user to a network server. It is assumed that a KDC is present and both host and verifier of authentication information (router or PDP) implement Kerberos authentication. A summary of the Kerberos AUTH_DATA policy element is shown below. +--------------+--------------+--------------+--------------+ | Length | P-type = AUTH_USER | +--------------+--------------+--------------+--------------+ | Length |POLICY_LOCATOR| SubType | +--------------+--------------+--------------+--------------+ | OctetString (User's Distinguished Name) ... +--------------+--------------+--------------+--------------+ | Length | CREDENTIAL | KERBEROS_TKT | +--------------+--------------+--------------+--------------+ | OctetString (Kerberos Session Ticket) ... +--------------+--------------+--------------+--------------+
ticket for the next hop network node or its PDP. The identity of the PDP or next network hop can be statically configured, learned via DHCP or maintained in a directory service. The Kerberos ticket is sent to the next network node (which may be a router or host) in a RSVP message. The KDC is used to validate the ticket and authentication the user sending RSVP message.
RSVP requestor uses its private key to generate DIGITAL_SIGNATURE. User Authenticators (router, PDP) use the user's public key (stored in the digital certificate) to verify the signature and authenticate the user. +-----+ +-----+ | PDP |-------+ | PDP | +-----+ | ................... +-----+ | : : | +--------+ : Transit : +-------+ +----| Router |------: Network : -------| Router|--+ | +--------+ : : +-------+ | | | :.................: | | | | | | Host A B C D Figure 1: User and Application Authentication using AUTH_DATA PE Network nodes (hosts/routers) generate AUTH_DATA policy elements, contents of which are depend on the identity type used and the authentication method used. These generally contain authentication credentials (Kerberos ticket or digital certificate) and policy locators (which can be the X.500 Distinguished Name of the user or network node or application names). Network nodes generate AUTH_DATA policy element containing the authentication identity when making the RSVP request or forwarding a RSVP message.
Network nodes generate user AUTH_DATA policy element using the following rules: 1. For unicast sessions the user policy locator is copied from the previous hop. The authentication credentials are for the current network node identity. 2. For multicast messages the user policy locator is for the current network node identity. The authentication credentials are for the current network node. Network nodes generate application AUTH_DATA policy element using the following rules: 1. For unicast sessions the application AUTH_DATA is copied from the previous hop. 2. For multicast messages the application AUTH_DATA is either the first application AUTH_DATA in the message or chosen by the PDP. RFC 2205] with following modifications. 1. RSVP message MAY contain multiple AUTH_DATA policy elements. 2. Authentication policy element (AUTH_DATA) is created and the IdentityType field is set to indicate the identity type in the policy element. - DN is inserted as POLICY_LOCATOR attribute. - Credentials such as Kerberos ticket or digital certificate are inserted as the CREDENTIAL attribute. 3. POLICY_DATA object (containing the AUTH_DATA policy element) is inserted in the RSVP message in appropriate place. If INTEGRITY object is not computed for the RSVP message then an INTEGRITY object SHOULD be computed for this POLICY_DATA object, as described in the [POL_EXT], and SHOULD be inserted as a Policy Data option.
RFC 2205] with following modifications. 1. If router is not 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. 2. Reject the message if the response from the PDP is negative. 3. Continue processing the RSVP message. RFC 2205] and [POL-EXT]. Also 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 (see section 3.3.4). The PEP will include this Policy Data object in the outgoing RSVP Error message. IANA-CONSIDERATIONS], Standard RSVP Policy Elements (P-type values) are assigned by IETF Consensus action as described in [POL-EXT].
P-Type AUTH_USER is assigned the value 2. P-Type AUTH_APP is assigned the value 3. Following the policies outlined in [IANA-CONSIDERATIONS], authentication attribute types (A-Type) in the range 0-127 are allocated through an IETF Consensus action, A-Type values between 128-255 are reserved for Private Use and are not assigned by IANA. A-Type POLICY_LOCATOR is assigned the value 1. A-Type CREDENTIAL is assigned the value 2. A-Type DIGITAL_SIGNATURE is assigned the value 3. A-Type POLICY_ERROR_OBJECT is assigned the value 4. Following the policies outlined in [IANA-CONSIDERATIONS], POLICY_LOCATOR SubType values in the range 0-127 are allocated through an IETF Consensus action, POLICY_LOCATOR SubType values between 128-255 are reserved for Private Use and are not assigned by IANA. POLICY_LOCATOR SubType ASCII_DN is assigned the value 1, SubType UNICODE_DN is assigned the value 2, SubType ASCII_DN_ENCRYPT is assigned the value 3 and SubType UNICODE_DN_ENCRYPT is assigned the value 4. Following the policies outlined in [IANA-CONSIDERATIONS], CREDENTIAL SubType values in the range 0-127 are allocated through an IETF Consensus action, CREDENTIAL SubType values between 128-255 are reserved for Private Use and are not assigned by IANA. CREDENTIAL SubType ASCII_ID is assigned the value 1, SubType UNICODE_ID is assigned the value 2, SubType KERBEROS_TKT is assigned the value 3, SubType X509_V3_CERT is assigned the value 4, SubType PGP_CERT is assigned the value 5. Following the policies outlined in [IANA-CONSIDERATIONS], ErrorValues in the range 0-32767 are allocated through an IETF Consensus action, ErrorValues between 32768-65535 are reserved for Private Use and are not assigned by IANA. ErrorValue ERROR_NO_MORE_INFO is assigned the value 1, UNSUPPORTED_CREDENTIAL_TYPE is assigned the value 2, INSUFFICIENT_PRIVILEGES is assigned the value 3, EXPIRED_CREDENTIAL is assigned the value 4, and IDENTITY_CHANGED is assigned the value 5.
[ASCII] Coded Character Set -- 7-Bit American Standard Code for Information Interchange, ANSI X3.4- 1986. [IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [POL-EXT] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000. [POL-FRAME] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for Policy-based Admission Control RSVP", RFC 2753, January 2000. [RFC 1510] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993. [RFC 1704] Haller, N. and R. Atkinson, "On Internet Authentication", RFC 1704, October 1994.
[RFC 1779] Killie, S., "A String Representation of Distinguished Names", RFC 1779, March 1995. [RFC 2205] Braden, R., 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 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC 2751] Herzog, S., "Signaled Preemption Priority Policy Element", RFC 2751, January 2000. [UNICODE] The Unicode Consortium, "The Unicode Standard, Version 2.0", Addison-Wesley, Reading, MA, 1996. [X.509] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", RFC 2459, January 1999. [X.509-ITU] ITU-T (formerly CCITT) Information technology - Open Systems Interconnection - The Directory: Authentication Framework Recommendation X.509 ISO/IEC 9594-8
Raj Yavatkar Intel, JF3-206 2111 NE 25th Avenue Hillsboro, OR 97124 EMail: Raj.Yavatkar@intel.com Ramesh Pabbati Microsoft 1 Microsoft Way Redmond, WA 98054 EMail: firstname.lastname@example.org Peter Ford Microsoft 1 Microsoft Way Redmond, WA 98054 EMail: email@example.com Tim Moore Microsoft 1 Microsoft Way Redmond, WA 98054 EMail: firstname.lastname@example.org Shai Herzog PolicyConsulting.Com 200 Clove Rd. New Rochelle, NY 10801 EMail: email@example.com Rodney Hess Intel, BD1 28 Crosby Drive Bedford, MA 01730 EMail: firstname.lastname@example.org
Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.