RFC 4230
RSVP Security Properties
RFC 4230: RSVP Security Properties 🎀
Part 1 of 12 💖 More parts are coming, so stay tuned!
The title block tea ☕: This is RFC 4230, titled RSVP Security Properties. It was written by H. Tschofenig from Siemens and R. Graveman from RFG Security. It's Informational, which means it's not a standard, and it's dated December 2005. The title block doesn't list anything it obsoletes or updates.
Status of This Memo ✨
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright Notice 📜
Copyright (C) The Internet Society (2005).
Abstract 🌸
This document summarizes the security properties of RSVP. The goal of this analysis is to benefit from previous work done on RSVP and to capture knowledge about past activities.
Table of Contents 🧚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Architectural Assumptions . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. The RSVP INTEGRITY Object . . . . . . . . . . . . . . 5
3.2. Security Associations . . . . . . . . . . . . . . . . 8
3.3. RSVP Key Management Assumptions . . . . . . . . . . . 8
3.4. Identity Representation . . . . . . . . . . . . . . . 9
3.5. RSVP Integrity Handshake . . . . . . . . . . . . . . 13
4. Detailed Security Property Discussion . . . . . . . . . . . 15
4.1. Network Topology . . . . . . . . . . . . . . . . . . 15
4.2. Host/Router . . . . . . . . . . . . . . . . . . . . . 15
4.3. User to PEP/PDP . . . . . . . . . . . . . . . . . . . 19
4.4. Communication between RSVP-Aware Routers . . . . . . . 28
5. Miscellaneous Issues . . . . . . . . . . . . . . . . . . . . 29
5.1. First-Hop Issue . . . . . . . . . . . . . . . . . . . 30
5.2. Next-Hop Problem . . . . . . . . . . . . . . . . . . . 30
5.3. Last-Hop Issue . . . . . . . . . . . . . . . . . . . 33
5.4. RSVP- and IPsec-protected data traffic . . . . . . . . 34
5.5. End-to-End Security Issues and RSVP . . . . . . . . . 36
5.6. IPsec protection of RSVP signaling messages . . . . . 36
5.7. Authorization . . . . . . . . . . . . . . . . . . . . 37
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . 38
7. Security Considerations . . . . . . . . . . . . . . . . . . 40
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
9.1. Normative References . . . . . . . . . . . . . . . . . 40
9.2. Informative References . . . . . . . . . . . . . . . . 41
A. Dictionary Attacks and Kerberos . . . . . . . . . . . . . . 45
B. Example of User-to-PDP Authentication . . . . . . . . . . . 45
C. Literature on RSVP Security . . . . . . . . . . . . . . . . 461. Introduction 💅
Okay so, when the NSIS working group got started, people raised concerns about security and what it means for how a signaling protocol gets designed 😳. To really understand RSVP's security properties and the options it has, you have to read a bunch of documents. This one sums up RSVP's security properties and is part of the bigger effort to analyze other signaling protocols and learn from their design choices. It should also give everyone a starting point for more discussion 🫶.
Here's the layout. Section 2 introduces the terminology used throughout the doc. Section 3 gives an overview of RSVP's security mechanisms, including the INTEGRITY object, how identity is represented inside the POLICY_DATA object (that's user authentication), and the RSVP Integrity Handshake mechanism. Section 4 goes deeper into those mechanisms and tries to describe them in detail. A few miscellaneous issues get covered in Section 5.
RSVP also supports multicast, but this document doesn't cover the security side of multicast QoS signaling 🙈. Multicast is currently outside the scope of the NSIS working group.
Then there's RSVP-TE, a variation of RSVP that's used with MPLS to distribute labels for a label switched path. Its usage is different from the scenarios envisioned for NSIS, so this document doesn't cover RSVP-TE or its security properties 🦋.
2. Terminology and Architectural Assumptions 🌈
This section covers some important terms and explains a few architectural assumptions ✨.
- Chain-of-Trust:
Lowkey the core idea here 👑. RSVP's security mechanisms [1] rely heavily on optional hop-by-hop protection, using the built-in INTEGRITY object. Hop-by-hop security with the INTEGRITY object inside the RSVP message refers to protection between RSVP-supporting network elements. There's also the idea of policy-aware nodes, which understand the POLICY_DATA element inside the RSVP message. Because that element also includes an INTEGRITY object, there's an extra hop-by-hop security mechanism that protects traffic between policy-aware nodes. Policy-ignorant nodes aren't affected by that object inside POLICY_DATA, because they don't try to interpret it 🍓.
To protect signaling messages that every RSVP router along the path might modify, it has to be assumed that each incoming request is authenticated, integrity protected, and replay protected. That protects against bogus messages injected by unauthorized nodes. Also, each RSVP-aware router is assumed to behave the way it's expected to. Outgoing messages sent to the next-hop network element get new protection through RSVP security processing 💜.
So here's the chain-of-trust idea. A signaling message sent by router A, passed along by router B, and received by router C is supposed to be secure if routers A and B share a security association, routers B and C share one, and all the routers behave as expected. That means router C trusts router A even though C doesn't have a direct security association with A 🤝. The protection you get from this hop-by-hop chain is no better than its weakest link 💀.
If one router is malicious (say an adversary has taken control of it), it can change messages arbitrarily, cause unexpected behavior, and launch a bunch of attacks that aren't limited to QoS signaling 😭. Also, some protocols need more protection than others, and that depends partly on which nodes run them. For example, edge devices where end users connect might be more likely to get attacked than the more secure core network of a service provider. In some cases, a network service provider may decide not to use RSVP's built-in security mechanisms inside its core network because it already has different security protection deployed there ✨.
Section 6 of [2] mentions the term chain-of-trust in the context of RSVP integrity protection. Section 6 of [14] uses the same term for user authentication with the INTEGRITY object inside the POLICY_DATA element. Unfortunately, the term isn't explained in detail, and the assumptions behind it aren't clearly specified 😤.
- Host and User Authentication:
RSVP protection plus a separate user identity representation means that both user identity and host identity get used for RSVP protection. So user-based security and host-based security are covered separately, because they use different authentication mechanisms 🎀. To avoid mixing up these concepts, Section 3.4 describes user authentication in more detail 📖.
- Key Management:
It's assumed that most of the security associations needed to protect RSVP signaling messages are already available, so key management was done in advance. The exception is Kerberos support. With Kerberos, an entity can distribute a session key that's used for RSVP signaling protection 🔑.
- RSVP INTEGRITY and POLICY_DATA INTEGRITY Objects:
RSVP uses an INTEGRITY object in two places in a message. The first is in the RSVP message itself, and it covers the entire RSVP message as defined in [1]. The second is included in the POLICY_DATA object and defined in [2]. To tell the two apart by what they protect, the terms RSVP INTEGRITY and POLICY_DATA INTEGRITY object are used, respectively. The data structure of the two objects is the same, though 🧚.
- Hop versus Peer:
The terminology for nodes addressed by RSVP has been debated a lot in the past. Two favorite terms came up: hop and peer. This document uses the term hop, and it's different from an IP hop. Two neighboring RSVP nodes that talk to each other aren't necessarily neighboring IP nodes, since they can be more than one IP hop apart 🌸.
3. Overview 🦋
This section describes the security mechanisms provided by RSVP. Use of IPsec is mentioned in Section 10 of [1], and the other security mechanisms that were primarily envisioned for RSVP are described here 💖.
3.1. The RSVP INTEGRITY Object 🔐
okay so the RSVP INTEGRITY object is literally the main character of RSVP security 💅 It's what gives integrity and replay protection to the content of the signaling message between two RSVP participating routers, or between an RSVP router and host. It also provides data origin authentication 🫶 Here's the breakdown of its attributes:
- Flags field:
The Handshake Flag is the only defined flag 🚩 It's used to synchronize sequence numbers if things get out of sync (e.g., it lets a restarting host recover the most recent sequence number) 🔄 Setting this flag to one means the sender is willing to respond to an Integrity Challenge message. So this flag is basically a negotiation capability sent inside every INTEGRITY object ✨
- Key Identifier:
The Key Identifier picks the key used to verify the Keyed Message Digest field, so it must be unique for the sender 🔑 It has a fixed 48-bit length. Generating this field is mostly up to the local host. [1] describes it as a combination of an address, sending interface, and key number. We assume the Key Identifier is just a (keyed) hash value computed over a number of fields, and it has to be unique if more than one security association is used in parallel between two hosts (e.g., when security associations have overlapping lifetimes) 🫠
A receiving system uniquely identifies a security association using the Key Identifier and the sender's IP address. The sender's IP address may come from the RSVP_HOP object, or from the source IP address of the packet if the RSVP_HOP object is not present. The sender uses the outgoing interface to determine which security association to use. ngl "outgoing interface" is a little confusing, so here's the tea: the sender selects the security association based on the receiver's IP address (i.e., the address of the next RSVP-capable router) 👀 How the sender figures out which node is that next RSVP-capable router isn't specified any further, and it's likely to be statically configured 🤷♀️
- Sequence Number:
The sequence number used by the INTEGRITY object is 64 bits long, and the starting value can be selected arbitrarily 🎲 The length was chosen so it won't run out during the lifetime of a security association, as stated in Section 3 of [1]. For the receiver to tell a new message from a replayed one, the sequence number must be monotonically incremented (modulo 2^64) for each message 📈 We assume the first sequence number seen (i.e., the starting sequence number) is stored somewhere. The modulo operation is required because the starting sequence number may be an arbitrary number. So the receiver only accepts packets with a sequence number larger (modulo 2^64) than the previous packet 💅 As explained in [1], this process kicks off with handshaking and agreeing on an initial sequence number. If no such handshaking is available, then the initial sequence number must be part of establishing the security association.
Generating and storing sequence numbers is a huge step in preventing replay attacks 🛡️ It's largely determined by what the system can handle when it crashes, fails, or restarts. Section 3 of [1] covers some of the most important considerations. But the way the receiver decides whether a sequence number is proper or improper is incomplete, because it implicitly assumes that gaps big enough to make the sequence number wrap around can't happen 😭
If delivery were guaranteed to be in order, this procedure would work 🧠 The receiver keeps track of the first sequence number received, INIT-SEQ, and the most recent one received, LAST-SEQ, for each key identifier in a security association. When the first message comes in, set INIT-SEQ = LAST-SEQ = the value received, and accept it. When a later message arrives, if its sequence number is strictly between LAST-SEQ and INIT-SEQ (modulo 2^64), accept it and update LAST-SEQ with the value just received. If it's between INIT-SEQ and LAST-SEQ, inclusive (modulo 2^64), reject it and leave LAST-SEQ unchanged. Because delivery in order is not guaranteed, these rules need to be combined with a method that allows a fixed-size window around LAST-SEQ for out-of-order delivery, for example as described in Appendix C of [3] 🪟
- Keyed Message Digest:
The Keyed Message Digest is a security mechanism built into RSVP that provides integrity protection for a signaling message (including its sequence number) 🔐 Before computing the value for this field, the Keyed Message Digest field itself must be set to zero, and then a keyed hash is computed over the entire RSVP packet. The field is variable in length, but it must be a multiple of four octets. If HMAC-MD5 is used, the output value is 16 bytes long. The keyed hash function HMAC-MD5 [4] is required for an RSVP implementation, as noted in Section 1 of [1]. Hash algorithms other than MD5 [5], like SHA-1 [15], may also be supported 🌈
The key used for computing this Keyed Message Digest may come from a pre-shared secret, which is either manually distributed or the result of a key management protocol. No key management protocol, however, is specified for creating the desired security associations 🙈 Also, no guidelines for key length are given. It should be recommended that HMAC-MD5 keys be 128 bits and SHA-1 keys 160 bits, as in IPsec AH [16] and ESP [17] 🎀
3.2. Security Associations 🤝
Security associations are stored with different attributes depending on whether the system is sending or receiving (i.e., they're unidirectional security associations) ➡️⬅️ The sending system needs to maintain the following attributes in such a security association [1]:
- Authentication algorithm and algorithm mode
- Key
- Key Lifetime
- Sending Interface
- Latest sequence number (received with this key identifier)
The receiving system has to store these fields:
- Authentication algorithm and algorithm mode
- Key
- Key Lifetime
- Source address of the sending system
- List of last n sequence numbers (received with this key identifier)
Note that security associations need some extra fields to show their state 📋 It's necessary to have overlapping lifetimes so an ongoing communication doesn't get interrupted by expired security associations 😤 During that overlap, it's necessary to authenticate with either one or both active keys. As mentioned in [1], a sender and a receiver may have multiple active keys at the same time. And if more than one algorithm is supported, the algorithm used must be specified for each security association 💖
3.3. RSVP Key Management Assumptions 🗝️
RFC 2205 [6] assumes that security associations are already available. An implementation must support manual key distribution, as noted in Section 5.2 of [1] 🙌 Manual key distribution has different requirements for key storage, though. In some cases a simple plaintext ASCII file may be enough 📝 If multiple security associations with different lifetimes need to be supported at the same time, a key engine would be more appropriate ⚙️ Further security requirements listed in Section 5.2 of [1] are the following:
- The manual deletion of security associations must be supported.
- The key storage should persist during a system restart.
- Each key must be assigned a specific lifetime and a specific Key Identifier.
3.4. Identity Representation ✨
okay so bestie, RSVP already has host-based authentication with the INTEGRITY object inside the RSVP message 🔐, but user-based authentication is also on the table, as introduced in [2]. Section 2 of [7] literally says "Providing policy based admission control mechanism based on user identities or application is one of the prime requirements." 💅 So to figure out who the user (or the application) is, a policy element called AUTH_DATA gets made by the RSVP daemon on the user's host 🖥️ and sent along inside the RSVP message. The structure of the POLICY_DATA element is in [2]. Then network nodes acting as policy decision points (PDPs) use the AUTH_DATA info to authenticate the user and run policy-based admission control 🚦. As [7] mentions, the policy element gets processed, and the PDP swaps the old element for a new one before forwarding it to the next hop router 🦋.
A detailed description of the POLICY_DATA element is in [2]. The attributes inside the authentication data policy element AUTH_DATA (defined in [7]) get a quick rundown in this section 🌸. Figure 1 shows the abstract structure of the RSVP message with its security-relevant objects and the scope of protection 👀. The RSVP INTEGRITY object (the outer one) covers the entire RSVP message, whereas the POLICY_DATA INTEGRITY object only covers objects within the POLICY_DATA element 🎀.
+--------------------------------------------------------+
| RSVP Message |
+--------------------------------------------------------+
| Object |POLICY_DATA Object ||
| +-------------------------------------------+|
| | INTEGRITY +------------------------------+||
| | Object | AUTH_DATA Object |||
| | +------------------------------+||
| | | Various Authentication |||
| | | Attributes |||
| | +------------------------------+||
| +-------------------------------------------+|
+--------------------------------------------------------+
Figure 1: Security Relevant Objects and Elements
within the RSVP Message.The AUTH_DATA object holds info for identifying users and applications, plus the credentials for those identities 🪪. The main purpose of these identities seems to be policy-based admission control, not authentication and key management 🤔. As noted in Section 6.1 of [7], an RSVP message can contain more than one POLICY_DATA object, and each of those can contain more than one AUTH_DATA object 📦. As shown in Figure 1 and in [7], one AUTH_DATA object can contain more than one authentication attribute 🧩. A typical setup for Kerberos-based user authentication includes at least the Policy Locator and an attribute with the Kerberos session ticket 🎫.
Successful user authentication is the basis for running policy-based admission control 👑. On top of that, other info like time-of-day, application type, location, group membership, etc. might matter for an access control policy 🌈.
The following attributes are defined for use in the AUTH_DATA object 📝:
- Policy Locator 📍
ASCII_DNUNICODE_DNASCII_DN_ENCRYPTUNICODE_DN_ENCRYPT
The policy locator string is an X.500 distinguished name (DN) used to find user or application-specific policy info 🗺️. The four types of X.500 DNs are listed above. The first two are the ASCII and the Unicode representation of the user or application DN identity 🔤. The two "encrypted" DN types are either encrypted with the Kerberos session key, or with the private key of the user's digital certificate (i.e., digitally signed) 🔏. The term "encrypted together with a digital signature" is easy to misconceive 🙃. If user identity confidentiality is provided, then the policy locator has to be encrypted with the public key of the recipient 🗝️. How to get this public key is not described in the document. This detail may be specified in a concrete architecture in which RSVP is used 🏗️.
- Credentials 🪪
Two cryptographic credentials are currently defined for a user: authentication with Kerberos V5 [8], and authentication with the help of digital signatures based on X.509 [18] and PGP [19] 🔐. The following list contains all defined credential types currently available and defined in [7] 📋:
+--------------+--------------------------------+
| Credential | Description |
| Type | |
+===============================================|
| ASCII_ID | User or application identity |
| | encoded as an ASCII string |
+--------------+--------------------------------+
| UNICODE_ID | User or application identity |
| | encoded as a Unicode string |
+--------------+--------------------------------+
| KERBEROS_TKT | Kerberos V5 session ticket |
+--------------+--------------------------------+
| X509_V3_CERT | X.509 V3 certificate |
+--------------+--------------------------------+
| PGP_CERT | PGP certificate |
+--------------+--------------------------------+
Figure 2: Credentials Supported in RSVP.The first two credentials only contain a plaintext string, so they don't provide cryptographic user authentication 🙅♀️. These plaintext strings may be used to identify applications that are included for policy-based admission control 📱. Note that these plain-text identifiers may, however, be protected if either the RSVP INTEGRITY or the INTEGRITY object of the POLICY_DATA element is present 🛡️. Also, the two INTEGRITY objects can terminate at different entities depending on the network structure 🌐. The digital signature may also protect application identifiers ✍️. A protected application identity (and the entire content of the POLICY_DATA element) cannot be modified as long as no policy-ignorant nodes are encountered in between 🚫.
A Kerberos session ticket, as mentioned before, is the ticket of a Kerberos AP_REQ message [8] without the Authenticator 🎟️. Normally, a client uses the AP_REQ message to authenticate to a server 🤝. The INTEGRITY object (e.g., the one in the POLICY_DATA element) does the job of the Kerberos Authenticator 🧠. That means it protects against replay and shows that the user was able to retrieve the session key by following the Kerberos protocol 🔑. This only works if the Kerberos session was used for the keyed message digest field of the INTEGRITY object 🫶. Section 7 of [1] discusses some issues for establishing keys for the INTEGRITY object 🧪. Setting up the security association for the RSVP INTEGRITY object, with the Kerberos Ticket included inside the AUTH_DATA element, can get messy because the ticket can be decrypted by node B, while the RSVP INTEGRITY object terminates at a different host C 😵💫.
The Kerberos session ticket contains, among many other fields, the session key 🗝️. The Policy Locator may also be encrypted with that same session key 🔒. The protocol steps needed to get such a Kerberos service ticket are not described in [7], and they may take several roundtrips, depending on many Kerberos-related factors 🔁. As an optimization, the Kerberos ticket does not need to be included in every RSVP message, as described in Section 7.1 of [1] ⚡. So the receiver must store the received service ticket 🗄️. If the ticket's lifetime has expired, then a new service ticket must be sent ⏰. If the receiver lost its state information (because of a crash or restart), then it may transmit an Integrity Challenge message to force the sender to re-transmit a new service ticket 🔄.
If either the X.509 V3 or the PGP certificate is included in the policy element, then a digital signature must be added ✍️. The digital signature computed over the entire AUTH_DATA object provides authentication and integrity protection 💖. The SubType of the digital signature authentication attribute is set to zero before computing the digital signature 0️⃣. Whether or not the digital signature provides a guarantee of freshness with replay protection (either timestamps or sequence numbers) is an open issue, as discussed in Section 4.3 🤷♀️.
- Digital Signature ✍️
The digital signature computed over the contents of the AUTH_DATA object must be the last attribute 🏁. The algorithm used to compute the digital signature depends on the authentication mode listed in the credential 🔧. This is only partially true, because, for example, PGP again allows different algorithms to be used for computing a digital signature 🐉. The algorithm identifier used for computing the digital signature is not included in the certificate itself 🙈. The algorithm identifier that is included in the certificate only serves to allow verification of the signature computed by the certificate authority (except for self-signed certificates) 📜.
- Policy Error Object 🚨
The Policy Error Object is used when policy-based admission control or other credential verification fails 😬. Currently available error messages allow notification if the credentials are expired (EXPIRED_CREDENTIALS), if the authorization process disallowed the resource request (INSUFFICIENT_PRIVILEGES), or if the given set of credentials is not supported (UNSUPPORTED_CREDENTIAL_TYPE) 💀. The last error message returned by the network lets the user's host discover the type of credentials supported 🔍. Particularly in mobile environments, this might be quite inefficient 📶. Furthermore, it is unlikely that a user supports different types of credentials 🙄. The purpose of the error message IDENTITY_CHANGED is unclear 🤨. Also, the protection of the error message is not discussed in [7] 🫠.
3.5. RSVP Integrity Handshake ✨
okay so the Integrity Handshake exists so a host that crashed or restarted can grab the latest valid challenge value stored at the receiving host 🔄. there's no key management here, so it must be guaranteed that two messages never use the same sequence number with the same key 🔐. a host keeps track of the latest sequence number from a message it has cryptographically verified 📝.
the problem is that if a crashed host lost its sequence numbers, an eavesdropper can replay old packets 😬. the fix is a fresh signaling message from the real sender with a new sequence number. that lets the crashed host update its sequence number field and stop further replays 🛑. so if the two hosts are constantly exchanging RSVP-protected messages, an attacker will have a harder time injecting old ones, because new authenticated messages with higher sequence numbers keep arriving and get stored right away 💅
the next part walks through the RSVP Integrity Handshake that Node A starts after recovering from a synchronization failure 🦋
Integrity Challenge
(1) Message (including
+----------+ a Cookie) +----------+
| |-------------------------->| |
| Node A | | Node B |
| |<--------------------------| |
+----------+ Integrity Response +----------+
(2) Message (including
the Cookie and the
INTEGRITY object)Figure 3: RSVP Integrity Handshake. 🎀
here's how the messages are built 🧩
CHALLENGE:=(Key Identifier, Challenge Cookie)
Integrity Challenge Message:=(Common Header, CHALLENGE)
Integrity Response Message:=(Common Header, INTEGRITY, CHALLENGE)the "Challenge Cookie" is suggested to be an MD5 hash of a local secret and a timestamp [1] 🌸
the Integrity Challenge message doesn't get an INTEGRITY object, as the flow above shows. Section 10 of [1] explains why: it avoids trouble when neither party has a valid starting sequence number 🙈
using the RSVP Integrity Handshake protocol is recommended, but it's not mandatory, since it may not be needed in every network environment 🌈
4. Detailed Security Property Discussion ✨
this section covers how RSVP protects authentication, authorization, integrity and replay protection one by one, plus user identity confidentiality and the confidentiality of the signaling messages, 🔒
4.1. Network Topology 🗺️
this part shows the basic interfaces in a simple RSVP network. the setup assumes there's only a single domain and that both routers are RSVP- and policy-aware 🧠. those assumptions get relaxed in the individual sections when needed ✨. Layer 2 devices between the clients and their first-hop routers aren't drawn 🙅. other stuff like a Kerberos Key Distribution Center, plus an LDAP server where the PDP pulls its policies from, is left out too 💀. the security of the interfaces to these servers (KDC, PDP, etc.) depends a LOT on the security policy of the specific network service provider 👑
+--------+
| Policy |
+----|Decision|
| | Point +---+
| +--------+ |
| |
| |
+------+ +-+----+ +---+--+ +------+
|Client| |Router| |Router| |Client|
| A +-------+ 1 +--------+ 2 +----------+ B |
+------+ +------+ +------+ +------+Figure 4: Simple RSVP Architecture. 🧚
4.2. Host/Router 🎀
okay so when we talk about authentication in RSVP, it's important to split things up: user authentication and host authentication of the signaling messages 💅 the host gets authenticated by the RSVP INTEGRITY object, while credentials inside the AUTH_DATA object can be used to authenticate the user 🫶 this section is all about host authentication, and the next section covers users ✨
(1) Authentication ✨
okay so "host authentication" is the term we're using up there, and it's because the security association gets picked based on the host's IP address, as mentioned in Section 3.1 and Section 3.2 🌸 depending on the key management protocol used to set up that security association and the identity used, it's also possible to tie a user identity to it 👀 but since the key management protocol isn't specified, it's kinda hard to evaluate this part, so we're talking about data-origin authentication based on the host's identity for RSVP INTEGRITY objects 🦋 the fact that the host identity is used to select the security association was already covered in Section 3.1 💜
data-origin authentication comes from a keyed hash value that's computed over the entire RSVP message, excluding the keyed message digest field itself 🔥 the security association between the user's host and the first-hop router is not set up by RSVP (like we said before), so it has to be available before signaling even starts 🧚
- Kerberos for the RSVP INTEGRITY object 👑
Section 7 of [1] says Kerberos can be used to create the key for the RSVP INTEGRITY object ✨ how to learn the principal name (and realm information) of the other node is outside the scope of [1] 🙈 but [20] describes a way to distribute principal and realm information via DNS, which can be used for this (assuming you know the FQDN or the IP address of the other node you want the info for) 🌈 all that's required is to put the Kerberos ticket inside the policy element 💖 it's also mentioned that Kerberos tickets with an expired lifetime must not be used, and the initiator is responsible for requesting and exchanging a new service ticket before expiration ⏰
RSVP multicast processing with Kerberos comes with extra considerations 😭 Section 7 of [1] states that in the multicast case, all receivers must share a single key with the Kerberos Authentication Server (so basically one principal used for all receivers) 💀 from a personal discussion with Rodney Hess, it seems there's no other solution available in the Kerberos context right now 🥺 so multicast handling leaves some open questions here 🫠
if one entity crashes, the established security association is lost, so the other node has to retransmit the service ticket 🍓 the crashed entity can use an Integrity Challenge message to request a new Kerberos ticket to be retransmitted by the other node ✨ and if a node gets such a request, a reply message must be returned 💌
(2) Integrity protection 🛡️
integrity protection between the user's host and the first-hop router is based on the RSVP INTEGRITY object 💜 HMAC-MD5 is preferred, though other keyed hash functions can also be used within the RSVP INTEGRITY object 🌸 either way, both communicating entities need a security association that says which algorithm to use 🧁 this can be kinda tricky, because no negotiation protocol is defined to agree on a specific algorithm 😩 so if RSVP is used in a mobile environment, it's likely that HMAC-MD5 is the only usable algorithm for the RSVP INTEGRITY object 📱 switching to a different keyed hash algorithm might only make sense in local environments 🏠 the other option is for every implementation to support the most important keyed hash algorithms, e.g., MD5, SHA-1, RIPEMD-160, etc. 🦋 HMAC-MD5 was chosen mainly because of its performance characteristics ⚡ the weaknesses of MD5 [21] are known and were first described in [22] 🙈 other algorithms like SHA-1 [15] and RIPEMD-160 [21] have stronger security properties 💪
(3) Replay Protection 🔁
the main mechanism for replay protection in RSVP is based on sequence numbers, and the sequence number is included in the RSVP INTEGRITY object 🎀 the properties of this sequence number mechanism are described in Section 3.1 of [1] 📖 the fact that the receiver stores a list of sequence numbers is a sign of a window mechanism 🪟 and that kinda conflicts with the requirement that the receiver only has to store the highest number given in Section 3 of [1] 😬 we assume this is an oversight 🫶 Section 4.2 of [1] has a few comments about out-of-order delivery and an implementation's ability to specify the replay window 🌈 Appendix C of [3] describes a window mechanism for handling out-of-sequence delivery 🧚
(4) Integrity Handshake 🤝
the Integrity Handshake mechanism is explained in Section 3.5 ✨ the Cookie value is suggested to be a hash of a local secret and a timestamp 🍪 the Cookie value is not verified by the receiver 🙃 the Integrity Handshake uses a simple Challenge/Response message, which assumes the key shared between the two hosts survives the crash 💔 but if the security association is created dynamically, this assumption may not be true 😳
in Section 10 of [1], the authors note that an adversary can create a faked Integrity Handshake message that includes challenge cookies 😱 the adversary could then store the received response and later try to replay these responses while a responder is recovering from a crash or restart 🚨 if this replayed Integrity Response value is valid and has a lower sequence number than what's actually been used, then this value gets stored at the recovering host 💀 for this attack to work, the adversary must either have collected a large number of challenge/response value pairs, or have "discovered" the cookie generation mechanism (for example by knowing the local secret) 🕵️♀️ collecting Challenge/Response pairs is even harder, because they depend on the Cookie value, the sequence number included in the response message, and the shared key used by the INTEGRITY object 🥹
(5) Confidentiality 🤫
confidentiality isn't considered a security requirement for RSVP 🙅♀️ so RSVP doesn't support it, except as described in paragraph d) of Section 4.3 🎀 this assumption might not hold, though, for enterprises or carriers who want to protect billing data, network usage patterns, or network configurations, along with users' identities, from eavesdropping and traffic analysis 💼 confidentiality can also help make certain other attacks harder 🛑 for example, the PathErr attack described in Section 5.2 is harder to pull off if the attacker can't observe the Path message that the PathErr corresponds to 👀
(6) Authorization 🪪
authorization has two subcategories: network access authorization and RSVP request authorization 🔑 access authorization is provided when a node is authenticated to the network, e.g., using EAP [23] together with AAA protocols (for example, RADIUS [24] or DIAMETER [9]) 🌐 issues related to network access authentication and authorization are outside the scope of RSVP 🙈
the second one, RSVP request authorization, is about RSVP itself 💅 depending on the network configuration:
- the router either forwards the received RSVP request to the policy decision point (e.g., using COPS [10] and [11]) to ask for an admission control procedure to be executed, or
- the router supports the functionality of a PDP, so there's no need to forward the request, or
- the router may already be configured with the appropriate policy information to decide locally whether to grant this request 🧠
based on the result of admission control, the request may be granted or rejected 🎟️ information about the resource-requesting entity must be available to provide policy-based admission control 📇
(7) Performance ⚡
computing the keyed message digest for an RSVP INTEGRITY object isn't a performance problem 🏃♀️ protecting signaling messages is usually not a problem either, because these messages are sent at a low rate 🐢 even a high volume of messages doesn't cause performance problems for an RSVP router, thanks to how efficient the keyed message digest routine is 🏎️
dynamic key management is computationally more demanding, but it's more important for scalability 📈 because RSVP doesn't specify a particular key exchange protocol, it's hard to estimate the effort needed to create the required security associations 🤷♀️ and the number of key exchanges triggered depends on security policy issues like the lifetime of a security association, the required security properties of the key exchange protocol, the authentication mode used by the key exchange protocol, etc. 🗓️ in a stationary environment with a single administrative domain, manual security association establishment may be acceptable and may give the best performance characteristics 🏡 in a mobile environment, asymmetric authentication methods are likely to be used with a key exchange protocol, and some sort of public key or certificate verification needs to be supported 🔐
4.3. User to PEP/PDP 🧚♀️
as noted in the previous section, RSVP supports both user-based and host-based authentication 💖 using RSVP, a user may authenticate to the first hop router or to the PDP as specified in [1], depending on the infrastructure provided by the network domain or the architecture used (e.g., the integration of RSVP and Kerberos V5 into the Windows 2000 Operating System [25]) 🪟 another architecture where RSVP is tightly integrated is the one specified by the PacketCable organization 📞 the interested reader is referred to [26] for a discussion of their security architecture 📚
(1) Authentication 🔐
Okay so when a user sends an RSVP PATH or RESV message 💌, that message can carry info to prove who they are 🪪. [7] explains how the user and app info gets tucked into the RSVP message (AUTH_DATA object) and how to lock it down 🔐. A router that gets one of these can use that info to authenticate the client and pass the user or app info along to the policy decision point (PDP) 🎀. The PDP can also authenticate the user itself, which we'll get to in the next section ✨. To authenticate the user, verify integrity, and check for replays, the whole POLICY_DATA element has to be forwarded from the router to the PDP (e.g., by putting the element into a COPS message) 🚚. It's assumed, though [7] doesn't spell it out, that the INTEGRITY object inside the POLICY_DATA element goes to the PDP along with all the other attributes 🤔.
Certificate Verification
Using the policy element as described in [7], you can't include a certificate revocation list or any other info that proves a certificate is still valid, inside the policy element 🙅♀️. [7] doesn't discuss a specific certificate verification mechanism, so there are a bunch you could use 🧩. For verification, the network element (a router or the PDP) that needs to authenticate the user could download certificate revocation lists pretty often, or use something like the Online Certificate Status Protocol (OCSP) [27] and the Simple Certificate Validation Protocol (SCVP) [28] to check a certificate's current status 📜.
User Authentication to the PDP
This alternative flow has the PDP authenticate the user instead of the first-hop router 👑. Section 4.2.1 of [7] gives the user a choice: get a session ticket for the next hop router or for the PDP 🎟️. As that same section notes, the identity of the PDP or next hop router is either statically configured or dynamically retrieved 🗂️. So now let's look at user authentication to the PDP 💅.
Kerberos-based Authentication to the PDP
If Kerberos is used to authenticate the user, a session ticket for the PDP must be requested first 🎫. A user who roams between routers in the same administrative domain doesn't need a new service ticket, because most or all of the first-hop routers in that domain will probably use the same PDP 🏠. That's different from the case where you need a session ticket for a router and have to authenticate to that router 🙃. Here the router is basically passive: it just forwards the request to the PDP and carries out whatever policy decision comes back 📨. Appendix B describes one example of user-to-PDP authentication 📚.
User authentication with the policy element only gives unilateral authentication, meaning the client authenticates to the router or PDP, not the other way round 🫤. If an RSVP message goes to the user's host and public-key-based authentication isn't used, the message has no certificate or digital signature, so no mutual authentication can be assumed 🙈. With Kerberos, mutual authentication may be accomplished if the PDP or the router sends a policy element with an INTEGRITY object computed using the session key from the Kerberos ticket, or if the Kerberos ticket included in the policy element is also used for the RSVP INTEGRITY object as described in Section 4.2 😮. But this only works if an earlier message already went from the end host to the network and that key is already established 🔑. [7] doesn't discuss this issue, so there's no particular requirement for sending network-specific credentials back to the end user's host 🤷♀️.
(2) Integrity Protection
Integrity protection is applied separately to the RSVP message and the POLICY_DATA element, as shown in Figure 1 🧱. If there's a policy-ignorant node along the path, the RSVP INTEGRITY object and the INTEGRITY object inside the policy element end at different nodes 🛤️. Basically, the same is true for the user credentials if they're verified at the PDP instead of the first hop router 🎯.
Kerberos
If Kerberos is used to authenticate the user to the first hop router, then the session key included in the Kerberos ticket may be used to compute the INTEGRITY object of the policy element 🗝️. It's the keyed message digest that provides the authentication. The existence of the Kerberos service ticket inside the AUTH_DATA object does not provide authentication or a guarantee of freshness for the receiving host 🙅♀️.
Authentication and freshness are provided by the keyed hash value of the INTEGRITY object inside the POLICY_DATA element 🔥. This shows that the user actively took part in the Kerberos protocol and was able to get the session key to compute the keyed message digest 💜. The Authenticator used in the Kerberos V5 protocol gives similar functionality, but replay protection is based on timestamps (or on a sequence number if the optional seq-number field inside the Authenticator is used for KRB_PRIV/KRB_SAFE messages as described in Section 5.3.2 of [8]) ⏰.
Digital Signature
If public-key-based authentication is provided, user authentication is done with a digital signature ✍️. As explained in Section 3.3.3 of [7], the DIGITAL_SIGNATURE attribute must be the last attribute in the AUTH_DATA object, and the digital signature covers the entire AUTH_DATA object. For PGP, which hash algorithm and public key algorithm are used for the digital signature computation is described in [19] 🔏. X.509 is more complicated 😩. Different mechanisms like CMS [29] or PKCS#7 [30] may be used for digitally signing the message element. X.509 only provides the standard for the certificate layout, which seems to give insufficient info for this purpose. Therefore, X.509 certificates are supported, for example, by CMS or PKCS#7. [7], however, makes no statements about the usage of CMS or PKCS#7. Currently there is no support for CMS or for PKCS#7 [7], which provides more than just public-key-based authentication (e.g., CRL distribution, key transport, key agreement, etc.). Furthermore, the use of PGP in RSVP is vaguely defined, because there are different versions of PGP (including OpenPGP [19]), and no indication is given as to which should be used 🌀.
Supporting public-key-based mechanisms in RSVP might increase the risks of denial-of-service attacks 🚨. The large processing, memory, and bandwidth requirements should also be considered. Fragmentation might also be an issue here 💀.
If the INTEGRITY object is not included in the POLICY_DATA element or not sent to the PDP, then we have to make the following observations 👀.
For the digital signature case, only the replay protection provided by the digital signature algorithm can be used. It's not clear, however, whether this usage was anticipated or not. Hence, we might assume that replay protection is based on the availability of the RSVP INTEGRITY object used with a security association that is established by other means 🧐.
Including only the Kerberos session ticket is insufficient, because freshness isn't provided (since the Kerberos Authenticator is missing). Obviously there's no guarantee that the user actually followed the Kerberos protocol and was able to decrypt the received TGS_REP (or, in rare cases, the AS_REP if a session ticket is requested with the initial AS_REQ) 😬.
(3) Replay Protection
Figure 5 shows the interfaces relevant for replay protection of signaling messages in a more complicated architecture 🦋. In this case, the client uses the policy data element with PEP2, because PEP1 is not policy-aware. The interfaces between the client and PEP1 and between PEP1 and PEP2 are protected with the RSVP INTEGRITY object. The link between PEP2 and the PDP is protected, for example, by using the COPS built-in INTEGRITY object. The dotted line between the Client and the PDP indicates the protection provided by the AUTH_DATA element, which has no RSVP INTEGRITY object included 🌸.
AUTH_DATA +----+
+---------------------------------------------------+PDP +-+
| +----+ |
| |
| |
| COPS |
| INTEGRITY|
| |
| |
| |
+--+---+ RSVP INTEGRITY +----+ RSVP INTEGRITY +----+ |
|Client+-------------------+PEP1+----------------------+PEP2+-+
+--+---+ +----+ +-+--+
| |
+-----------------------------------------------------+
POLICY_DATA INTEGRITY
Figure 5: Replay Protection.Host authentication with the RSVP INTEGRITY object and user authentication with the INTEGRITY object inside the POLICY_DATA element both use the same anti-replay mechanism 🔁. The length of the Sequence Number field, sequence number rollover, and the Integrity Handshake have already been explained in Section 3.1 🧠.
Section 9 of [7] states: "RSVP INTEGRITY object is used to protect the policy object containing user identity information from security (replay) attacks." 📖
When using public-key-based authentication, RSVP-based replay protection is not supported, because the digital signature does not cover the POLICY_DATA INTEGRITY object with its Sequence Number field 🚫. The digital signature covers only the entire AUTH_DATA object 🔒.
(4) (User Identity) Confidentiality ✨
Okay, so this part is all about keeping the user's identity private 🔒 Since RSVP has no built-in way to encrypt the POLICY_DATA object or the AUTH_DATA elements, this section looks at encrypting just one attribute inside AUTH_DATA: the POLICY_LOCATOR attribute 🫶
To protect the user's privacy, you really don't want to reveal their identity to an adversary sitting between the user's host and the first-hop router (think a wireless link 📡). User identities also shouldn't be sent outside the domain of the visited network provider. So the user identity info inside the policy data element should be removed or modified by the PDP, so other unauthorized entities along the signaling path can't see it 🙈 Honestly, with the mechanisms on offer, you can't fully hide the user's identity from the first policy-aware RSVP node (or from the attached network in general). Not possible, bestie 💀
The ASCII or Unicode distinguished name of the user or application inside the POLICY_LOCATOR attribute of the AUTH_DATA element may be encrypted as specified in Section 3.3.1 of [7]. The user (or application) identity gets encrypted with either the Kerberos session key or the private key, depending on whether public-key-based authentication is used. When the private key is used, we usually call it a digital signature, which anyone holding the public key can verify 🔑 And here's the catch: the certificate with the public key is included in the message itself, so decryption is no obstacle. Plus the included certificate, together with the other unencrypted info in the RSVP message, gives an eavesdropper plenty of identity info anyway 👀 So encrypting the policy locator with public-key-based authentication is problematic.
To encrypt identities using asymmetric cryptography, the user's host has to somehow retrieve the public key of the entity verifying the policy element (that's the first policy-aware router or the PDP) 🗝️ Then that public key could encrypt a symmetric key, which in turn encrypts the user's identity and certificate, the same way PGP does it. Currently, no such mechanism is defined in [7] 😭
The algorithm used to encrypt the POLICY_LOCATOR with the Kerberos session key is assumed to be the same one used for encrypting the service ticket. You can find the algorithm info in the etype field of the EncryptedData ASN.1 encoded message part. Section 6.3 of [8] lists the supported algorithms, and [33] defines newer encryption algorithms (Rijndael, Serpent, and Twofish) 🔥
Evaluating user identity confidentiality also means looking at protocols that run outside of RSVP, like Kerberos 🧚 The ticket included in the CREDENTIAL attribute can help protect user identity by leaving out the optional cname attribute from the unencrypted part of the Ticket. Since the Authenticator isn't sent with the RSVP message, the cname and crealm in the unencrypted part of the Authenticator don't get revealed either ✨ But to request the Kerberos session ticket for the CREDENTIAL attribute, the user has to run the Kerberos protocol exchange first. Then the Authenticator sent with the TGS_REQ reveals the user's identity anyway 👀 The AS_REQ also has to include the user's identity so the Kerberos Authentication Server can respond with an AS_REP message encrypted with the user's secret key. So with Kerberos, the only thing you can hide is the content of the encrypted policy locator, and that only helps if this value is different from the Kerberos principal name. Bottom line: with Kerberos, it's not "entirely" possible to get user identity confidentiality 🙃
Also, super important: information stored in the policy element can get changed by a policy-aware router or by the policy decision point 🦋 Which parts get changed depends on whether multicast or unicast is used, how the policy server reacts, where the user is authenticated, whether the user needs to be re-authenticated in other network nodes, and so on. So user-specific and application-specific info can leak once messages leave the first hop in the network where the user's host is attached. As mentioned at the start of this section, this info leakage is assumed to be intentional 💅
(5) Authorization 👑
On top of the authorization steps of the Host-to-Router interface, user-based authorization happens through the policy element, which carries the user credentials 🎀 Including user and application specific info makes policy-based admission control with special user policies possible, and those policies are likely stored on a dedicated server. So a Policy Decision Point can query, for example, an LDAP server for a service level agreement that says how many resources a certain user is allowed to request 💖 Group membership and other non-security-related info may also feed into the final policy decision. If the user isn't registered to the currently attached domain, there's the question of how much info the user's home domain is willing to share. And that also affects the user's privacy policy 🌸
Honestly, the user may not want to hand out much of this policy info 🙈 Also, the lack of a standardized authorization data format may cause interoperability problems when policy info gets exchanged. So we can assume the policy decision point may use info from an initial authentication and key agreement protocol to forward accounting messages to the user's home domain 🧾 That initial protocol may already have needed cross-realm communication with the home domain, if only to show the home domain knows the user and that the user is entitled to roam. This is the traditional subscriber-based accounting scenario. Non-traditional or alternative means of access might get deployed in the near future that don't need any inter-domain communication at all 🌈
Additional discussion is still needed to figure out the expected authorization procedures. [34] and [35] discuss authorization issues for QoS signaling protocols, and [36] describes a number of mobility implications for policy handling in RSVP ⭐
(6) Performance 🚀
If Kerberos is used for user authentication, a Kerberos ticket has to be included in the CREDENTIAL Section of the AUTH_DATA element. That ticket is larger than 500 bytes, but it only needs to be sent once, because a performance optimization lets the session key get cached, as noted in Section 7.1 of [1] 🍓 After that, it's assumed that subsequent RSVP messages only include the POLICY_DATA INTEGRITY object with a keyed message digest that uses the Kerberos session key. But this assumes the security association needed for the POLICY_DATA INTEGRITY object is created (or modified) so the correct key can be selected. Otherwise, it's hard to say which identifier is used to index the security association 🤔
If Kerberos is used as the authentication system, then from a performance perspective, the message exchange to get the session key needs to be considered too. The good news is it only needs to happen once in the lifetime of the session ticket 💜 This matters even more in a mobile environment with a fast-roaming user's host 🏃♀️
Public-key-based authentication usually gives the best scalability for key distribution, but those protocols are performance demanding 😤 A major downside of public-key-based user authentication in RSVP is that there's no method to derive a session key. So every RSVP PATH or RESV message includes the certificate and a digital signature, which is a huge performance and bandwidth penalty 💀 For a mobile environment with low power devices, high latency, channel noise, and low-bandwidth links, that's not very encouraging at all. Also, a public key infrastructure is required so the PDP (or the first-hop router) can verify the digital signature and the certificate 🔐 To check for revoked certificates, you need certificate revocation lists, or protocols like the Online Certificate Status Protocol [27] and the Simple Certificate Validation Protocol [28]. Then the integrity of the AUTH_DATA object can be verified via the digital signature ✨
4.4. Communication between RSVP-Aware Routers 🦋
(1) Authentication 🔐
okay so RSVP signaling messages get data origin authentication and are protected against modification and replay with the RSVP INTEGRITY object. The RSVP message flow between routers is protected based on the chain of trust, so each router only needs a security association with its neighboring routers ✨. This assumption was made because of performance advantages and because the core network has special security characteristics: no user hosts are directly attached to it 💅. In the core network the network structure does not change frequently, so the manual distribution of shared secrets for the RSVP INTEGRITY object may be acceptable. The shared secrets may be either manually configured or distributed by using appropriately secured network management protocols like SNMPv3 🔑.
Independent of the key distribution mechanism, host authentication with built-in RSVP mechanisms is accomplished using the keyed message digest in the RSVP INTEGRITY object, computed using the previously exchanged symmetric key 🫶.
(2) Integrity Protection 🧱
Integrity protection is accomplished with the RSVP INTEGRITY object with the variable length Keyed Message Digest field.
(3) Replay Protection 🔁
Replay protection with the RSVP INTEGRITY object is extensively described in previous sections. To enable crashed hosts to learn the latest sequence number used, the Integrity Handshake mechanism is provided in RSVP.
(4) Confidentiality 🙈
Confidentiality is not provided by RSVP. no cap 💀
(5) Authorization 👑
Depending on the RSVP network, QoS resource authorization at different routers may need to contact the PDP again. Because the PDP is allowed to modify the policy element, a token may be added to the policy element to increase the efficiency of the re-authorization procedure. This token is used to refer to an already computed policy decision. The communications interface from the PEP to the PDP must be properly secured 🛡️.
(6) Performance 🌈
The performance characteristics for the protection of the RSVP signaling messages are largely determined by the key exchange protocol, because the RSVP INTEGRITY object is only used to compute a keyed message digest of the transmitted signaling messages.
The security associations within the core network, that is, between individual routers (in comparison with the security association between the user's host and the first-hop router or with the attached network in general), can be established more easily because of the normally strong trust assumptions. Furthermore, it is possible to use security associations with an increased lifetime to avoid frequent rekeying. Hence, there is less impact on the performance compared with the user-to-network interface. The security association storage requirements are also less problematic.
5. Miscellaneous Issues ⚠️
This section describes a number of issues that illustrate some of the shortcomings of RSVP with respect to security.
5.1. First-Hop Issue 🚪
In case of end-to-end signaling, an end host starts signaling to its attached network. The first-hop communication is often more difficult to secure because of the different requirements and a missing trust relationship. An end host must therefore obtain some information to start RSVP signaling:
- Does this network support RSVP signaling?
- Which node supports RSVP signaling?
- To which node is authentication required?
- Which security mechanisms are used for authentication?
- Which algorithms are required?
- Where should the keys and security associations come from?
- Should a security association be established?
RSVP, as specified today, is used as a building block. Hence, these questions have to be answered as part of overall architectural considerations. Without answers to these questions, ad hoc RSVP communication by an end host roaming to an unknown network is not possible. A negotiation of security mechanisms and algorithms is not supported for RSVP 😭.
5.2. Next-Hop Problem 🧭
Throughout the document it was assumed that the next RSVP node along the path is always known. Knowing the next hop is important to be able to select the correct key for the RSVP Integrity object and to apply the proper protection. In the case in which an RSVP node assumes it knows which node is the next hop, the following protocol exchange can occur:
Integrity
(A<->C) +------+
(3) | RSVP |
+------------->+ Node |
| | B |
Integrity | +--+---+
(A<->C) | |
+------+ (2) +--+----+ |
(1) | RSVP +----------->+Router | | Error
----->| Node | | or +<-----------+ (I am B)
| A +<-----------+Network| (4)
+------+ (5) +--+----+
Error .
(I am B) . +------+
. | RSVP |
...............+ Node |
| C |
+------+
Figure 6: Next-Hop Issue.When RSVP node A in Figure 6 receives an incoming RSVP Path message, standard RSVP message processing takes place. Node A then has to decide which key to select to protect the signaling message. We assume that some unspecified mechanism is used to make this decision. In this example, node A assumes that the message will travel to RSVP node C. However, for some reasons (e.g., a route change, inability to learn the next RSVP hop along the path, etc.) the message travels to node B via a non-RSVP supporting router that cannot verify the integrity of the message (or cannot decrypt the Kerberos service ticket). The processing failure causes a PathErr message to be returned to the originating sender of the Path message. This error message also contains information about the node that recognized the error. In many cases, a security association might not be available. Node A receiving the PathErr message might use the information returned with the PathErr message to select a different security association (or to establish one).
Figure 6 describes a behavior that might help node A learn that an error occurred. However, the description in Section 4.2 of [1] states in step (5) that a signaling message is silently discarded if the receiving host cannot properly verify the message: "If the calculated digest does not match the received digest, the message is discarded without further processing." For RSVP Path and similar messages, this functionality is not really helpful 🙄.
The RSVP Path message therefore provides a number of functions: path discovery, detecting route changes, discovery of QoS capabilities along the path using the Adspec object (with some interpretation), next-hop discovery, and possibly security association establishment (for example, in the case of Kerberos). ✨
From a security point of view, there are conflicts between:
- Idempotent message delivery and efficiency 🔥: The RSVP Path message especially performs a number of functions. Supporting idempotent message delivery somehow contradicts with security association establishment, efficient message delivery, and message size. For example, a "real" idempotent signaling message would contain enough information to perform security processing without depending on a previously executed message exchange. Adding a Kerberos ticket with every signaling message is, however, inefficient. Using public-key-based mechanisms is even more inefficient when included in every signaling message. With public-key-based protection for idempotent messages, there is the additional risk of introducing denial-of-service attacks.
- RSVP Path message functionality and next-hop discovery 🎀: To protect an RSVP signaling message (and an RSVP Path message in particular) it is necessary to know the identity of the next RSVP-aware node (and some other parameters). Without a mechanism for next-hop discovery, an RSVP Path message is also responsible for this task. Without knowing the identity of the next hop, the Kerberos principal name is also unknown. The so-called Kerberos user-to-user authentication mechanism, which would allow the receiver to trigger the process of establishing Kerberos authentication, is not supported. This issue will again be discussed in relationship with the last-hop problem.
It is fair to assume that an RSVP-supporting node might not have security associations with all immediately neighboring RSVP nodes. Especially for inter-domain signaling, IntServ over DiffServ, or some new applications such as firewall signaling, the next RSVP-aware node might not be known in advance. The number of next RSVP nodes might be considerably large if they are separated by a large number of non-RSVP aware nodes. Hence, a node transmitting an RSVP Path message might experience difficulties in properly protecting the message if it serves as a mechanism to detect both the next RSVP node (i.e., Router Alert Option added to the signaling message and addressed to the destination address) and to detect route changes. It is fair to note that, in the intra-domain case with a dense distribution of RSVP nodes, protection might be possible with manual configuration.
Nothing prevents an adversary from continuously flooding an RSVP node with bogus PathErr messages, although it might be possible to protect the PathErr message with an existing, available security association. A legitimate RSVP node would believe that a change in the path took place. Hence, this node might try to select a different security association or try to create one with the indicated node. If an adversary is located somewhere along the path, and either authentication or authorization is not performed with the necessary strength and accuracy, then it might also be possible to act as a man-in-the-middle. One method of reducing susceptibility to this attack is as follows: when a PathErr message is received from a node with which no security association exists, attempt to establish a security association and then repeat the action that led to the PathErr message. 🚨
5.3. Last-Hop Issue 🎀
okay so this section is about the practical headaches you get when authentication and key establishment happen through a two-party protocol that's kinda asymmetric in how each side processes messages 🧐. Kerberos is that protocol, and it's also the only supported one that gives RSVP dynamic session key establishment ✨. For first-hop communication, authentication usually happens between a user and some router (like the access router). Especially in a mobile environment, it's not feasible to authenticate end hosts based on their IP or MAC address 🙈. To show the problem, here are the typical Kerberos steps for first-hop communication:
- End host A learns the identity (aka the Kerberos principal name) of some entity B. This entity B is either the next RSVP node, a PDP, or the next policy-aware RSVP node.
- Entity A then requests a ticket granting ticket for the network domain. This assumes that the identity of the network domain is known.
- Entity A then requests a service ticket for entity B, whose name was learned in step (1).
- Entity A includes the service ticket with the RSVP signaling message (inside the policy object). The Kerberos session key is used to protect the integrity of the entire RSVP signaling message 🔐.
For last-hop communication, this processing theoretically has to be reversed 🔄. Now entity A is a node in the network (like the access router), and entity B is the other end host (assuming RSVP signaling happens between two end hosts, not between an end host and an application server). The thing is, the access router in step (1) might not be able to learn the user's principal name, because that info might not be available 😭. Entity A could reverse the process by triggering an IAKERB exchange. That would cause entity B to request a service ticket for A, as described above. However, IAKERB is not supported in RSVP 💀.
5.4. RSVP- and IPsec-Protected Data Traffic 🦋
QoS signaling needs flow information established at routers along a path. This flow identifier installed at each device tells the router which data packets should get QoS treatment 🍓. RSVP typically sets up a flow identifier based on the 5-tuple (source IP address, destination IP address, transport protocol type, source port, and destination port). If that 5-tuple info isn't available, other identifiers have to be used. ESP-encrypted data traffic is a perfect example, because the transport protocol and the port numbers aren't accessible. So the IPsec SPI gets used as a substitute for them 🪄. [12] looks at these IPsec implications for RSVP, and it's based on three assumptions:
(1) An end host that starts the RSVP signaling message exchange has to be able to retrieve the SPI for a given flow. This needs some interaction with the IPsec security association database (SAD) and security policy database (SPD) [3]. An application usually doesn't know the SPI of the protected flow, so it can't provide the values. What it can do is give the signaling protocol daemon the flow identifiers. The signaling daemon would then need to query the SAD by passing in the flow identifiers as input parameters and getting the SPI back as an output parameter 🧠.
(2) [12] assumes end-to-end IPsec protection of the data traffic. If IPsec is applied in a nested fashion, then parts of the path don't get QoS treatment 😬. This can be treated as a tunneling problem that's initiated by the end host. The following figure shows the problem nicely in the case of enforcing secure network access 👀:
+------+ +---------------+ +--------+ +-----+
| Host | | Security | | Router | | Host|
| A | | Gateway (SGW) | | Rx | | B |
+--+---+ +-------+-------+ +----+---+ +--+--+
| | | |
|IPsec-Data( | | |
| OuterSrc=A, | | |
| OuterDst=SGW, | | |
| SPI=SPI1, | | |
| InnerSrc=A, | | |
| InnerDst=B, | | |
| Protocol=X, |IPsec-Data( | |
| SrcPort=Y, | SrcIP=A, | |
| DstPort=Z) | DstIP=B, | |
|=====================>| Protocol=X, |IPsec-Data( |
| | SrcPort=Y, | SrcIP=A, |
| --IPsec protected-> | DstPort=Z) | DstIP=B, |
| data traffic |------------------>| Protocol=X, |
| | | SrcPort=Y, |
| | | DstPort=Z) |
| | |---------------->|
| | | |
| | --Unprotected data traffic---> |
| | | |Figure 7: RSVP and IPsec protected data traffic.
Host A, sending data traffic, would either indicate a 3-tuple <A, SGW, SPI1> or a 5-tuple <A, B, X, Y, Z>. Either way, it's not possible to make a QoS reservation for the entire path 😤. Two similar examples are remote access using a VPN and protection of data traffic between a home agent (or a security gateway in the home network) and a mobile node 🏠. The same problem shows up with nested IPsec (for example, IPsec between A and SGW and between A and B) 🪆.
One possible fix for this problem is to change the flow identifier along the path, so it captures the new flow identifier after an IPsec endpoint 🔧.
IPsec tunnels that neither start nor end at one of the signaling end points (for example, between two networks) should be handled differently, by recursively applying an RSVP signaling exchange for the IPsec tunnel 🔁. RSVP signaling within tunnels is covered in [13].
(3) It's assumed that SPIs don't change during the lifetime of the established QoS reservation. If a new IPsec SA is created, then a new SPI gets allocated for the security association 🆕. To reflect this change, either a new reservation has to be established, or the flow identifier of the existing reservation has to be updated. Because IPsec SAs usually have a longer lifetime, this doesn't seem to be a major issue 😌. IPsec protection of SCTP data traffic might more often require an IPsec SA (and SPI) change, to reflect IP addresses being added to and removed from an SCTP association 🌊.
5.5. End-to-End Security Issues and RSVP 🔐
End-to-end security for RSVP hasn't been discussed throughout the document 🙊. In this context, end-to-end security refers to credentials sent between the two end hosts using RSVP. It's obvious that care must be taken to make sure routers along the path can process and modify the signaling messages according to the prescribed processing procedures 🛣️. Some objects or mechanisms could be used for end-to-end protection, though. The main question is really about the benefit of that end-to-end security 🤔. First, there's the question of how to establish the required security association. Between two arbitrary hosts on the Internet, this might turn out to be quite difficult 😵. Second, the usefulness of end-to-end security depends on the architecture where RSVP is deployed. If RSVP is only used to signal QoS information into the network, and other protocols have to be run beforehand to negotiate the parameters and decide which entity gets charged for the QoS reservation, then no end-to-end security is likely to be needed 💅. Introducing end-to-end security to RSVP would then cause problems with extensions like RSVP proxy [37], Localized RSVP [38], and others that terminate RSVP signaling somewhere along the path without reaching the destination end host 🚧. That kind of behavior could be interpreted as a man-in-the-middle attack 👀⚠️.
5.6. IPsec Protection of RSVP Signaling Messages 🛡️
It's assumed throughout that RSVP signaling messages can also be protected by IPsec [3] in a hop-by-hop fashion between two adjacent RSVP nodes 🧩. RSVP, however, uses special processing of signaling messages, which complicates IPsec protection 😩. As explained in this section, IPsec should only be used to protect RSVP signaling messages in a point-to-point communication environment (i.e., an RSVP message can only reach one RSVP router and not possibly more than one) 📍. This restriction is caused by combining signaling message delivery and discovery into a single message. On top of that, end-to-end addressing complicates IPsec handling a lot 💀. This section covers at least some of these complications.
RSVP messages are sent as raw IP packets with protocol number 46. They might be encapsulated in UDP, as described in Appendix C of [6] 📦. Some RSVP messages (Path, PathTear, and ResvConf) must have the Router Alert IP Option set in the IP header 🚨. These messages are addressed to the (unicast or multicast) destination address, not to the next RSVP node along the path. So an IPsec traffic selector can only use these fields for IPsec SA selection 🎯. If there's only a single path (and possibly all the traffic along it is protected), then there's no problem protecting signaling messages with IPsec ✅. This type of protection isn't common, and it might only be used to secure network access between an end host and its first-hop router 🏠. Because these RSVP messages are addressed to the destination address instead of the next RSVP node, it's not possible to use IPsec ESP [17] or AH [16] in transport mode. Only IPsec in tunnel mode is possible 🚇.
If an RSVP message can take more than one possible path, then the IPsec engine will have trouble protecting it 😵💫. Even if the RSVP daemon installs a traffic selector with the destination IP address, there's still no distinguishing element that lets it select the correct security association for any one of the possible RSVP nodes along the path 🙃. Even if it's possible to apply IPsec protection (in tunnel mode) to RSVP signaling messages by adding some extra information, there's still a chance the tunneled messages won't notice a path change in a non-RSVP router 🫠. In that case, the signaling messages would simply follow a different path than the data 🌀.
RSVP messages like RESV can be protected by IPsec, because they contain enough information to create IPsec traffic selectors that tell apart the various next RSVP nodes 🥳. The traffic selector would then contain the protocol number and the source and destination address pair of the two communicating RSVP nodes 💜.
One benefit of using IPsec is the availability of key management using IKE [39], KINK [40], or IKEv2 [41] 🔑✨.
5.7. Authorization 🔐
okay so [34] lays out two trust models (NJ Turnpike and NJ Parkway) and two authorization models (per-session and per-channel financial settlement) 💅. The NJ Turnpike model is the one that justifies hop-by-hop security protection, and RSVP is all about that model 🛣️. The other trust models aren't really explained in detail, though 🙈. RSVP supports the NJ Parkway model and per-channel financial settlement only a little, not fully 😬. Authenticating the user (or end host) is doable with the user identity representation mechanism, but ngl, authentication alone is often not enough for authorization 🙃.
The policy object procedures in [42] could get a glow-up to support the more efficient per-channel financial settlement model 💖. The trick is to stop doing policy handling between inter-domain networks on every single signaling message ✨. More info on how policy handling is expected to behave in RSVP can also be found in [43] 📚.
[35] and [36] have extra authorization info 🦋. Nobody has a good, agreed-upon way to handle QoS reservation authorization in roaming environments yet, which is a whole mood 😭. Price distribution mechanisms only exist in papers and never made it through standardization 📄. RSVP is built around receiver-initiated reservations, where the data receiver does the authorization for the QoS reservation 🎯. That adds a lot of complexity for mobility handling, as [36] describes 🌀.
6. Conclusions 🎀
RSVP was the first QoS signaling protocol with some security protection baked in 👑. Whether that protection is appropriate really depends on where it gets deployed 🌍. As specified today, RSVP should be seen as a building block that has to be adapted to a given architecture 🧱.
This document is here to give you more insight into RSVP security 🔍. It is NOT a pass or fail grade for the security RSVP provides 🙅♀️.
Real talk, this document is not a complete description of every security issue related to RSVP 💀. Some stuff still needs more thought, like RSVP extensions (for example [12]), multicast issues, and other security properties such as traffic analysis 🕵️♀️. The interaction with mobility protocols (micro- and macro-mobility) also needs more security investigation 🌊.
Practical protocol experience and the growing awareness of security tell us that some credential types have been more widely accepted than others ✨. Kerberos is already integrated into many IETF protocols 🫶. Public-key-based authentication techniques are still considered too heavy-weight (computationally and bandwidth-wise) to use for per-flow signaling 🐢. The increased focus on denial of service attacks also puts extra demands on how public-key-based authentication gets designed 🛡️.
Here's a quick rundown of the security or architectural issues that deserve some love 💕:
- Discovery and signaling message delivery should be separated.
- For some applications and scenarios, it cannot be assumed that neighboring RSVP-aware nodes know each other. Hence, some in-path discovery mechanism should be provided.
- Addressing for signaling messages should be done in a hop-by-hop fashion.
- Standard security protocols (IPsec, TLS, or CMS) should be used whenever possible. Authentication and key exchange should be separated from signaling message protection. In general, it is necessary to provide key management to establish security associations dynamically for signaling message protection. Relying on manually configured keys between neighboring RSVP nodes is insufficient. A separate, less frequently executed key management and security association establishment protocol is a good place to perform entity authentication, security service negotiation and selection, and agreement on mechanisms, transforms, and options.
- The use of public key cryptography in authorization tokens, identity representations, selective object protection, etc. is likely to cause fragmentation, the need to protect against denial of service attacks, and other problems.
- Public key authentication and user identity confidentiality provided with RSVP require some improvement.
- Public-key-based user authentication only provides entity authentication. An additional security association is required to protect signaling messages.
- Data origin authentication should not be provided by non-RSVP nodes (such as the PDP). Such a procedure could be accomplished by entity authentication during the authentication and key exchange phase.
- Authorization and charging should be better integrated into the base protocol.
- Selective message protection should be provided. A protected message should be recognizable from a flag in the header.
- Confidentiality protection is missing and should therefore be added to the protocol. The general principle is that protocol designers can seldom foresee all of the environments in which protocols will be run, so they should allow users to select from a full range of security services, as the needs of different user communities vary.
- Parameter and mechanism negotiation should be provided.
7. Security Considerations 🚨
This document discusses security properties of RSVP and, as such, it is concerned entirely with security 🔒. Literally the whole doc is security, bestie 💀🔥.
8. Acknowledgements 🫶
We would like to thank Jorge Cuellar, Robert Hancock, Xiaoming Fu, Guenther Schaefer, Marc De Vuyst, Bob Grillo, and Jukka Manner for their comments 💖. Additionally, Hannes would like to thank Robert and Jorge for their time discussing various issues 🌸.
Finally, we would like to thank Allison Mankin and John Loughney for their guidance and input 🧚.
9. References 📚
9.1. Normative References
[1] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[2] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000.
[3] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[4] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[6] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[7] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., Herzog, S., and R. Hess, "Identity Representation for RSVP", RFC 3182, October 2001.
[8] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993. Obsoleted by RFC 4120.
[9] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[10] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R., and A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000.
[11] Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan, R., and A. Sastry, "COPS usage for RSVP", RFC 2749, January 2000.
[12] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data Flows", RFC 2207, September 1997.
[13] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP Operation Over IP Tunnels", RFC 2746, January 2000.
9.2. Informative References 📚
Okay, this is the shelf of extra reading, bestie. Every entry is here exactly as the original lists it, so you can track down any of them:
- [14] Hess, R. and S. Herzog, "RSVP Extensions for Policy Control", Work in Progress, June 2001.
- [15] "Secure Hash Standard, NIST, FIPS PUB 180-1", Federal Information Processing Society, April 1995.
- [16] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
- [17] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
- [18] Fowler, D., "Definitions of Managed Objects for the DS1, E1, DS2 and E2 Interface Types", RFC 2495, January 1999.
- [19] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998.
- [20] Hornstein, K. and J. Altman, "Distributing Kerberos KDC and Realm Information with DNS", Work in Progress, July 2002.
- [21] Dobbertin, H., Bosselaers, A., and B. Preneel, "RIPEMD-160: A strengthened version of RIPEMD in Fast Software Encryption", LNCS vol. 1039, pp. 71-82, 1996.
- [22] Dobbertin, H., "The Status of MD5 After a Recent Attack", RSA Laboratories CryptoBytes, vol. 2, no. 2, 1996.
- [23] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
- [24] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
- [25] "Microsoft Authorization Data Specification v. 1.0 for Microsoft Windows 2000 Operating Systems", April 2000.
- [26] Cable Television Laboratories, Inc., "PacketCable Security Specification, PKT-SP-SEC-I01-991201", website:
http://www.PacketCable.com/, June 2003. - [27] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999.
- [28] Malpani, A., Housley, R., and T. Freeman, "Simple Certificate Validation Protocol (SCVP)", Work in Progress, October 2005.
- [29] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369, August 2002.
- [30] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315, March 1998.
- [31] "Specifications and standard documents", website:
http://www.PacketCable.com/, March 2002. - [32] Davis, D. and D. Geer, "Kerberos With Clocks Adrift: History, Protocols and Implementation", USENIX Computing Systems, vol 9 no. 1, Winter 1996.
- [33] Raeburn, K., "Encryption and Checksum Specifications for Kerberos 5", RFC 3961, February 2005.
- [34] Tschofenig, H., Buechli, M., Van den Bosch, S., and H. Schulzrinne, "NSIS Authentication, Authorization and Accounting Issues", Work in Progress, March 2003.
- [35] Tschofenig, H., Buechli, M., Van den Bosch, S., Schulzrinne, H., and T. Chen, "QoS NSLP Authorization Issues", Work in Progress, June 2003.
- [36] Thomas, M., "Analysis of Mobile IP and RSVP Interactions", Work in Progress, October 2002.
- [37] Gai, S., Gaitonde, S., Elfassy, N., and Y. Bernet, "RSVP Proxy", Work in Progress, March 2002.
- [38] Manner, J., Suihko, T., Kojo, M., Liljeberg, M., and K. Raatikainen, "Localized RSVP", Work in Progress, September 2004.
- [39] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
- [40] Thomas, M., "Kerberized Internet Negotiation of Keys (KINK)", Work in Progress, October 2005.
- [41] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, November 2005.
- [42] Herzog, S., "Accounting and Access Control in RSVP", PhD Dissertation, USC, Work in Progress, November 1995.
- [43] Herzog, S., "Accounting and Access Control for Multicast Distributions: Models and Mechanisms", June 1996.
- [44] Pato, J., "Using Pre-Authentication to Avoid Password Guessing Attacks", Open Software Foundation DCE Request for Comments, December 1992.
- [45] Tung, B. and L. Zhu, "Public Key Cryptography for Initial Authentication in Kerberos", Work in Progress, November 2005.
- [46] Wu, T., "A Real-World Analysis of Kerberos Password Security", in Proceedings of the 1999 Internet Society Network and Distributed System Security Symposium, San Diego, February 1999.
- [47] Wu, T., Wu, F., and F. Gong, "Securing QoS: Threats to RSVP Messages and Their Countermeasures", IEEE IWQoS, pp. 62-64, 1999.
- [48] Talwar, V., Nahrstedt, K., and F. Gong, "Securing RSVP For Multimedia Applications", Proc ACM Multimedia 2000 (Multimedia Security Workshop), November 2000.
- [49] Talwar, V., Nahrstedt, K., and S. Nath, "RSVP-SQoS: A Secure RSVP Protocol", International Conf on Multimedia and Exposition, Tokyo, Japan, August 2001.
- [50] Jablon, D., "Strong Password-only Authenticated Key Exchange", ACM Computer Communication Review, 26(5), pp. 5-26, October 1996.
Appendix A. Dictionary Attacks and Kerberos 🔐
Okay, so Kerberos might be used with RSVP the way this document describes. And since dictionary attacks come up a lot whenever Kerberos is mentioned, this appendix covers a few issues. 🧐
The initial Kerberos AS_REQ request (without pre-authentication, without various extensions, and without PKINIT) is unprotected 😬. The response message AS_REP is encrypted with the client's long-term key. So an adversary can take advantage of that by requesting AS_REP messages to mount an off-line dictionary attack. Pre-authentication ([44]) can be used to reduce this problem. However, pre-authentication does not entirely prevent dictionary attacks by an adversary who can still eavesdrop on Kerberos messages along the path between a mobile node and a KDC. With mandatory pre-authentication for the initial request, an adversary cannot request a Ticket Granting Ticket for an arbitrary user. 🙅♀️
On-line password guessing attacks are still possible, though. The adversary picks a password (for example, from a dictionary) and then transmits an initial request that includes a pre-authentication data field. If the KDC doesn't authenticate it, the KDC sends back an error message, and that error gives the adversary a hint to restart the protocol and try a new password. Yikes 💀
There are, however, some proposals that prevent dictionary attacks, and they're iconic 👑. The use of Public Key Cryptography for initial authentication [45] (PKINIT) is one such solution. Other proposals use strong-password-based authenticated key agreement protocols to protect the user's password during the initial Kerberos exchange. [46] discusses the security of Kerberos and also discusses mechanisms to prevent dictionary attacks. Go read it, it's giving research 📖✨
Appendix B. Example of User-to-PDP Authentication 🧚
The following section describes an example of user-to-PDP authentication. Heads up: the description below is not fully covered by the RSVP specification, so it should only be viewed as an example. 🫶
Windows 2000 integrates Kerberos into RSVP, and it uses a configuration with user authentication to the PDP as described in [25]. Here's how the steps for authenticating the user to the PDP go in an intra-realm scenario:
- Windows 2000 requires the user to contact the KDC and to request a Kerberos service ticket for the PDP account AcsService in the local realm.
- This ticket is then embedded into the AUTH_DATA element and included in either the PATH or the RESV message. In the case of Microsoft's implementation, the user identity encoded as a distinguished name is encrypted with the session key provided with the Kerberos ticket. The Kerberos ticket is sent without the Kerberos authdata element that contains authorization information, as explained in [25].
- The RSVP message is then intercepted by the PEP, which forwards it to the PDP. [25] does not state which protocol is used to forward the RSVP message to the PDP.
- The PDP that finally receives the message decrypts the received service ticket. The ticket contains the session key used by the user's host to:
- Encrypt the principal name inside the policy locator field of the AUTH_DATA object and to
- Create the integrity-protected Keyed Message Digest field in the INTEGRITY object of the POLICY_DATA element. The protection described here is between the user's host and the PDP. The RSVP INTEGRITY object, on the other hand, is used to protect the path between the user's host and the first-hop router, because the two message parts terminate at different nodes, and different security associations must be used. The interface between the message-intercepting, first-hop router and the PDP must be protected as well.
- The PDP does not maintain a user database, and [25] describes how the PDP may query the Active Directory (a LDAP based directory service) for user policy information.
Appendix C. Literature on RSVP Security 📚💜
Few documents address the security of RSVP signaling, so this section briefly describes some important ones. 🦋
Improvements to RSVP are proposed in [47] to deal with insider attacks. Insider attacks are caused by malicious RSVP routers that modify RSVP signaling messages in such a way that they cause harm to the nodes participating in the signaling message exchange. Yikes, that's giving villain arc 😈
As a solution, non-mutable RSVP objects are digitally signed by the sender. This digital signature is added to the RSVP PATH message. Additionally, the receiver attaches an object to the RSVP RESV message containing a "signed" history. This value allows intermediate RSVP routers (by examining the previously signed value) to detect a malicious RSVP node. Clever, right? 🕵️♀️
A few issues are, however, left open in this document. Replay attacks are not covered, so it is assumed that timestamp-based replay protection is used. To identify a malicious node, all routers along the path need to be able to verify the digital signature. That may require a global public key infrastructure and also client-side certificates. Furthermore, the bandwidth and computational requirements to compute, transmit, and verify digital signatures for each signaling message might place a burden on a real-world deployment. 😮💨
Authorization is not considered in the document, which might have an influence on the implications of signaling message modification. Hence, the chain-of-trust relationship (or this step in a different direction) should be considered in relationship with authorization. 🔗
In [48], the idea above of detecting malicious RSVP nodes is improved by addressing performance aspects. The proposed solution is somewhere between hop-by-hop security and the approach in [47], insofar as it separates the end-to-end path into individual networks. Furthermore, some additional RSVP messages (e.g., feedback messages) are introduced to implement a mechanism called "delayed integrity checking." In [49], the approach presented in [48] is enhanced. 🌈
Authors' Addresses 🎀
Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany
EMail: Hannes.Tschofenig@siemens.com
Richard Graveman RFG Security 15 Park Avenue Morristown, NJ 07960 USA
EMail: rfg@acm.org
Full Copyright Statement 💖
Okay bestie, the legal bit, but make it cute 🎀 Copyright (C) The Internet Society (2005).
This doc is governed by the rights, licenses and restrictions in BCP 78, and except as set out there, the authors keep all their rights 🦋
THIS DOCUMENT AND THE INFORMATION CONTAINED HEREIN ARE PROVIDED ON AN "AS IS" BASIS AND THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. 💀
Translation: the info is handed over "as is," and nobody involved (the contributor, their org or sponsor, the Internet Society, or the IETF) promises it won't step on anyone's rights or that it's sellable or fit for any specific use 🙈
Intellectual Property 🔥
Here's the IPR part, and it's giving neutral 😌 The IETF doesn't take a side on whether any Intellectual Property Rights or other rights might cover the tech in this doc, or whether any license for them exists or is available. It also hasn't made any independent effort to hunt those rights down. If you want the rules on rights for RFC docs, check out BCP 78 and BCP 79 📚
Copies of IPR disclosures sent to the IETF Secretariat are available, along with any licensing assurances, or the outcome of anyone trying to get a general license or permission to use those proprietary rights. Implementers and users can find all of that in the IETF online IPR repository at http://www.ietf.org/ipr 🍓
And the IETF is literally asking everyone to speak up ✨ If you know about any copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard, tell the IETF. Send it to ietf-ipr@ietf.org 🫶
Acknowledgement 🌸
Shoutout to the people keeping the lights on: funding for the RFC Editor function is currently provided by the Internet Society 💜 Iconic support, no cap 👑
📦 where this page comes from
- ietf: rfc4230 2005-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms