Hi Dave, I agree. Inspite of this we need to work on a generic mechanism because best operational practices might start deprecating MD5 and SHA1, and recommend some other authentication algo to be used in the future. Moreover, detecting auth algo based on the packet size is absurd because people use truncated hashes all the time. One could truncate a HMAC-SHA-256 digest to 20 bytes (or even 16). Thus even if there is no burning need today, we should start working on defining a generic way to secure NTP packets going forward.
Cheers, Manna ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Dave Hart Sent: Wednesday, December 14, 2011 8:40 AM To: John Smith Cc: [email protected]; [email protected]; David L. Mills Subject: Re: [TICTOC] [ntpwg] NTP Extension Field without Authentication What Dr. Mills suggests is if you can't MITM NTP exchanges secured by 20-octet digests, there is no need for a larger digest. This is why he harkens back to the discussion of MD5 flaws and how they might be exploited in the context of NTP authentication. NTP has the advantage of time -- the MITM has to not only find a correct digest for the modified packet, he must do so fast enough that the client will not find reason to ignore the response. There is no doubt it is ugly that there are two different ad-hoc extensions to the basic NTPv4 packet defined, both detected solely by the received datagram size, and unfortunate that means extensions must be at least 7 x 32 bits long to avoid ambiguity. One might hope any NTPv5 would include indication in the basic packet headers of whether authentication and/or extensions are used in a way that avoids such ambiguity. Cheers, Dave Hart On Tue, Dec 13, 2011 at 20:45, John Smith <[email protected]<mailto:[email protected]>> wrote: Dave, I think the discussion is not as much as whether SHA is secure enough or not but rather whether the current design of inferring the auth algo based on the length scalable or not? At some point of time we have to allow NTP to use an auth algo that has a digest size > 16 or 20 bytes. What needs to be done to get us to that stage is what folks would like to hear. John ________________________________ From: David L. Mills <[email protected]<mailto:[email protected]>> To: Danny Mayer <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>; "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Sent: Tuesday, 13 December 2011, 22:09 Subject: Re: [ntpwg] [TICTOC] NTP Extension Field without Authentication Danny, I don't know where this is going. I mentioned some constraints in my recent message. I have no agenda for the spec; if it can be warped for some goal or other, that's fine. However, the parsing design assumes the packet format checks are independent of the contents of the extension field. That doesn't leave much latitude for MACs longer than 6 words. Apparently, we are having the same discussion about the vulnerability of the SHA family as we had with MD5. The issue id whether we can concoct an NTP header that has correct digest but altered header fields that are acceptable to the client. That is a tall order, as I discussed in the NTP Security Analysis cited earlier. Dave Danny Mayer wrote: On 12/13/2011 12:33 AM, Bhatia, Manav (Manav) wrote: Ok, let me put it this way. I was trying to propose extending NTP to support having an arbitrary MAC size. I was also trying to push HMAC-SHA-1, instead of the regular SHA-1. That's one possibility. Another is SHA-2. That's why we need to revisit the question. Security vulnerabilities found in SHA-1 and SHA-2 don't apply to HMAC-SHA-1 and HMAC-SHA-2. I understand that the known attacks on SHA-1 and SHA-2 will not apply to NTP (like most IETF protocols) but that doesn't mean that we should go ahead using them. The security ADs I believe are insistent on the HMAC construct to be used. To cite an example, Bidirectional Forwarding Detection (BFD) protocol already supports SHA-1. It is however being upgraded to support the HMAC version of the SHA algorithms. I thus don't recommend going ahead with SHA-2. Sorry, I managed to miscommunicate what I meant. If HMAC is what is needed to be used then we should use it. I just threw out SHA-2 as an example. It wasn't meant as a specific recommendation. There are several parts to the requirements about the MAC: 1) Signalling by the sender what algorithm to use for the MAC in the packet; 2) Signalling by the requestor what algorithms it can accept since the two ends may have support for different algorithms. 3) What to do in the case where there is no algorithm in common. Danny Cheers, Manav _______________________________________________ ntpwg mailing list [email protected]<mailto:[email protected]> http://lists.ntp.org/listinfo/ntpwg _______________________________________________ TICTOC mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/tictoc
_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
