RFC 3520
Session Authorization Policy Element
RFC 3520: Session Authorization Policy Element 🎀
Okay bestie, let's get into RFC 3520 ✨ First, the title block tea so you know who's behind it:
- Network Working Group 🌸
- Request for Comments: 3520
- Category: Standards Track, so this is an Internet standards track protocol 💅
- Date: April 2003 🗓️
- Authors: L-N. Hamer and B. Gage (Nortel Networks), B. Kosinski (Invidi Technologies), H. Shieh (AT&T Wireless) 🫶
- Obsoletes / Updates: the title block doesn't list any Obsoletes or Updates entries 🙈
Status of This Memo 📜
This document specifies an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 🫶 If you want the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🦋
Copyright Notice ©️
Copyright (C) The Internet Society (2003). All Rights Reserved. 💜
Abstract ✨
Okay so this doc is all about the session authorization policy element 💖 It's a way to support policy-based, per-session authorization and admission control. The big goal is to let network elements swap info so they can authorize the use of resources for a service and coordinate actions between the signaling plane and the transport plane. It's giving teamwork 👑
Here's the flow: a process on a system authorizes a host to reserve resources, then gives that host a session authorization policy element. The host puts that element into a resource reservation protocol message (like the RSVP PATH message) so the reservation can be handled properly and securely inside the network 🔐 The element is encoded as a policy element that follows the format of a Policy Data object (RFC 2750). The doc also covers operations, processing rules, and error scenarios, so it's thorough af 😭
Table of Contents 📋
1. Conventions used in this document..............................3
2. Introduction...................................................3
3. Policy Element for Session Authorization.......................4
3.1 Policy Data Object Format..................................4
3.2 Session Authorization Policy Element.......................4
3.3 Session Authorization Attributes...........................4
3.3.1 Authorizing Entity Identifier..........................6
3.3.2 Session Identifier.....................................7
3.3.3 Source Address.........................................7
3.3.4 Destination Address....................................9
3.3.5 Start time............................................10
3.3.6 End time..............................................11
3.3.7 Resources Authorized..................................11
3.3.8 Authentication data...................................12
4. Integrity of the AUTH_SESSION policy element..................13
4.1 Shared symmetric keys.....................................13
4.1.1 Operational Setting using shared symmetric keys.......13
4.2 Kerberos..................................................14
4.2.1. Operational Setting using Kerberos...................15
4.3 Public Key................................................16
4.3.1. Operational Setting for public key based
authentication.......................................16
4.3.1.1 X.509 V3 digital certificates.....................17
4.3.1.2 PGP digital certificates..........................17
5. Framework.....................................................18
5.1 The coupled model.........................................18
5.2 The associated model with one policy server...............18
5.3 The associated model with two policy servers..............19
5.4 The non-associated model..................................19
6. Message Processing Rules......................................20
6.1 Generation of the AUTH_SESSION by the authorizing entity..20
6.2 Message Generation (RSVP Host)............................20
6.3 Message Reception (RSVP-aware Router).....................20
6.4 Authorization (Router/PDP)................................21
7. Error Signaling...............................................22
8. IANA Considerations...........................................22
9. Security Considerations.......................................24
10. Acknowledgments..............................................24
11. Normative References.........................................25
12. Informative References.......................................27
13. Intellectual Property Statement..............................27
14. Contributors.................................................28
15. Authors' Addresses...........................................29
16. Full Copyright Statement.....................................301. Conventions used in this document 🧠
Okay, so the key words are "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 💅 In this doc, they're to be read as described in BCP 14, RFC 2119 [RFC-2119]. Those words are the whole vibe for how strict each rule is, so keep an eye out for them 👀
2. Introduction 🦋
Okay so RSVP [RFC-2205] is one example of a resource reservation protocol. A host uses it to ask the network for specific services for particular application data streams or flows 🌊 RSVP requests usually end up reserving resources in each router along the data path. It lets users get preferential access to network resources, but only under the control of an admission control mechanism. That admission control is often based on user or application identity [RFC-3182], but it's also super valuable to have per-session admission control 💖
So here's the thing: for per-session admission control, there needs to be a mechanism that makes sure a host's use of resources has been properly authorized before those resources get reserved 🔐 To meet that, the resource reservation message has to carry information that can be used to verify the reservation request. The way to do that is to give the host a session authorization policy element, which goes inside the resource reservation message and gets verified by the network ✨
This document describes the session authorization policy element (AUTH_SESSION), which carries information about the resources a session is authorized to use 🎀 The host must get an AUTH_SESSION element from an authorizing entity through a session signaling protocol, such as SIP [RFC-3261]. Then the host puts the AUTH_SESSION element into the resource reservation message so the network can verify the resource request. With RSVP, this element MUST be encapsulated in the Policy Data object [RFC-2750] of an RSVP PATH message 🫶 Network elements then verify the request and process the resource reservation message based on admission policy 💅
[RFC-3521] describes a framework where a session authorization policy element can hold information that's relevant to the network's decision to grant a reservation request 🧚
3. Policy Element for Session Authorization 💜
3.1 Policy Data Object Format 🍓
The Session Authorization policy element follows the format of a POLICY_DATA object. That object holds policy information and gets carried by policy-based admission protocols like RSVP 🌈 You can find the full details of the POLICY_DATA object in "RSVP Extensions for Policy Control" [RFC-2750] 📖
3.2 Session Authorization Policy Element ✨
Here we describe a policy element (PE) called session authorization (AUTH_SESSION) 💖 It holds a list of fields that describe the session, along with other attributes, so it's basically the whole session in one neat package 🎁
+-------------+-------------+-------------+-------------+
| Length | P-Type = AUTH_SESSION |
+-------------+-------------+-------------+-------------+
// Session Authorization Attribute List //
+-------------------------------------------------------+Length: 16 bits. This is the length of the policy element, counting the Length and P-Type. It's measured in octets and it MUST be in multiples of 4 🔥 It also marks where the session authorization information block ends 🏁
P-Type: 16 bits (Session Authorization Type). This is the Policy element type (P-type) for this element, and it's AUTH_SESSION = 0x04 🌸 IANA acts as the registry for policy element types, as described in [RFC-2750] 📋
Session Authorization Attribute List: variable length. This is a collection of objects that describe the session and give other info needed to verify the resource reservation request 🧩 The initial set of valid objects is in Section 3.3 👀
3.3 Session Authorization Attributes 🎀
A session authorization attribute can carry a bunch of different info, and it has both an attribute type and a subtype 💅 The attribute itself MUST be a multiple of 4 octets long. Any attribute that isn't a multiple of 4 octets MUST be padded to a 4-octet boundary, and all padding bytes MUST have a value of zero 🫧 No exceptions, bestie 🙅♀️
+--------+--------+--------+--------+
| Length | X-Type |SubType |
+--------+--------+--------+--------+
| Value ...
+--------+--------+--------+--------+Length: 16 bits. This field is two octets and shows the actual length of the attribute, counting the Length, X-Type, and SubType fields, in octets 📏 The length does NOT include any padding bytes added to the value field to make the attribute a multiple of 4 octets 🙈
X-Type: 8 bits. This is the session authorization attribute type, and it's one octet. IANA acts as the registry for X-Types, as described in section 7, IANA Considerations 🗂️ At first, the registry holds these X-Types:
1 AUTH_ENT_ID The unique identifier of the entity which
authorized the session.
2 SESSION_ID Unique identifier for this session.
3 SOURCE_ADDR Address specification for the session
originator.
4 DEST_ADDR Address specification for the session
end-point.
5 START_TIME The starting time for the session.
6 END_TIME The end time for the session.
7 RESOURCES The resources which the user is authorized
to request.
8 AUTHENTICATION_DATA Authentication data of the session
authorization policy element.SubType: 8 bits. The session authorization attribute sub-type is one octet long. Its value depends on the X-Type 🧚
Value: variable length. This is the attribute-specific information 💖
To be continued... 🦋 Part 2 is coming with Section 4, the integrity stuff, so stay tuned 💅
3.3.1 Authorizing Entity Identifier 🪪
okay so AUTH_ENT_ID is how we say which entity authorized the very first service request and generated the session authorization policy element 👑 It can show up in a bunch of different formats, and the SubType is what tells you which format you're looking at 🦋
+-------+-------+-------+-------+
| Length |X-Type |SubType|
+-------+-------+-------+-------+
| OctetString ...
+-------+-------+-------+-------+Length: Length of the attribute, which MUST be > 4. 📏
X-Type: AUTH_ENT_ID ✨
SubType: These are the sub-types for AUTH_ENT_ID that are defined. IANA acts as a registry for AUTH_ENT_ID sub-types, as described in section 7, IANA Considerations. At the start, the registry has these sub-types of AUTH_ENT_ID:
1 IPV4_ADDRESS IPv4 address represented in 32 bits
2 IPV6_ADDRESS IPv6 address represented in 128 bits
3 FQDN Fully Qualified Domain Name as defined in
RFC 1034 as an ASCII string.
4 ASCII_DN X.500 Distinguished name as defined in RFC
2253 as an ASCII string.
5 UNICODE_DN X.500 Distinguished name as defined in RFC
2253 as a UTF-8 string.
6 URI Universal Resource Identifier, as defined
in RFC 2396.
7 KRB_PRINCIPAL Fully Qualified Kerberos Principal name
represented by the ASCII string of a
principal followed by the @ realm name as
defined in RFC 1510 (e.g.,
principalX@realmY).
8 X509_V3_CERT The Distinguished Name of the subject of
the certificate as defined in RFC 2253 as a
UTF-8 string.
9 PGP_CERT The PGP digital certificate of the
authorizing entity as defined in RFC 2440.OctetString: Contains the authorizing entity identifier. 🫶
3.3.2 Session Identifier 🆔
SESSION_ID is a unique identifier that the authorizing entity uses to identify the request 💜 It may be used for a bunch of things, like replay detection, or for linking this request to a policy decision entry made by the authorizing entity. For example, the SESSION_ID can be based on simple sequence numbers or on a standard NTP timestamp ⏰
+-------+-------+-------+-------+
| Length |X-Type |SubType|
+-------+-------+-------+-------+
| OctetString ...
+-------+-------+-------+-------+Length: Length of the attribute, which MUST be > 4. 📏
X-Type: SESSION_ID 🌸
SubType: No subtypes for SESSION_ID are defined right now. This field MUST be set to zero. The authorizing entity is the only network entity that needs to interpret the contents of the SESSION_ID, so the contents and format are implementation dependent. 🙈
OctetString: Contains the session identifier. 🦋
3.3.3 Source Address 📍
SOURCE_ADDR is used to identify the source address specification of the authorized session. This X-Type can be really useful in some scenarios, since it makes sure the resource request was authorized for that exact source address and/or port 🎯
+-------+-------+-------+-------+
| Length |X-Type |SubType|
+-------+-------+-------+-------+
| OctetString ...
+-------+-------+-------+-------+Length: Length of the attribute, which MUST be > 4. 📏
X-Type: SOURCE_ADDR 💫
SubType: These are the sub types for SOURCE_ADDR that are defined. IANA acts as a registry for SOURCE_ADDR sub-types, as described in section 7, IANA Considerations. At the start, the registry has these sub types for SOURCE_ADDR:
1 IPV4_ADDRESS IPv4 address represented in 32 bits
2 IPV6_ADDRESS IPv6 address represented in 128 bits
3 UDP_PORT_LIST list of UDP port specifications,
represented as 16 bits per list entry.
4 TCP_PORT_LIST list of TCP port specifications,
represented as 16 bits per list entry.OctetString: The OctetString contains the source address information. 🧾
In scenarios where a source address is required (see Section 5), at least one of the subtypes 1 through 2 (inclusive) MUST be included in every Session Authorization Data Policy Element. 🔑 You can include multiple SOURCE_ADDR attributes if multiple addresses have been authorized, since that's a MAY 🌈 The source address field of the resource reservation datagram (e.g., RSVP PATH) MUST match one of the SOURCE_ADDR attributes in this Session Authorization Data Policy Element. No skipping this one, bestie 🫶
At most, one instance of subtype 3 MAY be included in every Session Authorization Data Policy Element. At most, one instance of subtype 4 MAY be included in every Session Authorization Data Policy Element. Adding a subtype 3 attribute doesn't stop you from adding a subtype 4 attribute, so both UDP and TCP ports can be authorized at the same time 🔥
If no PORT attributes are specified, then all ports are considered valid. Otherwise, only the specified ports are authorized for use 🚪
Every source address and port list must be included in a separate SOURCE_ADDR attribute. 🧩
3.3.4 Destination Address 🎯
DEST_ADDR is used to identify the destination address of the authorized session. This X-Type can be really useful in some scenarios too, since it makes sure the resource request was authorized for that exact destination address and/or port 💅
+-------+-------+-------+-------+
| Length |X-Type |SubType|
+-------+-------+-------+-------+
| OctetString ...
+-------+-------+-------+-------+Length: Length of the attribute, which MUST be > 4. 📏
X-Type: DEST_ADDR 🌟
SubType: These are the sub types for DEST_ADDR that are defined. IANA acts as a registry for DEST_ADDR sub-types, as described in section 7, IANA Considerations. At the start, the registry has these sub types for DEST_ADDR:
1 IPV4_ADDRESS IPv4 address represented in 32 bits
2 IPV6_ADDRESS IPv6 address represented in 128 bits
3 UDP_PORT_LIST list of UDP port specifications,
represented as 16 bits per list entry.
4 TCP_PORT_LIST list of TCP port specifications,
represented as 16 bits per list entry.OctetString: The OctetString contains the destination address specification. 🧾
In scenarios where a destination address is required (see Section 5), at least one of the subtypes 1 through 2 (inclusive) MUST be included in every Session Authorization Data Policy Element. 🔑 Multiple DEST_ADDR attributes MAY be included if multiple addresses have been authorized. The destination address field of the resource reservation datagram (e.g., RSVP PATH) MUST match one of the DEST_ADDR attributes in this Session Authorization Data Policy Element. Same energy as the source address, periodt 💖
At most, one instance of subtype 3 MAY be included in every Session Authorization Data Policy Element. At most, one instance of subtype 4 MAY be included in every Session Authorization Data Policy Element. Subtype 3 doesn't block subtype 4, so UDP and TCP ports can both be authorized 🦋
If no PORT attributes are specified, then all ports are considered valid. Otherwise, only the specified ports are authorized for use 🚪
Every destination address and port list must be included in a separate DEST_ADDR attribute. 🧩
3.3.5 Start time ⏰
START_TIME is used to identify the start time of the authorized session, and it can be used to prevent replay attacks 🛡️ If the AUTH_SESSION policy element shows up in a resource request, the network SHOULD reject the request if it isn't received within a few seconds of the start time specified. Timing is everything, bestie 😭
+-------+-------+-------+-------+
| Length |X-Type |SubType|
+-------+-------+-------+-------+
| OctetString ...
+-------+-------+-------+-------+Length: Length of the attribute, which MUST be > 4. 📏
X-Type: START_TIME 🌈
SubType: These are the sub types for START_TIME that are defined. IANA acts as a registry for START_TIME sub-types, as described in section 7, IANA Considerations. At the start, the registry has these sub types for START_TIME:
1 NTP_TIMESTAMP NTP Timestamp Format as defined in
RFC 1305.OctetString: The OctetString contains the start time. 🕰️
3.3.6 End time 🏁
END_TIME is used to identify the end time of the authorized session, and it can be used to limit how long resources stay authorized for use (for example, in prepaid session scenarios) 💸
+-------+-------+-------+-------+
| Length |X-Type |SubType|
+-------+-------+-------+-------+
| OctetString ...
+-------+-------+-------+-------+Length: Length of the attribute, which MUST be > 4. 📏
X-Type: END_TIME 🍓
SubType: These are the sub types for END_TIME that are defined. IANA acts as a registry for END_TIME sub-types, as described in section 7, IANA Considerations. At the start, the registry has these sub types for END_TIME:
1 NTP_TIMESTAMP NTP Timestamp Format as defined in
RFC 1305.OctetString: The OctetString contains the end time. ⌛
3.3.7 Resources Authorized 📦
RESOURCES is used to define the characteristics of the authorized session. This X-Type can be useful in some scenarios for spelling out the specific resources that were authorized, so the request fits the authorized specs 🎀
+-------+-------+-------+-------+
| Length |X-Type |SubType|
+-------+-------+-------+-------+
| OctetString ...
+-------+-------+-------+-------+Length: Length of the attribute, which MUST be > 4. 📏
X-Type: RESOURCES 💎
SubType: These are the sub-types for RESOURCES that are defined. IANA acts as a registry for RESOURCES sub-types, as described in section 7, IANA Considerations. At the start, the registry has these sub types for RESOURCES:
1 BANDWIDTH Maximum bandwidth (kbps) authorized.
2 FLOW_SPEC Flow spec specification as defined in RFC 2205.
3 SDP SDP Media Descriptor as defined in RFC 2327.
4 DSCP Differentiated services codepoint as defined in
RFC 2474.OctetString: The OctetString contains the resources specification. 🧁
In scenarios where a resource specification is required (see Section 5), at least one of the subtypes 1 through 4 (inclusive) MUST be included in every Session Authorization Data Policy Element. 👑 Multiple RESOURCE attributes MAY be included if multiple types of resources have been authorized, like DSCP and BANDWIDTH together 🌸
3.3.8 Authentication data
Okay bestie, this is where the signature lives 🔐 The AUTHENTICATION_DATA attribute holds the authentication data for the AUTH_SESSION policy element, and it signs everything in that element up to the AUTHENTICATION_DATA. If you include it, it MUST be the last attribute in the list 💅 Which algorithm makes the authentication data depends on the AUTH_ENT_ID SubType field, and you'll find all the details in Section 4, Integrity of the AUTH_SESSION policy element ✨
Here's the vibe of the format:
+-------+-------+-------+-------+
| Length |X-Type |SubType|
+-------+-------+-------+-------+
| OctetString ...
+-------+-------+-------+-------+- Length: The length of the attribute, which MUST be > 4. 🫶
- X-Type: AUTHENTICATION_DATA 🎀
- SubType: There are no sub types for AUTHENTICATION_DATA defined right now, so this field MUST be set to 0 🌸
- OctetString: This holds the authentication data of the AUTH_SESSION 🔥
4. Integrity of the AUTH_SESSION policy element ✨
This section is all about making sure the policy element's integrity stays intact. No tampering allowed 😤🔒
4.1 Shared symmetric keys 🔑
In shared symmetric key environments, the AUTH_ENT_ID MUST be one of these subtypes: IPV4_ADDRESS, IPV6_ADDRESS, FQDN, ASCII_DN, UNICODE_DN or URI. Here's an example AUTH_SESSION policy element so you can see the shape of it 👀
+--------------+--------------+--------------+--------------+
| Length | P-type = AUTH_SESSION |
+--------------+--------------+--------------+--------------+
| Length |SESSION_ID | zero |
+--------------+--------------+--------------+--------------+
| OctetString (The session identifier) ...
+--------------+--------------+--------------+--------------+
| Length | AUTH_ENT_ID | IPV4_ADDRESS |
+--------------+--------------+--------------+--------------+
| OctetString (The authorizing entity's Identifier) ...
+--------------+--------------+--------------+--------------+
| Length |AUTH DATA. | zero |
+--------------+--------------+--------------+--------------+
| KEY_ID |
+--------------+--------------+--------------+--------------+
| OctetString (Authentication data) ...
+--------------+--------------+--------------+--------------+4.1.1 Operational Setting using shared symmetric keys 🗝️
So this assumes that both the Authorizing Entity and the Network router/PDP are provisioned with shared symmetric keys, plus policies that spell out which algorithm to use for computing the authentication data and the expected length of that data for the algorithm 💖
Key maintenance is out of scope for this document, BUT AUTH_SESSION implementations MUST at least provide the ability to manually configure keys and their parameters locally 🛠️ The key used to produce the authentication data is identified by the AUTH_ENT_ID field. Since multiple keys can be configured for one AUTH_ENT_ID value, the first 32 bits of the AUTH_DATA field MUST be a key ID so the right key can be picked out 🎯 Each key must also be configured with lifetime parameters for the time period in which it's valid, plus an associated cryptographic algorithm parameter that says which algorithm goes with the key. At a minimum, all AUTH_SESSION implementations MUST support the HMAC-MD5-128 [RFC-2104], [RFC-1321] cryptographic algorithm for computing the authentication data. New algorithms may be added through the IETF standards process 🦋
It's good practice to change keys regularly 🔄 Keys MUST be configurable so their lifetimes overlap, which allows smooth transitions between keys. At the midpoint of the lifetime overlap between two keys, senders should transition from the current key to the next/longer-lived key. Meanwhile, receivers simply accept any identified key received within its configured lifetime and reject the ones that aren't 🙌
4.2 Kerberos 🐶
In a Kerberos environment, the AUTH_ENT_ID MUST be of the subtype KRB_PRINCIPAL. The KRB_PRINCIPAL field is defined as the Fully Qualified Kerberos Principal name of the authorizing entity 🪪 Kerberos [RFC-1510] authentication uses a trusted third party, the Kerberos Distribution Center (KDC), to authenticate the AUTH_SESSION to a network server. It's assumed that a KDC is present and that both the host and the verifier of authentication information (the authorizing entity and the router/PDP) implement Kerberos authentication 🏰
Here's an example of the Kerberos AUTH_DATA policy element:
+--------------+--------------+--------------+--------------+
| Length | P-type = AUTH_SESSION |
+--------------+--------------+--------------+--------------+
| Length |SESSION_ID | zero |
+--------------+--------------+--------------+--------------+
| OctetString (The session identifier) ...
+--------------+--------------+--------------+--------------+
| Length | AUTH_ENT_ID | KERB_P. |
+--------------+--------------+--------------+--------------+
| OctetString (The principal@realm name) ...
+--------------+--------------+--------------+--------------+4.2.1. Operational Setting using Kerberos 🎟️
The authorizing entity is configured to build the AUTH_SESSION policy element so that it uses the Kerberos authentication method (KRB_PRINCIPAL) as defined in RFC 1510. When the resource reservation request arrives, the router/PDP contacts its local KDC with a KRB_AS_REQ message to ask for credentials for the authorizing entity (principal@realm) 📨 In that request, the client (router/PDP) sends, in cleartext, its own identity and the identity of the server it wants credentials for (the authorizing entity, taken from the AUTH_ENT_ID field). The local KDC answers with those credentials in a KRB_AS_REP message, encrypted in the client's key 🔐 The credentials are 1) a "ticket" for the server and 2) a temporary encryption key (often called a "session key") 🎫
The router/PDP uses the ticket to reach the authorizing entity with a KRB_AP_REQ message. The session key, now shared by the router/PDP and the authorizing entity, is used to authenticate the router/PDP, and it's also used to authenticate the authorizing entity. The session key is an encryption key, and it's also used to encrypt further communication between the two parties 🤝 The authorizing entity replies with a concatenated message made of a KRB_AP_REP and a KRB_SAFE. The KRB_AP_REP is used to authenticate the authorizing entity, and the KRB_SAFE message carries the authentication data in its safe-body field. The authentication data must be either a 16 byte MD5 hash or a 20 byte SHA-1 hash of all the data in the AUTH_SESSION policy element up to the AUTHENTICATION_DATA. (Heads up: when you're using Kerberos, the AUTH_SESSION PE should not include AUTHENTICATION_DATA, because that gets sent in the KRB_SAFE message instead 🙈) The router/PDP computes the hash independently and compares it with the received hash in the user-data field of the KRB-SAFE-BODY [RFC-1510] 🧮
At a minimum, all AUTH_SESSION implementations using Kerberos MUST support the Kerberos des-cbc-md5 encryption type [RFC-1510] (for encrypted data in tickets and Kerberos messages) and the Kerberos rsa-md5-des checksum type [RFC-1510] (for the KRB_SAFE checksum). New algorithms may be added through the IETF standards process. Triple-DES encryption is supported by many Kerberos implementations (even though it isn't specified in [RFC-1510]), and it SHOULD be used over single DES 💪
For cases where the authorizing entity is in a different realm (aka a different administrative domain or organizational boundary), the router/PDP needs to fetch a cross-realm Ticket Granting Ticket (TGT) from its local KDC. That TGT can then be used to fetch authorizing entity tickets from the KDC in the remote realm. For performance reasons, tickets are typically cached for extended periods ⏳
4.3 Public Key 🔏
In a public key environment, the AUTH_ENT_ID MUST be one of these subtypes: X509_V3_CERT or PGP_CERT. The authentication data is used to authenticate the authorizing entity 🪄 Here's an example of the public key AUTH_SESSION policy element:
+--------------+--------------+--------------+--------------+
| Length | P-type = AUTH_SESSION |
+--------------+--------------+--------------+--------------+
| Length |SESSION_ID | zero |
+--------------+--------------+--------------+--------------+
| OctetString (The session identifier) ...
+--------------+--------------+--------------+--------------+
| Length | AUTH_ENT_ID | PGP_CERT |
+--------------+--------------+--------------+--------------+
| OctetString (Authorizing entity Digital Certificate) ...
+--------------+--------------+--------------+--------------+
| Length |AUTH DATA. | zero |
+--------------+--------------+--------------+--------------+
| OctetString (Authentication data) ...
+--------------+--------------+--------------+--------------+4.3.1. Operational Setting for public key based authentication 🧁
Public key based authentication assumes the following:
- Authorizing entities have a pair of keys (a private key and a public key). 🗝️
- The private key is secured by the authorizing entity. 🔒
- Public keys are stored in digital certificates, and a trusted party, a certificate authority (CA), issues these digital certificates. 📜
- The verifier (PDP or router) has the ability to verify the digital certificate. ✅
The authorizing entity uses its private key to generate AUTHENTICATION_DATA. Authenticators (router, PDP) use the authorizing entity's public key (stored in the digital certificate) to verify and authenticate the policy element 🌈
4.3.1.1 X.509 V3 digital certificates ✨
okay so when the AUTH_ENT_ID is X509_V3_CERT, the AUTHENTICATION_DATA MUST be generated by following these steps 🎀
- A Signed-data gets built the way section 5 of CMS [RFC-3369] describes 📜. A digest is computed over the content (as specified in section 6.1) using a signer-specific message-digest algorithm. The certificates field holds the chain of the authorizing entity's X.509 V3 digital certificates. The certificate revocation list lives in the crls field. Then the digest output gets digitally signed following section 8 of RFC 3447, using the signer's private key ✍️
When the AUTH_ENT_ID is X509_V3_CERT, verification MUST be done by following these steps 🔍
- Parse the X.509 V3 certificate to pull out the distinguished name of the certificate's issuer.
- Certification Path Validation gets performed the way section 6 of RFC 3280 defines it 🛤️
- Parse through the Certificate Revocation list to check that the received certificate is not listed there 🚫
- Once the X.509 V3 certificate is validated, you can extract the public key of the authorizing entity from it 🔑
- Pull out the digest algorithm and the length of the digested data by parsing the CMS signed-data 📦
- The recipient independently computes the message digest. That message digest plus the signer's public key are used to verify the signature value ✨
This verification ensures integrity, non-repudiation and data origin. Lowkey the whole point, bestie 🫶
4.3.1.2 PGP digital certificates 🌈
When the AUTH_ENT_ID is PGP_CERT, AUTHENTICATION_DATA MUST be generated by following these steps 💜
AUTHENTICATION_DATAcontains a Signature Packet as defined in section 5.2.3 of RFC 2440. The short version:- Compute the hash of all data in the AUTH_SESSION policy element up to the
AUTHENTICATION_DATA🧮 - The hash output is digitally signed following section 8 of RFC 3447, using the signer's private key 🖊️
- Compute the hash of all data in the AUTH_SESSION policy element up to the
When the AUTH_ENT_ID is PGP_CERT, verification MUST be done by following these steps 🕵️♀️
- Validate the certificate ✅
- Once the PGP certificate is validated, the public key of the authorizing entity can be extracted from it 🗝️
- Extract the hash algorithm and the length of the hashed data by parsing the PGP signature packet 📚
- The recipient independently computes the message digest. That message digest and the signer's public key are used to verify the signature value 💅
This verification ensures integrity, non-repudiation and data origin. Iconic, honestly 👑
5. Framework 🦋
[RFC-3521] describes a framework in which the AUTH_SESSION policy element can be utilized to transport the information needed for authorizing resource reservation for media flows 🎬. [RFC-3521] introduces 4 different models:
- the coupled model
- the associated model with one policy server
- the associated model with two policy servers
- the non-associated model
The fields that are required in an AUTH SESSION policy element depend on which of the models is used 🧩.
5.1 The coupled model 💞
In the Coupled Model, the only information that MUST be included in the policy element is the SESSION_ID. It's what the Authorizing Entity uses to correlate the resource reservation request with the media that got authorized during session set up 🔗. Since the End Host is assumed to be untrusted, the Policy Server SHOULD take measures to ensure that the integrity of the SESSION_ID is preserved in transit 🛡️. The exact mechanisms to be used and the format of the SESSION_ID are implementation dependent 🤷♀️.
5.2 The associated model with one policy server 🌸
In this model, the contents of the AUTH_SESSION policy element MUST include:
- A session identifier - SESSION_ID. This is info the authorizing entity can use to correlate the resource reservation request with the media authorized during session set up 🪪.
- The identity of the authorizing entity - AUTH_ENT_ID. The Edge Router uses this to figure out which authorizing entity (Policy Server) it should ask for resource policy decisions 🧭.
In some environments, an Edge Router may have no means of checking whether the identity refers to a legitimate Policy Server within its domain 😬. To protect against authorization requests getting redirected to a bogus authorizing entity, the AUTH_SESSION MUST also include:
- AUTHENTICATION_DATA. This authentication data is calculated over all other fields of the AUTH_SESSION policy element 🔐.
5.3 The associated model with two policy servers 🍓
The content of the AUTH_SESSION Policy Element is identical to the associated model with one policy server. Same vibes, no notes 💅.
5.4 The non-associated model 🧚
In this model, the AUTH_SESSION MUST contain enough information to let the Policy Server make resource policy decisions on its own, without going back to the authorizing entity 🙌. The policy element is created using information about the session that the authorizing entity has. The information in the AUTH_SESSION policy element MUST include:
- Calling party IP address or Identity (e.g., FQDN) - SOURCE_ADDR X-TYPE
- Called party IP address or Identity (e.g., FQDN) - DEST_ADDR X-TYPE
- The characteristics of (each of) the media stream(s) authorized for this session - RESOURCES X-TYPE
- The authorization lifetime - START_TIME X-TYPE
- The identity of the authorizing entity, so the token can be validated in shared symmetric key and Kerberos schemes - AUTH_ENT_ID X-TYPE
- The credentials of the authorizing entity in a public-key scheme - AUTH_ENT_ID X-TYPE
- Authentication data used to prevent tampering with the AUTH_SESSION policy element - AUTHENTICATION_DATA
Furthermore, the AUTH_SESSION policy element MAY contain:
- The lifetime of (each of) the media stream(s) - END_TIME X-TYPE
- Calling party port number - SOURCE_ADDR X-TYPE
- Called party port number - DEST_ADDR X-TYPE
All AUTH_SESSION fields MUST match the resource request. If a field doesn't match, the request SHOULD be denied 🚫✨.
6. Message Processing Rules 💖
6.1 Generation of the AUTH_SESSION by the authorizing entity 🎀
- Generate the AUTH_SESSION policy element with the appropriate contents as specified in section 5.
- If authentication is needed, the entire AUTH_SESSION policy element is constructed, excluding the length, type and subtype fields of the AUTH_SESSION field. Note that the message MUST include either a START_TIME or a SESSION_ID (See Section 9) to prevent replay attacks 🔁. The output of the authentication algorithm, plus appropriate header information, is appended to the AUTH_SESSION policy element.
6.2 Message Generation (RSVP Host) 📮
An RSVP message is created as specified in [RFC-2205] with the following modifications.
- An RSVP message MUST contain at most one AUTH_SESSION policy element.
- The AUTH SESSION policy element received from the authorizing entity (Section 3.2) MUST be copied without modification into the POLICY DATA object 📋.
- The POLICY_DATA object (containing the AUTH_SESSION policy element) is inserted into the RSVP message in the appropriate place 🧁.
6.3 Message Reception (RSVP-aware Router) 🛣️
An RSVP message is processed as specified in [RFC-2205] with the following modifications.
- If the router is policy aware, it SHOULD send the RSVP message to the PDP and wait for a response. If the router is policy unaware, it ignores the policy data objects and keeps processing the RSVP message 👀.
- Reject the message if the response from the PDP is negative ❌.
- Continue processing the RSVP message 🏃♀️.
6.4 Authorization (Router/PDP) 👑
- Retrieve the AUTH_SESSION policy element. Check the PE type field and return an error if the identity type is not supported 🙅♀️.
- Verify the message integrity 🔐.
- Shared symmetric key authentication: The Network router/PDP uses the AUTH_ENT_ID field to consult a table keyed by that field. The table should identify the cryptographic authentication algorithm to be used, along with the expected length of the authentication data and the shared symmetric key for the authorizing entity. Verify that the indicated length of the authentication data is consistent with the configured table entry, then validate the authentication data 🗂️.
- Public Key: Validate the certificate chain against the trusted Certificate Authority (CA) and validate the message signature using the public key 🔏.
- Kerberos Ticket: If the AUTH_ENT_ID is of subtype KRB_PRINCIPAL, Request a ticket for the authorizing entity (principal@realm) from the local KDC. Use the ticket to access the authorizing entity and obtain authentication data for the message 🎟️.
- Once the identity of the authorizing entity and the validity of the service request have been established, the authorizing router/PDP MUST then consult its local policy tables (the contents of which are a local matter) to determine whether or not the specific request is authorized 📖. To the extent that these access control decisions require supplementary information, routers/PDPs MUST ensure that the supplementary information is obtained securely. An example of insecure access control decisions would be if the authorizing party relies upon an insecure database (such as DNS or a public LDAP directory) and authorizes with a certificate or an FQDN 🚨. Yikes, not it 💀.
- Verify the requested resources do not exceed the authorized QoS 📊.
7. Error Signaling 🚨
If a PDP fails to verify the AUTH_SESSION policy element, it MUST return a policy control failure (Error Code = 02) to the PEP 🙅♀️. The error values are described in [RFC-2205] and [RFC-2750]. The PDP SHOULD also supply a policy data object containing an AUTH_DATA Policy Element with A-Type=POLICY_ERROR_CODE, which holds more details on the Policy Control failure [RFC-3182] 🧾. If RSVP is being used, the PEP MUST include this Policy Data object in the outgoing RSVP Error message 📨.
8. IANA Considerations ✨
okay bestie, IANA is the registry keeper for all the Internet's numbers, and this section is basically the big "who gets which number" list for RSVP authorization stuff 📋💖 Here's the vibe: the rules are set out in [IANA-CONSIDERATIONS], and it's giving "IETF Consensus" for the Standard RSVP Policy Elements (P-type values), as described in [RFC-2750] 🫶
P-Type AUTH_SESSION is assigned the value 0x04.The session authorization attribute types (X-Type) in the range 0-127 are handed out through an IETF Consensus action, and X-Type values between 128-255 are reserved for Private Use and are not assigned by IANA 🔥
X-Type AUTH_ENT_ID is assigned the value 1.
X-Type SESSION_ID is assigned the value 2.
X-Type SOURCE_ADDR is assigned the value 3.
X-Type DEST_ADDR is assigned the value 4.
X-Type START_TIME is assigned the value 5.
X-Type END_TIME is assigned the value 6.
X-Type RESOURCES is assigned the value 7.
X-Type AUTHENTICATION_DATA is assigned the value 8.For AUTH_ENT_ID SubTypes, the range 0-127 goes through IETF Consensus, and 128-255 is Private Use, not IANA territory 🦋
AUTH_ENT_ID SubType IPV4_ADDRESS is assigned the value 1.
SubType IPV6_ADDRESS is assigned the value 2.
SubType FQDN is assigned the value 3.
SubType ASCII_DN is assigned the value 4.
SubType UNICODE_DN is assigned the value 5.
SubType URI is assigned the value 6.
SubType KRB_PRINCIPAL is assigned the value 7.
SubType X509_V3_CERT is assigned the value 8.
SubType PGP_CERT is assigned the value 9.For SOURCE_ADDR SubTypes, same deal: 0-127 is IETF Consensus, 128-255 is Private Use 🌸
SOURCE_ADDR SubType IPV4_ADDRESS is assigned the value 1.
SubType IPV6_ADDRESS is assigned the value 2.
SubType UDP_PORT_LIST is assigned the value 3.
SubType TCP_PORT_LIST is assigned the value 4.DEST_ADDR SubTypes follow the same pattern: 0-127 through IETF Consensus, 128-255 for Private Use 💜
DEST_ADDR SubType IPV4_ADDRESS is assigned the value 1.
SubType IPV6_ADDRESS is assigned the value 2.
SubType UDP_PORT_LIST is assigned the value 3.
SubType TCP_PORT_LIST is assigned the value 4.START_TIME SubTypes: 0-127 is IETF Consensus, 128-255 is Private Use ⭐
START_TIME SubType NTP_TIMESTAMP is assigned the value 1.END_TIME SubTypes: same rules, 0-127 IETF Consensus, 128-255 Private Use 🎀
END_TIME SubType NTP_TIMESTAMP is assigned the value 1.RESOURCES SubTypes: 0-127 through IETF Consensus, 128-255 is Private Use 🍓
RESOURCES SubType BANDWIDTH is assigned the value 1.
SubType FLOW_SPEC is assigned the value 2.
SubType SDP is assigned the value 3.
SubType DSCP is assigned the value 4.9. Security Considerations 🙈
okay this section is SERIOUS, bestie, so buckle up 😭
The whole point of this document is to describe a mechanism for session authorization to prevent theft of service. Basically, stop people from freeloading on resources they never paid for 💅
Replay attacks MUST be prevented. In the non-associated model, the AUTH_SESSION policy element MUST include a START_TIME field and the Policy Servers MUST support NTP to ensure proper clock synchronization. Failure to ensure proper clock synchronization will allow replay attacks, since the clocks of the different network entities may not be in-synch. The start time is used to verify that the request is not being replayed at a later time. In all other models, the SESSION_ID is used by the Policy Server to ensure that the resource request successfully correlates with records of an authorized session. If a AUTH_SESSION is replayed, it MUST be detected by the policy server (using internal algorithms) and the request MUST be rejected. 💀
To keep the integrity of the policy element intact in untrusted environments, the AUTHENTICATION_DATA attribute MUST be included 🔒
In environments where shared symmetric keys are possible, they should be used so the AUTH_SESSION policy element stays at a strict minimum size. This is especially true in wireless environments, where the AUTH_SESSION policy element is sent over-the-air 📡 The shared symmetric keys authentication option MUST be supported by all AUTH_SESSION implementations.
If shared symmetric keys aren't a valid option, the Kerberos authentication mechanism is reasonably well secured and efficient in terms of AUTH_SESSION size. The AUTH_SESSION only needs to contain the principal@realm name of the authorizing entity, which is much more efficient than the PKI authentication option 🧚
The PKI authentication option provides a high level of security and good scalability. However, it requires credentials to be present in the AUTH_SESSION policy element, which impacts its size 🌈
10. Acknowledgments 🫶
Huge thanks to Francois Audet, Don Wade, Hamid Syed, Kwok Ho Chan, and many others for their valuable comments. Special shoutout to Eric Rescorla, who left numerous comments and suggestions that improved this document 👑
We also want to thank S. Yadav, et al., for their efforts on RFC 3182, since this document borrows from their work 💜
11. Normative References 📚
[ASCII] Coded Character Set -- 7-Bit American Standard
Code for Information Interchange, ANSI X3.4-
1986.
[X.509-ITU] ITU-T (formerly CCITT) Information technology
Open Systems Interconnection - The Directory:
Authentication Framework Recommendation X.509
ISO/IEC 9594-8
[RFC-1034] Mockapetris, P., "Domain names - concepts and
facilities", STD 13, RFC 1034, November 1987.
[RFC-1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation, and Analysis",
RFC 1305, March 1992.
[RFC-1321] Rivest, R., "The MD5 Message-Digest Algorithm",
RFC 1321, April 1992.
[RFC-1510] Kohl, J. and C. Neuman, "The Kerberos Network
Authentication Service (V5)", RFC 1510,
September 1993.
[RFC-2104] Krawczyk, H., Bellare, M. and R. Canetti,
"HMAC: Keyed-Hashing for Message
Authentication", RFC 2104, February 1997.
[RFC-2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, RFC 2119,
March 1997.
[RFC-2205] Braden, R., Ed., 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-2253] Wahl, M., Kille, S. and T. Howes , "UTF-8
String Representation of Distinguished Names",
RFC 2253, December 1997.
[RFC-2279] Yergeau, F., "UTF-8, a transformation format of
ISO 10646", RFC 2279, January 1998.
[RFC-2327] Handley, M. and V. Jacobson, "SDP: Session
Description Protocol", RFC 2327, October 1998.
[RFC-2396] Berners-Lee, T., Fielding, R., Masinter, L.,
"Uniform Resource Identifiers (URI): Generic
Syntax", RFC 2396, August 1998.
[RFC-2440] Callas, J., Donnerhacke, L., Finney, H. and R.
Thayer, "OpenPGP Message Format", RFC 2440,
November 1998.
[RFC-2474] Nichols, K., Blake, S., Baker, F. and D. Black,
"Definition of the Differentiated Services
Field (DS Field) in the IPv4 and IPv6 Headers",
RFC 2474, December 1998.
[RFC-2750] Herzog, S., "RSVP Extensions for Policy
Control", RFC 2750, January 2000.
[RFC-2753] Yavatkar, R., Pendarakis, D. and R. Guerin, "A
Framework for Policy-based Admission Control
RSVP", RFC 2753, January 2000.
[RFC-3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P.,
Moore, T., Herzog, S. and R. Hess, "Identity
Representation for RSVP", RFC 3182, October
2001
[RFC-3280] Housley, R., Polk, W., Ford, W. and D. Solo,
"Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List
(CRL) Profile", RFC 3280, April 2002.
[RFC-3369] Housley, R., "Cryptographic Message Syntax",
RFC 3369, August 2002.
[RFC-3447] Jonsson, J. and B. Kaliski, "Public-Key
Cryptography Standards (PKCS) #1: RSA
Cryptography Specifications Version 2.1", RFC
3447, February 2003.
[RFC-3521] Hamer, L.-N., Gage, B. and H. Shieh, "Framework
for Session Setup with Media Authorization",
RFC 3521, April 2003.12. Informative References 🦋
[IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for
Writing an IANA Considerations Section in
RFCs", BCP 26, RFC 2434, October 1998.
[RFC-3261] Rosenberg, J., Schulzrinne, H., Camarillo, G.,
Johnston, A., Peterson, J., Sparks, R.,
Handley, M. and E. Schooler, "SIP: Session
Initiation Protocol", RFC 3261, June 2002.13. Intellectual Property Statement ✨
okay so this section is basically the IETF being like "we're not saying whether any patents or rights apply to this tech, and we haven't gone looking for them" 🙈 it's giving legal disclaimer energy, but the vibe is still very much "figure out your own licensing, bestie." 💅
if you want the paperwork on how the IETF handles rights for standards-track stuff, go read BCP-11. 📜 anyone who wants copies of claimed rights or license assurances can ask the IETF Secretariat. 🫶
and the IETF is also inviting anyone who knows about copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to practice this standard to tell them. 🦋 send it to the IETF Executive Director. 👑
14. Contributors 🎀
big shoutout to the folks who helped make this happen:
Matt Broda Nortel Networks
EMail: mbroda@nortelnetworks.com
Louis LeVay Nortel Networks
EMail: levay@nortelnetworks.com
Dennis Beard Nortel Networks
EMail: beardd@nortelnetworks.com
Lawrence Dobranski Nortel Networks
EMail: ldobran@nortelnetworks.com
15. Authors' Addresses 💌
these are the people who wrote it, and where to find them 🦋
Louis-Nicolas Hamer Nortel Networks PO Box 3511 Station C Ottawa, Ontario Canada K1Y 4H7
Phone: +1 613.768.3409 EMail: nhamer@nortelnetworks.com
Brett Kosinski Invidi Technologies Edmonton, Alberta Canada T5J 3S4
EMail: brettk@invidi.com
Bill Gage Nortel Networks PO Box 3511 Station C Ottawa, Ontario Canada K1Y 4H7
Phone: +1 613.763.4400 EMail: gageb@nortelnetworks.com
Hugh Shieh AT&T Wireless 7277 164th Avenue NE Redmond, WA USA 98073-9761
Phone: +1 425.580.6898 EMail: hugh.shieh@attws.com
16. Full Copyright Statement 🌈
Copyright (C) The Internet Society (2003). All Rights Reserved. 💖
this document and translations of it can be copied and shared, and people can write derivative works that comment on or explain it or help implement it, and publish and distribute them, in whole or in part, without restriction of any kind, as long as the copyright notice and this paragraph stay on all copies and derivative works. ✨
however, this document itself can't be modified in any way, like removing the copyright notice or references to the Internet Society or other Internet organizations. 🙅♀️ the exceptions are when it's needed for developing Internet standards (then the Internet Standards process copyright procedures must be followed) or when it's translated into languages other than English. 🌸
the limited permissions above are perpetual and won't be revoked by the Internet Society or its successors or assigns. 💜
this document and the information in it 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. 💅
📦 where this page comes from
- ietf: rfc3520 2003-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms