HMAC-SHA-2 Authentication Protocols in USM for SNMP

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines additional authentication protocols for the User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) specified in RFC 3414 . In RFC 3414, two different authentication protocols, HMAC-MD5-96 and HMAC-SHA-96, are defined based on the hash functions MD5 and SHA-1, respectively. This memo specifies new optional HMAC-SHA-2 authentication protocols for USM using an HMAC based on the SHA-2 family of hash functions and truncated to 128 bits for SHA-224 and SHA-256, to 192 bits for SHA-256, to 256 bits for SHA-384 and SHA-512, and to 384 bits for SHA-512. These protocols are straightforward adaptations of the authentication protocols HMAC-MD5-96 and HMAC-SHA-96 to the SHA-2 based HMAC.

For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 . Managed objects are accessed via a virtual information store, termed 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 defined 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, RFC 2578 , STD 58, RFC 2579 and STD 58, RFC 2580 .

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 .

This section describes the HMAC-SHA-2 authentication protocols. They use the SHA-2 hash functions, which are described in and , in HMAC mode described in and , truncating the output to 128 bits for SHA-224 and SHA-256, 192 bits for SHA-256, 256 bits for SHA-384 and SHA-512, and 384 bits for SHA-512. also provides source code for all the SHA-2 algorithms and HMAC (without truncation). It also includes test harness and standard test vectors for all the defined hash functions and HMAC examples. The following protocols are defined: usmHMAC128SHA224AuthProtocol: uses SHA-224 and truncates the output to 128 bits (16 octets); usmHMAC128SHA256AuthProtocol: uses SHA-256 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); usmHMAC256SHA512AuthProtocol: uses SHA-512 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 usmHMAC256SHA512AuthProtocol. All other protocols specified above are OPTIONAL.

All the HMAC-SHA-2 authentication protocols are straightforward adaptations of the HMAC-MD5-96 and HMAC-SHA-96 authentication protocols. Precisely, they differ from the HMAC-MD5-96 and HMAC-SHA-96 authentication protocols in the following aspects: The SHA-2 hash function is used to compute the message digest in the HMAC computation according to , as opposed to the MD5 hash function and SHA-1 hash function used in HMAC-MD5-96 and HMAC-SHA-96, respectively. Consequently, the length of the message digest prior to truncation is 224 bits for SHA-224 based protocol, 256 bits for SHA-256 based protocol, 384 bits for SHA-384 based protocol, and 512 bits for SHA-512 based protocol. The resulting message digest (output of HMAC) is truncated to 16 octets for usm128HMACSHA224AuthProtocol and usmHMAC128SHA256AuthProtocol 24 octets for usm192HMACSHA256AuthProtocol 32 octets for usm256HMACSHA384AuthProtocol and usmHMAC256SHA512AuthProtocol 48 octets for usm384HMACSHA512AuthProtocol 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 protocols usmHMAC128SHA256AuthProtocol and 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 protocols usmHMAC256SHA512AuthProtocol and usmHMAC384SHA512AuthProtocol as opposed to the keys being 16 and 20 octets long in HMAC-MD5-96 and HMAC-SHA-96, respectively.

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

Values of constants M (the length of the secret key) and N (the length of the MAC output) used below, are: usmHMAC128SHA224AuthProtocol: M=28, N=16; usmHMAC128SHA256AuthProtocol: M=32, N=16; usmHMAC192SHA256AuthProtocol: M=32, N=24; usmHMAC256SHA384AuthProtocol: M=48, N=32; usmHMAC256SHA512AuthProtocol: M=64, N=32; usmHMAC384SHA512AuthProtocol: M=64, N=48. correspondingly. This section describes the procedure followed by an SNMP engine whenever it must authenticate an outgoing message using one of the authentication protocols defined above. The msgAuthenticationParameters field is set to serialization, according to the rules in , of an OCTET STRING containing N zero octets. From the secret authKey of M octets, calculate the HMAC-SHA-2 digest over it according to HMAC . Take the first N octets of the final digest - this is the Message Authentication Code (MAC). Replace the msgAuthenticationParameters field with the MAC obtained in the previous step. The authenticatedWholeMsg is then returned to the caller together with statusInformation indicating success.

Values of the constants M and N are the same as in , and are selected based on which authentication protocol is configured for the given USM usmUserTable entry. This section describes the procedure followed by an SNMP engine whenever it must authenticate an incoming message using one of the HMAC-SHA-2 authentication protocols. If the digest received in the msgAuthenticationParameters field is not N octets long, then an failure and an errorIndication (authenticationError) is returned to the calling module. The MAC received in the msgAuthenticationParameters field is saved. The digest in the msgAuthenticationParameters field is replaced by the N zero octets. Using the secret authKey, the HMAC is calculated over the wholeMsg. N first octets of the above HMAC are taken as the computed MAC value. The msgAuthenticationParameters field is replaced with the MAC value that was saved in step 2. The newly calculated MAC is compared with the MAC saved in step 2. If they do not match, then a failure and an errorIndication (authenticationFailure) are returned to the calling module. The authenticatedWholeMsg and statusInformation indicating success are then returned to the caller.

For any of the protocols defined in , key localization and key change SHALL be performed according to RFC 3414 using the SHA-2 hash function applied in the respective protocol.

The MIB module specified in this memo does not define any managed objects, subtrees, notifications or tables, but only object identities (for authentication protocols) under a subtree of an existing MIB.

RFC 3414 specifies the MIB for the User-based Security Model (USM) for SNMPv3 (SNMP-USER-BASED-SM-MIB), which defines authentication protocols for USM based on the hash functions MD5 and SHA-1, respectively. The following MIB module defines new HMAC-SHA2 authentication protocols for USM based on the SHA-2 hash functions . The use of the HMAC-SHA2 authentication protocols requires the usage of the objects defined in the SNMP-USER-BASED-SM-MIB.

RFC 3411 specifies the The SNMP Management Architecture MIB (SNMP-FRAMEWORK-MIB), which defines a subtree snmpAuthProtocols for SNMP authentication protocols. The following MIB module defines new authentication protocols in the snmpAuthProtocols subtree. Therefore, the use of the HMAC-SHA2 authentication protocols requires the usage of the objects defined in the SNMP-FRAMEWORK-MIB.

The following MIB module IMPORTS objects from SNMPv2-SMI and SNMP-FRAMEWORK-MIB .

The security considerations of also apply the use of all the HMAC-SHA-2 authentication protocols in USM.

At the time of this writing, all of the HMAC-SHA-2 authentication protocols provide a very high level of security. The security of each HMAC-SHA-2 authentication protocol depends on the parameters used in the corresponding HMAC computation, which are the length of the key, the size of the hash function's internal state, and the length of the truncated MAC. For the HMAC-SHA-2 authentication protocols these values are as follows (values are given in bits). Protocol Key length Size of internal state MAC length usmHMAC128SHA224AuthProtocol 224 256 128 usmHMAC128SHA256AuthProtocol 256 256 128 usmHMAC192SHA256AuthProtocol 256 256 192 usmHMAC256SHA384AuthProtocol 384 512 256 usmHMAC256SHA512AuthProtocol 512 512 256 usmHMAC384SHA512AuthProtocol 512 512 384 The security of the HMAC scales with both the key length and the size of the internal state: longer keys render key guessing attacks more difficult, and a larger internal state decreases the success probability of MAC forgeries based on internal collisions of the hash function. The role of the truncated output length is more complicated: according to , there is a trade-off in that "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"; thus, truncation weakens the HMAC against forgery by guessing, but at the same time strengthens it against chosen message attacks aiming at MAC forgery based on internal collisions or at key guessing. and allow truncation to any length that is not less than half the size of the internal state. In order to provide some flexibility in the case of future results on optimal HMAC truncation, this specification provides multiple choices. Further discussion of the security of the HMAC construction is given in .

If secret keys to be used for HMAC-SHA-2 authentication protocols are derived from passwords, the derivation SHOULD be performed using the password-to-key algorithm from Appendix A.1 of RFC 3414 with MD5 being replaced by the SHA-2 hash function H used in the HMAC-SHA-2 authentication protocol. Specifically, the password is converted into the required secret key by the following 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. a second string is formed by concatenating digest1, the SNMP engine's snmpEngineID value, and digest1. This string is used as input to the hash function H.

None of the objects defined in SNMP-USM-HMAC-SHA2-MIB is writable, and the information they represent is not deemed to be particularly sensitive. However, if they are deemed sensitive in a particular environment, access to them should be restricted through the use of appropriately configured Security and Access Control models.

IANA is requested to assign an OID for Descriptor OBJECT IDENTIFIER value snmpUsmHmacSha2MIB { snmpModules nn } with nn appearing in the MIB module definition in . Furthermore, IANA is requested to assign a value in the SnmpAuthProtocols registry for each of the following protocols. Description Value Reference usmHMAC128SHA224AuthProtocol aa RFC YYYY usmHMAC128SHA256AuthProtocol bb RFC YYYY usmHMAC192SHA256AuthProtocol cc RFC YYYY usmHMAC256SHA384AuthProtocol dd RFC YYYY usmHMAC256SHA512AuthProtocol ee RFC YYYY usmHMAC384SHA512AuthProtocol ff RFC YYYY -- RFC Ed.: replace YYYY with actual RFC number and remove this line with aa, bb, cc, etc. appearing in the MIB module definition in .