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.
Cheers, Manav > -----Original Message----- > From: Danny Mayer [mailto:[email protected]] > Sent: Tuesday, December 13, 2011 9:49 AM > To: Bhatia, Manav (Manav) > Cc: David L. Mills; [email protected]; [email protected] > Subject: Re: [TICTOC] [ntpwg] NTP Extension Field without > Authentication > > 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
