Right! On the names, I am happy with whatever you choose, as long as the I-D is internally consistent! The existing one is usmHMACSHAAuthProtocol so that looks like a good model to follow, which Uri's suggestion does.
As to how many, I am uncomfortable with giving implementers the choice of eight along with the statement that you do not have to implement them all, which, for me, invites a lack of interoperability, regardless of whether or not the crypto libraries have all the options available so making them easy to implement! So my thinking would be either a MUST implement for one, or recommend that all should be implemented, with a recommended order to choose, or some such - just not the current wording. As to MUST, this I-D will have to be Standards Track, not Informational, in order to update SnmpAuthProtocols so the use of requirements language, and the boiler plate thereon, is not an issue. On Security, I have memories of discussions on the TLS list of the merits of size and truncation. One reference I have found is 'SHA-1 is being deprecated' from 2008 from one 'Uri' - so I think something along those lines worth including by way of justification for this I-D (Suite B got a lot of mentions around that time). I have memories of an argument against the use of SHA-512, I think on the grounds that the registers were not wide enough and that the extra security did not justify the extra computation required, but cannot find a reference for that. As to degree of truncation, I understand the argument in principle but do not have the mathematics to take a view as to what is best. I do note that in 2006, it was suggested that the merit of truncation was to save bandwidth in constrained environments - I don't know if that is now more or less applicable. So I would like to see more in the Security Considerations along these lines with a target audience of non-cryptographers. Tom Petch ----- Original Message ----- From: "Johannes Merkle" <[email protected]> To: "Blumenthal, Uri - 0558 - MITLL" <[email protected]>; "t.petch" <[email protected]>; <[email protected]> Cc: "Manfred Lochter" <[email protected]> Sent: Tuesday, March 25, 2014 6:03 PM > > Blumenthal, Uri - 0558 - MITLL schrieb am 25.03.2014 16:52: > > 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)? > > Good catch! > > > > > I think yes, and would suggest the following (unified) name format: > > > > usmHMAC128SHA224AuthProtocol > > I like this proposal, because it is easier to read. > > > >> 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. :-) > > Yeah, I'll take care of this. > > > > >> 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? > > AFAIK this is common. > > > 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 had already received very positive feedback on the first draft (which specified merely usmHMAC128SHA256AuthProtocol), > .e.g. > > > Thus, I have no clear preference here, but Uri's proposal is fine for me. > > > > >> 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? > > All versions use truncated HMAC, the difference lies in the degree of truncation. You probably mean "do we select the > variants using 50% truncation or those with 75% truncation?" > > I don't think that interoperability is really a big issue. Crypto libraries typically support most, if not all SHA-2 > hash functions. Futhermore, implementing two different lengths for truncation is trivial. Thus, I do not see why anyone > should implement usmHMAC384SHA512AuthProtocol but not usmHMAC256SHA512AuthProtocol. > > But, yes, if required for WG consensus, I do not object to remove some variants. > > > > > If it's the second - I'll let others speak. :-) > > > > From Tom's responses to our first draft, I understand that he does not question that SHA2 based HMAC authentication is > useful. > > > > >> 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. > > > > I think Tom is referring to the discussion regarding MAC truncation, which was a sideline of the discussion about the > optimal order of encryption and MAC in TLS. > http://web.archiveorange.com/archive/v/aFZ9KRJi4JLUvLRo8Ek7 > http://web.archiveorange.com/archive/v/aFZ9KQVpfdL7WYG1B9l7 > > The second thread cites Bart Preneel saying > "On the other hand, several (key recovery) > attacks on MAC algorithms (including HMAC-MD4 and HMAC-MD5) > have been found based on internal collisions. These attacks > would become more difficult if fewer output bits are available. > [...] > My conclusion is that my intuition as cryptanalyst was correct > and that it would be best to shorten the output of a MAC > algorithm to half the internal state." > This recommendation is also included in the seminal paper of van Oorschot and Preneel (page 11) > ftp://ftp.esat.kuleuven.ac.be/cosic/preneel/mdxmac_crypto95.ps.gz > For the SHA-2 family, the length of the internal state is 256 bits for SHA-224 and SHA-256 and 512 bits for SHA-384 and > SHA-512 (recall that SHA-224 and SHA-384 are truncated SHA-225 and SHA-512, respectively, with modified constants). This > recommendation results in HMAC128SHA224, HMAC128SHA256, HMAC256SHA384, HMAC256SHA512. > > On the other hand, shortening the output length reduces the strength against collision attacks. Thus, we were not > completely comfortable with the 50% truncation for SHA-256 and SHA-512. On the other hand, AFAIK, there are no clear > cryptanalytic results about truncation, let alone on the optimal degree of truncation. For this reason, we also included > HMAC192SHA256 and HMAC384SHA512. > > -- > Johannes _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
