rfc3182.txt

RFC 的详细文档！

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]