From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3182.txt | 1011 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1011 insertions(+) create mode 100644 doc/rfc/rfc3182.txt (limited to 'doc/rfc/rfc3182.txt') diff --git a/doc/rfc/rfc3182.txt b/doc/rfc/rfc3182.txt new file mode 100644 index 0000000..78c7d20 --- /dev/null +++ b/doc/rfc/rfc3182.txt @@ -0,0 +1,1011 @@ + + + + + + +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. + +Abstract + + This 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. + + + + + +Yadav, et al. Standards Track [Page 1] + +RFC 3182 Identity Representation for RSVP October 2001 + + +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 [RFC 2119]. + +2. 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 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]. + + + + + + + + + +Yadav, et al. Standards Track [Page 2] + +RFC 3182 Identity Representation for RSVP October 2001 + + +3. Policy Element for Authentication Data + +3.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]. + +3.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. + + +-------------+-------------+-------------+-------------+ + | Length | P-Type = Identity Type | + +-------------+-------------+-------------+-------------+ + // Authentication Attribute List // + +-------------------------------------------------------+ + + Length + The length of the policy element (including the Length and P-Type) + is in number of octets (MUST be a multiple of 4) and indicates the + end of the authentication attribute list. + + P-Type (Identity Type) + Type of identity information contained in this Policy Element + supplied as the Policy element type (P-type). The Internet + Assigned Numbers Authority (IANA) acts as a registry for policy + element types for identity as described in the [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. + + + + + + +Yadav, et al. Standards Track [Page 3] + +RFC 3182 Identity Representation for RSVP October 2001 + + +3.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 to the + value field to make the attribute multiple of 4 octets long. + + A-Type + Authentication attribute type (A-Type) field is one octet. IANA + acts as a registry for A-Types as described in the 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. + + + + + + +Yadav, et al. Standards Track [Page 4] + +RFC 3182 Identity Representation for RSVP October 2001 + + +3.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 User or + application hence a DN is used as policy locator. + + +-------+-------+-------+-------+ + | Length |A-Type |SubType| + +-------+-------+-------+-------+ + | OctetString ... + +-------+-------+-------+-------- + + Length + Length of the attribute, which MUST be >= 4. + + A-Type + POLICY_LOCATOR + + SubType + Following sub types for POLICY_LOCATOR are defined. IANA acts as + a registry for POLICY_LOCATOR sub types as described in the + 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. + + + + +Yadav, et al. Standards Track [Page 5] + +RFC 3182 Identity Representation for RSVP October 2001 + + +3.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. + + A summary of the CREDENTIAL attribute format is shown below. The + fields are transmitted from left to right. + + +-------+-------+-------+-------+ + | Length |A-Type |SubType| + +-------+-------+-------+-------+ + | OctetString ... + +-------+-------+-------+-------- + + Length + Length of the attribute, which MUST be >= 4. + + A-Type + CREDENTIAL + + SubType + IANA acts as a registry for CREDENTIAL sub types as described in + the 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. + + + + + + + + + +Yadav, et al. Standards Track [Page 6] + +RFC 3182 Identity Representation for RSVP October 2001 + + +3.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 ... + +-------+-------+-------+-------- + + Length + Length of the attribute, which MUST be >= 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. + +3.3.4 Policy Error Object + + This attribute is used to carry any specific policy control errors + generated by a node when processing/validating an Authentication Data + Policy Element. When a RSVP policy node (local policy decision point + or remote PDP) encounters a request that fails policy control due to + its Authentication Policy Element, it SHOULD add a POLICY_ERROR_CODE + containing additional information about the reason the failure + occurred into the policy element. This will then cause an + appropriate PATH_ERROR or RESV_ERROR message to be generated with the + policy element and appropriate RSVP error code in the message, which + is returned to the request's source. + + The AUTH_DATA policy element in the PATH or RSVP message SHOULD not + contain the POLICY_ERROR_OBJECT attribute. These are only inserted + into PATH_ERROR and RESV_ERROR messages when generated by policy + aware intermediate nodes. + + + + +Yadav, et al. Standards Track [Page 7] + +RFC 3182 Identity Representation for RSVP October 2001 + + + +----------+----------+----------+----------+ + | 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. + +4. Authentication Data Formats + + Authentication attributes are grouped in a policy element to + represent the identity credentials. + + + + + + +Yadav, et al. Standards Track [Page 8] + +RFC 3182 Identity Representation for RSVP October 2001 + + +4.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_USER | + +--------------+--------------+--------------+--------------+ + | Length |POLICY_LOCATOR| SubType | + +--------------+--------------+--------------+--------------+ + | OctetString (User's Distinguished Name) ... + +--------------+--------------+--------------+--------------+ + | Length |CREDENTIAL | ASCII_ID | + +--------------+--------------+--------------+--------------+ + | OctetString (User's login ID) ... + +--------------+--------------+--------------+--------------+ + +4.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 + 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) ... + +--------------+--------------+--------------+--------------+ + +4.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 PDP. A router when + generating a RSVP message contacts the KDC to obtain a Kerberos + + + +Yadav, et al. Standards Track [Page 9] + +RFC 3182 Identity Representation for RSVP October 2001 + + + 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. + +4.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_USER | + +--------------+--------------+--------------+--------------+ + | Length |POLICY_LOCATOR| SubType | + +--------------+--------------+--------------+--------------+ + | OctetString (User's Distinguished Name) ... + +--------------+--------------+--------------+--------------+ + | Length | CREDENTIAL | SubType | + +--------------+--------------+--------------+--------------+ + | OctetString (User's Digital Certificate) ... + +--------------+--------------+--------------+--------------+ + | Length |DIGITAL_SIGN. | 0 | + +--------------+--------------+--------------+--------------+ + | OctetString (Digital signature) ... + +--------------+--------------+--------------+--------------+ + +4.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 (PDP or router) has the ability to verify the + digital certificate. + + + + + + +Yadav, et al. Standards Track [Page 10] + +RFC 3182 Identity Representation for RSVP October 2001 + + + 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. + +4.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_APP | + +----------------+--------------+--------------+--------------+ + | Length |POLICY_LOCATOR| SubType | + +----------------+--------------+--------------+--------------+ + | OctetString (Application Identity attributes in + | the form of a Distinguished Name) ... + +----------------+--------------+--------------+--------------+ + | Length | CREDENTIAL | ASCII_ID | + +----------------+--------------+--------------+--------------+ + | OctetString (Application Id, e.g., vic.exe) + +----------------+--------------+--------------+--------------+ + +5. Operation + + +-----+ +-----+ + | 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. + + + + +Yadav, et al. Standards Track [Page 11] + +RFC 3182 Identity Representation for RSVP October 2001 + + + 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. + +6. Message Processing Rules + +6.1 Message Generation (RSVP Host) + + An RSVP message is created as specified in [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. + + + + + + + +Yadav, et al. Standards Track [Page 12] + +RFC 3182 Identity Representation for RSVP October 2001 + + +6.2 Message Reception (Router) + + RSVP message is processed as specified in [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. + +6.3 Authentication (Router/PDP) + + 1. Retrieve the AUTH_DATA policy element. Check the PE type field + and return an error if the identity type is not supported. + + 2. Verify user 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. + +7. Error Signaling + + If PDP fails to verify the AUTH_DATA policy element then it MUST + return policy control failure (Error Code = 02) to the PEP. The + error values are described in [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. + +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 [POL-EXT]. + + + + + +Yadav, et al. Standards Track [Page 13] + +RFC 3182 Identity Representation for RSVP October 2001 + + + 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. + + + + + + + + +Yadav, et al. Standards Track [Page 14] + +RFC 3182 Identity Representation for RSVP October 2001 + + +9. Security Considerations + + The purpose of this memo is to describe a mechanism to authenticate + RSVP requests based on user identity in a secure manner. RSVP + INTEGRITY object 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. + +10. Acknowledgments + + We would like to thank Andrew Smith, Bob Lindell and many others for + their valuable comments on this memo. + +11. References + + [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. + + + + + +Yadav, et al. Standards Track [Page 15] + +RFC 3182 Identity Representation for RSVP October 2001 + + + [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 + +12. Authors' Addresses + + Satyendra Yadav + Intel, JF3-206 + 2111 NE 25th Avenue + Hillsboro, OR 97124 + + EMail: Satyendra.Yadav@intel.com + + + + + + + + + + +Yadav, et al. Standards Track [Page 16] + +RFC 3182 Identity Representation for RSVP October 2001 + + + 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: rameshpa@microsoft.com + + + Peter Ford + Microsoft + 1 Microsoft Way + Redmond, WA 98054 + + EMail: peterf@microsoft.com + + + Tim Moore + Microsoft + 1 Microsoft Way + Redmond, WA 98054 + + EMail: timmoore@microsoft.com + + + Shai Herzog + PolicyConsulting.Com + 200 Clove Rd. + New Rochelle, NY 10801 + + EMail: herzog@policyconsulting.com + + + Rodney Hess + Intel, BD1 + 28 Crosby Drive + Bedford, MA 01730 + + EMail: rodney.hess@intel.com + + + + + +Yadav, et al. Standards Track [Page 17] + +RFC 3182 Identity Representation for RSVP October 2001 + + +13. Full Copyright Statement + + Copyright (C) The Internet Society (2001). 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. + + + + + + + + + + + + + + + + + + + +Yadav, et al. Standards Track [Page 18] + -- cgit v1.2.3