draft-ietf-rap-rsvp-identity-02.txt   draft-ietf-rap-rsvp-identity-03.txt 
Internet Draft Satyendra Yadav Internet Draft Satyendra Yadav
File: <draft-ietf-rap-rsvp-identity-02.txt> Raj Yavatkar Expiration: August 1999 Raj Yavatkar
Intel File: draft-ietf-rap-rsvp-identity-03.txt Intel
Ramesh Pabbati Ramesh Pabbati
Peter Ford Peter Ford
Tim Moore Tim Moore
Microsoft Microsoft
Shai Herzog Shai Herzog
IPHighway IPHighway
Identity Representation for RSVP Identity Representation for RSVP
January 1999 February 1999
Status of this Memo Status of this Memo
This document is an Internet Draft. Internet Drafts are working This document is an Internet-Draft and is in full conformance with
documents of the Internet Engineering Task Force (IETF), its Areas, all provisions of Section 10 of RFC2026.
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 Internet-Drafts are working documents of the Internet Engineering
months. Internet Drafts may be updated, replaced, or obsoleted by Task Force (IETF), its areas, and its working groups. Note that
other documents at any time. It is not appropriate to use Internet other groups may also distribute working documents as Internet-
Drafts as reference material or to cite them other than as a Drafts.
"working draft" or "work in progress".
To view the list Internet-Draft Shadow Directories, see Internet-Drafts are draft documents valid for a maximum of six
http://www.ietf.org/shadow.html. months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
A Revised Version of this draft document will be submitted to the The list of current Internet-Drafts can be accessed at
RFC editor as a Proposed Standard for the Internet Community. http://www.ietf.org/ietf/1id-abstracts.txt
Discussion and suggestions for improvement are requested. This
document will expire in July 1999. Distribution of this draft is The list of Internet-Draft Shadow Directories can be accessed at
unlimited. http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved. Copyright (C) The Internet Society (1999). All Rights Reserved.
1. Abstract 1. Abstract
This document describes the representation of identity information This document describes the representation of identity information
in POLICY_DATA object [POL-EXT] for supporting policy based in POLICY_DATA object [POL-EXT] for supporting policy based
admission control in RSVP. The goal of identity representation is to admission control in RSVP. The goal of identity representation is to
allow a process on a system to securely identify the owner and the allow a 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 of user identities for Kerberos and Public Key based representations of user identities for Kerberos and Public Key based
user authentication mechanisms. In summary we describe the use of user authentication mechanisms. In summary we describe the use of
this identity information in an operational setting. this identity information in an operational setting.
Yadav, et al. 1
2. Conventions used in this document 2. 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 document are to be interpreted as described in [RFC-2119]. this document are to be interpreted as described in [RFC-2119].
3. Introduction 3. Introduction
RSVP [RFC 2205] is a resource reservation setup protocol designed RSVP [RFC 2205] is a resource reservation setup protocol designed
for an integrated services Internet [RFC 1633]. RSVP is used by a for an integrated services Internet [RFC 1633]. RSVP is used by a
skipping to change at line 79 skipping to change at line 81
requested service. RSVP requests will generally result in resources requested service. RSVP requests will generally result in resources
being reserved in each node along the data path. RSVP allows being reserved in each node along the data path. RSVP allows
particular users to obtain preferential access to network resources, particular users to obtain preferential access to network resources,
under the control of an admission control mechanism. Permission to under the control of an admission control mechanism. Permission to
make a reservation is based both upon the availability of the make a reservation is based both upon the availability of the
requested resources along the path of the data and upon satisfaction requested resources along the path of the data and upon satisfaction
of policy rules. Providing policy based admission control mechanism of policy rules. Providing policy based admission control mechanism
based on user identity or application is one of the prime based on user identity or application is one of the prime
requirements. requirements.
In order to solve these problems and implement user based policy In order to solve these problems and implement identity based policy
control it is required to identify the user making an RSVP request. control it is required to identify the user and/or application making
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 of the user requesting resources from based on policy and identity.
the network.
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 generates 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) making the request for network message to identify the owner (user and/or application) making the
resources. Network elements, such as routers, authenticate user request for network resources. Network elements, such as routers,
using the credentials presented in the AUTH_DATA and admit the RSVP authenticate request using the credentials presented in the AUTH_DATA
message based on admission policy. After a request has been and admit the RSVP message based on admission policy. After a request
authenticated, first hop router installs the RSVP state and forwards has been authenticated, first hop router installs the RSVP state and
the new policy element returned by the Policy Decision Point (PDP) forwards the new policy element returned by the Policy Decision Point
[POL-FRAME]. (PDP) [POL-FRAME].
Yadav, et al. 2
4. Policy Element for Authentication Data 4. Policy Element for Authentication Data
4.1 Policy Data Object Format 4.1 Policy Data Object Format
POLICY_DATA objects contain policy information and are carried by POLICY_DATA objects contain policy information and are carried by
RSVP messages. A detail description of the format of POLICY_DATA RSVP messages. A detail description of the format of POLICY_DATA
object can be found in "RSVP Extensions for Policy Control" [POL- object can be found in "RSVP Extensions for Policy Control" [POL-
EXT]. EXT].
4.2 Authentication Data Policy Element 4.2 Authentication Data Policy Element
In this section, we describe a policy element (PE) called In this section, we describe a policy element (PE) called
authentication data (AUTH_DATA). AUTH_DATA policy element contains a authentication data (AUTH_DATA). AUTH_DATA policy element contains a
list of authentication attributes. Policy object containing list of authentication attributes.
AUTH_DATA must be protected against replay attacks using INTEGRITY
object option as described in the [POL-EXT].
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| 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) is in number of octets (must be a multiple of 4) and Type) is in number of octets (must be a multiple of 4) and
indicates the end of the authentication attribute list. indicates the end of the authentication attribute list.
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 Assigned Numbers Authority (IANA) acts as a registry for policy
identity types as described in the section 10, IANA element types for identity as described in the [POL-EXT].
Considerations. Initially, the registry contains the following Initially, the registry contains the following P-Types for
identity types: 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
Reserved
Must be set to 0.
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
4.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 a 4-octet boundary. to 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 the attribute (including the Length and A-Type fields) in of the attribute (including the Length and A-Type fields) in
number of octets. The length does not include any bytes padding number of octets. The length does not include any bytes padding
the attribute to make it multiple of 4 octets long. to the 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 10, 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]).
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
skipping to change at line 194 skipping to change at line 196
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 0-65351 octets. The value field contains the attribute specific information.
Yadav, et al. 4
4.3.1 Policy Locator 4.3.1 Policy Locator
POLICY_LOCATOR is used to locate the admission policy for the user POLICY_LOCATOR is used to locate the admission policy for the user
or application. Distinguished Name (DN) is unique for each 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 ...
+-------+-------+-------+-------- +-------+-------+-------+--------
Length Length
> 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 10, IANA Considerations. Initially, the registry section 9, IANA Considerations. Initially, the registry contains
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 described
in the RFC 1779 as an ASCII string. in the RFC 1779 as an ASCII string.
2 UNICODE_DN OctetString contains the X.500 DN described in 2 UNICODE_DN OctetString contains the X.500 DN described in
the RFC 1779 as an UNICODE string. the RFC 1779 as an UNICODE string.
3 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 encryption.
For Kerberos encryption the format is the same For Kerberos encryption the format is the same
as returned from gss_seal [RFC 1509]. as returned from gss_seal [RFC 1509].
skipping to change at line 242 skipping to change at line 246
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
4.3.2 Credential 4.3.2 Credential
CREDENTIAL indicates the credential of the user or application to be CREDENTIAL indicates the credential of the user or application to be
authenticated. For Kerberos authentication method the CREDENTIAL authenticated. For Kerberos authentication method the CREDENTIAL
object contains the Kerberos session ticket. For public key based object contains the Kerberos session ticket. For public key based
authentication this field contains a digital certificate. authentication this field contains a digital certificate.
A summary of the CREDENTIAL attribute format is shown below. The A summary of the CREDENTIAL attribute format is shown below. The
fields are transmitted from left to right. fields are transmitted from left to right.
+-------+-------+-------+-------+ +-------+-------+-------+-------+
| Length |A-Type |SubType| | Length |A-Type |SubType|
+-------+-------+-------+-------+ +-------+-------+-------+-------+
| OctetString | OctetString ...
+-------+-------+-------+-------- +-------+-------+-------+--------
Length Length
> 4 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 10, IANA Considerations. Initially, the registry the section 9, 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.
skipping to change at line 294 skipping to change at line 300
4.3.3 Digital Signature 4.3.3 Digital Signature
The DIGITAL_SIGNATURE attribute must be the last attribute in the The DIGITAL_SIGNATURE attribute must be the last attribute in the
attribute list and contains the digital signature of the AUTH_DATA attribute list and contains the digital signature of the AUTH_DATA
policy element. The digital signature signs all data in the policy element. The digital signature signs all data in the
AUTH_DATA policy element up to the DIGITAL_SIGNATURE. The algorithm AUTH_DATA policy element up to the DIGITAL_SIGNATURE. The algorithm
used to compute the digital signature depends on the authentication used to compute the digital signature depends on the authentication
method specified by the CREDENTIAL SubType field. method specified by the CREDENTIAL SubType field.
Yadav, et al. 6
A summary of DIGITAL_SIGNATURE attribute format is described below. A summary of DIGITAL_SIGNATURE attribute format is described below.
+-------+-------+-------+-------+ +-------+-------+-------+-------+
| Length |A-Type |SubType| | Length |A-Type |SubType|
+-------+-------+-------+-------+ +-------+-------+-------+-------+
| OctetString | OctetString ...
+-------+-------+-------+-------- +-------+-------+-------+--------
Length Length
> 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.
skipping to change at line 327 skipping to change at line 334
This attribute is used to specify any errors associated with the This attribute is used to specify any errors associated with the
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 may add a POLICY_ERROR_CODE its Authentication Policy Element, it may 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 PATH_ERROR or RESV_ERROR message to be generated with appropriate PATH_ERROR or RESV_ERROR message to be generated with
the policy element and appropriate RSVP error code in the message, the policy element and appropriate RSVP error code in the message,
which is returned to the request's source. which is returned to the request's source.
The AUTH DATA policy element in the PATH or RSVP message does not The AUTH_DATA policy element in the PATH or RSVP message should not
contain the POLICY_ERROR_OBJECT attribute. contain the POLICY_ERROR_OBJECT attribute. These are only inserted
into PATH_ERROR and RESV_ERROR messages when generated by policy
aware intermediate nodes.
+-------+-------+-------+-------+ +----------+----------+----------+----------+
| Length |A-Type | 0 | | Length | A-Type |SubType(0)|
+-------+-------+-------+-------+ +----------+----------+----------+----------+
| 0 (Reserved) |Error value | | 0 (Reserved) | ErrorValue |
+-------+-------+-------+-------+ +----------+----------+----------+----------+
| OctetString | OctetString ...
+-------+-------+-------+-------- +----------+----------+----------+----------+
Yadav, et al. 7
Length Length
>= 8 Length of the attribute, which must be >= 8.
A-Type A-Type
POLICY_ERROR_CODE POLICY_ERROR_CODE
Error Value Error Value
A 32-bit bit code containing the reason that the policy A 32-bit bit code containing the reason that the policy decision
decision point failed to process the policy element. The point failed to process the policy element. Following values
standard values are have been defined.
ERROR_NO_MORE_INFO 1 no information is available 1 ERROR_NO_MORE_INFO No information is available.
UNKNOWN_CREDENTIAL 2 the credentials are unknown
NO_PRIVILEGES 3 the credential has no privilege
EXPIRED_CREDENTIAL 4 the credential has expired
IDENTITY_CHANGED 5 identity has changed
OctetString 2 UNSUPPORTED_CREDENTIAL_TYPE This type of credentials are
The OctetString field contains information from the policy not supported.
decision point that may contain additional information about
the failure. For example
"MSFT", DEF_SUBNET FLOW_RATE, CONTROLLED LOAD, 10000, 10000, 3 INSUFFICIENT_PRIVILEGES The credentials do not have
1000, 0, 0, 1000, 1000 sufficient privilege.
This example contains an identification string for the policy 4 EXPIRED_CREDENTIAL The credential has expired.
decision point, more information about why the policy decision
point failed. In this case, the subnet default policy on Token 5 IDENTITY_CHANGED Identity has changed.
bucket rate failed and the flow spec that caused the failure is
also returned. OctetString
The OctetString field contains information from the policy
decision point that may, optionally, contain additional
information about the policy failure. For example, it may
include a human-readable message in the ASCII text.
5. Authentication Data Formats 5. 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 5.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
5.2 Kerberos User Authentication 5.2 Kerberos User Authentication
Kerberos [RFC 1510] authentication uses a trusted third party (the Kerberos [RFC 1510] authentication uses a trusted third party (the
Kerberos Distribution Center KDC) to provide for authentication of Kerberos Distribution Center - KDC) to provide for authentication of
the user to a network server. It is assumed that a KDC is present the user to a network server. It is assumed that a KDC is present
and both host and verifier of authentication information (router or and both host and verifier of authentication information (router or
PDP) 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) ...
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
5.2.1. Operational Setting using Kerberos Identities 5.2.1. Operational Setting using Kerberos Identities
An RSVP enabled host is configured to construct and insert AUTH_DATA An RSVP enabled host is configured to construct and insert AUTH_DATA
policy element into RSVP messages that designate use of the Kerberos policy element into RSVP messages that designate use of the Kerberos
authentication method (KERBEROS_TKT). Upon RSVP session authentication method (KERBEROS_TKT). Upon RSVP session
initialization, the user application contacts the KDC to obtain a initialization, the user application contacts the KDC to obtain a
Kerberos ticket for the next network node or its 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
5.3 Public Key based User Authentication 5.3 Public Key based User Authentication
In public key based user authentication method digital certificate In public key based user authentication method digital certificate
is encoded as user credentials. The digital signature is used for is encoded as user credentials. The digital signature is used for
authenticating the user. A summary of the public key user AUTH_DATA authenticating the user. A summary of the public key user AUTH_DATA
policy element is shown below. policy element is shown below.
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| 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 5.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.
skipping to change at line 473 skipping to change at line 485
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
5.4 Simple Application Authentication 5.4 Simple Application Authentication
The application authentication method encodes the application The application authentication method encodes the application
identification such as an executable filename as plain ASCII or identification such as an executable filename as plain ASCII or
UNICODE text. UNICODE text.
+----------------+--------------+--------------+--------------+ +----------------+--------------+--------------+--------------+
| Length | P-type = AUTH_APP | | Length | P-type = AUTH_APP |
+----------------+--------------+--------------+--------------+ +----------------+--------------+--------------+--------------+
| Length |POLICY_LOCATOR| SubType | | Length |POLICY_LOCATOR| SubType |
+----------------+--------------+--------------+--------------+ +----------------+--------------+--------------+--------------+
| OctetString (Application Distinguished Name) | OctetString (Application Identity attributes in the form of
| a Distinguished Name) ...
+----------------+--------------+--------------+--------------+ +----------------+--------------+--------------+--------------+
| Length | CREDENTIAL | ASCII_ID | | Length | CREDENTIAL | ASCII_ID |
+----------------+--------------+--------------+--------------+ +----------------+--------------+--------------+--------------+
| OctetString (Application Id ex: vic.exe) | OctetString (Application Id, e.g., vic.exe)
+----------------+--------------+--------------+--------------+ +----------------+--------------+--------------+--------------+
6. Operation 6. Operation
+-----+ +-----+ +-----+ +-----+
| PDP |-------+ | PDP | | PDP |-------+ | PDP |
+-----+ | .. +-----+ +-----+ | ................... +-----+
| : : | | : : |
+--------+ : Transit : +-------+ +--------+ : Transit : +-------+
+----| 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 depends on the identity type used and the contents of which are depend on the identity type used and the
authentication method used. But generally contains 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
RSVP request or forwarding an RSVP message. the RSVP request or forwarding an RSVP message.
Network nodes generate user AUTH_DATA policy element using the Network nodes generate user AUTH_DATA policy element using the
following rules following rules
1. For unicast sessions the user policy locator is the copied from 1. For unicast sessions the user policy locator is copied from
the previous hop. The authentication credentials are for the the previous hop. The authentication credentials are for the
current network node identity. current network node identity.
Yadav, et al. 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
following rules: the following rules:
1. For unicast sessions the application AUTH_DATA is the copied from 1. For unicast sessions the application AUTH_DATA is the copied from
the previous hop. the previous hop.
2. For multicast messages the application AUTH_DATA is either the 2. For multicast messages the application AUTH_DATA is either the
first application AUTH_DATA in the message or chosen by the PDP. first application AUTH_DATA in the message or chosen by the PDP.
7. Message Processing Rules 7. Message Processing Rules
7.1 Message Generation (RSVP Host) 7.1 Message Generation (RSVP Host)
skipping to change at line 552 skipping to change at line 569
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 must be computed for this POLICY_DATA object, as described object must be computed for this POLICY_DATA object, as described
in the [POL_EXT], and must be inserted as an Policy Data option. in the [POL_EXT], and must be inserted as a Policy Data option.
7.2 Message Reception (Router) 7.2 Message Reception (Router)
RSVP message is processed as specified in [RFC2205] with following RSVP message is processed as specified in [RFC2205] with following
modifications. modifications.
1. If router is not policy aware then it should send the RSVP 1. If router is not policy aware then it should send the RSVP
message to the PDP and wait for response. If the router is policy message to the PDP and wait for response. If the router is policy
unaware then it ignores the policy data objects and continues unaware then it ignores the policy data objects and continues
processing the RSVP message. processing 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
7.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 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 - Simple authentication: e.g. Get user ID and validate it, or
get executable name and validate it. get executable name and validate it.
skipping to change at line 594 skipping to change at line 613
- Public Key: Validate the certificate that it was issued by a - Public Key: Validate the certificate that it was issued by a
trusted Certificate Authority (CA) and authenticate the user trusted Certificate Authority (CA) and authenticate the user
or application by verifying the digital signature. or application by verifying the digital signature.
8. Error Signaling 8. 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 PEP. The error return Policy control failure (Error Code = 02) to PEP. The error
values are described in [RFC 2205] and [POL-EXT]. Also PDP must values are described in [RFC 2205] and [POL-EXT]. Also PDP must
supply a policy data object containing the AUTH DATA Policy Element supply a policy data object containing the AUTH_DATA Policy Element
with more details on the Policy Control failures in the policy error with more details on the Policy Control failures in the policy error
object attribute. The PEP will include this Policy Data object in object attribute. The PEP will include this Policy Data object in
the outgoing RSVP Error message. the outgoing RSVP Error message.
9. IANA Considerations 9. 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 an IETF Consensus action, A-Type values between 128-255 allocated an IETF Consensus action, A-Type values between 128-255
are reserved for Private Use and are not assigned by IANA. are reserved for Private Use and are not assigned by IANA.
skipping to change at line 616 skipping to change at line 635
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 an POLICY_LOCATOR SubType values in the range 0-127 are allocated an
IETF Consensus action, POLICY_LOCATOR SubType values between 128-255 IETF Consensus action, POLICY_LOCATOR SubType values between 128-255
are reserved for Private Use and are not assigned by IANA. 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],
CREDENTIAL SubType values in the range 0-127 are allocated an IETF CREDENTIAL SubType values in the range 0-127 are allocated 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.
Yadav, et al. 13
10. Security Considerations 10. Security Considerations
The purpose of this draft is to describe a mechanism to authenticate The purpose of this draft 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 identity information from security (replay) attacks. Combining user identity information from security (replay) attacks. Combining
the AUTH_DATA policy element and the INTEGRITY object results in a the AUTH_DATA policy element and the INTEGRITY object results in a
secure access control that enforces authentication based on both the secure 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.
skipping to change at line 639 skipping to change at line 660
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 11. 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 draft.
Yadav, et al. 14
12. References 12. References
[ASCII] Coded Character Set -- 7-Bit American Standard Code for [ASCII] Coded Character Set -- 7-Bit American Standard Code for
Information Interchange, ANSI X3.4-1986. Information Interchange, ANSI X3.4-1986.
[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 RFCs", BCP 26,
RFC 2434, October 1998. RFC 2434, October 1998.
[POL-EXT] Herzog, S., "RSVP Extensions for Policy Control." [POL-EXT] Herzog, S., "RSVP Extensions for Policy Control."
Internet-Draft, draft-ietf-rap-policy-ext-02.txt, Internet-Draft, draft-ietf-rap-policy-ext-03.txt,
January 1999. February 1999.
[POL-FRAME] Yavatkar, R., et.al. "A Framework for Policy-based [POL-FRAME] Yavatkar, R., et.al. "A Framework for Policy-based
Admission Control RSVP." Internet-Draft, draft-ietf-rap- Admission Control RSVP." Internet-Draft, draft-ietf-rap-
framework-01.txt, November 1998. framework-01.txt, November 1998.
[RFC 1510] The Kerberos Network Authentication Service (V5). Kohl [RFC 1510] The Kerberos Network Authentication Service (V5). Kohl
J., Neuman, C. RFC 1510. J., Neuman, C. RFC 1510.
[RFC 1704] On Internet Authentication. Haller, N, Atkinson, R., [RFC 1704] On Internet Authentication. Haller, N, Atkinson, R.,
RFC 1704. RFC 1704.
[RFC 1779] A String Representation of Distinguished Names. S. [RFC 1779] A String Representation of Distinguished Names. S.
Kille. RFC 1779 Kille. RFC 1779
[RFC 2205] Braden, R., et. al., "Resource ReSerVation Protocol [RFC 2205] Braden, R., et. al., "Resource ReSerVation Protocol
(RSVP) Version 1 Functional Specification." RFC 2205. (RSVP) - Version 1 Functional Specification." RFC 2205.
[RFC 2209] Braden, R., Zhang, L., "Resource ReSerVation Protocol [RFC 2209] Braden, R., Zhang, L., "Resource ReSerVation Protocol
(RSVP) - Version 1 Message Processing Rules." RFC 2209. (RSVP) - Version 1 Message Processing Rules." RFC 2209.
[UNICODE] The Unicode Consortium, "The Unicode Standard, Version [UNICODE] The Unicode Consortium, "The Unicode Standard, Version
2.0", Addison-Wesley, Reading, MA, 1996. 2.0", Addison-Wesley, Reading, MA, 1996.
[X.509] R. Housley, et. al., "Internet X.509 Public Key [X.509] R. Housley, et. al., "Internet X.509 Public Key
Infrastructure Certificate and CRL Profile", Internet- Infrastructure Certificate and CRL Profile", Internet-
Draft, draft-ietf-pkix-ipki-part1-11.txt, September Draft, draft-ietf-pkix-ipki-part1-11.txt, September
1998. 1998.
[X.509-ITU] ITU-T (formerly CCITT) Information technology Open [X.509-ITU] ITU-T (formerly CCITT) Information technology - Open
Systems Interconnection The Directory: Authentication Systems Interconnection - The Directory: Authentication
Framework Recommendation X.509 ISO/IEC 9594-8 Framework Recommendation X.509 ISO/IEC 9594-8
Yadav, et al. 15
13. Author Information 13. Author Information
Satyendra Yadav Satyendra Yadav
Intel, JF3-206 Intel, JF3-206
2111 NE 25th Avenue 2111 NE 25th Avenue
Hillsboro, OR 97124 Hillsboro, OR 97124
Satyendra.Yadav@intel.com Satyendra.Yadav@intel.com
Raj Yavatkar Raj Yavatkar
skipping to change at line 727 skipping to change at line 752
timmoore@microsoft.com timmoore@microsoft.com
Shai Herzog Shai Herzog
IPHighway IPHighway
2055 Gateway Pl., Suite 400 2055 Gateway Pl., Suite 400
San Jose, CA 95110 San Jose, CA 95110
herzog@iphighway.com herzog@iphighway.com
Yadav, et al. 16
14. Full Copyright Statement 14. Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved. Copyright (C) The Internet Society (1999). 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 included on all such copies and derivative works. However, this are included on all such copies and derivative works. However, this
skipping to change at line 755 skipping to change at line 782
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. 3 Yadav, et al. 17
Yadav, et al. 1
 End of changes. 

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