Internet Draft Satyendra Yadav File: Intel Ramesh Pabbati Microsoft Tim Moore Microsoft Shai Herzog IPHighway Identity Representation for RSVP November 1998 Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress". To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). A Revised Version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested. This document will expire in May 1999. Distribution of this draft is unlimited. 1. Abstract This document describes the representation of identity information in POLICY_DATA object [POL-EXT] for supporting policy based admission control in RSVP. The goal of identity representation is to allow a process on a system to securely identify the owner 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. Yadav, et al. 1 Internet Draft Identity Representation for RSVP November 1998 2. 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 [RFC-2119]. 3. Introduction RSVP [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 is one of the prime requirements. In order to solve these problems and implement user based policy control it is required to identify the user making an RSVP request. This document proposes a mechanism for sending identification information in the RSVP requests and enables authorization decisions based on policy and identity of the user requesting resources from the network. We describe the authentication policy element (AUTH_DATA) contained in the POLICY_DATA object. User process generates an AUTH_DATA policy element and gives it to RSVP process (service) on the originating host. RSVP process inserts AUTH_DATA into the RSVP message to identify the owner (user) making the request for network resources. Network elements, such as routers, authenticate user 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 server. Yadav, et al. 2 Internet Draft Identity Representation for RSVP November 1998 4. Policy Element for Authentication Data 4.1 Policy Data Object Format POLICY_DATA objects contain policy information and are carried by RSVP messages. A detail description of the format of POLICY_DATA object can be found in “RSVP Extensions for Policy Control” [POL- EXT]. 4.2 Authentication Data Policy Element In this section, we describe a policy element (PE) called authentication data (AUTH_DATA). AUTH_DATA policy element contains a list of authentication attributes. Policy object containing AUTH_DATA MUST be protected against replay attacks using INTEGRITY object option as described in the [POL-EXT]. +-------------+-------------+-------------+-------------+ | Length | P-Type = AUTH_DATA | +-------------+-------------+-------------+-------------+ | IdentityType | 0 (Reserved) | +-------------+-------------+-------------+-------------+ // Authentication Attribute List // | | +-------------------------------------------------------+ Length The length of the policy element (including the Length and P- Type) is in number of octets and indicates the end of the authentication attribute list. AUTH_DATA Policy element type (P-type) for the authentication data as registered with Internet Assigned Numbers Authority (IANA). IdentityType This field describes the authentication method being used. Following types are currently defined. 1 AUTH_USER authentication scheme to identify users 2 AUTH_APP authentication scheme to identify applications Reserved Must be set to 0. Yadav, et al. 3 Internet Draft Identity Representation for RSVP November 1998 Authentication Attribute List Authentication attributes contain information specific to authentication methods. The policy element provides the mechanism for grouping a collection of authentication attributes. 4.3 Authentication Attributes Authentication attributes must be encoded as a multiple of 4 octets, attributes that are not a multiple of 4 octets long must be padded to a 4-octet boundary. +--------+--------+--------+--------+ | Length | A-Type |SubType | +--------+--------+--------+--------+ | Value … +--------+--------+--------+--------+ Length The length field is two octets and indicates the actual length of the attribute (including the Length and A-Type fields) in number of octets. The length does not include any bytes padding the attribute to make it multiple of 4 octets long. A-Type Authentication attribute type (A-Type) field is one octet. The following values are defined: 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. SubType Authentication attribute sub-type field is one octet. Value of SubType depends on A-type. Value: The value field contains 0-65351 octets. Yadav, et al. 4 Internet Draft Identity Representation for RSVP November 1998 4.3.1 Policy Locator POLICY_LOCATOR is used to locate the admission policy for the user or application. Distinguished Name (DN) is unique for each policy hence a DN is used as policy locator. +-------+-------+-------+-------+ | Length |A-Type |SubType| +-------+-------+-------+-------+ | OctetString … +-------+-------+-------+-------- Length > 4 A-Type POLICY_LOCATOR SubType Following sub types for POLICY_LOCATOR are defined. 1 X500_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 X500_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 X500_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. 4.3.2 Credential CREDENTIAL indicates the credential of the user or application to be authenticated. For Kerberos authentication method the CREDENTIAL object contains the Kerberos session ticket. For public key based authentication this field contains a digital certificate. Yadav, et al. 5 Internet Draft Identity Representation for RSVP November 1998 A summary of the CREDENTIAL attribute format is shown below. The fields are transmitted from left to right. +-------+-------+-------+-------+ | Length |A-Type |SubType| +-------+-------+-------+-------+ | OctetString … +-------+-------+-------+-------- Length > 4 A-Type _CREDENTIAL SubType Following sub types for CREDENTIAL are defined. 1 ASCII_ID OctetString contains user or application identification in plain ASCII text. 2 UNICODE_ID OctetString contains user or application identification in plain UNICODE text. 3 KERBEROS_TKT OctetString contains Kerberos ticket. 4 X509_V3_CERT OctetString contains X.509v3 digital certificate [X.509]. 5 PGP_CERT OctetString contains PGP digital certificate. OctetString The OctetString contains the user or application credential. 4.3.3 Digital Signature The DIGITAL_SIGNATURE attribute must be the last attribute in the attribute list and contains the digital signature of the AUTH_DATA policy element. The digital signature signs all data in the AUTH_DATA policy element up to the DIGITAL_SIGNATURE. The algorithm used to compute the digital signature depends on the authentication method specified by the CREDENTIAL SubType field. A summary of DIGITAL_SIGNATURE attribute format is described below. +-------+-------+-------+-------+ | Length |A-Type |SubType| +-------+-------+-------+-------+ | OctetString … +-------+-------+-------+-------- Yadav, et al. 6 Internet Draft Identity Representation for RSVP November 1998 Length > 4 A-Type DIGITAL_SIGNATURE SubType No sub types for DIGITAL_SIGNATURE are currently defined. This field must be set to 0. OctetString OctetString contains the digital signature of the AUTH_DATA. 5. Authentication Data Formats Authentication attributes are grouped in a policy element to represent the identity credentials. 5.1 Simple User Authentication In simple user authentication method the user login ID (in plain ASCII or UNICODE text) is encoded as CREDENTIAL attribute. A summary of the simple user AUTH_DATA policy element is shown below. +--------------+--------------+--------------+--------------+ | Length | P-type = AUTH_DATA | +--------------+--------------+--------------+--------------+ | IdentityType = AUTH_USER | 0 | +--------------+--------------+--------------+--------------+ | Length |POLICY_LOCATOR| SubType | +--------------+--------------+--------------+--------------+ | OctetString (User’s Distinguished Name) … +--------------+--------------+--------------+--------------+ | Length |CREDENTIAL | SubType | +--------------+--------------+--------------+--------------+ | OctetString (User’s login ID) … +--------------+--------------+--------------+--------------+ 5.2 Kerberos User Authentication Kerberos [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 policy server) implement Kerberos authentication. Yadav, et al. 7 Internet Draft Identity Representation for RSVP November 1998 A summary of the Kerberos AUTH_DATA policy element is shown below. +--------------+--------------+--------------+--------------+ | Length | P-type (AUTH_DATA) | +--------------+--------------+--------------+--------------+ | IdentityType = AUTH_USER | +--------------+--------------+--------------+--------------+ | Length |POLICY_LOCATOR| SubType | +--------------+--------------+--------------+--------------+ | OctetString (User’s Distinguished Name) … +--------------+--------------+--------------+--------------+ | Length | CREDENTIAL | KERBEROS_TKT | +--------------+--------------+--------------+--------------+ | OctetString (Kerberos Session Ticket) … +--------------+--------------+--------------+--------------+ 5.2.1. Operational Setting using Kerberos Identities An RSVP enabled host is configured to construct and insert AUTH_DATA policy element into RSVP messages that designate use of the Kerberos authentication method (KERBEROS_TKT). Upon RSVP session initialization, the user application contacts the KDC to obtain a Kerberos ticket for the next network node or its policy server. A router when generating a RSVP message contacts the KDC to obtain a Kerberos ticket for the next hop network node or its policy server. The identity of the policy server 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 router may be a policy node or may use a policy server. The KDC is used to validate the ticket and authentication the user sending RSVP message. Yadav, et al. 8 Internet Draft Identity Representation for RSVP November 1998 5.3 Public Key based User Authentication In public key based user authentication method digital certificate is encoded as user credentials. The digital signature is used for authenticating the user. A summary of the public key user AUTH_DATA policy element is shown below. +--------------+--------------+--------------+--------------+ | Length | P-type (AUTH_DATA) | +--------------+--------------+--------------+--------------+ | IdentityType = AUTH_USER | 0 | +--------------+--------------+--------------+--------------+ | Length |POLICY_LOCATOR| SubType | +--------------+--------------+--------------+--------------+ | OctetString (User’s Distinguished Name) … +--------------+--------------+--------------+--------------+ | Length | _CREDENTIAL | SubType | +--------------+--------------+--------------+--------------+ | OctetString (User’s Digital Certificate)… +--------------+--------------+--------------+--------------+ | Length |DIGITAL_SIGN. | 0 | +--------------+--------------+--------------+--------------+ | OctetString (Digital signature) … +--------------+--------------+--------------+--------------+ 5.3.1. Operational Setting for public key based authentication Public key based authentication assumes following: - RSVP service requestors have a pair of keys (private key and public key). - Private key is secured with the user. - Public keys are stored in digital certificates and a trusted party, certificate authority (CA) issues these digital certificates. - The verifier (policy server or router) has the ability to verify the digital certificate. RSVP requestor uses its private key to generate DIGITAL_SIGNATURE. User Authenticators (router, policy server) use the user’s public key (stored in the digital certificate) to verify the signature and authenticate the user. Yadav, et al. 9 Internet Draft Identity Representation for RSVP November 1998 5.4 Simple Application Authentication The application authentication method encodes the application identification such as an executable filename as plain ASCII or UNICODE text. +--------------+--------------+--------------+------------------+ | Length | P-type = AUTH_DATA | +--------------+--------------+--------------+------------------+ | IdentityType = AUTH_APP | 0 | +--------------+--------------+--------------+------------------+ | Length |POLICY_LOCATOR| SubType | +--------------+--------------+--------------+------------------+ | OctetString (Application Distinguished Name) … +--------------+--------------+--------------+------------------+ | Length | CREDENTIAL | SubType +--------------+--------------+--------------+------------------+ | OctetString (Application Identification) +--------------+--------------+--------------+------------------+ 6. Operation +------+ +------+ |Policy|------+ |Policy| |Server| | |Server| +------+ | ………………………………….……. +------+ | : : | | : : | +---------+ : : +-------+ +----|First hop| Transit Transit -----|Transit| | | Router |----Router Router | Router|--+ | +---------+ : : +-------+ | | | :……………………………………...: | | | | | | Host A B C D Figure 1: User and Application Authentication using AUTH_DATA object Hosts and network nodes generate AUTH DATA policy elements, contents of which are depends on the identity type used and the authentication method used. But generally contains 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). Host systems generate AUTH_DATA policy element containing the authentication identity when making the RSVP request. Network nodes generate user AUTH_DATA policy element using the following rules Yadav, et al. 10 Internet Draft Identity Representation for RSVP November 1998 1. For unicast sessions the user policy locator is the 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 the 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 policy server. 7. Message Processing Rules 7.1 Message Generation (RSVP Host) An RSVP message is created as specified in [RFC2205] with following modifications. 1. An authentication policy element, AUTH_DATA, is created and the IdentityType field is modified to indicate the authentication identity type being used. - A DN is inserted as POLICY_LOCATOR attribute. - Credentials such as Kerberos ticket or digital certificate are inserted as the CREDENTIAL attribute. 2. A POLICY_DATA object is inserted in the RSVP message in appropriate place with AUTH_DATA as one of the policy elements. If INTEGRITY object is not computed for the RSVP message then an INTEGRITY object MUST be computed for this POLICY_DATA object, as described in the [POL_EXT], and MUST be inserted as an option. 7.2 Message Reception (Router/Subnet Bandwidth Manager (SBM)) RSVP message is processed as specified in [RFC2205] with following modifications. 1. If router/SBM is not policy aware then it SHOULD send the RSVP message to the policy server and wait for response. 2. Reject the message if the response from the policy server is negative. Yadav, et al. 11 Internet Draft Identity Representation for RSVP November 1998 3. Continue processing the RSVP message. 7.3 Authentication (Router/SBM/Policy server) 1. Retrieve the AUTH_DATA policy element. 2. Check the IdentityType field and return an error if the identity type is not supported. 3. Verify credential - Simple authentication: e.g. Get user ID and validate it, or get executable name and validate it. - Kerberos: Send the Kerberos ticket to the KDC to obtain the session key. Using the session key authenticate the user. - Public Key: Validate the certificate that it was issued by a trusted Certificate Authority (CA) and authenticate the user or application by verifying the digital signature. 8. Security Considerations The purpose of this draft is to describe a mechanism to authenticate RSVP requests based on user identity in a secure manner. RSVP INTEGRITY object [MD5] is used to protect the policy object containing user identity information from security (replay) attacks. Combining the AUTH_DATA policy element and the INTEGRITY object results in a secure access control that enforces authentication based on both the identity of the user and the identity of the originating node. Simple authentication does not contain credential that can be securely authenticated and is inherently less secured. The Kerberos authentication mechanism is reasonably well secured. User authentication using a public key certificate is known to provide the strongest security. 9. Error Signaling If Policy server fails to verify the AUTH_DATA policy element then it must indicate to the first hop router the Error Code = 02 (Policy control failure). The policy server may specify error value field. These typically include: - Authentication method not supported Yadav, et al. 12 Internet Draft Identity Representation for RSVP November 1998 - Authentication failure - Required attribute (specify) missing. For example CREDENTIAL attribute missing. - Unknown attribute (specify) type. - Unknown attribute (specify) sub type. 10. Appendix A Internet-Draft “RSVP Cryptography Authentication” [MD5] describes a mechanism to authenticate RSVP messages based on the interface of a node on which the RSVP messages are sent. A single key is used to authenticate RSVP requests made by all users for an interface of the node. The security of such a setup has following limitations: - Authentication and RSVP admission control on the basis of node credentials alone is less secure as a node can impersonate all of its users even when they are not logged in. - It is not possible to identify the user making the RSVP request. Mechanism described in this draft can be used to solve the key distribution problem between hosts and routers for implementing [MD5]. We call this key the integrity key and if a network node is using authentication information, it may obtain this integrity key from a key distribution center by using the authentication information. A network node can verify the Integrity object of the RSVP message by using the authentication credentials to obtain the key from a key distribution center. The integrity key is used to compute the messages digest in the INTEGRITY object. The next hop router may either be a policy node; a policy server client or it may obtain the integrity key from a key distribution center using the authentication credentials from the first AUTH_DATA policy element. The key management APIs described in [MD5] needs to use the whole message to obtain the necessary information to obtain the key for integrity verification from a key distribution center. The key to generate integrity object for PATH and RESV tear should use the same key that was used to generate integrity objects for the PATH or RESV message. Using the identity policy elements to find the integrity key does not work for the last hop for multicast RSVP. This requires authenticated multicast joins to allow the control of who can send RSVP messages for a multicast group. The certificate authority can issue secret keys for use between the requestor and the verifier. This secret key is used for the integrity key. Yadav, et al. 13 Internet Draft Identity Representation for RSVP November 1998 If the policy server or another key server supplies an integrity key then check the integrity object. The router or host for later use (e.g., on refreshes) may cache this key. If a policy server obtains the integrity key on behalf of the router it can send the key using cops [COPS-RSVP]. 11. Acknowledgments We would like to thank Raj Yavatkar, Bob Linden and many others for their valuable comments on this draft. 12. References [ASCII] Coded Character Set -- 7-Bit American Standard Code for Information Interchange, ANSI X3.4-1986. [MD5] Baker, F., et.al. "RSVP Cryptographic Authentication." Internet-Draft, draft-ietf-rsvp-md5-07.txt, November 1998. [POL-EXT] Herzog, S., "RSVP Extensions for Policy Control." Internet-Draft, draft-ietf-rap-policy-ext-00.txt, April 1998 [RFC 1510] The Kerberos Network Authentication Service (V5). Kohl J., Neuman, C. RFC 1510. [RFC 1704] On Internet Authentication. Haller, N, Atkinson, R., RFC 1704. [RFC 1779] A String Representation of Distinguished Names. S. Kille. RFC 1779 [RFC 2205] Braden, R., et. al., "Resource ReSerVation Protocol (RSVP) – Version 1 Functional Specification." RFC 2205. [RFC 2209] Braden, R., Zhang, L., "Resource ReSerVation Protocol (RSVP) - Version 1 Message Processing Rules." RFC 2209. [UNICODE] The Unicode Consortium, "The Unicode Standard, Version 2.0", Addison-Wesley, Reading, MA, 1996. [X.509] ITU-T (formerly CCITT) Information technology – Open Systems Interconnection – The Directory: Authentication Framework Recommendation X.509 ISO/IEC 9594-8 Yadav, et al. 14 Internet Draft Identity Representation for RSVP November 1998 13. Author Information Satyendra Yadav Intel, JF3-206 2111 NE 25th Avenue Hillsboro, OR 97124 Satyendra.Yadav@intel.com Ramesh Pabbati Microsoft 1 Microsoft Way Redmond, WA 98054 rameshpa@microsoft.com Tim Moore Microsoft 1 Microsoft Way Redmond, WA 98054 timmoore@microsoft.com Shai Herzog IPHighway 2055 Gateway Pl., Suite 400 San Jose, CA 95110 herzog@iphighway.com Yadav, et al. 15