= NTS support specification =

== Cisco's Statement of Work requirements ==

The NTS implementation shall:

* Use OpenSSL 1.1.1 for its crypto functions.

* Address RFC5705 Keying Material Exporting and AES_SIV (RFC5297) code
  support which may not be natively supported in OpenSSL.

* Comply with the standardized specification of NTS
  https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp

* Be interoperable with the other reference implementations in IETF hackathons.

== System Partitioning ==

Hal wrote:
> My understanding is that there are to be four agents: the client ntpd, a NTS
> symbiont communicating locally with the client ntpd, the server ntpd, and a
> symbiont communicating locally with the server ntpd.

> When a client wants to establish a secure link with a server, what are the
> first (say) three transactions among these agents?  Expand from there. I'll
> know that I understand enough to write code when I start correctly
> anticipating steps before you have described them.  This is unlikely to take
> long.

4 boxes.  My ASCII art is weak.  C for client, S for server.

   Bravo                       Delta
   NTS client ---------------- NTS server
      |                         |
   Alpha                       Charlie
   NTP client ---------------- NTP server

NTS-C-NTS-S (Bravo to Delta and back) is our stuff in TLS over TCP.
Everything we need to know is in the draft.  It's pretty simple.

NTP-C to NTS-C (Bravo to Alpha) is pretty simple.  NTP sends host
name, or something like that.  It gets back an IP Address (maybe more
than 1) and a bunch of cookies.

NTP-S to NTS-S (Charlie to Delta) Is only an occasional ?????.  I
don't have the right word handy.  It's whatever key transfer or status
messages are required.

NTP-C to NTP-S (Alpha to Charlie) is in the draft.

== Key Generation and Usage ==

NTS makes use of three keys:

* Client to Server (c2s)

* Server to Client (s2c)

* NTS Master Key

Because one of the goals of NTS is to not require any per-client state in
the servers, the server (both NTPD and NTS-KE) does not posess either of the
c2s/s2c pair. The servers do posess the NTS Master Key, which is expected to
be updated somewhat regularly.

The c2s/s2c pair is created during the TLS handshake between client and NTS-KE.
As part of this NTS-KE will create a variable number of cookies (should be 8).
These cookies are encrypted with the NTS master key, and are opaque to the
client. The cookies contain the c2s/s2c pair in a form that NTPD will
understand, and is how NTPD is able to en/decrypt data without needing to
store per-client keys.

When sending an NTS packet the client attaches a cookie-blob in cleartext,
then encrypts the rest of the data using the c2s key. When the NTPD server
recieves the packet it decrypts the cookie-blob using its Master Key, and
extracts the c2s/s2c pair so it can decrypt the rest. The response packet
is encrypted using the s2c key extracted from the cookie.
