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

                      Identity Representation for RSVP
                              November 1998
                              January 1999

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 Internet-Draft 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). Directories, see
   http://www.ietf.org/shadow.html.

   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 July 1999. Distribution of this draft is
   unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999). All Rights Reserved.

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

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. Policy Decision Point (PDP)
   [POL-FRAME].

Yadav, et al.                                                        2

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 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 (must be a multiple of 4) 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 identity type used for authentication.
       The Internet Assigned Numbers Authority (IANA) acts as a
       registry for identity types are currently defined. as described in the section 10, IANA
       Considerations. Initially, the registry contains the following
       identity types:

        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
   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 IANA
       acts as a registry for A-Types as described in the section 10,
       IANA Considerations. Initially, the registry contains the
       following values are defined: A-Types:

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

           2  CREDENTIAL_  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

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 User or
   application 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. defined.IANA acts as
       a registry for POLICY_LOCATOR sub types as described in the
       section 10, IANA Considerations. Initially, the registry
       contains the following sub types for POLICY_LOCATOR:

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

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

       3  X500_DN ENCRYPT  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  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.

Yadav, et al.                                                        5

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

   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
       CREDENTIAL

   SubType
       Following
       IANA acts as a registry for CREDENTIAL sub types as described in
       the section 10, IANA Considerations. Initially, the registry
       contains the following sub types for CREDENTIAL are defined. CREDENTIAL:

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

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

       3  KERBEROS_TKT  OctetString contains Kerberos ticket.

       4  X509_V3_CERT  OctetString contains X.509v3 X.509 V3 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.

Yadav, et al.                                                        6
   A summary of DIGITAL_SIGNATURE attribute format is described below.

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

Yadav, et al.                                                        6

   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 ASCII_ID     |
   +--------------+--------------+--------------+--------------+
   | OctetString (User’s login ID) …
   +--------------+--------------+--------------+--------------+

Yadav, et al.                                                        7

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)
   PDP) implement Kerberos authentication.

Yadav, et al.                                                        7

   A summary of the Kerberos 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   | 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. PDP. 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. PDP. The identity of the policy server
   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 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

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.

Yadav, et al.                                                        8
   +--------------+--------------+--------------+--------------+
   | Length                      | P-type  (AUTH_DATA)         |
   +--------------+--------------+--------------+--------------+
   | IdentityType = AUTH_USER    | 0                           |
   +--------------+--------------+--------------+--------------+
   | Length                      |POLICY_LOCATOR|   SubType    |
   +--------------+--------------+--------------+--------------+
   | OctetString (User’s Distinguished Name) …
   +--------------+--------------+--------------+--------------+
   | Length                      | _CREDENTIAL 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 (PDP 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) PDP) use the user’s public key (stored
   in the digital certificate) to verify the signature and authenticate
   the user.

Yadav, et al.                                                        9

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
   +--------------+--------------+--------------+------------------+ ASCII_ID     |
   +----------------+--------------+--------------+--------------+
   | OctetString (Application Identification)
   +--------------+--------------+--------------+------------------+
   +----------------+--------------+--------------+--------------+

6. Operation

   +------+                                                 +------+
   |Policy|------+                                          |Policy|
   |Server|

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

     Figure 1: User and Application Authentication using AUTH_DATA object

   Hosts and network PE

   Network nodes (hosts/routers) generate AUTH DATA 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 Network nodes generate AUTH_DATA
   policy element containing the authentication identity when making
   the RSVP request. request or forwarding an RSVP message.

   Network nodes generate user AUTH_DATA policy element using the
   following rules

Yadav, et al.                                                       10

   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.

Yadav, et al.                                                       10
   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. PDP.

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 RSVP message may contain multiple AUTH_DATA policy elements. Only
      one AUTH_DATA of each IdentityType is allowed.

   2. Authentication policy element, AUTH_DATA, 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

   3. 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 must be computed for this POLICY_DATA object, as described
      in the [POL_EXT], and MUST must be inserted as an option.

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

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

   1. If router/SBM router is not policy aware then it SHOULD should send the RSVP
      message to the policy server 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 policy server PDP is negative.

Yadav, et al.                                                       11
   3. Continue processing the RSVP message.

7.3 Authentication (Router/SBM/Policy server) (Router/PDP)

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

   If PDP 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 PDP may specify error value field. These typically
   include:

        - Authentication method not supported

        - Authentication failure

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

        - Unknown attribute (specify) type.

        - Unknown attribute (specify) sub type.

9. IANA Considerations

   Following the policies outlined in [IANA-CONSIDERATIONS],
   IdentityType values in the range 0-32767 are allocated an IETF
   Consensus action, IdentityType values between 32768-65535 are
   reserved for Private Use and are not assigned by IANA.

Yadav, et al.                                                       12
   Following the policies outlined in [IANA-CONSIDERATIONS],
   authentication attribute types (A-Type)in the range 0-127 are
   allocated an IETF Consensus action, A-Type values between 128-255
   are reserved for Private Use and are not assigned by IANA.

   Following the policies outlined in [IANA-CONSIDERATIONS],
   POLICY_LOCATOR SubType values in the range 0-127 are allocated an
   IETF Consensus action, POLICY_LOCATOR SubType values between 128-255
   are reserved for Private Use and are not assigned by IANA.

   Following the policies outlined in [IANA-CONSIDERATIONS],
   CREDENTIAL SubType values in the range 0-127 are allocated an IETF
   Consensus action, CREDENTIAL SubType values between 128-255 are
   reserved for Private Use and are not assigned by IANA.

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

11. Acknowledgments

   We would like 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
        - 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. thank Raj Yavatkar, Bob Linden and many others for
   their valuable comments on this draft.

12. References

Yadav, et al.                                                       13
   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

   [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."
               Internet-Draft, draft-ietf-rap-policy-ext-00.txt, April
               1998 draft-ietf-rap-policy-ext-01.txt,
               November 1998.

   [POL-FRAME] Yavatkar, R., et.al. "A Framework for Policy-based
               Admission Control RSVP." Internet-Draft, draft-ietf-rap-
               framework-01.txt, November 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]     R. Housley, et. al., "Internet X.509 Public Key
               Infrastructure Certificate and CRL Profile", Internet-
               Draft, draft-ietf-pkix-ipki-part1-11.txt, September
               1998.

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

Yadav, et al.                                                       14

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

   Peter Ford
   Microsoft
   1 Microsoft Way
   Redmond, WA 98054

   peterf@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

14. Full Copyright Statement

   Copyright (C) The Internet Society (1999). 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."

Yadav, et al.                                                       16