>That's one possibility. Another is SHA-2. That's why we need to revisit >the question. > >Danny
SHA-2 doesn't change much from SHA-1, if only two choices available, HMAC-SHA-1 is better than SHA-2, IMHO. Also don't forget that SHA-3 is coming. I agree with Manav that an arbitrary size of MAC is preferable. Yang -- Yang Cui Huawei Technologies [email protected] -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Tuesday, December 13, 2011 12:49 PM To: [email protected] Subject: TICTOC Digest, Vol 61, Issue 23 If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to https://www.ietf.org/mailman/listinfo/tictoc Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME. You can set this option globally for all the list digests you receive at this point. Send TICTOC mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/tictoc or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of TICTOC digest..." Today's Topics: 1. Re: [ntpwg] NTP Extension Field without Authentication (Danny Mayer) ---------------------------------------------------------------------- Message: 1 Date: Mon, 12 Dec 2011 23:48:29 -0500 From: Danny Mayer <[email protected]> To: "Bhatia, Manav (Manav)" <[email protected]> Cc: "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "David L. Mills" <[email protected]> Subject: Re: [TICTOC] [ntpwg] NTP Extension Field without Authentication Message-ID: <[email protected]> Content-Type: text/plain; charset=ISO-8859-1 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 End of TICTOC Digest, Vol 61, Issue 23 ************************************** _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
