draft-ietf-rap-rsvp-better-identity-00.txt   draft-ietf-rap-rsvp-better-identity-01.txt 
RAP Working Group R. Hess, Ed. RAP Working Group R. Hess, Ed.
Internet-Draft S. Yadav Internet-Draft S. Yadav
Obsoletes: 2752 R. Yavatkar Obsoletes: 2752 R. Yavatkar
Expires December 2001 Intel Expires January 2002 Intel
R. Pabbati R. Pabbati
P. Ford P. Ford
T. Moore T. Moore
Microsoft Microsoft
S. Herzog S. Herzog
IPHighway IPHighway
June 2001 July 2001
Identity Representation for RSVP Identity Representation for RSVP
draft-ietf-rap-rsvp-better-identity-00.txt draft-ietf-rap-rsvp-better-identity-01.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026. Internet-Drafts are working documents of of Section 10 of RFC2026. Internet-Drafts are working documents of
the Internet Engineering Task Force (IETF), its areas, and its the Internet Engineering Task Force (IETF), its areas, and its
working groups. Note that other groups may also distribute working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
skipping to change at page 1, line 39 skipping to change at page 1, line 39
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
The distribution of this memo is unlimited. This memo is filed as The distribution of this memo is unlimited. This memo is filed as
<draft-ietf-rap-rsvp-better-identity-00.txt> and expires December 31, <draft-ietf-rap-rsvp-better-identity-01.txt> and expires January 31,
2001. Please send comments to the author. 2002. Please send comments to the author.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract Abstract
This document describes the representation of identity information in This document describes the representation of identity information in
POLICY_DATA objects [POL-EXT] for supporting policy based admission POLICY_DATA objects [POL-EXT] for supporting policy based admission
control in RSVP. The goal of identity representation is to allow a control in RSVP [RFC 2205]. The goal of identity representation is
process on a system to securely identify the owner and the 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 application of the communicating process (e.g. user id) and to convey
this information in RSVP messages (PATH or RESV) in a secure manner. this information in RSVP PATH or RESV messages in a secure manner.
We describe the encoding of identities as a RSVP policy element. We We describe the encoding of identities as a 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 authentication mechanisms. In summary we describe the use of this
this identity information in an operational setting. identity information in an operational setting.
This memo updates the Security Considerations Section to correctly
reflect how various security issues are addressed.
1. Conventions used in this document 1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC-2119]. document are to be interpreted as described in [RFC 2119].
2. Introduction 2. Introduction
RSVP [RFC 2205] is a resource reservation setup protocol designed for RSVP [RFC 2205] is a resource reservation protocol designed for an
an integrated services Internet [RFC 1633]. RSVP is used by a host to integrated services Internet [RFC 1633]. A host uses RSVP to request
request specific quality of service (QoS) from the network for a specific quality of service (QoS) from the network for a particular
particular application data streams or flows. RSVP is also used by application's data flows. RSVP is also used by routers to deliver
routers to deliver QoS requests to all nodes along the path(s) of the QoS requests to all nodes along the path(s) of the flows and to
flows and to establish and maintain state to provide the requested establish and maintain state in order to provide the requested
service. RSVP requests will generally result in resources being service. RSVP requests will generally result in resources being
reserved in each node along the data path. RSVP allows particular reserved in each node along the data path. RSVP allows particular
users to obtain preferential access to network resources, under the users to obtain preferential access to network resources, under the
control of an admission control mechanism. Permission to make a control of an admission control mechanism. Permission to make a
reservation is based both upon the availability of the requested reservation is based both upon the availability of the requested
resources along the path of the data and upon satisfaction of policy resources along the data path and upon satisfaction of policy rules.
rules. Providing policy based admission control mechanism based on Providing policy based admission control mechanism based on user or
user identity or application is one of the prime requirements. application identity is one of the primary requirements of RSVP.
In order to solve these problems and implement identity based policy In order to solve these problems and implement identity based policy
control it is required to identify the user and/or application making control it is necessary to identify the user or application making
a RSVP request. the 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 an RSVP message, thereby enabling authorization
based on policy and identity. decisions to be based on policy and identity.
We describe the authentication policy element (AUTH_DATA) contained We describe the authentication policy element (AUTH_DATA) contained
in the POLICY_DATA object. User process can generate an AUTH_DATA in a POLICY_DATA object [POL-EXT]. A user process generates an
policy element and gives it to RSVP process (service) on the AUTH_DATA policy element and hands it off to a policy aware RSVP
originating host. RSVP service inserts AUTH_DATA into the RSVP service on the originating host. The RSVP service encapsulates the
message to identify the owner (user and/or application) making the AUTH_DATA policy element into a POLICY_DATA object. It then inserts
request for network resources. Network elements, such as routers, this object into the RSVP PATH or RESV message to permit
authenticate request using the credentials presented in the AUTH_DATA identification of the owner (e.g. user or application) making the
and admit the RSVP message based on admission policy. After a request request for network resources. Policy aware RSVP systems, also
has been authenticated, first hop router installs the RSVP state and referred to by this memo as Policy Enforcement Points (PEPs), forward
forwards the new policy element returned by the Policy Decision Point the policy elements to their Policy Decision Points (PDPs) [POL-FRAME].
(PDP) [POL-FRAME].
Each PDP along the data path authenticates the request using the
credentials present in the AUTH_DATA policy element. The PDP makes
an admission policy decision along with other policy decisions as
warranted by policy configuration. The admit or deny decision is
returned to the PEP, who either installs the necessary RSVP state or
rejects the RSVP request. Furthermore, with an admit decision, the
PDP also returns to the PEP a new policy element list in which exists
a new AUTH_DATA policy element amongst other possible policy elements.
This new AUTH_DATA contains the identity credentials of this PDP for
authentication by the next PDP in the data path. The PEP forwards
the RSVP message with the new policy elements to the next RSVP hop.
In this manner, network resources can be allocated or reserved based
on policy and identity.
3. Policy Element for Authentication Data 3. Policy Element for Authentication Data
3.1 Policy Data Object Format 3.1. Policy Data Object Format
POLICY_DATA objects contain policy information and are carried by POLICY_DATA objects contain policy information and are carried by
RSVP messages. A detail description of the format of POLICY_DATA RSVP messages. A detail description of the format of the POLICY_DATA
object can be found in "RSVP Extensions for Policy Control" [POL- object can be found in "RSVP Extensions for Policy Control" [POL-
EXT]. EXT].
3.2 Authentication Data Policy Element 3.2. Authentication Data Policy Element
In this section, we describe a policy element (PE) called In this section, we describe a policy element (PE) called
authentication data (AUTH_DATA). AUTH_DATA policy element contains a authentication data (AUTH_DATA). AUTH_DATA policy elements contain a
list of authentication attributes. list of authentication attributes.
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Length | P-Type = Identity Type | | Length | P-Type = Identity Type |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| |
// Authentication Attribute List // // Authentication Attribute List //
+-------------------------------------------------------+ | |
+-------------+-------------+-------------+-------------+
Length: 16 bits
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 fields) 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.
P-Type (Identity Type) P-Type (Identity Type): 16 bits
Type of identity information contained in this Policy Element Type of identity information contained in this Policy Element
supplied as the Policy element type (P-type). The Internet supplied as the Policy Element Type (P-Type). The Internet
Assigned Numbers Authority (IANA) acts as a registry for policy Assigned Numbers Authority (IANA) acts as a registry for Policy
element types for identity as described in the [POL-EXT]. Element Types for identity as described in the [POL-EXT].
Initially, the registry contains the following P-Types for Initially, the registry contains the following P-Types for
identity: identity:
2 AUTH_USER Authentication scheme to identify users 2 AUTH_USER Authentication scheme to identify users
3 AUTH_APP Authentication scheme to identify 3 AUTH_APP Authentication scheme to identify
applications applications
Authentication Attribute List Authentication Attribute List: Variable length
Authentication attributes contain information specific to Authentication attributes contain information specific to the
authentication method and type of AUTH_DATA. The policy element authentication method and the type of AUTH_DATA. The policy
provides the mechanism for grouping a collection of element definition [POL-EXT] provides the mechanism for grouping
authentication attributes. a collection of authentication attributes.
3.3 Authentication Attributes 3.3. Authentication Attributes
Authentication attributes MUST be encoded as a multiple of 4 octets, Authentication attributes MUST be encoded as a multiple of 4 octets;
attributes that are not a multiple of 4 octets long MUST be padded to attributes that are not a multiple of 4 octets long MUST be padded to
a 4-octet boundary. a 4-octet boundary.
+--------+--------+--------+--------+ +-------------+-------------+-------------+-------------+
| Length | A-Type |SubType | | Length | A-Type |SubType |
+--------+--------+--------+--------+ +-------------+-------------+-------------+-------------+
| Value ... | |
+--------+--------+--------+--------+ // Value //
| |
+-------------+-------------+-------------+-------------+
Length Length: 16 bits
The length field is two octets and indicates the actual length of
the attribute (including the Length and A-Type fields) in number The length field indicates the actual length of the attribute
of octets. The length does not include any bytes padding to the (including the Length and A-Type fields) in number of octets.
value field to make the attribute multiple of 4 octets long. The length does not include any octet padding to the Value field
to make the attribute a multiple of 4 octets long.
A-Type: 8 bits
A-Type
Authentication attribute type (A-Type) field is one octet. IANA Authentication attribute type (A-Type) field is one octet. IANA
acts as a registry for A-Types as described in the section 9, acts as a registry for A-Types as described in the section 9,
IANA Considerations. Initially, the registry contains the IANA Considerations. Initially, the registry contains the
following A-Types: following A-Types:
1 POLICY_LOCATOR Unique string for locating the 1 POLICY_LOCATOR Unique string for locating the
admission policy (such as X.500 DN admission policy (such as X.500 DN
described in [RFC 1779]). described in [RFC 1779]).
2 CREDENTIAL User credential such as Kerberos 2 CREDENTIAL User credential such as a Kerberos
ticket, or digital certificate. ticket, or a digital certificate.
Application credential such as Application credential such as an
application ID. application ID.
3 DIGITAL_SIGNATURE Digital signature of the 3 DIGITAL_SIGNATURE Digital signature of the
authentication data policy element. authentication data policy element.
4 POLICY_ERROR_OBJECT Detailed information on policy 4 POLICY_ERROR_OBJECT Detailed information on policy
failures. failures.
SubType SubType: 8 bits
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: Variable length
The value field contains the attribute specific information. The value field contains the attribute specific information.
3.3.1 Policy Locator 3.3.1. POLICY_LOCATOR A-Type
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 for the policy locator.
+-------+-------+-------+-------+ +-------------+-------------+-------------+-------------+
| Length |A-Type |SubType| | Length |A-Type |SubType|
+-------+-------+-------+-------+ +-------------+-------------+-------------+-------------+
| OctetString ... | |
+-------+-------+-------+-------- // OctetSting //
| |
+-------------+-------------+-------------+-------------+
Length: 16 bits
Length
Length of the attribute, which MUST be >= 4. Length of the attribute, which MUST be >= 4.
A-Type A-Type: 8 bits
POLICY_LOCATOR
SubType This field MUST contain the value POLICY_LOCATOR.
Following sub types for POLICY_LOCATOR are defined. IANA acts as
a registry for POLICY_LOCATOR sub types as described in the
section 9, IANA Considerations. Initially, the registry contains
the following sub types for POLICY_LOCATOR:
1 ASCII_DN OctetString contains the X.500 DN as described SubType: 8 bits
in the RFC 1779 as an ASCII string.
2 UNICODE_DN OctetString contains the X.500 DN described in The following SubTypes for POLICY_LOCATOR are defined. IANA acts
the RFC 1779 as an UNICODE string. As a registry for POLICY_LOCATOR SubTypes as described in Section
9, IANA Considerations. Initially, the registry contains
the following SubTypes 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 3 ASCII_DN_ENCRYPT OctetString contains the encrypted X.500
DN. The Kerberos session key or digital DN. The Kerberos session key or digital
certificate private key is used for encryption. certificate private key is used for
For Kerberos encryption the format is the same encryption. For Kerberos encryption the
as returned from gss_seal [RFC 1509]. format is the same as returned from
gss_seal [RFC 1509].
4 UNICODE_DN_ENCRYPT OctetString contains the encrypted 4 UNICODE_DN_ENCRYPT OctetString contains the encrypted
UNICODE X.500 DN. The Kerberos session key or UNICODE X.500 DN. The Kerberos session
digital certificate private key is used for key or digital certificate private key
encryption. For Kerberos encryption the format is used for encryption. For Kerberos
is the same as returned from gss_seal [RFC encryption the format is the same as
1509]. returned from gss_seal [RFC 1509].
OctetString: Variable length
OctetString
The OctetString field contains the DN. The OctetString field contains the DN.
3.3.2 Credential 3.3.2. CREDENTIAL A-Type
CREDENTIAL indicates the credential of the user or application to be CREDENTIAL indicates the credentials 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 ... | |
+-------+-------+-------+-------- // OctetSting //
| |
+-------------+-------------+-------------+-------------+
Length: 16 bits
Length
Length of the attribute, which MUST be >= 4. Length of the attribute, which MUST be >= 4.
A-Type A-Type: 8 bits
CREDENTIAL
SubType This field MUST contain the value CREDENTIAL.
IANA acts as a registry for CREDENTIAL sub types as described in
the section 9, IANA Considerations. Initially, the registry SubType: 8 bits
contains the following sub types for CREDENTIAL:
IANA acts as a registry for CREDENTIAL SubTypes as described in
Section 9, IANA Considerations. Initially, the registry contains
the following SubTypes 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 a 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 a plain UNICODE text string.
3 KERBEROS_TKT OctetString contains Kerberos ticket. 3 KERBEROS_TKT OctetString contains a Kerberos ticket.
4 X509_V3_CERT OctetString contains X.509 V3 digital 4 X509_V3_CERT OctetString contains a X.509 V3 digital
certificate [X.509]. certificate [X.509].
5 PGP_CERT OctetString contains PGP digital certificate. 5 PGP_CERT OctetString contains a PGP digital
certificate.
OctetString OctetString: Variable length
The OctetString contains the user or application credential.
3.3.3 Digital Signature The OctetString contains the user or application credentials.
3.3.3. DIGITAL_SIGNATURE A-Type
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, but not including, the
used to compute the digital signature depends on the authentication DIGITAL_SIGNATURE. The algorithm used to compute the digital
method specified by the CREDENTIAL SubType field. signature depends on the authentication method specified by the
CREDENTIAL SubType field.
A summary of DIGITAL_SIGNATURE attribute format is described below. A summary of DIGITAL_SIGNATURE attribute format is described below.
+-------+-------+-------+-------+ +-------------+-------------+-------------+-------------+
| Length |A-Type |SubType| | Length |A-Type |SubType|
+-------+-------+-------+-------+ +-------------+-------------+-------------+-------------+
| OctetString ... | |
+-------+-------+-------+-------- // OctetSting //
| |
+-------------+-------------+-------------+-------------+
Length: 16 bits
Length
Length of the attribute, which MUST be >= 4. Length of the attribute, which MUST be >= 4.
A-Type A-Type: 8 bits
DIGITAL_SIGNATURE
SubType This field MUST contain the value DIGITAL_SIGNATURE.
No sub types for DIGITAL_SIGNATURE are currently defined. This
SubType: 8 bits
No SubTypes for DIGITAL_SIGNATURE are currently defined. This
field MUST be set to 0. field MUST be set to 0.
OctetString OctetString: Variable length
OctetString contains the digital signature of the AUTH_DATA. OctetString contains the digital signature of the AUTH_DATA.
3.3.4 Policy Error Object 3.3.4. POLICY_ERROR_CODE A-Type
This attribute is used to carry any specific policy control errors This attribute is used to carry any specific policy control errors
generated by a node when processing/validating an Authentication Data generated by a node when processing/validating an Authentication Data
Policy Element. When a RSVP policy node (local policy decision point Policy Element. When a RSVP policy node (local policy decision point
or remote PDP) encounters a request that fails policy control due to or remote PDP) encounters a request that fails policy control due to
its Authentication Policy Element, it SHOULD add a POLICY_ERROR_CODE its Authentication Policy Element, it SHOULD add a POLICY_ERROR_CODE
containing additional information about the reason the failure containing additional information about the reason the failure
occurred into the policy element. This will then cause an appropriate occurred into the policy element. This will then cause an appropriate
PATH_ERROR or RESV_ERROR message to be generated with the policy PATH_ERROR or RESV_ERROR message to be generated with the policy
element and appropriate RSVP error code in the message, which is element and appropriate RSVP error code in the message, which is
returned to the request's source. returned to the request's source.
The AUTH_DATA policy element in the PATH or RSVP message SHOULD not The AUTH_DATA policy element in a PATH or RSVP message SHOULD NOT
contain the POLICY_ERROR_OBJECT attribute. These are only inserted contain the POLICY_ERROR_OBJECT attribute. These are only inserted
into PATH_ERROR and RESV_ERROR messages when generated by policy into PATH_ERROR and RESV_ERROR messages when generated by policy
aware intermediate nodes. aware intermediate nodes.
+----------+----------+----------+----------+ +-------------+-------------+-------------+-------------+
| Length | A-Type | SubType | | Length | A-Type | SubType |
+----------+----------+----------+----------+ +-------------+-------------+-------------+-------------+
| 0 (Reserved) | ErrorValue | | Reserved (0) | ErrorValue |
+----------+----------+----------+----------+ +-------------+-------------+-------------+-------------+
| OctetString ... | |
+----------+----------+----------+----------+ // OctetSting //
| |
+-------------+-------------+-------------+-------------+
Length: 16 bits
Length
Length of the attribute, which MUST be >= 8. Length of the attribute, which MUST be >= 8.
A-Type A-Type: 8 bits
POLICY_ERROR_CODE
SubType This field MUST contain the value POLICY_ERROR_CODE
No sub types for POLICY_ERROR_CODE are currently defined. This
SubType: 8 bits
No SubTypes for POLICY_ERROR_CODE are currently defined. This
field MUST be set to 0. field MUST be set to 0.
ErrorValue Reserved: 16 bits
A 32-bit bit code containing the reason that the policy decision
point failed to process the policy element. Following values have This field MUST be set to 0.
been defined.
ErrorValue: 16 bits
A 16-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 9, IANA
Considerations. The following values have been defined.
1 ERROR_NO_MORE_INFO No information is available. 1 ERROR_NO_MORE_INFO No information is available.
2 UNSUPPORTED_CREDENTIAL_TYPE This type of credentials is 2 UNSUPPORTED_CREDENTIAL_TYPE This type of credentials is
not supported. not supported.
3 INSUFFICIENT_PRIVILEGES The credentials do not have 3 INSUFFICIENT_PRIVILEGES The credentials do not have
sufficient privilege. sufficient privilege.
4 EXPIRED_CREDENTIAL The credential has expired. 4 EXPIRED_CREDENTIAL The credential has expired.
5 IDENTITY_CHANGED Identity has changed. 5 IDENTITY_CHANGED Identity has changed.
skipping to change at page 8, line 44 skipping to change at page 9, line 24
2 UNSUPPORTED_CREDENTIAL_TYPE This type of credentials is 2 UNSUPPORTED_CREDENTIAL_TYPE This type of credentials is
not supported. not supported.
3 INSUFFICIENT_PRIVILEGES The credentials do not have 3 INSUFFICIENT_PRIVILEGES The credentials do not have
sufficient privilege. sufficient privilege.
4 EXPIRED_CREDENTIAL The credential has expired. 4 EXPIRED_CREDENTIAL The credential has expired.
5 IDENTITY_CHANGED Identity has changed. 5 IDENTITY_CHANGED Identity has changed.
OctetString OctetString: Variable length
The OctetString field contains information from the policy
decision point that MAY contain additional information about the The OctetString field contains information from the Policy
policy failure. For example, it may include a human-readable Decision Point that MAY contain additional information about the
policy failure. For example, it may include a human readable
message in the ASCII text. message in the ASCII text.
4. Authentication Data Formats 4. Authentication Data Formats
Authentication attributes are grouped in a policy element to Authentication attributes are grouped together in a policy element to
represent the identity credentials. represent the identity credentials.
4.1 Simple User Authentication 4.1. Simple User Authentication
In simple user authentication method the user login ID (in plain In the simple user authentication method, the user's login ID, in
ASCII or UNICODE text) is encoded as CREDENTIAL attribute. A summary either plain ASCII or UNICODE text, is encoded as a CREDENTIAL
of the simple user AUTH_DATA policy element is shown below. attribute. A summary 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) ... | |
+--------------+--------------+--------------+--------------+ // OctetSting (User's Distinguished Name) //
| |
+-------------+-------------+--------------+-------------+
| Length |CREDENTIAL | ASCII_ID | | Length |CREDENTIAL | ASCII_ID |
+--------------+--------------+--------------+--------------+ +-------------+-------------+--------------+-------------+
| OctetString (User's login ID) ... | |
+--------------+--------------+--------------+--------------+ // OctetSting (User's login ID) //
| |
+-------------+-------------+--------------+-------------+
4.2 Kerberos User Authentication 4.2. Kerberos User Authentication
Kerberos [RFC 1510] authentication uses a trusted third party (the Kerberos [RFC 1510] authentication utilizes a trusted third party,
Kerberos Distribution Center - KDC) to provide for authentication of the Kerberos Distribution Center (KDC), to provide for authentication
the user to a network server. It is assumed that a KDC is present and of the user to a policy aware network element. For this method of
both host and verifier of authentication information (router or PDP) authentication to work, a KDC must be present, and both the host and
implement Kerberos authentication. the policy aware network element (re: PDP) implement the Kerberos
authentication protocol.
A summary of the Kerberos AUTH_DATA policy element is shown below. An example of a user 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) ... | |
+--------------+--------------+--------------+--------------+ // OctetSting (User's Distinguished Name) //
| |
+-------------+-------------+--------------+-------------+
| Length | CREDENTIAL | KERBEROS_TKT | | Length | CREDENTIAL | KERBEROS_TKT |
+--------------+--------------+--------------+--------------+ +-------------+-------------+--------------+-------------+
| OctetString (Kerberos Session Ticket) ... | |
+--------------+--------------+--------------+--------------+ // OctetSting (Kerberos Session Ticket) //
| |
+-------------+-------------+--------------+-------------+
4.2.1. Operational Setting using Kerberos Identities 4.2.1. Operational Setting using Kerberos Identities
An RSVP enabled host is configured to construct and insert AUTH_DATA A policy aware RSVP enabled host is configured to construct and
policy element into RSVP messages that designate use of the Kerberos insert AUTH_DATA policy objects into RSVP messages that designate use
authentication method (KERBEROS_TKT). Upon RSVP session of the Kerberos authentication method (KERBEROS_TKT). Upon a RSVP
initialization, the user application contacts the KDC to obtain a session initialization, the initiating application, be it a user
Kerberos ticket for the next network node or its PDP. A router when and/or an application, contacts the KDC to obtain a Kerberos ticket
generating a RSVP message contacts the KDC to obtain a Kerberos for the next policy aware RSVP system or its PDP on the data path.
ticket for the next hop network node or its PDP. The identity of the The identity of the next hop may have been statically configured,
PDP or next network hop can be statically configured, learned via learned via DHCP or maintained in a directory service. Once the
DHCP or maintained in a directory service. The Kerberos ticket is ticket is acquired, the host constructs a Kerberos AUTH_DATA policy
sent to the next network node (which may be a router or host) in a object, encapsulates it into a RSVP message, and sends it to the next
RSVP message. The KDC is used to validate the ticket and hop RSVP system. Once received by the PDP, the Kerberos ticket is
authentication the user sending RSVP message. used to authenticate the user and/or application initiating the RSVP
session.
4.3 Public Key based User Authentication 4.3. Public-Key Based User Authentication
In public key based user authentication method digital certificate is In the public-key based user authentication method, the digital
encoded as user credentials. The digital signature is used for certificate is encoded as the user's and/or application's
authenticating the user. A summary of the public key user AUTH_DATA credentials. The digital signature is used for authenticating the
policy element is shown below. user and/or application.
+--------------+--------------+--------------+--------------+ An example of a user public-key AUTH_DATA policy element is show
| Length | P-type = AUTH_USER | below.
+--------------+--------------+--------------+--------------+
+-------------+-------------+--------------+-------------+
| Length | P-Type = AUTH_USER |
+-------------+-------------+--------------+-------------+
| Length |POLICY_LOCATOR| SubType | | Length |POLICY_LOCATOR| SubType |
+--------------+--------------+--------------+--------------+ +-------------+-------------+--------------+-------------+
| OctetString (User's Distinguished Name) ... | |
+--------------+--------------+--------------+--------------+ // OctetSting (User's Distinguished Name) //
| Length | CREDENTIAL | SubType | | |
+--------------+--------------+--------------+--------------+ +-------------+-------------+--------------+-------------+
| OctetString (User's Digital Certificate) ... | Length | CREDENTIAL | PGP_CERT |
+--------------+--------------+--------------+--------------+ +-------------+-------------+--------------+-------------+
| |
// OctetSting (User's digital certificate) //
| |
+-------------+-------------+--------------+-------------+
| Length |DIGITAL_SIGN. | 0 | | Length |DIGITAL_SIGN. | 0 |
+--------------+--------------+--------------+--------------+ +-------------+-------------+--------------+-------------+
| OctetString (Digital signature) ... | |
+--------------+--------------+--------------+--------------+ // OctetSting (Digital signature) //
| |
+-------------+-------------+--------------+-------------+
4.3.1. Operational Setting for public key based authentication 4.3.1. Operational Setting for Public-Key Based Authentication
Public key based authentication assumes following: Public-key based authentication assumes the following:
- RSVP service requestors have a pair of keys (private key and - RSVP service requestors have a pair of keys, one private and
public key). one public.
- Private key is secured with the user. - The private key is secured with the user.
- Public keys are stored in digital certificates and a trusted - Public keys are stored in digital certificates. A trusted
party, certificate authority (CA) issues these digital third party, the certificate authority (CA), issues these
certificates. digital certificates upon request.
- The verifier (PDP or router) has the ability to verify the - The PDP has the ability to verify digital certificates.
digital certificate.
RSVP requestor uses its private key to generate DIGITAL_SIGNATURE. A policy aware RSVP enabled host is configured to construct and
User Authenticators (router, PDP) use the user's public key (stored insert AUTH_DATA policy objects into RSVP messages that designate use
in the digital certificate) to verify the signature and authenticate of a public-key authentication method. When constructing the
the user. AUTH_DATA policy element, the host uses the user's private key to
generate the digital signature. The host then encapsulates the
AUTH_DATA policy object into a RSVP message and sends it to the next
hop RSVP system. Once received by the PDP, authentication of the
user is accomplished by verifying the digital signature using the
user's public key stored in the digital certificate.
4.4 Simple Application Authentication 4.4. Simple Application Authentication
The application authentication method encodes the application The application authentication method encodes the application
identification such as an executable filename as plain ASCII or identification such as an executable filename as plain ASCII or
UNICODE text. UNICODE text.
+----------------+--------------+--------------+--------------+ +-------------+-------------+--------------+-------------+
| Length | P-type = AUTH_APP | | Length | P-Type = AUTH_APP |
+----------------+--------------+--------------+--------------+ +-------------+-------------+--------------+-------------+
| Length |POLICY_LOCATOR| SubType | | Length |POLICY_LOCATOR| SubType |
+----------------+--------------+--------------+--------------+ +-------------+-------------+--------------+-------------+
| OctetString (Application Identity attributes in | |
| the form of a Distinguished Name) ... // OctetSting (Application's identity attributes in //
+----------------+--------------+--------------+--------------+ | the form of a Distinguished Name) |
| |
+-------------+-------------+--------------+-------------+
| Length | CREDENTIAL | ASCII_ID | | Length | CREDENTIAL | ASCII_ID |
+----------------+--------------+--------------+--------------+ +-------------+-------------+--------------+-------------+
| OctetString (Application Id, e.g., vic.exe) | |
+----------------+--------------+--------------+--------------+ // OctetSting (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, 5. AUTH_DATA Construction at Intermediary PDP Nodes
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 As described in Section 2, each PDP along the data path constructs a
following rules new AUTH_DATA for the next PDP. More specifically, generation of the
user AUTH_DATA policy element follows these rules:
1. For unicast sessions the user policy locator is copied from the 1. For unicast RSVP sessions, the user policy locator is copied from
previous hop. The authentication credentials are for the current the previous hop. For authentication credentials, the PDP uses
network node identity. its own instead of the previous hop's.
2. For multicast messages the user policy locator is for the current 2. For multicast messages, the PDP discards data from the previous
network node identity. The authentication credentials are for the hop and uses its own policy locator and authentication
current network node. credentials instead.
Network nodes generate application AUTH_DATA policy element using the For application AUTH_DATA policy elements, the PDP follows these
following rules: rules:
1. For unicast sessions the application AUTH_DATA is copied from the 1. For unicast sessions, the application AUTH_DATA is copied from
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.
6. Message Processing Rules 6. Message Processing Rules
6.1 Message Generation (RSVP Host) 6.1. Message Generation
An RSVP message is created as specified in [RFC2205] with following
modifications.
1. RSVP message MAY contain multiple AUTH_DATA policy elements. A RSVP message is created by a policy aware RSVP host as specified in
[RFC 2205] and [POL-EXT] with the following modifications.
2. Authentication policy element (AUTH_DATA) is created and the 1. A RSVP message MAY contain multiple AUTH_DATA policy elements in
IdentityType field is set to indicate the identity type in the one or more POLICY_DATA objects.
policy element.
- DN is inserted as POLICY_LOCATOR attribute. 2. When an AUTH_DATA PE is created, the P-Type field is set to
indicate the identity type, e.g. user. The DN is inserted as a
POLICY_LOCATOR attribute. Authentication credentials such as a
Kerberos ticket or a digital certificate are inserted as a
CREDENTIAL attribute.
- Credentials such as Kerberos ticket or digital certificate are 3. The AUTH_DATA PE is encapsulated into a POLICY_DATA object as
inserted as the CREDENTIAL attribute. described in [POL-EXT]. The INTEGRITY option of a POLICY_DATA
object SHOULD be included if protection against corruption and
replay attacks is desired [POLICY-MD5].
3. POLICY_DATA object (containing the AUTH_DATA policy element) is 4. The policy object is inserted into the RSVP message at the
inserted in the RSVP message in appropriate place. If INTEGRITY appropriate place.
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) 6.2. Message Reception
RSVP message is processed as specified in [RFC2205] with following RSVP messages are processed as specified by [RFC 2205] with the
modifications. following modifications.
1. If router is not policy aware then it SHOULD send the RSVP message 1. If a RSVP system is policy unaware, it MUST ignore any policy data
to the PDP and wait for response. If the router is policy unaware objects it finds in a RSVP message [POL-EXT]. Processing of the
then it ignores the policy data objects and continues processing RSVP message occurs normally as specified in [RFC 2205] and
the RSVP message. [POL-EXT].
2. Reject the message if the response from the PDP is negative. If a RSVP system is policy aware, that is, it is also a policy
enforcement point (PEP), then it SHOULD send the policy elements
from the POLICY_DATA objects to its PDP (or LDP, as appropriate)
and wait for a response.
3. Continue processing the RSVP message. 2. Reject the RSVP message if the response from the PDP is negative.
Otherwise, continue processing the RSVP message.
6.3 Authentication (Router/PDP) 6.3. Authentication
1. Retrieve the AUTH_DATA policy element. Check the PE type field and 1. The PDP retrieves the AUTH_DATA PE from the list of policy
return an error if the identity type is not supported. elements. Check the P-Type field and return an error if the
identity type is unsupported (see Section 7).
2. Verify user credential 2. Verify user credentials. If the authentication method is
unsupported, return an error as described in Section 7.
- Simple authentication: e.g. Get user ID and validate it, or get - For simple authentication, this means validating the user ID or
executable name and validate it. executable name.
- Kerberos: Send the Kerberos ticket to the KDC to obtain the - For the Kerberos method, use the enclosed Kerberos ticket to
session key. Using the session key authenticate the user. validate the user.
- Public Key: Validate the certificate that it was issued by a - For the public-key method, first, validate the digital
trusted Certificate Authority (CA) and authenticate the user or certificate that should have been issued by a trusted
application by verifying the digital signature. certificate authority. Then, retrieve the user's public key
from the certificate, and verify the digital signature.
7. Error Signaling 7. Error Signaling
If PDP fails to verify the AUTH_DATA policy element then it MUST If the PDP fails to verify the AUTH_DATA policy element, then it MUST
return policy control failure (Error Code = 02) to the PEP. The error return a policy control failure (Error Code = 02) to the PEP. The
values are described in [RFC 2205] and [POL-EXT]. Also PDP SHOULD error values are described in [RFC 2205] and [POL-EXT]. Furthermore,
supply a policy data object containing an AUTH_DATA Policy Element the PDP SHOULD supply a policy data object containing an AUTH_DATA PE
with A-Type=POLICY_ERROR_CODE containing more details on the Policy with a POLICY_ERROR_CODE attribute containing more details on the
Control failure (see section 3.3.4). The PEP will include this Policy policy control failure (see Section 3.3.4). The PEP will include
Data object in the outgoing RSVP Error message. this policy data object in the outgoing RSVP Error message.
8. IANA Considerations 8. IANA Considerations
Following the policies outlined in [IANA-CONSIDERATIONS], Standard Following the policies outlined in [IANA-CONSIDERATIONS], Standard
RSVP Policy Elements (P-type values) are assigned by IETF Consensus RSVP Policy Elements (P-type values) are assigned by IETF Consensus
action as described in [POL-EXT]. action as described in [POL-EXT].
P-Type AUTH_USER is assigned the value 2. P-Type AUTH_APP is assigned P-Type AUTH_USER is assigned the value 2. P-Type AUTH_APP is assigned
the value 3. the value 3.
skipping to change at page 14, line 10 skipping to change at page 15, line 34
POLICY_LOCATOR SubType values in the range 0-127 are allocated POLICY_LOCATOR SubType values in the range 0-127 are allocated
through an IETF Consensus action, POLICY_LOCATOR SubType values through an IETF Consensus action, POLICY_LOCATOR SubType values
between 128-255 are reserved for Private Use and are not assigned by between 128-255 are reserved for Private Use and are not assigned by
IANA. IANA.
POLICY_LOCATOR SubType ASCII_DN is assigned the value 1, SubType POLICY_LOCATOR SubType ASCII_DN is assigned the value 1, SubType
UNICODE_DN is assigned the value 2, SubType ASCII_DN_ENCRYPT is UNICODE_DN is assigned the value 2, SubType ASCII_DN_ENCRYPT is
assigned the value 3 and SubType UNICODE_DN_ENCRYPT is assigned the assigned the value 3 and SubType UNICODE_DN_ENCRYPT is assigned the
value 4. value 4.
Following the policies outlined in [IANA-CONSIDERATIONS], ErrorValue
assignments for the POLICY_ERROR_CODE attribute are assigned by IETF
Consensus action.
The 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 the ErrorValue IDENTITY_CHANGED is
assigned the value 5.
Following the policies outlined in [IANA-CONSIDERATIONS], CREDENTIAL Following the policies outlined in [IANA-CONSIDERATIONS], CREDENTIAL
SubType values in the range 0-127 are allocated through an IETF SubType values in the range 0-127 are allocated through an IETF
Consensus action, CREDENTIAL SubType values between 128-255 are Consensus action, CREDENTIAL SubType values between 128-255 are
reserved for Private Use and are not assigned by IANA. reserved for Private Use and are not assigned by IANA.
CREDENTIAL SubType ASCII_ID is assigned the value 1, SubType CREDENTIAL SubType ASCII_ID is assigned the value 1, SubType
UNICODE_ID is assigned the value 2, SubType KERBEROS_TKT is assigned UNICODE_ID is assigned the value 2, SubType KERBEROS_TKT is assigned
the value 3, SubType X509_V3_CERT is assigned the value 4, SubType the value 3, SubType X509_V3_CERT is assigned the value 4, SubType
PGP_CERT is assigned the value 5. PGP_CERT is assigned the value 5.
skipping to change at page 14, line 38 skipping to change at page 16, line 23
option with an RSVP's INTEGRITY Object can result in a secure option with an RSVP's INTEGRITY Object can result in a secure
admission control mechanism that enforces authentication based on admission control mechanism that enforces authentication based on
both the identity of the user and the identity of the originating both the identity of the user and the identity of the originating
node. node.
Simple authentication does not contain credentials that can be Simple authentication does not contain credentials that can be
securely authenticated and is inherently less secured. securely authenticated and is inherently less secured.
The Kerberos authentication mechanism is reasonably well secured. The Kerberos authentication mechanism is reasonably well secured.
User authentication using a public key certificate is known to User authentication using a public-key certificate is known to
provide the strongest security. provide the strongest security.
10. Acknowledgments 10. Acknowledgments
We would like to thank Andrew Smith, Bob Lindell and many others for We would like to thank Andrew Smith, Bob Lindell and many others for
their valuable comments on this memo. their valuable comments on this memo.
11. References 11. References
[ASCII] Coded Character Set -- 7-Bit American Standard [ASCII] Coded Character Set -- 7-Bit American Standard
skipping to change at page 15, line 25 skipping to change at page 16, line 51
[POL-EXT] Hess, R., Ed., and Herzog, S., "RSVP Extensions [POL-EXT] Hess, R., Ed., and Herzog, S., "RSVP Extensions
for Policy Control", work in progress, draft- for Policy Control", work in progress, draft-
ietf-rap-new-rsvp-ext-00.txt, June 2001. ietf-rap-new-rsvp-ext-00.txt, June 2001.
[POL-FRAME] Yavatkar, R., Pendarakis, D. and R. Guerin, "A [POL-FRAME] Yavatkar, R., Pendarakis, D. and R. Guerin, "A
Framework for Policy-based Admission Control Framework for Policy-based Admission Control
RSVP", RFC 2753, January 2000. RSVP", RFC 2753, January 2000.
[POLICY-MD5] Hess, R., "Cryptographic Authentication for [POLICY-MD5] Hess, R., "Cryptographic Authentication for
RSVP POLICY_DATA Objects", work in progress, RSVP POLICY_DATA Objects", work in progress,
draft-ietf-rap-auth-policy-data-00.txt, draft-ietf-rap-auth-policy-data-01.txt,
June 2001. July 2001.
[RFC 1510] Kohl, J. and C. Neuman, "The Kerberos Network [RFC 1510] Kohl, J. and C. Neuman, "The Kerberos Network
Authentication Service (V5)", RFC 1510, Authentication Service (V5)", RFC 1510,
September 1993. September 1993.
[RFC 1704] Haller, N. and R. Atkinson, "On Internet [RFC 1704] Haller, N. and R. Atkinson, "On Internet
Authentication", RFC 1704, October 1994. Authentication", RFC 1704, October 1994.
[RFC 1779] Killie, S., "A String Representation of [RFC 1779] Killie, S., "A String Representation of
Distinguished Names", RFC 1779, March 1995. Distinguished Names", RFC 1779, March 1995.
[RFC 2205] Braden, R., Zhang, L., Berson, S., Herzog, S. [RFC 2205] Braden, R., Zhang, L., Berson, S., Herzog, S.
and S. Jamin, "Resource ReSerVation Protocol and S. Jamin, "Resource ReSerVation Protocol
(RSVP) - Version 1 Functional Specification", (RSVP) - Version 1 Functional Specification",
RFC 2205, September 1997. RFC 2205, September 1997.
[RFC 2209] Braden, R. and L. Zhang, "Resource ReSerVation [RFC 2209] Braden, R. and L. Zhang, "Resource ReSerVation
Protocol (RSVP) - Version 1 Message Processing Protocol (RSVP) - Version 1 Message Processing
Rules", RFC 2209, September 1997. Rules", RFC 2209, September 1997.
[RFC 2119] Bradner, S., "Key Words for use in RFCs to
Indicate Requirement Levels," RFC 2119, March
1997.
[UNICODE] The Unicode Consortium, "The Unicode Standard, [UNICODE] The Unicode Consortium, "The Unicode Standard,
Version 2.0", Addison-Wesley, Reading, MA, Version 2.0", Addison-Wesley, Reading, MA,
1996. 1996.
[X.509] Housley, R., Ford, W., Polk, W. and D. Solo, [X.509] Housley, R., Ford, W., Polk, W. and D. Solo,
"Internet X.509 Public Key Infrastructure "Internet X.509 Public Key Infrastructure
Certificate and CRL Profile", RFC 2459, January Certificate and CRL Profile", RFC 2459, January
1999. 1999.
[X.509-ITU] ITU-T (formerly CCITT) Information technology - [X.509-ITU] ITU-T (formerly CCITT) Information technology -
Open Systems Interconnection - The Directory: Open Systems Interconnection - The Directory:
Authentication Framework Recommendation X.509 Authentication Framework Recommendation X.509
ISO/IEC 9594-8 ISO/IEC 9594-8
12. Author Information 12. Author Information
Rodney Hess Rodney Hess
Intel, BD1 Intel, BD1
28 Crosby Drive 28 Crosby Drive
skipping to change at page 16, line 25 skipping to change at page 18, line 4
Bedford, MA 01730 Bedford, MA 01730
EMail: rodney.hess@intel.com EMail: rodney.hess@intel.com
Satyendra Yadav Satyendra Yadav
Intel, JF3-206 Intel, JF3-206
2111 NE 25th Avenue 2111 NE 25th Avenue
Hillsboro, OR 97124 Hillsboro, OR 97124
EMail: Satyendra.Yadav@intel.com EMail: Satyendra.Yadav@intel.com
Raj Yavatkar Raj Yavatkar
Intel, JF3-206 Intel, JF3-206
2111 NE 25th Avenue 2111 NE 25th Avenue
Hillsboro, OR 97124 Hillsboro, OR 97124
EMail: Raj.Yavatkar@intel.com Email: Raj.Yavatkar@intel.com
Ramesh Pabbati Ramesh Pabbati
Microsoft Microsoft
1 Microsoft Way 1 Microsoft Way
Redmond, WA 98054 Redmond, WA 98054
EMail: rameshpa@microsoft.com Email: rameshpa@microsoft.com
Peter Ford Peter Ford
Microsoft Microsoft
1 Microsoft Way 1 Microsoft Way
Redmond, WA 98054 Redmond, WA 98054
EMail: peterf@microsoft.com Email: peterf@microsoft.com
Tim Moore Tim Moore
Microsoft Microsoft
1 Microsoft Way 1 Microsoft Way
Redmond, WA 98054 Redmond, WA 98054
EMail: timmoore@microsoft.com Email: timmoore@microsoft.com
Shai Herzog Shai Herzog
IPHighway, Inc. IPHighway, Inc.
55 New York Avenue 55 New York Avenue
Framingham, MA 01701 Framingham, MA 01701
EMail: herzog@iphighway.com Email: herzog@iphighway.com
13. Full Copyright Statement Appendix A: Revision History
Revision 01
1. Corrected an error in the processing of Kerberos credentials in
AUTH_DATA policy objects by the PDP (Section 4.2.1 and Section
6.3).
2. Corrected the length of the ErrorValue field for a
POLICY_ERROR_OBJECT attribute (Section 3.3.4).
3. Specified the IANA considerations for ErrorValue in Section
3.3.4 and Section 9.
4. Expanded Section 2, Introduction.
5. Rewrote the text for Section 5 to better follow Section 2.
6. Updated Step 3 in Section 6.1 to correctly reflect how security
issues are addressed.
Revision 00
1. Updated the Security Considerations Section to correctly
reflect how various security issues are addressed.
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
 End of changes. 

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