Identity Representation for RSVP
obsoletes
- rfc-2752 — Identity Representation for RSVP
Extracted elements (27)
Distinguished Names (X.500 DN) are chosen as policy locators because they are globally unique per user or application, making them suitable for locating admission policies in a directory without ambiguity.
The DIGITAL_SIGNATURE attribute is mandated to appear last in the attribute list so that the signature can cover all preceding authentication data in the policy element without requiring foreknowledge of what follows.
This document obsoletes RFC 2752, correcting a P-Type codepoint assignment error and a field size definition error in ErrorValue. Implementations based on RFC 2752 must update their P-Type and ErrorValue handling to align with RFC 3182.
A policy-unaware router receiving RSVP messages ignores policy data objects and continues processing; a policy-aware router SHOULD forward the message to the PDP and await its response, rejecting the message if the PDP response is negative.
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.
DIGITAL_SIGNATURE (A-Type 3) MUST be the last attribute in the AUTH_DATA attribute list and signs all preceding data in the policy element. The SubType field MUST be set to 0.
For multicast sessions, application AUTH_DATA is either the first application AUTH_DATA in the message or chosen by the PDP; for unicast sessions it is copied from the previous hop.
For unicast sessions, a network node copies the user policy locator from the previous hop and uses its own credentials. For multicast messages, the node uses its own identity for both policy locator and credentials.
If a 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 containing AUTH_DATA with POLICY_ERROR_CODE details.
When a policy node fails to process an AUTH_DATA element, it SHOULD insert a POLICY_ERROR_OBJECT with the appropriate ErrorValue into a PATH_ERROR or RESV_ERROR message. The AUTH_DATA in PATH or RESV messages SHOULD NOT contain POLICY_ERROR_OBJECT.
When generating an RSVP message, if an INTEGRITY object is not computed for the RSVP message, then an INTEGRITY object SHOULD be computed for the POLICY_DATA object containing AUTH_DATA and SHOULD be inserted as a Policy Data option.
Application authentication (AUTH_APP, P-Type 3) encodes the application identity (e.g., executable filename) as an ASCII_ID or UNICODE_ID CREDENTIAL, accompanied by a POLICY_LOCATOR containing the application Distinguished Name.
CREDENTIAL (A-Type 2) encodes user or application credentials. SubTypes are ASCII_ID (1), UNICODE_ID (2), KERBEROS_TKT (3), X509_V3_CERT (4), and PGP_CERT (5). The OctetString field contains the actual credential.
Kerberos user authentication uses a KERBEROS_TKT CREDENTIAL sub-type. The Kerberos ticket for the next-hop network node or its PDP is obtained from the KDC and inserted as the CREDENTIAL OctetString in an AUTH_USER policy element.
POLICY_ERROR_OBJECT (A-Type 4) is used to convey policy control failure details. It includes a 2-octet reserved field, a 2-octet ErrorValue, and an optional OctetString with additional human-readable information. Length MUST be >= 8.
POLICY_LOCATOR (A-Type 1) encodes an X.500 Distinguished Name as a policy locator for the 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.
Public key user authentication includes an X509_V3_CERT or PGP_CERT CREDENTIAL attribute and a DIGITAL_SIGNATURE attribute (signed with the user's private key). The verifier uses the public key in the certificate to authenticate the user.
Simple user authentication encodes the user login ID (ASCII_ID or UNICODE_ID) as a CREDENTIAL attribute, combined with a POLICY_LOCATOR (Distinguished Name) attribute inside an AUTH_USER (P-Type 2) policy element.
The AUTH_DATA policy element (PE) carries identity credentials inside RSVP POLICY_DATA objects. It contains a Length field, a P-Type field (Identity Type), and a variable-length Authentication Attribute List. P-Type 2 = AUTH_USER; P-Type 3 = AUTH_APP.
IANA maintains the A-Type registry: POLICY_LOCATOR=1, CREDENTIAL=2, DIGITAL_SIGNATURE=3, POLICY_ERROR_OBJECT=4. Values 0–127 require IETF Consensus; 128–255 are reserved for Private Use.
IANA maintains the CREDENTIAL SubType registry: ASCII_ID=1, UNICODE_ID=2, KERBEROS_TKT=3, X509_V3_CERT=4, PGP_CERT=5. Values 0–127 require IETF Consensus; 128–255 are Private Use.
IANA maintains the ErrorValue registry for POLICY_ERROR_OBJECT: ERROR_NO_MORE_INFO=1, UNSUPPORTED_CREDENTIAL_TYPE=2, INSUFFICIENT_PRIVILEGES=3, EXPIRED_CREDENTIAL=4, IDENTITY_CHANGED=5. Values 0–32767 require IETF Consensus; 32768–65535 are Private Use.
IANA maintains the POLICY_LOCATOR SubType registry: ASCII_DN=1, UNICODE_DN=2, ASCII_DN_ENCRYPT=3, UNICODE_DN_ENCRYPT=4. Values 0–127 require IETF Consensus; 128–255 are Private Use.
IANA maintains the registry for RSVP Policy Element P-Types (identity types). AUTH_USER is assigned value 2; AUTH_APP is assigned value 3. New P-Type assignments require IETF Consensus.
The RSVP INTEGRITY object is used to protect AUTH_DATA policy objects from replay attacks. Combining AUTH_DATA with the INTEGRITY object enforces authentication based on both user identity and originating node identity. Simple (plaintext) authentication is inherently less secure; public key certificates provide the strongest assurance.
Each authentication attribute has a 4-octet header: 2-octet Length (actual length including header, not counting padding), 1-octet A-Type, 1-octet SubType, followed by a variable-length Value field.
The AUTH_DATA policy element header is 4 octets: a 2-octet Length (including header, must be a multiple of 4) followed by a 2-octet P-Type (Identity Type). The Authentication Attribute List follows immediately.