Authenticating version 3 of the Simple Network Management Protocol (SNMPv3) using HMAC-SHA-2 procedures
draft-hartman-snmp-sha2-00

Abstract

This document describes the mechanism to authenticate SNMPv3 protocol packets using Hashed Message Authentication Mode (HMAC) with the SHA-256, SHA-384, and SHA-512 algorithms.

Requirements Language

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 RFC 2119 [RFC2119].

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 http://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 January 16, 2014.

Copyright Notice

Copyright (c) 2013 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
• 2. Cryptographic Aspects
• 3. Authentication Protocols using SHA-2
• 3.1. Elements of Authentication Protocols
• 3.1.1. Users
• 3.1.2. SNMP Messages Using this Authentication Protocol
• 3.2. Services Provided by the Authentication Module
• 3.2.1. Services for Generating an Outgoing SNMP Message
• 3.2.2. Services for Processing an Incoming SNMP Message
• 4. Elements of Procedure
• 4.1. Procedures at the Sending Side
• 4.2. Procedure at the Receiving Side
• 5. IANA Considerations
• 6. Security Considerations
• 7. Acknowledgements
• 8. References
• 8.1. Normative References
• 8.2. Informative References
• Authors' Addresses

1. Introduction

The cryptographic authentication mechanism proposed in [RFC3414] specifies the support of MD5 [RFC1321] and Secure Hash Algorithm (SHA-1) algorithms for authenticating SNMPv3 packets. The recent escalating series of attacks on MD5 and SHA-1 [SHA-1-attack1] [SHA-1-attack2] raise concerns about their remaining useful lifetime [RFC6151] [RFC6194].

These attacks may not necessarily result in direct vulnerabilities for Keyed-MD5 and Keyed-SHA-1 digests as message authentication codes because the colliding message may not correspond to a syntactically correct SNMP protocol packet. Regardless, there is a need felt to deprecate MD5 and SHA-1 as the basis for the HMAC algorithm in favor of stronger digest algorithms.

This document adds support for Secure Hash Algorithms (SHA) defined in the US NIST Secure Hash Standard (SHS), which is defined by NIST FIPS 180-2 [FIPS-180-2]. [FIPS-180-2] includes SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512. The HMAC authentication mode defined in NIST FIPS 198 is used [FIPS-198].

2. Cryptographic Aspects

In the algorithm description below, the following nomenclature, which is consistent with [FIPS-198], is used:

H is the specific hashing algorithm (e.g. SHA-256).

K is the secret key for authentication.

Ko is the cryptographic key used with the hash algorithm.

B is the block size of H, measured in octets rather than bits. Note that B is the internal block size, not the hash size.

For SHA-1 and 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 of source IPv4 address repeated (L/4) times (repeated (L/16) for IPV6 addresses).

(1) Preparation of the 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 AuthenticationParameters field is filled with the value of Apad and is set to the serialization, according to the rules in [RFC3417].

Then, a first hash, also known as the inner hash, is computed as follows:

First-Hash = H(Ko XOR Ipad || (SNMP Packet))

(3) Second Hash T

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 resultant Second-Hash becomes the Authentication Data that is sent in the AuthenticationParameters field. The length of the AuthenticationParameters field is always identical to the message digest size of the specific hash function H that is being used.

3. Authentication Protocols using SHA-2

This section introduces how the authentication protocols using SHA-2 work. The protocols are identical to the authentication protocols proposed in the [RFC3414] except the authentication algorithms used in generating digests.

3.1. Elements of Authentication Protocols

3.1.1. Users

Authentication using the authentication protocols makes use of a defined set of userNames. For any user on whose behalf a message must be authenticated at a particular SNMP engine, that SNMP engine must have knowledge of that user. An SNMP engine that wishes to communicate with another SNMP engine must also have knowledge of a user known to that engine, including knowledge of the applicable attributes of that user.

A user and its attributes are defined as follows:

<userName> A string representing the name of the user.

<authKey> A user's secret key to be used when calculating a digest. Specifically, the value SHOULD be 40 octets for HMAC-SHA-256, 56 octets for HMAC-SHA-384, and 72 octets for HMAC- SHA-512.

3.1.2. SNMP Messages Using this Authentication Protocol

Messages using this authentication protocol carry a msgAuthenticationParameters field as part of the msgSecurityParameters. For this protocol, the msgAuthenticationParameters field is the serialized OCTET STRING representing the SHA-2 output done over the wholeMsg. Specifically, the length of this field is 40 octets for HMAC-SHA-256, 56 octets for HMAC-SHA-384, and 72 octets for HMAC- SHA-512. The digest is calculated over the wholeMsg so if a message is authenticated, that also means that all the fields in the message are intact and have not been tampered with.

3.2. Services Provided by the Authentication Module

3.2.1. Services for Generating an Outgoing SNMP Message

The authentication protocol assumes that the selection of the authKey is done by the caller and that the caller passes the secret key to be used. Upon completion the authentication module returns statusInformation and, if the message digest was correctly calculated, the wholeMsg with the digest inserted at the proper place. The abstract service primitive is:

   statusInformation =              -- success or failure
     authenticateOutgoingMsg(
     IN   authKey                   -- secret key for authentication
     IN   wholeMsg                  -- unauthenticated complete message
     OUT  authenticatedWholeMsg     -- complete authenticated message
          )

The abstract data elements are:

statusInformation: An indication of whether the authentication process was successful. If not it is an indication of the problem.

authKey: The secret key to be used by the authentication algorithm.

wholeMsg: The message to be authenticated.

authenticatedWholeMsg: The authenticated message (including inserted digest) on output.

3.2.2. Services for Processing an Incoming SNMP Message

The authentication protocol assumes that the selection of the authKey is done by the caller and that the caller passes the secret key to be used. Upon completion the authentication module returns statusInformation and, if the message digest was correctly calculated, the wholeMsg as it was processed. The abstract service primitive is:

   statusInformation =              -- success or failure
     authenticateIncomingMsg(
     IN   authKey                   -- secret key for authentication
     IN   authParameters            -- as received on the wire
     IN   wholeMsg                  -- as received on the wire
     OUT  authenticatedWholeMsg     -- complete authenticated message
          )

The abstract data elements are:

statusInformation: An indication of whether the authentication process was successful. If not it is an indication of the problem.

authKey: The secret key to be used by the authentication algorithm.

authParameters: The authParameters from the incoming message.

wholeMsg: The message to be authenticated on input and the authenticated message on output.

authenticatedWholeMsg: The whole message after the authentication check is complete.

4. Elements of Procedure

4.1. Procedures at the Sending Side

Before a SNMPv3 device sends an SNMP packet out, the device needs to select an appropriate key for authentication if a keyed digest for the packet is required. If no appropriate key is avaliable, the SNMP packet MUST be discarded.

If an appropriate key for authentication is available, the device then finds the authentication algorithm (HMAC-SHA-256, HMAC-SHA-384 or HMAC-SHA-512) associated with the key.

Then, the operations illustrated in Section 2 are performed.

The length of the msgAuthenticationParameters field is various according to different authentication algorithms being used. Specifically, the length is 40 octets for HMAC-SHA-256, 56 octets for HMAC-SHA-384, and 72 octets for HMAC-SHA-512.

The authenticatedWholeMsg is then returned to the caller together with statusInformation indicating success.

4.2. Procedure at the Receiving Side

Upon receiving an SNMP packet with a msgAuthenticationParameters field appended, a device needs to locate an appropriate key for authentication to verify the packet.

If there is no key found or the length of the digest received in the msgAuthenticationParameters field does not match the length associated with authentication algorithm, the received packet MUST be discarded.

An authentication algorithm dependent process then needs to be performed by using the algorithm specified by the appropriate key for the received packet.

Before the device performs any processing, it needs to save the content of the AuthenticationParameters field and set the AuthenticationParameters field with Apad.

Then, the operations illustrated in Section 2 are performed. The calculated data is compared with the received authentication data in the packet.

The packet MUST be discarded if the calculated and the received authentication data do not match. In this case, a failure and an errorIndication (authenticationFailure) are returned to the calling module. Otherwise, the authenticatedWholeMsg and statusInformation indicating success are then returned to the caller.

5. IANA Considerations

This document makes no request of IANA.

Note to RFC Editor: this section may be removed on publication as an RFC.

6. Security Considerations

7. Acknowledgements

This work makes use of signifitent texts from that RFC3414.

8. References

8.1. Normative References

8.2. Informative References

Authors' Addresses