Internet Draft                                       Satyendra Yadav
File: <draft-ietf-rap-rsvp-identity-00.txt>                   Intel
                                                     Ramesh Pabbati
                                                              Microsoft
                                                     Tim Moore
                                                              Microsoft
                                                     Shai Herzog
                                                              IPHighway

                      Identity Representation for RSVP
                              November 1998

Status of this Memo

   This document is an Internet Draft.  Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its Areas,
   and its Working Groups.  Note that other groups may also distribute
   working documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months.  Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a
   "working draft" or "work in progress".

   To view the entire list of current Internet-Drafts, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
   Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
   Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).

   A Revised Version of this draft document will be submitted to the
   RFC editor as a Proposed Standard for the Internet Community.
   Discussion and suggestions for improvement are requested. This
   document will expire in May 1999. Distribution of this draft is
   unlimited.


1. Abstract

   This document describes the representation of identity information
   in POLICY_DATA object [POL-EXT] for supporting policy based
   admission control in RSVP. The goal of identity representation is to
   allow a process on a system to securely identify the owner of the
   communicating process (e.g. user id) and convey this information in
   RSVP messages (PATH or RESV) in a secure manner. We describe the
   encoding of  identities as RSVP policy element. We describe the
   processing rules to generate identity policy elements for multicast
   merged flows. Subsequently, we describe representations of user
   identities for Kerberos and Public Key based user authentication
   mechanisms. In summary we describe the use of this identity
   information in an operational setting.



Yadav, et al.                                                        1

Internet Draft      Identity Representation for RSVP      November 1998



2. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in [RFC-2119].


3. Introduction

   RSVP [RFC 2205] is a resource reservation setup protocol designed
   for an integrated services Internet [RFC 1633]. RSVP is used by a
   host to request specific quality of service (QoS) from the network
   for particular application data streams or flows. RSVP is also used
   by routers to deliver QoS requests to all nodes along the path(s) of
   the flows and to establish and maintain state to provide the
   requested service. RSVP requests will generally result in resources
   being reserved in each node along the data path. RSVP allows
   particular users to obtain preferential access to network resources,
   under the control of an admission control mechanism. Permission to
   make a reservation is based both upon the availability of the
   requested resources along the path of the data and upon satisfaction
   of policy rules. Providing policy based admission control mechanism
   based on user identity is one of the prime requirements.

   In order to solve these problems and implement user based policy
   control it is required to identify the user making an RSVP request.
   This document proposes a mechanism for sending identification
   information in the RSVP requests and enables authorization decisions
   based on policy and identity of the user requesting resources from
   the network.

   We describe the authentication policy element (AUTH_DATA) contained
   in the POLICY_DATA object. User process generates an AUTH_DATA
   policy element and gives it to RSVP process (service) on the
   originating host. RSVP process inserts AUTH_DATA into the RSVP
   message to identify the owner (user) making the request for network
   resources. Network elements, such as routers, authenticate user
   using the credentials presented in the AUTH_DATA and admit the RSVP
   message based on admission policy. After a request has been
   authenticated, first hop router installs the RSVP state and forwards
   the new policy element returned by the policy server.












Yadav, et al.                                                        2

Internet Draft      Identity Representation for RSVP      November 1998


4. Policy Element for Authentication Data

4.1 Policy Data Object Format

   POLICY_DATA objects contain policy information and are carried by
   RSVP messages. A detail description of the format of POLICY_DATA
   object can be found in “RSVP Extensions for Policy Control” [POL-
   EXT].


4.2 Authentication Data Policy Element

   In this section, we describe a policy element (PE) called
   authentication data (AUTH_DATA). AUTH_DATA policy element contains a
   list of authentication attributes. Policy object containing
   AUTH_DATA MUST be protected against replay attacks using INTEGRITY
   object option as described in the [POL-EXT].

       +-------------+-------------+-------------+-------------+
       | Length                    | P-Type = AUTH_DATA        |
       +-------------+-------------+-------------+-------------+
       | IdentityType              | 0 (Reserved)              |
       +-------------+-------------+-------------+-------------+
       // Authentication Attribute List                       //
       |                                                       |
       +-------------------------------------------------------+

   Length
       The length of the policy element (including the Length and P-
       Type) is in number of octets and indicates the end of the
       authentication attribute list.

   AUTH_DATA
       Policy element type (P-type) for the authentication data as
       registered with Internet Assigned Numbers Authority (IANA).


   IdentityType
   This field describes the authentication method being used.
   Following types are currently defined.

        1   AUTH_USER       authentication scheme to identify users

        2   AUTH_APP        authentication scheme to identify
                            applications

   Reserved
       Must be set to 0.






Yadav, et al.                                                        3

Internet Draft      Identity Representation for RSVP      November 1998


   Authentication Attribute List

       Authentication attributes contain information specific to
       authentication methods.  The policy element provides the
       mechanism for grouping a collection of authentication
       attributes.


4.3 Authentication Attributes

   Authentication attributes must be encoded as a multiple of 4 octets,
   attributes that are not a multiple of 4 octets long must be padded
   to a 4-octet boundary.

   +--------+--------+--------+--------+
   | Length          | A-Type |SubType |
   +--------+--------+--------+--------+
   | Value …
   +--------+--------+--------+--------+

   Length
       The length field is two octets and indicates the actual length
       of the attribute (including the Length and A-Type fields) in
       number of octets. The length does not include any bytes padding
       the attribute to make it multiple of 4 octets long.

   A-Type
       Authentication attribute type (A-Type) field is one octet. The
       following values are defined:

           1  POLICY_LOCATOR     Unique string for locating the
                                 admission policy (such as X.500 DN
                                 described in [RFC 1779]).

           2  CREDENTIAL_       User credential such as Kerberos
                                 ticket, or digital certificate.
                                 Application credential such as
                                 application ID.

           3  DIGITAL_SIGNATURE  Digital signature of the
                                 authentication data policy element.

   SubType
       Authentication attribute sub-type field is one octet. Value of
       SubType depends on A-type.

   Value:
       The value field contains 0-65351 octets.






Yadav, et al.                                                        4

Internet Draft      Identity Representation for RSVP      November 1998


4.3.1 Policy Locator

   POLICY_LOCATOR is used to locate the admission policy for the user
   or application. Distinguished Name (DN) is unique for each policy
   hence a DN is used as policy locator.

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

   Length
       > 4

   A-Type
       POLICY_LOCATOR

   SubType
       Following sub types for POLICY_LOCATOR are defined.

       1  X500_DN       OctetString contains the X.500 DN as described
                        in the RFC 1779 as an ASCII string.

       2  UNICODE DN   OctetString contains the X.500 DN described in
                        the RFC 1779 as an UNICODE string.

       3  X500_DN ENCRYPT  OctetString contains the encrypted X.500 DN.
                        The Kerberos session key or digital certificate
                        private key is used for encryption. For
                        Kerberos encryption the format is the same as
                        returned from gss_seal [RFC 1509].

       4  X500_UNICODE_DN ENCRYPT  OctetString contains the encrypted
                        UNICODE X.500 DN. The Kerberos session key or
                        digital certificate private key is used for
                        encryption. For Kerberos encryption the format
                        is the same as returned from gss_seal [RFC
                        1509].

   OctetString
      The OctetString field contains the DN.


4.3.2 Credential

   CREDENTIAL indicates the credential of the user or application to be
   authenticated. For Kerberos authentication method the CREDENTIAL
   object contains the Kerberos session ticket. For public key based
   authentication this field contains a digital certificate.




Yadav, et al.                                                        5

Internet Draft      Identity Representation for RSVP      November 1998


   A summary of the CREDENTIAL attribute format is shown below. The
   fields are transmitted from left to right.

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

   Length
       >  4

   A-Type
       _CREDENTIAL

   SubType
       Following sub types for CREDENTIAL are defined.

       1  ASCII_ID      OctetString contains user or application
                         identification in plain ASCII text.

       2  UNICODE_ID    OctetString contains user or application
                         identification in plain UNICODE text.

       3  KERBEROS_TKT  OctetString contains Kerberos ticket.

       4  X509_V3_CERT  OctetString contains X.509v3 digital
                         certificate [X.509].

       5  PGP_CERT      OctetString contains PGP digital certificate.

   OctetString
       The OctetString contains the user or application credential.


4.3.3 Digital Signature

   The DIGITAL_SIGNATURE attribute must be the last attribute in the
   attribute list and contains the digital signature of the AUTH_DATA
   policy element.  The digital signature signs all data in the
   AUTH_DATA policy element up to the DIGITAL_SIGNATURE. The algorithm
   used to compute the digital signature depends on the authentication
   method specified by the CREDENTIAL SubType field.

   A summary of DIGITAL_SIGNATURE attribute format is described below.

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



Yadav, et al.                                                        6

Internet Draft      Identity Representation for RSVP      November 1998


   Length
       > 4

   A-Type
       DIGITAL_SIGNATURE

   SubType
       No sub types for DIGITAL_SIGNATURE are currently defined. This
       field must be set to 0.

   OctetString
       OctetString contains the digital signature of the AUTH_DATA.


5. Authentication Data Formats

   Authentication attributes are grouped in a policy element to
   represent the identity credentials.


5.1 Simple User Authentication

   In simple user authentication method the user login ID (in plain
   ASCII or UNICODE text) is encoded as CREDENTIAL attribute. A summary
   of the simple user AUTH_DATA policy element is shown below.

   +--------------+--------------+--------------+--------------+
   | Length                      | P-type = AUTH_DATA          |
   +--------------+--------------+--------------+--------------+
   | IdentityType = AUTH_USER    | 0                           |
   +--------------+--------------+--------------+--------------+
   | Length                      |POLICY_LOCATOR| SubType      |
   +--------------+--------------+--------------+--------------+
   | OctetString (User’s Distinguished Name) …
   +--------------+--------------+--------------+--------------+
   | Length                      |CREDENTIAL    | SubType      |
   +--------------+--------------+--------------+--------------+
   | OctetString (User’s login ID) …
   +--------------+--------------+--------------+--------------+


5.2 Kerberos User Authentication

   Kerberos [RFC 1510] authentication uses a trusted third party (the
   Kerberos Distribution Center – KDC) to provide for authentication of
   the user to a network server. It is assumed that a KDC is present
   and both host and verifier of authentication information (router or
   policy server) implement Kerberos authentication.






Yadav, et al.                                                        7

Internet Draft      Identity Representation for RSVP      November 1998


   A summary of the Kerberos AUTH_DATA policy element is shown below.

   +--------------+--------------+--------------+--------------+
   | Length                      | P-type  (AUTH_DATA)         |
   +--------------+--------------+--------------+--------------+
   | IdentityType = AUTH_USER    |
   +--------------+--------------+--------------+--------------+
   | Length                      |POLICY_LOCATOR|   SubType    |
   +--------------+--------------+--------------+--------------+
   | OctetString (User’s Distinguished Name) …
   +--------------+--------------+--------------+--------------+
   | Length                      | CREDENTIAL   | KERBEROS_TKT |
   +--------------+--------------+--------------+--------------+
   | OctetString (Kerberos Session Ticket) …
   +--------------+--------------+--------------+--------------+


5.2.1. Operational Setting using Kerberos Identities

   An RSVP enabled host is configured to construct and insert AUTH_DATA
   policy element into RSVP messages that designate use of the Kerberos
   authentication method (KERBEROS_TKT). Upon RSVP session
   initialization, the user application contacts the KDC to obtain a
   Kerberos ticket for the next network node or its policy server. A
   router when generating a RSVP message contacts the KDC to obtain a
   Kerberos ticket for the next hop network node or its policy server.
   The identity of the policy server or next network hop can be
   statically configured, learned via DHCP or maintained in a directory
   service. The Kerberos ticket is sent to the next network node (which
   may be a router or host) in a RSVP message. The router may be a
   policy node or may use a policy server. The KDC is used to validate
   the ticket and authentication the user sending RSVP message.






















Yadav, et al.                                                        8

Internet Draft      Identity Representation for RSVP      November 1998


5.3 Public Key based User Authentication

   In public key based user authentication method digital certificate
   is encoded as user credentials. The digital signature is used for
   authenticating the user. A summary of the public key user AUTH_DATA
   policy element is shown below.

   +--------------+--------------+--------------+--------------+
   | Length                      | P-type  (AUTH_DATA)         |
   +--------------+--------------+--------------+--------------+
   | IdentityType = AUTH_USER    | 0                           |
   +--------------+--------------+--------------+--------------+
   | Length                      |POLICY_LOCATOR|   SubType    |
   +--------------+--------------+--------------+--------------+
   | OctetString (User’s Distinguished Name) …
   +--------------+--------------+--------------+--------------+
   | Length                      | _CREDENTIAL  |   SubType    |
   +--------------+--------------+--------------+--------------+
   | OctetString (User’s Digital Certificate)…
   +--------------+--------------+--------------+--------------+
   | Length                      |DIGITAL_SIGN. | 0            |
   +--------------+--------------+--------------+--------------+
   | OctetString (Digital signature) …
   +--------------+--------------+--------------+--------------+


5.3.1. Operational Setting for public key based authentication

   Public key based authentication assumes following:

        -  RSVP service requestors have a pair of keys (private key and
          public key).

        - Private key is secured with the user.

        - Public keys are stored in digital certificates and a trusted
          party, certificate authority (CA) issues these digital
          certificates.

        - The verifier (policy server or router) has the ability to
          verify the digital certificate.

   RSVP requestor uses its private key to generate DIGITAL_SIGNATURE.
   User Authenticators (router, policy server) use the user’s public
   key (stored in the digital certificate) to verify the signature and
   authenticate the user.








Yadav, et al.                                                        9

Internet Draft      Identity Representation for RSVP      November 1998


5.4 Simple Application Authentication

   The application authentication method encodes the application
   identification such as an executable filename as plain ASCII or
   UNICODE text.

   +--------------+--------------+--------------+------------------+
   | Length                      | P-type = AUTH_DATA              |
   +--------------+--------------+--------------+------------------+
   | IdentityType = AUTH_APP     | 0                               |
   +--------------+--------------+--------------+------------------+
   | Length                      |POLICY_LOCATOR| SubType          |
   +--------------+--------------+--------------+------------------+
   | OctetString (Application Distinguished Name) …
   +--------------+--------------+--------------+------------------+
   | Length                      | CREDENTIAL   | SubType
   +--------------+--------------+--------------+------------------+
   | OctetString (Application Identification)
   +--------------+--------------+--------------+------------------+


6. Operation

   +------+                                                 +------+
   |Policy|------+                                          |Policy|
   |Server|      |                                          |Server|
   +------+      |              ………………………………….…….           +------+
                 |             :                 :          |
                 |             :                 :          |
               +---------+     :                 :        +-------+
          +----|First hop|    Transit        Transit -----|Transit|
          |    | Router  |----Router          Router      | Router|--+
          |    +---------+     :                 :        +-------+  |
          |        |           :……………………………………...:             |     |
          |        |                                           |     |
     Host A        B                                           C     D

   Figure 1: User and Application Authentication using AUTH_DATA object

   Hosts and network nodes generate AUTH DATA policy elements, contents
   of which are depends on the identity type used and the
   authentication method used. But generally contains authentication
   credentials (Kerberos ticket or digital certificate) and policy
   locators (which can be the X.500 Distinguished Name of the user or
   network node or application names). Host systems generate AUTH_DATA
   policy element containing the authentication identity when making
   the RSVP request.

   Network nodes generate user AUTH_DATA policy element using the
   following rules




Yadav, et al.                                                       10

Internet Draft      Identity Representation for RSVP      November 1998


   1. For unicast sessions the user policy locator is the copied from
      the previous hop. The authentication credentials are for the
      current network node identity.

   2. For multicast messages the user policy locator is for the current
      network node identity. The authentication credentials are for the
      current network node.

   Network nodes generate application AUTH_DATA policy element using
   the following rules:

   1.
     For unicast sessions the application AUTH_DATA is the copied from
     the previous hop.

   2.
     For multicast messages the application AUTH_DATA is either the
     first application AUTH_DATA in the message or chosen by the policy
     server.


7. Message Processing Rules

7.1 Message Generation (RSVP Host)

   An RSVP message is created as specified in [RFC2205] with following
   modifications.

   1. An authentication policy element, AUTH_DATA, is created and the
      IdentityType field is modified to indicate the authentication
      identity type being used.

        - A DN is inserted as POLICY_LOCATOR attribute.

        - Credentials such as Kerberos ticket or digital certificate
          are inserted as the CREDENTIAL attribute.

   2. A POLICY_DATA object is inserted in the RSVP message in
      appropriate place with AUTH_DATA as one of the policy elements.
      If INTEGRITY object is not computed for the RSVP message then an
      INTEGRITY object MUST be computed for this POLICY_DATA object, as
      described in the [POL_EXT], and MUST be inserted as an option.


7.2 Message Reception (Router/Subnet Bandwidth Manager (SBM))

   RSVP message is processed as specified in [RFC2205] with following
   modifications.

   1. If router/SBM is not policy aware then it SHOULD send the RSVP
      message to the policy server and wait for response.

   2. Reject the message if the response from the policy server is
      negative.


Yadav, et al.                                                       11

Internet Draft      Identity Representation for RSVP      November 1998



   3. Continue processing the RSVP message.


7.3 Authentication (Router/SBM/Policy server)

    1. Retrieve the AUTH_DATA policy element.

    2. Check the IdentityType field and return an error if the identity
       type is not supported.

    3. Verify credential

        - Simple authentication: e.g. Get user ID and validate it, or
          get executable name and validate it.

        - Kerberos: Send the Kerberos ticket to the KDC to obtain the
          session key. Using the session key authenticate the user.

        - Public Key: Validate the certificate that it was issued by a
          trusted Certificate Authority (CA) and authenticate the user
          or application by verifying the digital signature.


8. Security Considerations

   The purpose of this draft is to describe a mechanism to authenticate
   RSVP requests based on user identity in a secure manner. RSVP
   INTEGRITY object [MD5] is used to protect the policy object
   containing user identity information from security (replay) attacks.
   Combining the AUTH_DATA policy element and the INTEGRITY object
   results in a secure access control that enforces authentication
   based on both the identity of the user and the identity of the
   originating node.

   Simple authentication does not contain credential that can be
   securely authenticated and is inherently less secured.

   The Kerberos authentication mechanism is reasonably well secured.

   User authentication using a public key certificate is known to
   provide the strongest security.


9. Error Signaling

   If Policy server fails to verify the AUTH_DATA policy element then
   it must indicate to the first hop router the Error Code = 02 (Policy
   control failure). The policy server may specify error value field.
   These typically include:

        - Authentication method not supported


Yadav, et al.                                                       12

Internet Draft      Identity Representation for RSVP      November 1998



        - Authentication failure

        - Required attribute (specify) missing. For example CREDENTIAL
          attribute missing.

        - Unknown attribute (specify) type.

        - Unknown attribute (specify) sub type.


10. Appendix A

   Internet-Draft “RSVP Cryptography Authentication” [MD5] describes a
   mechanism to authenticate RSVP messages based on the interface of a
   node on which the RSVP messages are sent. A single key is used to
   authenticate RSVP requests made by all users for an interface of the
   node. The security of such a setup has following limitations:

        - Authentication and RSVP admission control on the basis of
          node credentials alone is less secure as a node can
          impersonate all of its users even when they are not logged
          in.

        - It is not possible to identify the user making the RSVP
          request.

   Mechanism described in this draft can be used to solve the key
   distribution problem between hosts and routers for implementing
   [MD5]. We call this key the integrity key and if a network node is
   using authentication information, it may obtain this integrity key
   from a key distribution center by using the authentication
   information. A network node can verify the Integrity object of the
   RSVP message by using the authentication credentials to obtain the
   key from a key distribution center. The integrity key is used to
   compute the messages digest in the INTEGRITY object. The next hop
   router may either be a policy node; a policy server client or it may
   obtain the integrity key from a key distribution center using the
   authentication credentials from the first AUTH_DATA policy element.
   The key management APIs described in [MD5] needs to use the whole
   message to obtain the necessary information to obtain the key for
   integrity verification from a key distribution center.
   The key to generate integrity object for PATH and RESV tear should
   use the same key that was used to generate integrity objects for the
   PATH or RESV message.

   Using the identity policy elements to find the integrity key does
   not work for the last hop for multicast RSVP. This requires
   authenticated multicast joins to allow the control of who can send
   RSVP messages for a multicast group. The certificate authority can
   issue secret keys for use between the requestor and the verifier.
   This secret key is used for the integrity key.


Yadav, et al.                                                       13

Internet Draft      Identity Representation for RSVP      November 1998



   If the policy server or another key server supplies an integrity key
   then check the integrity object. The router or host for later use
   (e.g., on refreshes) may cache this key. If a policy server obtains
   the integrity key on behalf of the router it can send the key using
   cops [COPS-RSVP].


11. Acknowledgments

   We would like to thank Raj Yavatkar, Bob Linden and many others for
   their valuable comments on this draft.


12. References

   [ASCII]     Coded Character Set -- 7-Bit American Standard Code for
               Information Interchange, ANSI X3.4-1986.

   [MD5]       Baker, F., et.al. "RSVP Cryptographic Authentication."
               Internet-Draft, draft-ietf-rsvp-md5-07.txt, November
               1998.

   [POL-EXT]   Herzog, S., "RSVP Extensions for Policy Control."
               Internet-Draft, draft-ietf-rap-policy-ext-00.txt, April
               1998

   [RFC 1510]  The Kerberos Network Authentication Service (V5). Kohl
               J., Neuman, C. RFC 1510.

   [RFC 1704]  On Internet Authentication. Haller, N, Atkinson, R.,
               RFC 1704.

   [RFC 1779]  A String Representation of Distinguished Names. S.
               Kille. RFC 1779

   [RFC 2205]  Braden, R., et. al., "Resource ReSerVation Protocol
               (RSVP) – Version 1 Functional Specification."  RFC 2205.

   [RFC 2209]  Braden, R., Zhang, L., "Resource ReSerVation Protocol
               (RSVP) - Version 1 Message Processing Rules."  RFC 2209.

   [UNICODE]   The Unicode Consortium, "The Unicode Standard, Version
               2.0", Addison-Wesley, Reading, MA, 1996.

   [X.509]     ITU-T (formerly CCITT) Information technology – Open
               Systems Interconnection –  The Directory: Authentication
               Framework Recommendation X.509 ISO/IEC 9594-8






Yadav, et al.                                                       14

Internet Draft      Identity Representation for RSVP      November 1998


13. Author Information

   Satyendra Yadav
   Intel, JF3-206
   2111 NE 25th Avenue
   Hillsboro, OR 97124
   Satyendra.Yadav@intel.com

   Ramesh Pabbati
   Microsoft
   1 Microsoft Way
   Redmond, WA 98054
   rameshpa@microsoft.com

   Tim Moore
   Microsoft
   1 Microsoft Way
   Redmond, WA 98054
   timmoore@microsoft.com

   Shai Herzog
   IPHighway
   2055 Gateway Pl., Suite 400
   San Jose, CA 95110
   herzog@iphighway.com





























Yadav, et al.                                                       15