rfc-2752

Identity Representation for RSVP

S. Yadav, R. Yavatkar, R. Pabbati, P. Ford, T. Moore, S. Herzog
date2000-01 streamIETF areaops wgrap statusPROPOSED STANDARD pages17 canonicalhttps://www.rfc-editor.org/rfc/rfc2752 doi10.17487/RFC2752
This document describes the representation of identity information in POLICY_DATA object for supporting policy based admission control in RSVP. [STANDARDS-TRACK]

obsoleted by

Extracted elements (25)

design-rationale §3.3.1

Distinguished Names (X.500 DN) are used as POLICY_LOCATOR values because DNs are unique per user or application, making them suitable as keys for locating admission policy in a directory. Both ASCII and UNICODE forms are supported to accommodate different deployment environments.

security, ldap

design-rationale §5

For multicast merged flows, the application AUTH_DATA is set to either the first application AUTH_DATA in the message or chosen by the PDP, while user AUTH_DATA uses the current node's identity rather than copying from a previous hop — this prevents identity merging ambiguity across multicast branches.

security, qos, multicast

normative-requirement §6.1 SHOULD

An RSVP message MAY contain multiple AUTH_DATA policy elements. When an INTEGRITY object is not computed for the RSVP message, an INTEGRITY object SHOULD be computed for the POLICY_DATA object containing AUTH_DATA and SHOULD be inserted as a Policy Data option.

security, qos

normative-requirement §3.3 MUST

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.

security, qos

normative-requirement §5 SHOULD

For unicast sessions, the user policy locator is copied from the previous hop and authentication credentials are for the current network node; for multicast, the user policy locator and credentials are both for the current network node.

security, qos, multicast

normative-requirement §6.2 SHOULD

If a router is not policy-aware, it SHOULD send the RSVP message to the PDP and wait for a response; if policy-unaware, it ignores the policy data objects and continues processing.

security, qos

normative-requirement §7 MUST

If the PDP fails to verify the AUTH_DATA policy element, it MUST return a policy control failure (Error Code = 02) to the PEP, and SHOULD supply a POLICY_DATA object with AUTH_DATA containing A-Type=POLICY_ERROR_CODE with details on the failure.

security, qos

normative-requirement §3.3.4 SHOULD NOT

The AUTH_DATA policy element in PATH or RESV messages SHOULD NOT contain the POLICY_ERROR_OBJECT attribute; these attributes are only inserted into PATH_ERROR and RESV_ERROR messages by policy-aware intermediate nodes.

security, qos

normative-requirement §3.3.3 MUST

The DIGITAL_SIGNATURE attribute MUST be the last attribute in the authentication attribute list, and its SubType field MUST be set to 0 as no sub-types are currently defined.

security, crypto

normative-requirement §3.3.4 SHOULD

When a policy node encounters an AUTH_DATA policy element that fails policy control, it SHOULD add a POLICY_ERROR_CODE attribute with details about the failure, causing an appropriate PATH_ERROR or RESV_ERROR to be returned to the request source.

security, qos

protocol-element §3.2

AUTH_DATA is a policy element (PE) contained in the POLICY_DATA object that carries authentication credentials and policy locators to identify the user or application making an RSVP request. It contains a list of authentication attributes and is typed by P-Type (Identity Type): AUTH_USER (1) or AUTH_APP (2).

security, qos

protocol-element §3.3.2

CREDENTIAL (A-Type=2) carries the authentication credential for the user or application. SubTypes include ASCII_ID (1), UNICODE_ID (2), KERBEROS_TKT (3), X509_V3_CERT (4), and PGP_CERT (5).

security, crypto, pkix

protocol-element §3.3.3

DIGITAL_SIGNATURE (A-Type=3) contains the digital signature over all AUTH_DATA policy element data preceding it. The signing algorithm is determined by the CREDENTIAL SubType field.

security, crypto

protocol-element §4.2

Kerberos user authentication uses P-type AUTH_USER with a POLICY_LOCATOR (user DN) and a CREDENTIAL attribute with SubType KERBEROS_TKT carrying the Kerberos session ticket obtained from the KDC for the next network node or PDP.

security, qos

protocol-element §3.3.4

POLICY_ERROR_OBJECT (A-Type=4) carries a 32-bit ErrorValue code and optional OctetString describing why a policy decision point failed to process the AUTH_DATA element. Error values include: ERROR_NO_MORE_INFO (1), UNSUPPORTED_CREDENTIAL_TYPE (2), INSUFFICIENT_PRIVILEGES (3), EXPIRED_CREDENTIAL (4), IDENTITY_CHANGED (5).

security, qos

protocol-element §3.3.1

POLICY_LOCATOR (A-Type=1) carries the X.500 Distinguished Name used to locate the admission policy for a user or application. SubTypes include ASCII_DN (1), UNICODE_DN (2), ASCII_DN_ENCRYPT (3), and UNICODE_DN_ENCRYPT (4); encrypted forms use the Kerberos session key or digital certificate private key.

security, qos, ldap

protocol-element §4.3

Public key based user authentication uses P-type AUTH_USER with POLICY_LOCATOR (user DN), CREDENTIAL containing a digital certificate (X509_V3_CERT or PGP_CERT), and a DIGITAL_SIGNATURE attribute computed using the user's private key.

security, crypto, pkix

protocol-element §4.4

Simple application authentication encodes the application identity (e.g., executable filename) as a CREDENTIAL with ASCII_ID, combined with a POLICY_LOCATOR in DN form, under P-type AUTH_APP.

security, qos

protocol-element §4.1

Simple user authentication encodes the user login ID (ASCII or UNICODE) as a CREDENTIAL attribute with ASCII_ID or UNICODE_ID SubType, combined with a POLICY_LOCATOR containing the user's Distinguished Name, under P-type AUTH_USER.

security, qos

registry §8

IANA registry for Authentication Attribute Types (A-Type): values 0–127 allocated via IETF Consensus; values 128–255 reserved for Private Use. Initially defined: POLICY_LOCATOR (1), CREDENTIAL (2), DIGITAL_SIGNATURE (3), POLICY_ERROR_OBJECT (4).

registry, security

registry §8

IANA registry for CREDENTIAL SubType values: 0–127 via IETF Consensus, 128–255 Private Use. Initially defined: ASCII_ID (1), UNICODE_ID (2), KERBEROS_TKT (3), X509_V3_CERT (4), PGP_CERT (5).

registry, security, pkix, crypto

registry §8

IANA registry for POLICY_LOCATOR SubType values: 0–127 via IETF Consensus, 128–255 Private Use. Initially defined: ASCII_DN (1), UNICODE_DN (2), ASCII_DN_ENCRYPT (3), UNICODE_DN_ENCRYPT (4).

registry, security

security-consideration §9

The RSVP INTEGRITY object is used to protect the POLICY_DATA object containing AUTH_DATA from replay attacks. Combining AUTH_DATA with INTEGRITY enforces authentication based on both user identity and originating node identity. Simple authentication (plain ASCII/UNICODE ID) is inherently less secure; Kerberos is reasonably secure; public key certificate authentication provides the strongest security.

security, crypto, pkix

wire-format §3.3

Each authentication attribute is encoded with a 2-octet Length (actual length including header, not counting padding), a 1-octet A-Type, a 1-octet SubType, and a variable-length Value field. A-Types defined: POLICY_LOCATOR (1), CREDENTIAL (2), DIGITAL_SIGNATURE (3), POLICY_ERROR_OBJECT (4).

security, qos

wire-format §3.2

The AUTH_DATA policy element header consists of a 2-octet Length field (total length including header, must be a multiple of 4) followed by a 2-octet P-Type (Identity Type) field, followed by a variable-length Authentication Attribute List.

security, qos