Of course I forgot to ask the question: Is anyone using the extension fields for anything outside of Autokey?
Danny On 12/12/2011 8:36 PM, Danny Mayer wrote: > 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
