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,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.






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, <https://datatracker.ietf.org/doc/html/draft-
              atkinson-teas-rsvp-auth-v2-01>.

   [RFC4634]  Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
              (SHA and HMAC-SHA)", RFC 4634, DOI 10.17487/RFC4634, July
              2006, <https://www.rfc-editor.org/info/rfc4634>.

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,
              <https://www.rfc-editor.org/info/rfc2104>.

   [RFC2747]  Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
              Authentication", RFC 2747, DOI 10.17487/RFC2747, January
              2000, <https://www.rfc-editor.org/info/rfc2747>.

   [RFC3097]  Braden, R. and L. Zhang, "RSVP Cryptographic
              Authentication -- Updated Message Type Value", RFC 3097,
              DOI 10.17487/RFC3097, April 2001,
              <https://www.rfc-editor.org/info/rfc3097>.

   [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
              "Randomness Requirements for Security", BCP 106, RFC 4086,
              DOI 10.17487/RFC4086, June 2005,
              <https://www.rfc-editor.org/info/rfc4086>.

   [RFC4822]  Atkinson, R. and M. Fanto, "RIPv2 Cryptographic
              Authentication", RFC 4822, DOI 10.17487/RFC4822, February
              2007, <https://www.rfc-editor.org/info/rfc4822>.

   [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,
              <https://www.rfc-editor.org/info/rfc6151>.

   [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,
              <https://standards.ieee.org/IEEE/802.1AE/7154/>.  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,
              <https://csrc.nist.gov/pubs/fips/180-4/upd1/final>.
              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,
              <https://csrc.nist.gov/pubs/fips/198-1/final>.  Federal
              Information Processing Standard 198-1

   [NIST-ENTROPY]
              Turan, M., "Recommendation for the Entropy Sources Used
              for Random Bit Generation", January 2018,
              <https://csrc.nist.gov/pubs/sp/800/90/b/final>.  Special
              Publication 800-90B

   [RFC1704]  Haller, N. and R. Atkinson, "On Internet Authentication",
              RFC 1704, DOI 10.17487/RFC1704, October 1994,
              <https://www.rfc-editor.org/info/rfc1704>.

   [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, <https://www.rfc-editor.org/info/rfc5310>.

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]