RFC 5981

Authorization for NSIS Signaling Layer Protocols

📅 published February 2011, from ietf

RFC 5981 🦋 Authorization for NSIS Signaling Layer Protocols

Okay bestie, this is RFC 5981, called "Authorization for NSIS Signaling Layer Protocols" 💅. It's an Experimental document, not a Standards Track one, so it's published for examination, experimentation, and evaluation 🧪. The ISSN is 2070-1721, and it's dated February 2011. The authors are J. Manner (Aalto University), M. Stiemerling (NEC), H. Tschofenig (Nokia Siemens Networks), and R. Bless, Ed. (KIT) 🫶. The header doesn't list any RFCs it obsoletes or updates, so there's nothing to report on that front 🙈.

Abstract

Okay so, signaling layer protocols in the NSIS framework can lean on GIST to handle authorization ✨. But the signaling layer protocol sitting above GIST might still need its own separate authorization step when a node gets a request for a certain kind of service or resources 🔐. This doc gives a generic model and object formats for session authorization inside the NSIS signaling layer protocols 🧩. The whole point is letting network elements swap info so they can authorize resource use for a service, and coordinate actions between the signaling plane and the transport plane. Iconic, honestly 👑.

Status of This Memo

This document is not an Internet Standards Track specification 💅. It's published for examination, experimental implementation, and evaluation 🧪.

This document defines an Experimental Protocol for the Internet community 🌈. It's a product of the Internet Engineering Task Force (IETF), and it represents the consensus of the IETF community 🫶. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) ✨. Not every IESG-approved document is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 for the details 📚.

For info on the current status of this document, any errata, and how to send feedback, head to http://www.rfc-editor.org/info/rfc5981 🔗.

Copyright Notice

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please read these carefully, because they spell out your rights and restrictions for this document 📜. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License 💜.

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
2.  Conventions Used in This Document  . . . . . . . . . . . . . .  4
3.  Session Authorization Object . . . . . . . . . . . . . . . . .  4
  3.1.  Session Authorization Object format  . . . . . . . . . . .  5
  3.2.  Session Authorization Attributes . . . . . . . . . . . . .  6
    3.2.1.  Authorizing Entity Identifier  . . . . . . . . . . . .  7
    3.2.2.  Session Identifier . . . . . . . . . . . . . . . . . .  9
    3.2.3.  Source Address . . . . . . . . . . . . . . . . . . . .  9
    3.2.4.  Destination Address  . . . . . . . . . . . . . . . . . 11
    3.2.5.  Start Time . . . . . . . . . . . . . . . . . . . . . . 12
    3.2.6.  End Time . . . . . . . . . . . . . . . . . . . . . . . 13
    3.2.7.  NSLP Object List . . . . . . . . . . . . . . . . . . . 13
    3.2.8.  Authentication Data  . . . . . . . . . . . . . . . . . 15
4.  Integrity of the SESSION_AUTH Object . . . . . . . . . . . . . 15
  4.1.  Shared Symmetric Keys  . . . . . . . . . . . . . . . . . . 15
    4.1.1.  Operational Setting Using Shared Symmetric Keys  . . . 16
  4.2.  Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . 17
  4.3.  Public Key . . . . . . . . . . . . . . . . . . . . . . . . 18
    4.3.1.  Operational Setting for Public-Key-Based
            Authentication . . . . . . . . . . . . . . . . . . . . 19
  4.4.  HMAC Signed  . . . . . . . . . . . . . . . . . . . . . . . 21
5.  Framework  . . . . . . . . . . . . . . . . . . . . . . . . . . 23
  5.1.  The Coupled Model  . . . . . . . . . . . . . . . . . . . . 23
  5.2.  The Associated Model with One Policy Server  . . . . . . . 23
  5.3.  The Associated Model with Two Policy Servers . . . . . . . 24
  5.4.  The Non-Associated Model . . . . . . . . . . . . . . . . . 24
6.  Message Processing Rules . . . . . . . . . . . . . . . . . . . 25
  6.1.  Generation of the SESSION_AUTH by an Authorizing Entity  . 25
  6.2.  Processing within the QoS NSLP . . . . . . . . . . . . . . 25
    6.2.1.  Message Generation . . . . . . . . . . . . . . . . . . 25
    6.2.2.  Message Reception  . . . . . . . . . . . . . . . . . . 26
    6.2.3.  Authorization (QNE or PDP) . . . . . . . . . . . . . . 26
    6.2.4.  Error Signaling  . . . . . . . . . . . . . . . . . . . 27
  6.3.  Processing with the NATFW NSLP . . . . . . . . . . . . . . 27
    6.3.1.  Message Generation . . . . . . . . . . . . . . . . . . 28
    6.3.2.  Message Reception  . . . . . . . . . . . . . . . . . . 28
    6.3.3.  Authorization (Router/PDP) . . . . . . . . . . . . . . 28
    6.3.4.  Error Signaling  . . . . . . . . . . . . . . . . . . . 29
  6.4.  Integrity Protection of NSLP Messages  . . . . . . . . . . 29
7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 30
8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 31
9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 34
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
  10.1. Normative References . . . . . . . . . . . . . . . . . . . 34
  10.2. Informative References . . . . . . . . . . . . . . . . . . 35

1. Introduction ✨

Okay so the Next Steps in Signaling (NSIS) framework [RFC4080] is a whole suite of protocols for the next generation of Internet signaling 🚀. It's built on a generalized transport protocol for signaling apps, the General Internet Signaling Transport (GIST) [RFC5971], plus a bunch of different signaling applications 🎀. Two signaling applications and their NSIS Signaling Layer Protocol (NSLP) have been designed so far: a Quality of Service application (QoS NSLP) [RFC5974] and a NAT/firewall application (NATFW NSLP) [RFC5973] 💖.

The basic security architecture for NSIS is a chain-of-trust model 🔗. Each GIST hop may pick the appropriate security protocol, depending on what the signaling application needs 🔒. For example, two directly adjacent GIST peers may secure their communication with TCP/TLS 🧚. This is giving flexibility 💅: it works for a lot of different use cases, and it lets the signaling applications hand off security to GIST entirely ✨. The catch is that several sessions from different signaling applications then get multiplexed onto the same GIST TLS connection 👀.

Yet, if you want finer-grained per-session or per-user admission control, you need a way to make sure a host's use of resources has been properly authorized before the signaling application commits the resource request 🫣. Think a QoS reservation or NAT traversal mappings 🌸. To pull that off, there has to be info inside the NSLP message that can be used to verify the request is valid 🔍. The fix is to give the host a Session Authorization Object, which gets inserted into the message and then verified by the respective network elements 🛡️.

This document describes a generic NSLP-layer Session Authorization Object (SESSION_AUTH) that carries authorization info for the request 🎟️. "Generic" here means every NSLP can use it 🌈. The scheme is built on third-party tokens: a trusted third party hands out authentication tokens to clients and lets network elements verify the info 🤝. The requesting host puts the authorization info (for example, a policy object) it got from that trusted third party into the NSLP message, so the network resource request can be verified 📋. Then the network elements check the request and process it based on admission policy. For example, they might do a resource reservation, change bindings, or set a firewall filter 🧱. This work builds on RFC 3520 [RFC3520] and RFC 3521 [RFC3521] 💜.

By default, using NSLP-layer session authorization means adding one authorization policy object 🎀. But to support end-to-end signaling and request authorization across different networks, a host starting an NSLP signaling session can add more than one SESSION_AUTH object to the message 🌟. The identifier of the authorizing entity lets network elements use whichever third party they trust to verify the request 🫶.

2. Conventions Used in This Document

Okay, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in BCP 14, RFC 2119 [RFC2119] 📖. Read them carefully, bestie 🧐.

The term "NSLP node" (NN) refers to an NSIS node running an NSLP that can use the authorization object covered in this document 💅. Right now, that node would run either the QoS NSLP [RFC5974] or the NAT/Firewall NSLP [RFC5973] service 🦋.

3. Session Authorization Object 🌸

This section introduces a new NSLP-layer object called session authorization (SESSION_AUTH) 💖. The SESSION_AUTH object can be used in the NSLP protocols that are currently specified, and in future ones too 🔮.

The authorization attributes follow the format and specification given in RFC3520 [RFC3520] 📚. Slay 👑.

3.1. Session Authorization Object format 📦

Okay so the SESSION_AUTH object is basically a bundle of fields that describe the session, plus some other attributes 💅 Its header follows the generic NSLP object header, which means it can be used with any NSLP. Iconic, right? 🎀

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |A|B|r|r|         Type          |r|r|r|r|        Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +                                                               +
   //         Session Authorization Attribute List                //
   +                                                               +
   +---------------------------------------------------------------+

The value for the Type field comes from the shared NSLP object type space 🧚 The Length field is measured in 32-bit words and counts the Value part of the TLV object. So it does not include the standard header, bestie.

The bits marked A and B are extensibility flags 🦋 They decide what happens to objects whose treatment hasn't been defined in the protocol spec, meaning objects whose Type the receiver doesn't recognise. There are four categories. They're here just for your information, and the real normative behaviour lives in the particular NSLP documents, like [RFC5974] [RFC5973].

AB=00 ("Mandatory"): If the object isn't understood, the entire message containing it MUST be rejected, and an error message MUST be sent back (usually with class/code "Protocol Error/Unknown object present") 😭
AB=01 ("Ignore"): If the object isn't understood, it MUST be deleted, and the rest of the message gets processed as usual 🌸
AB=10 ("Forward"): If the object isn't understood, it MUST be retained unchanged in any message forwarded as a result of message processing, but it MUST NOT be stored locally 🧺
AB=11 ("Refresh"): If the object isn't understood, it should be incorporated into the locally stored signaling application state for this flow/session, forwarded in any resulting message, and also used in any refresh or repair message generated locally. This flag combo isn't used by every NSLP. For example, it isn't used in the NATFW NSLP 🙈

The remaining r bits are reserved 🔒 The extensibility flags follow the definition in the GIST spec. The SESSION_AUTH object defined here MUST have the AB bits set to "10" ✨ An NSLP Node (NN) may use the authorization information if it's configured to, but it may also just skip the object. Totally valid, no judgement 🫶

Here are the key details:

Type: SESSION_AUTH_OBJECT (0x016)

Length: Variable, contains length of session authorization object list in units of 32-bit words.

Session Authorization Attribute List: variable length

The session authorization attribute list is a collection of objects that describes the session and gives any other info needed to verify a resource request (like a resource reservation, binding, or firewall filter change request) 💖 An initial set of valid objects is described in Section 3.2.

3.2. Session Authorization Attributes 🎀

A session authorization attribute can hold all kinds of info, and it has both an attribute type and a sub-type 🌈 The attribute itself MUST be a multiple of 4 octets long. Any attribute that isn't a multiple of 4 octets MUST be padded out to a 4-octet boundary, and all padding bytes MUST have a value of zero 💜

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Length             |    X-Type     |   SubType     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                           Value ...                         //
   +---------------------------------------------------------------+

Length: 16 bits 📏

The Length field is two octets and tells you the actual length of the attribute in octets, counting the Length, X-Type, and SubType fields too. The length does not include any padding added to the value field to make the attribute a multiple of 4 octets. Padding is not your friend here, sis 🙈

X-Type: 8 bits 🔑

The X-Type field (the session authorization attribute type) is one octet. IANA acts as a registry for X-Types, as described in Section 8, IANA Considerations 📋 This spec uses the following X-Types:

AUTH_ENT_ID: The unique identifier of the entity that authorized the session 👑
SESSION_ID: The unique identifier for this session, usually created locally at the authorizing entity. See also RFC 3520 [RFC3520]. Don't mix it up with the SESSION-ID of GIST/NSIS, that's a different thing 🙃
SOURCE_ADDR: The address specification for the signaling session initiator, i.e., the source address of the signaling message originator 🧭
DEST_ADDR: The address specification for the signaling session endpoint 🎯
START_TIME: The starting time for the session ⏰
END_TIME: The end time for the session ⌛
AUTHENTICATION_DATA: The authentication data of the Session Authorization Object 🔐

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 💖

3.2.1. Authorizing Entity Identifier 🪪

The AUTH_ENT_ID identifies the entity that authorized the initial service request and generated the Session Authorization Object ✨ It can be represented in various formats, and the SubType is what defines the format of the ID. Here's the layout:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Length             |    X-Type     |   SubType     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                        OctetString ...                      //
   +---------------------------------------------------------------+

Length: Length of the attribute, which MUST be > 4.

X-Type: AUTH_ENT_ID

SubType: here's the list of defined sub-types for AUTH_ENT_ID. IANA acts as a registry for AUTH_ENT_ID SubTypes too, as described in Section 8, IANA Considerations. To start, the registry holds these SubTypes of AUTH_ENT_ID:

IPV4_ADDRESS: IPv4 address represented in 32 bits 🌐
IPV6_ADDRESS: IPv6 address represented in 128 bits 🌍
FQDN: Fully Qualified Domain Name as defined in [RFC1034], as an ASCII string 🏷️
ASCII_DN: X.500 Distinguished name as defined in [RFC4514], as an ASCII string 📇
UNICODE_DN: X.500 Distinguished name as defined in [RFC4514], as a UTF-8 string 🪄
URI: Universal Resource Identifier, as defined in [RFC3986] 🔗
KRB_PRINCIPAL: Fully Qualified Kerberos Principal name, represented by the ASCII string of a principal followed by the @ realm name as defined in [RFC4120] (e.g., johndoe@nowhere) 🎫
X509_V3_CERT: The Distinguished Name of the subject of the certificate, as defined in [RFC4514] as a UTF-8 string 📜
PGP_CERT: The OpenPGP certificate of the authorizing entity, as defined as Public-Key Packet in [RFC4880] 🔏
HMAC_SIGNED: Indicates that the AUTHENTICATION_DATA attribute contains a self-signed HMAC signature [RFC2104] that ensures the integrity of the NSLP message. The HMAC is calculated over all NSLP objects given in the NSLP_OBJECT_LIST attribute, which MUST also be present. The object specifies the hash algorithm used for the HMAC calculation as a Transform ID from Transform Type 3 of the IKEv2 registry [RFC5996] 🛡️

OctetString: Contains the authorizing entity identifier.

3.2.2. Session Identifier 🆔

SESSION_ID is a unique identifier that the authorizing entity uses to identify the request 💜 It can be used for a bunch of things, including replay detection, or to link this request to a policy decision entry the authorizing entity made. For example, the SESSION_ID can be based on simple sequence numbers or on a standard NTP timestamp ⏱️

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Length             |    X-Type     |   SubType     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                        OctetString ...                      //
   +---------------------------------------------------------------+

Length: Length of the attribute, which MUST be > 4.

X-Type: SESSION_ID

SubType: no sub-types for SESSION_ID are defined yet, so 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. That means the contents and format are implementation dependent, so the sky's the limit 🌈

OctetString: The OctetString contains the session identifier.

3.2.3. Source Address 🦋

okay so SOURCE_ADDR is the attribute that says which source address (and port) the authorized session is actually for 💅 This X-Type can be super useful when you need to make sure the resource request was authorized for that exact source address and/or port 👀 Usually it lines up with the signaling source, like the IP source address of the GIST packet, or the flow source or flow destination address. Those last two live in the GIST MRI (Message Routing Information) object 🌸

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Length             |    X-Type     |   SubType     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                        OctetString ...                      //
   +---------------------------------------------------------------+

Length: the length of the attribute, which MUST be > 4 ✨

X-Type: SOURCE_ADDR

SubType: the following sub-types for SOURCE_ADDR are defined 🧚 IANA acts as a registry for SOURCE_ADDR SubTypes, as described in Section 8, IANA Considerations. Initially, the registry contains these SubTypes for SOURCE_ADDR:

IPV4_ADDRESS: IPv4 address represented in 32 bits.
IPV6_ADDRESS: IPv6 address represented in 128 bits.
UDP_PORT_LIST: list of UDP port specifications, represented as 16 bits per list entry.
TCP_PORT_LIST: list of TCP port specifications, represented as 16 bits per list entry.
SPI: Security Parameter Index, represented in 32 bits.

OctetString: the OctetString holds the source address information 🫶

In scenarios where a source address is required (see Section 5), at least one of the sub-types 1 or 2 MUST be included in every Session Authorization Object 🔥 Multiple SOURCE_ADDR attributes MAY be included if multiple addresses have been authorized, so you can be a whole main character with several addresses 👑 The source address of the request (e.g., a QoS NSLP RESERVE) MUST match one of the SOURCE_ADDR attributes contained in this Session Authorization Object. No mismatches, bestie 💀

At most, one instance of sub-type 3 MAY be included in every Session Authorization Object 🌈 At most, one instance of sub-type 4 MAY be included in every Session Authorization Object too. Including a sub-type 3 attribute doesn't stop you from including a sub-type 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.2.4. Destination Address 🌷

DEST_ADDR is how we identify the destination address of the authorized session 💖 It's giving the same energy as SOURCE_ADDR, just on the other end. This X-Type can help make sure the resource request was authorized for that particular destination address and/or port 🎀

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Length             |    X-Type     |   SubType     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                        OctetString ...                      //
   +---------------------------------------------------------------+

Length: the length of the attribute in number of octets, which MUST be > 4 ✨

X-Type: DEST_ADDR

SubType: the following sub-types for DEST_ADDR are defined 🍓 IANA acts as a registry for DEST_ADDR SubTypes, as described in Section 8, IANA Considerations. Initially, the registry contains these SubTypes for DEST_ADDR:

IPV4_ADDRESS: IPv4 address represented in 32 bits.
IPV6_ADDRESS: IPv6 address represented in 128 bits.
UDP_PORT_LIST: list of UDP port specifications, represented as 16 bits per list entry.
TCP_PORT_LIST: list of TCP port specifications, represented as 16 bits per list entry.
SPI: Security Parameter Index, represented in 32 bits.

OctetString: the OctetString holds the destination address specification 🫶

In scenarios where a destination address is required (see Section 5), at least one of the sub-types 1 or 2 MUST be included in every Session Authorization Object 😭 Multiple DEST_ADDR attributes MAY be included if multiple addresses have been authorized. The destination address field of the resource reservation datagram (e.g., QoS NSLP Reserve) MUST match one of the DEST_ADDR attributes contained in this Session Authorization Object. Same rule, other side of the call 📞

At most, one instance of sub-type 3 MAY be included in every Session Authorization Object 🌸 At most, one instance of sub-type 4 MAY be included in every Session Authorization Object. Including a sub-type 3 attribute doesn't prevent a sub-type 4 attribute, so both UDP and TCP ports may be authorized (iconic, honestly) 🦋

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.2.5. Start Time ⏰

START_TIME identifies when the authorized session starts, and it can be used to prevent replay attacks 🔥 If the SESSION_AUTH object 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. Late is not the vibe here 💀

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Length             |    X-Type     |   SubType     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                        OctetString ...                      //
   +---------------------------------------------------------------+

Length: the length of the attribute, which MUST be > 4 ✨

X-Type: START_TIME

SubType: the following sub-type for START_TIME is defined 🌈 IANA acts as a registry for START_TIME SubTypes, as described in Section 8, IANA Considerations. Initially, the registry contains this SubType for START_TIME:

1 NTP_TIMESTAMP: NTP Timestamp Format as defined in RFC 5905 [RFC5905].

OctetString: the OctetString holds the start time 🫶

3.2.6. End Time 🕰️

END_TIME identifies when the authorized session ends. It can be used to limit how long resources are authorized for use, like in prepaid session scenarios 💸 Time's up, babe 🧚

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Length             |    X-Type     |   SubType     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                        OctetString ...                      //
   +---------------------------------------------------------------+

Length: the length of the attribute, which MUST be > 4 ✨

X-Type: END_TIME

SubType: the following sub-type for END_TIME is defined 💜 IANA acts as a registry for END_TIME SubTypes, as described in Section 8, IANA Considerations. Initially, the registry contains this SubType for END_TIME:

1 NTP_TIMESTAMP: NTP Timestamp Format as defined in RFC 5905 [RFC5905].

OctetString: the OctetString holds the end time 🌸

3.2.7. NSLP Object List 📜

The NSLP_OBJECT_LIST attribute holds a list of NSLP object types that go into the keyed-hash computation, and the result of that computation is given in the AUTHENTICATION_DATA attribute 🔐 This is how you get integrity protection for NSLP PDUs, which is so iconic of it 👑 If an NSLP_OBJECT_LIST attribute has been included in the SESSION_AUTH object, then an AUTHENTICATION_DATA attribute MUST also be present. No solo NSLP_OBJECT_LISTs allowed 🙈

The creator of this attribute lists every NSLP object type whose NSLP PDU object was included in the hash computation. The hash computation has to follow the order of the NSLP object types exactly as the list gives them 🎀 The receiver can verify the integrity of the NSLP PDU by hashing all NSLP objects listed in this attribute (in the given order), including all the attributes of the authorization object. Since all NSLP object types are unique across every NSLP, this works for any NSLP ✨

Basic NSIS Transport Layer Protocol (NTLP) and NSLP objects, like the session ID, the NSLPID, and the MRI, MUST always be included in the HMAC 🦋 They aren't carried within the NSLP itself, only within GIST, so they have to be provided for the HMAC calculation, e.g., they can be delivered via the GIST API. They MUST be normalized to their network representation from [RFC5971] again before the hash is calculated. These values MUST be hashed first (in the order session ID, NSLPID, MRI), before any other NSLP object values that are included in the hash computation. Order matters, periodt 💅

A summary of the NSLP_OBJECT_LIST attribute format is below 🌷

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +---------------+---------------+---------------+---------------+
   | Length                        | NSLP_OBJ_LIST |     zero      |
   +---------------+---------------+-------+-------+---------------+
   | # of signed NSLP objects = n  |  rsv  |  NSLP object type (1) |
   +-------+-------+---------------+-------+-------+---------------+
   |  rsv  | NSLP object type (2)  |             .....            //
   +-------+-------+---------------+---------------+---------------+
   |  rsv  | NSLP object type (n)  |     (padding if required)     |
   +--------------+----------------+---------------+---------------+

Length: the length of the attribute, which MUST be > 4 ✨

X-Type: NSLP_OBJECT_LIST

SubType: no sub-types for NSLP_OBJECT_LIST are currently defined. This field MUST be set to 0 and ignored upon reception 🧚

# of signed NSLP objects: the number n of NSLP object types that follow. n=0 is allowed. In that case, only a padding field is contained 🍓

rsv: reserved bits; MUST be set to 0 and ignored upon reception 🫶

NSLP object type: the NSLP 12-bit object type identifier of the object that was included in the hash calculation. The NSLP object type values comprise only 12 bits, so four bits per type value are currently not used within the list. Depending on the number of signed objects, a corresponding padding word of 16 bits must be supplied 🌈

padding: padding MUST be added if the number of NSLP objects is even, and MUST NOT be added if the number of NSLP objects is odd. If padding has to be applied, the padding field MUST be 16 bits set to 0, and its contents MUST be ignored upon reception 🌸

3.2.8. Authentication Data 🔐

okay so the AUTHENTICATION_DATA attribute holds the authentication data for the SESSION_AUTH object, and it signs everything in the object up to the AUTHENTICATION_DATA itself 🫶. if it's included, it MUST be the last attribute in the list, no exceptions bestie 💅. the algorithm used to compute the authentication data depends on the AUTH_ENT_ID SubType field, so peep Section 4 entitled "Integrity of the SESSION_AUTH Object" for the full tea 🍵.

here's a quick glow-up of the AUTHENTICATION_DATA attribute format 👀:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Length             |    X-Type     |   SubType     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                        OctetString ...                      //
   +---------------------------------------------------------------+

Length: the length of the attribute, which MUST be > 4. 📏

X-Type: AUTHENTICATION_DATA 🏷️

SubType: no sub-types for AUTHENTICATION_DATA are currently defined. this field MUST be set to 0 and ignored upon reception 🙈

OctetString: the OctetString holds the authentication data of the SESSION_AUTH. 🔏

4. Integrity of the SESSION_AUTH Object ✨

this section is all about making sure the SESSION_AUTH object's integrity stays intact, so nobody can sneak in and mess with it 🛡️

4.1. Shared Symmetric Keys 🗝️

in shared symmetric key environments, the AUTH_ENT_ID MUST be of sub-types: IPV4_ADDRESS, IPV6_ADDRESS, FQDN, ASCII_DN, UNICODE_DN, or URI. here's an example SESSION_AUTH object 🧁:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0|0|0| Type = SESSION_AUTH   |0|0|0|0|    Object Length      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Length             |   AUTH_ENT_ID | IPV4_ADDRESS  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   OctetString ...   (The authorizing entity's Identifier)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Length             |   AUTH_DATA   |     zero      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Key-ID                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   OctetString ...   (Authentication data)                     |
   +---------------------------------------------------------------+

                Figure 1: Example of a SESSION_AUTH Object

4.1.1. Operational Setting Using Shared Symmetric Keys 🔑

this assumes both the Authorizing Entity and the network router/PDP (Policy Decision Point) are provisioned with shared symmetric keys, policies detailing which algorithm to be used for computing the authentication data, and the expected length of the authentication data for that particular algorithm 📋

key maintenance is outside the scope of this document, but SESSION_AUTH implementations MUST at least provide the ability to manually configure keys and their parameters 🛠️ the key used to produce the authentication data is identified by the AUTH_ENT_ID field. since multiple keys may be configured for a particular AUTH_ENT_ID value, the first 32 bits of the AUTHENTICATION_DATA field MUST be a Key-ID to be used to identify the appropriate key 🆔 each key must also be configured with lifetime parameters for the time period within which it is valid, as well as an associated cryptographic algorithm parameter specifying the algorithm to be used with the key ⏳ at a minimum, all SESSION_AUTH implementations MUST support the HMAC-SHA2-256 [RFC4868] [RFC2104] cryptographic algorithm for computing the authentication data 💜

it is good practice to regularly change keys 🔄 Keys MUST be configurable such that their lifetimes overlap, thereby allowing smooth transitions between keys 🌈 at the midpoint of the lifetime overlap between two keys, senders should transition from using the current key to the next/longer-lived key. meanwhile, receivers simply accept any identified key received within its configured lifetime and reject those that are not 🦋

4.2. Kerberos 🎫

since Kerberos [RFC4120] is widely used for end-user authorization, e.g., in Windows domains, it is well suited for being used in the context of user-based authorization for NSIS sessions 👑 for instance, a user may request a ticket for authorization to install rules in an NATFW-capable router 🧚

in a Kerberos environment, it is assumed that the user of the NSLP requesting host requests a ticket from the Kerberos Key Distribution Center (KDC) for using the NSLP node (router) as a resource (target service) 🎟️ the NSLP requesting host (client) can present the ticket to the NSLP node via Kerberos by sending a KRB_CRED message to the NSLP node independently but prior to the NSLP exchange. so the principal name of the service must be known at the client in advance, though the exact IP address may not be known in advance 📇 how the name is assigned and made available to the client is implementation specific. the extracted common session key can subsequently be used to employ the HMAC_SIGNED variant of the SESSION_AUTH object 🔐

another option is to encapsulate the credentials in the AUTHENTICATION_DATA portion of the SESSION_AUTH object. in this case, the AUTH_ENT_ID MUST be of the sub-type KRB_PRINCIPAL. the KRB_PRINCIPAL field is defined as the Fully Qualified Kerberos Principal name of the authorizing entity 🧾 the AUTHENTICATION_DATA portion of the SESSION_AUTH object contains the KRB_CRED message that the receiving NSLP node has to extract and verify. a second SESSION_AUTH object of type HMAC_SIGNED SHOULD protect the integrity of the NSLP message, including the prior SESSION_AUTH object. the session key included in the first SESSION_AUTH object has to be used for HMAC calculation 🫶

an example of the Kerberos AUTHENTICATION_DATA object is shown below in Figure 2 ✨

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0|0|0| Type = SESSION_AUTH   |0|0|0|0|    Object Length      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Length             |   AUTH_ENT_ID |  KERB_P.      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   OctetString ...   (The principal@realm name)                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Length             |   AUTH_DATA   |     zero      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   OctetString ...   (KRB_CRED Data)                           |
   +---------------------------------------------------------------+

        Figure 2: Example of a Kerberos AUTHENTICATION_DATA Object

4.3. Public Key 🗝️💖

in a public key environment, the AUTH_ENT_ID MUST be of the sub-types: X509_V3_CERT or PGP_CERT. the authentication data is used for authenticating the authorizing entity 🪪 two examples of the public key SESSION_AUTH object are shown in Figures 3 and 4 👀

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0|0|0| Type = SESSION_AUTH   |0|0|0|0|    Object Length      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Length             |   AUTH_ENT_ID |   PGP_CERT    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   OctetString ...   (Authorizing entity Digital Certificate)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Length             |   AUTH_DATA   |     zero      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   OctetString ...   (Authentication data)                     |
   +---------------------------------------------------------------+

    Figure 3: Example of a SESSION_AUTH_OBJECT Using a PGP Certificate
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0|0|0| Type = SESSION_AUTH   |0|0|0|0|    Object   Length    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Length             |   AUTH_ENT_ID | X509_V3_CERT  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   OctetString ...   (Authorizing entity Digital Certificate)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Length             |   AUTH_DATA   |     zero      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   OctetString ...   (Authentication data)                     |
   +---------------------------------------------------------------+

     Figure 4: Example of a SESSION_AUTH_OBJECT Using an X509_V3_CERT
                                Certificate

4.3.1. Operational Setting for Public-Key-Based Authentication 🔐🌸

public-key-based authentication assumes the following 🧠

authorizing entities have a pair of keys (private key and public key) 🔑
the private key is secured with the authorizing entity 🔒
public keys are stored in digital certificates; a trusted party, the 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 object. it's giving trust chain, bestie 🫶💅

4.3.1.1. X.509 V3 Digital Certificates ✨

okay bestie, so when the AUTH_ENT_ID is of type X509_V3_CERT, the AUTHENTICATION_DATA MUST be generated by the authorizing entity like this 💅

First, a signed-data gets built the way [RFC5652] says. A digest is then computed on the content (as specified in Section 6.1) using a signer-specific message-digest algorithm. The certificates field holds the chain of X.509 V3 digital certificates from each authorizing entity, and the certificate revocation list goes in the crls field. Last step: the digest output gets digitally signed following Section 8 of RFC 3447 [RFC3447], using the signer's private key 🔐

now the other side of the coin: when it's X509_V3_CERT, the verification at the verifying network element (PDP or router) MUST be done following these steps 👀

Parse the X.509 V3 certificate to pull out the distinguished name of the issuer of the certificate.
Certification Path Validation is performed as defined in Section 6 of RFC 5280 [RFC5280].
Parse through the Certificate Revocation list to check that the received certificate is not listed.
Once the X.509 V3 certificate is validated, the public key of the authorizing entity can be extracted from the certificate.
Extract the digest algorithm and the length of the digested data by parsing the CMS (Cryptographic Message Syntax) signed-data.
The recipient independently computes the message digest. This message digest and the signer's public key are used to verify the signature value.

and that whole check gives you integrity, non-repudiation, and data origin. iconic, honestly 🫶

4.3.1.2. PGP Digital Certificates 🌸

when the AUTH_ENT_ID is of type PGP_CERT, the AUTHENTICATION_DATA MUST be generated by the authorizing entity following these steps:

AUTHENTICATION_DATA holds a Signature Packet as defined in Section 5.2.3 of [RFC4880]. the short version:

Compute the hash of all data in the SESSION_AUTH object up to the AUTHENTICATION_DATA.
The hash output is digitally signed following Section 8 of RFC 3447, using the signer's private key.

and for PGP_CERT, the verification MUST be done by the verifying network element (PDP or router) like so 🧚

Validate the certificate.
Once the PGP certificate is validated, the public key of the authorizing entity can be extracted from the certificate.
Extract the hash algorithm and the length of the hashed data by parsing the PGP signature packet.
The recipient independently computes the message digest. This message digest and the signer's public key are used to verify the signature value.

same energy as before: integrity, non-repudiation, and data origin, all in one check 💖

4.4. HMAC Signed 🔥

a SESSION_AUTH object that carries an AUTH_ENT_ID of HMAC_SIGNED is used as integrity protection for NSLP messages. the SESSION_AUTH object MUST contain these attributes:

SOURCE_ADDR: the source address of the entity that created the HMAC
START_TIME: the timestamp when the HMAC signature was calculated. This MUST be different for any two messages in sequence, so replay attacks don't get a free pass. The NTP timestamp currently gives you a resolution of 200 picoseconds, which should be sufficient.
NSLP_OBJECT_LIST: lists all NSLP objects that are included in the HMAC calculation.
AUTHENTICATION_DATA: contains the Key-ID that's used for the HMAC calculation, plus the HMAC data itself [RFC2104].

the key for the HMAC calculation must be exchanged securely by some other means, e.g., a Kerberos Ticket or pre-shared manual installation, etc. the Key-ID in the AUTHENTICATION_DATA points you to the right key, and it also lets you periodically change signing keys within a session 🔑

the key length MUST be at least 64 bits, but ideally it's longer so it holds up against brute-force attacks during the key validity period 💪 for scalability reasons, it's suggested to use a per-user key for signing NSLP messages. a per-session key is possible too, but that costs a per-session key exchange. a per-user key lets you verify the authenticity of the message, which gives you a basis for session-based per-user authorization ✨

it is RECOMMENDED to periodically change the shared key so eavesdroppers can't go off-line brute-forcing it 🙈 the actual hash algorithm used in the HMAC computation is specified by the "Transform ID" field (given as Transform Type 3 of the IKEv2 registry [RFC5996]). the hash algorithm MUST be chosen consistently between the object creator and the NN verifying the HMAC. this can be sorted out with out-of-band mechanisms when the shared key is exchanged.

Figure 5 shows an example of an object that's used for integrity protection of NSLP messages 🦋

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0|0|0| Type = SESSION_AUTH   |0|0|0|0|    Object   Length    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Length             |   AUTH_ENT_ID | HMAC_SIGNED   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   reserved                    | Transform ID  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Length             | SOURCE_ADDR   |  IPV4_ADDRESS |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                IPv4 Source Address of NSLP sender             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Length             |  START_TIME   | NTP_TIME_STAMP|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        NTP Time Stamp (1)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        NTP Time Stamp (2)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Length             | NSLP_OBJ_LIST |     zero      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |No. of signed NSLP objects = n |  rsv  |  NSLP object type (1) |
   +-------+-------+---------------+-------+-------+---------------+
   |  rsv  | NSLP object type (2)  |             .....            //
   +-------+-------+---------------+---------------+---------------+
   |  rsv  | NSLP object type (n)  |     (padding if required)     |
   +--------------+----------------+---------------+---------------+
   |            Length             |   AUTH_DATA   |     zero      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Key-ID                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Message Authentication Code HMAC Data                |
   +---------------------------------------------------------------+

    Figure 5: Example of a SESSION_AUTH_OBJECT That Provides Integrity
                       Protection for NSLP Messages

5. Framework 🌈

[RFC3521] describes a framework in which the SESSION_AUTH object may be utilized to carry the info needed for authorizing resource reservation for data flows (e.g., media flows). [RFC3521] introduces four different models:

The coupled model
The associated model with one policy server
The associated model with two policy servers
The non-associated model

which fields are REQUIRED in a SESSION_AUTH object depends on which of these models you're using. (okay that one's in caps for real, it's a keyword, so I'm keeping it exact.)

5.1. The Coupled Model 🦋

in the coupled model, the only thing the SESSION_AUTH object MUST include is the SESSION_ID. the Authorizing Entity uses it to match the resource reservation request with the media that got authorized during session setup. since the End Host is assumed to be untrusted, the Policy Server SHOULD take measures to keep the integrity of the SESSION_ID intact in transit. the exact mechanisms 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 SESSION_AUTH object MUST include:

A session identifier, SESSION_ID. This is the info the authorizing entity uses to correlate the resource request with the data flows authorized during session setup.
The identity of the authorizing entity, AUTH_ENT_ID. An NN uses this to figure out which authorizing entity (Policy Server) it should ask for resource policy decisions.

in some environments, an NN might have no way to tell whether the identity points to a legit Policy Server inside its domain. to guard against authorization requests getting redirected to a bogus authorizing entity, the SESSION_AUTH MUST also include:

AUTHENTICATION_DATA. This authentication data is calculated over all other fields of the SESSION_AUTH object.

5.3. The Associated Model with Two Policy Servers 🎀

the content of the SESSION_AUTH object is identical to the associated model with one policy server. same vibes, no notes 🫶

5.4. The Non-Associated Model 👑

in this model, the SESSION_AUTH object MUST contain enough info for the Policy Server to make resource policy decisions on its own, without the authorizing entity. the object gets created by the authorizing entity using info about the session. the information in the SESSION_AUTH object MUST include:

Initiating party's IP address or Identity (e.g., FQDN): SOURCE_ADDR X-Type
Responding party's IP address or Identity (e.g., FQDN): DEST_ADDR 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 SESSION_AUTH object: AUTHENTICATION_DATA X-Type

and then there's the stuff the SESSION_AUTH object MAY contain:

The lifetime of (each of) the media stream(s): END_TIME X-Type
Initiating party's port number: SOURCE_ADDR X-Type
Responding party's port number: DEST_ADDR X-Type

all SESSION_AUTH fields MUST match with the resource request. if a field doesn't match, the request SHOULD be denied 🚫

6. Message Processing Rules 💅

this section is all about the message processing related to the SESSION_AUTH object. the details of how the SESSION_AUTH object gets processed within QoS NSLP and NATFW NSLP are spelled out. new NSLP protocols should use the same logic when they make use of the SESSION_AUTH object ✨

6.1. Generation of the SESSION_AUTH by an Authorizing Entity 🧚

Generate the SESSION_AUTH object with the appropriate contents as specified in Section 3.
If authentication is needed, the entire SESSION_AUTH object is constructed, excluding the length, type, and SubType fields of the SESSION_AUTH field. Note that the message MUST include a START_TIME to prevent replay attacks. The output of the authentication algorithm, plus appropriate header information, is appended as the AUTHENTICATION_DATA attribute to the SESSION_AUTH object.

6.2. Processing within the QoS NSLP ✨

okay so the SESSION_AUTH object can tag along with QoS NSLP QUERY and RESERVE messages 🎀 for authorizing a query on network resources and for authorizing a resource reservation request, respectively 💅

it can also show up in RESPONSE messages 🦋 to say the authorizing entity changed the original request 🙈 like the session start or end times got moved, or the client asked for all ports and the authorizing entity was like "nah, just these ports" 💀

if the QoS NSIS Initiator (QNI) gets a RESPONSE message with a SESSION_AUTH object, the QNI MUST inspect that object to see which authentication attribute got changed by an authorizing entity 👀 and the QNI SHOULD also quietly accept any SESSION_AUTH objects in a RESPONSE message that don't show any change to the original authorization request ✨

6.2.1. Message Generation

a QoS NSLP message gets made the way [RFC5974] says 🧚

the policy element that came from the authorizing entity MUST be copied without modification into the SESSION_AUTH object 💖
the SESSION_AUTH object (with the policy element inside it) gets inserted into the NSLP message in the appropriate place 🌸

6.2.2. Message Reception

the QoS NSLP message gets processed as [RFC5974] describes, with the following tweaks 🫶

if the QoS NSIS Entity (QNE) is policy aware, then it SHOULD use the Diameter QoS application or the RADIUS QoS protocol to talk to the PDP 💅 to build the AAA message, you have to pull out the SESSION_AUTH object and the QoS-related objects from the QoS NSLP message and then craft the matching RADIUS or Diameter message 🔥 the message processing and object format live in the respective RADIUS or Diameter QoS protocol docs 📚 if the QNE is policy unaware, it just ignores the policy data objects and keeps on processing the NSLP message 🌈
if the response from the PDP is negative, the request must be rejected 💀 a negative response in RADIUS is an Access-Reject, and in Diameter it's based on the DIAMETER_SUCCESS value in the Result-Code AVP of the QoS-Authz-Answer (QAA) message 😭 the QNE must construct and send a RESPONSE message with the status of the authorization failure, as [RFC5974] specifies 🙅‍♀️
continue processing the NSIS message 🦋

6.2.3. Authorization (QNE or PDP)

retrieve the policy element from the SESSION_AUTH object 🔍 check the AUTH_ENT_ID type and SubType fields, and return an error if the identity type isn't supported 🚫
verify the message integrity 🔐
- Shared symmetric key authentication: the QNE or PDP uses the AUTH_ENT_ID field to look up a table keyed by that field 🗝️ the table should identify the cryptographic authentication algorithm to be used, plus 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 matches the configured table entry, and 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 🎀
- HMAC signed: the QNE or PDP uses the Key-ID field of the AUTHENTICATION_DATA attribute to look up a table keyed by that field 🗂️ the table should identify the cryptographic authentication algorithm to be used, plus 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 matches the configured table entry, and validate the integrity of the parts of the NSLP message, i.e., session ID, MRI, NSLPID, and all the other NSLP elements listed in the NSLP_OBJECT_LIST authentication data, plus the SESSION_AUTH object contents (cf. Section 6.4) 🧠
- Kerberos: if AUTHENTICATION_DATA contains an encapsulated KRB_CRED message (cf. Section 4.2), the integrity of the KRB_CRED message can be verified within Kerberos itself 🛡️ and if the same NSLP message also has another SESSION_AUTH object using HMAC_SIGNED, that one can be used to verify message integrity as described above 🌸
once the identity of the authorizing entity and the validity of the service request are established, the authorizing router/PDP MUST then consult its authorization policy to figure out whether or not the specific request is finally authorized (e.g., based on available credits and on info in the subscriber's database) 💅 to whatever extent these access control decisions need supplementary information, routers/PDPs MUST ensure that the supplementary information is obtained securely 🔒
verify that the requested resources don't exceed the authorized QoS 📏

6.2.4. Error Signaling

when the PDP (e.g., a RADIUS or Diameter server) fails to verify the policy element, the appropriate actions described in the respective AAA document need to be taken 🧯

the QNE node MUST return a RESPONSE message with the INFO_SPEC error code 'Authorization failure', as defined in the QoS NSLP specification [RFC5974] 🚨 the QNE MAY include an INFO_SPEC Object Value Info to indicate which SESSION_AUTH attribute caused the error 🔍

6.3. Processing with the NATFW NSLP 🌐

this section lays out the processing rules for the NATFW NSLP [RFC5973] 🦋

6.3.1. Message Generation

a NATFW NSLP message gets made the way [RFC5973] says 🧚

the policy element that came from the authorizing entity MUST be copied without modification into the SESSION_AUTH object 💖
the SESSION_AUTH object (with the policy element inside it) gets inserted into the NATFW NSLP message in the appropriate place 🌸

6.3.2. Message Reception

the NATFW NSLP message gets processed as [RFC5973] describes, with the following tweaks 🫶

if the router is policy aware, then it SHOULD use the Diameter application or the RADIUS protocol to talk to the PDP 💅 to build the AAA message, you have to pull out the SESSION_AUTH object and the objects related to NATFW policy rules from the NSLP message, then craft the matching RADIUS or Diameter message 🔥 the message processing and object format are described in the respective RADIUS or Diameter protocols 📚 if the router is policy unaware, it ignores the policy data objects and keeps processing the NSLP message 🌈
reject the message if the response from the PDP is negative 💀 a negative response in RADIUS is an Access-Reject, and in Diameter it's based on the DIAMETER_SUCCESS value in the Result-Code AVP 😭
continue processing the NSIS message 🦋

6.3.3. Authorization (Router/PDP)

retrieve the policy element from the SESSION_AUTH object 🔍 check the AUTH_ENT_ID type and SubType fields, and return an error if the identity type isn't supported 🚫
verify the message integrity 🔐
- Shared symmetric key authentication: the network router/PDP uses the AUTH_ENT_ID field to look up 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 matches the configured table entry, and 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 🎀
- HMAC signed: the QNE or PDP uses the Key-ID field of the AUTHENTICATION_DATA attribute to look up a table keyed by that field 🗂️ the table should identify the cryptographic authentication algorithm to be used, plus 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 matches the configured table entry, and validate the integrity of parts of the NSLP message, i.e., session ID, MRI, NSLPID, and all the other NSLP elements listed in the NSLP_OBJECT_LIST authentication data, plus the SESSION_AUTH object contents (cf. Section 6.4) 🧠
- Kerberos: if AUTHENTICATION_DATA contains an encapsulated KRB_CRED message (cf. Section 4.2), the integrity of the KRB_CRED message can be verified within Kerberos itself 🛡️ and if the same NSLP message also has another SESSION_AUTH object using HMAC_SIGNED, that one can be used to verify message integrity as described above 🌸
once the identity of the authorizing entity and the validity of the service request are established, the authorizing router/PDP MUST then consult its authorization policy to figure out whether or not the specific request is authorized 💅 to whatever extent these access control decisions need supplementary information, routers/PDPs MUST ensure that the supplementary information is obtained securely 🔒

6.3.4. Error Signaling

when the PDP (e.g., a RADIUS or Diameter server) fails to verify the SESSION_AUTH object, the appropriate actions described in the respective AAA document need to be taken 🧯 the NATFW NSLP node MUST return an error message of class 'Permanent failure' (0x5) with error code 'Authorization failed' (0x02) 🚨

6.4. Integrity Protection of NSLP Messages ✨

okay so the SESSION_AUTH object can also be used to give every NSLP signaling message integrity protection 🔐, which also means requests and responses get authenticated. Picture this: a user has dropped a shared key off at some NN. That NN can then check the integrity of every NSLP message the user sends to it 💅. Once the NN knows who's talking, it can apply authorization policies to things like resource reservations or opening firewall pinholes. main character energy for security 👑

The sender of an NSLP message builds a SESSION_AUTH object with the AUTH_ENT_ID attribute set to HMAC_SIGNED (cf. Section 4.4). It hashes with the shared key over all the NSLP objects that need protecting, and it lists them in the NSLP_OBJECT_LIST 🧚. The SESSION_AUTH object is protected by the HMAC too. When that object rides along in the NSLP message, the receiver can verify its integrity, but only if it has the right shared key for the HMAC 🔑. Any response back to the sender should also include a SESSION_AUTH object, so attackers can't slide in fake responses pretending to be the real NN 🙈.

If a SESSION_AUTH object shows up with an AUTH_ENT_ID attribute set to HMAC_SIGNED, then the integrity of every NSLP element listed in the NSLP_OBJECT_LIST has to be checked 🔍. That includes the contents of the SESSION_AUTH object itself. On top of that, the session ID, MRI, and NSLPID also have to be included in the HMAC calculation, as specified in Section 3.2.7 🎀. The key used for the HMAC is identified by the Key-ID inside the AUTHENTICATION_DATA attribute. And if the timestamp in START_TIME isn't recent enough, or the calculated HMAC doesn't match the one in AUTHENTICATION_DATA, the message must be discarded silently and an error should be logged locally 💀.

7. Security Considerations 🔐

okay bestie, this section is the serious one 😭. This document describes a mechanism for session authorization whose whole job is to prevent theft of service. There are three kinds of security issues to think about: protection against replay attacks, integrity of the SESSION_AUTH object, and choosing the authentication algorithms and keys 🧐.

Issue number one is replay attacks, and they MUST be prevented 🚨. In the non-associated model, the SESSION_AUTH object MUST include a START_TIME field, and the NNs as well as Policy Servers MUST support NTP so their clocks stay synchronized. If clock synchronization fails, replay attacks become possible, because the clocks of the different network entities may not agree 🕰️. The start time is what lets the system check that a request isn't being replayed at some later time. In all other models, the Policy Server uses the SESSION_ID to make sure a resource request actually lines up with the records of an authorized session. If a SESSION_AUTH object gets replayed, the policy server MUST detect it (using internal algorithms), and the request MUST be rejected 🚫.

Issue number two is the integrity of the SESSION_AUTH object. In untrusted environments, it stays protected by including the AUTHENTICATION_DATA attribute 🛡️.

In environments where shared symmetric keys are possible, they should be used, which keeps the SESSION_AUTH object size to a strict minimum. This matters a lot when wireless links are involved 📶. A secondary option is Public Key Infrastructure (PKI) authentication, which gives a high level of security and good scalability ✨. The catch is that PKI authentication needs credentials in the SESSION_AUTH object, and that makes the object bigger.

The SESSION_AUTH object can also protect the integrity of NSLP message parts by using the HMAC_SIGNED Authentication Data, as described in Section 6.4 🔒.

When shared keys are in play, for example in AUTHENTICATION_DATA (cf. Section 4.1) or together with HMAC_SIGNED (cf. Section 4.4), the keys have to stay secret 🤫. That means they must be exchanged, stored, and managed in a secure and confidential way, so no unauthorized party ever gets their hands on the key material. If key material leaks to an unauthorized party, authentication and integrity protection stop working entirely 💔.

Security considerations for public-key mechanisms using the X.509 certificate mechanisms described in [RFC5280] apply too. Likewise, the security considerations for PGP (Pretty Good Privacy) described in [RFC4880] apply 📜.

Further security issues are outlined in RFC 4081 [RFC4081] 👀.

8. IANA Considerations 🗂️

okay registry time 🍓. The SESSION_AUTH_OBJECT NSLP Message Object type is specified as 0x016.

This document specifies an 8-bit Session authorization attribute type (X-Type) field, plus 8-bit SubType fields for each X-Type. IANA has created and will maintain corresponding sub-registries for the NSLP Session Authorization Object 💅.

The initial values for the X-Type registry, and the registration procedures according to [RFC5226], are as follows: