NOTE WELL!

This project has been broken into several other projects and development continues there:

• ntske NTS-KE Go package.
• ntskeserver NTS-KE server.
• ntsclient: A simple NTS client.
• ntp: An NTP and NTS client package.

NOTE WELL!

Network Time Security (NTS) is a development of the venerable Network Time Protocol (NTP). NTS defines a separate Network Time Security Key Establishment (NTS-KE) protocol and uses extension fields in NTPv4.

This is an attempt to implement NTS-KE and SNTP with NTS extension fields according to the Dansarie specification in Go.

The NTS-KE is implemented as its own package for use in both NTS-KE clients and servers. An example client and server is provided. The client is also an SNTP client.

We also provide the beginning of an NTP server but it doesn't yet support any NTS extensions and is mostly cobbled together from internal structures in Brett Vickers NTP library, but it's a start.

These commands are under cmd/:

• ntsclient - An NTP client with NTS support.
• ntskeserver - A key exchange server for NTS.
• ntpserver - A silly excuse for an NTP server.

If you just want to run them you can do a

% go get github.com/mchackorg/gonts/cmd/...

and they should end up in your $GOPATH/bin/ directory.

For development purposes there is a simple Makefile. make should build everything.

The current project was started in two days during the 102 IETF Hackathon. Michael "MC" Cardell Widerkrantz, Daniel "quite" Lublin, omni and raccoon gathered as remote participants in the hackathon in central Malmö with lots of Club-Mate. Lots of specification reading, some false starts and kludgy code were the results.

MC wrote a blog post about the hackathon that you might want to read.

1. The NTS-KE client initiates traffic. It initiates an application layer TLS session to the NTS-KE server and sends a selection of AEAD algorithms.

2. The NTS-KE server lists its selection of AEAD algorithms. If the client and server have overlapping algorithms they continue to export keying materials from the TLS session. Now they both have a pair of keys for use in each direction in NTP.

   The server also creates, encrypts, and sends initial cookies for later use. These cookies are opaque to the client.

3. The NTS-KE client might also be an NTP client. It can now ask for the time with the cookie it got from NTS-KE and using the C2S key for encrypted fields.

4. The NTP server gets the NTP request, unpacks the cookie and can now reply to the NTP client with the current time, encrypted with the S2C key that was in the cookie (see below).

   Since all information it needs is contained in the cookie it doesn't need to keep any state about the client.

There are several keys involved here:

1. A private key for the server's X.509 certificate.

2. A session key used in the TLS session.

3. A negotiated pair of keys for later NTP C2S and S2C communication.

4. A server-side key used to encrypt cookies.

Cookies are generated by the server, then encrypted by a server-only master secret. The NTS-KE and NTP servers should somehow share the secret used for cookie encryption.

The cookies contain:

in encrypted form:

• the negotiated AEAD algorithm,
• the S2C key
• the C2S key.

in plaintext:

• identifier of the server-side secret used to encrypt this cookie.

Note for this to work the cookies should not be encrypted by the C2S key when sent over NTP!

The NTP client sends both a cookie and asks for a new cookie with every request. It will use the new cookie on the next request.