Hi, Dave, So, if ntpd detects the algorithm not by checking the digest size, then it is easier to make some extension on MAC size. We could have more scalability and agility. Am I right?
Cheers, Yang >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
