Subject: [ntpwg] Comments/questions on the "Network Time Security" draft

From: Philip Prindeville <[email-masked]>
Date: Fri, 7 Mar 2014 23:44:04 -0700

Hi.

Sorry about coming into this conversation late. Working in too many groups on too many standards.

I’m excited about adding security to NTP, and I’d like to do an interoperability bake-off once I’ve got an implementation hacked together, but I’m not sure I understand the spec clearly enough to do so, so here’s my list of questions...

Reading section 6.2.1 I’m wondering about a few things. What’s the encoding of the “negotiated version number”? 

Obviously certain encodings like the width of the public keys depends on the certs themselves, but other things like the encoding of the “negotiated version number” could be explicitly stated (e.g. 16 bits, network byte order).

What’s the significance of the “client’s hostname” (especially if the name isn’t DNS-resolvable, and/or the address is RFC-1918)?  Or is the hostname only for tracing/debugging purposes?  And how is the “signature algorithm negotiated during the association message” encoded?  Is there standard enumerations for various algorithms?

Ditto for section 6.1.1: how are the “selection of hash algorithms” and “selection of accepted algorithms for the signature” encoded?

In section 6.3.2, the cookie and its signature are fairly time invariant, right?  Does this make it vulnerable to replay, or make the client’s private key easier to crack?  Would it make sense to include some bits of entropy like a nonce or a timestamp that we could ignore?

And in section 6.4.2, we generate a MAC but not a signature.  I don’t know if I’ve ever seen a MAC without also doing signing. Because we’d be able to spoof the response otherwise, right? The nonce in the time_request and the cookie both go by in the clear, so while we can test the integrity of the message, we can’t test the authenticity of it without using something that’s only known to the server (hence the need for signing).

Or maybe I’m just tired and missing something really obvious…

Anyone else working on an implementation at this time?

Thanks,

-Philip

_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: "Ulrich Windl" <[email-masked]>
Date: Mon, 10 Mar 2014 08:19:05 +0100

>>> Philip Prindeville <[email-masked]> schrieb am
08.03.2014
um 07:44 in Nachricht
<[email-masked]>:

[...]
> What’s the significance of the “client’s hostname” (especially if
the name 
> isn’t DNS-resolvable, and/or the address is RFC-1918)?  Or is the hostname
only 
> for tracing/debugging purposes?  And how is the “signature algorithm 
[...]

Hello,

while not following the development closely, I'd like to add some comment:
Good point! If you are running multiple services on a host, the interface
address used for a service may not match the host name when being resolved.
This causes some pain with the current autokey mechanism for example. I'm
wondering whether a concept like iSCSI's "initiator name" should be introduced
(iSCSI a node is identified not by an IP address, but by a unique name (iqn,
iSCSI qualified name (if I remember it correctly) or eui (IEEE EUI-64)). All
authentication is using the iqn (as a name, not as an address). [See RFCs
3720/3721]. This would also mean that hosts may change addresses without
breaking authentication.
I see that IP addresses of NTP servers "come for free", but maybe a host
identifier can be passed as well in the future.

Regards,
Ulrich Windl

---

From: [email-masked]
Date: Mon, 10 Mar 2014 16:12:10 +0100

Hi Philip,

thanks for your questions and comments. We try to answer them as best as we
can.

Regarding the encoding of version number, algorithms, etc. We haven't done
that yet. But it is on our to do list. In the meantime we got a suggestion
to use the CMS schemes for wrapping and encoding of suchthings.  If you
have any specific suggestions on this topic, please let us know.

The client's hostname is included for explicitness and due to the fact that
the connection is supposed to be stateless on the server side.

Regarding your question to 6.3.2. Yes, you are probably right. As a matter
of fact. This argument will probably also apply to 6.2.2. So, we'll
consider this.

Regarding 6.4.2. No, in a time request the cookie has not to be exchanged.
Instead the server will recalculate the cookie based on the client's public
key and it's own seed. The MAC will be calculated as a HMAC with the cookie
as key. Verification of the MAC will therefore testify integrity and verify
authenticity.
The cookie has to be exchanged only once, namely during the cookie message
(6.3). This exchange is encrypted by the public key of the client and
signed by the key of the server (6.3.2). The client will store the cookie;
the server will recalculate it at each time request from the client.

Greetings

----------------------------------
Physikalisch-Technische Bundesanstalt
Dr. Dieter Sibold
Q.42 - Serversysteme und Datenhaltung
QM-Verantwortlicher der Stelle IT-Infrastruktur
Bundesallee 100
D-38116 Braunschweig
Tel: +49-531-592-84 20
E-Mail: [email-masked]

Von:	Philip Prindeville <[email-masked]>
An:	[email-masked]
Datum:	08.03.2014 07:48
Betreff:	[ntpwg] Comments/questions on the "Network Time Security" draft
Gesendet von:	ntpwg-bounces+dieter.sibold=[email-masked]

Hi.

Sorry about coming into this conversation late. Working in too many groups
on too many standards.

I’m excited about adding security to NTP, and I’d like to do an
interoperability bake-off once I’ve got an implementation hacked together,
but I’m not sure I understand the spec clearly enough to do so, so here’s
my list of questions...

Reading section 6.2.1 I’m wondering about a few things. What’s the encoding
of the “negotiated version number”?

Obviously certain encodings like the width of the public keys depends on
the certs themselves, but other things like the encoding of the “negotiated
version number” could be explicitly stated (e.g. 16 bits, network byte
order).

What’s the significance of the “client’s hostname” (especially if the name
isn’t DNS-resolvable, and/or the address is RFC-1918)?  Or is the hostname
only for tracing/debugging purposes?  And how is the “signature algorithm
negotiated during the association message” encoded?  Is there standard
enumerations for various algorithms?

Ditto for section 6.1.1: how are the “selection of hash algorithms” and
“selection of accepted algorithms for the signature” encoded?

In section 6.3.2, the cookie and its signature are fairly time invariant,
right?  Does this make it vulnerable to replay, or make the client’s
private key easier to crack?  Would it make sense to include some bits of
entropy like a nonce or a timestamp that we could ignore?

And in section 6.4.2, we generate a MAC but not a signature.  I don’t know
if I’ve ever seen a MAC without also doing signing. Because we’d be able to
spoof the response otherwise, right? The nonce in the time_request and the
cookie both go by in the clear, so while we can test the integrity of the
message, we can’t test the authenticity of it without using something
that’s only known to the server (hence the need for signing).

Thanks,

-Philip

---

From: [email-masked]
Date: Mon, 10 Mar 2014 18:23:29 +0100

In autokey the IP addresses of the client and server are used for the
calculation of the cookie. That is not the case in NTS. Here we made the
cookie dependable on the public key of the client and the seed of the
server. Therefore, NTS should have no issues with IP address changes.

Von:	"Ulrich Windl" <[email-masked]>
An:	<[email-masked]>, "Philip Prindeville"
            <[email-masked]>
Datum:	10.03.2014 08:20
Betreff:	[ntpwg] Antw: Comments/questions on the "Network Time Security"
            draft
Gesendet von:	ntpwg-bounces+dieter.sibold=[email-masked]

08.03.2014
um 07:44 in Nachricht

[...]
the name
only
[...]

Hello,

while not following the development closely, I'd like to add some comment:
Good point! If you are running multiple services on a host, the interface
address used for a service may not match the host name when being resolved.
This causes some pain with the current autokey mechanism for example. I'm
wondering whether a concept like iSCSI's "initiator name" should be
introduced
(iSCSI a node is identified not by an IP address, but by a unique name
(iqn,
iSCSI qualified name (if I remember it correctly) or eui (IEEE EUI-64)).
All
authentication is using the iqn (as a name, not as an address). [See RFCs
3720/3721]. This would also mean that hosts may change addresses without
breaking authentication.
I see that IP addresses of NTP servers "come for free", but maybe a host
identifier can be passed as well in the future.

Regards,
Ulrich Windl