TEAS Working Group R. Atkinson Internet-Draft Consultant Obsoletes: 2747 3097 (if approved) J. Halpern Intended status: Standards Track Ericsson Expires: 5 November 2025 4 May 2025 RSVP Cryptographic Authentication with HMAC-SHA2 draft-atkinson-teas-rsvp-hmac-sha2-00 Abstract 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. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 5 November 2025. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Atkinson & Halpern Expires 5 November 2025 [Page 1] Internet-Draft RSVP HMAC-SHA2 May 2025 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Cryptographic Authentication with NIST SHS in HMAC Mode . . . 3 3.1. Generating Cryptographic Authentication . . . . . . . . . 4 3.2. Cryptographic Aspects . . . . . . . . . . . . . . . . . . 5 3.3. Message Verification . . . . . . . . . . . . . . . . . . 7 3.4. Smooth Key Rollover . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. 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. [I-D.atkinson-teas-rsvp-auth-v2] Those secure hash algorithms are defined in the US NIST Secure Hash Standard (SHS).[NIST-SHS] [NIST-HMAC] specifies multiple cryptographic hash functions, including SHA-256, SHA-384, and SHA- 512. The Hashed Message Authentication Code (HMAC) authentication mode is defined in [NIST-HMAC] and [RFC2104]. While it is believed that [RFC2104] is mathematically identical to [NIST-HMAC] and it is also believed that algorithms in [RFC4634] are mathematically identical to [NIST-SHS], in the event of any confusion or discrepancies the NIST specifications 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.[RFC2747][RFC3097] As of the date of publication, the Keyed MD5 construction is widely believed not to have sufficient cryptographic strength.[RFC6151] Atkinson & Halpern Expires 5 November 2025 [Page 2] Internet-Draft RSVP HMAC-SHA2 May 2025 1.1. 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 [RFC2119] [RFC8174] 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. 2. Background All RSVP protocol exchanges can be authenticated using the revised mechanism defined in [I-D.atkinson-teas-rsvp-auth-v2]. 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 [I-D.atkinson-teas-rsvp-auth-v2]. This document specifies the use of NIST SHS algorithms with the HMAC mode for use with [I-D.atkinson-teas-rsvp-auth-v2]. 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). 3. 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 [RFC1704]. 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. Atkinson & Halpern Expires 5 November 2025 [Page 3] Internet-Draft RSVP HMAC-SHA2 May 2025 With the additions in this document, the currently valid Cryptographic Transforms for use with RSVP Cryptographic Authentication include: TRANSFORM NAME SPECIFICATION(S) Keyed-MD5 {{RFC2747}} and {{RFC3097}} HMAC-SHA-256 (defined here) HMAC-SHA-384 (defined here) HMAC-SHA-512 (defined here) Of the above, all implementations of this specification MUST support at least both: HMAC-SHA-256 HMAC-SHA-512 and SHOULD (for backwards compatibility with existing implementations and deployments of RSVP Cryptographic Authentication) include support for: Keyed-MD5 and MAY include support for: HMAC-SHA-384 NOTE WELL: This document deliberately does not specify a Cryptographic Transform using either SHA-1 or SHA-224 because those algorithms are considered to be too weak as of this document's publication date. 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. 3.1. Generating Cryptographic Authentication First, following the procedure defined in [I-D.atkinson-teas-rsvp-auth-v2], 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. Atkinson & Halpern Expires 5 November 2025 [Page 4] Internet-Draft RSVP HMAC-SHA2 May 2025 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 | +-------------------------+-----------------+ Table 1 Third, the Sequence Number of the RSVP INTEGRITY object is set following the procedures in [I-D.atkinson-teas-rsvp-auth-v2]. Fourth, the authentication data is calculated, as described below. 3.2. 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 [NIST-HMAC], is used: Atkinson & Halpern Expires 5 November 2025 [Page 5] Internet-Draft RSVP HMAC-SHA2 May 2025 H is the specific hashing algorithm (e.g., SHA-256). K is the Authentication Key for the RSVP Security Association. Ko is the cryptographic key used with the hash algorithm. B is the block size of H, measured in octets rather than bits. Note well that B is the internal block size, not the hash size. For SHA-256: B == 64 For SHA-384 and SHA-512: B == 128 L is the length of the hash, measured in octets rather than bits. XOR is the exclusive-or operation. Opad is the hexadecimal value 0x5c repeated B times. Ipad is the hexadecimal value 0x36 repeated B times. Apad is the hexadecimal value 0x7865FE3E repeated (L/4) times. Implementation Notes: This definition of Apad means that Apad is always the same length as the hash output. The Authentication Data field length for SHA256 is 32 bytes, for SHA384 is 48 bytes, and for SHA512 is 64 bytes. As a side effect, RSVP packets containing the RSVP INTEGRITY object will be larger when hash functions with larger hash output sizes are used. (1) PREPARATION OF KEY In this application, Ko is always L octets long. If the Authentication Key (K) is L octets long, then Ko is equal to K. If the Authentication Key (K) is more than L octets long, then Ko is set to H(K). If the Authentication Key (K) is less than L octets long, then Ko is set to the Authentication Key (K) with zeros appended to the end of the Authentication Key (K), such that Ko is L octets long. (2) FIRST-HASH First, the RSVP INTEGRITY object's Authentication Data field is filled with the value Apad. Atkinson & Halpern Expires 5 November 2025 [Page 6] Internet-Draft RSVP HMAC-SHA2 May 2025 Then, a First-Hash, also known as the inner hash, is computed as follows: First-Hash = H(Ko XOR Ipad || (RSVP Packet)) The definition of Apad (above) ensures it is always the same length as the hash output. (3) SECOND-HASH Then a Second-Hash, also known as the outer hash, is computed as follows: Second-Hash = H(Ko XOR Opad || First-Hash) (4) RESULT The resulting Second-Hash becomes the Authentication Data that is sent in the Authentication Data field of the RSVP Integrity Object. 3.3. Message Verification Message verification follows the procedure defined in [I-D.atkinson-teas-rsvp-auth-v2] 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. 3.4. 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 [I-D.atkinson-teas-rsvp-auth-v2] 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 supporting more than two concurrent RSVP Security Associations as that can greatly simplify operational security management. Atkinson & Halpern Expires 5 November 2025 [Page 7] Internet-Draft RSVP HMAC-SHA2 May 2025 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. 4. 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 [RFC4822] and IS-IS SHA [RFC5310]. 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. [RFC4086] and [NIST-ENTROPY] 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. Atkinson & Halpern Expires 5 November 2025 [Page 8] Internet-Draft RSVP HMAC-SHA2 May 2025 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 [IEEE-802.1AE-2018], to protect not only the link-layer but also upper-layers. 5. IANA Considerations IANA is requested to add the following entries to the RSVP Cryptographic Transforms registry created in [I-D.atkinson-teas-rsvp-auth-v2]: TRANSFORM SPECIFICATION IMPLEMENTATION STATUS HMAC-256 (this document) MUST implement HMAC-384 (this document) MAY implement HMAC-512 (this document) MUST implement 6. 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. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Atkinson & Halpern Expires 5 November 2025 [Page 9] Internet-Draft RSVP HMAC-SHA2 May 2025 [I-D.atkinson-teas-rsvp-auth-v2] Atkinson, R. and T. Li, "RSVP Cryptographic Authentication, Version 2", Work in Progress, Internet- Draft, draft-atkinson-teas-rsvp-auth-v2-01, 1 December 2024, . [RFC4634] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and HMAC-SHA)", RFC 4634, DOI 10.17487/RFC4634, July 2006, . 7.2. Informative References [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, . [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, DOI 10.17487/RFC2747, January 2000, . [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic Authentication -- Updated Message Type Value", RFC 3097, DOI 10.17487/RFC3097, April 2001, . [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, . [RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic Authentication", RFC 4822, DOI 10.17487/RFC4822, February 2007, . [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, DOI 10.17487/RFC6151, March 2011, . [IEEE-802.1AE-2018] Institute of Electrical and Electronics Engineers (IEEE), "IEEE Standard for Local and Metropolitan Area Networks - Media Access Control (MAC) Security", December 2018, . IEEE Standard 802.1AE Atkinson & Halpern Expires 5 November 2025 [Page 10] Internet-Draft RSVP HMAC-SHA2 May 2025 [NIST-SHS] (US) National Institute of Standards and Technology (NIST), "Secure Hash Standard (SHS)", August 2015, . Federal Information Processing Standard 180-4 [NIST-HMAC] (US) National Institute of Standards and Technology (NIST), "The Keyed-Hash Message Authentication Code (HMAC)", July 2008, . Federal Information Processing Standard 198-1 [NIST-ENTROPY] Turan, M., "Recommendation for the Entropy Sources Used for Random Bit Generation", January 2018, . Special Publication 800-90B [RFC1704] Haller, N. and R. Atkinson, "On Internet Authentication", RFC 1704, DOI 10.17487/RFC1704, October 1994, . [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, DOI 10.17487/RFC5310, February 2009, . Authors' Addresses Ran Atkinson Consultant Email: rja.lists@gmail.com Joel Halpern Ericsson Email: jmh@joelhalpern.org Atkinson & Halpern Expires 5 November 2025 [Page 11]