RSVP Cryptographic Authentication
updated by
- rfc-3097 — RSVP Cryptographic Authentication -- Updated Message Type Value
Extracted elements (25)
Integrated key management protocol techniques were deliberately omitted from the specification to avoid requiring changes to all RSVP implementations if a flaw were discovered in a key management protocol, given the long history of subtle flaws in such protocols.
IPsec Authentication Header was explicitly rejected for RSVP because IPsec security associations are destination-address-based, yet routers must forward PATH and PATH TEAR messages using the sender's source address, and RSVP neighbor relationships across non-RSVP clouds are not necessarily visible to the sending system. A router-to-router association model was chosen instead.
The Integrity Challenge message is intentionally not integrity-checked, because if both peering routers lack a starting sequence number for each other's key, requiring integrity on the challenge would cause them to endlessly drop each other's challenges. Only the Response is integrity-checked, also removing a dependency on a security association in the opposite direction.
The sequence number field is 64 bits rather than 32 bits to avoid exhaustion over a key lifetime. A 32-bit counter would limit average RSVP message rates to ~136 messages/second, whereas 64 bits supports ~585 gigamessages/second for a one-year key lifetime.
The RSVP checksum MAY be disabled (set to zero) when the INTEGRITY object is present, as the message digest provides a much stronger integrity check. Implementations MUST set the checksum field to zero before computing the keyed digest and before recomputing on receipt.
All conforming implementations MUST implement HMAC-MD5 as the baseline authentication algorithm and MUST support smooth key rollover as described in the Key Management Procedures. Manual key distribution MUST be supported. Stronger algorithms such as HMAC-SHA1 are optional.
During message generation, the unused flags and reserved field in the INTEGRITY object MUST be set to 0, the Sequence Number MUST be updated to a unique monotonically increasing value, and the Keyed Message Digest field MUST be set to zero before computing the authenticating digest.
During message reception, if the computed digest does not match the received digest, the message MUST be discarded without further processing. Sequence numbers are then validated to prevent replay attacks; messages with invalid sequence numbers are ignored.
Implementations MUST support storage and use of more than one active key simultaneously (for both sending and receiving), MUST associate KeyStartValid and KeyEndValid lifetimes with each key, and MUST support manual key distribution including infinite-lifetime keys.
Implementations SHOULD allow administrative configuration of the receiver's tolerance to out-of-order message delivery via a reordering window. A received sequence number is valid if it is greater than the maximum seen, or if it lies within the reordering window and has not previously been recorded.
Implementations SHOULD allow configuration of which interfaces are secured for sending, receiving, or both. Messages sent on a secured sending interface MUST include an INTEGRITY object; messages received on a secured receiving interface that lack an INTEGRITY object MUST be discarded.
Key storage SHOULD persist across system restarts. Administrators should configure an overlap between the old key's expiration (KeyEndValid) and the new key's validity (KeyStartValid) of at least twice the clock synchrony uncertainty interval to allow safe key rollover.
Receivers SHOULD NOT attempt to handshake with senders whose INTEGRITY object has HF=0. Whether to perform an integrity handshake, and whether to accept messages from senders that refuse challenges, SHOULD be an administrative decision based on the network environment.
Sequence numbers used in the INTEGRITY object MUST be unique for the lifetime of the integrity key and MUST be generated in monotonically increasing order modulo 2^64. This allows receivers to distinguish new messages from replays while minimizing state (only the highest sequence number seen need be stored).
The Challenge Cookie in an Integrity Challenge message MUST be unique and based on a local secret to prevent guessing. The recommended construction is an MD5 hash of a local secret and a timestamp.
A security association includes: authentication algorithm and mode, key, key lifetime (KeyStartValid/KeyEndValid), sending interface (sender-side), source address of sender (receiver-side), latest sending sequence number (sender-side), and a list of the last N received sequence numbers (receiver-side).
Kerberos MAY be used to generate ephemeral RSVP Authentication Keys via a KDC. The sender encapsulates the Kerberos ticket in an Identity Policy Object included in the RSVP message; the receiver decrypts the ticket to retrieve the session key. Kerberos tickets MUST NOT be used after expiration; a new ticket MUST be requested before the current one expires.
The Flags field in the INTEGRITY object currently defines one flag: Handshake Flag (HF) at bit 0. Senders willing to respond to integrity handshake messages SHOULD set HF=1; those that will reject such messages SHOULD set HF=0. All other flag bits are reserved and MUST be set to 0.
The integrity handshake uses two new RSVP message types: 'Integrity Challenge' (type 11) containing a CHALLENGE object (Class=64, C-Type=1) with a 48-bit Key Identifier and a 64-bit Challenge Cookie, and 'Integrity Response' (type 12) echoing the CHALLENGE object inside an integrity-signed message.
The INTEGRITY object (Class=4, C-Type=1) carries hop-by-hop authentication data in every secured RSVP message. It contains an 8-bit Flags field, a 48-bit Key Identifier, a 64-bit Sequence Number, and a variable-length Keyed Message Digest (multiple of 4 octets; 16 bytes for HMAC-MD5).
The Key Identifier is an unsigned 48-bit number that MUST be unique for a given sender. Combined with the sending system's IP address, it uniquely identifies the security association. Locally unique values can be generated from the sending interface address (IP, MAC, or LIH) and a key number.
An attacker can forge Integrity Challenge messages with a guessed challenge cookie, save a valid Integrity Response, and replay it against a restarting receiver to establish a stale (low) sequence number, opening the receiver to replay attacks. Exploitation requires guessing the cookie (based on a local secret) and impersonating the receiver's IP address, making it difficult in practice.
The mechanism provides no confidentiality; messages are transmitted in the clear. If confidentiality is required, IPsec ESP may be used, but it is subject to the same deployment concerns as IPsec Authentication. Protection against traffic analysis is also not provided.
The CHALLENGE object (Class=64, C-Type=1) wire layout is: 2 bytes reserved (zero), 6 bytes Key Identifier (48-bit), 8 bytes Challenge Cookie (64-bit unique value based on a local secret to prevent guessing).
The INTEGRITY object wire layout is: 1-byte Flags, 1-byte reserved (zero), 6-byte Key Identifier (48-bit unsigned), 8-byte Sequence Number (64-bit unsigned, monotonically increasing), followed by the Keyed Message Digest (16 bytes for HMAC-MD5, must be a multiple of 4 octets).