Subject: Re: [TICTOC] TICTOC Digest, Vol 61, Issue 23

From: Cui Yang <[email-masked]>
Date: Tue, 13 Dec 2011 05:13:49 +0000

>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-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, December 13, 2011 12:49 PM
To: [email-masked]
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-masked]

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-masked]

You can reach the person managing the list at
	[email-masked]

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-masked]>
To: "Bhatia, Manav (Manav)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>,	"[email-masked]"
	<[email-masked]>, "David L. Mills" <[email-masked]>
Subject: Re: [TICTOC] [ntpwg]   NTP Extension Field without
	Authentication
Message-ID: <[email-masked]>
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-masked]] 
>> Sent: Tuesday, December 13, 2011 9:49 AM
>> To: Bhatia, Manav (Manav)
>> Cc: David L. Mills; [email-masked]; [email-masked]
>> 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-masked]
>>>> [mailto:[email-masked]] On Behalf Of Danny Mayer
>>>> Sent: Tuesday, December 13, 2011 7:07 AM
>>>> To: David L. Mills
>>>> Cc: [email-masked]; [email-masked]
>>>> 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-masked]]
>>>>>> *Sent:* Monday, December 12, 2011 6:01 AM
>>>>>> *To:* Tal Mizrahi
>>>>>> *Cc:* [email-masked]; [email-masked]
>>>>>> *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-masked]
https://www.ietf.org/mailman/listinfo/tictoc

End of TICTOC Digest, Vol 61, Issue 23
**************************************

---

From: Danny Mayer <[email-masked]>
Date: Tue, 13 Dec 2011 08:16:27 -0500

Please don't respond to a digest message without fixing the Subject line
to be the subject being responded to.

I threw out SHA-2 as an example of what you might want to use. It was
not meant as a recommendation. Manav's message indicated that HMAC style
of these algorithms are better. Part of what we change in the protocol
would need to include a list of preferred algorithms, how to indicate
what they are (would require an IANA registry) and how to choose which
one(s) to use and which should not be used.

Danny

---

From: Cui Yang <[email-masked]>
Date: Wed, 14 Dec 2011 08:13:43 +0000

>to be the subject being responded to.
Thanks for the kindly reminding.

>one(s) to use and which should not be used.
I see. Thanks for explaining to us.
My point there is that SHA-2 bears many similar designing principles with SHA-1, so that it looks a little bit unnatural to list up SHA-2 when we are leaving SHA-1, from a crypto point of view. And that is probably the one of motivations for NIST to design SHA-3, IMO.

Cheers,
Yang
--
  Yang Cui
  Huawei Technologies
  [email-masked]

-----Original Message-----
From: Danny Mayer [mailto:[email-masked]] 
Sent: Tuesday, December 13, 2011 9:16 PM
To: Cui Yang
Cc: [email-masked]; NTP Working Group; David L. Mills
Subject: Re: [ntpwg] NTP Extension Field without Authentication

Danny