HMAC-SHA-2 Authentication Protocols in the User-based Security Model (USM) for SNMPv3
draft-ietf-opsawg-hmac-sha-2-usm-snmp-06

[Ballot comment]

I'm a yes on this, but am still holding my nose:-)

The yes is because it's a fine thing to make sure that up-to-date
options for securing protocols are available.

The nose-holding is because defining multiple options that
aren't significantly different in strength (if one assumes that
key management is the likely weakest link) is a bad plan.

In case it helps, my main logic for not wanting all these
options is that it is overwhelmingly more likely that the
code to switch between them or react to which you've received
or to configure things will (due to bugs etc.) weaken
security much much much more than the existence of more
than one of these options could ever strengthen security.
(Put another way the probability of a security bug due
to adding N things here is far far higher than the
probability that having N things saves the day when N-1
of them are no longer considered good crypto at some
point.)

So by defining more of these you are doing worse than
if you only defined one of these. (The fact that all sha2
digests have the same internal structure is part of but
not all of this argument.)

On truncation, I'd argue that if that was a significant
benefit then it'd be used everywhere and it is not. In
fact I don't believe truncation is used anywhere else
when there's no protocol (e.g. PDU/fragmentation) issue
that causes us to want shorter MACs.

I also believe that even those who for truncation would
agree that the benefit of reasonable-length truncation is
definitely an insignificant benefit, if any, and would
also agree that that's a matter of taste when it comes
to sha2 variants of hmac (assuming the protocol can live
with full length, as in this case).

Bottom line: Discuss is cleared and I'm out of the way, but
with a heartfelt plea that you ditch all of these but one. And
then ditch truncation too. And so end up with just adding
hmac-sha2 as many other protocols have done.

[Ballot discuss]

Thanks for defining these. I do have a thing do briefly
discuss before balloting yes. I'll be getting out of your way
very shortly, but I want to check first to see if you agree
with me that this could be simpler and more useful.

I note the following:

- You're defining a bunch of HMAC options.
- Additional options for fun isn't a good idea with crypto.
- There may be platforms that do not have good APIs for
  SHA224 or SHA384.
- HMAC-SHA256 without any truncation is considered perfectly
  fine for this purpose and is widely used elsewhere.
- You don't need truncation for protocol reasons.

To me, that implies that this would be better if it *only*
defined a non-truncated HMAC-SHA256 option and if all of the
rest were removed.

Do you agree that doing so would achieve just as much of a
security improvement, but with less complexity for
implementation, test and interop? If so, should we just do
that?

[Ballot comment]
Editorial:

- OLD:      ORGANIZATION    "SNMPv3 Working Group"
NEW:      ORGANIZATION    "OPSAWG Working Group"

- The copyright within the MIB should be 2015

[Ballot comment]
Thanks for your work on this draft!  It's great to see the improvements in security.

This is just a comment and not critical at all… I found this sentence at the bottom of the second bullet of 4.1 a little odd:
      as opposed to the truncation to 12 octets in HMAC-MD5-96 and HMAC-
      SHA-96.

Since the guideline is to truncate the size in half and have 80 or more bits for a HMAC, you are covered and already cite the appropriate RFCs.  Is this there just for history of previous solutions?  Or would it be better to just state the guidance so folks understand why you chose the truncation size?  You can do nothing with my comment, it's just a question as the text had me curious.  And I see that you have included the HMAC truncation guidance in the security considerations section already.

IESG/Authors/WG Chairs:

IANA has reviewed [draft-enter-here].  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

IANA has a question about one of the actions requested in the IANA Considerations section of this document.

Upon approval of this document, IANA understands that there are two actions which must be completed.

First, in the SMI Network Management MGMT Codes Internet-standard MIBsubregistry
of the Network Management Parameters registry located at:

http://www.iana.org/assignments/smi-numbers

a new MIB will be registered as follows:

IANA Question --> What is the description for the registration below?

Decimal: [ TBD by IANA at time of registration ]
Name: snmpUsmHmacSha2MIB
Description: [ TBD-based-on-question-above ]
References: [ RFC-to-be ]

Second, in the SnmpAuthProtocols subregistry of the Simple Network Management Protocol (SNMP) Number Spaces registry located at:

http://www.iana.org/assignments/snmp-number-spaces/

four new registrations will be made as follows:

Value: Description: Reference:
-------------------------------------------------------------------
[ TBD-at-regisitration ] usmHMAC128SHA224AuthProtocol [ RFC-to-be ]
[ TBD-at-regisitration ] usmHMAC192SHA256AuthProtocol [ RFC-to-be ]
[ TBD-at-regisitration ] usmHMAC256SHA384AuthProtocol [ RFC-to-be ]
[ TBD-at-regisitration ] usmHMAC384SHA512AuthProtocol [ RFC-to-be ]

IANA understands that these two actions are the only ones required upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 

Please note that IANA cannot reserve specific values. However, early allocation is available for some types of registrations. For more information, please see RFC 7120.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (HMAC-SHA-2 Authentication Protocols in USM for SNMP) to Proposed Standard


The IESG has received a request from the Operations and Management Area
Working Group WG (opsawg) to consider the following document:
- 'HMAC-SHA-2 Authentication Protocols in USM for SNMP'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-04-20. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


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




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-opsawg-hmac-sha-2-usm-snmp/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-opsawg-hmac-sha-2-usm-snmp/ballot/


No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested:
Standards Track - this document
request an assignment from the SnmpAuthProtocols registry
(http://www.iana.org/assignments/snmp-number-spaces/snmp-number-spaces.xhtml#snmp-number-spaces-5)
which requires a Standards Track document.


(2) Technical Summary:

This memo specifies new HMAC-SHA-2 authentication protocols for USM using an
HMAC based on the SHA-2 family of hash functions. They are straightforward
adaptations of the authentication protocols HMAC-MD5-96 and HMAC-SHA-96 to the
SHA-2 based HMAC.

Working Group Summary:

During the adoption call we discovered that there was another document
(https://datatracker.ietf.org/doc/draft-hartman-snmp-sha2/) which did
something very similar. This document had been written earlier, but neither
the document authors, nor most of the OpsAWG WG was aware of it. The CfA
stalled for a long time while we asked the WG to decide which option they
proffered, and to see if there was a clean way to combine the two
documents. In the end, the authors of hartman-snmp-sha2 agreed that this
document (hmac-sha-2-usm-snmp) should progress.


Document Quality:

The document is well written and clear.  David Reid (at least) has implemented
this ("We have also implemented it (using private OIDs for now).")

Personnel:

Warren Kumari will be the document shepherd. Joel Jaeggli will be the AD.

(3) The DS is also the chair of the WG. He followed the document during its
lifetime.

(4) Does the document Shepherd have any concerns about the depth or breadth of
the reviews that have been performed?
Nope. The right set of people reviewed
the document. We got sufficient review during the WGLC, but also got lots of
review during the CfA. What the document is an important maintenance activity,
not new protocol design.


(5) Do portions of the document need review from a particular or from broader
perspective:
Nope.



(6) Describe any specific concerns or issues:
None

(7) Has each author confirmed that any and all appropriate IPR disclosures
required for full conformance with the provisions of BCP 78 and BCP 79 have
already been filed.
Yes.


(8) Has an IPR disclosure been filed that references this document?
Nope.

(9) How solid is the WG consensus behind this document?
Good consensus. See Answer 4.


(10) Has anyone threatened an appeal?
Nope.


(11) Identify any ID nits the Document Shepherd has found in this
document.
None!


(12) Describe how the document meets any required formal review criteria:
The document shepherd
extracted the MIB and then ran (online) MIB tests, at maximum strictness
levels. After making some fixups (e.g: replacing 'aa' (to be assigned by IANA)
with numbers) it linted fine.  Michael MacFaden also checked it and found it
clean.



(13) Have all references within this document been identified as either
normative or informative?
Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state?
No.

(15) Are there downward normative references references (see RFC 3967)?

** YES **

Normative reference to an Informational RFC 2104 Non-RFC normative reference
'SHA' Normative reference to an Informational RFC 6234

RFC 2104 and RFC 6234 are in the downregreg (which is currently throwing 500
Errors) SHA references: National Institute of Standards and Technology,
"Secure Hash Standard (SHS)", FIPS PUB 180-4, March 2012. Note that RFC2014
and RFC6234 also reference versions of this document.

(16) Will publication of this document change the status of any existing RFCs?
Nope.

(17) Describe the review of the IANA considerations section.
The IANA registry section is clear, and matches up with the requests
in the document.

(18) Any new IANA registries?
None.

(19) Describe reviews and automated checks performed by the Document
Shepherd.
Shepherd ran online MIB checker at max strictness.
Michael MacFaden and Juergen Schoenwaelder also checked.
The MIB checker threw some errors, but these were
all for things like '{ snmpAuthProtocols dd } -- dd to be assigned by
IANA'. Replacing these with numbers made things happy.