RSVP Identity: Identity Representation for RSVP
How RSVP messages carry a verifiable user or application identity so routers can apply policy to reservations.
Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., Herzog, S., and R. Hess, "Identity Representation for RSVP", RFC 3182, DOI 10.17487/RFC3182, October 2001, <https://www.rfc-editor.org/info/rfc3182>.
@misc{rfc3182,
series = {Request for Comments},
number = 3182,
howpublished = {RFC 3182},
publisher = {RFC Editor},
doi = {10.17487/RFC3182},
url = {https://www.rfc-editor.org/info/rfc3182},
author = {S. Yadav and R. Yavatkar and R. Pabbati and P. Ford and T. Moore and S. Herzog and R. Hess},
title = {{Identity Representation for RSVP}},
pagetotal = 18,
year = 2001,
month = oct,
} RFC text
Contents
Network Working Group S. Yadav
Request for Comments: 3182 R. Yavatkar
Obsoletes: 2752 Intel
Category: Standards Track R. Pabbati
P. Ford
T. Moore
Microsoft
S. Herzog
PolicyConsulting.Com
R. Hess
Intel
October 2001
Identity Representation for RSVP
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
This document describes the representation of identity information in
POLICY_DATA object for supporting policy based admission control in
the Resource ReSerVation Protocol (RSVP). The goal of identity
representation is to allow a process on a system to securely identify
the owner and the application of the communicating process (e.g.,
user id) and convey this information in RSVP messages (PATH or RESV)
in a secure manner. We describe the encoding of identities as RSVP
policy element. We describe the processing rules to generate
identity policy elements for multicast merged flows. Subsequently,
we describe representations of user identities for Kerberos and
Public Key based user authentication mechanisms. In summary, we
describe the use of this identity information in an operational
setting.
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
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC 2119].
2. Introduction
RSVP [RFC 2205] is a resource reservation setup protocol designed for
an integrated services Internet [RFC 1633]. RSVP is used by a host
to request specific quality of service (QoS) from the network for
particular application data streams or flows. RSVP is also used by
routers to deliver QoS requests to all nodes along the path(s) of the
flows and to establish and maintain state to provide the requested
service. RSVP requests will generally result in resources being
reserved in each node along the data path. RSVP allows particular
users to obtain preferential access to network resources, under the
control of an admission control mechanism. Permission to make a
reservation is based both upon the availability of the requested
resources along the path of the data and upon satisfaction of policy
rules. Providing policy based admission control mechanism based on
user identity or application is one of the prime requirements.
In order to solve these problems and implement identity based policy
control it is required to identify the user and/or application making
a RSVP request.
This document proposes a mechanism for sending identification
information in the RSVP messages and enables authorization decisions
based on policy and identity.
We describe the authentication policy element (AUTH_DATA) contained
in the POLICY_DATA object. User process can generate an AUTH_DATA
policy element and gives it to RSVP process (service) on the
originating host. RSVP service inserts AUTH_DATA into the RSVP
message to identify the owner (user and/or application) making the
request for network resources. Network elements, such as routers,
authenticate request using the credentials presented in the AUTH_DATA
and admit the RSVP message based on admission policy. After a
request has been authenticated, first hop router installs the RSVP
state and forwards the new policy element returned by the Policy
Decision Point (PDP) [POL-FRAME].
3. Policy Element for Authentication Data
3.1 Policy Data Object Format
POLICY_DATA objects contain policy information and are carried by
RSVP messages. A detail description of the format of POLICY_DATA
object can be found in "RSVP Extensions for Policy Control" [POL-
EXT].
3.2 Authentication Data Policy Element
In this section, we describe a policy element (PE) called
authentication data (AUTH_DATA). AUTH_DATA policy element contains a
list of authentication attributes.
+-------------+-------------+-------------+-------------+
| Length | P-Type = Identity Type |
+-------------+-------------+-------------+-------------+
// Authentication Attribute List //
+-------------------------------------------------------+
Length
The length of the policy element (including the Length and P-Type)
is in number of octets (MUST be a multiple of 4) and indicates the
end of the authentication attribute list.
P-Type (Identity Type)
Type of identity information contained in this Policy Element
supplied as the Policy element type (P-type). The Internet
Assigned Numbers Authority (IANA) acts as a registry for policy
element types for identity as described in the [POL-EXT].
Initially, the registry contains the following P-Types for
identity:
2 AUTH_USER Authentication scheme to identify users
3 AUTH_APP Authentication scheme to identify
applications
Authentication Attribute List
Authentication attributes contain information specific to
authentication method and type of AUTH_DATA. The policy element
provides the mechanism for grouping a collection of authentication
attributes.
3.3 Authentication Attributes
Authentication attributes MUST be encoded as a multiple of 4 octets,
attributes that are not a multiple of 4 octets long MUST be padded to
a 4-octet boundary.
+--------+--------+--------+--------+
| Length | A-Type |SubType |
+--------+--------+--------+--------+
| Value ...
+--------+--------+--------+--------+
Length
The length field is two octets and indicates the actual length of
the attribute (including the Length and A-Type fields) in number
of octets. The length does not include any bytes padding to the
value field to make the attribute multiple of 4 octets long.
A-Type
Authentication attribute type (A-Type) field is one octet. IANA
acts as a registry for A-Types as described in the section 8,
IANA Considerations. Initially, the registry contains the
following A-Types:
1 POLICY_LOCATOR Unique string for locating the
admission policy (such as X.500 DN
described in [RFC 1779]).
2 CREDENTIAL User credential such as Kerberos
ticket, or digital certificate.
Application credential such as
application ID.
3 DIGITAL_SIGNATURE Digital signature of the
authentication data policy element.
4 POLICY_ERROR_OBJECT Detailed information on policy
failures.
SubType
Authentication attribute sub-type field is one octet. Value of
SubType depends on A-type.
Value:
The value field contains the attribute specific information.
3.3.1 Policy Locator
POLICY_LOCATOR is used to locate the admission policy for the user or
application. Distinguished Name (DN) is unique for each User or
application hence a DN is used as policy locator.
+-------+-------+-------+-------+
| Length |A-Type |SubType|
+-------+-------+-------+-------+
| OctetString ...
+-------+-------+-------+--------
Length
Length of the attribute, which MUST be >= 4.
A-Type
POLICY_LOCATOR
SubType
Following sub types for POLICY_LOCATOR are defined. IANA acts as
a registry for POLICY_LOCATOR sub types as described in the
section 8, IANA Considerations. Initially, the registry contains
the following sub types for POLICY_LOCATOR:
1 ASCII_DN OctetString contains the X.500 DN as
described in the RFC 1779 as an ASCII
string.
2 UNICODE_DN OctetString contains the X.500 DN described
in the RFC 1779 as an UNICODE string.
3 ASCII_DN_ENCRYPT OctetString contains the encrypted X.500
DN. The Kerberos session key or digital
certificate private key is used for
encryption. For Kerberos encryption the
format is the same as returned from
gss_seal [RFC 1509].
4 UNICODE_DN_ENCRYPT OctetString contains the encrypted UNICODE
X.500 DN. The Kerberos session key or
digital certificate private key is used for
encryption. For Kerberos encryption the
format is the same as returned from
gss_seal [RFC 1509].
OctetString
The OctetString field contains the DN.
3.3.2 Credential
CREDENTIAL indicates the credential of the user or application to be
authenticated. For Kerberos authentication method the CREDENTIAL
object contains the Kerberos session ticket. For public key based
authentication this field contains a digital certificate.
A summary of the CREDENTIAL attribute format is shown below. The
fields are transmitted from left to right.
+-------+-------+-------+-------+
| Length |A-Type |SubType|
+-------+-------+-------+-------+
| OctetString ...
+-------+-------+-------+--------
Length
Length of the attribute, which MUST be >= 4.
A-Type
CREDENTIAL
SubType
IANA acts as a registry for CREDENTIAL sub types as described in
the section 8, IANA Considerations. Initially, the registry
contains the following sub types for CREDENTIAL:
1 ASCII_ID OctetString contains user or application
identification in plain ASCII text string.
2 UNICODE_ID OctetString contains user or application
identification in plain UNICODE text string.
3 KERBEROS_TKT OctetString contains Kerberos ticket.
4 X509_V3_CERT OctetString contains X.509 V3 digital
certificate [X.509].
5 PGP_CERT OctetString contains PGP digital certificate.
OctetString
The OctetString contains the user or application credential.
3.3.3 Digital Signature
The DIGITAL_SIGNATURE attribute MUST be the last attribute in the
attribute list and contains the digital signature of the AUTH_DATA
policy element. The digital signature signs all data in the
AUTH_DATA policy element up to the DIGITAL_SIGNATURE. The algorithm
used to compute the digital signature depends on the authentication
method specified by the CREDENTIAL SubType field.
A summary of DIGITAL_SIGNATURE attribute format is described below.
+-------+-------+-------+-------+
| Length |A-Type |SubType|
+-------+-------+-------+-------+
| OctetString ...
+-------+-------+-------+--------
Length
Length of the attribute, which MUST be >= 4.
A-Type
DIGITAL_SIGNATURE
SubType
No sub types for DIGITAL_SIGNATURE are currently defined. This
field MUST be set to 0.
OctetString
OctetString contains the digital signature of the AUTH_DATA.
3.3.4 Policy Error Object
This attribute is used to carry any specific policy control errors
generated by a node when processing/validating an Authentication Data
Policy Element. When a RSVP policy node (local policy decision point
or remote PDP) encounters a request that fails policy control due to
its Authentication Policy Element, it SHOULD add a POLICY_ERROR_CODE
containing additional information about the reason the failure
occurred into the policy element. This will then cause an
appropriate PATH_ERROR or RESV_ERROR message to be generated with the
policy element and appropriate RSVP error code in the message, which
is returned to the request's source.
The AUTH_DATA policy element in the PATH or RSVP message SHOULD not
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 | SubType |
+----------+----------+----------+----------+
| 0 (Reserved) | ErrorValue |
+----------+----------+----------+----------+
| OctetString ...
+----------+----------+----------+----------+
Length
Length of the attribute, which MUST be >= 8.
A-Type
POLICY_ERROR_CODE
SubType
No sub types for POLICY_ERROR_CODE are currently defined. This
field MUST be set to 0.
ErrorValue
A 16-bit bit code containing the reason that the policy decision
point failed to process the policy element. IANA acts as a
registry for ErrorValues as described in section 8, IANA
Considerations. Following values have been defined.
1 ERROR_NO_MORE_INFO No information is available.
2 UNSUPPORTED_CREDENTIAL_TYPE This type of credentials is
not supported.
3 INSUFFICIENT_PRIVILEGES The credentials do not have
sufficient privilege.
4 EXPIRED_CREDENTIAL The credential has expired.
5 IDENTITY_CHANGED Identity has changed.
OctetString
The OctetString field contains information from the policy
decision point that MAY contain additional information about the
policy failure. For example, it may include a human-readable
message in the ASCII text.
4. Authentication Data Formats
Authentication attributes are grouped in a policy element to
represent the identity credentials.
4.1 Simple User Authentication
In simple user authentication method the user login ID (in plain
ASCII or UNICODE text) is encoded as CREDENTIAL attribute. A summary
of the simple user AUTH_DATA policy element is shown below.
+--------------+--------------+--------------+--------------+
| Length | P-type = AUTH_USER |
+--------------+--------------+--------------+--------------+
| Length |POLICY_LOCATOR| SubType |
+--------------+--------------+--------------+--------------+
| OctetString (User's Distinguished Name) ...
+--------------+--------------+--------------+--------------+
| Length |CREDENTIAL | ASCII_ID |
+--------------+--------------+--------------+--------------+
| OctetString (User's login ID) ...
+--------------+--------------+--------------+--------------+
4.2 Kerberos User Authentication
Kerberos [RFC 1510] authentication uses a trusted third party (the
Kerberos Distribution Center - KDC) to provide for authentication of
the user to a network server. It is assumed that a KDC is present
and both host and verifier of authentication information (router or
PDP) implement Kerberos authentication.
A summary of the Kerberos AUTH_DATA policy element is shown below.
+--------------+--------------+--------------+--------------+
| Length | P-type = AUTH_USER |
+--------------+--------------+--------------+--------------+
| Length |POLICY_LOCATOR| SubType |
+--------------+--------------+--------------+--------------+
| OctetString (User's Distinguished Name) ...
+--------------+--------------+--------------+--------------+
| Length | CREDENTIAL | KERBEROS_TKT |
+--------------+--------------+--------------+--------------+
| OctetString (Kerberos Session Ticket) ...
+--------------+--------------+--------------+--------------+
4.2.1. Operational Setting using Kerberos Identities
An RSVP enabled host is configured to construct and insert AUTH_DATA
policy element into RSVP messages that designate use of the Kerberos
authentication method (KERBEROS_TKT). Upon RSVP session
initialization, the user application contacts the KDC to obtain a
Kerberos ticket for the next network node or its PDP. A router when
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
PDP or next network hop can be statically configured, learned via
DHCP or maintained in a directory service. The Kerberos ticket is
sent to the next network node (which may be a router or host) in a
RSVP message. The KDC is used to validate the ticket and
authentication the user sending RSVP message.
4.3 Public Key based User Authentication
In public key based user authentication method digital certificate is
encoded as user credentials. The digital signature is used for
authenticating the user. A summary of the public key user AUTH_DATA
policy element is shown below.
+--------------+--------------+--------------+--------------+
| Length | P-type = AUTH_USER |
+--------------+--------------+--------------+--------------+
| Length |POLICY_LOCATOR| SubType |
+--------------+--------------+--------------+--------------+
| OctetString (User's Distinguished Name) ...
+--------------+--------------+--------------+--------------+
| Length | CREDENTIAL | SubType |
+--------------+--------------+--------------+--------------+
| OctetString (User's Digital Certificate) ...
+--------------+--------------+--------------+--------------+
| Length |DIGITAL_SIGN. | 0 |
+--------------+--------------+--------------+--------------+
| OctetString (Digital signature) ...
+--------------+--------------+--------------+--------------+
4.3.1. Operational Setting for public key based authentication
Public key based authentication assumes following:
- RSVP service requestors have a pair of keys (private key and
public key).
- Private key is secured with the user.
- Public keys are stored in digital certificates and a trusted
party, certificate authority (CA) issues these digital
certificates.
- The verifier (PDP or router) has the ability to verify the
digital certificate.
RSVP requestor uses its private key to generate DIGITAL_SIGNATURE.
User Authenticators (router, PDP) use the user's public key (stored
in the digital certificate) to verify the signature and authenticate
the user.
4.4 Simple Application Authentication
The application authentication method encodes the application
identification such as an executable filename as plain ASCII or
UNICODE text.
+----------------+--------------+--------------+--------------+
| Length | P-type = AUTH_APP |
+----------------+--------------+--------------+--------------+
| Length |POLICY_LOCATOR| SubType |
+----------------+--------------+--------------+--------------+
| OctetString (Application Identity attributes in
| the form of a Distinguished Name) ...
+----------------+--------------+--------------+--------------+
| Length | CREDENTIAL | ASCII_ID |
+----------------+--------------+--------------+--------------+
| OctetString (Application Id, e.g., vic.exe)
+----------------+--------------+--------------+--------------+
5. Operation
+-----+ +-----+
| PDP |-------+ | PDP |
+-----+ | ................... +-----+
| : : |
+--------+ : Transit : +-------+
+----| Router |------: Network : -------| Router|--+
| +--------+ : : +-------+ |
| | :.................: | |
| | | |
Host A B C D
Figure 1: User and Application Authentication using AUTH_DATA PE
Network nodes (hosts/routers) generate AUTH_DATA policy elements,
contents of which are depend on the identity type used and the
authentication method used. These generally contain authentication
credentials (Kerberos ticket or digital certificate) and policy
locators (which can be the X.500 Distinguished Name of the user or
network node or application names). Network nodes generate AUTH_DATA
policy element containing the authentication identity when making the
RSVP request or forwarding a RSVP message.
Network nodes generate user AUTH_DATA policy element using the
following rules:
1. For unicast sessions the user policy locator is copied from the
previous hop. The authentication credentials are for the current
network node identity.
2. For multicast messages the user policy locator is for the current
network node identity. The authentication credentials are for the
current network node.
Network nodes generate application AUTH_DATA policy element using the
following rules:
1. For unicast sessions the application AUTH_DATA is copied from the
previous hop.
2. For multicast messages the application AUTH_DATA is either the
first application AUTH_DATA in the message or chosen by the PDP.
6. Message Processing Rules
6.1 Message Generation (RSVP Host)
An RSVP message is created as specified in [RFC 2205] with following
modifications.
1. RSVP message MAY contain multiple AUTH_DATA policy elements.
2. Authentication policy element (AUTH_DATA) is created and the
IdentityType field is set to indicate the identity type in the
policy element.
- DN is inserted as POLICY_LOCATOR attribute.
- Credentials such as Kerberos ticket or digital certificate are
inserted as the CREDENTIAL attribute.
3. POLICY_DATA object (containing the AUTH_DATA policy element) is
inserted in the RSVP message in appropriate place. If INTEGRITY
object is not computed for the RSVP message then an INTEGRITY
object SHOULD be computed for this POLICY_DATA object, as
described in the [POL_EXT], and SHOULD be inserted as a Policy
Data option.
6.2 Message Reception (Router)
RSVP message is processed as specified in [RFC 2205] with following
modifications.
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
then it ignores the policy data objects and continues processing
the RSVP message.
2. Reject the message if the response from the PDP is negative.
3. Continue processing the RSVP message.
6.3 Authentication (Router/PDP)
1. Retrieve the AUTH_DATA policy element. Check the PE type field
and return an error if the identity type is not supported.
2. Verify user credential
- Simple authentication: e.g., Get user ID and validate it, or
get executable name and validate it.
- Kerberos: Send the Kerberos ticket to the KDC to obtain the
session key. Using the session key authenticate the user.
- Public Key: Validate the certificate that it was issued by a
trusted Certificate Authority (CA) and authenticate the user or
application by verifying the digital signature.
7. Error Signaling
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 values are described in [RFC 2205] and [POL-EXT]. Also PDP
SHOULD supply a policy data object containing an AUTH_DATA Policy
Element with A-Type=POLICY_ERROR_CODE containing more details on the
Policy Control failure (see section 3.3.4). The PEP will include
this Policy Data object in the outgoing RSVP Error message.
8. IANA Considerations
Following the policies outlined in [IANA-CONSIDERATIONS], Standard
RSVP Policy Elements (P-type values) are assigned by IETF Consensus
action as described in [POL-EXT].
P-Type AUTH_USER is assigned the value 2. P-Type AUTH_APP is
assigned the value 3.
Following the policies outlined in [IANA-CONSIDERATIONS],
authentication attribute types (A-Type) in the range 0-127 are
allocated through an IETF Consensus action, A-Type values between
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
assigned the value 2. A-Type DIGITAL_SIGNATURE is assigned the value
3. A-Type POLICY_ERROR_OBJECT is assigned the value 4.
Following the policies outlined in [IANA-CONSIDERATIONS],
POLICY_LOCATOR SubType values in the range 0-127 are allocated
through an IETF Consensus action, POLICY_LOCATOR SubType values
between 128-255 are reserved for Private Use and are not assigned by
IANA.
POLICY_LOCATOR SubType ASCII_DN is assigned the value 1, SubType
UNICODE_DN is assigned the value 2, SubType ASCII_DN_ENCRYPT is
assigned the value 3 and SubType UNICODE_DN_ENCRYPT is assigned the
value 4.
Following the policies outlined in [IANA-CONSIDERATIONS], CREDENTIAL
SubType values in the range 0-127 are allocated through an IETF
Consensus action, CREDENTIAL SubType values between 128-255 are
reserved for Private Use and are not assigned by IANA.
CREDENTIAL SubType ASCII_ID is assigned the value 1, SubType
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
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
The purpose of this memo is to describe a mechanism to authenticate
RSVP requests based on user identity in a secure manner. RSVP
INTEGRITY object is used to protect the policy object containing user
identity information from security (replay) attacks. Combining the
AUTH_DATA policy element and the INTEGRITY object results in a secure
access control that enforces authentication based on both the
identity of the user and the identity of the originating node.
Simple authentication does not contain credential that can be
securely authenticated and is inherently less secured.
The Kerberos authentication mechanism is reasonably well secured.
User authentication using a public key certificate is known to
provide the strongest security.
10. Acknowledgments
We would like to thank Andrew Smith, Bob Lindell and many others for
their valuable comments on this memo.
11. References
[ASCII] Coded Character Set -- 7-Bit American Standard
Code for Information Interchange, ANSI X3.4-
1986.
[IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for
Writing an IANA Considerations Section in
RFCs", BCP 26, RFC 2434, October 1998.
[POL-EXT] Herzog, S., "RSVP Extensions for Policy
Control", RFC 2750, January 2000.
[POL-FRAME] Yavatkar, R., Pendarakis, D. and R. Guerin, "A
Framework for Policy-based Admission Control
RSVP", RFC 2753, January 2000.
[RFC 1510] Kohl, J. and C. Neuman, "The Kerberos Network
Authentication Service (V5)", RFC 1510,
September 1993.
[RFC 1704] Haller, N. and R. Atkinson, "On Internet
Authentication", RFC 1704, October 1994.
[RFC 1779] Killie, S., "A String Representation of
Distinguished Names", RFC 1779, March 1995.
[RFC 2205] Braden, R., Zhang, L., Berson, S., Herzog, S.
and S. Jamin, "Resource ReSerVation Protocol
(RSVP) - Version 1 Functional Specification",
RFC 2205, September 1997.
[RFC 2209] Braden, R. and L. Zhang, "Resource ReSerVation
Protocol (RSVP) - Version 1 Message Processing
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,
Version 2.0", Addison-Wesley, Reading, MA,
1996.
[X.509] Housley, R., Ford, W., Polk, W. and D. Solo,
"Internet X.509 Public Key Infrastructure
Certificate and CRL Profile", RFC 2459, January
1999.
[X.509-ITU] ITU-T (formerly CCITT) Information technology -
Open Systems Interconnection - The Directory:
Authentication Framework Recommendation X.509
ISO/IEC 9594-8
12. Authors' Addresses
Satyendra Yadav
Intel, JF3-206
2111 NE 25th Avenue
Hillsboro, OR 97124
EMail: Satyendra.Yadav@intel.com
Raj Yavatkar
Intel, JF3-206
2111 NE 25th Avenue
Hillsboro, OR 97124
EMail: Raj.Yavatkar@intel.com
Ramesh Pabbati
Microsoft
1 Microsoft Way
Redmond, WA 98054
EMail: rameshpa@microsoft.com
Peter Ford
Microsoft
1 Microsoft Way
Redmond, WA 98054
EMail: peterf@microsoft.com
Tim Moore
Microsoft
1 Microsoft Way
Redmond, WA 98054
EMail: timmoore@microsoft.com
Shai Herzog
PolicyConsulting.Com
200 Clove Rd.
New Rochelle, NY 10801
EMail: herzog@policyconsulting.com
Rodney Hess
Intel, BD1
28 Crosby Drive
Bedford, MA 01730
EMail: rodney.hess@intel.com
13. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
ISO Plain Language
On this page
§2Why RSVP Needs an Identity
RSVP (RFC 2205) is a resource reservation setup protocol designed for an integrated services Internet. It is used by a host to request a specific quality of service from the network for particular application data streams or flows, and by routers to deliver QoS requests to all nodes along the path of the flows and to establish and maintain state to provide the requested service. RSVP requests generally result in resources being reserved in each node along the data path.
RSVP allows particular users to obtain preferential access to network resources under the control of an admission control mechanism. Permission to make a reservation is based both upon the availability of the requested resources along the path of the data and upon satisfaction of policy rules. Providing a policy-based admission control mechanism based on user identity or application is, the RFC says, one of the prime requirements. To solve these problems and implement identity-based policy control, it is required to identify the user or application making an RSVP request.
The document therefore proposes a mechanism for sending identification information in the RSVP messages, which enables authorization decisions based on policy and identity. It describes the authentication policy element, AUTH_DATA, contained in the POLICY_DATA object. A user process can generate an AUTH_DATA policy element and give it to the RSVP service on the originating host, and the RSVP service inserts it into the RSVP message to identify the owner, the user or application, making the request for network resources.
Network elements such as routers authenticate the request using the credentials presented in the AUTH_DATA and admit the RSVP message based on admission policy. After a request has been authenticated, the first hop router installs the RSVP state and forwards the new policy element returned by the Policy Decision Point described in RFC 2753. The RFC's abstract also records that it corrects an RSVP POLICY_DATA P-Type codepoint assignment error and a field size definition error in ErrorValue in RFC 2752.
RSVP is the protocol a host uses to ask the network for a guaranteed quality of service on a data stream. The network checks policy before it grants the reservation, and the policy is usually about the user or the application making the request. This RFC defines how that identity travels in the RSVP message and how a router can check it.
§3The AUTH_DATA Policy Element
POLICY_DATA objects contain policy information and are carried by RSVP messages; the format is described in "RSVP Extensions for Policy Control" (RFC 2750). The policy element defined here is the authentication data element, AUTH_DATA, which contains a list of authentication attributes.
The element has a Length, a P-Type and the attribute list. The Length is the length of the policy element, including the Length and P-Type fields, in octets, and it MUST be a multiple of 4; it indicates the end of the authentication attribute list. The P-Type, the Identity Type, is the type of identity information in the element, supplied as the policy element type. IANA acts as a registry for policy element types for identity, and initially the registry holds P-Type 2, AUTH_USER, an authentication scheme to identify users, and P-Type 3, AUTH_APP, an authentication scheme to identify applications.
Each authentication attribute carries information specific to the authentication method and the type of AUTH_DATA. The attribute is encoded as a multiple of 4 octets, and attributes that are not a multiple of 4 octets long MUST be padded to a 4-octet boundary. An attribute has a two-octet Length, a one-octet A-Type, a one-octet SubType and a Value. The Length indicates the actual length of the attribute, including the Length and A-Type fields, in octets, and does not include any padding bytes added to make the attribute a multiple of 4 octets long. The SubType depends on the A-Type.
IANA acts as a registry for A-Types, and initially the registry holds four. A-Type 1, POLICY_LOCATOR, is a unique string for locating the admission policy, such as an X.500 Distinguished Name. A-Type 2, CREDENTIAL, is a user credential such as a Kerberos ticket or a digital certificate, or an application credential such as an application ID. A-Type 3, DIGITAL_SIGNATURE, is a digital signature of the authentication data policy element. A-Type 4, POLICY_ERROR_OBJECT, carries detailed information on policy failures.
Each of the four has its own format. POLICY_LOCATOR holds an OctetString containing the Distinguished Name, and its SubType selects how that name is written: ASCII_DN, UNICODE_DN, ASCII_DN_ENCRYPT or UNICODE_DN_ENCRYPT. The two encrypted forms use the Kerberos session key or the digital certificate private key for encryption, and for Kerberos encryption the format is the same as returned from gss_seal in RFC 1509. The Length of a POLICY_LOCATOR attribute MUST be at least 4.
CREDENTIAL holds the credential itself. Its SubType values are ASCII_ID for a plain ASCII user or application identification, UNICODE_ID for the same in UNICODE, KERBEROS_TKT for a Kerberos ticket, X509_V3_CERT for an X.509 V3 digital certificate, and PGP_CERT for a PGP digital certificate. The Length of a CREDENTIAL attribute MUST be at least 4.
The DIGITAL_SIGNATURE attribute MUST be the last attribute in the list and holds the digital signature of the AUTH_DATA policy element, signing all the data in the element up to the DIGITAL_SIGNATURE. The algorithm used depends on the authentication method specified by the CREDENTIAL SubType. No sub-types are defined for it, so the SubType field MUST be set to 0, and its Length MUST be at least 4.
The POLICY_ERROR_CODE attribute is used to carry policy control errors generated by a node when processing or validating an authentication data policy element. When a policy node, whether a local policy decision point or a remote one, encounters a request that fails policy control due to its authentication policy element, it SHOULD add a POLICY_ERROR_CODE with more information about the reason into the policy element. That then causes an appropriate PATH_ERROR or RESV_ERROR message to be generated with the policy element and the appropriate RSVP error code, returned to the request's source. The AUTH_DATA policy element in a PATH or RESV message SHOULD NOT contain this attribute; it is inserted only into the error messages generated by policy-aware intermediate nodes. Its Length MUST be at least 8, its SubType MUST be set to 0, and its ErrorValue is a 16-bit code giving the reason the policy decision point failed to process the element.
The identity is carried in a policy element called AUTH_DATA inside the POLICY_DATA object of the RSVP message. It has a length, a type number saying whether it describes a user or an application, and a list of attributes. Each attribute has its own length, a type number and a sub-type number, followed by the value, and the whole thing is padded to a multiple of four bytes so that everything lines up.
| Field | Name | Size | Value | Description |
|---|---|---|---|---|
LENGTH | Length | 4 bytes | Length of the policy element in octets; must be a multiple of 4. | |
P-TYPE | P-Type | 4 bytes | Identity type: 2 for AUTH_USER, 3 for AUTH_APP. | |
ATTRIBUTE-LIST | Authentication Attribute List | 4 bytes | The attributes, each padded to a 4-octet boundary. |
| Field | Name | Size | Value | Description |
|---|---|---|---|---|
LENGTH | Length | 2 bytes | Length of the attribute in octets, excluding padding. | |
A-TYPE | A-Type | 1 byte | Attribute type: 1 POLICY_LOCATOR, 2 CREDENTIAL, 3 DIGITAL_SIGNATURE, 4 POLICY_ERROR_OBJECT. | |
SUB-TYPE | SubType | 1 byte | Meaning depends on the A-Type; 0 where no sub-type is defined. | |
VALUE | Value | 1 byte | The attribute-specific information. |
- 1POLICY_LOCATOR — A unique string locating the admission policy, such as an X.500 Distinguished Name.
- 2CREDENTIAL — A user credential such as a Kerberos ticket or digital certificate, or an application ID.
- 3DIGITAL_SIGNATURE — Signature of the AUTH_DATA element; must be the last attribute in the list.
- 4POLICY_ERROR_OBJECT — Detailed information on policy failures.
§4Four Ways to Fill It In
Section 4 of the RFC groups authentication attributes into a policy element to represent the identity credentials, and gives four concrete arrangements.
Simple user authentication encodes the user login ID, in plain ASCII or UNICODE text, as the CREDENTIAL attribute, alongside a POLICY_LOCATOR holding the user's Distinguished Name.
Kerberos user authentication uses Kerberos (RFC 1510), which uses a trusted third party, the Kerberos Distribution Center, to authenticate the user to a network server. It assumes a KDC is present and that both the host and the verifier of the authentication information, a router or a policy decision point, implement Kerberos. The CREDENTIAL attribute holds the Kerberos session ticket instead of a login ID.
The operational setting is described in Section 4.2.1. An RSVP-enabled host is configured to construct and insert an AUTH_DATA policy element into RSVP messages that designate the use of the Kerberos authentication method, KERBEROS_TKT. Upon RSVP session initialization the user application contacts the KDC to obtain a Kerberos ticket for the next network node or its policy decision point. A router generating an RSVP message contacts the KDC to obtain a Kerberos ticket for the next hop network node or its policy decision point. The identity of the policy decision point or next network hop can be statically configured, learned via DHCP or maintained in a directory service. The ticket is sent to the next network node in the RSVP message, and the KDC is used to validate the ticket and authenticate the user sending the message.
Public key based user authentication encodes a digital certificate as the user credential, and uses a digital signature to authenticate the user. It assumes that the RSVP service requestors have a pair of keys, a private key and a public key; that the private key is secured with the user; that the public keys are stored in digital certificates issued by a trusted party, the certificate authority; and that the verifier, a policy decision point or router, can verify the digital certificate. The requestor uses its private key to generate the DIGITAL_SIGNATURE, and the authenticators use the user's public key, stored in the digital certificate, to verify the signature and authenticate the user.
Simple application authentication encodes the application identification, such as an executable filename, as plain ASCII or UNICODE text, and uses P-Type AUTH_APP.
Four ways of filling it in are described. The simplest puts the login name in plain text. Kerberos puts a session ticket in. Public key puts a digital certificate and a signature in. And for an application, the identity can simply be the name of the program making the request.
- 1ASCII_ID — User or application identification in plain ASCII text.
- 2UNICODE_ID — User or application identification in UNICODE text.
- 3KERBEROS_TKT — Kerberos ticket.
- 4X509_V3_CERT — X.509 V3 digital certificate.
- 5PGP_CERT — PGP digital certificate.
§5Who Generates What
Section 5 of the RFC shows a network of hosts and routers between two policy decision points, and then gives the rules for generating the policy elements.
Network nodes, hosts or routers, generate AUTH_DATA policy elements whose contents depend on the identity type used and the authentication method used. These generally contain authentication credentials, such as a Kerberos ticket or a digital certificate, and policy locators, which can be the X.500 Distinguished Name of the user or network node, or application names. A node generates the AUTH_DATA policy element containing the authentication identity when making the RSVP request or forwarding an RSVP message.
For a user AUTH_DATA policy element the rules are these. For unicast sessions the user policy locator is copied from the previous hop, and the authentication credentials are for the current network node identity. For multicast messages the user policy locator is for the current network node identity, and the authentication credentials are for the current network node.
For an application AUTH_DATA policy element the rules are these. For unicast sessions the application AUTH_DATA is copied from the previous hop. For multicast messages the application AUTH_DATA is either the first application AUTH_DATA in the message or chosen by the policy decision point.
Every node that forwards an RSVP message generates an AUTH_DATA element for itself. For a one-to-one session the user identity is copied from the previous hop but the credentials are for the current node. For a multicast session both are for the current node.
§6Message Generation, Reception and Authentication
Section 6.1 covers message generation at the RSVP host. The RSVP message is created as specified in RFC 2205 with three modifications. The message MAY contain multiple AUTH_DATA policy elements. An authentication policy element is created and the IdentityType field is set to indicate the identity type in the policy element, with the Distinguished Name inserted as the POLICY_LOCATOR attribute and credentials such as a Kerberos ticket or digital certificate inserted as the CREDENTIAL attribute. The POLICY_DATA object containing the AUTH_DATA policy element is inserted in the RSVP message in the appropriate place, and if an INTEGRITY object is not computed for the RSVP message then an INTEGRITY object SHOULD be computed for the POLICY_DATA object, as described in RFC 2750, and inserted as a Policy Data option.
Section 6.2 covers message reception at the router, again with three modifications. If the router is not policy aware, it SHOULD send the RSVP message to the policy decision point and wait for a response; if the router is policy unaware, it ignores the policy data objects and continues processing the RSVP message. The message is rejected if the response from the policy decision point is negative. Processing of the RSVP message then continues.
Section 6.3 covers the authentication performed by the router or policy decision point. The AUTH_DATA policy element is retrieved, and the PE type field is checked, returning an error if the identity type is not supported. The user credential is then verified, in one of three ways. With simple authentication, the user ID is obtained and validated, or the executable name is obtained and validated. With Kerberos, the ticket is sent to the KDC to obtain the session key, and the session key is used to authenticate the user. With public key, the certificate is checked to see that it was issued by a trusted certificate authority, and the user or application is authenticated by verifying the digital signature.
The host builds the element and puts it in the RSVP message. A router that is not policy aware hands the message to the policy decision point and waits; a router that ignores policy data carries on without it. The verifier then checks the credentials, using the Kerberos key distribution centre, the certificate authority, or a simple name check.
§7Error Signalling
If the policy decision point fails to verify the AUTH_DATA policy element, it MUST return a policy control failure, error code 02, to the policy enforcement point. The error values are described in RFC 2205 and RFC 2750. The policy decision point SHOULD also supply a policy data object containing an AUTH_DATA policy element with A-Type POLICY_ERROR_CODE giving more details on the failure, and the policy enforcement point will include that policy data object in the outgoing RSVP error message.
The five ErrorValues are the ones the RFC registers. ERROR_NO_MORE_INFO, value 1, means no information is available. UNSUPPORTED_CREDENTIAL_TYPE, value 2, means this type of credentials is not supported. INSUFFICIENT_PRIVILEGES, value 3, means the credentials do not have sufficient privilege. EXPIRED_CREDENTIAL, value 4, means the credential has expired. IDENTITY_CHANGED, value 5, means the identity has changed.
When the check fails, the policy decision point returns a policy control failure and may add a short explanation, which the router passes back to the host in the error message. Five error values are defined, from no more information through to identity changed.
- 1ERROR_NO_MORE_INFO — No information is available.
- 2UNSUPPORTED_CREDENTIAL_TYPE — This type of credentials is not supported.
- 3INSUFFICIENT_PRIVILEGES — The credentials do not have sufficient privilege.
- 4EXPIRED_CREDENTIAL — The credential has expired.
- 5IDENTITY_CHANGED — Identity has changed.
§8IANA Registries
Standard RSVP policy elements, the P-Type values, are assigned by IETF Consensus action as described in RFC 2750. P-Type AUTH_USER is assigned the value 2 and P-Type AUTH_APP the value 3.
Authentication attribute types, the A-Type values, in the range 0 to 127 are allocated through an IETF Consensus action, and A-Type values between 128 and 255 are reserved for private use and are not assigned by IANA. A-Type POLICY_LOCATOR is assigned the value 1, CREDENTIAL the value 2, DIGITAL_SIGNATURE the value 3 and POLICY_ERROR_OBJECT the value 4.
The same rule applies to the POLICY_LOCATOR SubType values: 0 to 127 by IETF Consensus action, 128 to 255 reserved for private use. POLICY_LOCATOR SubType ASCII_DN is assigned the value 1, UNICODE_DN the value 2, ASCII_DN_ENCRYPT the value 3 and UNICODE_DN_ENCRYPT the value 4.
The CREDENTIAL SubType values follow the same pattern. CREDENTIAL SubType ASCII_ID is assigned the value 1, UNICODE_ID the value 2, KERBEROS_TKT the value 3, X509_V3_CERT the value 4 and PGP_CERT the value 5.
ErrorValues in the range 0 to 32767 are allocated through an IETF Consensus action, and ErrorValues between 32768 and 65535 are reserved for private use and are not assigned by IANA. ERROR_NO_MORE_INFO is assigned the value 1, UNSUPPORTED_CREDENTIAL_TYPE the value 2, INSUFFICIENT_PRIVILEGES the value 3, EXPIRED_CREDENTIAL the value 4 and IDENTITY_CHANGED the value 5.
IANA holds the registries for the type numbers, the attribute types and the error values, and the RFC lists the values assigned by this document. The ranges 128 to 255 of the attribute and sub-type registries are left for private use.
§9Security Considerations
The purpose of the memo is to describe a mechanism to authenticate RSVP requests based on user identity in a secure manner. The RSVP INTEGRITY object is used to protect the policy object containing the user identity information from security, replay, attacks. Combining the AUTH_DATA policy element and the INTEGRITY object results in a secure access control that enforces authentication based on both the identity of the user and the identity of the originating node.
The RFC then compares the three authentication methods. Simple authentication does not contain a credential that can be securely authenticated and is inherently less secured. The Kerberos authentication mechanism is reasonably well secured. User authentication using a public key certificate is known to provide the strongest security.
The RSVP INTEGRITY object protects the policy object holding the identity, so a captured message cannot be replayed. Combining it with AUTH_DATA gives an access control that checks both the user and the node that sent the request. The RFC ranks the three methods: a plain name is the weakest, Kerberos is reasonably well secured, and a public key certificate is the strongest.