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
