Repository files navigation

NOTE WELL!

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

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

NOTE WELL!

Network Time Security (NTS) is a development of the venerable NetworkTime Protocol (NTP). NTS defines a separate Network Time Security KeyEstablishment (NTS-KE) protocol anduses extensionfields in NTPv4.

This is an attempt to implement NTS-KE and SNTP with NTS extensionfields according to theDansariespecificationin Go.

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

We also provide the beginning of an NTP server but it doesn't yetsupport any NTS extensions and is mostly cobbled together frominternal structures inBrett Vickers NTPlibrary, but it's a start.

These commands are undercmd/:

• 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 simpleMakefile.make shouldbuild everything.

The current project was started in two days during the102 IETFHackathon.Michael "MC" Cardell Widerkrantz, Daniel "quite" Lublin, omni andraccoon gathered as remote participants in the hackathon in centralMalmö with lots of Club-Mate. Lots of specification reading, somefalse starts and kludgy code were the results.

MC wrotea blog post about thehackathon that you might want to read.

1. The NTS-KE client initiates traffic. It initiates an applicationlayer TLS session to the NTS-KE server and sends a selection ofAEAD algorithms.

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

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

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

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

   Since all information it needs is contained in the cookie itdoesn'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-onlymaster secret. The NTS-KE and NTP servers should somehow share thesecret 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 cookiesshould not be encrypted by the C2Skey when sent over NTP!

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