Subject: [TICTOC] [ntpwg] NTP Extension Field without Authentication

From: Tal Mizrahi <[email-masked]>
Date: Sun, 11 Dec 2011 17:30:00 +0200

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.

---

From: "David L. Mills" <[email-masked]>
Date: Mon, 12 Dec 2011 04:00:39 +0000

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:

> 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.
>
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>ntpwg mailing list
>[email-masked]
>http://lists.ntp.org/listinfo/ntpwg
>

---

From: Tal Mizrahi <[email-masked]>
Date: Mon, 12 Dec 2011 09:44:32 +0200

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,

Thanks,
Tal.

________________________________

ntpwg mailing list

[email-masked]<mailto:[email-masked]>

---

From: "David L. Mills" <[email-masked]>
Date: Mon, 12 Dec 2011 18:53:25 +0000

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.
>
>  
>
> 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.
>
>[email-masked] <mailto:[email-masked]>
>

---

From: Danny Mayer <[email-masked]>
Date: Mon, 12 Dec 2011 20:36:46 -0500

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:
>> *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 ,
>>
------------------------------------------------------------------

---

From: Danny Mayer <[email-masked]>
Date: Mon, 12 Dec 2011 21:01:05 -0500

Of course I forgot to ask the question: Is anyone using the extension
fields for anything outside of Autokey?

Danny

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 13 Dec 2011 08:20:41 +0530

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.

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
> 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.
> 
> 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
> 
> > 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.
> >>
> >>  
> >>
> >> 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.
> >>
> >> 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.
> >>
> >>  
> >>
> >> 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
>

---

From: Danny Mayer <[email-masked]>
Date: Mon, 12 Dec 2011 23:18:48 -0500

> 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

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 13 Dec 2011 09:53:23 +0530

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.

Cheers, Manav

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

---

From: Danny Mayer <[email-masked]>
Date: Mon, 12 Dec 2011 23:48:29 -0500

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

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 13 Dec 2011 11:03:42 +0530

> 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.

Security vulnerabilities found in SHA-1 and SHA-2 don't apply to HMAC-SHA-1 and HMAC-SHA-2. I understand that the known attacks on SHA-1 and SHA-2 will not apply to NTP (like most IETF protocols) but that doesn't mean that we should go ahead using them. The security ADs I believe are insistent on the HMAC construct to be used. To cite an example, Bidirectional Forwarding Detection (BFD) protocol already supports SHA-1. It is however being upgraded to support the HMAC version of the SHA algorithms. I thus don't recommend going ahead with SHA-2.

Cheers, Manav

---

From: Danny Mayer <[email-masked]>
Date: Tue, 13 Dec 2011 07:53:12 -0500

On 12/13/2011 12:33 AM, Bhatia, Manav (Manav) wrote:
> Security vulnerabilities found in SHA-1 and SHA-2 don't apply to
HMAC-SHA-1 and HMAC-SHA-2. I understand that the known attacks on SHA-1
and SHA-2 will not apply to NTP (like most IETF protocols) but that
doesn't mean that we should go ahead using them. The security ADs I
believe are insistent on the HMAC construct to be used. To cite an
example, Bidirectional Forwarding Detection (BFD) protocol already
supports SHA-1. It is however being upgraded to support the HMAC version
of the SHA algorithms. I thus don't recommend going ahead with SHA-2.

Sorry, I managed to miscommunicate what I meant. If HMAC is what is
needed to be used then we should use it. I just threw out SHA-2 as an
example. It wasn't meant as a specific recommendation. There are several
parts to the requirements about the MAC:

1) Signalling by the sender what algorithm to use for the MAC in the packet;
2) Signalling by the requestor what algorithms it can accept since the
two ends may have support for different algorithms.
3) What to do in the case where there is no algorithm in common.

Danny

---

From: Brian Utterback <[email-masked]>
Date: Tue, 13 Dec 2011 09:06:58 -0500

Dave, in a email message to the ntpwg list on July 14, you wrote to Todd 
Glassey and said:

"A careful read of the specification should give you comfort that the 
parsing rules do distinguish between an extension field and a MAC. In 
particular, the rules permit one or more extension fields without a MAC. 
The only requirement is that a MAC, if present, must be the last field."

Which is it?

Personally, I would love for the extension field to be independent of 
the MAC field.

On 12/12/11 13:53, David L. Mills wrote:
>> So you are saying that according to the current spec it is possible 
>> assume that a message digest is always present if an extension field 
>> 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.
>>
>> RFC 5905 defines an extension field. The RFC states that a MAC must 

-- 
blu

Always code as if the guy who ends up maintaining your code will be a
violent psychopath who knows where you live. - Martin Golding
-----------------------------------------------------------------------|
Brian Utterback - Solaris RPE, Oracle Corporation.
Ph:603-262-3916, Em:[email-masked]

---

From: todd glassey <[email-masked]>
Date: Tue, 13 Dec 2011 08:30:10 -0800

On 12/13/2011 6:06 AM, Brian Utterback wrote:
> Dave, in a email message to the ntpwg list on July 14, you wrote to 
> Todd Glassey and said:
>
> particular, the rules permit one or more extension fields without a 
> MAC. The only requirement is that a MAC, if present, must be the last 
> field."

Speaking of which Dave I also took your suggestion and our new Patent 
Applied For version of NTP (which also serves PTP too) last Sunday and 
its now on file with US PTO...  he he he - as is the GPUniverse 
application for the Trillion-+ timestamp server... (filed a week 
earlier) oh and I forgot to mention just because Dave and I slap each 
other around once in a while for fun doesnt mean we don't respect or 
admire each others work. Dave is a Research Timekeeper (as is much of 
this list)  - I am a Production Timekeeper and tis a very different 
world therein.

So folks - we will be looking for parties who want to test this new 
system and will of course make them available to USNO and NIST T&F for 
review as well per our discussion with USNO last week in DC. For those 
of you with commercial systems - you are seriously going to want this 
new secured system since it can be used to create a reference clock 
system which can replace the SYSLOG or OS Logging model as the 
repository of the timestamps - that's right, its fast enough to allow 
application level access to the reference clock system at  HOST OS Event 
speeds.

Booya!

Todd
>>> 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,
>>>
>>> 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.
>>>

-- 
Todd S. Glassey
This is from my personal email account and any materials from this account come with personal disclaimers.

Further I OPT OUT of any and all commercial emailings.

---

From: "David L. Mills" <[email-masked]>
Date: Tue, 13 Dec 2011 16:39:58 +0000

Danny,

I don't know where this is going. I mentioned some constraints in my 
recent message. I have no agenda for the spec; if it can be warped for 
some goal or other, that's fine. However, the parsing design assumes the 
packet format checks are independent of the contents of the extension 
field. That doesn't leave much latitude for MACs longer than 6 words.

Apparently, we are having the same discussion about the vulnerability of 
the SHA family as we had with MD5. The issue id whether we can concoct 
an NTP header that has correct digest but altered header fields that are 
acceptable to the client. That is a tall order, as I discussed in the 
NTP Security Analysis cited earlier.

Dave

---

From: Danny Mayer <[email-masked]>
Date: Tue, 13 Dec 2011 13:23:22 -0500

On 12/13/2011 11:30 AM, todd glassey wrote:
> Applied For version of NTP 

This is not a topic for the working group. Please take this elsewhere.
If you are making any claims of IPR against NTP then you need to file
that with the IETF and not here.

Danny

---

From: John Smith <[email-masked]>
Date: Tue, 13 Dec 2011 20:45:41 +0000 (GMT)

Dave,

I think the discussion is not as much as whether SHA is secure enough or not but rather whether the current design of inferring the auth algo based on the length scalable or not? At some point of time we have to allow NTP to use an auth algo that has a digest size > 16 or 20 bytes. What needs to be done to get us to that stage is what folks would like to hear.

John

________________________________
 From: David L. Mills <[email-masked]>
To: Danny Mayer <[email-masked]> 
Cc: "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]> 
Sent: Tuesday, 13 December 2011, 22:09
Subject: Re: [ntpwg] [TICTOC]    NTP Extension Field without Authentication

Danny,

I don't know where this is going. I mentioned some constraints in my
recent message. I have no agenda for the spec; if it can be warped for
some goal or other, that's fine. However, the parsing design assumes
the packet format checks are independent of the contents of the
extension field. That doesn't leave much latitude for MACs longer than
6 words.

Apparently, we are having the same discussion about the vulnerability
of the SHA family as we had with MD5. The issue id whether we can
concoct an NTP header that has correct digest but altered header fields
that are acceptable to the client. That is a tall order, as I discussed
in the NTP Security Analysis cited earlier.

Dave

Danny Mayer wrote: 
>>>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. 
and SHA-2 will not apply to NTP (like most IETF protocols) but that
doesn't mean that we should go ahead using them. The security ADs I
believe are insistent on the HMAC construct to be used. To cite an
example, Bidirectional Forwarding Detection (BFD) protocol already
supports SHA-1. It is however being upgraded to support the HMAC version
of the SHA algorithms. I thus don't recommend going ahead with SHA-2. Sorry, I managed to miscommunicate what I meant. If HMAC is what is
needed to be used then we should use it. I just threw out SHA-2 as an
example. It wasn't meant as a specific recommendation. There are several
parts to the requirements about the MAC: 1) Signalling by the sender what algorithm to use for the MAC in the packet;
2) Signalling by the requestor what algorithms it can accept since the
two ends may have support for different algorithms.
3) What to do in the case where there is no algorithm in common. Danny

---

From: Dave Hart <[email-masked]>
Date: Wed, 14 Dec 2011 03:10:10 +0000

What Dr. Mills suggests is if you can't MITM NTP exchanges secured by
20-octet digests, there is no need for a larger digest.  This is why he
harkens back to the discussion of MD5 flaws and how they might be exploited
in the context of NTP authentication.  NTP has the advantage of time -- the
MITM has to not only find a correct digest for the modified packet, he must
do so fast enough that the client will not find reason to ignore the
response.

There is no doubt it is ugly that there are two different ad-hoc extensions
to the basic NTPv4 packet defined, both detected solely by the received
datagram size, and unfortunate that means extensions must be at least 7 x
32 bits long to avoid ambiguity.  One might hope any NTPv5 would include
indication in the basic packet headers of whether authentication and/or
extensions are used in a way that avoids such ambiguity.

Cheers,
Dave Hart

On Tue, Dec 13, 2011 at 20:45, John Smith <[email-masked]> wrote:

> Dave,
>
> I think the discussion is not as much as whether SHA is secure enough or
> not but rather whether the current design of inferring the auth algo based
> on the length scalable or not? At some point of time we have to allow NTP
> to use an auth algo that has a digest size > 16 or 20 bytes. What needs to
> be done to get us to that stage is what folks would like to hear.
>
> John
>
>   ------------------------------
> *From:* David L. Mills <[email-masked]>
> *To:* Danny Mayer <[email-masked]>
> *Cc:* "[email-masked]" <[email-masked]>; "[email-masked]" <
> [email-masked]>
> *Sent:* Tuesday, 13 December 2011, 22:09
> recent message. I have no agenda for the spec; if it can be warped for some
> goal or other, that's fine. However, the parsing design assumes the packet
> format checks are independent of the contents of the extension field. That
> doesn't leave much latitude for MACs longer than 6 words.
>
> the SHA family as we had with MD5. The issue id whether we can concoct an
> NTP header that has correct digest but altered header fields that are
> acceptable to the client. That is a tall order, as I discussed in the NTP
> Security Analysis cited earlier.
>
> Dave
>
> Danny Mayer wrote:
>

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 14 Dec 2011 10:22:15 +0530

Hi Dave,

I agree. Inspite of this we need to work on a generic mechanism because best operational practices might start deprecating MD5 and SHA1, and recommend some other authentication algo to be used in the future. Moreover, detecting auth algo based on the packet size is absurd because people use truncated hashes all the time. One could truncate a HMAC-SHA-256 digest to 20 bytes (or even 16). Thus even if there is no burning need today, we should start working on defining a generic way to secure NTP packets going forward.

Cheers, Manna

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave Hart
Sent: Wednesday, December 14, 2011 8:40 AM
To: John Smith
Cc: [email-masked]; [email-masked]; David L. Mills
Subject: Re: [TICTOC] [ntpwg] NTP Extension Field without Authentication

What Dr. Mills suggests is if you can't MITM NTP exchanges secured by 20-octet digests, there is no need for a larger digest.  This is why he harkens back to the discussion of MD5 flaws and how they might be exploited in the context of NTP authentication.  NTP has the advantage of time -- the MITM has to not only find a correct digest for the modified packet, he must do so fast enough that the client will not find reason to ignore the response.

There is no doubt it is ugly that there are two different ad-hoc extensions to the basic NTPv4 packet defined, both detected solely by the received datagram size, and unfortunate that means extensions must be at least 7 x 32 bits long to avoid ambiguity.  One might hope any NTPv5 would include indication in the basic packet headers of whether authentication and/or extensions are used in a way that avoids such ambiguity.

Cheers,
Dave Hart

On Tue, Dec 13, 2011 at 20:45, John Smith <[email-masked]<mailto:[email-masked]>> wrote:
Dave,

John

________________________________
From: David L. Mills <[email-masked]<mailto:[email-masked]>>
To: Danny Mayer <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, 13 December 2011, 22:09
Subject: Re: [ntpwg] [TICTOC] NTP Extension Field without Authentication

Danny,

I don't know where this is going. I mentioned some constraints in my recent message. I have no agenda for the spec; if it can be warped for some goal or other, that's fine. However, the parsing design assumes the packet format checks are independent of the contents of the extension field. That doesn't leave much latitude for MACs longer than 6 words.

Apparently, we are having the same discussion about the vulnerability of the SHA family as we had with MD5. The issue id whether we can concoct an NTP header that has correct digest but altered header fields that are acceptable to the client. That is a tall order, as I discussed in the NTP Security Analysis cited earlier.

Dave

Danny Mayer wrote:

Danny

Cheers, Manav

_______________________________________________
TICTOC mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tictoc

---

From: Dave Hart <[email-masked]>
Date: Wed, 14 Dec 2011 04:56:17 +0000

Again you seem to be ignoring the point that a generic policy to avoid MD5,
or SHA1, is probably not applicable to NTP's use of those algorithms.
 Fine, I'm not going to beat that drum anymore.

You are mistaken in assuming ntpd detects the algorithm based on the digest
size.  The algorithm is configured into both sides and not communicated on
the wire at all for symmetric authed NTP.

Cheers,
Dave Hart

On Wed, Dec 14, 2011 at 04:52, Bhatia, Manav (Manav) <
[email-masked]> wrote:

> **
> Hi Dave,
>
> I agree. Inspite of this we need to work on a generic mechanism because
> best operational practices might start deprecating MD5 and SHA1, and
> recommend some other authentication algo to be used in the future.
> Moreover, detecting auth algo based on the packet size is absurd because
> people use truncated hashes all the time. One could
> truncate a HMAC-SHA-256 digest to 20 bytes (or even 16). Thus even if there
> is no burning need today, we should start working on defining a generic way
> to secure NTP packets going forward.
>
> Cheers, Manna
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Dave Hart
> *Sent:* Wednesday, December 14, 2011 8:40 AM
> *To:* John Smith
> *Cc:* [email-masked]; [email-masked]; David L. Mills
> *Subject:* Re: [TICTOC] [ntpwg] NTP Extension Field without Authentication
>
> There is no doubt it is ugly that there are two different ad-hoc
> extensions to the basic NTPv4 packet defined, both detected solely by the
> received datagram size, and unfortunate that means extensions must be at
> least 7 x 32 bits long to avoid ambiguity.  One might hope any NTPv5 would
> include indication in the basic packet headers of whether authentication
> and/or extensions are used in a way that avoids such ambiguity.
>
> Cheers,
> Dave Hart
>
> On Tue, Dec 13, 2011 at 20:45, John Smith <[email-masked]>wrote:
>
>>  Dave,
>>

---

From: Danny Mayer <[email-masked]>
Date: Wed, 14 Dec 2011 07:58:23 -0500

On 12/13/2011 10:10 PM, Dave Hart wrote:
> harkens back to the discussion of MD5 flaws and how they might be
> exploited in the context of NTP authentication.  NTP has the advantage
> of time -- the MITM has to not only find a correct digest for the
> modified packet, he must do so fast enough that the client will not find
> reason to ignore the response.

That's not the discussion at all. MITM are totally separate from what we
are discussing. A MITM can interpret/recreate an MAC-protected NTP
packet just the same as any other NTP server.

> extensions to the basic NTPv4 packet defined, both detected solely by
> the received datagram size, and unfortunate that means extensions must
> be at least 7 x 32 bits long to avoid ambiguity.  One might hope any
> NTPv5 would include indication in the basic packet headers of whether
> authentication and/or extensions are used in a way that avoids such
> ambiguity.

We aren't going to wait on a putative NTPv5 for this. We are discussing
NTP v4 and how to clean up extension fields and have well defined MAC
algorithms in the packets. You just defined the problem yourself: "two
different ad-hoc extensions". They cannot remain ad-hoc.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Wed, 14 Dec 2011 08:16:08 -0500

On 12/13/2011 11:56 PM, Dave Hart wrote:
> Again you seem to be ignoring the point that a generic policy to avoid
> MD5, or SHA1, is probably not applicable to NTP's use of those
> algorithms.  Fine, I'm not going to beat that drum anymore.

No, you are ignoring the point that when the government says don't use
MD5 or some other hashing algorithm in any software provided to the
government, you can't use it and you have to find a replacement for it.
Worse still some governments may say that you cannot use algorithm X.
Saying that it is probably not applicable is like sticking your head in
the sand; it doesn't solve the underlying problem.

> 
> You are mistaken in assuming ntpd detects the algorithm based on the
> digest size.  The algorithm is configured into both sides and not
> communicated on the wire at all for symmetric authed NTP.
> 

That assumes a lot, including the fact that each server communicating
with an single host may want to use different algorithms. Not signalling
which one is being used is a really bad idea and a very poor design.

Danny

---

From: "David L. Mills" <[email-masked]>
Date: Wed, 14 Dec 2011 16:14:02 +0000

Danny,

Think of the message digest algorithm identifier as part of the key 
defined in the keys file. Only the server and client know the key and 
algorithm according to the key ID in the packet. There is no need for 
negotiation and no need for the client to learn the digest algorithm 
implicitly from the packet. Just to make life more interesting, in 
Autokey the key is used only once. While not algorithm the 
specification, there is no reason whey subsequent Autokey packets could 
not use different digest algorithms.

I submit that NTP cryptographic vulnerability is a tough nut to crack. 
Better a distributed DoS attack, then we get to talk about the rate 
managment provisions and the KoD packet.

Dave

---

From: Danny Mayer <[email-masked]>
Date: Thu, 15 Dec 2011 08:00:15 -0500

Dave,

I don't recall if the digest algorithm is specified for the MAC as part
of the Autokey specifications (RFC5906) but I don't believe so. If
Autokey requires a specific digest algorithm, or well defined ways of
disambiguating them, then that needs to be added to the Autokey RFC.

However we are not just talking about Autokey. There are two questions:
1) Is a MAC really required if there is an some other extension field?;
2) How do you specify the MAC digest algorithm outside of an Autokey
extension?

So let's discuss the above without Autokey with the understanding that
Autokey may require changes to the RFC to specify how to deal with a MAC
digest algorithm specification.

Danny

---

From: "David L. Mills" <[email-masked]>
Date: Thu, 15 Dec 2011 14:35:59 +0000

>Danny,
We are talking right past each other. Myy comments applied mainly to the 
symmetric key cryptography, onlyincidently to Autokey. In symmetric key 
cryptography the message digest algorithm is specified in the keys file; 
there is no opportunity to negotiate following that. In Autokey the 
signature and digest algorihtms are specified in the initial exchange; 
the group key algorithm is negotiated. Obviously, all things could be 
negotiated, but that is not the point of this message.

The fundamental requirements whether a MAC is present or not and whehter 
one or more extension fields are present has been covered in several 
previous messages. Limitations on the extension field and MAC 
configuration have been discussed as well. I have nothing further to 
add, other than a rewrite of the basic format with no backwards 
compatibility. You are welcome to initiate a discussion on a possible 
format revision.

Dave