On 3/25/14 11:33 , "t.petch" <[email protected]> wrote: >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 yes, and would suggest the following (unified) name format: usmHMAC128SHA224AuthProtocol for all of them. >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, e.g.,.............. I'll leave this to Johannes to take care of. :-) >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)? Can we have mandatory-to-implement in an "optional" RFC? Assuming the answer is yes, I'd recommend: For those who implement this RFC, usmHMAC192SHA256AuthProtocol is MUST, usmHMAC384SHA512AuthProtocol is SHOULD, everything else is MAY. Unless there's a preference for the "non-truncated" algorithms. >I would like to see some discussion of the benefits, if any, of the six >new options. Do you mean "the benefits of having so many rather than just one or two", or do you mean "the benefits of adding SHA2-based auth"? If it's the first - then we probably can shrink the number of the available choices. The question is - do we select truncated ones (as the prior standards did), or not? If it's the second - I'll let others speak. :-) >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. Honestly I don't think TLS WG is a good example here, considering the complexity of the protocol, and the kind of problems they're facing and are trying to address. But your point is taken. TNX! >----- 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 >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
