RFC 2747

RSVP Cryptographic Authentication

📅 published January 2000, from ietf

RSVP Cryptographic Authentication 🦋

Okay bestie, this is RFC 2747 💖 It's called RSVP Cryptographic Authentication, and it's a Standards Track doc from the Network Working Group. The authors are F. Baker (Cisco), B. Lindell (USC/ISI), and M. Talwar (Microsoft), and it's dated January 2000. The title block doesn't list anything it obsoletes or updates, so it stands on its own ✨

Status of This Memo 📜

This document specifies an Internet standards track protocol for the Internet community, and asks for discussion and suggestions for improvements. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited.

Copyright (C) The Internet Society (2000). All Rights Reserved.

Abstract 🌸

This doc explains the format and use of RSVP's INTEGRITY object, which gives hop-by-hop integrity and authentication for RSVP messages 🔐

1. Introduction ✨

Okay so RSVP (the Resource ReSerVation Protocol) [1] is how routers and hosts set up distributed state, mostly to reserve resources for integrated services 🎀 It lets particular users get preferential access to network resources, and an admission control mechanism decides who gets in. A reservation is only allowed if the resources are actually available along the data path and the policy rules are satisfied. Main character admission control energy 👑

Because that admission control is only as good as its protection, RSVP needs to keep its messages safe from corruption and spoofing 🛡️ This doc defines a way to protect RSVP message integrity hop-by-hop. The sender includes an authenticating digest of the message, computed with a secret Authentication Key and a keyed-hash algorithm. That gives protection against forgery or message modification. Each RSVP message's INTEGRITY object also gets a one-time-use sequence number, so the receiver can spot playbacks and shut down replay attacks 🚫 The mechanism doesn't give confidentiality, since messages stay in the clear 🙈 It's still exportable from most countries, which wouldn't be possible if a privacy algorithm were used. Also, heads up: this doc uses the words "sender" and "receiver" differently from [1]. Here they mean the two systems facing each other across an RSVP hop, with the "sender" being the one generating RSVP messages.

The replay prevention algorithm is honestly simple 💅 The sender generates packets with monotonically increasing sequence numbers, and the receiver only accepts a packet if its sequence number is larger than the previous one's. To get things started, a receiver does a handshake with the sender to get an initial sequence number. This memo also talks about ways to loosen the strictness of in-order delivery, plus techniques for generating monotonically increasing sequence numbers that survive sender failures and restarts 🍓

The mechanism doesn't depend on one specific cryptographic algorithm, but this doc describes using Keyed-Hashing for Message Authentication with HMAC-MD5 [7]. [7] notes that stronger hashes like HMAC-SHA1 exist, and implementations are smart to offer them where it makes sense 🧠 But in general, [7] says HMAC-MD5 is good enough for the job and has nicer performance characteristics. [7] also includes source code and test vectors for the algorithm, which is a huge gift for anyone testing interoperability 🥹 HMAC-MD5 is required as a baseline that every RSVP implementation providing cryptographic authentication universally includes, with other proposals optional (see Section 6 on Conformance Requirements).

The RSVP checksum MAY be disabled (set to zero) when the INTEGRITY object is included in the message, because the message digest is a much stronger integrity check 💜

1.1. Conventions used in this document 📝

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [8].

1.2. Why not use the Standard IPSEC Authentication Header? 🤔

Okay, the obvious question is: IPSEC [3,5] already has a standard authentication mechanism, so why not just use that? The working group talked about this at length, and they rejected IPSEC for the following reasons 💭

IPSEC security associations are based on destination address. It's not clear that RSVP messages are well defined for either source-based or destination-based security associations, because a router has to forward PATH and PATH TEAR messages using the same source address as the sender listed in the SENDER TEMPLATE. RSVP traffic also may not follow exactly the same path as data traffic. Using either source-based or destination-based associations would mean opening a new security association among all the routers that a reservation goes through 😩

There's another wrinkle too: neighbor relationships between RSVP systems aren't limited to systems that face one another across a communication channel. RSVP relationships across non-RSVP clouds, like the ones described in Section 2.9 of [1], might not be visible to the sending system at all 👀 All of this points toward a key management strategy based on RSVP router-to-router associations instead of IPSEC 🦋

2. Data Structures 🧩

2.1. INTEGRITY Object Format 💎

An RSVP message is a sequence of "objects," which are type-length-value encoded fields that each have a specific purpose. The info needed for hop-by-hop integrity checking lives in an INTEGRITY object. The same INTEGRITY object type is used for both IPv4 and IPv6, so you don't need separate versions 🙌

The INTEGRITY object has the following format:

      Keyed Message Digest INTEGRITY Object: Class = 4, C-Type = 1

       +-------------+-------------+-------------+-------------+
       |    Flags    | 0 (Reserved)|                           |
       +-------------+-------------+                           +
       |                    Key Identifier                     |
       +-------------+-------------+-------------+-------------+
       |                    Sequence Number                    |
       |                                                       |
       +-------------+-------------+-------------+-------------+
       |                                                       |
       +                                                       +
       |                                                       |
       +                  Keyed Message Digest                 |
       |                                                       |
       +                                                       +
       |                                                       |
       +-------------+-------------+-------------+-------------+
  • Flags: An 8-bit field with the following format:
                                      Flags

                          0   1   2   3   4   5   6   7
                        +---+---+---+---+---+---+---+---+
                        | H |                           |
                        | F |             0             |
                        +---+---+---+---+---+---+---+---+

Only one flag (HF) is defined so far. The remaining flags are reserved for future use and MUST be set to 0 🌈

  • Bit 0: Handshake Flag (HF) concerns the integrity handshake mechanism (Section 4.3). Message senders that are willing to respond to integrity handshake messages SHOULD set this flag to 1, whereas those that will reject integrity handshake messages SHOULD set this to 0 ✨
  • Key Identifier: An unsigned 48-bit number that MUST be unique for a given sender 🔑 Locally unique Key Identifiers can be generated using some combination of the address (IP or MAC or LIH) of the sending interface and the key number. The combination of the Key Identifier and the sending system's IP address uniquely identifies the security association (Section 2.2).
  • Sequence Number: An unsigned 64-bit, monotonically increasing, unique sequence number 🔢

The sequence number values can be any monotonically increasing sequence, as long as the INTEGRITY object [of each RSVP message] gets a tag that's unique for the associated key's lifetime. Details on sequence number generation are in Section 3.

  • Keyed Message Digest: The digest MUST be a multiple of 4 octets long. For HMAC-MD5, it will be 16 bytes long 🫶

2.2. Security Association 🔐

The sending and receiving systems keep a security association for each authentication key they share. This security association includes the following parameters:

  • Authentication algorithm and algorithm mode being used.
  • Key used with the authentication algorithm.
  • Lifetime of the key.
  • Associated sending interface and other security association selection criteria [REQUIRED at Sending System].
  • Source Address of the sending system [REQUIRED at Receiving System].
  • Latest sending sequence number used with this key identifier [REQUIRED at Sending System].
  • List of last N sequence numbers received with this key identifier [REQUIRED at Receiving System].

3. Generating Sequence Numbers 🔢✨

In this section we go over methods that could be used to generate the sequence numbers that go in the INTEGRITY object of an RSVP message. As mentioned earlier, there are two important properties that MUST be satisfied by the generation procedure 🎯 The first is that the sequence numbers are unique, or one-time, for the lifetime of the integrity key currently in use. A receiver can use this property to tell a new message apart from a replayed one, no guessing 💅 The second is that the sequence numbers are generated in monotonically increasing order, modulo 2^64. That's required to greatly reduce the amount of saved state, since a receiver only has to remember the highest sequence number it has seen to avoid a replay attack 🧠 The starting sequence number could be arbitrarily large, so the modulo operation is needed to handle sequence number roll-over within a key's lifetime. This approach draws from TCP's approach [9] 🦋

The sequence number field is a 64-bit unsigned quantity. That's big enough to avoid running out over the key lifetime 🌌 For example, if a key lifetime were conservatively defined as one year, there would be enough sequence number values to send RSVP messages at an average rate of about 585 gigaMessages per second. A 32-bit sequence number would limit that average rate to about 136 messages per second. Iconic math, no cap 📈

Generating unique, monotonically increasing sequence numbers across a failure and restart implies some form of stable storage, either local to the device or remote over the network 💾 Three sequence number generation procedures are described below 🧚

3.1. Simple Sequence Numbers 🎀

okay so the most straightforward way to get a unique sequence number is literally a message counter 🔢. Every time a message goes out for a given key, the counter ticks up by one ✨. The current value gets saved to stable storage, either continuously or on a schedule 💾, and after a restart you recover the counter from there. Now here's the lowkey tricky bit: if you were only saving it periodically, you have to bump the recovered value up so it's bigger than any value the counter could have reached before the failure 😭. You work that out by knowing how often you saved it and adding that interval onto the stored number. Iconic math, periodt 💅.

3.2. Sequence Numbers Based on a Real Time Clock ⏰

Most devices probably can't save a sequence number counter to stable storage for every single key 🙈, so the more universal move is to base sequence numbers on the stable storage of a real time clock 💖. Lots of computing devices have a real time clock module that keeps its own stable storage of the clock, usually some kind of nonvolatile memory that holds onto the clock info even when the power goes out 🔋.

In this approach, we could use an NTP based timestamp value as the sequence number 🕰️. An NTP timestamp rolls over about every 136 years, which is way longer than any reasonable key lifetime 🌸. And the granularity is so fine that it's enough room to generate an RSVP message every 200 picoseconds for a given key 🤯. Real talk though, lots of real time clock modules don't have NTP-level resolution 🥲. When that happens, the least significant bits can come from a message counter that gets reset every clock tick 🔁. For example, if the real time clock only gives you 1 second resolution, the 32 least significant bits of the sequence number come from a message counter, and the remaining 32 bits are filled with the 32 least significant bits of the timestamp 🧚. As long as recovering after a failure takes longer than one tick of the clock, the low order counter can safely reset to zero after a restart 💅.

3.3. Sequence Numbers Based on a Network Recovered Clock 🌐

If the device doesn't have any stable storage for sequence number counters or a real time clock 😵, it can recover the real time clock from the network using NTP 🛰️. Once the clock is back after a restart, the sequence number generation works exactly the same way as described above ✨.

4. Message Processing 🔥

Implementations SHOULD let you pick which interfaces get secured, for sending messages, receiving them, or both 🔐. The sender must ensure that all RSVP messages sent on secured sending interfaces include an INTEGRITY object, generated using the appropriate Key 🗝️. Receivers check whether RSVP messages arriving on a secured receiving interface contain the INTEGRITY object, except for messages of the type "Integrity Challenge" (Section 4.3) 👀. If the INTEGRITY object is missing, the receiver throws the message away 🗑️.

Security associations are simplex 🦋. The keys a sending system uses to sign its messages can be different from the keys its receivers use to sign theirs. So each association is tied to one unique sending system and (possibly) multiple receiving systems 💜.

Each sender SHOULD have distinct security associations (and keys) per secured sending interface (or LIH) 🌈. Admins can configure all the routers and hosts on a subnet (or, for that matter, their whole network) with a single security association 🙃, but implementations MUST assume that each sender may send using a distinct security association on each secured interface 👑. On the sending side, the security association is picked based on the interface the message goes out through. That selection MAY include extra criteria, like the destination address (when sending unicast over a broadcast LAN with a large number of hosts) or user identities at the sender or receivers [2] 🎯. Finally, all intended message recipients should participate in this security association 🫶. Route flaps in a non RSVP cloud might cause messages for the same receiver to go out on different interfaces at different times 😬. In that case, the receivers should participate in all the possible security associations that might get selected for the interfaces the message could leave through 🧠.

Receivers select keys based on the Key Identifier and the sending system's IP address 🔑. The Key Identifier is included in the INTEGRITY object. The sending system's address comes from the RSVP_HOP object or, if that's not there (like with PathErr and ResvConf messages), from the IP source address 📍. Since the Key Identifier is unique for a sender, this combo uniquely identifies the key 💅.

The integrity mechanism slightly changes the processing rules for RSVP messages 🛠️. That happens both when an INTEGRITY object is included in a message sent over a secured sending interface and when a message is accepted on a secured receiving interface. The details are below ⬇️.

4.1. Message Generation 📨

For an RSVP message sent over a secured sending interface, the message is created as described in [1], with these exceptions:

  1. The RSVP checksum field is set to zero. If required, an RSVP checksum can be calculated once the processing of the INTEGRITY object is complete 🧮.
  2. The INTEGRITY object is inserted in the appropriate place, and its location in the message is remembered for later use 📌.
  3. The sending interface and the other appropriate criteria (as mentioned above) are used to determine the Authentication Key and the hash algorithm to be used 🔍.
  4. The unused flags and the reserved field in the INTEGRITY object MUST be set to 0 🧹. The Handshake Flag (HF) should be set according to the rules in Section 2.1 🤝.
  5. The sending sequence number MUST be updated so it's a unique, monotonically increasing number. It is then placed in the Sequence Number field of the INTEGRITY object 🔢✨.
  6. The Keyed Message Digest field is set to zero 0️⃣.
  7. The Key Identifier is placed into the INTEGRITY object 🪪.
  8. An authenticating digest of the message is computed using the Authentication Key together with the keyed-hash algorithm 🔏. When the HMAC-MD5 algorithm is used, the hash calculation is described in [7] 🧪.
  9. The digest is written into the Cryptographic Digest field of the INTEGRITY object 💌.

4.2. Message Reception 📬

When the message is received on a secured receiving interface, and it isn't of the type "Integrity Challenge", it gets processed like this:

  1. The RSVP checksum field is saved, and then the field is set to zero 💾.
  2. The Cryptographic Digest field of the INTEGRITY object is saved, and then the field is set to zero 💾.
  3. The Key Identifier field and the sending system address are used to uniquely determine the Authentication Key and the hash algorithm to be used. Processing of this packet might get delayed while the Key Management System (Appendix 1) is queried for this information 🐢.
  4. A new keyed-digest is calculated using the indicated algorithm and the Authentication Key 🧮.
  5. If the calculated digest doesn't match the received digest, the message is discarded without any further processing 🚫.
  6. If the message is of type "Integrity Response", verify that the CHALLENGE object identically matches the originated challenge. If it matches, save the sequence number in the INTEGRITY object as the largest sequence number received to date 🏆.

Otherwise, for all other RSVP messages, the sequence number is validated to prevent replay attacks, and messages with invalid sequence numbers are ignored by the receiver 🙅‍♀️.

When a message is accepted, its sequence number could update a stored value for the largest sequence number received to date. Each subsequent message must then have a larger (modulo 2^64) sequence number to be accepted 📈. This simple processing rule prevents message replay attacks, but it must be modified to tolerate limited out-of-order message delivery 🔀. For example, if several messages were sent in a burst (in a periodic refresh generated by a router, or as a result of a tear down function), they might get reordered, and then the sequence numbers wouldn't arrive in increasing order 😵‍💫.

An implementation SHOULD allow administrative configuration that sets the receiver's tolerance to out-of-order message delivery ⚙️. A simple approach would let admins specify a message window that matches the worst case reordering behavior. For example, one might specify that packets reordered within a 32 message window would be accepted 🪟. If no reordering can happen, the window is set to one 1️⃣.

The receiver must store a list of all sequence numbers seen within the reordering window 📋. A received sequence number is valid if (a) it is greater than the maximum sequence number received, or (b) it is a past sequence number lying within the reordering window and not recorded in the list ✅. Accepting a sequence number means adding it to the list and removing a number from the lower end of the list 🧾. Messages received with sequence numbers below the lower end of the list, or marked as seen in the list, are discarded 🗑️.

When an "Integrity Challenge" message is received on a secured sending interface, it gets processed like this:

  1. An "Integrity Response" message is formed using the Challenge object received in the challenge message 💬.
  2. The message is sent back to the receiver, based on the source IP address of the challenge message, using the "Message Generation" steps outlined above 📤. The Authentication Key and the hash algorithm to be used are determined by the key identifier supplied in the challenge message 🔑✨.

4.3. Integrity Handshake at Restart or Initialization of the Receiver

okay so, to grab the starting sequence number for a live Authentication Key, the receiver MAY start an integrity handshake with the sender 🫶 The handshake is a receiver's Challenge followed by the sender's Response, and it can happen during restart or get postponed until a message signed with that key shows up ✨

Once the receiver decides to handshake for a particular Authentication Key, it finds the sender using the sending system's address from the matching security association 🦋 Then it sends an RSVP Integrity Challenge message. This message carries the Key Identifier so the sender knows which key is in play, and it MUST have a unique challenge cookie based on a local secret so nobody can guess it 🔐 (see Section 2.5.3 of [4]). It's suggested that the cookie be an MD5 hash of a local secret and a timestamp, which gives it uniqueness (see Section 9) 💜

An RSVP Integrity Challenge message will carry a message type of 11. The format looks like this:

<Integrity Challenge message> ::= <Common Header> <CHALLENGE>

The CHALLENGE object is laid out like this 🧚

            CHALLENGE Object: Class = 64, C-Type = 1

   +-------------+-------------+-------------+-------------+
   |        0 (Reserved)       |                           |
   +-------------+-------------+                           +
   |                    Key Identifier                     |
   +-------------+-------------+-------------+-------------+
   |                    Challenge Cookie                   |
   |                                                       |
   +-------------+-------------+-------------+-------------+

The sender accepts the "Integrity Challenge" without running an integrity check 🌸 It sends back an RSVP "Integrity Response" message that contains the original CHALLENGE object, plus an INTEGRITY object signed with the key named by the Key Identifier in the "Integrity Challenge" 🔥

An RSVP Integrity Response message will carry a message type of 12. The format is:

<Integrity Response message> ::= <Common Header> <INTEGRITY>
                                 <CHALLENGE>

The receiver (the challenger) only accepts the "Integrity Response" if the CHALLENGE object that comes back matches the one it sent in the "Integrity Challenge" message 🙈 This is what stops old "Integrity Response" messages from being replayed. If it matches, the receiver saves the Sequence Number from the INTEGRITY object as the latest sequence number received with the key identifier from the CHALLENGE 👑

If no response shows up within a set period of time, the challenge gets repeated 💅 Once the integrity handshake successfully completes, the receiver starts accepting normal RSVP signaling messages from that sender and ignores any other "Integrity Response" messages. Iconic behavior, honestly ✨

The Handshake Flag (HF) gives implementations the freedom to skip the integrity handshake mechanism entirely 🦋 Setting this flag to 1 lets message senders that implement the handshake stand out from the ones that don't. Receivers SHOULD NOT attempt to handshake with senders whose INTEGRITY object has HF = 0 🚫

An integrity handshake isn't necessary in every environment, bestie. Keep the context in mind 🌈

A common use of RSVP integrity is between peering domain routers, which are usually processing a steady stream of RSVP messages because of aggregation effects 🌊 When a router restarts after a crash, valid RSVP messages from peering senders will probably show up pretty quickly. Assuming replay messages are injected into that stream of valid messages, there may only be a small window for a replay attack before a valid message gets processed. That valid message sets the largest sequence number seen to something bigger than any number stored before the crash, which stops any further replays 💖

Not using an integrity handshake, on the other hand, could leave things open to replay attacks if a sender goes quiet for a long time after a receiver restarts 😭 So it SHOULD be an administrative decision whether the receiver performs an integrity handshake with senders that are willing to respond to "Integrity Challenge" messages, and whether it accepts messages from senders that refuse to do so. These decisions depend on assumptions about the particular network environment 🎀

5. Key Management

It's likely the IETF will define a standard key management protocol 👑 It's strongly desirable to use that protocol to distribute RSVP Authentication Keys between communicating RSVP implementations, since it would provide scalability and seriously cut down on human admin work 💅 The Key Identifier can act as a hook between RSVP and that future protocol 🧚 Key management protocols have a long, messy history of subtle flaws that often get found long after they're first published 💀 So, to avoid having to change every RSVP implementation if such a flaw turns up, integrated key management techniques were deliberately left out of this specification 🫶

5.1. Key Management Procedures

Every key has a lifetime recorded in all the systems (senders and receivers) configured with it 🦋 The idea of a "key lifetime" only requires that the earliest (KeyStartValid) and latest (KeyEndValid) times a key is valid be programmable in a way the system understands ✨ Some key generation mechanisms, like Kerberos or certain public key schemes, can directly produce ephemeral keys. In that case, the key's lifetime is implicitly defined as part of the key itself 🌸

In general, no key is ever used outside its lifetime (but see Section 5.3) 🔐 Possible ways to manage key lifetime include the Network Time Protocol and hardware time-of-day clocks ⏰

To keep things secure, it's advisable to change the RSVP Authentication Key on a regular basis 💜 It should be possible to switch the key without losing RSVP state or interrupting reservation service, and without making people change every key all at once 🙈 This requires an RSVP implementation to store and use more than one active RSVP Authentication Key at the same time. So both senders and receivers might have multiple active keys for a given security association 🌈

Since keys are shared between a sender and (possibly) multiple receivers, there's a region of uncertainty around the switch-over time. During that window, some systems may still be using the old key while others have already moved to the new one 😭 The size of this uncertainty region depends on how synchronized the clocks of the systems are. Administrators should configure the overlap between the old key's expiration time (KeyEndValid) and the new key's validity start (KeyStartValid) to be at least twice the size of this uncertainty interval 🧚 That lets the sender do the switch-over at the midpoint of the interval and be confident that all receivers are now accepting the new key 👑 For the whole overlap in key lifetimes, a receiver must be prepared to authenticate messages using either key 🫶

During a key switch-over, each receiver will need to handshake with the sender using the new key 🔥 As mentioned before, a receiver can choose to start a handshake during the switch-over, or postpone it until it receives a message using that key ✨

5.2. Key Management Requirements

Requirements on an implementation are as follows:

  • It is strongly desirable that a hypothetical security breach in one Internet protocol does not automatically compromise other Internet protocols. The Authentication Key of this specification SHOULD NOT be stored using protocols or algorithms that have known flaws 🔐
  • An implementation MUST support the storage and use of more than one key at the same time, for both sending and receiving systems 💖
  • An implementation MUST associate a specific lifetime (i.e., KeyStartValid and KeyEndValid) with each key and the corresponding Key Identifier 🦋
  • An implementation MUST support manual key distribution (e.g., the privileged user manually typing in the key, key lifetime, and key identifier on the console). The lifetime may be infinite 🎀
  • If more than one algorithm is supported, then the implementation MUST require that the algorithm be specified for each key at the time the other key information is entered 🌸
  • Keys that are out of date MAY be automatically deleted by the implementation 🧹
  • Manual deletion of active keys MUST also be supported 💅
  • Key storage SHOULD persist across a system restart, warm or cold, to make operations easier 🌈

5.3. Pathological Case

It's possible that the last key for a given security association has expired 💀 When that happens, it's unacceptable to fall back to an unauthenticated condition, and it's not advisable to disrupt current reservations either 😭 So the system should send a "last authentication key expiration" notification to the network manager, and treat the key as having an infinite lifetime until the lifetime is extended, the key is deleted by network management, or a new key is configured 🫶

6. Conformance Requirements

To conform to this specification, an implementation MUST support all of its aspects 👑 The HMAC-MD5 authentication algorithm defined in [7] MUST be implemented by all conforming implementations. A conforming implementation MAY also support other authentication algorithms, such as NIST's Secure Hash Algorithm (SHA) 🌈 Manual key distribution, as described above, MUST be supported by all conforming implementations. All implementations MUST support the smooth key roll over described under "Key Management Procedures" ✨

Implementations SHOULD support a standard key management protocol for secure distribution of RSVP Authentication Keys once the IETF standardizes one 🦋 Periodt 💅

7. Kerberos generation of RSVP Authentication Keys ✨

okay bestie, so Kerberos[10] MAY be used to generate the RSVP Authentication key that gets used for the signature in the Integrity Object sent from an RSVP sender to a receiver 🔐. the big slay here is that Kerberos means you don't need shared keys between RSVP senders and receivers (like hosts and routers) 🙅‍♀️. Kerberos lets the security principals (the RSVP sender and receivers) use trusted third-party keying, where the Kerberos key distribution center (KDC) makes an ephemeral session key that then gets shared between the sender and the receivers 🧚. in the multicast case, all receivers of a multicast RSVP message MUST share a single key with the KDC (e.g. the receivers are in effect the same security principal with respect to Kerberos) 👑.

The Key information the sender determines MAY say to use Kerberos instead of configured shared keys for setting up a key between the sender and receiver 💅. the receiver's Kerberos identity gets set as part of the sender's interface configuration, or it can be figured out through other mechanisms 🌸. when the sender makes the first RSVP message for a specific key identifier, it asks the KDC for a Kerberos service ticket and gets back an ephemeral session key and a Kerberos ticket 🎀. the sender then wraps the ticket and its own identity up in an Identity Policy Object[2] and includes that Policy Object in the RSVP message 🫶. the sender uses the session key as the RSVP Authentication key in section 4.1 step (3), and it stores that key as Key information tied to the key identifier 🔥.

when an RSVP message comes in, the receiver pulls the Kerberos Ticket out of the Identity Policy Object, decrypts the ticket, and grabs the session key from it 🦋. that session key is the same key the sender has, and the receiver uses it as the key in section 4.2 step (3) ✨. then the receiver stores the key so it can handle the RSVP messages that come after 💜.

Kerberos tickets have lifetimes, so the sender MUST NOT use tickets that have expired 💀. a new ticket MUST be requested and used by the sender for the receiver before the old one expires 🙈.

7.1. Optimization when using Kerberos Based Authentication

Kerberos tickets are pretty chunky (> 500 bytes), so it's not necessary to send one in every RSVP message 🍓. the sender and receiver can cache the ephemeral session key and use it for as long as the Kerberos ticket lives 🌈. in this setup, the sender only needs to include the Kerberos ticket in the first Message it generates. after that, RSVP messages use the key identifier to look up the cached key (and optionally other identity information), instead of sending a ticket from sender to receiver in every single message 🧚‍♀️.

a receiver might not have cached key state for an associated Key Identifier because it rebooted or because routes changed 😭. if the receiver's policy says to use Kerberos keys for integrity checking, the receiver can send an integrity Challenge message back to the sender 🔍. when a sender gets an integrity Challenge message, it MUST send an Identity object that includes the Kerberos ticket in the integrity Response message 🫶. that lets the receiver pull the session key out of the Kerberos ticket and store it for later integrity checking ✨.

8. Acknowledgments

this document is derived directly from similar work done for OSPF and RIP Version II, jointly by Ran Atkinson and Fred Baker 🙌. Bob Braden did significant editing, which made it way clearer 💖. Steve Bellovin left significant comments, and he actually understands this stuff 🤓. Matt Crawford and Dan Harkins helped revise the document 💜.

9. References

[1] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.

[2] Yadav, S., et al., "Identity Representation for RSVP", RFC 2752, January 2000.

[3] Atkinson, R. and S. Kent, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.

[4] Maughan, D., Schertler, M., Schneider, M. and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.

[5] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.

[6] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.

[7] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, March 1996.

[8] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[9] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.

[10] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.

10. Security Considerations

okay this part is SERIOUS, so listen up 🚨. this entire memo describes and specifies an authentication mechanism for RSVP that is believed to be secure against active and passive attacks 🛡️.

the quality of the security this mechanism gives you depends on how strong the authentication algorithms are, how strong the key is, and whether every communicating RSVP implementation is set up correctly 😤. it also depends on every party keeping the RSVP Authentication Keys confidential 🤫. if any of these assumptions are wrong, or the procedures aren't secure enough, then the users of this mechanism get no real security at all 💀.

the handshake "Integrity Response" message is integrity-checked, but the handshake "Integrity Challenge" message is not 🙈. this was on purpose, to avoid the situation where both peering routers don't have a starting sequence number for each other's key. when that happens, they'd keep sending handshake "Integrity Challenge" messages that the other end just drops 🙃. requiring only the response to be integrity-checked also gets rid of a dependency on a security association in the opposite direction 🧠.

BUT this lets an intruder generate fake handshaking challenges with a certain challenge cookie 😱. they could save the response and try to play it back against a receiver that's in recovery. if they were lucky enough to guess the challenge cookie the receiver used at recovery time, they could use the saved response. this response would be accepted, since it's properly signed, and it would have a smaller sequence number for the sender because it was an old message. that opens the receiver up to replays 🚩. still, it seems very difficult to exploit 🤔. it requires not only guessing the challenge cookie (which is based on a locally known secret) in advance, but also being able to masquerade as the receiver to generate a handshake "Integrity Challenge" with the proper IP address and not getting caught 🕵️.

confidentiality is NOT provided by this mechanism 🙅‍♀️. if you need confidentiality, IPSEC ESP [6] may be the best approach, although it has the same criticisms as IPSEC Authentication, so it'd only be applicable in specific environments 🌍. protection against traffic analysis is also not provided by this mechanism. mechanisms like bulk link encryption might be used when protection against traffic analysis is required 🔐.

11. Authors' Addresses

Fred Baker Cisco Systems 519 Lado Drive Santa Barbara, CA 93111

Phone: (408) 526-4257 EMail: fred@cisco.com

Bob Lindell USC Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292

Phone: (310) 822-1511 EMail: lindell@ISI.EDU

Mohit Talwar Microsoft Corporation One Microsoft Way Redmond, WA 98052

Phone: +1 425 705 3131 EMail: mohitt@microsoft.com

12. Appendix 1: Key Management Interface

this appendix describes a generic interface to Key Management 🎀. it's written at an abstract level, since implementations may need small variations to the actual interface 🧩.

at the start of execution, RSVP uses this interface to get the current set of relevant keys for sending and receiving messages 🚀. while things are running, RSVP can query for specific keys given a Key Identifier and Source Address, discover newly created keys, and be told about keys that have been deleted 👀. the interface offers both a polling and an asynchronous upcall style, so it works for more situations 💅.

12.1. Data Structures

information about keys is returned using the following KeyInfo data structure 📦:

  KeyInfo {
          Key Type (Send or Receive)
          KeyIdentifier
          Key
          Authentication Algorithm Type and Mode
          KeyStartValid
          KeyEndValid
          Status (Active or Deleted)
          Outgoing Interface (for Send only)
          Other Outgoing Security Association Selection Criteria
                  (for Send only, optional)
          Sending System Address (for Receive Only)
  }

12.2. Default Key Table

this function returns a list of KeyInfo data structures for all the keys that are configured for sending and receiving RSVP messages and have an Active Status 🔑. it's usually called at the start of execution, but there's no limit on how many times it can be called 🔁.

  KM_DefaultKeyTable() -> KeyInfoList

12.3. Querying for Unknown Receive Keys

when a message arrives with an unknown Key Identifier and Sending System Address pair, RSVP can use this function to ask the Key Management System for the right key 🕵️‍♀️. the status of the element returned, if there is one, must be Active ✅.

  KM_GetRecvKey( INTEGRITY Object, SrcAddress ) -> KeyInfo

12.4. Polling for Updates

this function returns a list of KeyInfo data structures for any incremental changes made to the default key table or requested keys since the last call to KM_KeyTablePoll, KM_DefaultKeyTable, or KM_GetRecvKey 📝. the status of some elements in the returned list may be set to Deleted 🗑️.

   KM_KeyTablePoll() -> KeyInfoList

12.5. Asynchronous Upcall Interface

instead of calling KM_KeyTablePoll() over and over, an implementation may choose an asynchronous event model 🔔. this function registers interest in key changes for a given Key Identifier, or for all keys if no Key Identifier is specified. the upcall function gets called every time a change is made to a key 💫.

  KM_KeyUpdate ( Function [, KeyIdentifier ] )

where the upcall function is parameterized as follows:

  Function ( KeyInfo )

Copyright (C) The Internet Society (2000). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 🫶

Funding for the RFC Editor function is currently provided by the Internet Society. 🌸

📦 where this page comes from