draft-ietf-rap-rsvp-identity-00.txt   draft-ietf-rap-rsvp-identity-01.txt 
Internet Draft Satyendra Yadav Internet Draft Satyendra Yadav
File: <draft-ietf-rap-rsvp-identity-00.txt> Intel File: <draft-ietf-rap-rsvp-identity-01.txt> Intel
Ramesh Pabbati Ramesh Pabbati
Microsoft Peter Ford
Tim Moore Tim Moore
Microsoft Microsoft
Shai Herzog Shai Herzog
IPHighway IPHighway
Identity Representation for RSVP Identity Representation for RSVP
November 1998 January 1999
Status of this Memo Status of this Memo
This document is an Internet Draft. Internet Drafts are working This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas, documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts. working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a Drafts as reference material or to cite them other than as a
"working draft" or "work in progress". "working draft" or "work in progress".
To view the entire list of current Internet-Drafts, please check the To view the list Internet-Draft Shadow Directories, see
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow http://www.ietf.org/shadow.html.
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 A Revised Version of this draft document will be submitted to the
RFC editor as a Proposed Standard for the Internet Community. RFC editor as a Proposed Standard for the Internet Community.
Discussion and suggestions for improvement are requested. This Discussion and suggestions for improvement are requested. This
document will expire in May 1999. Distribution of this draft is document will expire in July 1999. Distribution of this draft is
unlimited. unlimited.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
1. Abstract 1. Abstract
This document describes the representation of identity information This document describes the representation of identity information
in POLICY_DATA object [POL-EXT] for supporting policy based in POLICY_DATA object [POL-EXT] for supporting policy based
admission control in RSVP. The goal of identity representation is to admission control in RSVP. The goal of identity representation is to
allow a process on a system to securely identify the owner of the allow a process on a system to securely identify the owner of the
communicating process (e.g. user id) and convey this information in communicating process (e.g. user id) and convey this information in
RSVP messages (PATH or RESV) in a secure manner. We describe the RSVP messages (PATH or RESV) in a secure manner. We describe the
encoding of identities as RSVP policy element. We describe the encoding of identities as RSVP policy element. We describe the
processing rules to generate identity policy elements for multicast processing rules to generate identity policy elements for multicast
skipping to change at line 95 skipping to change at line 96
We describe the authentication policy element (AUTH_DATA) contained We describe the authentication policy element (AUTH_DATA) contained
in the POLICY_DATA object. User process generates an AUTH_DATA in the POLICY_DATA object. User process generates an AUTH_DATA
policy element and gives it to RSVP process (service) on the policy element and gives it to RSVP process (service) on the
originating host. RSVP process inserts AUTH_DATA into the RSVP originating host. RSVP process inserts AUTH_DATA into the RSVP
message to identify the owner (user) making the request for network message to identify the owner (user) making the request for network
resources. Network elements, such as routers, authenticate user resources. Network elements, such as routers, authenticate user
using the credentials presented in the AUTH_DATA and admit the RSVP using the credentials presented in the AUTH_DATA and admit the RSVP
message based on admission policy. After a request has been message based on admission policy. After a request has been
authenticated, first hop router installs the RSVP state and forwards authenticated, first hop router installs the RSVP state and forwards
the new policy element returned by the policy server. the new policy element returned by the Policy Decision Point (PDP)
[POL-FRAME].
Yadav, et al. 2 Yadav, et al. 2
4. Policy Element for Authentication Data 4. Policy Element for Authentication Data
4.1 Policy Data Object Format 4.1 Policy Data Object Format
POLICY_DATA objects contain policy information and are carried by POLICY_DATA objects contain policy information and are carried by
RSVP messages. A detail description of the format of POLICY_DATA RSVP messages. A detail description of the format of POLICY_DATA
object can be found in “RSVP Extensions for Policy Control” [POL- object can be found in “RSVP Extensions for Policy Control” [POL-
EXT]. EXT].
4.2 Authentication Data Policy Element 4.2 Authentication Data Policy Element
In this section, we describe a policy element (PE) called In this section, we describe a policy element (PE) called
authentication data (AUTH_DATA). AUTH_DATA policy element contains a authentication data (AUTH_DATA). AUTH_DATA policy element contains a
list of authentication attributes. Policy object containing list of authentication attributes. Policy object containing
AUTH_DATA MUST be protected against replay attacks using INTEGRITY AUTH_DATA must be protected against replay attacks using INTEGRITY
object option as described in the [POL-EXT]. object option as described in the [POL-EXT].
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Length | P-Type = AUTH_DATA | | Length | P-Type = AUTH_DATA |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| IdentityType | 0 (Reserved) | | IdentityType | 0 (Reserved) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
// Authentication Attribute List // // Authentication Attribute List //
| | | |
+-------------------------------------------------------+ +-------------------------------------------------------+
Length Length
The length of the policy element (including the Length and P- The length of the policy element (including the Length and P-
Type) is in number of octets and indicates the end of the Type) is in number of octets (must be a multiple of 4) and
authentication attribute list. indicates the end of the authentication attribute list.
AUTH_DATA AUTH_DATA
Policy element type (P-type) for the authentication data as Policy element type (P-type) for the authentication data as
registered with Internet Assigned Numbers Authority (IANA). registered with Internet Assigned Numbers Authority (IANA).
IdentityType IdentityType
This field describes the authentication method being used. This field describes the identity type used for authentication.
Following types are currently defined. The Internet Assigned Numbers Authority (IANA) acts as a
registry for identity types as described in the section 10, IANA
Considerations. Initially, the registry contains the following
identity types:
1 AUTH_USER authentication scheme to identify users 1 AUTH_USER authentication scheme to identify users
2 AUTH_APP authentication scheme to identify 2 AUTH_APP authentication scheme to identify
applications applications
Reserved Reserved
Must be set to 0. Must be set to 0.
Yadav, et al. 3 Yadav, et al. 3
skipping to change at line 173 skipping to change at line 178
| Value … | Value …
+--------+--------+--------+--------+ +--------+--------+--------+--------+
Length Length
The length field is two octets and indicates the actual length The length field is two octets and indicates the actual length
of the attribute (including the Length and A-Type fields) in of the attribute (including the Length and A-Type fields) in
number of octets. The length does not include any bytes padding number of octets. The length does not include any bytes padding
the attribute to make it multiple of 4 octets long. the attribute to make it multiple of 4 octets long.
A-Type A-Type
Authentication attribute type (A-Type) field is one octet. The Authentication attribute type (A-Type) field is one octet. IANA
following values are defined: acts as a registry for A-Types as described in the section 10,
IANA Considerations. Initially, the registry contains the
following A-Types:
1 POLICY_LOCATOR Unique string for locating the 1 POLICY_LOCATOR Unique string for locating the
admission policy (such as X.500 DN admission policy (such as X.500 DN
described in [RFC 1779]). described in [RFC 1779]).
2 CREDENTIAL_ User credential such as Kerberos 2 CREDENTIAL User credential such as Kerberos
ticket, or digital certificate. ticket, or digital certificate.
Application credential such as Application credential such as
application ID. application ID.
3 DIGITAL_SIGNATURE Digital signature of the 3 DIGITAL_SIGNATURE Digital signature of the
authentication data policy element. authentication data policy element.
SubType SubType
Authentication attribute sub-type field is one octet. Value of Authentication attribute sub-type field is one octet. Value of
SubType depends on A-type. SubType depends on A-type.
Value: Value:
The value field contains 0-65351 octets. The value field contains 0-65351 octets.
Yadav, et al. 4 Yadav, et al. 4
4.3.1 Policy Locator 4.3.1 Policy Locator
POLICY_LOCATOR is used to locate the admission policy for the user POLICY_LOCATOR is used to locate the admission policy for the user
or application. Distinguished Name (DN) is unique for each policy or application. Distinguished Name (DN) is unique for each User or
hence a DN is used as policy locator. application hence a DN is used as policy locator.
+-------+-------+-------+-------+ +-------+-------+-------+-------+
| Length |A-Type |SubType| | Length |A-Type |SubType|
+-------+-------+-------+-------+ +-------+-------+-------+-------+
| OctetString … | OctetString …
+-------+-------+-------+-------- +-------+-------+-------+--------
Length Length
> 4 > 4
A-Type A-Type
POLICY_LOCATOR POLICY_LOCATOR
SubType SubType
Following sub types for POLICY_LOCATOR are defined. Following sub types for POLICY_LOCATOR are 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 1 X500_DN OctetString contains the X.500 DN as described
in the RFC 1779 as an ASCII string. in the RFC 1779 as an ASCII string.
2 UNICODE DN OctetString contains the X.500 DN described in 2 UNICODE_DN OctetString contains the X.500 DN described in
the RFC 1779 as an UNICODE string. the RFC 1779 as an UNICODE string.
3 X500_DN ENCRYPT OctetString contains the encrypted X.500 DN. 3 X500_DN_ENCRYPT OctetString contains the encrypted X.500 DN.
The Kerberos session key or digital certificate The Kerberos session key or digital certificate
private key is used for encryption. For private key is used for encryption. For
Kerberos encryption the format is the same as Kerberos encryption the format is the same as
returned from gss_seal [RFC 1509]. returned from gss_seal [RFC 1509].
4 X500_UNICODE_DN ENCRYPT OctetString contains the encrypted 4 X500_UNICODE_DN_ENCRYPT OctetString contains the encrypted
UNICODE X.500 DN. The Kerberos session key or UNICODE X.500 DN. The Kerberos session key or
digital certificate private key is used for digital certificate private key is used for
encryption. For Kerberos encryption the format encryption. For Kerberos encryption the format
is the same as returned from gss_seal [RFC is the same as returned from gss_seal [RFC
1509]. 1509].
OctetString OctetString
The OctetString field contains the DN. The OctetString field contains the DN.
Yadav, et al. 5
4.3.2 Credential 4.3.2 Credential
CREDENTIAL indicates the credential of the user or application to be CREDENTIAL indicates the credential of the user or application to be
authenticated. For Kerberos authentication method the CREDENTIAL authenticated. For Kerberos authentication method the CREDENTIAL
object contains the Kerberos session ticket. For public key based object contains the Kerberos session ticket. For public key based
authentication this field contains a digital certificate. authentication this field contains a digital certificate.
Yadav, et al. 5
A summary of the CREDENTIAL attribute format is shown below. The A summary of the CREDENTIAL attribute format is shown below. The
fields are transmitted from left to right. fields are transmitted from left to right.
+-------+-------+-------+-------+ +-------+-------+-------+-------+
| Length |A-Type |SubType| | Length |A-Type |SubType|
+-------+-------+-------+-------+ +-------+-------+-------+-------+
| OctetString … | OctetString …
+-------+-------+-------+-------- +-------+-------+-------+--------
Length Length
> 4 > 4
A-Type A-Type
_CREDENTIAL CREDENTIAL
SubType SubType
Following sub types for CREDENTIAL are defined. 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:
1 ASCII_ID OctetString contains user or application 1 ASCII_ID OctetString contains user or application
identification in plain ASCII text. identification in plain ASCII text string.
2 UNICODE_ID OctetString contains user or application 2 UNICODE_ID OctetString contains user or application
identification in plain UNICODE text. identification in plain UNICODE text string.
3 KERBEROS_TKT OctetString contains Kerberos ticket. 3 KERBEROS_TKT OctetString contains Kerberos ticket.
4 X509_V3_CERT OctetString contains X.509v3 digital 4 X509_V3_CERT OctetString contains X.509 V3 digital
certificate [X.509]. certificate [X.509].
5 PGP_CERT OctetString contains PGP digital certificate. 5 PGP_CERT OctetString contains PGP digital certificate.
OctetString OctetString
The OctetString contains the user or application credential. The OctetString contains the user or application credential.
4.3.3 Digital Signature 4.3.3 Digital Signature
The DIGITAL_SIGNATURE attribute must be the last attribute in the The DIGITAL_SIGNATURE attribute must be the last attribute in the
attribute list and contains the digital signature of the AUTH_DATA attribute list and contains the digital signature of the AUTH_DATA
policy element. The digital signature signs all data in the policy element. The digital signature signs all data in the
AUTH_DATA policy element up to the DIGITAL_SIGNATURE. The algorithm AUTH_DATA policy element up to the DIGITAL_SIGNATURE. The algorithm
used to compute the digital signature depends on the authentication used to compute the digital signature depends on the authentication
method specified by the CREDENTIAL SubType field. method specified by the CREDENTIAL SubType field.
Yadav, et al. 6
A summary of DIGITAL_SIGNATURE attribute format is described below. A summary of DIGITAL_SIGNATURE attribute format is described below.
+-------+-------+-------+-------+ +-------+-------+-------+-------+
| Length |A-Type |SubType| | Length |A-Type |SubType|
+-------+-------+-------+-------+ +-------+-------+-------+-------+
| OctetString … | OctetString …
+-------+-------+-------+-------- +-------+-------+-------+--------
Yadav, et al. 6
Length Length
> 4 > 4
A-Type A-Type
DIGITAL_SIGNATURE DIGITAL_SIGNATURE
SubType SubType
No sub types for DIGITAL_SIGNATURE are currently defined. This No sub types for DIGITAL_SIGNATURE are currently defined. This
field must be set to 0. field must be set to 0.
skipping to change at line 333 skipping to change at line 346
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| Length | P-type = AUTH_DATA | | Length | P-type = AUTH_DATA |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| IdentityType = AUTH_USER | 0 | | IdentityType = AUTH_USER | 0 |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| Length |POLICY_LOCATOR| SubType | | Length |POLICY_LOCATOR| SubType |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| OctetString (User’s Distinguished Name) … | OctetString (User’s Distinguished Name) …
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| Length |CREDENTIAL | SubType | | Length |CREDENTIAL | ASCII_ID |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| OctetString (User’s login ID) … | OctetString (User’s login ID) …
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
Yadav, et al. 7
5.2 Kerberos User Authentication 5.2 Kerberos User Authentication
Kerberos [RFC 1510] authentication uses a trusted third party (the Kerberos [RFC 1510] authentication uses a trusted third party (the
Kerberos Distribution Center – KDC) to provide for authentication of Kerberos Distribution Center – KDC) to provide for authentication of
the user to a network server. It is assumed that a KDC is present the user to a network server. It is assumed that a KDC is present
and both host and verifier of authentication information (router or and both host and verifier of authentication information (router or
policy server) implement Kerberos authentication. PDP) implement Kerberos authentication.
Yadav, et al. 7
A summary of the Kerberos AUTH_DATA policy element is shown below. A summary of the Kerberos AUTH_DATA policy element is shown below.
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| Length | P-type (AUTH_DATA) | | Length | P-type (AUTH_DATA) |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| IdentityType = AUTH_USER | | IdentityType = AUTH_USER | 0 |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| Length |POLICY_LOCATOR| SubType | | Length |POLICY_LOCATOR| SubType |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| OctetString (User’s Distinguished Name) … | OctetString (User’s Distinguished Name) …
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| Length | CREDENTIAL | KERBEROS_TKT | | Length | CREDENTIAL | KERBEROS_TKT |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| OctetString (Kerberos Session Ticket) … | OctetString (Kerberos Session Ticket) …
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
5.2.1. Operational Setting using Kerberos Identities 5.2.1. Operational Setting using Kerberos Identities
An RSVP enabled host is configured to construct and insert AUTH_DATA An RSVP enabled host is configured to construct and insert AUTH_DATA
policy element into RSVP messages that designate use of the Kerberos policy element into RSVP messages that designate use of the Kerberos
authentication method (KERBEROS_TKT). Upon RSVP session authentication method (KERBEROS_TKT). Upon RSVP session
initialization, the user application contacts the KDC to obtain a initialization, the user application contacts the KDC to obtain a
Kerberos ticket for the next network node or its policy server. A Kerberos ticket for the next network node or its PDP. A router when
router when generating a RSVP message contacts the KDC to obtain a generating a RSVP message contacts the KDC to obtain a Kerberos
Kerberos ticket for the next hop network node or its policy server. ticket for the next hop network node or its PDP. The identity of the
The identity of the policy server or next network hop can be PDP or next network hop can be statically configured, learned via
statically configured, learned via DHCP or maintained in a directory DHCP or maintained in a directory service. The Kerberos ticket is
service. The Kerberos ticket is sent to the next network node (which sent to the next network node (which may be a router or host) in a
may be a router or host) in a RSVP message. The router may be a RSVP message. The KDC is used to validate the ticket and
policy node or may use a policy server. The KDC is used to validate authentication the user sending RSVP message.
the ticket and authentication the user sending RSVP message.
Yadav, et al. 8
5.3 Public Key based User Authentication 5.3 Public Key based User Authentication
In public key based user authentication method digital certificate In public key based user authentication method digital certificate
is encoded as user credentials. The digital signature is used for is encoded as user credentials. The digital signature is used for
authenticating the user. A summary of the public key user AUTH_DATA authenticating the user. A summary of the public key user AUTH_DATA
policy element is shown below. policy element is shown below.
Yadav, et al. 8
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| Length | P-type (AUTH_DATA) | | Length | P-type (AUTH_DATA) |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| IdentityType = AUTH_USER | 0 | | IdentityType = AUTH_USER | 0 |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| Length |POLICY_LOCATOR| SubType | | Length |POLICY_LOCATOR| SubType |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| OctetString (User’s Distinguished Name) … | OctetString (User’s Distinguished Name) …
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| Length | _CREDENTIAL | SubType | | Length | CREDENTIAL | SubType |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| OctetString (User’s Digital Certificate)… | OctetString (User’s Digital Certificate)…
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| Length |DIGITAL_SIGN. | 0 | | Length |DIGITAL_SIGN. | 0 |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| OctetString (Digital signature) … | OctetString (Digital signature) …
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
5.3.1. Operational Setting for public key based authentication 5.3.1. Operational Setting for public key based authentication
skipping to change at line 419 skipping to change at line 431
- RSVP service requestors have a pair of keys (private key and - RSVP service requestors have a pair of keys (private key and
public key). public key).
- Private key is secured with the user. - Private key is secured with the user.
- Public keys are stored in digital certificates and a trusted - Public keys are stored in digital certificates and a trusted
party, certificate authority (CA) issues these digital party, certificate authority (CA) issues these digital
certificates. certificates.
- The verifier (policy server or router) has the ability to - The verifier (PDP or router) has the ability to verify the
verify the digital certificate. digital certificate.
RSVP requestor uses its private key to generate DIGITAL_SIGNATURE. RSVP requestor uses its private key to generate DIGITAL_SIGNATURE.
User Authenticators (router, policy server) use the user’s public User Authenticators (router, PDP) use the user’s public key (stored
key (stored in the digital certificate) to verify the signature and in the digital certificate) to verify the signature and authenticate
authenticate the user. the user.
Yadav, et al. 9 Yadav, et al. 9
5.4 Simple Application Authentication 5.4 Simple Application Authentication
The application authentication method encodes the application The application authentication method encodes the application
identification such as an executable filename as plain ASCII or identification such as an executable filename as plain ASCII or
UNICODE text. UNICODE text.
+--------------+--------------+--------------+------------------+ +----------------+--------------+--------------+--------------+
| Length | P-type = AUTH_DATA | | Length | P-type = AUTH_DATA |
+--------------+--------------+--------------+------------------+ +----------------+--------------+--------------+--------------+
| IdentityType = AUTH_APP | 0 | | IdentityType = AUTH_APP | 0 |
+--------------+--------------+--------------+------------------+ +----------------+--------------+--------------+--------------+
| Length |POLICY_LOCATOR| SubType | | Length |POLICY_LOCATOR| SubType |
+--------------+--------------+--------------+------------------+ +----------------+--------------+--------------+--------------+
| OctetString (Application Distinguished Name) … | OctetString (Application Distinguished Name) …
+--------------+--------------+--------------+------------------+ +----------------+--------------+--------------+--------------+
| Length | CREDENTIAL | SubType | Length | CREDENTIAL | ASCII_ID |
+--------------+--------------+--------------+------------------+ +----------------+--------------+--------------+--------------+
| OctetString (Application Identification) | OctetString (Application Identification)
+--------------+--------------+--------------+------------------+ +----------------+--------------+--------------+--------------+
6. Operation 6. Operation
+------+ +------+ +-----+ +-----+
|Policy|------+ |Policy| | PDP |-------+ | PDP |
|Server| | |Server| +-----+ | ………………………………….……. +-----+
+------+ | ………………………………….……. +------+
| : : |
| : : | | : : |
+---------+ : : +-------+ +--------+ : Transit : +-------+
+----|First hop| Transit Transit -----|Transit| +----| Router |------: Network : -------| Router|--+
| | Router |----Router Router | Router|--+ | +--------+ : : +-------+ |
| +---------+ : : +-------+ |
| | :……………………………………...: | | | | :……………………………………...: | |
| | | | | | | |
Host A B C D Host A B C D
Figure 1: User and Application Authentication using AUTH_DATA object Figure 1: User and Application Authentication using AUTH_DATA PE
Hosts and network nodes generate AUTH DATA policy elements, contents Network nodes (hosts/routers) generate AUTH_DATA policy elements,
of which are depends on the identity type used and the contents of which are depends on the identity type used and the
authentication method used. But generally contains authentication authentication method used. But generally contains authentication
credentials (Kerberos ticket or digital certificate) and policy credentials (Kerberos ticket or digital certificate) and policy
locators (which can be the X.500 Distinguished Name of the user or locators (which can be the X.500 Distinguished Name of the user or
network node or application names). Host systems generate AUTH_DATA network node or application names). Network nodes generate AUTH_DATA
policy element containing the authentication identity when making policy element containing the authentication identity when making
the RSVP request. the RSVP request or forwarding an RSVP message.
Network nodes generate user AUTH_DATA policy element using the Network nodes generate user AUTH_DATA policy element using the
following rules following rules
Yadav, et al. 10
1. For unicast sessions the user policy locator is the copied from 1. For unicast sessions the user policy locator is the copied from
the previous hop. The authentication credentials are for the the previous hop. The authentication credentials are for the
current network node identity. current network node identity.
Yadav, et al. 10
2. For multicast messages the user policy locator is for the current 2. For multicast messages the user policy locator is for the current
network node identity. The authentication credentials are for the network node identity. The authentication credentials are for the
current network node. current network node.
Network nodes generate application AUTH_DATA policy element using Network nodes generate application AUTH_DATA policy element using
the following rules: the following rules:
1. For unicast sessions the application AUTH_DATA is the copied from 1. For unicast sessions the application AUTH_DATA is the copied from
the previous hop. the previous hop.
2. For multicast messages the application AUTH_DATA is either the 2. For multicast messages the application AUTH_DATA is either the
first application AUTH_DATA in the message or chosen by the policy first application AUTH_DATA in the message or chosen by the PDP.
server.
7. Message Processing Rules 7. Message Processing Rules
7.1 Message Generation (RSVP Host) 7.1 Message Generation (RSVP Host)
An RSVP message is created as specified in [RFC2205] with following An RSVP message is created as specified in [RFC2205] with following
modifications. modifications.
1. An authentication policy element, AUTH_DATA, is created and the 1. RSVP message may contain multiple AUTH_DATA policy elements. Only
one AUTH_DATA of each IdentityType is allowed.
2. Authentication policy element (AUTH_DATA) is created and the
IdentityType field is modified to indicate the authentication IdentityType field is modified to indicate the authentication
identity type being used. identity type being used.
- A DN is inserted as POLICY_LOCATOR attribute. - DN is inserted as POLICY_LOCATOR attribute.
- Credentials such as Kerberos ticket or digital certificate - Credentials such as Kerberos ticket or digital certificate
are inserted as the CREDENTIAL attribute. are inserted as the CREDENTIAL attribute.
2. A POLICY_DATA object is inserted in the RSVP message in 3. POLICY_DATA object is inserted in the RSVP message in appropriate
appropriate place with AUTH_DATA as one of the policy elements. place with AUTH_DATA as one of the policy elements. If INTEGRITY
If INTEGRITY object is not computed for the RSVP message then an object is not computed for the RSVP message then an INTEGRITY
INTEGRITY object MUST be computed for this POLICY_DATA object, as object must be computed for this POLICY_DATA object, as described
described in the [POL_EXT], and MUST be inserted as an option. in the [POL_EXT], and must be inserted as an option.
7.2 Message Reception (Router/Subnet Bandwidth Manager (SBM)) 7.2 Message Reception (Router)
RSVP message is processed as specified in [RFC2205] with following RSVP message is processed as specified in [RFC2205] with following
modifications. modifications.
1. If router/SBM is not policy aware then it SHOULD send the RSVP 1. If router is not policy aware then it should send the RSVP
message to the policy server and wait for response. message to the PDP and wait for response. If the router is policy
unaware then it ignores the policy data objects and continues
processing the RSVP message.
2. Reject the message if the response from the policy server is 2. Reject the message if the response from the PDP is negative.
negative.
Yadav, et al. 11 Yadav, et al. 11
3. Continue processing the RSVP message. 3. Continue processing the RSVP message.
7.3 Authentication (Router/SBM/Policy server) 7.3 Authentication (Router/PDP)
1. Retrieve the AUTH_DATA policy element. 1. Retrieve the AUTH_DATA policy element.
2. Check the IdentityType field and return an error if the identity 2. Check the IdentityType field and return an error if the identity
type is not supported. type is not supported.
3. Verify credential 3. Verify credential
- Simple authentication: e.g. Get user ID and validate it, or - Simple authentication: e.g. Get user ID and validate it, or
get executable name and validate it. get executable name and validate it.
- Kerberos: Send the Kerberos ticket to the KDC to obtain the - Kerberos: Send the Kerberos ticket to the KDC to obtain the
session key. Using the session key authenticate the user. session key. Using the session key authenticate the user.
- Public Key: Validate the certificate that it was issued by a - Public Key: Validate the certificate that it was issued by a
trusted Certificate Authority (CA) and authenticate the user trusted Certificate Authority (CA) and authenticate the user
or application by verifying the digital signature. or application by verifying the digital signature.
8. Security Considerations 8. Error Signaling
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 If PDP fails to verify the AUTH_DATA policy element then it must
it must indicate to the first hop router the Error Code = 02 (Policy indicate to the first hop router the Error Code = 02 (Policy control
control failure). The policy server may specify error value field. failure). The PDP may specify error value field. These typically
These typically include: include:
- Authentication method not supported - Authentication method not supported
Yadav, et al. 12
- Authentication failure - Authentication failure
- Required attribute (specify) missing. For example CREDENTIAL - Required attribute (specify) missing. For example CREDENTIAL
attribute missing. attribute missing.
- Unknown attribute (specify) type. - Unknown attribute (specify) type.
- Unknown attribute (specify) sub type. - Unknown attribute (specify) sub type.
10. Appendix A 9. IANA Considerations
Internet-Draft “RSVP Cryptography Authentication” [MD5] describes a Following the policies outlined in [IANA-CONSIDERATIONS],
mechanism to authenticate RSVP messages based on the interface of a IdentityType values in the range 0-32767 are allocated an IETF
node on which the RSVP messages are sent. A single key is used to Consensus action, IdentityType values between 32768-65535 are
authenticate RSVP requests made by all users for an interface of the reserved for Private Use and are not assigned by IANA.
node. The security of such a setup has following limitations:
- Authentication and RSVP admission control on the basis of Yadav, et al. 12
node credentials alone is less secure as a node can Following the policies outlined in [IANA-CONSIDERATIONS],
impersonate all of its users even when they are not logged authentication attribute types (A-Type)in the range 0-127 are
in. allocated an IETF Consensus action, A-Type values between 128-255
are reserved for Private Use and are not assigned by IANA.
- It is not possible to identify the user making the RSVP Following the policies outlined in [IANA-CONSIDERATIONS],
request. 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.
Mechanism described in this draft can be used to solve the key Following the policies outlined in [IANA-CONSIDERATIONS],
distribution problem between hosts and routers for implementing CREDENTIAL SubType values in the range 0-127 are allocated an IETF
[MD5]. We call this key the integrity key and if a network node is Consensus action, CREDENTIAL SubType values between 128-255 are
using authentication information, it may obtain this integrity key reserved for Private Use and are not assigned by IANA.
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 10. Security Considerations
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 The purpose of this draft is to describe a mechanism to authenticate
If the policy server or another key server supplies an integrity key RSVP requests based on user identity in a secure manner. RSVP
then check the integrity object. The router or host for later use INTEGRITY object is used to protect the policy object containing
(e.g., on refreshes) may cache this key. If a policy server obtains user identity information from security (replay) attacks. Combining
the integrity key on behalf of the router it can send the key using the AUTH_DATA policy element and the INTEGRITY object results in a
cops [COPS-RSVP]. 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.
11. Acknowledgments 11. Acknowledgments
We would like to thank Raj Yavatkar, Bob Linden and many others for We would like to thank Raj Yavatkar, Bob Linden and many others for
their valuable comments on this draft. their valuable comments on this draft.
12. References 12. References
Yadav, et al. 13
[ASCII] Coded Character Set -- 7-Bit American Standard Code for [ASCII] Coded Character Set -- 7-Bit American Standard Code for
Information Interchange, ANSI X3.4-1986. Information Interchange, ANSI X3.4-1986.
[MD5] Baker, F., et.al. "RSVP Cryptographic Authentication." [IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for
Internet-Draft, draft-ietf-rsvp-md5-07.txt, November Writing an IANA Considerations Section in RFCs", BCP 26,
1998. RFC 2434, October 1998.
[POL-EXT] Herzog, S., "RSVP Extensions for Policy Control." [POL-EXT] Herzog, S., "RSVP Extensions for Policy Control."
Internet-Draft, draft-ietf-rap-policy-ext-00.txt, April Internet-Draft, draft-ietf-rap-policy-ext-01.txt,
1998 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 [RFC 1510] The Kerberos Network Authentication Service (V5). Kohl
J., Neuman, C. RFC 1510. J., Neuman, C. RFC 1510.
[RFC 1704] On Internet Authentication. Haller, N, Atkinson, R., [RFC 1704] On Internet Authentication. Haller, N, Atkinson, R.,
RFC 1704. RFC 1704.
[RFC 1779] A String Representation of Distinguished Names. S. [RFC 1779] A String Representation of Distinguished Names. S.
Kille. RFC 1779 Kille. RFC 1779
[RFC 2205] Braden, R., et. al., "Resource ReSerVation Protocol [RFC 2205] Braden, R., et. al., "Resource ReSerVation Protocol
(RSVP) – Version 1 Functional Specification." RFC 2205. (RSVP) – Version 1 Functional Specification." RFC 2205.
[RFC 2209] Braden, R., Zhang, L., "Resource ReSerVation Protocol [RFC 2209] Braden, R., Zhang, L., "Resource ReSerVation Protocol
(RSVP) - Version 1 Message Processing Rules." RFC 2209. (RSVP) - Version 1 Message Processing Rules." RFC 2209.
[UNICODE] The Unicode Consortium, "The Unicode Standard, Version [UNICODE] The Unicode Consortium, "The Unicode Standard, Version
2.0", Addison-Wesley, Reading, MA, 1996. 2.0", Addison-Wesley, Reading, MA, 1996.
[X.509] ITU-T (formerly CCITT) Information technology – Open [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 Systems Interconnection – The Directory: Authentication
Framework Recommendation X.509 ISO/IEC 9594-8 Framework Recommendation X.509 ISO/IEC 9594-8
Yadav, et al. 14 Yadav, et al. 14
13. Author Information 13. Author Information
Satyendra Yadav Satyendra Yadav
Intel, JF3-206 Intel, JF3-206
2111 NE 25th Avenue 2111 NE 25th Avenue
skipping to change at line 688 skipping to change at line 682
Framework Recommendation X.509 ISO/IEC 9594-8 Framework Recommendation X.509 ISO/IEC 9594-8
Yadav, et al. 14 Yadav, et al. 14
13. Author Information 13. Author Information
Satyendra Yadav Satyendra Yadav
Intel, JF3-206 Intel, JF3-206
2111 NE 25th Avenue 2111 NE 25th Avenue
Hillsboro, OR 97124 Hillsboro, OR 97124
Satyendra.Yadav@intel.com Satyendra.Yadav@intel.com
Ramesh Pabbati Ramesh Pabbati
Microsoft Microsoft
1 Microsoft Way 1 Microsoft Way
Redmond, WA 98054 Redmond, WA 98054
rameshpa@microsoft.com rameshpa@microsoft.com
Peter Ford
Microsoft
1 Microsoft Way
Redmond, WA 98054
peterf@microsoft.com
Tim Moore Tim Moore
Microsoft Microsoft
1 Microsoft Way 1 Microsoft Way
Redmond, WA 98054 Redmond, WA 98054
timmoore@microsoft.com timmoore@microsoft.com
Shai Herzog Shai Herzog
IPHighway IPHighway
2055 Gateway Pl., Suite 400 2055 Gateway Pl., Suite 400
San Jose, CA 95110 San Jose, CA 95110
herzog@iphighway.com herzog@iphighway.com
Yadav, et al. 15 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
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/