draft-ietf-rap-rsvp-newidentity-02.txt   rfc3182.txt 
Network Working Group R. Hess, Editor
Request for Comments: S. Yadav Network Working Group S. Yadav
Obsoletes: 2752 R. Yavatkar Request for Comments: 3182 R. Yavatkar
Category: Standards Track Intel Obsoletes: 2752 Intel
R. Pabbati Category: Standards Track R. Pabbati
P. Ford P. Ford
T. Moore T. Moore
Microsoft Microsoft
S. Herzog S. Herzog
IPHighway PolicyConsulting.Com
January 2000 R. Hess
Intel
October 2001
Identity Representation for RSVP Identity Representation for RSVP
draft-ietf-rap-rsvp-newidentity-02.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document specifies an Internet standards track protocol for the
provisions of Section 10 of RFC2026. Internet-Drafts are working Internet community, and requests discussion and suggestions for
documents of the Internet Engineering Task Force (IETF), its areas, and improvements. Please refer to the current edition of the "Internet
its working groups. Note that other groups may also distribute working Official Protocol Standards" (STD 1) for the standardization state
documents as Internet-Drafts. and status of this protocol. Distribution of this memo is unlimited.
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract Abstract
This document describes the representation of identity information in This document describes the representation of identity information in
POLICY_DATA object [POL-EXT] for supporting policy based admission POLICY_DATA object for supporting policy based admission control in
control in RSVP. The goal of identity representation is to allow a the Resource ReSerVation Protocol (RSVP). The goal of identity
process on a system to securely identify the owner and the representation is to allow a process on a system to securely identify
application of the communicating process (e.g. user id) and convey the owner and the application of the communicating process (e.g.,
this information in RSVP messages (PATH or RESV) in a secure manner. user id) and convey this information in RSVP messages (PATH or RESV)
We describe the encoding of identities as RSVP policy element. We in a secure manner. We describe the encoding of identities as RSVP
describe the processing rules to generate identity policy elements policy element. We describe the processing rules to generate
for multicast merged flows. Subsequently, we describe representations identity policy elements for multicast merged flows. Subsequently,
of user identities for Kerberos and Public Key based user we describe representations of user identities for Kerberos and
authentication mechanisms. In summary we describe the use of this Public Key based user authentication mechanisms. In summary, we
identity information in an operational setting. describe the use of this identity information in an operational
setting.
RFC xxxx Identity Representation for RSVP January 2000 This memo corrects an RSVP POLICY_DATA P-Type codepoint assignment
error and a field size definition error in ErrorValue in RFC 2752.
1. 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 this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC-2119]. document are to be interpreted as described in [RFC 2119].
This memo corrects an RSVP POLICY_DATA P-Type codepoint assignment
error in RFC2752.
2. Introduction 2. Introduction
RSVP [RFC 2205] is a resource reservation setup protocol designed for RSVP [RFC 2205] is a resource reservation setup protocol designed for
an integrated services Internet [RFC 1633]. RSVP is used by a host to an integrated services Internet [RFC 1633]. RSVP is used by a host
request specific quality of service (QoS) from the network for to request specific quality of service (QoS) from the network for
particular application data streams or flows. RSVP is also used by particular application data streams or flows. RSVP is also used by
routers to deliver QoS requests to all nodes along the path(s) of the routers to deliver QoS requests to all nodes along the path(s) of the
flows and to establish and maintain state to provide the requested flows and to establish and maintain state to provide the requested
service. RSVP requests will generally result in resources being service. RSVP requests will generally result in resources being
reserved in each node along the data path. RSVP allows particular reserved in each node along the data path. RSVP allows particular
users to obtain preferential access to network resources, under the users to obtain preferential access to network resources, under the
control of an admission control mechanism. Permission to make a control of an admission control mechanism. Permission to make a
reservation is based both upon the availability of the requested reservation is based both upon the availability of the requested
resources along the path of the data and upon satisfaction of policy resources along the path of the data and upon satisfaction of policy
rules. Providing policy based admission control mechanism based on rules. Providing policy based admission control mechanism based on
user identity or application is one of the prime requirements. 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 making control it is required to identify the user and/or application 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 AUTH_DATA authenticate request using the credentials presented in the AUTH_DATA
and admit the RSVP message based on admission policy. After a request and admit the RSVP message based on admission policy. After a
has been authenticated, first hop router installs the RSVP state and request has been authenticated, first hop router installs the RSVP
forwards the new policy element returned by the Policy Decision Point state and forwards the new policy element returned by the Policy
(PDP) [POL-FRAME]. Decision Point (PDP) [POL-FRAME].
RFC xxxx Identity Representation for RSVP January 2000
3. Policy Element for Authentication Data 3. Policy Element for Authentication Data
3.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].
3.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 //
+-------------------------------------------------------+ +-------------------------------------------------------+
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)
Type) is in number of octets (MUST be a multiple of 4) and is in number of octets (MUST be a multiple of 4) and indicates the
indicates the end of the authentication attribute list. end of the authentication attribute list.
P-Type (Identity Type) P-Type (Identity Type)
Type of identity information contained in this Policy Element Type of identity information contained in this Policy Element
supplied as the Policy element type (P-type). The Internet supplied as the Policy element type (P-type). The Internet
Assigned Numbers Authority (IANA) acts as a registry for policy Assigned Numbers Authority (IANA) acts as a registry for policy
element types for identity as described in the [POL-EXT]. element types for identity as described in the [POL-EXT].
Initially, the registry contains the following P-Types for Initially, the registry contains the following P-Types for
identity: identity:
2 AUTH_USER Authentication scheme to identify users 2 AUTH_USER Authentication scheme to identify users
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
authentication attributes. attributes.
RFC xxxx Identity Representation for RSVP January 2000
3.3 Authentication Attributes 3.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 to attributes that are not a multiple of 4 octets long MUST be padded 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 of The length field is two octets and indicates the actual length of
the attribute (including the Length and A-Type fields) in number the attribute (including the Length and A-Type fields) in number
of octets. The length does not include any bytes padding to the of octets. The length does not include any bytes padding to the
value field to make the attribute multiple of 4 octets long. value field to make the attribute multiple of 4 octets 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 8,
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]).
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.
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.
RFC xxxx Identity Representation for RSVP January 2000
3.3.1 Policy Locator 3.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
or application. Distinguished Name (DN) is unique for each User 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 ...
+-------+-------+-------+-------- +-------+-------+-------+--------
Length Length
Length of the attribute, which MUST be >= 4. Length of the attribute, which MUST be >= 4.
A-Type A-Type
POLICY_LOCATOR POLICY_LOCATOR
SubType SubType
Following sub types for POLICY_LOCATOR are defined. IANA acts as Following sub types for POLICY_LOCATOR are defined. IANA acts as
a registry for POLICY_LOCATOR sub types as described in the a registry for POLICY_LOCATOR sub types as described in the
section 9, IANA Considerations. Initially, the registry contains section 8, IANA Considerations. Initially, the registry contains
the following sub types for POLICY_LOCATOR: the following sub types for POLICY_LOCATOR:
1 ASCII_DN OctetString contains the X.500 DN as described 1 ASCII_DN OctetString contains the X.500 DN as
in the RFC 1779 as an ASCII string. described 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
the RFC 1779 as an UNICODE string. in the RFC 1779 as an UNICODE string.
3 ASCII_DN_ENCRYPT OctetString contains the encrypted X.500 3 ASCII_DN_ENCRYPT OctetString contains the encrypted X.500
DN. The Kerberos session key or digital DN. The Kerberos session key or digital
certificate private key is used for encryption. certificate private key is used for
For Kerberos encryption the format is the same encryption. For Kerberos encryption the
as returned from gss_seal [RFC 1509]. format is the same as returned from
gss_seal [RFC 1509].
4 UNICODE_DN_ENCRYPT OctetString contains the encrypted 4 UNICODE_DN_ENCRYPT OctetString contains the encrypted UNICODE
UNICODE X.500 DN. The Kerberos session key or 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
is the same as returned from gss_seal [RFC format is the same as returned from
1509]. gss_seal [RFC 1509].
OctetString OctetString
The OctetString field contains the DN. The OctetString field contains the DN.
RFC xxxx Identity Representation for RSVP January 2000
3.3.2 Credential 3.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.
+-------+-------+-------+-------+ +-------+-------+-------+-------+
| 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 A-Type
CREDENTIAL CREDENTIAL
SubType SubType
IANA acts as a registry for CREDENTIAL sub types as described in IANA acts as a registry for CREDENTIAL sub types as described in
the section 9, IANA Considerations. Initially, the registry the section 8, IANA Considerations. Initially, the registry
contains the following sub types for CREDENTIAL: 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 string. 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 string. 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.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.
RFC xxxx Identity Representation for RSVP January 2000
3.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.
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 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.
3.3.4 Policy Error Object 3.3.4 Policy Error Object
This attribute is used to carry any specific policy control errors This attribute is used to carry any specific policy control errors
generated by a node when processing/validating an Authentication Data generated by a node when processing/validating an Authentication Data
Policy Element. When a RSVP policy node (local policy decision point 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 SHOULD 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 appropriate occurred into the policy element. This will then cause an
PATH_ERROR or RESV_ERROR message to be generated with the policy appropriate PATH_ERROR or RESV_ERROR message to be generated with the
element and appropriate RSVP error code in the message, which is policy element and appropriate RSVP error code in the message, which
returned to the request's source. is returned to the request's source.
RFC xxxx Identity Representation for RSVP January 2000
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 | | Length | A-Type | SubType |
+----------+----------+----------+----------+ +----------+----------+----------+----------+
| 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.
A-Type A-Type
POLICY_ERROR_CODE POLICY_ERROR_CODE
SubType SubType
No sub types for POLICY_ERROR_CODE are currently defined. This No sub types for POLICY_ERROR_CODE are currently defined. This
field MUST be set to 0. field MUST be set to 0.
ErrorValue ErrorValue
A 32-bit bit code containing the reason that the policy decision A 16-bit bit code containing the reason that the policy decision
point failed to process the policy element. Following values have point failed to process the policy element. IANA acts as a
been defined. registry for ErrorValues as described in section 8, IANA
Considerations. Following values have 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 the decision point that MAY contain additional information about the
policy failure. For example, it may include a human-readable policy failure. For example, it may include a human-readable
message in the ASCII text. message in the ASCII text.
4. 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.
RFC xxxx Identity Representation for RSVP January 2000
4.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) ...
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
4.2 Kerberos User Authentication 4.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 and the user to a network server. It is assumed that a KDC is present
both host and verifier of authentication information (router or PDP) and both host and verifier of authentication information (router or
implement Kerberos authentication. PDP) 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) ...
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
4.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
RFC xxxx Identity Representation for RSVP January 2000
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.
4.3 Public Key based User Authentication 4.3 Public Key based User Authentication
In public key based user authentication method digital certificate is In public key based user authentication method digital certificate 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 |
skipping to change at page 10, line 40 skipping to change at page 10, line 38
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| Length |DIGITAL_SIGN. | 0 | | Length |DIGITAL_SIGN. | 0 |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| OctetString (Digital signature) ... | OctetString (Digital signature) ...
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
4.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.
RFC xxxx Identity Representation for RSVP January 2000
4.4 Simple Application Authentication 4.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 |
skipping to change at page 11, line 43 skipping to change at page 11, line 46
+----| Router |------: Network : -------| Router|--+ +----| Router |------: Network : -------| Router|--+
| +--------+ : : +-------+ | | +--------+ : : +-------+ |
| | :.................: | | | | :.................: | |
| | | | | | | |
Host A B C D Host A B C D
Figure 1: User and Application Authentication using AUTH_DATA PE Figure 1: User and Application Authentication using AUTH_DATA PE
Network nodes (hosts/routers) generate AUTH_DATA policy elements, Network nodes (hosts/routers) generate AUTH_DATA policy elements,
contents of which are depend on the identity type used and the contents of which are depend on the identity type used and the
authentication method used. These generally contain authentication authentication method used. These generally contain 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). Network nodes generate AUTH_DATA network node or application names). Network nodes generate AUTH_DATA
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.
RFC xxxx Identity Representation for RSVP January 2000
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.
6. Message Processing Rules 6. Message Processing Rules
6.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 [RFC 2205] 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 are - Credentials such as Kerberos ticket or digital certificate 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.
6.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 [RFC 2205] with following
modifications. modifications.
1. If router is not policy aware then it SHOULD send the RSVP message 1. If router is not policy aware then it SHOULD send the RSVP message
to the PDP and wait for response. If the router is policy unaware to the PDP and wait for response. If the router is policy unaware
then it ignores the policy data objects and continues processing then it ignores the policy data objects and continues 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.
RFC xxxx Identity Representation for RSVP January 2000
3. Continue processing the RSVP message. 3. Continue processing the RSVP message.
6.3 Authentication (Router/PDP) 6.3 Authentication (Router/PDP)
1. Retrieve the AUTH_DATA policy element. Check the PE type field and 1. Retrieve the AUTH_DATA policy element. Check the PE type field
return an error if the identity type is not supported. and 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 get - Simple authentication: e.g., Get user ID and validate it, or
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 or trusted Certificate Authority (CA) and authenticate the user or
application by verifying the digital signature. application by verifying the digital signature.
7. 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 error return policy control failure (Error Code = 02) to the PEP. The
values are described in [RFC 2205] and [POL-EXT]. Also PDP SHOULD error values are described in [RFC 2205] and [POL-EXT]. Also PDP
supply a policy data object containing an AUTH_DATA Policy Element SHOULD supply a policy data object containing an AUTH_DATA Policy
with A-Type=POLICY_ERROR_CODE containing more details on the Policy Element with A-Type=POLICY_ERROR_CODE containing more details on the
Control failure (see section 3.3.4). The PEP will include this Policy Policy Control failure (see section 3.3.4). The PEP will include
Data object in the outgoing RSVP Error message. this Policy Data object in the outgoing RSVP Error message.
8. IANA Considerations 8. IANA Considerations
Following the policies outlined in [IANA-CONSIDERATIONS], Standard Following the policies outlined in [IANA-CONSIDERATIONS], Standard
RSVP Policy Elements (P-type values) are assigned by IETF Consensus RSVP Policy Elements (P-type values) are assigned by IETF Consensus
action as described in [POL-EXT]. action as described in [POL-EXT].
P-Type AUTH_USER is assigned the value 2. P-Type AUTH_APP is assigned P-Type AUTH_USER is assigned the value 2. P-Type AUTH_APP is
the value 3. assigned the value 3.
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.
A-Type POLICY_LOCATOR is assigned the value 1. A-Type CREDENTIAL is A-Type POLICY_LOCATOR is assigned the value 1. A-Type CREDENTIAL is
assigned the value 2. A-Type DIGITAL_SIGNATURE is assigned the value assigned the value 2. A-Type DIGITAL_SIGNATURE is assigned the value
3. A-Type POLICY_ERROR_OBJECT is assigned the value 4. 3. A-Type POLICY_ERROR_OBJECT is assigned the value 4.
RFC xxxx Identity Representation for RSVP January 2000
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.
POLICY_LOCATOR SubType ASCII_DN is assigned the value 1, SubType POLICY_LOCATOR SubType ASCII_DN is assigned the value 1, SubType
UNICODE_DN is assigned the value 2, SubType ASCII_DN_ENCRYPT is UNICODE_DN is assigned the value 2, SubType ASCII_DN_ENCRYPT is
assigned the value 3 and SubType UNICODE_DN_ENCRYPT is assigned the assigned the value 3 and SubType UNICODE_DN_ENCRYPT is assigned the
skipping to change at page 14, line 28 skipping to change at page 14, line 38
Following the policies outlined in [IANA-CONSIDERATIONS], CREDENTIAL Following the policies outlined in [IANA-CONSIDERATIONS], CREDENTIAL
SubType values in the range 0-127 are allocated through an IETF SubType values in the range 0-127 are allocated through an IETF
Consensus action, CREDENTIAL SubType values between 128-255 are Consensus action, CREDENTIAL SubType values between 128-255 are
reserved for Private Use and are not assigned by IANA. reserved for Private Use and are not assigned by IANA.
CREDENTIAL SubType ASCII_ID is assigned the value 1, SubType CREDENTIAL SubType ASCII_ID is assigned the value 1, SubType
UNICODE_ID is assigned the value 2, SubType KERBEROS_TKT is assigned UNICODE_ID is assigned the value 2, SubType KERBEROS_TKT is assigned
the value 3, SubType X509_V3_CERT is assigned the value 4, SubType the value 3, SubType X509_V3_CERT is assigned the value 4, SubType
PGP_CERT is assigned the value 5. PGP_CERT is assigned the value 5.
Following the policies outlined in [IANA-CONSIDERATIONS], ErrorValues
in the range 0-32767 are allocated through an IETF Consensus action,
ErrorValues between 32768-65535 are reserved for Private Use and are
not assigned by IANA.
ErrorValue ERROR_NO_MORE_INFO is assigned the value 1,
UNSUPPORTED_CREDENTIAL_TYPE is assigned the value 2,
INSUFFICIENT_PRIVILEGES is assigned the value 3, EXPIRED_CREDENTIAL
is assigned the value 4, and IDENTITY_CHANGED is assigned the value
5.
9. Security Considerations 9. Security Considerations
The purpose of this memo 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 user INTEGRITY object is used to protect the policy object containing user
identity information from security (replay) attacks. Combining the identity information from security (replay) attacks. Combining the
AUTH_DATA policy element and the INTEGRITY object results in a secure AUTH_DATA policy element and the INTEGRITY object results in a 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.
10. 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 memo. their valuable comments on this memo.
RFC xxxx Identity Representation for RSVP January 2000
11. References 11. References
[ASCII] Coded Character Set -- 7-Bit American Standard [ASCII] Coded Character Set -- 7-Bit American Standard
Code for Information Interchange, ANSI X3.4- Code for Information Interchange, ANSI X3.4-
1986. 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 Writing an IANA Considerations Section in
RFCs", BCP 26, RFC 2434, October 1998. RFCs", BCP 26, RFC 2434, October 1998.
skipping to change at page 15, line 43 skipping to change at page 16, line 17
[RFC 2205] Braden, R., Zhang, L., Berson, S., Herzog, S. [RFC 2205] Braden, R., Zhang, L., Berson, S., Herzog, S.
and S. Jamin, "Resource ReSerVation Protocol and S. Jamin, "Resource ReSerVation Protocol
(RSVP) - Version 1 Functional Specification", (RSVP) - Version 1 Functional Specification",
RFC 2205, September 1997. RFC 2205, September 1997.
[RFC 2209] Braden, R. and L. Zhang, "Resource ReSerVation [RFC 2209] Braden, R. and L. Zhang, "Resource ReSerVation
Protocol (RSVP) - Version 1 Message Processing Protocol (RSVP) - Version 1 Message Processing
Rules", RFC 2209, September 1997. Rules", RFC 2209, September 1997.
[RFC 2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, RFC 2119,
March 1997.
[RFC 2751] Herzog, S., "Signaled Preemption Priority
Policy Element", RFC 2751, January 2000.
[UNICODE] The Unicode Consortium, "The Unicode Standard, [UNICODE] The Unicode Consortium, "The Unicode Standard,
Version 2.0", Addison-Wesley, Reading, MA, Version 2.0", Addison-Wesley, Reading, MA,
1996. 1996.
[X.509] Housley, R., Ford, W., Polk, W. and D. Solo, [X.509] Housley, R., Ford, W., Polk, W. and D. Solo,
"Internet X.509 Public Key Infrastructure "Internet X.509 Public Key Infrastructure
Certificate and CRL Profile", RFC 2459, January Certificate and CRL Profile", RFC 2459, January
1999. 1999.
[X.509-ITU] ITU-T (formerly CCITT) Information technology - [X.509-ITU] ITU-T (formerly CCITT) Information technology -
Open Systems Interconnection - The Directory: Open Systems Interconnection - The Directory:
Authentication Framework Recommendation X.509 Authentication Framework Recommendation X.509
ISO/IEC 9594-8 ISO/IEC 9594-8
RFC xxxx Identity Representation for RSVP January 2000 12. Authors' Addresses
12. Author Information
Rodney Hess
Intel, BD1
28 Crosby Drive
Bedford, MA 01730
EMail: rodney.hess@intel.com
Satyendra Yadav Satyendra Yadav
Intel, JF3-206 Intel, JF3-206
2111 NE 25th Avenue 2111 NE 25th Avenue
Hillsboro, OR 97124 Hillsboro, OR 97124
EMail: 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
EMail: Raj.Yavatkar@intel.com EMail: Raj.Yavatkar@intel.com
Ramesh Pabbati Ramesh Pabbati
Microsoft Microsoft
1 Microsoft Way 1 Microsoft Way
skipping to change at page 17, line 5 skipping to change at page 17, line 32
EMail: 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
EMail: timmoore@microsoft.com EMail: timmoore@microsoft.com
RFC xxxx Identity Representation for RSVP January 2000
Shai Herzog Shai Herzog
IPHighway, Inc. PolicyConsulting.Com
55 New York Avenue 200 Clove Rd.
Framingham, MA 01701 New Rochelle, NY 10801
EMail: herzog@iphighway.com EMail: herzog@policyconsulting.com
Rodney Hess
Intel, BD1
28 Crosby Drive
Bedford, MA 01730
EMail: rodney.hess@intel.com
13. Full Copyright Statement 13. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2001). 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 are kind, provided that the above copyright notice and this paragraph 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
 End of changes. 111 change blocks. 
259 lines changed or deleted 241 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/