Subject: Re: [ntpwg] Questions on draft-ietf-ntp-using-nts-for-ntp-01

From: [email-masked]
Date: Tue, 1 Sep 2015 23:14:34 +0200

Hi Miroslav,

thank you for feedback and questions.

"ntpwg" <ntpwg-bounces+kristof.teichel=[email-masked]> schrieb am 28.08.2015 13:58:05:
> Von: Miroslav Lichvar <[email-masked]>
> An: [email-masked]
> Datum: 28.08.2015 14:11
> Betreff: [ntpwg] Questions on draft-ietf-ntp-using-nts-for-ntp-01
> Gesendet von: "ntpwg" <ntpwg-bounces+kristof.teichel=[email-masked]>
>
> I have some questions and comments on draft-ietf-ntp-using-nts-for-ntp-01

>
> I think Florian has commented on this issue in the previous version of
> the draft, but I'm not sure if/how it was resolved. How does the
> client verify the identity of the server after receiving the
> server_assoc message? For persistent associations it would probably be
> a check of the hostname from the certificate, but what about ephemeral
> associations? Would it be acceptable for the client to be configured
> with a public key that the server certificate has to be signed by?

While I'm not sure I understand all the implications here (of persistent vs. ephemeral associations), I think it *might* be acceptable for the client to be configured to base his trust solely on such a public key. What would be the benefit of this?

>
> There doesn't seem to be anything specific to symmetric associations.
> I guess the simplest approach is to treat them in NTS as two
> independent client/server associations, created separately and then
> each packet having both time_request and time_response messages.

This is how I've always imagined symmetric associations to be treated by NTS, exactly.

> However, a special care must be taken when creating the association.
> To succeed even when an attacker is sending spoofed packets to the
> peers, I think there has to be a server_assoc/cook reply for each
> client_assoc/cook request, i.e. the initialization has to be
> independent from the normal peer polling process. Should be the
> assoc/cook messages sent in the NTP client/server mode packets or keep
> them in the symmetric mode? My preference would be the former.

Please explain the two options. Our idea has been to use the assoc/cook messages as specified for client-server also in the case of symmetric association, but we have not put much thought into the details yet.

>
> Will there be any recommendations on the minimum interval between
> client requests when creating an NTS association? I think it should
> follow the NTP rules on polling interval. With the 2s (i)burst
> interval and server_assoc message that didn't require more than one
> packet, the client could have the first secure timestamps after 4
> seconds.

I think the NTS4NTP document could include comments on data like minimum request intervals, yes.

>
> Should be the client_assoc message (or other NTS messages) required to
> include padding to prevent traffic amplification attacks?

We intend to specify the use of a kind of Photuris cookie approach in order to defend against traffic amplification attacks (a small exchange as confirmation that a traffic-intensive exchange is desired by the client). Therefore I do not believe that another measure (like padding) is necessary. On the other hand, I cannot see any downside to it immediately, so it might be considered.

>
> What exactly is preventing NTS to be usable with NTP pools? Is that
> meant for the pool.ntp.org pool where the servers are not controlled
> by a single entity or is there a requirement that one certificate
> cannot be used on multiple servers?

We figured there would not be a use case where a client would require authenticated time but would turn to a pool, because authenticated time seemed to imply that a client would need to choose a specific server (or several) which would be sufficiently trusted for its purposes. I have never explicitly thought about the mentioned requirement (a certificate may only validate one time server), but I believe it to make sense and have always implicitly assumed that it is there.

Also, isn't it currently incredibly easy to become a member of an NTP pool? For usage with NTS, I think this would have to be severely restricted.

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

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

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 2 Sep 2015 17:24:31 +0200

Thanks for the response, Kristof.

On Tue, Sep 01, 2015 at 11:14:34PM +0200, [email-masked] wrote:
>    > Would it be acceptable for the client to be configured
>    While I'm not sure I understand all the implications here (of
>    persistent vs. ephemeral associations), I think it *might* be
>    acceptable for the client to be configured to base his trust solely on
>    such a public key. What would be the benefit of this?

The benefit would be that the client doesn't have to accept time only
from a specified server. A broadcast/multicast server or an active
peer can push the association to the clients or passive peers (if they
are willing to accept it), which don't have to be configured with the
hostname of the server or active peer.

>    Please explain the two options. Our idea has been to use the assoc/cook
>    messages as specified for client-server also in the case of symmetric
>    association, but we have not put much thought into the details yet.

The question is what packet mode should be used to start a symmetric
association using NTS. I think one option is to use the client (mode
3) packets and switch to the symmetric mode (1 or 2) later when the
NTS association has been created, i.e. don't allow server_assoc/cook
messages in symmetric mode packets. The other option is to start
immediately with symmetric mode packets, but modify the peer polling
process to reply to all assoc/cook requests to prevent the DoS attack.
The former seems like a cleaner approach to me.

>    We figured there would not be a use case where a client would require
>    authenticated time but would turn to a pool, because authenticated time
>    seemed to imply that a client would need to choose a specific server
>    (or several) which would be sufficiently trusted for its purposes. I
>    have never explicitly thought about the mentioned requirement (a
>    certificate may only validate one time server), but I believe it to
>    make sense and have always implicitly assumed that it is there.
>    Also, isn't it currently incredibly easy to become a member of an NTP
>    pool? For usage with NTS, I think this would have to be severely
>    restricted.

Yes, anyone can join the pool.ntp.org pool, so using authentication
would probably not make much sense there. But what about pools where
all servers are owned by one company for instance? As a pool I
understand a name that resolves to addresses of multiple NTP servers.

---

From: [email-masked]
Date: Thu, 3 Sep 2015 13:04:43 +0200

Miroslav Lichvar <[email-masked]> schrieb am 02.09.2015 17:24:31:

> An: [email-masked]
> Kopie: [email-masked]
> Datum: 02.09.2015 17:24
> Betreff: Re: [ntpwg] Questions on draft-ietf-ntp-using-nts-for-ntp-01
> 

We have designed the association and cookie exchanges with nonces for 
freshness checks, so that a client can be sure that an association 
response is not a replay of an old one which was valid at the time but is 
now outdated and possibly unsecure.
I believe that for this to work, the association always has to be 
initiated by the client.

For NTS-secured NTP, broadcast/multicast is treated largely seperately 
from unicast, the association/cookie exchanges do not really play a role 
there.

> The former seems like a cleaner approach to me.

I also like the former approach better.

> understand a name that resolves to addresses of multiple NTP servers.

For this topic, I do not yet have a good enough understanding of how 
clients work with pools. Does a client query the pool once, then get a 
fixed name/adress under which it can always reach the same server? Or is 
any time request sent to the pool name and then just routed to a random 
one of the servers reachable under that name?

In the former case, a client could just use NTS after it has acquired a 
name for a fixed server. In the latter case, the NTS/autokey approach of 
having a shared secret that is re-generatable on the server side (cookie) 
seems very difficult to apply, for all servers in the pool would have to 
possess synchronized secret server seeds.

---

From: Miroslav Lichvar <[email-masked]>
Date: Fri, 4 Sep 2015 10:11:49 +0200

> one of the servers reachable under that name?

The clients maintain separate NTP associations for different
addresses. The pool name is used to obtain addresses of NTP servers
when the client is started and to find replacement for servers that
become unreachable or otherwise unsuitable for synchronization later.

> possess synchronized secret server seeds.

I think it's the former, the client can create a separate NTS
association for each server.