Again you seem to be ignoring the point that a generic policy to avoid MD5, or SHA1, is probably not applicable to NTP's use of those algorithms. Fine, I'm not going to beat that drum anymore.
You are mistaken in assuming ntpd detects the algorithm based on the digest size. The algorithm is configured into both sides and not communicated on the wire at all for symmetric authed NTP. Cheers, Dave Hart On Wed, Dec 14, 2011 at 04:52, Bhatia, Manav (Manav) < [email protected]> wrote: > ** > 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]>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]> >> *To:* Danny Mayer <[email protected]> >> *Cc:* "[email protected]" <[email protected]>; "[email protected]" < >> [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] >> http://lists.ntp.org/listinfo/ntpwg >> >> >> _______________________________________________ >> TICTOC mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/tictoc >> >> >
_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
