Subject: [ntpwg] Fwd: Early Allocations for NTS drafts from the IETF NTP Working Group

From: Richard Welty <[email-masked]>
Date: Thu, 10 Mar 2016 12:30:53 -0500

resending this with the correct from address; this is the message
Karen asked me to forward to the list.

richard

Subject: Early Allocations for NTS drafts from the IETF NTP Working Group
From: Richard Welty <[email-masked]>
To: [email-masked]
Date: Thu, 25 Feb 2016 09:12:09 -0500

The IETF NTP Working Group requests allocation of OIDs and
extension field ids for the Network Time Security protocols in
advance of Working Group Last Call (which is pending.) We need
to have OID assignments before OpenSSL 1.1.0 goes to beta
testing which is about a month away.

The assignments requested are from
draft-ietf-ntp-cms-for-nts-messages.txt section 5 and
draft-ietf-ntp-using-nts-for-ntp.txt section 7.

the specific request is as follows:

==================================================

- From draft-ietf-ntp-cms-for-nts-messages.txt:

5.  IANA Considerations

5.1.  SMI Security for S/MIME Module Identifier Registry

   Within the "SMI Security for S/MIME Module Identifier
   (1.2.840.113549.1.9.16.0)" table, add one module identifier:

         Decimal  Description                             References
         -------  --------------------------------------  ----------
         TBD0     id-networkTimeSecurity-2015             [this doc]

5.2.  SMI Security for S/MIME CMS Content Type Registry

   Within the "SMI Security for S/MIME CMS Content Type
   (1.2.840.113549.1.9.16.1)" table, add eleven content type
   identifiers:

         Decimal  Description                             References
         -------  --------------------------------------  ----------
         TBD1     id-ct-nts-clientAccess                  [this doc]
         TBD2     id-ct-nts-serverAccess                  [this doc]
         TBD3     id-ct-nts-clientAssoc                   [this doc]
         TBD4     id-ct-nts-serverAssoc                   [this doc]
         TBD5     id-ct-nts-clientCookie                  [this doc]
         TBD6     id-ct-nts-serverCookie                  [this doc]
         TBD7     id-ct-nts-securityDataReq               [this doc]
         TBD8     id-ct-nts-securityDataResp              [this doc]

5.3.  SMI Security for PKIX Extended Key Purpose Registry

   Within the "SMI Security for PKIX Extended Key Purpose Identifiers
   (1.3.6.1.5.5.7.3)" table, add three key purpose identifiers:

         Decimal  Description                             References
         -------  --------------------------------------  ----------
         TBD14    id-kp-ntsServerAuth                     [this doc]
         TBD15    id-kp-ntsServerAuthz                    [this doc]
         TBD16    id-kp-ntsClientAuthz                    [this doc]

==================================================

- From draft-ietf-ntp-using-nts-for-ntp.txt

7.  IANA Considerations

7.1.  Field Type Registry

   Within the "NTP Extensions Field Types" registry table, add one field
   type:

   Field Type  Meaning                              References
   ----------  ------------------------------------ ----------
   TBD1        NTS-Related Content                  [this doc]

7.2.  SMI Security for S/MIME CMS Content Type Registry

   Within the "SMI Security for S/MIME CMS Content Type
   (1.2.840.113549.1.9.16.1)" table, add one content type identifier:

   Decimal  Description                                   References
   -------  --------------------------------------------  ----------
   TBD2     id-ct-nts-ntsForNtpMessageAuthenticationCode  [this doc]
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Richard Welty <[email-masked]>
Date: Thu, 10 Mar 2016 11:57:21 -0500

this is the document that Karen requested i resend to the mailing list.

richard

5.  IANA Considerations

7.  IANA Considerations

7.1.  Field Type Registry

---

From: Harlan Stenn <[email-masked]>
Date: Fri, 11 Mar 2016 08:42:51 +0000

I request that we recommend IANA allocate the following Field Types for
the NTS extension field:

 0x0004	NTS: MAC required
 0x1004	NTS: MAC included

Should we discuss if:

 0x2004 NTS: MAC not required

should also be permitted?  It would be used for the initial 6 packets if
the sender felt comfortable sending these initial packets with no
symmetric key MAC protection.

I'm not yet seeing any reason to allocate the:

 0x40xx Response
 0x80xx Error

Field Type flags for use with NTS.
-- 
Harlan Stenn <[email-masked]>
http://networktimefoundation.org - be a member!
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: [email-masked]
Date: Fri, 11 Mar 2016 11:01:43 +0100

I fail to see the necessity of the requested extension field types, 
mentioned below. The current specification only requires a single 
extension field type value. The requirement to append or not append a NTS 
MAC to the message is given unambiguously by the context.

Dieter

"ntpwg" <ntpwg-bounces+dieter.sibold=[email-masked]> schrieb am 
11.03.2016 09:42:51:

> Von: Harlan Stenn <[email-masked]>
> An: [email-masked]
> Datum: 11.03.2016 09:43
> Betreff: Re: [ntpwg] Fwd: Early Allocations for NTS drafts from the 
> IETF NTP Working Group
> Gesendet von: "ntpwg" <ntpwg-bounces+dieter.sibold=[email-masked]>
>

---

From: Harlan Stenn <[email-masked]>
Date: Fri, 11 Mar 2016 12:12:45 +0000

> MAC to the message is given unambiguously by the context.

The need for MAC protection is generic, and increasing.

The flags I describe do not care if the MAC is NTS, old-style, or something
"new".

I think your statement about the requirement to (not) append a MAC to the
message is known unambiguously by the context is white-box.  We need a
black-box answer/information.  The described flag bits convey this
information, black-box, with no extra processing.

An increasing number of systems (want to) require MAC protection before they
will believe timestamps.

There is also increasing pressure to have correct time on a machine as soon
as possible.  Delaying the availability of MAC-protected timestamps until
the beginning of the 4th NTS exchange (the 7th packet) in this case is
unacceptable.

If you see another way to authenticate time packets before the beginning
of the 4th exchange (or 7th packet), please describe it.

I'm also about to submit a number of other extension field proposals that
make use of these flags.

H
--

---

From: Danny Mayer <[email-masked]>
Date: Fri, 11 Mar 2016 08:00:13 -0500

>  0x2004 NTS: MAC not required

None of this is needed. NTS already knows what it needs.

Danny

---

From: Miroslav Lichvar <[email-masked]>
Date: Fri, 11 Mar 2016 14:56:35 +0100

> the beginning of the 4th NTS exchange (the 7th packet) in this case is

I'm not sure I follow here. If you have a symmetric key or another
authentication mechanism enabled, why would you use NTS?

IIRC, Autokey in the client/server mode has the same delay (4th reply
is authenticated). Why is that now a problem with NTS? I don't
remember seeing any complaints on Autokey.

> of the 4th exchange (or 7th packet), please describe it.

I guess the packet with the server_cook message could include a MAC
using the cookie that the message contains, so the client could have
authenticated timestamps in the third reply.

> I'm also about to submit a number of other extension field proposals that

I'm still not sure why would an extension field need to specify it
needs a MAC. Maybe if we saw for what the proposals use these flags,
it would make more sense.

-- 
Miroslav Lichvar

---

From: [email-masked]
Date: Fri, 11 Mar 2016 15:01:40 +0100

> The flags I describe do not care if the MAC is NTS, old-style, or 
something

In this case I do not understand: Why do you list them as "NTS: MAC 
required/included"?

If there is a way to communicate these things independently from the fact 
that the extension field is NTS-related, then that is another discussion. 
But from what I understand, you are proposing values that explicitly 
identify more than multiple different identifiers for NTS-related 
extension fields. In which case I agree with Dieter: I do not see a need 
to differentiate at that point (where a participant has seen, but not 
begun to process, an extension field).

> the beginning of the 4th NTS exchange (the 7th packet) in this case is

Any kind of MAC protection requires that the participants perform some 
kind of key exchange beforehand. In the case of NTS, this exchange is 
performed over NTP packets. 
This should not be looked at as delaying authenticated time exchange, but 
as doing the key exchange procedure (which has to be done anyway) 
in-protocol. The alternative would be to do it out-of-protocol, but 
overall: does this save any time or effort?

Instead of the time that passes between the first NTP packet sent and the 
first authenticated timestamp available to the client, consider the time 
that passes between the decision to obtain authenticated time and the 
first authenticated timestamp being available. This will in fact take more 
time and effort if the client needs to do some out-of-protocol key 
exchange first (as in the case of e.g. symmetric key MAC protection).

> > > Gesendet von: "ntpwg" 
<ntpwg-bounces+dieter.sibold=[email-masked]>

---

From: [email-masked]
Date: Fri, 11 Mar 2016 20:01:09 +0100

>remember seeing any complaints on Autokey.

That's a point I've been meaning to bring up, but somehow didn't get around to: this "issue" is not new, or unique to NTS.

One could even have the association done in fewer excahnges, but at a significant security cost (and I would therefore absolutley not recommend it): 1 exchange could be saved if we cut algorithm negotiation, another 1 echange could be cut if we disabled the defense mechanism against crypto DoS.

>authenticated timestamps in the third reply.

You are right in that all necessary arrangements are ready by that point. In fact, we thought about this recently, but we decided that the drawback was too severe:

In contrast to the crypto operations for a time_response (which are fast by design), the processing of the NTS extension fields for a server_cook are computationally expensive, and precision might be degraded beyond acceptable limits.

---

From: Karen ODonoghue <[email-masked]>
Date: Fri, 11 Mar 2016 17:28:03 -0500

Folks,

Based on the process outlined in RFC 7120, I have decided to proceed 
with the early allocation request as documented by Richard. This request 
was discussed in previous IETF NTP wg meetings and on the previous (Feb 
2016) virtual interim. Please note that this request does not restrict 
any additional allocations that are needed. The issues raised regarding 
additional allocations can be resolved during the development of the 
spec and the implementation. Thanks to Richard for putting together the 
final request.

Regards,
Karen

On 3/11/16 2:01 PM, [email-masked] wrote:
> That's a point I've been meaning to bring up, but somehow didn't get 
> around to: this "issue" is not new, or unique to NTS.
> One could even have the association done in fewer excahnges, but at a 
> significant security cost (and I would therefore absolutley not 
> recommend it): 1 exchange could be saved if we cut algorithm 
> negotiation, another 1 echange could be cut if we disabled the defense 
> mechanism against crypto DoS.
>
> You are right in that all necessary arrangements are ready by that 
> point. In fact, we thought about this recently, but we decided that 
> the drawback was too severe:
> In contrast to the crypto operations for a time_response (which are 
> fast by design), the processing of the NTS extension fields for a 
> server_cook are computationally expensive, and precision might be 
> degraded beyond acceptable limits.
>
> >

---

From: Harlan Stenn <[email-masked]>
Date: Sat, 12 Mar 2016 00:17:27 +0000

> None of this is needed. NTS already knows what it needs.

That's not the point.  I've repeatedly stated it's not the point, and
explained the reasonings for my choices.

You have repeatedly said "NTS already know what it needs."

We can continue if something new happens.

H

---

From: Harlan Stenn <[email-masked]>
Date: Sat, 12 Mar 2016 00:55:32 +0000

Miroslav Lichvar writes:
>> There is also increasing pressure to have correct time on a machine
>> as soon as possible.  Delaying the availability of MAC-protected
>> timestamps until the beginning of the 4th NTS exchange (the 7th
>> packet) in this case is unacceptable.
> 

How do you protect the first few packets otherwise?

I'm offering a mechanism that would permit symmetric key for the first
few packets.  At that point one can shift to NTS.

Put another way, we just saw an enhancement request wrapped in a CVE
about how the current symmetric key scheme does not protect broadcast
group members from receiving spoofed packets from any server that has
the private key.  CVE-2015-7974, or NTP Bug 2936.

This goes to the distinction between authentication and authorization.

> remember seeing any complaints on Autokey.

*All* autokey packets use a MAC, so they always have that level of
authentication and protection.  Autokey is an extra means to
authenticate the server to the client.

>> If you see another way to authenticate time packets before the
>> beginning of the 4th exchange (or 7th packet), please describe it.
> 

That's closer, but even if that works it still means one has to wait
until the 6th packet to get MAC-protected time.

>> I'm also about to submit a number of other extension field proposals
>> that make use of these flags.
> 

Because Tal's extension field proposal, as written, requires *no* MAC.

This triggered a bunch of changes to extension fields that I have strong
objections to.

In a short while you'll see the other proposals.

One of the first ones will be the proposal Danny and I are working on to
put MACs in an extension field.

That is an extension field that:

- contains a MAC
- requires no MAC after the extension field

---

From: Harlan Stenn <[email-masked]>
Date: Sat, 12 Mar 2016 01:24:20 +0000

[email-masked] writes:
> Dies ist eine mehrteilige Nachricht im MIME-Format.
> --===============8193363747663456345==
> Content-Type: multipart/alternative; boundary="=_alternative 004D0F17C1257F73
> _="
> 
> Dies ist eine mehrteilige Nachricht im MIME-Format.
> --=_alternative 004D0F17C1257F73_=
> Content-Type: text/plain; charset="US-ASCII"
> 
>>> extension field type value. The requirement to append or not append
>>> a NTS MAC to the message is given unambiguously by the context.
>>> 
>>> Dieter
>> 
>> The flags I describe do not care if the MAC is NTS, old-style, or
>> something "new".
> 

Each NTS packet would use *one* of the following Field Types:

 0x0004 NTS: MAC required (later in the packet)
 0x1004 NTS: MAC included in this extension field

One could also use:

which would mean "The NTS packet I'm sending does not expect any MAC
protection."

Compare this with the Autokey Field Types:

 0xXX02 Autokey: MAC required (later in the packet)

> If there is a way to communicate these things independently from the
> fact that the extension field is NTS-related, then that is another
> discussion.  But from what I understand, you are proposing values that
> explicitly identify more than multiple different identifiers for
> NTS-related extension fields. In which case I agree with Dieter: I do
> not see a need to differentiate at that point (where a participant has
> seen, but not begun to process, an extension field).

See RFC5906 for the description of the Field Types for autokey.  In
these. the 2nd nibble describes the packet content.  NTS does not want
to make this information public, and that's fine.

But that does not obviate the black-box need to know if any given
extension field is expecting additional MAC protection, or if any given
extension field provides MAC protection over the preceding packet
contents.

>> I think your statement about the requirement to (not) append a MAC to
>> the message is known unambiguously by the context is white-box.  We
>> need a black-box answer/information.  The described flag bits convey
>> this information, black-box, with no extra processing.
>> 
>> An increasing number of systems (want to) require MAC protection
>> before they will believe timestamps.
>> 

Yes, and until that time there is *no* MAC protection available.

If that doesn't matter for you, that's your local policy choice.

If it matters to somebody else, that's their local policy choice.

You don't get to dictate their policy choices.

I'm talking about mechanism, which gives people the ability to make
local policy choices.

> This should not be looked at as delaying authenticated time exchange,
> but as doing the key exchange procedure (which has to be done anyway)
> in-protocol.

I'm happy for you.  And if that works for you, fine.

I'm telling you it won't work for others who have a different use-case,
and I'm going to do my best to provide a robust mechanism that will
permit folks to make local policy choices that meet their needs.

> The alternative would be to do it out-of-protocol, but

That's a local policy choice.  What I describe permits this *now* with
the existing symmetric key mechanism.  If somebody wants something else,
they can make a proposal.

> Instead of the time that passes between the first NTP packet sent and
> the first authenticated timestamp available to the client, consider
> the time that passes between the decision to obtain authenticated time
> and the first authenticated timestamp being available. This will in
> fact take more time and effort if the client needs to do some
> out-of-protocol key exchange first (as in the case of e.g. symmetric
> key MAC protection).

If an ntp.keys file exists already then it takes no time at all to offer
traditional MAC protection, as good or bad as that is.  We have *many*
choices for algorithms here.  If using this is importanant, key
distribution has already been considered and addressed.

>> of the 4th exchange (or 7th packet), please describe it.

If that needs to be changed to "... before the response portion on the
3rd exchange (or the 6th packet), please describe it.

We need to permit MAC protection on or before the 2nd packet, as that
provides iburst with the fastest way to get the local clock stabilized.

H

---

From: Harlan Stenn <[email-masked]>
Date: Fri, 11 Mar 2016 17:43:45 -0800

On 3/11/16 11:01 AM, [email-masked] wrote:
> That's a point I've been meaning to bring up, but somehow didn't get around to: 
> this "issue" is not new, or unique to NTS.
> significant security cost (and I would therefore absolutley not recommend it): 1 
> exchange could be saved if we cut algorithm negotiation, another 1 echange could 
> be cut if we disabled the defense mechanism against crypto DoS.

That doesn't seem to be a useful solution.

But as I mentioned earlier, autokey packets are already *always*
MAC-protected.  That's all we need here.

> Miroslav wrote:
> You are right in that all necessary arrangements are ready by that point. In 
> fact, we thought about this recently, but we decided that the drawback was too 
> severe:
> In contrast to the crypto operations for a time_response (which are fast by 
> design), the processing of the NTS extension fields for a server_cook are 
> computationally expensive, and precision might be degraded beyond acceptable limits.

I thought this might be the case.

iburst sends 8 packets at 2-second intervals.

If the NTS handshake process takes more than 2 seconds to finish, iburst
will be sending its next query before we have time to finish preparing
the next NTS field.

>> it would make more sense.

As I said before, from the beginnings of NTPv4, if there was an
extension field, a MAC was REQUIRED.

The thing is we're now seeing our first case where an extension field
does *not* require a MAC.

I'm comfortable being strongly in favor of having this sort of knowledge
be black-box obvious, at the level of the overall extension field API.

-- 
Harlan Stenn <[email-masked]>
http://networktimefoundation.org - be a member!

---

From: Danny Mayer <[email-masked]>
Date: Fri, 11 Mar 2016 22:13:01 -0500

> Because Tal's extension field proposal, as written, requires *no* MAC.

That's because his proposal changes the transmit timestamp and any MAC
that might be present would therefore be invalidated and would not be
correctable.

> This triggered a bunch of changes to extension fields that I have strong

The only real change was to clarify whether or not a MAC was required in
the presence of any extension field and some guidance on handling
unknown extension fields.

Danny

---

From: Harlan Stenn <[email-masked]>
Date: Sat, 12 Mar 2016 04:51:54 +0000

> that might be present would therefore be invalidated and would not be

Yes.

>> This triggered a bunch of changes to extension fields that I have
>> strong objections to.
> 

I strongly disagree with your position.  There were several other
significant changes, and I think they are wrong.

But I hope to have time to respond properly to these soon.

H

---

From: [email-masked]
Date: Sat, 12 Mar 2016 13:28:13 +0100

Hi Harlan,
see comments below.

-----Harlan Stenn <[email-masked]> wrote: -----

>To: Miroslav Lichvar <[email-masked]>
>From: Harlan Stenn <[email-masked]>
>Date: 03/12/2016 01:58
>Cc: Harlan Stenn <[email-masked]>, [email-masked],
>[email-masked]
>Subject: Re: [ntpwg] Fwd: Early Allocations for NTS drafts from the
>IETF NTP Working Group
>
>Miroslav Lichvar writes:

Autokey adds an extension field to each packet only because of the requirement that there has to be a MAC field after an extension field. But the MAC during the initial phase of autokey, in which the challenge-response scheme and then the cookie exchange runs, are without any information, because the underlying cookie, which is the base for the  autokeys, which are used to calculate the MAC has the public value zero. You can read this in RFC5906, Page 10. 
The NTP packet format has been augmented to include one or more
extension fields piggybacked between the original NTP header and the
MAC.  For packets without extension fields, the cookie is a shared
private value.  For packets with extension fields, the cookie has a
default public value of zero, since these packets are validated
independently using digital signatures.  

That's in principal just the same principle as with NTS. NTS also protects there initial exchanges via signatures.

>strong

---

From: Harlan Stenn <[email-masked]>
Date: Sun, 13 Mar 2016 02:44:35 +0000

[email-masked] writes:
> Autokey adds an extension field to each packet only because of the
> requirement that there has to be a MAC field after an extension
> field. But the MAC during the initial phase of autokey, in which the
> challenge-response scheme and then the cookie exchange runs, are
> without any information, because the underlying cookie, which is the
> base for the =A0autokeys, which are used to calculate the MAC has the
> public value zero. You can read this in RFC5906, Page 10.

I'm not digging in to the reasoning underneath.  I'm just saying the
reality is that until *very* recently, the presence of an extension
field REQUIRED a MAC.

That the initial algorithm for autokey is NULL is, I believe, a
shortcoming.

It could be easily fixed, if anybody cared enough to fix it.

I'm fine *allowing* the current behavior to move forward with NTS, and
my preference is to *allow* MAC protection on initial NTS packets until
the state of an NTS-protected association can provide MAC protection as
part of its packets.

H

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 14 Mar 2016 10:51:33 +0100

> reality is that until *very* recently, the presence of an extension

I thought you wanted to include a MAC to have authenticated data
sooner. Now you say you want to include a dummy MAC to fulfill a
requirement from time when no other extension fields than Autokey
existed?

> That the initial algorithm for autokey is NULL is, I believe, a

The algorithm doesn't change, but the key is public, which means the
MAC doesn't protect anything and can't be used for authentication.

> the state of an NTS-protected association can provide MAC protection as

If you really want I think you can already do that it with a symmetric
key. Or is there anything in the current NTS draft that forbids the
old-style MACs in packets containing NTS messages?

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 14 Mar 2016 11:43:59 +0100

On Fri, Mar 11, 2016 at 08:01:09PM +0100, [email-masked] wrote:
>    point. In fact, we thought about this recently, but we decided that the
>    drawback was too severe:

Yes, it would likely add an error to the measurement. I think it would
rather be due to packets being longer (and possibly fragmented) as
more time would be needed to send and receive them. The time needed
for processing of the NTS fields shouldn't matter as the RX/TX
timestamps are captured before/after the fields are processed.

---

From: [email-masked]
Date: Mon, 14 Mar 2016 11:50:47 +0100

> Von: Miroslav Lichvar <[email-masked]>
> > 

Exactly. And I for one am strongly against the use of such a feature, as 
it arguably creates false security.

> old-style MACs in packets containing NTS messages?

No, there is not.
Harlan, maybe this is a point where we have a misunderstanding? Do you 
think that NTS somehow prohibits the use of old-style MACs?

-------------
Best regards,
Kristof

---

From: "Dr. Dieter Sibold" <[email-masked]>
Date: Mon, 14 Mar 2016 14:26:01 +0100

Hi all,
to end this discussion, I propose that we add the following language to the Security Considerations of the draft: draft-ietf-ntp-using-nts-for-ntp-04

      <section title="Protection for Initial Messages">
        <t>The messages for access, association, and cookie exchange are
        encapsulated in NTP extension fields which are piggybacked onto NTP
        packets. The MAC for the protection of the NTP packet cannot be
        calculated until the cookie exchange has been successfully finished.
        Therefore, NTS does not append a MAC to (and thus does not protect the
        NTP header of) the messages associated to access, association and
        cookie exchange.</t>
      </section>

Dieter

> Am 14.03.2016 um 10:51 schrieb Miroslav Lichvar <[email-masked]>:
>

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 14 Mar 2016 21:45:22 +0000

> timestamps are captured before/after the fields are processed.

If one can get the arrival timestamp of the first fragment then what
additional error is being accumulated?

H

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 14 Mar 2016 21:44:04 +0000

> requirement from time when no other extension fields than Autokey

You are seriously misunderstanding what's going on here.

For autokey, the MAC is ALWAYS there.  The first few packets apparently
have a "null" algorithm, and we can certainly do better there.

For NTS, there is *no* MAC coverage until the 7th packet *that contains
NTS data*.  If there is enough work "behind the scenes" that we can't
get the NTS work done in the 2 second window between iburst packets then
the iburst exchange will be done before NTS gets completed, and we'll be
making additional progress every poll interval.

If that's OK for some people, that's great.

If that's not OK for some people, that's great.  The instant solution
for these folks is to use symmetric keys with the traditional MAC to
protect packet contents before NTS can provide a MAC itself.

> MAC doesn't protect anything and can't be used for authentication.

I don't understand what you mean.  What is the key you are talking about
that is public?

> old-style MACs in packets containing NTS messages?

This is exactly what I have proposed.

H

---

From: Hal Murray <[email-masked]>
Date: Mon, 14 Mar 2016 15:06:44 -0700

[email-masked] said:
> If that's not OK for some people, that's great.  The instant solution for
> these folks is to use symmetric keys with the traditional MAC to protect
> packet contents before NTS can provide a MAC itself. 

If I have symmetric keys, why would I bother with NTS?

Is there some crypto argument about changing keys after using a key on X 
bytes of data?  If so, what is X and/or how does that translate to something 
like years of NTP traffic?

-- 
These are my opinions.  I hate spam.

---

From: Kurt Roeckx <[email-masked]>
Date: Mon, 14 Mar 2016 23:35:16 +0100

On Mon, Mar 14, 2016 at 03:06:44PM -0700, Hal Murray wrote:
> bytes of data?

As far as I know, it depends on how you use that key, but I would
say yes.

Even if it doesn't depend on it, it might still be a good idea to
replace it on regular basis.

> If so, what is X

I think here the answer is even more complicated.

> how does that translate to something like years of NTP traffic?

Depending on how you use the key, it might not relate to the NTP
traffic.  That is, the key used for the NTP traffic might not be
the same.

If you want more specific answers you should ask more specific
questions, including on how you intend to use it.  And you should
probably ask someone who knows more about such things.

I also have no idea if there has been a real study of the proposal
or not, and I would strongly suggest that happens.

Kurt

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 15 Mar 2016 00:57:34 +0000

> it arguably creates false security.

It creates nothing.  It's the current situation for autokey.  It can be
easily fixed if anybody cares enough to do this.  With autokey being
deprecated in favor of NTS, I'm not sure who cares.  If a volunteer
steps up with a working patch we'll put it in place.  If somebody wants
to fund the development of this patch, that works, too.

>>> I'm fine *allowing* the current behavior to move forward with NTS,
>>> and my preference is to *allow* MAC protection on initial NTS
>>> packets until the state of an NTS-protected association can provide
>>> MAC protection as part of its packets.
>> 

Not at all.  My proposal has been to *allow* a legacy-MAC in addition to
the NTS MAC.

If one want initial packet content protection, they get it if they use a
MAC after the NTS EF.

If one does not care about initial packet content protection, fine.
They don't do any other MAC after the NTS EF.

If one wants *both* NTS MAC and some other MAC after the NTS EF, they
may have that too.  Their choice.  

H

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 15 Mar 2016 01:17:11 +0000

"Dr. Dieter Sibold" writes:
> 
> Hi all,
> to end this discussion, I propose that we add the following language to 
> the Security Considerations of the draft: 
> draft-ietf-ntp-using-nts-for-ntp-04
> 
>   <section title=3D"Protection for Initial Messages">
>   <section title=3D"Protection for Initial Messages">

How about this instead:

   <section title="Protection for Initial Messages">
     <t>The NTS messages providing access, association, and cookie
     exchange are encapsulated in an NTP extension field which is
     piggybacked onto NTP packets. NTS does not itself provide MAC
     protection of the NTP packet until the NTS cookie exchange has been
     successfully finished.  If some other form of MAC protection of the
     NTP packet and the NTS access, association, and cookie exchange is
     desired before NTS is able to provide it, existing alternative MAC
     protection MAY be used.</t>
     <t>The state of NTS MAC protection can be seen in the Field Type of
     the NTS extension field.</t> 
   </section>

My understanding is that there will be at most 1 NTS EF in any given NTP
packet.  I might wrong about that, and if I am, I'm curious why we'd
want multiple NTS EFs in a single NTP packet.

H

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 15 Mar 2016 02:52:57 +0000

> If I have symmetric keys, why would I bother with NTS?

I have no strong opinion on this.

> like years of NTP traffic?

I have no strong opinion on this.

H

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 15 Mar 2016 09:16:40 +0100

On Mon, Mar 14, 2016 at 09:44:04PM +0000, Harlan Stenn wrote:
> For autokey, the MAC is ALWAYS there.

Yes, the packets have a MAC, but as people in this thread have been
trying to explain to you, that MAC is worthless until the cookie is
exchanged. If ntpd used the first few packets for time
synchronization, a MITM attacker could easily modify the packets and
feed the client with bogus time. (I'm ignoring here the fact that
Autokey has a number of vulnerabilities that allow the attacker to do
that anyway.)

> The first few packets apparently

No, you can't. There is no secret that could be used to create a
proper MAC yet.

> making additional progress every poll interval.

I think with NTS it will be (assuming no further changes in the
protocol) exactly the same as it's with Autokey using an identity
scheme. The client gets authenticated timestamps in the fourth reply.
If it's using iburst (2s interval) that is about 6 seconds after the
start.

> If that's OK for some people, that's great.

I think that's ok for most people. At least with Autokey, I didn't see
any complaints.

> protect packet contents before NTS can provide a MAC itself.

That's not really a solution. NTS is using public-key crypto so you
don't have to deal with secret keys. If you are able to distribute
symmetric keys between the hosts and trust it enough that you will
accept packets for synchronization, you probably don't need NTS at
all.

> This is exactly what I have proposed.

Well, you can add old-style MACs to packets with NTS messages. Nothing
in the draft as it's currently written prevents you from doing that
apparently. You can use add an old-style MAC using a symmetric key to
packets that don't have the NTS MAC yet, so you can use them for
synchronization. You can also add it to packets that have the NTS MAC
for "extra protection".

---

From: "Dr. Dieter Sibold" <[email-masked]>
Date: Tue, 15 Mar 2016 11:26:04 +0100

> Am 15.03.2016 um 02:17 schrieb Harlan Stenn <[email-masked]>:
> 
Harlan, I don’t agree. This might be work, but I strongly recommend NOT to include this text into the document.

Dieter

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 15 Mar 2016 10:31:55 +0000

> Autokey has a number of vulnerabilities that allow the attacker to do

Yes.  We are in violent agreement.

> No, you can't. There is no secret that could be used to create a

Yes we can,  with a symmetric key.

> If it's using iburst (2s interval) that is about 6 seconds after the

Yes, except it's not yet clear the we can validate the certificate chain
in these various steps quickly enough for this to happen.

For situations that require some degree of proof about timestamps, we
may not get fast startup if we cannot use the first 3 timestamps of the
iburst volley.

There is also currently no way to invalidate timestamps once they have
been "accepted".

We might discover this is possible, but we have no idea yet.

>From what I have seen, not that many people used autokey, and it was
used in situations where fast startup was not a critical need.

The world has changed, and many more sites are being extra security
conscious.  That means they also need reliable time, quickly, to
continue certificate validation or DNSSEC or other things.

> accept packets for synchronization, you probably don't need NTS at

Lots of this is a non-issue if certain aspects don't matter for a given
local policy.

I agree, if it's not important it's not important.

The thing is, where it *is* important it needs to be available.

> synchronization. You can also add it to packets that have the NTS MAC

That's exactly what I've been saying.

H

---

From: [email-masked]
Date: Tue, 15 Mar 2016 17:48:55 +0100

>I don't understand what you mean. What is the key you are talking about

If you want to secure a message via a MAC, you need:

- Some MAC algorithm M which takes two parameters:

- A key K

- The message X that is supposed to be secured

Then you send the message X and attach M(K, X) to it to have MAC security.

MAC security is based on the assumption that only the involved participants can create the MAC (because only they know the key K).

The point here is that for the initial message exchagnes, Autokey does not use a NULL algorithm (which would mean M = NULL and which yes, could be fixed simply by saying "use something that is not NULL as the algorithm").

Instead, Autokey --much like NTS-- uses its initial message exchanges to actually exchange the key K. Therefore, it does not have it available during those exchanges.

Only (presumably) because of the self-inflicted requirement to always have a MAC when there is an extension field does Autokey even attach a MAC for those exchanges. The MAC that is always attached for any message X during these exchanges is M(NULL, X).

The key that Miroslav (?) is talking about that is publically available is the NULL key. The fact that there is no "real" key available for those exchanges is exactly the reason why this "shortcoming" is not (!) easily fixable.

>This is exactly what I have proposed.

I think the point here is that we do not need a proposal. The NTS spec already allows everyone to do just this.

I am strongly opposed to include any text to the effect of recommending it (for reasons explained in a separate mail).

---

From: Hal Murray <[email-masked]>
Date: Tue, 15 Mar 2016 11:04:03 -0700

> Yes we can,  with a symmetric key. 

If you have a symmetric key you don't need NTS.

It may be that the right approach is to dump NTS and use shared keys.  If so, 
we should be working on ways to distribute shared keys out of band from NTP 
proper.

Is there any reason to tightly couple distributing keys with NTP?

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 15 Mar 2016 21:18:37 +0000

> If you have a symmetric key you don't need NTS.

That's your policy choice.  I don't believe you should be able to
enforce that choice on others.

> It may be that the right approach is to dump NTS and use shared keys.
> If so, we should be working on ways to distribute shared keys out of
> band from NTP proper.

I think that's a poor mechanism, but it is an alternative mechanism.

> Is there any reason to tightly couple distributing keys with NTP?

Sure.    Good reasons?  Maybe.  Feeping creatureism?  Maybe.  Either
way, it boils down to the question of "is this a mechanism we want to
specifically address/include?"

One person's signal is another person's noise.

H

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 15 Mar 2016 16:32:38 -0700

On 3/15/16 9:48 AM, [email-masked] wrote:
> MAC security is based on the assumption that only the involved participants can 
> create the MAC (because only they know the key K).
> 
> The point here is that for the initial message exchanges, Autokey does not use a 
> NULL algorithm (which would mean M = NULL and which yes, could be fixed simply 
> by saying "use something that is not NULL as the algorithm").
> Instead, Autokey --much like NTS-- uses its initial message exchanges to 
> actually exchange the key K. Therefore, it does not have it available during 
> those exchanges.
> Only (presumably) because of the self-inflicted requirement to always have a MAC 
> when there is an extension field does Autokey even attach a MAC for those 
> exchanges. The MAC that is always attached for any message X during these 
> exchanges is M(NULL, X).
> The key that Miroslav (?) is talking about that is publicly available is the 
> NULL key. The fact that there is no "real" key available for those exchanges is 
> exactly the reason why this "shortcoming" is not (!) easily fixable.

Autokey requires MAC protection.  We have long had an optional MAC field
at the end of an NTP packet.

We've had the ntp.keys file for a long time, too.

There is a MAC added after the end of the autokey EF.  The keyid is 32
bits.  Symmetric keys have a keyid of <65535, while autokey keyids are
larger than 65535.  Don't trip over an exposed fencepost.

Today, the MAC that protects an autokey exchange is likely an autokey
session key, and for the first few steps of the dance that keyid is
effectively a null key.  It satisfies the "letter of the law" as far as
"you MUST have a MAC".

The initial autokey dance, like the initial NTS dance, CAN use a MAC
that is based on a symmetric key.  That key is NOT PUBLIC.

When looking at a MAC we check its 32-bit key.  We therefore instantly
know if the key is from the symmetric list or from the autokey list.

So, to summarize:

- autokey is ALWAYS protected by a MAC.
- The first few autokey packets are USELESSLY protected with
  what amounts to a NULL key/algorithm.

- At present, the first few NTS packets are not protected with
  the MAC that is eventually provided for with NTS

Some people have good reason to want initial packets to be protected
with a useful MAC.

My proposal allows this.  It does not require this.

> allows everyone to do just this.

How does NTS protect the first few packets?

If the answer is "It does not prohibit the use of an external MAC" then
sure, we agree.  But it's unclear.  If the Field Types that I describe
are properly used, things are clear.  Hence my request to clarify things
as I have already written.

If it means something else, then we have still not communicated clearly.

> reasons explained in a separate mail).

My firm position is as I have stated.  Nothing I have yet seen shows me
any reason to change my position, either.

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 15 Mar 2016 20:15:31 -0700

Howdy sir,

> Harlan, I don’t agree. This might be work, but I strongly recommend NOT to include this text into the document.

What do you disagree with?

Sentence by sentence:

D: The messages for access, association, and cookie exchange
   are encapsulated in NTP extension fields which are
   piggybacked onto NTP packets.

H: The NTS messages providing access, association, and
   cookie exchange are encapsulated in an NTP extension field
   which is piggybacked onto NTP packets.

I think my phrasing is cleaner and makes no substantive changes.
Is there anything in my changes to this sentence you disagree with?

D: The MAC for the protection of the NTP packet cannot be
   calculated until the cookie exchange has been successfully
   finished.

H: NTS does not itself provide MAC protection of the NTP packet
   until the NTS cookie exchange has been successfully finished.

Again, I think my phrasing is cleaner and makes no substantive changes.
Is there anything in my proposed sentence you disagree with?

D: Therefore, NTS does not append a MAC to (and thus does not
   protect the NTP header of) the messages associated to access,
   association and cookie exchange.

H: If some other form of MAC protection of the NTP packet and
   the NTS access, association, and cookie exchange is desired
   before NTS is able to provide it, existing alternative MAC
   protection MAY be used.

I don't fully understand what you mean when you say "NTS does not append
a MAC" - do you mean a legacy-MAC?  My understanding is that
NTS *includes* MAC protection starting with the 4th NTS exchange, which
is why I offer my language.  I see no substantive difference between
your wording and mine.  I think my language is cleaner.
Is there something you disagree with in what I have suggested?

I then add:

 The state of NTS MAC protection can be seen in the Field Type of
 the NTS extension field.

This is simply a matter of "fact", if we assume that my proposals are
accepted for how additions to the extension Field Type will be handled.
This is already the case for Tal's checksum complement proposal, see:

 https://datatracker.ietf.org/doc/draft-ietf-ntp-checksum-trailer/

Also see the 5 proposals I've submitted.
-- 
Harlan Stenn <[email-masked]>
http://networktimefoundation.org - be a member!

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 16 Mar 2016 09:31:46 +0100

> additional error is being accumulated?

Longer packets generally need more time for transmission and reception.
The error in the NTP TX/RX timestamps may change (depending on how the
timestamping is implemented) and the extra delay adds up with each
switch and router the packet goes through.

When measuring offset, the packets should be the same length in both
directions so there is a better chance the delays will cancel each
other out. For packets with the *access, *assoc and *cook NTS messages
this is not a problem as they can't be used for measurements (assuming
there is no protection outside NTS), but with the time_request and
time_response messages I think it matters.

That's why I'm suggesting to pad the time_response message to the
length of the time_request message. In the expected typical case where
both server and client packets include one of the time_* messages and
the NTS MAC, they will have the same length.

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 16 Mar 2016 20:47:34 -0700

On 3/16/16 5:14 AM, Dieter Sibold wrote:
> 
>> Am 16.03.2016 um 04:15 schrieb Harlan Stenn <[email-masked]>:
>>
>> Howdy sir,
>>
> Agree
> That is not quite the same. Our formulation states that NTS does not add a MAC to the exchanges considered. Your is not false but i implies that NTS does not protect the NTP packet which is false. In order to use your sentence it would have be changed to:
> 
> NTS does not itself provide MAC protection to the NTP header until the NTS cookie exchange has been successfully finished
> 
> It this okay with you?

How about:

 NTS provides MAC protection starting with the NTP packet that
 starts the 4th NTS exchange (the 7th NTP packet that contains
 an NTS extension field).

> If we formulate the second sentence as above the third sentence is not necessary. NTS does not explicitly prohibit the usage of the the alternative MAC, but I don’t want to recommend it. Therefore, I suggest to discard the third sentence completely.
> 
>> I then add:
>>
> I don’t understand?

The top 4 bits of the Extension Field Type contain high-level information:

 0x8000  Error (Autokey)
 0x4000  Response (Autokey, I Do)
 0x2000  MAC not required
 0x1000  MAC included

so in the case of NTS, the Field Type would be:

 0x0004	NTS, MAC SHOULD/MUST be provided separately
 0x1004 NTS, MAC included in the packet (implicitly
	indicates no subsequent separate MAC is needed)

We can debate the usefulness of:

 0x2004	NTS packet; MAC MAY be provided separately
 0x3004 NTS packet; MAC included and MAY be provided
	separately

>> This is simply a matter of "fact", if we assume that my proposals are

So is the following acceptable to you:

 The NTS messages providing access, association, and
 cookie exchange are encapsulated in an NTP extension field
 which is piggybacked onto NTP packets.

Hmmm, how about:

 An NTS message includes access, association, authentication,
 and/or cookie data encapsulated in an NTP extension field
 which is piggybacked onto an NTP packet.

 NTS provides MAC protection starting with the NTP packet that
 starts the 4th NTS exchange (the 7th NTP packet that contains
 an NTS extension field).

 If MAC protection of the NTP packet and the NTS access,
 association, and cookie exchange is desired on NTP packets
 before the start of the 4th NTS exchange (the 7th NTP packet
 that contains an NTS exntension field), existing alternative
 MAC protection MAY be used.

---

From: [email-masked]
Date: Thu, 17 Mar 2016 13:11:19 +0100

> > That is not quite the same. Our formulation states that NTS does 
> not add a MAC to the exchanges considered. Your is not false but i 
> implies that NTS does not protect the NTP packet which is false. In 
> order to use your sentence it would have be changed to:
> > 
> > NTS does not itself provide MAC protection to the NTP header until
> the NTS cookie exchange has been successfully finished
> > 
> > It this okay with you?
> 
> How about:
> 

The initial exchanges (Access, Association, Cookie Exchange) are only one 
possible way to exchange the cookie successfully. 
The draft demands that this exchange is supported, but it also allows for 
the cookie to be exchanged via other means. 
Therefore I would prefer to not bring the "4th exchange" formulation into 
the text, except in a context like "until the cookie has been successfully 
exchanged (which is usually by the end of the 3rd exchange, when using the 
access, association and cookie exchanges provided in [Quote appropriate 
appendix in main NTS draft])".
This, on the other hand, is quite lengthy, and also not very precise 
information.
Overall, I still strongly prefer:
> > NTS does not itself provide MAC protection to the NTP header until
> > the NTS cookie exchange has been successfully finished.

> > If we formulate the second sentence as above the third sentence is
> not necessary. NTS does not explicitly prohibit the usage of the the
> alternative MAC, but I don?t want to recommend it. Therefore, I 
> suggest to discard the third sentence completely.

I second this, again.

> > I don?t understand?

I would like to discuss this issue separately. We are creating so much 
content on this mailing list that noise is becoming a real problem IMO.

>  starts the 4th NTS exchange (the 7th NTP packet that contains

See above. There is too much to potentially nitpick about the "4th 
exchange" bit, and I would prefer to not use it.

>  MAC protection MAY be used.

To be honest, I find this unnecessarily stressing the issue. 
The statement "existing alternative MAC protection MAY be used" is always 
true for any NTS-protected NTP packet. 
Your proposed formulation would implicitly enable the misconception that 
the initial exchanges somehow differ from later exchanges in this regard.

---

From: Dieter Sibold <[email-masked]>
Date: Wed, 16 Mar 2016 13:14:30 +0100

Agree

It this okay with you?

I don’t understand?

> https://datatracker.ietf.org/doc/draft-ietf-ntp-checksum-trailer/ <https://datatracker.ietf.org/doc/draft-ietf-ntp-checksum-trailer/>
> 
Sorry, but I still haven’t had time to look at these proposals. 

> Harlan Stenn <[email-masked] <mailto:[email-masked]>>
> http://networktimefoundation.org <http://networktimefoundation.org/> - be a member!