RFC 7630

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

📅 published October 2015, from ietf

RFC 7630: HMAC-SHA-2 Authentication Protocols in the User-based Security Model (USM) for SNMPv3 💖

okay bestie, let's get into it 🎀 This is an Internet Standards Track doc (the category that means it's a real, official spec) from October 2015, and it's giving IETF energy 🦋

  • Authors: J. Merkle, Ed. (Secunet Security Networks) and M. Lochter (BSI) ✨
  • Category: Standards Track 🔥
  • ISSN: 2070-1721 🌸
  • Date: October 2015 📅
  • Obsoletes / Updates: the header doesn't list either one 🙈

Abstract ✨

this memo spells out new HMAC-SHA-2 authentication protocols for the User-based Security Model (USM) for SNMPv3, which was defined in RFC 3414. main character energy 👑

Status of This Memo 📝

this is an Internet Standards Track document 💅

it's a product of the Internet Engineering Task Force (IETF) and it represents the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). if you want more on Internet Standards, check Section 2 of RFC 5741 🧚

info about the current status of this doc, any errata, and how to give feedback lives at http://www.rfc-editor.org/info/rfc7630 🌈

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. 💜

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the publication date. please actually read these, because they describe your rights and restrictions for this doc 🫶 if you pull Code Components out of it, they have to include the Simplified BSD License text from Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes 🔥

Table of Contents 🗂️

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

1. Introduction 🌸

okay so this memo defines a piece of the Management Information Base (MIB) that network management protocols use. specifically, it adds more authentication protocols for the User-based Security Model (USM) of the Simple Network Management Protocol version 3 (SNMPv3), which is specified in RFC 3414 [RFC3414] 💅

in RFC 3414 there are two authentication protocols, HMAC-MD5-96 and HMAC-SHA-96, built on the MD5 and SHA-1 hash functions. this memo adds new HMAC-SHA-2 protocols for USM. they use a Hashed Message Authentication Code (HMAC) built on the SHA-2 family of hash functions [SHA]. the output gets truncated to 128 bits for SHA-224, 192 bits for SHA-256, 256 bits for SHA-384, and 384 bits for SHA-512 ✨ honestly these are straightforward glow-ups of HMAC-MD5-96 and HMAC-SHA-96, just with the SHA-2-based HMAC swapped in 🦋

2. The Internet-Standard Management Framework 🧚

if you want a detailed tour of the documents that make up the current Internet-Standard Management Framework, check section 7 of RFC 3410 [RFC3410] 🎀

managed objects get accessed through a virtual information store called the Management Information Base, or MIB. MIB objects are usually accessed through the Simple Network Management Protocol (SNMP). objects in the MIB get defined with the mechanisms in the Structure of Management Information (SMI). this memo specifies a MIB module that's compliant with SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [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 is the main event 💖 It describes the HMAC-SHA-2 authentication protocols, which use the SHA-2 hash functions (described in FIPS PUB 180-4 [SHA] and RFC 6234 [RFC6234]) in HMAC mode (described in RFC 2104 [RFC2104] and RFC 6234). the output gets truncated 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 has source code for all the SHA-2 algorithms and HMAC (without truncation), plus a test harness and standard test vectors for every hash function and HMAC example. so many resources 😭

these protocols are 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) 🍓
okay this part is key: implementations conforming to this spec MUST support usmHMAC192SHA256AuthProtocol and SHOULD support usmHMAC384SHA512AuthProtocol. 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 HMAC-MD5-96 and HMAC-SHA-96. specifically, they differ from those two in the following ways:

  • the SHA-2 hash function computes the message digest inside the HMAC, following RFC 2104 and RFC 6234. the older ones used the MD5 hash function [RFC1321] and the SHA-1 hash function [SHA], respectively for HMAC-MD5-96 and HMAC-SHA-96. so the digest length before truncation is 224 bits for SHA-224, 256 bits for SHA-256, 384 bits for SHA-384, and 512 bits for SHA-512 🌈
  • the resulting message digest (the HMAC output) gets truncated to:
    • 16 octets for usmHMAC128SHA224AuthProtocol 🌸
    • 24 octets for usmHMAC192SHA256AuthProtocol 💖
    • 32 octets for usmHMAC256SHA384AuthProtocol ✨
    • 48 octets for usmHMAC384SHA512AuthProtocol 👑

compare that to the 12-octet truncation in HMAC-MD5-96 and HMAC-SHA-96 🙈

  • the user's secret key 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 🔑

the older keys were 16 and 20 octets long, for HMAC-MD5-96 and HMAC-SHA-96 respectively 🫣

4.2. Processing ⚙️

this section covers the procedures for the HMAC-SHA-2 authentication protocols. the descriptions are based on the services and data elements defined for HMAC-SHA-96 in RFC 3414, with the deviations from Section 4.1 layered on top 💅

the constants M (the length of the secret key in octets) and N (the length of the Message Authentication Code (MAC) output in octets), along with 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 explains the steps an SNMP engine follows whenever it has to authenticate an outgoing message using one of the authentication protocols above. the values of the constants M and N, and the hash function H, are the ones defined in Section 4.2. which ones apply depends on the authentication protocol 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 gets serialized according to the rules in RFC 3417 [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 that HMAC are taken as the computed MAC value 🎀
  4. the msgAuthenticationParameters field is replaced with the MAC from the previous step 💖
  5. the authenticatedWholeMsg is returned to the caller, together with statusInformation indicating success 🥳

4.2.2. Processing an Incoming Message 📥

okay so this section is the step-by-step for when 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 come from Section 4.2, and which values you get depends on the protocol configured for the USM usmUser Table entry.

  1. If the digest in the msgAuthenticationParameters field is not N octets long, then a failure and an errorIndication (authenticationError) get returned to the calling module 🙅‍♀️.
  2. The MAC in the msgAuthenticationParameters field gets saved for later 💾.
  3. The digest in the msgAuthenticationParameters field is replaced with 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 are taken as the computed MAC value.
  6. The msgAuthenticationParameters field is replaced with the MAC value you saved in step 2.
  7. The new MAC gets compared with the MAC from step 2. If they don't match, then a failure and an errorIndication (authenticationFailure) get returned to the calling module 💀.
  8. If everything checks out, the authenticatedWholeMsg and a statusInformation indicating success get returned to the caller 🎉.

5. Key Localization and Key Change 🔑

for any of the protocols defined in Section 4, key localization and key change SHALL be performed according to RFC 3414 [RFC3414], using the same SHA-2 hash function as the HMAC-SHA-2 authentication protocol. this part is non-negotiable, bestie 🙅‍♀️💅.

6. Structure of the MIB Module 🧩

the MIB module in this memo doesn't define any managed objects, subtrees, notifications, or tables 🙃. what it does do is define object identities (for the authentication protocols) under a subtree of an existing MIB. it's giving "just the labels, no furniture" 🏷️.

7. Relationship to Other MIB Modules 🌸

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

so RFC 3414 is the one that specifies the USM MIB module 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 the HMAC-SHA2 protocols need the objects from SNMP-USER-BASED-SM-MIB to work, so they're a package deal 🎀.

7.2. Relationship to SNMP-FRAMEWORK-MIB

RFC 3411 [RFC3411] specifies the SNMP-FRAMEWORK-MIB, which defines a subtree called snmpAuthProtocols for SNMP authentication protocols 🌳. this MIB module adds new authentication protocols right into that snmpAuthProtocols subtree, main character energy 👑.

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,
       snmpModules             FROM SNMPv2-SMI          -- [RFC2578]
       snmpAuthProtocols       FROM SNMP-FRAMEWORK-MIB; -- [RFC3411]

   snmpUsmHmacSha2MIB MODULE-IDENTITY
       LAST-UPDATED    "201508130000Z"       -- 13 August 2015, 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 by SNMP's User-based
                       Security Model.

             Copyright (c) 2015 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    "201508130000Z"       -- 13 August 2015, midnight
       DESCRIPTION "Initial version, published as RFC 7630"
   ::= { snmpModules 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 🔥

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

the security considerations of RFC 3414 [RFC3414] also apply to the HMAC-SHA-2 authentication protocols defined in this document. so go read those too, no skipping 🫶.

9.2. Cryptographic Strength of the Authentication Protocols

at the time this document was published, all of the HMAC-SHA-2 authentication protocols provided a very high level of security 💪. each protocol's security depends on the parameters used in its HMAC computation: the length of the key (if the key has maximum entropy), the size of the hash function's internal state, and the length of the truncated MAC. here's the breakdown for each HMAC-SHA-2 protocol (values are 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 security of HMAC scales with both the key length and the size of the internal state 📈. longer keys make key guessing attacks harder, and a bigger internal state lowers the success probability of MAC forgeries based on internal collisions of the hash function 🧠.

the truncated output length is the tricky bit 🤔. 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 HMAC weaker against forgery by guessing, but it makes it stronger against chosen message attacks aiming at MAC forgery through internal collisions, or at key guessing 🦋. RFC 2104 and [BCK] allow truncation to any length that is not less than half the size of the internal state. further discussion of HMAC's security is in RFC 2104 📚.

9.3. Derivation of Keys from Passwords

if secret keys for the HMAC-SHA-2 authentication protocols are derived from passwords, the derivation SHOULD use 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 by itself it 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 already gave the MIB its own OID 🦋 Here's the bestie-approved lineup:

+--------------------+-------------------------+
|     Descriptor     | OBJECT IDENTIFIER value |
+--------------------+-------------------------+
| snmpUsmHmacSha2MIB |   { snmpModules 235 }   |
+--------------------+-------------------------+

Table 2: OID of MIB

And IANA also assigned a value in the SnmpAuthProtocols registry for each of the four protocols 💅 Literally one value per protocol, all from RFC 7630 🎀

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

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

11. References 📚

11.1. Normative References

These are the sources this doc basically can't function without 🫶

11.2. Informative References

These ones are good background reading, bestie 🧚

Authors' Addresses 🎀

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

That's the whole thing, bestie 🌈 Literally iconic work from both of them 👑

📦 where this page comes from