RSVP Cryptographic Authentication with HMAC-SHA2

Introduction This document specifies the use of the US NIST Secure Hash Standard in the Hashed Message Authentication Code (HMAC) mode with RSVP Cryptographic Authentication version 2. Those secure hash algorithms are defined in the US NIST Secure Hash Standard (SHS). specifies multiple cryptographic hash functions, including SHA-256, SHA-384, and SHA-512. The Hashed Message Authentication Code (HMAC) authentication mode is defined in and . While it is believed that is mathematically identical to and it is also believed that algorithms in are mathematically identical to , in the event of any confusion or discrepancies the NIST specifications are correct and are canonical. This addition to RSVP Cryptographic Authentication was driven by operator requests that they be able to use algorithms from the NIST Secure Hash Standard in the NIST HMAC mode for RSVP Cryptographic Authentication, instead of being forced to use the much older Keyed-MD5 algorithm and mode as originally defined for RSVP Cryptographic Authentication. As of the date of publication, the Keyed MD5 construction is widely believed not to have sufficient cryptographic strength.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. These words may also appear in this document in lower case as plain English words, absent their normative meanings.

Background All RSVP protocol exchanges can be authenticated using the revised mechanism defined in draft-ietf-teas-rsvp-auth-v2-00. That specification is carefully written to be independent both of the cryptographic algorithm and the cryptographic mode. This approach means that additional cryptographic modes and cryptographic algorithms can be defined in the future without needing to change the RSVP Authentication specification of draft-ietf-teas-rsvp-auth-v2-00. This document specifies the use of NIST SHS algorithms with the HMAC mode for use with draft-ietf-teas-rsvp-auth-v2-00. In the future, other documents might be specified for other cryptographic algorithms with this or another cryptographic mode. The combination of a cryptographic mode (e.g., HMAC) with a specific cryptographic algorithm (e.g., SHA256) is known as a "Cryptographic Transform" (e.g., HMAC-SHA256).

Cryptographic Authentication with NIST SHS in HMAC Mode When using this authentication method, a shared secret Cryptographic Key, the cryptographic mode and algorithm (e.g., HMAC-SHA256), and its associated Key Identifier are configured in the router. For each RSVP protocol packet, that secret key is used to generate/verify a "message digest" that is placed in the Authentication Data field of the RSVP INTEGRITY object. The message digest is a one-way function of the RSVP protocol packet and the secret key. Since the secret key is never sent over the network in the clear, protection is provided against passive attacks . This specification discusses the computation of the Authentication Data field of the RSVP INTEGRITY object when one of the NIST SHS family of algorithms is used in the Hashed Message Authentication Code (HMAC) mode. With the additions in this document, the currently valid Cryptographic Transforms for use with RSVP Cryptographic Authentication include: Of the above, all implementations of this specification MUST support at least both: and SHOULD (for backwards compatibility with existing implementations and deployments of RSVP Cryptographic Authentication) include support for: and MAY include support for: An implementation of this specification MUST allow network operators to configure ANY RSVP Cryptographic Transform supported by that implementation for use with ANY given RSVP Security Association (and with its corresponding Key Identifier value) that is configured into that router.

Generating Cryptographic Authentication First, following the procedure defined in draft-ietf-teas-rsvp-auth-v2-00, select the appropriate RSVP Security Association for use with this packet and set the Key Identifier field to the Key Identifier value of that RSVP Security Association. Second, add an RSVP INTEGRITY object to the outgoing RSVP packet if one does not yet exist, taking care to size the Authentication Data field appropriately for the Cryptographic Algorithm specified in that RSVP Security Association. Using the appropriate RSVP Security Association, set the Flags field, set the AAL field to the appropriate value for the Cryptographic Algorithm that will be used, set the Key Identifier, and set the Sequence Number. The Authentication Data field is filled with the fixed value of "Apad", which is defined in the next section. When any NIST SHS algorithm is used in HMAC mode with RSVP Cryptographic Authentication, the Authentication Data Length is equal to the normal hash output length (measured in bytes) for the specific NIST SHS algorithm in use.

Cryptographic Transform	AAL Field value
HMAC-SHA256	4
HMAC-SHA384	8
HMAC-SHA512	12

Third, the Sequence Number of the RSVP INTEGRITY object is set following the procedures in draft-ietf-teas-rsvp-auth-v2-00. Fourth, the authentication data is calculated, as described below.

Cryptographic Aspects This describes the computation of the Authentication Data value when the HMAC cryptographic mode is combined with any NIST SHS algorithm is used with RSVP Cryptographic Authentication. The value of Apad selected is arbitrary. The only goal was to pick a different value of Apad than is in use with other IETF routing or control protocols. In the algorithm description below, the following nomenclature, which is consistent with , is used: (1) PREPARATION OF KEY In this application, Ko is always L octets long. (2) FIRST-HASH First, the RSVP INTEGRITY object's Authentication Data field is filled with the value Apad. (3) SECOND-HASH Then a Second-Hash, also known as the outer hash, is computed as follows: (4) RESULT The resulting Second-Hash becomes the Authentication Data that is sent in the Authentication Data field of the RSVP Integrity Object.

Message Verification Message verification follows the procedure defined in draft-ietf-teas-rsvp-auth-v2-00 except that the cryptographic calculation of the message digest follows the procedure in Cryptographic Considerations above when any NIST SHS algorithm in the HMAC mode is in use. The KeyID of the received RSVP packet is used to help locate the correct RSVP Security Association to use. Implementation Note: One must save the received digest value before calculating the expected digest value, so that after that calculation the received value can be compared with the expected value to determine whether to accept that RSVP packet.

Smooth Key Rollover The Key Identifier field of the RSVP INTEGRITY object enables smooth key rollover in operational deployments. Based on the lifetime of the current RSVP Security Association, both sender and receiver will know when to switch to a different RSVP Security Association and will do so at the same time. Both draft-ietf-teas-rsvp-auth-v2-00 and this document require that all implementations MUST support more than one RSVP Security Association at any given time, because this also is needed to enable smooth key rollover. Implementations SHOULD support more than two concurrent RSVP Security Associations as that can greatly simplify operational security management. After changing the active RSVP Security Association, the RSVP sender will use the (different) Key Identifier value associated with the newly active RSVP Security Association. The receiver will use this new Key Identifier to select the appropriate (new) RSVP Security Association to use with the received RSVP packet whose INTEGRITY object contains the new Key Identifier value. Because the Key Identifier field is present, the receiver does not need to (and implementations of this specification MUST NOT) try all configured RSVP Security Associations with any received RSVP packet. This requirement mitigates some of the risks of a Denial-of-Service (DoS) attack on the RSVP instance, but does not entirely prevent all conceivable DoS attacks. For example, an on-link adversary still could generate RSVP packets that are syntactically valid but that contain invalid Authentication Data, thereby forcing the receiver(s) to perform expensive cryptographic computations to discover that the packets are invalid.

Security Considerations This document enhances the security of the RSVP signaling protocol by specifying support for the algorithms defined in the NIST Secure Hash Standard (SHS) using the Hashed Message Authentication Code (HMAC) mode. The value Apad is used here primarily for consistency with IETF specifications for HMAC-SHA authentication of RIPv2 SHA and IS-IS SHA . The value of Apad chosen is arbitrary, other than being different from the value used with RIPv2, OSPFv2, or IS-IS authentication. The quality of the security provided by the Cryptographic Authentication option depends completely on the strength of the cryptographic algorithm and cryptographic mode in use, the strength of the key being used, and the correct implementation of the authentication mechanism in all communicating RSVP implementations. Accordingly, the use of high assurance development methods is recommended. Security of a deployment of RSVP Authentication also requires that all parties maintain the secrecy of the shared secret key. and provide guidance on methods for generating cryptographically random bits. Because the RSVP protocol contains information that need not be kept confidential, privacy is not a requirement. This mechanism significantly increases the work an adversary would need to undertake to inject false information into the RSVP protocol deployment, while remaining practical to deploy. This mechanism is vulnerable to a replay attack by any on-link node. An on-link node could record a legitimate RSVP packet sent on the link, then replay that packet at the next time the recorded RSVP packet's sequence number is valid. This is easily prevented simply by rekeying the RSVP session prior to the sequence number repeating. This also can be prevented by using link-encryption. Operators also should note that an upper-layer authentication mechanism, such as this specification, cannot prevent an attack on the lower layers. Operators should consider deployment of link-layer encryption, such as , to protect not only the link-layer but also upper-layers.

IANA Considerations IANA is requested to add the following entries to the RSVP Cryptographic Transforms registry created in draft-ietf-teas-rsvp-auth-v2-00:

Acknowledgements The authors would like to thank TBD for review of this document. TBD (in alphabetical order by last name) provided feedback on earlier versions of this document. That feedback has greatly improved both the technical content and the readability of the current document.