On 12/12/2011 9:50 PM, Bhatia, Manav (Manav) wrote: > Hi Danny, > > I had raised a similar point way back in 2008 that we cant assume that the > MAC in NTP will always be just 16 bytes. >
It already isn't. The reference implementation supports both MD5 and SHA-1 with different MAC sizes. The reference implementation assumes one or the other depending on the size and that is obviously not sustainable. Danny > http://lists.ntp.org/pipermail/ntpwg/2008-December/001435.html > > Cheers, Manav > >> -----Original Message----- >> From: [email protected] >> [mailto:[email protected]] On Behalf Of Danny Mayer >> Sent: Tuesday, December 13, 2011 7:07 AM >> To: David L. Mills >> Cc: [email protected]; [email protected] >> Subject: Re: [TICTOC] [ntpwg] NTP Extension Field without >> Authentication >> >> Dave, >> >> You are talking about the current specification. Tal is >> talking about changing the specification. >> >> I see no reason why it cannot be done, provided we can find a >> way for it to be specified in a backward compatible way. The >> real question is whether or not it should be made optional. >> The parsing rules can always be changed, not necessarily >> easily, but it can be done. >> >> RFC 5906 (autokey) should require it whatever is decided. >> >> Can you remind everyone why we might like to make it not >> mandatory? Also we need to have a MAC can we specify the >> algorithm/size for the MAC since we shouldn't make >> assumptions about this as has been done so far. >> >> Danny >> >> On 12/12/2011 1:53 PM, David L. Mills wrote: >>> Tai, >>> >>> All I can say is read my message again. Doing without the MAC is a >>> very special case and unintended by the specification. >>> >>> Dave >>> >>> Tal Mizrahi wrote: >>>> >>>> Hi Dave, >>>> >>>> >>>> >>>> So you are saying that according to the current spec it is >> possible >>>> in some configurations to have an extension field without the >>>> existence of a MAC? >>>> >>>> >>>> >>>> Tal. >>>> >>>> >>>> >>>> *From:*David L. Mills [mailto:[email protected]] >>>> *Sent:* Monday, December 12, 2011 6:01 AM >>>> *To:* Tal Mizrahi >>>> *Cc:* [email protected]; [email protected] >>>> *Subject:* Re: [ntpwg] [TICTOC] NTP Extension Field without >>>> Authentication >>>> >>>> >>>> >>>> Tal , >>>> >>>> It's a little more complicated than it seems. The parsing rules >>>> assume that a message digest is always present if an >> extension field >>>> is present. The NT$ packet header, extension fields and MAC are >>>> multiples of 32-bit words. The minimum MAC length is 5 words and >>>> maximum length is 6 words. The minimum extension field length is 2 >>>> words. If the remaining number of words during the parse >> is less than >>>> 7, the remainder is the MAC. If not, an extension field is >> present. >>>> The parser updates the parser pointer folloowing the >> extension field >>>> and tries again. >>>> >>>> Thus, if there are at least 7 words remaining and the >> extension field >>>> eats up all those words, the MAC could be assumed absent . >> This is a >>>> rather hokey design, but would in principle work. >>>> >>>> Dave >>>> >>>> Tal Mizrahi wrote: >>>> >>>> Hi, >>>> >>>> >>>> >>>> Revisiting an issue that was raised a few months ago and >> is yet to be >>>> resolved: >>>> >>>> RFC 5905 defines an extension field. The RFC states that a >> MAC must >>>> be present when there is an extension field. >>>> >>>> >>>> >>>> Obviously, it would be beneficial for various purposes to allow >>>> Extension Fields independent of whether the MAC is present. >>>> >>>> >>>> >>>> Some people thought this is a mistake in the spec, and >> that it should >>>> be included in the errata. Others thought that Extension Fields >>>> without MAC are something new that needs to be defined in >> a new document. >>>> >>>> This was discussed in IETF 81, and then revisited in the ad-hoc >>>> meeting in October, but no conclusion was reached. >>>> >>>> >>>> >>>> It would be great to hear the opinion of the WG and the >> chairs about >>>> how to proceed with this. >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Tal. >> ------------------------------------------------------------------ >> _______________________________________________ >> TICTOC mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/tictoc >> _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
