rfc2752.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 956 行 · 第 1/3 页

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.








Yadav, et al.               Standards Track                     [Page 6]

RFC 2752            Identity Representation for RSVP        January 2000


   +-------+-------+-------+-------+
   | Length        |A-Type |SubType|
   +-------+-------+-------+-------+
   | OctetString ...
   +-------+-------+-------+--------

   Length
       Length of the attribute, which MUST be >= 4.

       ti3 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.

   +----------+----------+----------+----------+
   | Length              | A-Type   |SubType(0)|
   +----------+----------+----------+----------+
   | 0 (Reserved)        | ErrorValue          |
   +----------+----------+----------+----------+
   | OctetString ...
   +----------+----------+----------+----------+

   Length
       Length of the attribute, which MUST be >= 8.




Yadav, et al.               Standards Track                     [Page 7]

RFC 2752            Identity Representation for RSVP        January 2000


   A-Type
       POLICY_ERROR_CODE

   ErrorValue
       A 32-bit bit code containing the reason that the policy decision
       point failed to process the policy element. 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.

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) ...
   +--------------+--------------+--------------+--------------+




Yadav, et al.               Standards Track                     [Page 8]

RFC 2752            Identity Representation for RSVP        January 2000


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
   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.








Yadav, et al.               Standards Track                     [Page 9]

RFC 2752            Identity Representation for RSVP        January 2000


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

   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.









Yadav, et al.               Standards Track                    [Page 10]

RFC 2752            Identity Representation for RSVP        January 2000


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

   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.




Yadav, et al.               Standards Track                    [Page 11]

RFC 2752            Identity Representation for RSVP        January 2000


   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 [RFC2205] with following
   modifications.