First round of my stupid questions about NTS

Sat Jan 19 03:26:56 UTC 2019

On 1/18/19 8:33 PM, Gary E. Miller via devel wrote:
> On Fri, 18 Jan 2019 20:24:15 -0600
> Richard Laager via devel <devel at ntpsec.org> wrote:
> 
>> On 1/18/19 8:21 PM, Gary E. Miller via devel wrote:
>>> Once again: there is no TLS session between NTPD client and NTPD
>>> server.  
>>
>> As I quoted, from section 1.2 of draft-ietf-ntp-using-nts-for-ntp-15:
>>
>> "The client connects to an
>>  NTS-KE server on the NTS TCP port and the two parties perform a TLS
>>  handshake.  Via the TLS channel, ..."
> 
> I know you said that.
> 
> You are talking about the NTS-KE to NTPD server connection.
> 
> I am talking about the NTPD client to NTPD server connection.
> 
> Since they both need to work the same way we need to look at them
> at the same time.

Yes, as the draft says in multiple places, the client first makes an
NTS-KE connection (over TLS). The TLS session parameters from that
connection are used, per RFC 5705, to generate the "C2S" and "S2C". Over
the TLS channel, the client and server negotiate an AEAD algorithm
("algorithm") as (described in section 4.1.5) for use with NTP (which is
not necessarily the same algorithm they negotiated with TLS for this
NTS-KE connection). The NTS-KE server then needs to reply with a New
Cookie response, which MUST contain at least 1 cookie and SHOULD contain
8 (if and only if the Next Protocol and AEAD negotiations went as expected).

The cookie details are implementation-dependent, but I assume the plan
is to start from the suggested cookie format in section 6. The NTS-KE
server has a separate key "K" identified by key-identifier "I". The
NTS-KE server encrypts plaintext "P" (algorithm + S2C + C2S) under key K
with nonce "N", creating cookie (I,N,C) using an algorithm of its
choice. If multiple cookies are being generated (as in the initial
generation, where 8 SHOULD be generated), the plaintext of the cookies
differ in the nonce.

The (encrypted) cookie(s) are then provided to the client, which treats
them as opaque blob(s). From the client's perspective, this is random
data, as it does not have the server's key K.

In other words, C2S and S2C are derived by the client and server,
independently, using a deterministic algorithm (RFC 5705) dependent on
parameters they both know from the NTS-KE TLS connection.

When the client makes an NTP (not NTP-KE) request to the server, it
includes the cookie in an extension field. The server can decrypt this
cookie, using K (or a previous K in its rollover buffer), to get
plaintext P (algorithm, C2S, and S2C).

"[T]he client SHOULD avoid reusing a cookie." The client SHOULD include
N NTS Cookie Placeholder extension fields such that when the server
replies with N+1 new cookies, the client is back to 8 unused cookies
(section 5.7). As new cookies are re-issued, they are generated using
the same algorithm, varying only in nonce, reusing the same algorithm,
C2S, and S2C.

Note that C2S and S2C are not rotated. To rotate these keys, a new
NTS-KE connection would be required.

If you would like the NTP server to enforce rollover of C2S and S2C,
then simply extend the implementation-defined cookie format to include a
timestamp or something that lets the server statelessly determine when
the C2S and S2C should be discontinued. When that happens, the NTP
server can refuse to issue new cookies (as issuing new cookies is only a
SHOULD, not a MUST). Eventually, the client will run out of cookies, and
it SHOULD refuse to re-use a cookie and start a new NTS-KE connection at
that point, which generates a new C2S and S2C. But the client MAY simply
re-use old cookies. If it does so, eventually the server's rollover of
key K will mean that the old cookies become invalid. At that point, the
client is forced to re-negotiate NTS-KE.

> Looked at yet another way, the draft suggest to rotate the master key
> once a day, same master key on NTS-server and NTPD server.  But TLS
> uses a new master key every connection.

This is a different key, used for a different purpose. This master key
is identified as "K" in the draft and above. It is used only to encrypt
the plaintext P (algorithm, C2S, and S2C) to form the cookie.

> How do you propose that the NTS-KE (with TLS) and NTPD (without TLS)
> server share the same master key for one day using a master key from
> ephmeral TLS connections to the NTS-KE?
The client <-> NTS-KE server ephemeral TLS session is used to generate
C2S and S2C. Over the client <-> NTS-KE session is negotiated an AEAD
algorithm (plus optional NTP server and port) for use with NTPv4+NTS
traffic later. Those three values are provided back to the client as an
implementation-defined cookie, which in the suggested cookie format is
encrypted to the server's key K. The client then provides that cookie to
the NTP server, which can decrypt it using K to arrive back at C2S and S2C.

If the NTS-KE and NTP processes are separate (which they can be, and
presumably will be for NTPsec, but need not be), then the key they share
is key "K", and only key K. The NTS-KE process uses key K to encrypt the
initial cookie(s), which contains algorithm, C2S, and S2C. The NTP
process uses key K to decrypt cookies to get back algorithm, C2S, and
S2C, which are used for the AEAD function in the NTP protocol in the
client-to-server and server-to-client directions respectively. The NTP
process also uses key K to encrypt new cookies to the client.

How the NTS-KE and NTP processes share and roll over key K is
implementation-defined, but the specification gives a suggestion in
section 6:

   The need to keep keys synchronized between NTS-KE and NTP servers as
   well as across load-balanced clusters can make automatic key rotation
   challenging.  However, the task can be accomplished without the need
   for central key-management infrastructure by using a ratchet, i.e.,
   making each new key a deterministic, cryptographically pseudo-random
   function of its predecessor.  A recommended concrete implementation
   of this approach is to use HKDF [RFC5869] to derive new keys, using
   the key's predecessor as Input Keying Material and its key identifier
   as a salt.

In the suggested cookie scheme, the NTP/NTS-KE servers have one current
K at all times, and two past K to allow for smooth key rollover. The key
rollover time and rollover depth (two in the example) should obviously
be set such that clients will have issued 8 requests (and thus used up
all their old cookies) before the key rolls off completely. In other
words, if you're keeping two old Ks, the keys should be rolled no more
frequently than it takes a typical client to use 4 cookies. This isn't a
big deal, as a poll interval of 1024s means that 8 cookies are used up
in 136 minutes, and the suggestion of rolling K once per day and keeping
two old ones means cookies are valid for at least two days.

-- 
Richard

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20190118/3787bdbe/attachment-0001.bin>