draft-ietf-rap-rsvp-newidentity-00.txt   draft-ietf-rap-rsvp-newidentity-01.txt 
Network Working Group S. Yadav
Internet Draft Satyendra Yadav Request for Comments: R. Yavatkar
Expiration: December 2000 Raj Yavatkar Obsoletes: 2752 Intel
File: draft-ietf-rap-rsvp-newidentity-00.txt Intel Category: Standards Track R. Pabbati
Ramesh Pabbati P. Ford
Peter Ford T. Moore
Tim Moore
Microsoft Microsoft
Shai Herzog S. Herzog
IPHighway IPHighway
January 2000
Identity Representation for RSVP Identity Representation for RSVP
June 2000
Status of this Memo
This document is an Internet-Draft and is in full conformance with draft-ietf-rap-rsvp-newidentity-01.txt
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Status of this Memo
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 This document is an Internet-Draft and is in full conformance with all
months and may be updated, replaced, or obsoleted by other documents provisions of Section 10 of RFC2026. Internet-Drafts are working
at any time. It is inappropriate to use Internet-Drafts as reference documents of the Internet Engineering Task Force (IETF), its areas, and
material or to cite them other than as "work in progress." its working groups. Note that other groups may also distribute working
documents as Internet-Drafts.
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved. Copyright (C) The Internet Society (2000). All Rights Reserved.
1. Abstract Abstract
This document describes the representation of identity information This document describes the representation of identity information in
in POLICY_DATA object [POL-EXT] for supporting policy based POLICY_DATA object [POL-EXT] for supporting policy based admission
admission control in RSVP. The goal of identity representation is to control in RSVP. The goal of identity representation is to allow a
allow a process on a system to securely identify the owner and the process on a system to securely identify the owner and the
application of the communicating process (e.g. user id) and convey application of the communicating process (e.g. user id) and convey
this information in RSVP messages (PATH or RESV) in a secure manner. this information in RSVP messages (PATH or RESV) in a secure manner.
We describe the encoding of identities as RSVP policy element. We We describe the encoding of identities as RSVP policy element. We
describe the processing rules to generate identity policy elements describe the processing rules to generate identity policy elements
for multicast merged flows. Subsequently, we describe for multicast merged flows. Subsequently, we describe representations
representations of user identities for Kerberos and Public Key based of user identities for Kerberos and Public Key based user
user authentication mechanisms. In summary we describe the use of authentication mechanisms. In summary we describe the use of this
this identity information in an operational setting. identity information in an operational setting.
Yadav, et al. 1
2. Conventions used in this document 1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
this document are to be interpreted as described in [RFC-2119]. document are to be interpreted as described in [RFC-2119].
3. Introduction This memo corrects an RSVP POLICY_DATA P-Type codepoint assignment
error in RFC2752.
RSVP [RFC 2205] is a resource reservation setup protocol designed 2. Introduction
for an integrated services Internet [RFC 1633]. RSVP is used by a
host to request specific quality of service (QoS) from the network RSVP [RFC 2205] is a resource reservation setup protocol designed for
for particular application data streams or flows. RSVP is also used an integrated services Internet [RFC 1633]. RSVP is used by a host to
by routers to deliver QoS requests to all nodes along the path(s) of request specific quality of service (QoS) from the network for
the flows and to establish and maintain state to provide the particular application data streams or flows. RSVP is also used by
requested service. RSVP requests will generally result in resources routers to deliver QoS requests to all nodes along the path(s) of the
being reserved in each node along the data path. RSVP allows flows and to establish and maintain state to provide the requested
particular users to obtain preferential access to network resources, service. RSVP requests will generally result in resources being
under the control of an admission control mechanism. Permission to reserved in each node along the data path. RSVP allows particular
make a reservation is based both upon the availability of the users to obtain preferential access to network resources, under the
requested resources along the path of the data and upon satisfaction control of an admission control mechanism. Permission to make a
of policy rules. Providing policy based admission control mechanism reservation is based both upon the availability of the requested
based on user identity or application is one of the prime resources along the path of the data and upon satisfaction of policy
requirements. rules. Providing policy based admission control mechanism based on
user identity or application is one of the prime requirements.
In order to solve these problems and implement identity based policy In order to solve these problems and implement identity based policy
control it is required to identify the user and/or application control it is required to identify the user and/or application making
making a RSVP request. a RSVP request.
This document proposes a mechanism for sending identification This document proposes a mechanism for sending identification
information in the RSVP messages and enables authorization decisions information in the RSVP messages and enables authorization decisions
based on policy and identity. based on policy and identity.
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 can generate an AUTH_DATA in the POLICY_DATA object. User process can generate 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 service inserts AUTH_DATA into the RSVP originating host. RSVP service inserts AUTH_DATA into the RSVP
message to identify the owner (user and/or application) making the message to identify the owner (user and/or application) making the
request for network resources. Network elements, such as routers, request for network resources. Network elements, such as routers,
authenticate request using the credentials presented in the authenticate request using the credentials presented in the AUTH_DATA
AUTH_DATA and admit the RSVP message based on admission policy. and admit the RSVP message based on admission policy. After a request
After a request has been authenticated, first hop router installs has been authenticated, first hop router installs the RSVP state and
the RSVP state and forwards the new policy element returned by the forwards the new policy element returned by the Policy Decision Point
Policy Decision Point (PDP) [POL-FRAME]. (PDP) [POL-FRAME].
Yadav, et al. 2
4. Policy Element for Authentication Data 3. Policy Element for Authentication Data
4.1 Policy Data Object Format 3.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 3.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. list of authentication attributes.
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Length | P-Type = Identity Type | | Length | P-Type = Identity Type |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
// Authentication Attribute List // // Authentication Attribute List //
+-------------------------------------------------------+ +-------------------------------------------------------+
skipping to change at line 149 skipping to change at page 3, line 42
3 AUTH_APP Authentication scheme to identify 3 AUTH_APP Authentication scheme to identify
applications applications
Authentication Attribute List Authentication Attribute List
Authentication attributes contain information specific to Authentication attributes contain information specific to
authentication method and type of AUTH_DATA. The policy element authentication method and type of AUTH_DATA. The policy element
provides the mechanism for grouping a collection of provides the mechanism for grouping a collection of
authentication attributes. authentication attributes.
Yadav, et al. 3 3.3 Authentication Attributes
4.3 Authentication Attributes
Authentication attributes MUST be encoded as a multiple of 4 octets, Authentication attributes MUST be encoded as a multiple of 4 octets,
attributes that are not a multiple of 4 octets long MUST be padded attributes that are not a multiple of 4 octets long MUST be padded to
to a 4-octet boundary. a 4-octet boundary.
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Length | A-Type |SubType | | Length | A-Type |SubType |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| 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
of the attribute (including the Length and A-Type fields) in the attribute (including the Length and A-Type fields) in number
number of octets. The length does not include any bytes padding of octets. The length does not include any bytes padding to the
to the value field to make the attribute multiple of 4 octets value field to make the attribute multiple of 4 octets long.
long.
A-Type A-Type
Authentication attribute type (A-Type) field is one octet. IANA Authentication attribute type (A-Type) field is one octet. IANA
acts as a registry for A-Types as described in the section 9, acts as a registry for A-Types as described in the section 9,
IANA Considerations. Initially, the registry contains the IANA Considerations. Initially, the registry contains the
following A-Types: 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]).
skipping to change at line 198 skipping to change at page 4, line 38
4 POLICY_ERROR_OBJECT Detailed information on policy 4 POLICY_ERROR_OBJECT Detailed information on policy
failures. failures.
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 the attribute specific information. The value field contains the attribute specific information.
Yadav, et al. 4 3.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 User or or application. Distinguished Name (DN) is unique for each User or
application 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 ...
+-------+-------+-------+-------- +-------+-------+-------+--------
skipping to change at line 246 skipping to change at page 5, line 38
4 UNICODE_DN_ENCRYPT OctetString contains the encrypted 4 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 3.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.
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.
+-------+-------+-------+-------+ +-------+-------+-------+-------+
skipping to change at line 291 skipping to change at page 6, line 38
3 KERBEROS_TKT OctetString contains Kerberos ticket. 3 KERBEROS_TKT OctetString contains Kerberos ticket.
4 X509_V3_CERT OctetString contains X.509 V3 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 3.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 ...
+-------+-------+-------+-------- +-------+-------+-------+--------
Length Length
Length of the attribute, which MUST be >= 4. Length of the attribute, which MUST be >= 4.
A-Type ti3 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.
OctetString OctetString
OctetString contains the digital signature of the AUTH_DATA. OctetString contains the digital signature of the AUTH_DATA.
4.3.4 Policy Error Object 3.3.4 Policy Error Object
This attribute is used to specify any errors associated with the This attribute is used to carry any specific policy control errors
policy element. When a RSVP policy node (local policy decision point generated by a node when processing/validating an Authentication Data
Policy Element. When a RSVP policy node (local policy decision point
or remote PDP) encounters a request that fails policy control due to or remote PDP) encounters a request that fails policy control due to
its Authentication Policy Element, it MAY add a POLICY_ERROR_CODE its Authentication Policy Element, it SHOULD add a POLICY_ERROR_CODE
containing additional information about the reason the failure containing additional information about the reason the failure
occurred into the policy element. This will then cause an occurred into the policy element. This will then cause an appropriate
appropriate PATH_ERROR or RESV_ERROR message to be generated with PATH_ERROR or RESV_ERROR message to be generated with the policy
the policy element and appropriate RSVP error code in the message, element and appropriate RSVP error code in the message, which is
which is returned to the request's source. returned to the request's source.
The AUTH_DATA policy element in the PATH or RSVP message SHOULD not The AUTH_DATA policy element in the PATH or RSVP message SHOULD not
contain the POLICY_ERROR_OBJECT attribute. These are only inserted contain the POLICY_ERROR_OBJECT attribute. These are only inserted
into PATH_ERROR and RESV_ERROR messages when generated by policy into PATH_ERROR and RESV_ERROR messages when generated by policy
aware intermediate nodes. aware intermediate nodes.
+----------+----------+----------+----------+ +----------+----------+----------+----------+
| Length | A-Type |SubType(0)| | Length | A-Type |SubType(0)|
+----------+----------+----------+----------+ +----------+----------+----------+----------+
| 0 (Reserved) | ErrorValue | | 0 (Reserved) | ErrorValue |
+----------+----------+----------+----------+ +----------+----------+----------+----------+
| OctetString ... | OctetString ...
+----------+----------+----------+----------+ +----------+----------+----------+----------+
Length Length
Length of the attribute, which MUST be >= 8. Length of the attribute, which MUST be >= 8.
Yadav, et al. 7
A-Type A-Type
POLICY_ERROR_CODE POLICY_ERROR_CODE
ErrorValue ErrorValue
A 32-bit bit code containing the reason that the policy decision A 32-bit bit code containing the reason that the policy decision
point failed to process the policy element. Following values point failed to process the policy element. Following values have
have been defined. been defined.
1 ERROR_NO_MORE_INFO No information is available. 1 ERROR_NO_MORE_INFO No information is available.
2 UNSUPPORTED_CREDENTIAL_TYPE This type of credentials is 2 UNSUPPORTED_CREDENTIAL_TYPE This type of credentials is
not supported. not supported.
3 INSUFFICIENT_PRIVILEGES The credentials do not have 3 INSUFFICIENT_PRIVILEGES The credentials do not have
sufficient privilege. sufficient privilege.
4 EXPIRED_CREDENTIAL The credential has expired. 4 EXPIRED_CREDENTIAL The credential has expired.
5 IDENTITY_CHANGED Identity has changed. 5 IDENTITY_CHANGED Identity has changed.
OctetString OctetString
The OctetString field contains information from the policy The OctetString field contains information from the policy
decision point that MAY contain additional information about decision point that MAY contain additional information about the
the policy failure. For example, it may include a human- policy failure. For example, it may include a human-readable
readable message in the ASCII text. message in the ASCII text.
5. Authentication Data Formats 4. Authentication Data Formats
Authentication attributes are grouped in a policy element to Authentication attributes are grouped in a policy element to
represent the identity credentials. represent the identity credentials.
5.1 Simple User Authentication 4.1 Simple User Authentication
In simple user authentication method the user login ID (in plain In simple user authentication method the user login ID (in plain
ASCII or UNICODE text) is encoded as CREDENTIAL attribute. A summary ASCII or UNICODE text) is encoded as CREDENTIAL attribute. A summary
of the simple user AUTH_DATA policy element is shown below. of the simple user AUTH_DATA policy element is shown below.
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| Length | P-type = AUTH_USER | | Length | P-type = AUTH_USER |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| Length |POLICY_LOCATOR| SubType | | Length |POLICY_LOCATOR| SubType |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| OctetString (User's Distinguished Name) ... | OctetString (User's Distinguished Name) ...
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| Length |CREDENTIAL | ASCII_ID | | Length |CREDENTIAL | ASCII_ID |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| OctetString (User's login ID) ... | OctetString (User's login ID) ...
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
Yadav, et al. 8 4.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
and both host and verifier of authentication information (router or both host and verifier of authentication information (router or PDP)
PDP) implement Kerberos authentication. implement Kerberos authentication.
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_USER | | Length | P-type = AUTH_USER |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| 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 4.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 PDP. A router when Kerberos ticket for the next network node or its PDP. A router when
generating a RSVP message contacts the KDC to obtain a Kerberos generating a RSVP message contacts the KDC to obtain a Kerberos
ticket for the next hop network node or its PDP. The identity of the ticket for the next hop network node or its PDP. The identity of the
PDP or next network hop can be statically configured, learned via PDP or next network hop can be statically configured, learned via
DHCP or maintained in a directory service. The Kerberos ticket is 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 sent to the next network node (which may be a router or host) in a
RSVP message. The KDC is used to validate the ticket and RSVP message. The KDC is used to validate the ticket and
authentication the user sending RSVP message. authentication the user sending RSVP message.
Yadav, et al. 9 4.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
is encoded as user credentials. The digital signature is used for 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.
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| Length | P-type = AUTH_USER | | Length | P-type = AUTH_USER |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| 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 4.3.1. Operational Setting for public key based authentication
Public key based authentication assumes following: Public key based authentication assumes following:
- 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 (PDP or router) has the ability to verify the - The verifier (PDP or router) has the ability to 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, PDP) use the user's public key (stored User Authenticators (router, PDP) use the user's public key (stored
in the digital certificate) to verify the signature and authenticate in the digital certificate) to verify the signature and authenticate
the user. the user.
Yadav, et al. 10 4.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_APP | | Length | P-type = AUTH_APP |
+----------------+--------------+--------------+--------------+ +----------------+--------------+--------------+--------------+
| Length |POLICY_LOCATOR| SubType | | Length |POLICY_LOCATOR| SubType |
+----------------+--------------+--------------+--------------+ +----------------+--------------+--------------+--------------+
| OctetString (Application Identity attributes in | OctetString (Application Identity attributes in
| the form of a Distinguished Name) ... | the form of a Distinguished Name) ...
+----------------+--------------+--------------+--------------+ +----------------+--------------+--------------+--------------+
| Length | CREDENTIAL | ASCII_ID | | Length | CREDENTIAL | ASCII_ID |
+----------------+--------------+--------------+--------------+ +----------------+--------------+--------------+--------------+
| OctetString (Application Id, e.g., vic.exe) | OctetString (Application Id, e.g., vic.exe)
+----------------+--------------+--------------+--------------+ +----------------+--------------+--------------+--------------+
6. Operation 5. Operation
+-----+ +-----+ +-----+ +-----+
| PDP |-------+ | PDP | | PDP |-------+ | PDP |
+-----+ | ................... +-----+ +-----+ | ................... +-----+
| : : | | : : |
+--------+ : Transit : +-------+ +--------+ : Transit : +-------+
+----| Router |------: Network : -------| Router|--+ +----| Router |------: Network : -------| Router|--+
| +--------+ : : +-------+ | | +--------+ : : +-------+ |
| | :.................: | | | | :.................: | |
| | | | | | | |
skipping to change at line 536 skipping to change at page 11, line 49
policy element containing the authentication identity when making the policy element containing the authentication identity when making the
RSVP request or forwarding a RSVP message. RSVP request or forwarding a 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
1. For unicast sessions the user policy locator is copied from the 1. For unicast sessions the user policy locator is copied from the
previous hop. The authentication credentials are for the current previous hop. The authentication credentials are for the current
network node identity. network node identity.
Yadav, et al. 11
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 the Network nodes generate application AUTH_DATA policy element using the
following rules: following rules:
1. For unicast sessions the application AUTH_DATA is copied from the 1. For unicast sessions the application AUTH_DATA is copied from the
previous hop. 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 PDP. first application AUTH_DATA in the message or chosen by the PDP.
7. Message Processing Rules 6. Message Processing Rules
7.1 Message Generation (RSVP Host) 6.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. RSVP message MAY contain multiple AUTH_DATA policy elements. 1. RSVP message MAY contain multiple AUTH_DATA policy elements.
2. Authentication policy element (AUTH_DATA) is created and the 2. Authentication policy element (AUTH_DATA) is created and the
IdentityType field is set to indicate the identity type in the IdentityType field is set to indicate the identity type in the
policy element. policy element.
- 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
are inserted as the CREDENTIAL attribute. inserted as the CREDENTIAL attribute.
3. POLICY_DATA object (containing the AUTH_DATA policy element) is 3. POLICY_DATA object (containing the AUTH_DATA policy element) is
inserted in the RSVP message in appropriate place. If INTEGRITY inserted in the RSVP message in appropriate place. If INTEGRITY
object is not computed for the RSVP message then an INTEGRITY object is not computed for the RSVP message then an INTEGRITY
object SHOULD be computed for this POLICY_DATA object, as object SHOULD be computed for this POLICY_DATA object, as
described in the [POL_EXT], and SHOULD be inserted as a Policy described in the [POL_EXT], and SHOULD be inserted as a Policy
Data option. Data option.
7.2 Message Reception (Router) 6.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 is not policy aware then it SHOULD send the RSVP 1. If router is not policy aware then it SHOULD send the RSVP message
message to the PDP and wait for response. If the router is policy to the PDP and wait for response. If the router is policy unaware
unaware then it ignores the policy data objects and continues then it ignores the policy data objects and continues processing
processing the RSVP message. the RSVP message.
2. Reject the message if the response from the PDP is negative. 2. Reject the message if the response from the PDP is negative.
3. Continue processing the RSVP message. 3. Continue processing the RSVP message.
Yadav, et al. 12 6.3 Authentication (Router/PDP)
7.3 Authentication (Router/PDP)
1. Retrieve the AUTH_DATA policy element. Check the PE type field 1. Retrieve the AUTH_DATA policy element. Check the PE type field and
and return an error if the identity type is not supported. return an error if the identity type is not supported.
2. Verify user credential 2. Verify user credential
- Simple authentication: e.g. Get user ID and validate it, or - Simple authentication: e.g. Get user ID and validate it, or get
get executable name and validate it. 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
or application by verifying the digital signature. application by verifying the digital signature.
8. Error Signaling 7. Error Signaling
If PDP fails to verify the AUTH_DATA policy element then it MUST If PDP fails to verify the AUTH_DATA policy element then it MUST
return policy control failure (Error Code = 02) to the PEP. The return policy control failure (Error Code = 02) to the PEP. The error
error values are described in [RFC 2205] and [POL-EXT]. Also PDP values are described in [RFC 2205] and [POL-EXT]. Also PDP SHOULD
SHOULD supply a policy data object containing the AUTH_DATA Policy supply a policy data object containing an AUTH_DATA Policy Element
Element with more details on the Policy Control failures in the with A-Type=POLICY_ERROR_CODE containing more details on the Policy
policy error object attribute. The PEP will include this Policy Data Control failure (see section 3.3.4). The PEP will include this Policy
object in the outgoing RSVP Error message. Data object in the outgoing RSVP Error message.
9. IANA Considerations 8. IANA Considerations
Following the policies outlined in [IANA-CONSIDERATIONS], Following the policies outlined in [IANA-CONSIDERATIONS],
authentication attribute types (A-Type)in the range 0-127 are authentication attribute types (A-Type)in the range 0-127 are
allocated through an IETF Consensus action, A-Type values between allocated through an IETF Consensus action, A-Type values between
128-255 are reserved for Private Use and are not assigned by IANA. 128-255 are reserved for Private Use and are not assigned by IANA.
Following the policies outlined in [IANA-CONSIDERATIONS], Following the policies outlined in [IANA-CONSIDERATIONS],
POLICY_LOCATOR SubType values in the range 0-127 are allocated POLICY_LOCATOR SubType values in the range 0-127 are allocated
through an IETF Consensus action, POLICY_LOCATOR SubType values through an IETF Consensus action, POLICY_LOCATOR SubType values
between 128-255 are reserved for Private Use and are not assigned by between 128-255 are reserved for Private Use and are not assigned by
IANA. IANA.
Following the policies outlined in [IANA-CONSIDERATIONS], Following the policies outlined in [IANA-CONSIDERATIONS], CREDENTIAL
CREDENTIAL SubType values in the range 0-127 are allocated through SubType values in the range 0-127 are allocated through an IETF
an IETF Consensus action, CREDENTIAL SubType values between 128-255 Consensus action, CREDENTIAL SubType values between 128-255 are
are reserved for Private Use and are not assigned by IANA. reserved for Private Use and are not assigned by IANA.
Yadav, et al. 13
10. Security Considerations 9. Security Considerations
The purpose of this draft is to describe a mechanism to authenticate The purpose of this memo is to describe a mechanism to authenticate
RSVP requests based on user identity in a secure manner. RSVP RSVP requests based on user identity in a secure manner. RSVP
INTEGRITY object is used to protect the policy object containing INTEGRITY object is used to protect the policy object containing user
user identity information from security (replay) attacks. Combining identity information from security (replay) attacks. Combining the
the AUTH_DATA policy element and the INTEGRITY object results in a AUTH_DATA policy element and the INTEGRITY object results in a secure
secure access control that enforces authentication based on both the access control that enforces authentication based on both the
identity of the user and the identity of the originating node. identity of the user and the identity of the originating node.
Simple authentication does not contain credential that can be Simple authentication does not contain credential that can be
securely authenticated and is inherently less secured. securely authenticated and is inherently less secured.
The Kerberos authentication mechanism is reasonably well secured. The Kerberos authentication mechanism is reasonably well secured.
User authentication using a public key certificate is known to User authentication using a public key certificate is known to
provide the strongest security. provide the strongest security.
11. Acknowledgments 10. Acknowledgments
We would like to thank Andrew Smith, Bob Lindell and many others for We would like to thank Andrew Smith, Bob Lindell and many others for
their valuable comments on this draft. their valuable comments on this memo.
Yadav, et al. 14
12. References 11. References
[ASCII] Coded Character Set -- 7-Bit American Standard Code for [ASCII] Coded Character Set -- 7-Bit American Standard
Information Interchange, ANSI X3.4-1986. Code for Information Interchange, ANSI X3.4-
1986.
[IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for [IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in
RFC 2434, October 1998. RFCs", BCP 26, RFC 2434, October 1998.
[POL-EXT] Herzog, S., "RSVP Extensions for Policy Control."
Internet-Draft, draft-ietf-rap-policy-ext-06.txt, April
1999.
[POL-FRAME] Yavatkar, R., et.al. "A Framework for Policy-based [POL-EXT] Herzog, S., "RSVP Extensions for Policy
Admission Control RSVP." Internet-Draft, draft-ietf-rap- Control", RFC 2750, January 2000.
framework-03.txt, April 1999.
[RFC 1510] The Kerberos Network Authentication Service (V5). Kohl [POL-FRAME] Yavatkar, R., Pendarakis, D. and R. Guerin, "A
J., Neuman, C. RFC 1510. Framework for Policy-based Admission Control
RSVP", RFC 2753, January 2000.
[RFC 1704] On Internet Authentication. Haller, N, Atkinson, R., [RFC 1510] Kohl, J. and C. Neuman, "The Kerberos Network
RFC 1704. Authentication Service (V5)", RFC 1510,
September 1993.
[RFC 1779] A String Representation of Distinguished Names. S. [RFC 1704] Haller, N. and R. Atkinson, "On Internet
Kille. RFC 1779 Authentication", RFC 1704, October 1994.
[RFC 2205] Braden, R., et. al., "Resource ReSerVation Protocol [RFC 1779] Killie, S., "A String Representation of
(RSVP) - Version 1 Functional Specification." RFC 2205. Distinguished Names", RFC 1779, March 1995.
[RFC 2209] Braden, R., Zhang, L., "Resource ReSerVation Protocol [RFC 2205] Braden, R., Zhang, L., Berson, S., Herzog, S.
(RSVP) - Version 1 Message Processing Rules." RFC 2209. and S. Jamin, "Resource ReSerVation Protocol
(RSVP) - Version 1 Functional Specification",
RFC 2205, September 1997.
[UNICODE] The Unicode Consortium, "The Unicode Standard, Version [RFC 2209] Braden, R. and L. Zhang, "Resource ReSerVation
2.0", Addison-Wesley, Reading, MA, 1996. Protocol (RSVP) - Version 1 Message Processing
Rules", RFC 2209, September 1997.
[X.509] R. Housley, et. al., "Internet X.509 Public Key [UNICODE] The Unicode Consortium, "The Unicode Standard,
Infrastructure Certificate and CRL Profile", RFC 2459 Version 2.0", Addison-Wesley, Reading, MA,
1996.
[X.509-ITU] ITU-T (formerly CCITT) Information technology - Open [X.509] Housley, R., Ford, W., Polk, W. and D. Solo,
Systems Interconnection - The Directory: Authentication "Internet X.509 Public Key Infrastructure
Framework Recommendation X.509 ISO/IEC 9594-8 Certificate and CRL Profile", RFC 2459, January
1999.
Yadav, et al. 15 [X.509-ITU] ITU-T (formerly CCITT) Information technology -
Open Systems Interconnection - The Directory:
Authentication Framework Recommendation X.509
ISO/IEC 9594-8
13. Author Information 12. 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 EMail: Satyendra.Yadav@intel.com
Raj Yavatkar Raj Yavatkar
Intel, JF3-206 Intel, JF3-206
2111 NE 25th Avenue 2111 NE 25th Avenue
Hillsboro, OR 97124 Hillsboro, OR 97124
Raj.Yavatkar@intel.com EMail: Raj.Yavatkar@intel.com
Ramesh Pabbati Ramesh Pabbati
Microsoft Microsoft
1 Microsoft Way 1 Microsoft Way
Redmond, WA 98054 Redmond, WA 98054
rameshpa@microsoft.com EMail: rameshpa@microsoft.com
Peter Ford Peter Ford
Microsoft Microsoft
1 Microsoft Way 1 Microsoft Way
Redmond, WA 98054 Redmond, WA 98054
peterf@microsoft.com EMail: peterf@microsoft.com
Tim Moore Tim Moore
Microsoft Microsoft
1 Microsoft Way 1 Microsoft Way
Redmond, WA 98054 Redmond, WA 98054
timmoore@microsoft.com EMail: timmoore@microsoft.com
Shai Herzog Shai Herzog
IPHighway IPHighway, Inc.
2055 Gateway Pl., Suite 400 55 New York Avenue
San Jose, CA 95110 Framingham, MA 01701
herzog@iphighway.com
Yadav, et al. 16 EMail: herzog@iphighway.com
14. Full Copyright Statement 13. Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved. Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph are
are included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Yadav, et al. 17 Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 

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