doc: Add RFC documents

1 files changed, 1011 insertions, 0 deletions

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]
+