Javascript disabled? Like other modern websites, the IETF Datatracker relies on Javascript. Please enable Javascript for full functionality.

HMAC-SHA-2 Authentication Protocols in USM for SNMPv3
draft-ietf-opsawg-hmac-sha-2-usm-snmp-new-03

Versions:

The information below is for an old version of the document.

Document	Type	This is an older version of an Internet-Draft that was ultimately published as RFC 7860.
	Authors	Johannes Merkle , Manfred Lochter
	Last updated	2016-01-26
	RFC stream	Internet Engineering Task Force (IETF)
	Formats	txt htmlized pdf bibtex bibxml
	Reviews	GENART Telechat review (of -04) by Dan Romascanu Ready OPSDIR Last Call review (of -01) by Will LIU Has nits SECDIR Last Call review (of -01) by Donald Eastlake Has nits GENART Last Call review (of -01) by Dan Romascanu Ready
	Additional resources	Mailing list discussion
Stream	WG state	Submitted to IESG for Publication
	Document shepherd	(None)
IESG	IESG state	Became RFC 7860 (Proposed Standard)
	Consensus boilerplate	Unknown
	Telechat date	(None)
	Responsible AD	Joel Jaeggli
	Send notices to	(None)
IANA	IANA review state	Version Changed - Review Needed

Email authors Email WG IPR References Referenced by Nits Search email archive

draft-ietf-opsawg-hmac-sha-2-usm-snmp-new-03

OPSAWG J. Merkle, Ed.
Internet-Draft Secunet Security Networks
Obsoletes: 7630 (if approved) M. Lochter
Intended status: Standards Track BSI
Expires: July 29, 2016 January 26, 2016

HMAC-SHA-2 Authentication Protocols in USM for SNMPv3
draft-ietf-opsawg-hmac-sha-2-usm-snmp-new-03

Abstract

This memo specifies new HMAC-SHA-2 authentication protocols for the
User-based Security Model (USM) for SNMPv3 defined in RFC 3414.

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 July 29, 2016.

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.

Merkle & Lochter Expires July 29, 2016 [Page 1]
Internet-Draft HMAC-SHA-2_Auth_USM_new January 2016

Table of Contentsquot;), providing a quick and generic comparison
table among them. Then the document describes the issues that an
operator need to understand on different matters that will allow to
define what is the best approach/scenario for each specific network
case. A summary provides some recommendations and decision points.
A section with clarifications on the usage of this document for
enterprise networks, is also provided. Finally, an annex provides an
example of a broadband deployment using 464XLAT and another annex
provides hints for a CLAT implementation.

[RFC7269] already provides information about NAT64 deployment options
and experiences. Both, this document and [RFC7269] are
complementary, as they are looking into different deployment
considerations and furthermore, this document is considering the
updated deployment experience and newer standards.

The target deployment scenarios in this document may be covered as
well by other IPv4-as-a-Service (IPv4aaS) transition mechanisms.
Note that this is true only for the case of broadband networks, as in
the case of cellular networks the only supported solution is the use
of NAT64/464XLAT. So, it is out of scope of this document to provide
a comparison among the different IPv4aaS transition mechanisms, which
is being analyzed already in [I-D.lmhp-v6ops-transition-comparison].

Palet Martinez Expires November 5, 2019 [Page 4]
Internet-Draft NAT64/464XLAT Deployment May 2019

Consequently, this document should not be understood as a guide for
an operator or enterprise to decide which IPv4aaS is the best one for
its own network. Instead it should be used as a tool for
understanding all the implications, including relevant documents (or
even specific parts of them), for the deployment of NAT64/464XLAT and
facilitate the decision process regarding specific deployment
details.

2. 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.

3. NAT64 Deployment Scenarios

Section 7 of DNS64 ([RFC6147]), provides three scenarios, depending
on the location of the DNS64 function. However, since the
publication of that document, other deployment scenarios and NAT64
use cases need to be considered in actual networks, despite some of
them were specifically ruled out by the original NAT64/DNS64 work.

Consequently, the perspective in this document is to broaden those
scenarios, including a few new ones. However, in order to be able to
reduce the number of possible cases, we work under the assumption
that typically, the service provider wants to make sure that all the
customers have a service without failures. This means considering
the following assumptions for the worst possible case:

a. There are hosts that will be validating DNSSEC.

b. IPv4 literal addresses and non-IPv6 compliant APIs are being
used.

c. There are IPv4-only hosts or applications beyond the IPv6-only
link (e.g., tethering in cellular networks).

The document uses a common set of possible "participant entities":

1. An IPv6-only access network (IPv6).

2. An IPv4-only remote network/server/service (IPv4).

3. A NAT64 function (NAT64) in the service provider.

4. A DNS64 function (DNS64) in the service provider.

Palet Martinez Expires November 5, 2019 [Page 5]
Internet-Draft NAT64/464XLAT Deployment May 2019

5. An external service provider offering the NAT64 function and/or
the DNS64 function (extNAT64/extDNS64).

6. 464XLAT customer side translator (CLAT).

Note that the nomenclature used in parenthesis is the one that, for
short, will be used in the figures.

The possible scenarios are split in two general categories:

1. Known to work.

2. Known to work under special conditions.

3.1. Known to Work

The scenarios in this category are known to work. Each one may have
different pros and cons, and in some cases the trade-offs, maybe
acceptable for some operators.

3.1.1. Service Provider NAT64 with DNS64

In this scenario, the service provider offers both, the NAT64 and the
DNS64 functions.

This is the most common scenario as originally considered by the
designers of NAT64 ([RFC6146]) and DNS64 ([RFC6147]), however also
may have the implications related the DNSSEC.

This scenario also may fail to solve the issue of IPv4 literal
addresses or non-IPv6 compliant APIs, as well as the issue of
IPv4-only hosts or applications behind the IPv6-only access network.

+----------+ +----------+ +----------+
| | | NAT64 | | |
| IPv6 +--------+ + +--------+ IPv4 |
| | | DNS64 | | |
+----------+ +----------+ +----------+

Figure 1: NAT64 with DNS64

A similar scenario will be if the service provider offers only the
DNS64 function, and the NAT64 function is provided by an outsourcing
agreement with an external provider. All the considerations in the
previous paragraphs of this section are the same for this sub-case.

Palet Martinez Expires November 5, 2019 [Page 6]
Internet-Draft NAT64/464XLAT Deployment May 2019

+----------+ +----------+
| | | |
| extNAT64 +--------+ IPv4 |
| | | |
+----+-----+ +----------+
|
|
+----------+ +----+-----+
| | | |
| IPv6 +--------+ DNS64 +
| | | |
+----------+ +----------+

Figure 2: NAT64 in external service provider

This is equivalent to the scenario where the outsourcing agreement
with the external provider is to provide both the NAT64 and DNS64
functions. Once more, all the considerations in the previous
paragraphs of this section are the same for this sub-case.

+----------+ +----------+
| extNAT64 | | |
| + +-------+ IPv4 |
| extDNS64 | | |
+----+-----+ +----------+
|
+----------+ |
| | |
| IPv6 +-------------+
| |
+----------+

Figure 3: NAT64 and DNS64 in external provider

One more equivalent scenario will be if the service provider offers
the NAT64 function only, and the DNS64 function is from an external
provider with or without a specific agreement among them. This is a
scenario already common today, as several "global" service providers
provide free DNS/DNS64 services and users often configure manually
their DNS. This will only work if both the NAT64 and the DNS64
functions are using the WKP (Well-Known Prefix) or the same NSP
(Network-Specific Prefix). All the considerations in the previous
paragraphs of this section are the same for this sub-case.

Of course, if the external DNS64 function is agreed with the service
provider, then we are in the same case as in the previous ones
already depicted in this scenario.

Palet Martinez Expires November 5, 2019 [Page 7]
Internet-Draft NAT64/464XLAT Deployment May 2019

+----------+
| |
| extDNS64 |
| |
+----+-----+
|
|
+----------+ +----+-----+ +----------+
| | | | | |
| IPv6 +--------+ NAT64 +--------+ IPv4 |
| | | | | |
+----------+ +----------+ +----------+

Figure 4: NAT64; DNS64 by external provider

3.1.2. Service Provider Offering 464XLAT, with DNS64

464XLAT ([RFC6877]) describes an architecture that provides IPv4
connectivity across a network, or part of it, when it is only
natively transporting IPv6. [RFC7849] already suggest the need to
support the CLAT function in order to ensure the IPv4 service
continuity in IPv6-only cellular deployments.

In order to do that, 464XLAT ([RFC6877]) relies on the combination of
existing protocols:

1. The customer-side translator (CLAT) is a stateless IPv4 to IPv6
translator (NAT46) ([RFC7915]) implemented in the end-user device
or CE (Customer Edge Router), located at the "customer edge" of
the network.

2. The provider-side translator (PLAT) is a stateful NAT64
([RFC6146]), implemented typically at in the operator network.

3. Optionally, DNS64 ([RFC6147]), may allow an optimization: a
single translation at the NAT64, instead of two translations
(NAT46+NAT64), when the application at the end-user device
supports IPv6 DNS (uses AAAA Resource Records).

Note that even if in the 464XLAT ([RFC6877]) terminology, the
provider-side translator is referred as PLAT, for simplicity and
uniformity, across this document is always referred as NAT64
(function).

In this scenario the service provider deploys 464XLAT with a DNS64
function.

As a consequence, the DNSSEC issues remain, unless the host is doing

Palet Martinez Expires November 5, 2019 [Page 8]
Internet-Draft NAT64/464XLAT Deployment May 2019

the address synthesis.

464XLAT ([RFC6877]) is a very simple approach to cope with the major
NAT64+DNS64 drawback: Not working with applications or devices that
use literal IPv4 addresses or non-IPv6 compliant APIs.

464XLAT ([RFC6877]) has been used initially mainly in IPv6-only
cellular networks. By supporting a CLAT function, the end-user
device applications can access IPv4-only end-networks/applications,
despite those applications or devices use literal IPv4 addresses or
non-IPv6 compliant APIs.

In addition to that, in the same example of the cellular network
above, if the User Equipment (UE) provides tethering, other devices
behind it will be presented with a traditional NAT44, in addition to
the native IPv6 support, so clearly it allows IPv4-only hosts behind
the IPv6-only access network.

Furthermore, as discussed in [RFC6877], 464XLAT can be used in
broadband IPv6 network architectures, by implementing the CLAT
function at the CE.

The support of this scenario offers two additional advantages:

o DNS load optimization: A CLAT should implement a DNS proxy (as per
[RFC5625]), so that only IPv6 native queries and only for AAAA
records are sent to the DNS64 server. Otherwise doubling the
number of queries may impact the DNS infrastructure.

o Connection establishment delay optimization: If the UE/CE
implementation is detecting the presence of a DNS64 function, it
may issue only the AAAA query, instead of both the AAAA and A
queries.

In order to understand all the communication possibilities, let's
assume the following representation of two dual-stack peers:

Palet Martinez Expires November 5, 2019 [Page 9]
Internet-Draft NAT64/464XLAT Deployment May 2019

Figure A: Representation of 464XLAT among two peers with DNS64

The possible communication paths, among the IPv4/IPv6 stacks of both
peers, in this case, are:

a. Local-IPv6 to Remote-IPv6: Regular DNS and native IPv6 among
peers.

b. Local-IPv6 to Remote-IPv4: DNS64 and NAT64 translation.

c. Local-IPv4 to Remote-IPv6: Not possible unless the CLAT
implements EAM (Explicit Address Mappings) as indicated by
Section 4.9. In principle, it is not expected that services are
deployed in Internet using IPv6-only, unless there is certainty
that peers will also be IPv6-capable.

d. Local-IPv4 to Remote-IPv4: DNS64, CLAT and NAT64 translations.

e. Local-IPv4 to Remote-dual-stack using EAM optimization: If the
CLAT implements EAM as indicated by Section 4.9, instead of using
the path d. above, NAT64 translation is avoided and the flow will
use IPv6 from the CLAT to the destination.

The rest of the figures in this section show different choices for
placing the different elements.

+----------+ +----------+ +----------+
| IPv6 | | NAT64 | | |
| + +--------+ + +--------+ IPv4 |
| CLAT | | DNS64 | | |
+----------+ +----------+ +----------+

Figure 5: 464XLAT with DNS64

Palet Martinez Expires November 5, 2019 [Page 10]
Internet-Draft NAT64/464XLAT Deployment May 2019

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 . . . . . . . . . . . . . . . . . . . . . . . 13

1. Introduction

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 the Simple Network Management Protocol version 3 (SNMPv3)
specified in [RFC3414].

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 HMAC-SHA-2 authentication
protocols for USM using a Hashed Message Authentication Code (HMAC)
based on the SHA-2 family of hash functions [SHA] and truncated to
128 bits for SHA-224, to 192 bits for SHA-256, to 256 bits for
SHA-384, 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.

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

Merkle & Lochter Expires July 29, 2016 [Page 2]
Internet-Draft HMAC-SHA-2_Auth_USM_new January 2016

2. The Internet-Standard Management Framework

For a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to section 7 of
[RFC3410].

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
[RFC2578], [RFC2579], and [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, which
use the SHA-2 hash functions (described in FIPS PUB 180-4 [SHA] and
[RFC6234]) in the HMAC mode (described in [RFC2104] and RFC 6234),
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 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);

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

Merkle & Lochter Expires July 29, 2016 [Page 3]
Internet-Draft HMAC-SHA-2_Auth_USM_new January 2016

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 the HMAC-MD5-96 and HMAC-
SHA-96 authentication protocols in the following aspects:

o 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 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.

o 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.

o 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

Merkle & Lochter Expires July 29, 2016 [Page 4]
Internet-Draft HMAC-SHA-2_Auth_USM_new January 2016

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 defined for HMAC-SHA-96 in
RFC 3414 with the deviations listed in Section 4.1.

Values of constants M (the length of the secret key in octets) and N
(the length of the Message Authentication Code (MAC) output in
octets), and 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 describes the procedure followed by an SNMP engine
whenever it must authenticate an outgoing message using one of the
authentication protocols defined above. Values of the constants M
and N, and the hash function H are as defined in Section 4.2 and are
selected 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 is 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 N first 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.

Merkle & Lochter Expires July 29, 2016 [Page 5]
Internet-Draft HMAC-SHA-2_Auth_USM_new January 2016

4.2.2. Processing an Incoming Message

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. Values of the constants M and
N, and the hash function H are as defined in Section 4.2 and are
selected based on which authentication protocol is configured for the
given USM usmUser Table entry.

1. If the digest received in the msgAuthenticationParameters field
is not N octets long, then a failure and an errorIndication
(authenticationError) are returned to the calling module.

2. The MAC received in the msgAuthenticationParameters field is
saved.

3. The digest in the msgAuthenticationParameters field is replaced
by the N zero octets.

4. Using the secret authKey of M octets, the HMAC is calculated over
the wholeMsg according to RFC 6234 with hash function H.

5. The N first octets of the above HMAC are taken as the computed
MAC value.

6. The msgAuthenticationParameters field is replaced with the MAC
value that was saved in step 2.

7. 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.

8. The authenticatedWholeMsg and statusInformation indicating
success are then 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 [RFC3414] using the same
SHA-2 hash function as in the HMAC-SHA-2 authentication protocol.

6. Structure of the MIB Module

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

Merkle & Lochter Expires July 29, 2016 [Page 6]
Internet-Draft HMAC-SHA-2_Auth_USM_new January 2016

7. Relationship to Other MIB Modules

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

RFC 3414 specifies the MIB module for 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 [SHA]. The use of the HMAC-SHA2
authentication protocols requires the usage of the objects defined in
the SNMP-USER-BASED-SM-MIB.

7.2. Relationship to SNMP-FRAMEWORK-MIB

[RFC3411] specifies the SNMP-FRAMEWORK-MIB, which defines a subtree
snmpAuthProtocols for SNMP authentication protocols. The following
MIB module defines new authentication protocols in the
snmpAuthProtocols subtree.

7.3. MIB Modules Required for IMPORTS

The following 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 -- [RFC2578]
snmpAuthProtocols FROM SNMP-FRAMEWORK-MIB; -- [RFC3411]

snmpUsmHmacSha2MIB MODULE-IDENTITY
LAST-UPDATED "201510210000Z" -- 21 October 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

Merkle & Lochter Expires July 29, 2016 [Page 7]
Internet-Draft HMAC-SHA-2_Auth_USM_new January 2016

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.

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 "201510210000Z" -- 21 October 2015, midnight
DESCRIPTION "Version correcting the MODULE-IDENTITY value, published as RFC TBD"
-- RFC Ed.: replace TBD with actual RFC number & remove this line
REVISION "201508130000Z" -- 13 August 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,

Merkle & Lochter Expires July 29, 2016 [Page 8]
Internet-Draft HMAC-SHA-2_Auth_USM_new January 2016

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 [RFC3414] also apply to the HMAC-SHA-2
authentication protocols defined in this document.

9.2. Cryptographic Strength of the Authentication Protocols

At the time of publication of this document, 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 (if the key has maximum entropy), 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).

Merkle & Lochter Expires July 29, 2016 [Page 9]
Internet-Draft HMAC-SHA-2_Auth_USM_new January 2016

+------------------------------+---------+----------------+---------+
| 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 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 [BCK], 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. RFC
2104 and [BCK] allow truncation to any length that is not less than
half the size of the internal state.

Further discussion of the security of the HMAC construction is given
in RFC 2104.

9.3. Derivation of Keys from Passwords

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:

o 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.

Merkle & Lochter Expires July 29, 2016 [Page 10]
Internet-Draft HMAC-SHA-2_Auth_USM_new January 2016

o 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 does not define any objects that
can be accessed. As such, the SNMP-USM-HMAC-SHA2-MIB does not, by
itself, have any 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

IANA has assigned an OID for the MIB as follows.

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

Table 2: OID of MIB

Furthermore, IANA has assigned a value in the SnmpAuthProtocols
registry for each of the following protocols.

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

-- RFC Ed.: replace XXX with actual RFC number and remove this line

Merkle & Lochter Expires July 29, 2016 [Page 11]
Internet-Draft HMAC-SHA-2_Auth_USM_new January 2016

11. References

11.1. Normative References

[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997,
<http://www.rfc-editor.org/info/rfc2104>.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.

[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management Information
Version 2 (SMIv2)", STD 58, RFC 2578,
DOI 10.17487/RFC2578, April 1999,
<http://www.rfc-editor.org/info/rfc2578>.

[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Textual Conventions for SMIv2",
STD 58, RFC 2579, DOI 10.17487/RFC2579, April 1999,
<http://www.rfc-editor.org/info/rfc2579>.

[RFC2580] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Conformance Statements for SMIv2",
STD 58, RFC 2580, DOI 10.17487/RFC2580, April 1999,
<http://www.rfc-editor.org/info/rfc2580>.

[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model
(USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)", STD 62, RFC 3414,
DOI 10.17487/RFC3414, December 2002,
<http://www.rfc-editor.org/info/rfc3414>.

[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011,
<http://www.rfc-editor.org/info/rfc6234>.

[SHA] National Institute of Standards and Technology, "Secure
Hash Standard (SHS)", FIPS PUB 180-4,
DOI 10.6028/NIST.FIPS.180-4, March 2012,
<http://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.180-4.pdf>.

Merkle & Lochter Expires July 29, 2016 [Page 12]
Internet-Draft HMAC-SHA-2_Auth_USM_new January 2016

11.2. Informative References

[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
DOI 10.17487/RFC1321, April 1992,
<http://www.rfc-editor.org/info/rfc1321>.

[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410,
DOI 10.17487/RFC3410, December 2002,
<http://www.rfc-editor.org/info/rfc3410>.

[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
DOI 10.17487/RFC3411, December 2002,
<http://www.rfc-editor.org/info/rfc3411>.

[RFC3417] Presuhn, R., Ed., "Transport Mappings for the Simple
Network Management Protocol (SNMP)", STD 62, RFC 3417,
DOI 10.17487/RFC3417, December 2002,
<http://www.rfc-editor.org/info/rfc3417>.

[BCK] Bellare, M., Canetti, R., and H. Krawczyk, "Keyed Hash
Functions for Message Authentication", Advances in
Cryptology - CRYPTO 96, Lecture Notes in Computer
Science 1109, Springer-Verlag Berlin Heidelberg,
DOI 10.1007/3-540-68697-5_1, 1996.

Authors' Addresses

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

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

Merkle & Lochter Expires July 29, 2016 [Page 13]A similar scenario will be if the service provider offers only the
DNS64 function, and the NAT64 function is provided by an outsourcing
agreement with an external provider. All the considerations in the
previous paragraphs of this section are the same for this sub-case.

+----------+ +----------+
| | | |
| extNAT64 +--------+ IPv4 |
| | | |
+----+-----+ +----------+
|
|
+----------+ +----+-----+
| IPv6 | | |
| + +--------+ DNS64 +
| CLAT | | |
+----------+ +----------+

Figure 6: 464XLAT with DNS64; NAT64 in external provider

As well, is equivalent to the scenario where the outsourcing
agreement with the external provider is to provide both the NAT64 and
DNS64 functions. Once more, all the considerations in the previous
paragraphs of this section are the same for this sub-case.

+----------+ +----------+
| extNAT64 | | |
| + +--------+ IPv4 |
| extDNS64 | | |
+----+-----+ +----------+
|
+----------+ |
| IPv6 | |
| + +-------------+
| CLAT |
+----------+

Figure 7: 464XLAT with DNS64; NAT64 and DNS64 in external provider

3.1.3. Service Provider Offering 464XLAT, without DNS64

The major advantage of this scenario, using 464XLAT without DNS64, is
that the service provider ensures that DNSSEC is never broken, even
in case the user modifies the DNS configuration. Nevertheless, some
CLAT implementations or applications may impose an extra delay, which
is induced by the dual A/AAAA queries (and wait for both responses),
unless Happy Eyeballs v2 (HEv2, [RFC8305]) is also present.

Palet Martinez Expires November 5, 2019 [Page 11]
Internet-Draft NAT64/464XLAT Deployment May 2019

A possible variation of this scenario is the case when DNS64 is used
only for the discovery of the NAT64 prefix. The rest of the document
is not considering it as a different scenario, because once the
prefix has been discovered, the DNS64 function is not used, so it
behaves as if the DNS64 synthesis function is not present.

In this scenario, as in the previous one, there are no issues related
to IPv4-only hosts (or IPv4-only applications) behind the IPv6-only
access network, neither related to the usage of IPv4 literals or non-
IPv6 compliant APIs.

The support of this scenario offers one advantage:

o DNS load optimization: A CLAT should implement a DNS proxy (as per
[RFC5625]), so that only IPv6 native queries are sent to the DNS64
server. Otherwise doubling the number of queries may impact the
DNS infrastructure.

As indicated earlier, the connection establishment delay optimization
is achieved only in the case of devices, Operating Systems, or
applications that use HEv2 ([RFC8305]), which is very common.

Let's assume the representation of two dual-stack peers as in the
previous case:

Figure B: Representation of 464XLAT among two peers without DNS64

The possible communication paths, among the IPv4/IPv6 stacks of both
peers, in this case, are:

a. Local-IPv6 to Remote-IPv6: Regular DNS and native IPv6 among
peers.

b. Local-IPv6 to Remote-IPv4: Regular DNS, CLAT and NAT64

Palet Martinez Expires November 5, 2019 [Page 12]
Internet-Draft NAT64/464XLAT Deployment May 2019

translations.

c. Local-IPv4 to Remote-IPv6: Not possible unless the CLAT
implements EAM as indicated by Section 4.9. In principle, it is
not expected that services are deployed in Internet using
IPv6-only, unless there is certainty that peers will also be
IPv6-capable.

d. Local-IPv4 to Remote-IPv4: Regular DNS, CLAT and NAT64
translations.

It needs to be noticed that this scenario works while the local
hosts/applications are dual-stack (which is the current situation),
because the connectivity from a local-IPv6 to a remote-IPv4 is not
possible without an AAAA synthesis. This aspect is important only
when in the LANs behind the CLAT there are IPv6-only hosts and they
need to communicate with remote IPv4-only hosts. However, it doesn't
look a sensible approach from an Operating System or application
vendor perspective, to provide IPv6-only support unless, similarly to
case c above, there is certainty of peers supporting IPv6 as well. A
solution approach to this is also presented in
[I-D.palet-v6ops-464xlat-opt-cdn-caches].

The following figures show different choices for placing the
different elements.

+----------+ +----------+ +----------+
| IPv6 | | | | |
| + +--------+ NAT64 +--------+ IPv4 |
| CLAT | | | | |
+----------+ +----------+ +----------+

Figure 8: 464XLAT without DNS64

This is equivalent to the scenario where there is an outsourcing
agreement with an external provider for the NAT64 function. All the
considerations in the previous paragraphs of this section are the
same for this sub-case.

Palet Martinez Expires November 5, 2019 [Page 13]
Internet-Draft NAT64/464XLAT Deployment May 2019

+----------+ +----------+
| | | |
| extNAT64 +--------+ IPv4 |
| | | |
+----+-----+ +----------+
|
+----------+ |
| IPv6 | |
| + +-------------+
| CLAT |
+----------+

Figure 9: 464XLAT without DNS64; NAT64 in external provider

3.2. Known to Work Under Special Conditions

The scenarios in this category are known to not work unless
significant effort is devoted to solve the issues, or are intended to
solve problems across "closed" networks, instead of as a general
Internet access usage. In addition to the different pros, cons and
trade-offs, which may be acceptable for some operators, they have
implementation difficulties, as they are beyond the original
expectations of the NAT64/DNS64 original intent.

3.2.1. Service Provider NAT64 without DNS64

In this scenario, the service provider offers a NAT64 function,
however there is no DNS64 function support at all.

As a consequence, an IPv6 host in the IPv6-only access network, will
not be able to detect the presence of DNS64 by means of [RFC7050],
neither to learn the IPv6 prefix to be used for the NAT64 function.

This can be sorted out as indicated in Section 4.1.1.

However, despite that, because the lack of the DNS64 function, the
IPv6 host will not be able to obtain AAAA synthesized records, so the
NAT64 function becomes useless.

An exception to this "useless" scenario will be manually configure
mappings between the A records of each of the IPv4-only remote hosts
and the corresponding AAAA records, with the WKP (Well-Known Prefix)
or NSP (Network-Specific Prefix) used by the service provider NAT64
function, as if they were synthesized by a DNS64 function.

This mapping could be done by several means, typically at the
authoritative DNS server, or at the service provider resolvers by
means of DNS RPZ (Response Policy Zones, [I-D.vixie-dns-rpz]) or

Palet Martinez Expires November 5, 2019 [Page 14]
Internet-Draft NAT64/464XLAT Deployment May 2019

equivalent functionality. DNS RPZ, may have implications in DNSSEC,
if the zone is signed. Also, if the service provider is using an
NSP, having the mapping at the authoritative server, may create
troubles to other parties trying to use different NSP or the WKP,
unless multiple DNS "views" (split-DNS) is also being used at the
authoritative servers.

Generally, the mappings alternative, will only make sense if a few
set of IPv4-only remote hosts need to be accessed by a single network
(or a small number of them), which support IPv6-only in the access.
This will require some kind of mutual agreement for using this
procedure, so it doesn't care if they become a trouble for other
parties across Internet ("closed services").

In any case, this scenario doesn't solve the issue of IPv4 literal
addresses or non-IPv6 compliant APIs, neither it solves the problem
of IPv4-only hosts within that IPv6-only access network.

+----------+ +----------+ +----------+
| | | | | |
| IPv6 +--------+ NAT64 +--------+ IPv4 |
| | | | | |
+----------+ +----------+ +----------+

Figure 10: NAT64 without DNS64

3.2.2. Service Provider NAT64; DNS64 in the IPv6 hosts

In this scenario, the service provider offers the NAT64 function, but
not the DNS64 function. However, the IPv6 hosts have a built-in
DNS64 function.

This may become common if the DNS64 function is implemented in all
the IPv6 hosts/stacks, which is not the actual situation, but it may
happen in the medium-term. At this way, the DNSSEC validation is
performed on the A record, and then the host can use the DNS64
function so to be able to use the NAT64 function, without any DNSSEC
issues.

This scenario fails to solve the issue of IPv4 literal addresses or
non-IPv6 compliant APIs, unless the IPv6 hosts also supports HEv2
([RFC8305], Section 7.1), which may solve that issue.

However, this scenario still fails to solve the problem of IPv4-only
hosts or applications behind the IPv6-only access network.

Palet Martinez Expires November 5, 2019 [Page 15]
Internet-Draft NAT64/464XLAT Deployment May 2019

+----------+ +----------+ +----------+
| IPv6 | | | | |
| + +--------+ NAT64 +--------+ IPv4 |
| DNS64 | | | | |
+----------+ +----------+ +----------+

Figure 11: NAT64; DNS64 in IPv6 hosts

3.2.3. Service Provider NAT64; DNS64 in the IPv4-only remote network

In this scenario, the service provider offers the NAT64 function
only. The remote IPv4-only network offers the DNS64 function.

This is not common, and looks like doesn't make too much sense that a
remote network, not deploying IPv6, is providing a DNS64 function.
As in the case of the scenario depicted in Section 3.2.1, it will
only work if both sides are using the WKP or the same NSP, so the
same considerations apply. It can be also tuned to behave as in
Section 3.1.1

This scenario still fails to solve the issue of IPv4 literal
addresses or non-IPv6 compliant APIs.

This scenario also fails to solve the problem of IPv4-only hosts or
applications behind the IPv6-only access network.

+----------+ +----------+ +----------+
| | | | | IPv4 |
| IPv6 +--------+ NAT64 +--------+ + |
| | | | | DNS64 |
+----------+ +----------+ +----------+

Figure 12: NAT64; DNS64 in the IPv4-only

3.3. Comparing the Scenarios

This section compares the different scenarios, including the possible
variations (each one represented in the precedent sections by a
different figure), looking at the following criteria:

a. DNSSEC: Are there hosts validating DNSSEC?

b. Literal/APIs: Are there applications using IPv4 literals or non-
IPv6 compliant APIs?

c. IPv4-only: Are there hosts or applications using IPv4-only?

d. Foreign DNS: Is the scenario surviving if the user, Operating

Palet Martinez Expires November 5, 2019 [Page 16]
Internet-Draft NAT64/464XLAT Deployment May 2019

Internet-Draft HMAC-SHA-2_Auth_USM_new January 2016

Manfred Lochter
BSI
Postfach 200363
53133 Bonn
Germany

Phone: +49 228 9582 5643
EMail: manfred.lochter@bsi.bund.de

Merkle & Lochter Expires July 29, 2016 [Page 14]

HMAC-SHA-2 Authentication Protocols in USM for SNMPv3 draft-ietf-opsawg-hmac-sha-2-usm-snmp-new-03

HMAC-SHA-2 Authentication Protocols in USM for SNMPv3
draft-ietf-opsawg-hmac-sha-2-usm-snmp-new-03