Subject: [ntpwg] New Version Notification for draft-ietf-ntp-network-time-security-12.txt and draft-ietf-ntp-using-nts-for-ntp-03.txt

From: [email-masked]
Date: Mon, 21 Dec 2015 19:12:21 +0100

Hi all,
I've just submitted new versions of the drafts mentioned above. The most 
substantial change is the introduction of a MAC for the time_request 
message. Any comment is appreciated.

Greetings
Dieter

-------------------------------------
Dr. Dieter Sibold
Physikalisch-Technische Bundesanstalt
Q.42 - Serversysteme und Datenhaltung
QM-Verantwortlicher der Stelle IT
Bundesallee 100 
D-38116 Braunschweig
Tel:    +49-531-592-84 20
E-Mail: [email-masked]
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Danny Mayer <[email-masked]>
Date: Mon, 21 Dec 2015 15:11:17 -0500

> message. Any comment is appreciated.

Please don't use the existing MAC for this. It's horribly restrictive,
inflexible and impossible to extend. I'm in the process of putting
together an extension field MAC that will allow you to specify the
algorithm to be used for the hashing, you will know the length of the
MAC data and you will be able to have multiple MAC extension fields with
different algorithms. We need to get rid of the existing MAC as it
stands (though this will be gradual) and add flexibility.

Danny

---

From: [email-masked]
Date: Mon, 21 Dec 2015 22:43:38 +0100

Hi Danny,

since one of the past versions, we have discontinued usage of the MAC field and now use an additional extension field which carries exactly the MAC (covering everything else).

If you find any fragments in the documents that say otherwise, please let us know.

Kristof

-----"ntpwg" <ntpwg-bounces+kristof.teichel=[email-masked]> schrieb: -----

An: [email-masked], [email-masked]
Von: Danny Mayer
Gesendet von: "ntpwg"
Datum: 21.12.2015 21:20
Betreff: Re: [ntpwg] New Version Notification for draft-ietf-ntp-network-time-security-12.txt and draft-ietf-ntp-using-nts-for-ntp-03.txt

Danny

---

From: Danny Mayer <[email-masked]>
Date: Mon, 21 Dec 2015 17:06:51 -0500

On 12/21/2015 4:43 PM, [email-masked] wrote:
> Hi Danny,
> 
> since one of the past versions, we have discontinued usage of the MAC
> field and now use an additional extension field which carries exactly
> the MAC (covering everything else).

Can you point to the description of this? I haven't seen one and we need
a complete description of any Extension Field.

Danny

---

From: [email-masked]
Date: Tue, 22 Dec 2015 10:24:25 +0100

You can see it in the draft "draft-ietf-ntp-using-nts-for-ntp-03". There 
it is mentioned e.g. in sect. 6.1.3.2. The idea is that NTS for NTP 
defines one additional extension field (see section IANA registration) and 
that all NTS-messages are using this extension field. The different NTS 
message types are distinguished by their respective OID (see the next 
version of the draft "draft-ietf-ntp-cms-for-nts-message"). This also is 
true for the MAC. Kristof please correct me if I'm wrong. The field type 
of the NTS extension field is not registered yet. This has to be done as 
soon as possible. This was also discussed with the NTF.

Dieter

Danny Mayer <[email-masked]> schrieb am 21.12.2015 23:06:51:

> Von: Danny Mayer <[email-masked]>
> An: [email-masked]
> Kopie: [email-masked], [email-masked]
> Datum: 21.12.2015 23:06
> Betreff: Re: [ntpwg] New Version Notification for draft-ietf-ntp-
> network-time-security-12.txt and draft-ietf-ntp-using-nts-for-ntp-03.txt
>

---

From: Richard Welty <[email-masked]>
Date: Tue, 22 Dec 2015 09:52:13 -0500

On 12/22/15 4:24 AM, [email-masked] wrote:
> You can see it in the draft "draft-ietf-ntp-using-nts-for-ntp-03". There it is mentioned e.g. in
sect. 6.1.3.2. The idea is that NTS for NTP defines one additional
extension field (see section IANA registration) and that all
NTS-messages are using this extension field. The different NTS message
types are distinguished by their respective OID (see the next version of
the draft "draft-ietf-ntp-cms-for-nts-message"). This also is true for
the MAC. Kristof please correct me if I'm wrong. The field type of the
NTS extension field is not registered yet. This has to be done as soon
as possible. This was also discussed with the NTF.
i believe the extension field type will be assigned by the IANA at the same
time as the OIDs; please correct me if i'm wrong.

richard

---

From: Danny Mayer <[email-masked]>
Date: Tue, 22 Dec 2015 13:45:18 -0500

> time as the OIDs; please correct me if i'm wrong.

Part of the problem is that section 6.1.3.2 mentions and extension field
MAC but does not describe it. We cannot go forward with this draft
unless there is already a MAC extension field draft to go along with it.
I have been intending to get this done but it doesn't exist yet unless
someone else is doing it.

Danny

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 23 Dec 2015 01:33:03 +0000

> soon as possible. This was also discussed with the NTF.

I gather we want an extension field for NTS and we want an extension
field for the message authenticator.

DLM says the original expectation and plan was for mulitple extension
fields to be allowed, and that the MAC, if present, would always be the
last thing in the packet.

If a new extention field was added to the packet that process should
remove any previous MAC field and add a new one to the end of the packet.

I'm curious if there is new information available that would show good
reason why we should reconsider this.

H

---

From: [email-masked]
Date: Wed, 23 Dec 2015 09:10:17 +0100

Danny, I understand your point. Yes the MAC extension field in 6.1.4.3 has 
to be described more clearly. But why should we need a special draft for a 
MAC extension field. There is already the draft 
"draft-ietf-ntp-extension-field" which should me general enough for 
additional new extension fields. 

"ntpwg" <ntpwg-bounces+dieter.sibold=[email-masked]> schrieb am 
22.12.2015 19:45:18:

> An: Richard Welty <[email-masked]>, [email-masked]
> Datum: 22.12.2015 20:07
> Gesendet von: "ntpwg" <ntpwg-bounces+dieter.sibold=[email-masked]>
>

---

From: Hal Murray <[email-masked]>
Date: Wed, 23 Dec 2015 02:29:07 -0800

> DLM says the original expectation and plan was for mulitple extension fields
> to be allowed, and that the MAC, if present, would always be the last thing
> in the packet.

> If a new extention field was added to the packet that process should remove
> any previous MAC field and add a new one to the end of the packet.

> reason why we should reconsider this. 

The rules for parsing the current MAC are ugly enough that I think a it would 
be progress if any changes in that area set things up so the MAC could follow 
normal rules with a length/type header.  (I think it's fine to require the 
MAC to be at the end of the packet.)

If you are looking for new information, I'd say we now appreciate how 
complicated the current MAC parsing rules are and/or how they interact with 
trying to use new extension fields.

Is anybody actually using ntp packets with extension fields other than a MAC? 
 How much do we have to grandfather in?

-- 
These are my opinions.  I hate spam.

---

From: Danny Mayer <[email-masked]>
Date: Wed, 23 Dec 2015 09:34:29 -0500

On 12/22/2015 8:33 PM, Harlan Stenn wrote:
> If a new extension field was added to the packet that process should

That would be necessary if there is only the MAC at the end of the
packet because you cannot have two or more of them. However if the MAC
is an extension field itself there can be as many as necessary.

> reason why we should reconsider this.

Yes. The MAC field in the packet has reached the end of it's useful
life. It is inflexible, the algorithm to be used cannot be specified,
and we are currently guessing whether or not it is present and how long
it is.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Wed, 23 Dec 2015 09:45:38 -0500

On 12/23/2015 3:10 AM, [email-masked] wrote:
> Danny, I understand your point. Yes the MAC extension field in 6.1.4.3
> has to be described more clearly. But why should we need a special draft
> for a MAC extension field. There is already the draft

I know, I coauthored that draft with Tal Mizrahi. The problem is that a
MAC extension field needs to be specified so that it can replace the
existing MAC field. I'm also considering allowing for multiple MAC
extension fields in a single packet so that one MAC hashing algorithm
can be retired if found to be compromisable without disrupting NTP
infrastructure and existing implementations. It also needs some
discussion on usage by responding packets and which to use.

Danny

---

From: [email-masked]
Date: Wed, 23 Dec 2015 16:28:04 +0100

So, the intention of the MAC extension field is to replace the current MAC 
field? And it will support the current pre-shared key authentication 
scheme?

Dieter

Von:    Danny Mayer <[email-masked]>
An:     [email-masked]
Kopie:  [email-masked], ntpwg 
<ntpwg-bounces+dieter.sibold=[email-masked]>, Richard Welty 
<[email-masked]>
Datum:  23.12.2015 15:45
Betreff:        Re: [ntpwg] New Version Notification for 
draft-ietf-ntp-network-time-security-12.txt and 
draft-ietf-ntp-using-nts-for-ntp-03.txt

Danny

---

From: Danny Mayer <[email-masked]>
Date: Wed, 23 Dec 2015 10:48:22 -0500

On 12/23/2015 10:28 AM, [email-masked] wrote:
> So, the intention of the MAC extension field is to replace the current
> MAC field? And it will support the current pre-shared key authentication
> scheme?
> 

Yes. It will be close to the existing MAC but implemented as an
extension field. I'm hoping to get rid of the existing MAC in favor of
it as an extension field to give us the needed flexibility.

Danny

> ------------------------------------------------------------------------
> 
> 
>

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 23 Dec 2015 21:13:46 +0000

Danny Mayer writes:
> ... The problem is that a

If this is a V4 thing there will be backward compatability issues.

I think I have an idea about how to do this so older systems might still
work.  It will require more research though.

H

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 23 Dec 2015 21:23:35 +0000

> it as an extension field to give us the needed flexibility.

I'm curious to see how you will deal with backward compatibility.

H

---

From: Danny Mayer <[email-masked]>
Date: Wed, 23 Dec 2015 16:58:52 -0500

> If this is a V4 thing there will be backward compatability issues.

No, not really. New code like NTS would use the new Extension Field but
the MAC will need to be kept for older systems who won't be able to use
NTS anyway.

> work.  It will require more research though.

The older systems won't know about the NTS stuff so it doesn't matter.
The MAC itself can't go away until v5.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Wed, 23 Dec 2015 16:59:54 -0500

> I'm curious to see how you will deal with backward compatibility.

Older systems only know about Autokey at most and that will be using the
existing MAC implementation.

Danny

---

From: Harlan Stenn <[email-masked]>
Date: Thu, 24 Dec 2015 00:42:02 +0000

> the MAC will need to be kept for older systems who won't be able to use

You mean "updated versions of ntpd" wil be able to use the new Extension
Field, right?

> The older systems won't know about the NTS stuff so it doesn't matter.

This is not about NTS.  It's about your statement re using an extension
field for the MAC instead of the old MAC.

Think about the case where a new authenticated association is being spun
up and the initiating system does not know if the target system supports
this new extension field.

> The MAC itself can't go away until v5.

We've done a suboptimal job of supporting older NTP versions.  The good
news is that this hasn't caused problems so nobody has cared about it,
at least not enough to have ever emailed or opened a bug about it.

I don't think we'll have that luxury for v5 servers with v4 (or earlier)
clients.

And while we will need a mechanism in v5 to support v4 or earlier
versions, we can also implement a policy choice to decide what earlier
versions of the protocol the running ntpd will/won't support.
-- 
Harlan Stenn <[email-masked]>
http://networktimefoundation.org - be a member!
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Hal Murray <[email-masked]>
Date: Wed, 23 Dec 2015 21:53:48 -0800

[email-masked] said:
> The older systems won't know about the NTS stuff so it doesn't matter. The
> MAC itself can't go away until v5. 

Right.

But do we need to support current style hard to decode MACs if there are new 
extension fields?  Is anybody currently using extension fields other than for 
old style MACs?

One approach for adding new extension fields is for them to have a 
length/type header, optionally followed by an old style MAC.  A cleaner 
approach would be to require that any MAC following a new extension have a 
length/type header.  That would break existing code if it was using new 
extension fields with an old MAC, but that only matters if there is running 
code out there to break.

---

From: "Ulrich Windl" <[email-masked]>
Date: Mon, 28 Dec 2015 07:51:46 +0100

>>> Danny Mayer <[email-masked]> schrieb am 23.12.2015 um 22:58 in Nachricht
> the MAC will need to be kept for older systems who won't be able to use

Obviously in a transition period the servers need to provide both, the new MAC extension AND the old one, so old partners can ignore the MAC extension field and use the old MAC, while new partners will ignore(?) the old MAC and use the new one instead. Then the next generation can drop the old MAC. Maybe for consistency the transition version should check both MACS for consistency.

Ulrich