https://github.com/mchackorg/gonts
Network Time Security in Go
https://github.com/mchackorg/gonts
go network ntp nts protocol security
Last synced: 5 months ago
JSON representation
Network Time Security in Go
- Host: GitHub
- URL: https://github.com/mchackorg/gonts
- Owner: mchackorg
- Created: 2018-12-11T08:06:37.000Z (over 7 years ago)
- Default Branch: master
- Last Pushed: 2019-11-02T16:26:24.000Z (over 6 years ago)
- Last Synced: 2025-08-14T17:55:36.975Z (10 months ago)
- Topics: go, network, ntp, nts, protocol, security
- Language: Go
- Size: 66.4 KB
- Stars: 5
- Watchers: 2
- Forks: 2
- Open Issues: 6
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# Network Time Security in Go
**NOTE WELL!**
This project has been broken into several other projects and
development continues there:
- [ntske](https://gitlab.com/hacklunch/ntske) NTS-KE Go package.
- [ntskeserver](https://gitlab.com/hacklunch/ntskeserver) NTS-KE server.
- [ntsclient](https://gitlab.com/hacklunch/ntsclient): A simple NTS client.
- [ntp](https://gitlab.com/hacklunch/ntp): An NTP and NTS client
package.
**NOTE WELL!**
## Introduction
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](https://tools.ietf.org/html/rfc7822) in NTPv4.
This is an attempt to implement NTS-KE and SNTP with NTS extension
fields according to the [Dansarie
specification](https://datatracker.ietf.org/doc/draft-dansarie-nts/?include_text=1)
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](https://github.com/beevik/ntp/), but it's a start.
## Commands
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.
## Building
For development purposes there is a simple `Makefile`. `make` should
build everything.
## Background
The current project was started in two days during the [102 IETF
Hackathon](https://trac.ietf.org/trac/ietf/meeting/wiki/102hackathon).
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](https://hack.org/mc/blog/nts.html) about the
hackathon that you might want to read.
## NTS Architecture
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.
2. A server-side key used to encrypt cookies.
## About 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.