On 12/12/2011 11:23 PM, 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. Danny > > 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
