RFC 7860

HMAC-SHA-2 Authentication Protocols in User-Based Security Model (USM) for SNMPv3

📅 published April 2016, from ietf

RFC 7860: HMAC-SHA-2 Authentication Protocols in User-Based Security Model (USM) for SNMPv3 🦋

Okay bestie, here's the title block tea ☕. Request for Comments: 7860. Authors: J. Merkle, Ed. (Secunet Security Networks) and M. Lochter (BSI). Category: Standards Track. ISSN: 2070-1721. Date: April 2016. Obsoletes: RFC 7630. It doesn't list anything it updates 💅.

Abstract ✨

This doc spells out several authentication protocols based on the SHA-2 hash functions for the User-based Security Model (USM) for SNMPv3 defined in RFC 3414. It obsoletes RFC 7630, where the MIB MODULE-IDENTITY value was incorrectly specified 🙈.

Status of This Memo 📜

This is an Internet Standards Track document 🔥.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

Info about the current status of this document, any errata, and how to give feedback is at http://www.rfc-editor.org/info/rfc7860.

Copyright (c) 2016 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 (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents 🗺️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  The Internet-Standard Management Framework  . . . . . . . . .   3
3.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . .   3
4.  The HMAC-SHA-2 Authentication Protocols . . . . . . . . . . .   4
  4.1.  Deviations from the HMAC-SHA-96 Authentication Protocol .   4
  4.2.  Processing  . . . . . . . . . . . . . . . . . . . . . . .   5
    4.2.1.  Processing an Outgoing Message  . . . . . . . . . . .   6
    4.2.2.  Processing an Incoming Message  . . . . . . . . . . .   6
5.  Key Localization and Key Change . . . . . . . . . . . . . . .   7
6.  Structure of the MIB Module . . . . . . . . . . . . . . . . .   7
7.  Relationship to Other MIB Modules . . . . . . . . . . . . . .   7
  7.1.  Relationship to SNMP-USER-BASED-SM-MIB  . . . . . . . . .   7
  7.2.  Relationship to SNMP-FRAMEWORK-MIB  . . . . . . . . . . .   7
  7.3.  MIB Modules Required for IMPORTS  . . . . . . . . . . . .   8
8.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .   8
9.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
  9.1.  Use of the HMAC-SHA-2 Authentication Protocols in USM . .  10
  9.2.  Cryptographic Strength of the Authentication Protocols  .  10
  9.3.  Derivation of Keys from Passwords . . . . . . . . . . . .  11
  9.4.  Access to the SNMP-USM-HMAC-SHA2-MIB  . . . . . . . . . .  11
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
  11.1.  Normative References . . . . . . . . . . . . . . . . . .  12
  11.2.  Informative References . . . . . . . . . . . . . . . . .  13
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1. Introduction 💖

So the big picture is this: the Architecture for describing Simple Network Management Protocol (SNMP) Management Frameworks [RFC3411] is where the User-based Security Model (USM) [RFC3414] for SNMPv3 lives, as a Security Subsystem inside an SNMP engine 🧚. RFC 3414 gave us two auth protocols, HMAC-MD5-96 and HMAC-SHA-96, built on the hash functions MD5 and SHA-1 respectively 🌸.

This memo brings in new HMAC-SHA-2 authentication protocols for USM. They use a Hashed Message Authentication Code (HMAC) based on the SHA-2 family of hash functions [SHA], truncated to 128 bits for SHA-224, 192 bits for SHA-256, 256 bits for SHA-384, and 384 bits for SHA-512. They're basically straightforward adaptations of HMAC-MD5-96 and HMAC-SHA-96 onto the SHA-2-based HMAC, so it's giving familiar 🦋.

This document obsoletes RFC 7630, in which the MIB MODULE-IDENTITY value was incorrectly specified 🙈.

2. The Internet-Standard Management Framework 🌈

For a detailed overview of the documents that describe the current Internet-Standard Management Framework, check section 7 of RFC 3410 [RFC3410] 📚.

Managed objects are accessed via a virtual information store called the Management Information Base, or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, [RFC2578], STD 58, [RFC2579] and STD 58, [RFC2580] 💅.

3. Conventions 🎀

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 BCP 14, RFC 2119 [RFC2119] 🫶.

4. The HMAC-SHA-2 Authentication Protocols 🔥

This section describes the HMAC-SHA-2 authentication protocols. They use the SHA-2 hash functions (described in FIPS PUB 180-4 [SHA] and RFC 6234 [RFC6234]) in the HMAC mode (described in [RFC2104] and [RFC6234]), truncating the output to 128 bits for SHA-224, 192 bits for SHA-256, 256 bits for SHA-384, and 384 bits for SHA-512. RFC 6234 also provides source code for all the SHA-2 algorithms and HMAC (without truncation). It also includes a test harness and standard test vectors for all the defined hash functions and HMAC examples 👑.

These are the protocols that get defined:

  • usmHMAC128SHA224AuthProtocol: uses SHA-224 and truncates the output to 128 bits (16 octets);
  • usmHMAC192SHA256AuthProtocol: uses SHA-256 and truncates the output to 192 bits (24 octets);
  • usmHMAC256SHA384AuthProtocol: uses SHA-384 and truncates the output to 256 bits (32 octets);
  • usmHMAC384SHA512AuthProtocol: uses SHA-512 and truncates the output to 384 bits (48 octets).

Implementations conforming to this specification MUST support usmHMAC192SHA256AuthProtocol and SHOULD support usmHMAC384SHA512AuthProtocol. The protocols usmHMAC128SHA224AuthProtocol and usmHMAC256SHA384AuthProtocol are OPTIONAL 🌸.

4.1. Deviations from the HMAC-SHA-96 Authentication Protocol 🍓

All the HMAC-SHA-2 authentication protocols are straightforward adaptations of the HMAC-MD5-96 and HMAC-SHA-96 authentication protocols. Specifically, they differ from HMAC-MD5-96 and HMAC-SHA-96 in the following aspects 💜:

  • The SHA-2 hash function is used to compute the message digest in the HMAC computation according to RFC 2104 and RFC 6234, as opposed to the MD5 hash function [RFC1321] and the SHA-1 hash function [SHA] used in HMAC-MD5-96 and HMAC-SHA-96, respectively. Consequently, the length of the message digest prior to truncation is 224 bits for the SHA-224-based protocol, 256 bits for the SHA-256-based protocol, 384 bits for the SHA-384-based protocol, and 512 bits for the SHA-512-based protocol.
  • The resulting message digest (output of HMAC) is truncated to:
    • 16 octets for usmHMAC128SHA224AuthProtocol
    • 24 octets for usmHMAC192SHA256AuthProtocol
    • 32 octets for usmHMAC256SHA384AuthProtocol
    • 48 octets for usmHMAC384SHA512AuthProtocol

as opposed to the truncation to 12 octets in HMAC-MD5-96 and HMAC-SHA-96.

  • The user's secret key to be used when calculating a digest MUST be:
    • 28 octets long and derived with SHA-224 for the SHA-224-based protocol usmHMAC128SHA224AuthProtocol
    • 32 octets long and derived with SHA-256 for the SHA-256-based protocol usmHMAC192SHA256AuthProtocol
    • 48 octets long and derived with SHA-384 for the SHA-384-based protocol usmHMAC256SHA384AuthProtocol
    • 64 octets long and derived with SHA-512 for the SHA-512-based protocol usmHMAC384SHA512AuthProtocol

as opposed to the keys being 16 and 20 octets long in HMAC-MD5-96 and HMAC-SHA-96, respectively.

4.2. Processing ⚙️

This section describes the procedures for the HMAC-SHA-2 authentication protocols. The descriptions are based on the definition of services and data elements specified for HMAC-SHA-96 in RFC 3414, with the deviations listed in Section 4.1 ✨.

The constants M (the length of the secret key in octets) and N (the length of the Message Authentication Code (MAC) output in octets), plus the hash function H used below, are:

usmHMAC128SHA224AuthProtocol: M=28, N=16, H=SHA-224;

usmHMAC192SHA256AuthProtocol: M=32, N=24, H=SHA-256;

usmHMAC256SHA384AuthProtocol: M=48, N=32, H=SHA-384;

usmHMAC384SHA512AuthProtocol: M=64, N=48, H=SHA-512.

4.2.1. Processing an Outgoing Message 📤

This section covers the steps an SNMP engine follows whenever it must authenticate an outgoing message using one of the authentication protocols defined above. The values of the constants M and N, and the hash function H, are as defined in Section 4.2, and they're picked based on which authentication protocol is configured for the given USM usmUser Table entry 💖.

  1. The msgAuthenticationParameters field is set to the serialization of an OCTET STRING containing N zero octets. It's serialized according to the rules in [RFC3417].
  2. Using the secret authKey of M octets, the HMAC is calculated over the wholeMsg according to RFC 6234 with hash function H.
  3. The first N octets of the above HMAC are taken as the computed MAC value.
  4. The msgAuthenticationParameters field is replaced with the MAC obtained in the previous step.
  5. The authenticatedWholeMsg is then returned to the caller, together with the statusInformation indicating success 🎉.

4.2.2. Processing an Incoming Message ✨

okay so this section is the receiving side's checklist 💅 whenever an SNMP engine has to authenticate an incoming message with one of the HMAC-SHA-2 protocols. The constants M and N and the hash function H are the ones from Section 4.2, and which values you get depends on the authentication protocol configured for that USM usmUser Table entry 🫶

  1. If the digest in the msgAuthenticationParameters field is not N octets long, then a failure happens and an errorIndication (authenticationError) gets returned to the calling module 😭
  2. The MAC sitting in the msgAuthenticationParameters field is saved 💾
  3. The digest in msgAuthenticationParameters gets swapped out for N zero octets 🙈
  4. Using the secret authKey (M octets long), the HMAC is calculated over the wholeMsg according to RFC 6234 with hash function H 🔥
  5. The first N octets of that HMAC become the computed MAC value ✨
  6. The msgAuthenticationParameters field gets the saved MAC from step 2 put back in 🎀
  7. The newly calculated MAC gets compared with the one saved in step 2. If they don't match, a failure and an errorIndication (authenticationFailure) are returned to the calling module 💀
  8. The authenticatedWholeMsg and a statusInformation indicating success go back to the caller 👑

5. Key Localization and Key Change 🔑

bestie, for every protocol in Section 4, key localization and key change SHALL be done according to [RFC3414], using the same SHA-2 hash function as the HMAC-SHA-2 authentication protocol 💖

6. Structure of the MIB Module 🧚

the MIB module in this memo doesn't define any managed objects, subtrees, notifications, or tables 🙅‍♀️ it only defines object identities (for the authentication protocols) under a subtree of an existing MIB. very minimal, very clean, very on brand 💅

7. Relationship to Other MIB Modules 🌸

7.1. Relationship to SNMP-USER-BASED-SM-MIB 🦋

ok so [RFC3414] is the one that specifies the USM MIB for SNMPv3 (SNMP-USER-BASED-SM-MIB). It defines authentication protocols for USM based on MD5 and SHA-1, respectively. This new MIB module adds HMAC-SHA2 authentication protocols for USM, based on the SHA-2 hash functions [SHA] 🔥 and using the HMAC-SHA2 protocols still requires the objects from SNMP-USER-BASED-SM-MIB. no skipping that one, bestie 🙏

7.2. Relationship to SNMP-FRAMEWORK-MIB 💜

[RFC3411] specifies the SNMP-FRAMEWORK-MIB, which defines a subtree called snmpAuthProtocols for SNMP authentication protocols. The MIB module here defines new authentication protocols inside that snmpAuthProtocols subtree 🌈

7.3. MIB Modules Required for IMPORTS 📦

this MIB module IMPORTS definitions from SNMPv2-SMI [RFC2578] and SNMP-FRAMEWORK-MIB [RFC3411] ✨

8. Definitions 📜

 SNMP-USM-HMAC-SHA2-MIB DEFINITIONS ::= BEGIN
    IMPORTS
       MODULE-IDENTITY, OBJECT-IDENTITY,
           mib-2 FROM SNMPv2-SMI -- RFC 2578
           snmpAuthProtocols FROM SNMP-FRAMEWORK-MIB; -- RFC 3411

snmpUsmHmacSha2MIB MODULE-IDENTITY
    LAST-UPDATED    "201604180000Z" -- 18 April 2016, midnight
    ORGANIZATION    "SNMPv3 Working Group"
    CONTACT-INFO    "WG email: OPSAWG@ietf.org
                    Subscribe:
                        https://www.ietf.org/mailman/listinfo/opsawg
                    Editor:    Johannes Merkle
                               secunet Security Networks
                    Postal:    Mergenthaler Allee 77
                               D-65760 Eschborn
                               Germany
                    Phone:     +49 20154543091
                    Email:     johannes.merkle@secunet.com

                    Co-Editor: Manfred Lochter
                               Bundesamt fuer Sicherheit in der
                               Informationstechnik (BSI)
                    Postal:    Postfach 200363
                               D-53133 Bonn
                               Germany
                    Phone:     +49 228 9582 5643
                    Email:     manfred.lochter@bsi.bund.de"

    DESCRIPTION
        "Definitions of Object Identities needed for the use of
        HMAC-SHA2 Authentication Protocols by SNMP's User-based Security
        Model.

        Copyright (c) 2016 IETF Trust and the persons identified as
        authors of the code.  All rights reserved.

        Redistribution and use in source and binary forms, with or
        without modification, is permitted pursuant to, and subject
        to the license terms contained in, the Simplified BSD License
        set forth in Section 4.c of the IETF Trust's Legal Provisions
        Relating to IETF Documents
        (http://trustee.ietf.org/license-info)."

    REVISION "201604180000Z" -- 18 April 2016, midnight
    DESCRIPTION
        "Version correcting the MODULE-IDENTITY value,
        published as RFC 7860"

    REVISION "201510140000Z" -- 14 October 2015, midnight
    DESCRIPTION
        "Initial version, published as RFC 7630"

    ::= { mib-2 235 }


usmHMAC128SHA224AuthProtocol OBJECT-IDENTITY
    STATUS      current
    DESCRIPTION "The Authentication Protocol
                usmHMAC128SHA224AuthProtocol uses HMAC-SHA-224 and
                truncates output to 128 bits."
    REFERENCE   "- Krawczyk, H., Bellare, M., and R. Canetti,
                HMAC: Keyed-Hashing for Message Authentication,
                RFC 2104.
                - National Institute of Standards and Technology,
                Secure Hash Standard (SHS), FIPS PUB 180-4, 2012."
    ::= { snmpAuthProtocols 4 }

usmHMAC192SHA256AuthProtocol OBJECT-IDENTITY
    STATUS      current
    DESCRIPTION "The Authentication Protocol
                usmHMAC192SHA256AuthProtocol uses HMAC-SHA-256 and
                truncates output to 192 bits."
    REFERENCE   "- Krawczyk, H., Bellare, M., and R. Canetti,
                HMAC: Keyed-Hashing for Message Authentication,
                RFC 2104.
                - National Institute of Standards and Technology,
                Secure Hash Standard (SHS), FIPS PUB 180-4, 2012."
    ::= { snmpAuthProtocols 5 }

usmHMAC256SHA384AuthProtocol OBJECT-IDENTITY
    STATUS      current
    DESCRIPTION "The Authentication Protocol
                usmHMAC256SHA384AuthProtocol uses HMAC-SHA-384 and
                truncates output to 256 bits."
    REFERENCE   "- Krawczyk, H., Bellare, M., and R. Canetti,
                HMAC: Keyed-Hashing for Message Authentication,
                RFC 2104.
                - National Institute of Standards and Technology,
                Secure Hash Standard (SHS), FIPS PUB 180-4, 2012."
    ::= { snmpAuthProtocols 6 }

usmHMAC384SHA512AuthProtocol OBJECT-IDENTITY
    STATUS      current
    DESCRIPTION "The Authentication Protocol
                usmHMAC384SHA512AuthProtocol uses HMAC-SHA-512 and
                truncates output to 384 bits."
    REFERENCE   "- Krawczyk, H., Bellare, M., and R. Canetti,
                HMAC: Keyed-Hashing for Message Authentication,
                RFC 2104.
                - National Institute of Standards and Technology,
                Secure Hash Standard (SHS), FIPS PUB 180-4, 2012."
    ::= { snmpAuthProtocols 7 }

END

9. Security Considerations 🚨

this part is serious, bestie, so read it carefully 🫣

9.1. Use of the HMAC-SHA-2 Authentication Protocols in USM 🔐

the security considerations of [RFC3414] also apply to the HMAC-SHA-2 authentication protocols defined in this document. no escaping those ones 💀

9.2. Cryptographic Strength of the Authentication Protocols 💪

when this document was published, all of the HMAC-SHA-2 authentication protocols gave a very high level of security 👑 each protocol's security depends on the parameters in its HMAC computation: the key length (assuming the key has maximum entropy), the size of the hash function's internal state, and the length of the truncated MAC. Here are the values for the HMAC-SHA-2 protocols (in bits) 📊

+------------------------------+---------+----------------+---------+
|           Protocol           |   Key   |    Size of     |   MAC   |
|                              |  length | internal state |  length |
+------------------------------+---------+----------------+---------+
| usmHMAC128SHA224AuthProtocol |   224   |      256       |   128   |
| usmHMAC192SHA256AuthProtocol |   256   |      256       |   192   |
| usmHMAC256SHA384AuthProtocol |   384   |      512       |   256   |
| usmHMAC384SHA512AuthProtocol |   512   |      512       |   384   |
+------------------------------+---------+----------------+---------+

Table 1: HMAC Parameters of the HMAC-SHA-2 Authentication Protocols

the HMAC's security goes up with both the key length and the internal state size. Longer keys make key guessing attacks harder, and a bigger internal state lowers the success chance of MAC forgeries that rely on internal collisions of the hash function 🧠

the truncated output length is trickier 🙃 According to [BCK], there's a trade-off:

by outputting less bits the attacker has less bits to predict in a MAC forgery but, on the other hand, the attacker also learns less about the output of the compression function from seeing the authentication tags computed by legitimate parties.

so truncation makes the HMAC weaker against forgery by guessing, but at the same time it makes it stronger against chosen message attacks aimed at MAC forgery through internal collisions or at key guessing 🦋 RFC 2104 and [BCK] both allow truncation to any length that isn't less than half the size of the internal state.

more on the HMAC construction's security is in RFC 2104 📚

9.3. Derivation of Keys from Passwords 🗝️

if the secret keys for HMAC-SHA-2 authentication protocols are derived from passwords, the derivation SHOULD be done with the password-to-key algorithm from Appendix A.1 of RFC 3414, with MD5 swapped out for the SHA-2 hash function H used in the HMAC-SHA-2 authentication protocol. Specifically, the password gets turned into the required secret key in these steps:

  • forming a string of length 1,048,576 octets by repeating the value of the password as often as necessary, truncating accordingly, and using the resulting string as the input to the hash function H. The resulting digest, termed "digest1", is used in the next step.
  • forming a second string by concatenating digest1, the SNMP engine's snmpEngineID value, and digest1. This string is used as input to the hash function H.

9.4. Access to the SNMP-USM-HMAC-SHA2-MIB 👀

the SNMP-USM-HMAC-SHA2-MIB module defines OBJECT IDENTIFIER values for use in other MIB modules. It doesn't define any objects that can be accessed. So the SNMP-USM-HMAC-SHA2-MIB, by itself, has no effect on the security of the Internet 🌍

the values defined in this module are expected to be used with the usmUserTable defined in the SNMP-USER-BASED-SM-MIB [RFC3414]. The considerations in Section 11.5 of RFC 3414 should be taken into account 🫶

10. IANA Considerations ✨

okay so IANA handed this MIB its very own OID, and it's giving official 💅. The descriptor is snmpUsmHmacSha2MIB, and its spot in the tree is { mib-2 235 }. Look at the table, it's so clean 🎀

+--------------------+-------------------------+
|     Descriptor     | OBJECT IDENTIFIER value |
+--------------------+-------------------------+
| snmpUsmHmacSha2MIB |      { mib-2 235 }      |
+--------------------+-------------------------+

                   Table 2: OID of MIB

And that's not all 🦋 IANA also put values in the SnmpAuthProtocols registry for each of the four protocols, and every single one points back to RFC 7860, bestie. The HMAC-SHA-2 protocols are literally registered here as code points 4 through 7:

+------------------------------+-------+-----------+
|         Description          | Value | Reference |
+------------------------------+-------+-----------+
| usmHMAC128SHA224AuthProtocol |   4   |  RFC 7860 |
| usmHMAC192SHA256AuthProtocol |   5   |  RFC 7860 |
| usmHMAC256SHA384AuthProtocol |   6   |  RFC 7860 |
| usmHMAC384SHA512AuthProtocol |   7   |  RFC 7860 |
+------------------------------+-------+-----------+

Table 3: Code Points Assigned to HMAC-SHA-2 Authentication Protocols

Registered, numbered, and locked in 🔒✨

11. References

11.1. Normative References

These are the ones you absolutely need to have read, no skipping 🫶

11.2. Informative References

These ones are background reading, super helpful but not required 🌸

Authors' Addresses

the people behind this spec, lowkey iconic 🧚

Johannes Merkle (editor)
Secunet Security Networks
Mergenthaler Allee 77
65760 Eschborn
Germany

Phone: +49 201 5454 3091
Email: johannes.merkle@secunet.com


Manfred Lochter
BSI
Postfach 200363
53133 Bonn
Germany

Phone: +49 228 9582 5643
Email: manfred.lochter@bsi.bund.de
📦 where this page comes from