HMAC-SHA-2 Authentication Protocols in the User-based Security Model (USM) for SNMPv3
Note: This ballot was opened for revision 06 and is now closed.Search Mailarchive
(Stephen Farrell) (was Discuss) Yes
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.
(Joel Jaeggli) Yes
Kathleen Moriarty Yes
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.
(Jari Arkko) No Objection
Alia Atlas No Objection
Deborah Brungard No Objection
Ben Campbell No Objection
Benoit Claise No Objection
Editorial: - OLD: ORGANIZATION "SNMPv3 Working Group" NEW: ORGANIZATION "OPSAWG Working Group" - The copyright within the MIB should be 2015