Subject: [ntpwg] Symmetric mode in NTS

From: Miroslav Lichvar <[email-masked]>
Date: Fri, 2 Jun 2017 17:03:26 +0200

I was reading the current text of nts-for-ntp about DTLS and the
symmetric mode, but it's not obvious to me how exactly it's supposed
to work. I have few questions:

- Do the peers use separate ports for DTLS client and server?

- What should happen when both peers are active and are started at the
  same time? Should each have its own DTLS connection? 

- How should be handled the case when a passive peer doesn't mobilize
  an association? This is normally a stateless mode of operation.
  Should the peer reject the connection and let the other peer figure
  out that it needs to use the client mode and maybe try symmetric
  mode again later?

To be honest, I don't like that the symmetric mode has a completely
different protocol. Why not use the same NTS-KE over TLS and NTP
extensions as the client/server mode? I think the issue with replay
attacks can be solved by requiring both ends of the NTS association to
save unused cookies. Are there any other issues?

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

---

From: Daniel Franke <[email-masked]>
Date: Fri, 2 Jun 2017 12:58:46 -0400

> - Do the peers use separate ports for DTLS client and server?

Servers use the IANA-allocated NTS port. Clients can use whatever they want.

>   same time? Should each have its own DTLS connection?

Good question, I'll add a paragraph clarifying this. I think the
answer is necessarily yes. Peers configured as active don't
necessarily know whether the other peer is active or passive, so they
each would need to at least attempt to initiate their own DTLS
session. Only one session is needed, but if two get established then I
think it's easier to just keep them both open than to attempt to
somehow break the symmetry and figure out which one to close.

>   out that it needs to use the client mode and maybe try symmetric

I think this is a policy question and it's up to implementers. Servers
may choose to answer mode 1 packets over DTLS without standing up an
association, but if they do so they'll incur the overhead of keeping
the DTLS session open. Clients which try to peer with a server but
find that it's not accepting DTLS handshakes can implement whatever
fallback behavior seems appropriate.

> save unused cookies. Are there any other issues?

Remember, cookies are opaque. When a client gets cookies from a server
all it can do is pass them back; it can't decode them. So to get
symmetric mode working over NTS Extensions for NTPv4, you'd have to
exchange cookies in both directions during the NTS-KE handshake, and
then every packet would have to have two cookie extensions as well as
well as unique identifier extensions, one for each direction. This is
all possible, but it's a pretty radical change this late in the game.

The other issue is that we still need DTLS anyhow in order to secure
mode 6, where there are stronger confidentiality requirements and the
packets don't follow the normal structure so there's no well-defined
way to include extension fields.
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Daniel Franke <[email-masked]>
Date: Fri, 2 Jun 2017 14:15:23 -0400

How about this text?

Since DTLS-encapulated NTPv4 sessions may carry arbitrary NTP packets,
there is no prescribed implication from an implementation's role as a
DTLS client vs. DTLS server, to its role in the application-level
Network Time Protocol. For example, it is entirely permissible, albeit
perverse, for an implementation to initiate a DTLS handshake (thus
acting in the role of DTLS client), and then once the handshake is
completed, act as an NTP server with the DTLS server acting as an NTP
client. However, in the name of practicality, the following guidelines
are offered for what constitutes sensible default
behavior. Implementations may depart from this guidance if the user
configures them to do so.

Implementations typically should not use DTLS-encapsulated NTPv4 for
client/server mode, instead preferring to use NTS-KE and NTS
Extensions for NTPv4. If DTLS-encapsulated NTPv4 is used for
client/server mode, then the NTP client (mode 3) should be the DTLS
client and the NTP server (mode 4) should be the DTLS server.

For control mode (6), the party sending queries should be the DTLS
client and the party responding to the queries should be the DTLS
server.

For symmetric operation between an active (mode 1) and passive (mode
2) peer, the active peer should be the DTLS client and the passive
peer should be the DTLS server.

For symmetric operation between two active (mode 1) peers, both
parties should attempt to initiate a DTLS session with their peer. If
one handshake fails and the other succeeds, the
successfully-established session should be used for traffic in both
directions. If both handshakes succeed, either session may be used and
packets should receive identical dispositon regardless of which of the
two sessions they arrived over. Inactive sessions may be timed out but
the redundant session should not be proactively closed.

If, likely as a result of user error, party A is configured as a
symmetry active peer of party B, but party B is neither accepting DTLS
handshakes from party A nor initiating one with it, then after a
suitable number of failed attempts, party A may fall back to acting as
an NTP client (mode 3) of party B using NTS-KE and NTS Extensions for
NTPv4.

---

From: [email-masked]
Date: Sat, 3 Jun 2017 21:57:25 +0200

I agree with the text, but would like to have slight changes to the first paragraph.

Since DTLS-encapsulated NTPv4 sessions may carry arbitrary NTP packets,
there is no prescribed implication from an implementation's role as a
DTLS client vs. DTLS server, to its role in the application-level
Network Time Protocol. For example, it is entirely permissible for an 
implementation to initiate a DTLS handshake (thus
acting in the role of DTLS client), and then once the handshake is
completed, act as an NTP server with the DTLS server acting as an NTP
client. The following guidelines are offered as sensible default behavior.
Implementations may depart from this guidance if the user
configures them to do so.

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" <ntpwg-bounces+dieter.sibold=[email-masked]> wrote: -----
To: Miroslav Lichvar <[email-masked]>
From: Daniel Franke 
Sent by: "ntpwg" 
Date: 06/02/2017 20:15
Cc: [email-masked]
Subject: Re: [ntpwg] Symmetric mode in NTS

How about this text?

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 5 Jun 2017 16:00:55 +0200

> How about this text?

Thanks, it does help. I have few more questions below.

> the redundant session should not be proactively closed.

How will the peers know which two DTLS sessions belong together?
Should they assume all connections with an IP address belong to the
same server instance? That would probably create a new limitation.

In normal NTP it is possible to peer with multiple instances on one IP
address, e.g. multiple computers behind NAT, as there is only one UDP
connection per symmetric association and both ports of an
active-active association are known. If NTS needs four ports and only
two are known for each peer, that won't work.

> an NTP client (mode 3) of party B using NTS-KE and NTS Extensions for

The trouble with this is when B is reconfigured to accept symmetric
associations with A, A will likely need to be restarted in order to
switch to the symmetric mode.

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 5 Jun 2017 17:10:40 +0200

> all possible, but it's a pretty radical change this late in the game.

Making the protocol fully symmetric in active-active associations
would be nice, but I'm not sure if it's necessary. I think it could
work using just one client/server NTS association, except the server
needs to save cookies issued to the client and allow only one update
per cookie. The server would be checking cookies and the client would
be checking unique identifiers in order to protect against replay
attacks. As I understand it, the client doesn't need to decode the
cookies.

The question is how to determine the direction of the NTS
client/server association when both peers are active. One solution
that comes to my mind would be to include an ID of the peer in the
NTS-KE. Each peer has a random ID. A new record would be added to
NTS-KE to request a symmetric association, which would include the ID.
An active peer will compare the ID with its own and allow the KE to
succeed only if it's smaller. If it's not smaller it will return a
specific error code. That way, if both are trying to make an NTS-KE
association, only one will succeed. A passive peer will create the
association and ignore the ID.

I can try to look into the details and prepare changes for the
document if there is interest.

> way to include extension fields.

For mode 6 it makes perfect sense. With modes 1 and 2 not so much. It
will probably be good enough for most cases, but it's not a full
replacement of the older authententication protocols. So far, I
noticed the following issues:

- no stateless passive mode
- problematic pairing of DTLS sessions
- requires timestamping of messages on a new port
  - won't work with HW which can timestamp only packets on port 123
    (or 319)
  - will require changes in QoS classification on routers/switches
- won't work with future NTP extensions for delay corrections in
  routers/switches

I think this would all disappear if we used NTS-KE and NTP extensions.