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
