NTS for the NTP pool
Cloudflare
watsonbladd@gmail.com
General
NTP
Internet-Draft
Network Time Security authenticates NTP servers. This document outlines an architecture that uses
ACME and SRV records for the NTP pool to carry out NTS.
Introduction
NTP is commonly provided via an NTP pool: a collection of servers behind a DNS load balanced
and/or geolocated domain name. However Network Time Security requires certificates associated to the
hostname of a server.
Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14
when, and only when, they appear in all capitals, as shown here.
The reader may wish to note that one of the two RFC references in the
preceding paragraph was normative; the other was informative. These will
be correctly identified as such in the References section below.
Background
The NTP pool uses dynamic DNS techniques to spread the load of NTP
over a wide variety of servers. Unfortunately this creates challenges
to the deployment of NTS: the servers all appear to share the same
hostname of the pool, and would all need certificates for that hostname.
To avoid these problems this draft presents a technique using SRV records
and per-server hostnames along with ACME.
Clients
A client interested in using NTS with nts-pool.ntp.example.org will
look up the SRV records for NTS-KE at nts-pool.ntp.example.org. This
SRV record will point to Fully Qualified Domain names of the form
servername.servers.pool.ntp.example.org, here called pool associated
domain names.
Clients will then execute NTS-KE against the resolved IP address for
those names, and continue as specified in
Clients SHOULD obtain multiple servers from a pool lookup and treat them
as independent sources. If a source is unacceptable clients SHOULD
replace them with new ones obtained from the pool.
Clients MAY periodically resolve the pool associated domain names to confirm
the server is still trusted by the pool.
Pool Members
Pool members will register their servers and provide a servername,
e.g. Alice. They will then use ACME with the HTTP-01 or ALPN challenge
to obtain a certificate for alice.servers.pool.ntp.example.org.
Pool Operators
On registration of a server pool operators will create
servername.servers.pool.ntp.example.org pointing to the provided IP
address(s).
Once a certificate has been issued and NTS is confirmed operational,
the pool may return SRV records pointing to the domain, either created
by the pool or provided by the server operator.
Pool operators who remove a server from the pool MUST break the pool associated
domain name. This prevents renewal of the associated certificate.
Security Considerations
This mechanism depends on the integrity of data in the DNS, for
security and therefore DNSSEC should be used to protect the
records. Webservers on server in the pool MUST check the Hosts header
of incoming HTTP requests to prevent cookie theft.
IANA Considerations
This document has no IANA actions.
Normative References
Informative References