I am confused by your choice of names. The text uses, e.g.,
usmHMACSHA224128AuthProtocol
whereas the MIB module has
usmHmacSha224128Protocol
Do these refer to the same identity (times six)?
I think that the IANA Considerations needs more work; you might want to
review RFC4181 for a more detailed approach but you need at least
something along the lines of an explicit request that the MIB module be
assigned a number under the appropriate tree, eg
.1 IANA is requested to assign an object identifier for
Descriptor OBJECT IDENTIFIER value
---------- -----------------------
snmpUsmHmacSha2MIB { snmpModules XXX }
[with XXX harking back to the same string in the MIB module itself].
And then for each algorithm, so that the entries in IANA can be tied
into the text of the final RFC,
.2 IANA is requested to assign a value in the SnmpAuthProtocols registry
for each of
Value Description Reference
aa usmHMACSHA224128AuthProtocol RFC YYYY
bb usmHMACSHA256128AuthProtocol RFC YYYY
cc usmHMACSHA256192AuthProtocol RFC YYYY
dd usmHMACSHA384256AuthProtocol RFC YYYY
ee usmHMACSHA512256AuthProtocol RFC YYYY
ff usmHMACSHA512384AuthProtocol RFC YYYY
-- RFC Ed.: replace YYYY with actual RFC number & remove this line
with aa bb cc etc appearing in the MIB Module. As it stands, you might
appear to be requesting that all six get the same value, namely mm.
And then there are Security Considerations. You are replacing a simple,
well understood choice of two values with a choice of eight, and saying
that there is no need to implement them all. This gives great scope for
a lack of interoperability. Should there be a mandatory to implement
value (or negotiation - perhaps not)?
I would like to see some discussion of the benefits, if any, of the six
new options. I have seen discussions along these lines on the TLS WG
list (with a considerable degree of expertise in cryptography present)
that makes it far from clear cut what the best choice is, and that what
appears to be the strongest may not be a good choice for IETF protocols.
Tom Petch
----- Original Message -----
From: "Johannes Merkle" <[email protected]>
To: <[email protected]>
Cc: "Manfred Lochter" <[email protected]>; <[email protected]>
Sent: Monday, March 24, 2014 12:35 PM
Subject: [OPSAWG] Fwd: New Version Notification
fordraft-hmac-sha-2-usm-snmp-00.txt
> Dear all,
>
> a while ago, I had announced a draft on a new USM authentication
protocol HMAC-SHA-256-128 for use in SNMP. Following
> Uri's suggestion (and with his valuable support) I have considerably
extended the draft:
> - Further SHA-2 based HMAC authentication protocols have been
included to provide ore flexibility.
> - A (short) section explains how to perform key change and key
localization with these protocols
> - A MIB definition has been added.
>
> URL:
http://www.ietf.org/internet-drafts/draft-hmac-sha-2-usm-snmp-00.txt
> Status:
https://datatracker.ietf.org/doc/draft-hmac-sha-2-usm-snmp/
> Htmlized:
http://tools.ietf.org/html/draft-hmac-sha-2-usm-snmp-00
>
>
> Abstract:
> This memo specifies new optional HMAC-SHA-2 authentication
protocols
> for the User-based Security Model (USM) for SNMPv3 defined in RFC
> 3414.
>
>
> Due to the extension of the draft to other SHA-2-based HMAC, I have
changed the draft name from
> draft-hmac-sha-256-128-usm-snmp
> to
> draft-hmac-sha-2-usm-snmp
> resulting in a reset of the version number (00).
>
> Is there interest in adoption of this draft by the WG?
>
> Johannes
>
>
> _______________________________________________
> OPSAWG mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/opsawg
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
