1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
|
= NTS Quick Start Guide
include::include-html.ad[]
[cols="10%,90%",frame="none",grid="none",style="verse"]
|==============================
|image:pic/beaver.gif[]|
{millshome}pictures.html[from 'Pogo', Walt Kelly]
For putting out compiler fires.
|==============================
== Related Links
include::includes/hand.adoc[]
== Table of Contents
* link:#introduction[Introduction]
* link:#client[NTS Client Configuration]
* link:#server[NTS Server Configuration]
* link:#verify[Verification]
* link:#refer[References]
'''''
[[introduction]]
== Introduction
NTS is a method for using TLS/SSL to authenticate NTP traffic on the net.
That means that bad guys can't forge packets that will give your
system bogus time.
The RFC hasn't been published yet (August 2020). Nothing has changed
recently, but there may be minor adjustments when it is finalized.
Note: The NTP Pool does not currently support NTS.
It is strongly suggested that you get a "normal", unauthenticated,
NTP server working before enabling NTS. This may reduce the time
spent debugging. See the link:quick.adoc[Client Quick Start Guide].
[[client]]
== NTS Client Configuration
Append the keyword `nts` to the end of your `server` lines. Do this only for
servers that speak NTS. If the server uses a port other than 4460 for NTS key
exchange, you also need to specify the port number. As of August 2020, the
following should work:
Public NTP servers supporting NTS:
------------------------------------------------------------
server time.cloudflare.com nts # Global, anycast
server nts.ntp.se:4443 nts # Sweden
------------------------------------------------------------
These are development machines, so there may be gaps in availability:
------------------------------------------------------------
server ntpmon.dcs1.biz nts # Singapore
server ntp1.glypnod.com nts # San Francisco
server ntp2.glypnod.com nts # London
------------------------------------------------------------
Note that you must use the same host name that was used to create
the server's certificate. IP addresses will not work.
This assumes that the server is using a certificate covered by
your OS/distro's root certificate collection.
NetBSD needs the +mozilla-rootcerts-openssl+ package and `ca /etc/openssl/certs/` added to the +server+ line.
Restart `ntpd`, and skip to link:#verify[Verification], below.
[[server]]
== NTS Server Configuration
Being an NTS server requires a well-formed SSL certificate. The
easiest way to do this is to use Let's Encrypt. It needs a FQDN.
Please see the
https://certbot.eff.org/[certbot client site] for instructions.
The following worked on Fedora:
------------------------------------------------------------
$ sudo dnf install certbot
# Install
$ sudo certbot certonly --standalone
# Renew
$ sudo certbot renew
$ sudo killall -HUP ntpd
------------------------------------------------------------
If you already have an SSL certificate for your server, and you are
serving time using the same FQDN, you can reuse that certificate.
Next, add the line:
`nts enable`
to your +{ntpconf}+ file.
Locate the following two files:
* Your certificate private key
* Your certificate chain (i.e. your certificate followed by any intermediate
CA certificates)
Then add the lines below to your +{ntpconf}+, replacing
with your pathnames.
Example, using Let's Encrypt:
------------------------------------------------------------
nts key /etc/letsencrypt/live/ntp.example.com/privkey.pem
nts cert /etc/letsencrypt/live/ntp.example.com/fullchain.pem
------------------------------------------------------------
Note that `ntpd` must be able to read both files and you want to
make sure that the bad guys can't read your private key. It may
be simpler to copy those files over to `/etc/ntpsec/` and adjust
their owner and mode so `ntpd` running as user `ntpsec` can read them.
You may need to tell your system where to store the keys used
to encrypt cookies. The default is `/var/lib/ntpsec/nts-keys`.
------------------------------------------------------------
nts cookie /var/lib/ntpsec/nts-keys
------------------------------------------------------------
Again, make sure the bad guys can't read that file.
Restart your server, and skip to link:#verify[Verification], below.
[[verify]]
== Verification
Check your log file. The current client side NTS implementation
is quite chatty. The log lines may change, but what you see should be
similar to below.
As a client, you should see lines like this:
------------------------------------------------------------
3 Sep 13:36:40 ntpd[89030]: DNS: dns_probe: time.cloudflare.com, cast_flags:1, flags:21a01
3 Sep 13:36:40 ntpd[89030]: NTSc: DNS lookup of time.cloudflare.com took 0.698 sec
3 Sep 13:36:40 ntpd[89030]: NTSc: connecting to time.cloudflare.com:4460 => 162.159.200.1:4460
3 Sep 13:36:41 ntpd[89030]: NTSc: set cert host: time.cloudflare.com
3 Sep 13:36:44 ntpd[89030]: NTSc: Using TLSv1.3, TLS_AES_256_GCM_SHA384 (256)
3 Sep 13:36:44 ntpd[89030]: NTSc: certificate subject name: /C=US/ST=California/L=San Francisco/O=Cloudflare, Inc./CN=time.cloudflare.com
3 Sep 13:36:44 ntpd[89030]: NTSc: certificate issuer name: /C=US/O=DigiCert Inc/CN=DigiCert ECC Secure Server CA
3 Sep 13:36:44 ntpd[89030]: NTSc: certificate is valid.
3 Sep 13:36:44 ntpd[89030]: NTSc: Good ALPN from time.cloudflare.com
3 Sep 13:36:46 ntpd[89030]: NTSc: read 750 bytes
3 Sep 13:36:46 ntpd[89030]: NTSc: Using port 123
3 Sep 13:36:46 ntpd[89030]: NTSc: Got 7 cookies, length 100, aead=15.
3 Sep 13:36:46 ntpd[89030]: NTSc: NTS-KE req to time.cloudflare.com took 6.063 sec, OK
3 Sep 13:36:46 ntpd[89030]: DNS: dns_check: processing time.cloudflare.com, 1, 21a01
3 Sep 13:36:46 ntpd[89030]: DNS: Server taking: 162.159.200.1
3 Sep 13:36:46 ntpd[89030]: DNS: Server poking hole in restrictions for: 162.159.200.1
3 Sep 13:36:46 ntpd[89030]: PROTO: 162.159.200.1 unlink local addr 127.0.0.1 -> 192.168.1.2
3 Sep 13:36:46 ntpd[89030]: DNS: dns_take_status: time.cloudflare.com=>good, 0
3 Sep 13:36:47 ntpd[89030]: PROTO: 162.159.200.1 e014 84 reachable
------------------------------------------------------------
For initializing a server, you should see lines like this:
------------------------------------------------------------
11 Aug 12:24:12 ntpd[789]: INIT: OpenSSL 1.1.1g FIPS 21 Apr 2020, 1010107f
11 Aug 12:24:12 ntpd[789]: NTSs: starting NTS-KE server listening on port 4460
11 Aug 12:24:12 ntpd[789]: NTSs: OpenSSL security level is 1
11 Aug 12:24:12 ntpd[789]: NTSs: starting NTS-KE server listening on port 4460
11 Aug 12:24:12 ntpd[789]: NTSs: listen4 worked
11 Aug 12:24:12 ntpd[789]: NTSs: listen6 worked
11 Aug 12:24:12 ntpd[789]: NTSc: Using system default root certificates.
11 Aug 12:24:12 ntpd[789]: NTSs: loaded certificate (chain) from /etc/ntp/fullchain.pem
11 Aug 12:24:12 ntpd[789]: NTSs: loaded private key from /etc/ntp/privkey.pem
11 Aug 12:24:12 ntpd[789]: NTSs: Private Key OK
------------------------------------------------------------
On a server, each time a client uses TLS to setup cookies,
you should see lines like these. If all goes well, there is a single
line for each connection.
------------------------------------------------------------
11 Aug 12:29:38 ntpd[789]: NTSs: NTS-KE from 64.139.1.69:49253, Using TLSv1.3, TLS_AES_256_GCM_SHA384 (256), took 0.437 sec
------------------------------------------------------------
Servers on the big bad internet will get a lot of garbage connections.
The common cases produce a single line. Less common cases will have additional lines with OpenSSL error data.
------------------------------------------------------------
26 Dec 18:13:55 ntpd[940892]: NTSs: SSL accept from 68.134.33.4:52188 failed: wrong version number, took 0.000 sec
26 Dec 18:24:20 ntpd[940892]: NTSs: SSL accept from 64.139.1.69:56525 failed, took 0.101 sec
26 Dec 18:24:20 ntpd[940892]: NTS: error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca
------------------------------------------------------------
`alert` means the client on the other end encountered troubles and is
reporting them back to the server.
The logging prefix *NTSs* is for the NTS server component. The *NTSc*
component is for the NTS client part, where your +ntpd+ is talking
to other NTS servers.
=== Check with ntpq
The output of ntpq will be slightly different when NTS is in use,
note the `t` column. Example:
------------------------------------------------------------
root@ntpmon:/var/www/html/ntp# ntpq -p
remote refid st t when poll reach delay offset jitter
*SHM(1) .PPS. 0 l 20 64 377 0.0000 0.0007 0.0281
xSHM(0) .GPS. 0 l 19 64 377 0.0000 233.3966 19.2212
+pi3.rellim.com .PPS. 1 8 56 64 371 197.4484 0.0932 0.9660
+kong.rellim.com 204.17.205.17 2 8 17 64 273 210.7230 -1.3924 0.6086
-ntp1.glypnod.com 204.123.2.72 2 8 50 64 277 178.5749 3.8921 0.9611
-ntp2.glypnod.com 17.253.34.253 2 8 - 64 177 185.7582 -2.6534 0.0275
2407:8000:8001:80::8 .DNS. 16 u - 1024 0 0.0000 0.0000 0.0005
-navobs1.wustl.edu .GPS. 1 u 105 64 356 221.5282 -2.4354 0.0293
------------------------------------------------------------
The `t` column shows how many cookies your NTS client is holding for the
appropriate servers. The number should be 8. Lower numbers indicate dropped
packets. (7 could be a packet in flight.)
The RFC calls for the server to rotate the private key used to
encrypt cookies every 24 hours. The server also saves the previous
key so old cookies will work for at least 24 hours. 24 hours and 8 cookies
will work for a polling interval of up to 3 hours. That's much longer
than the default +maxpoll+ of 10 (1024 seconds).
=== Check ntp variables
Try `ntpq -c nts`. This will show various counters related
to NTS. This feature is under active development, so the
format might change. An example:
------------------------------------------------------------
root@ntpmon:/var/www/html/ntp# ntpq -c nts
NTS client sends: 7491
NTS client recvs: 6562
NTS client recvs w error: 0
NTS server recvs: 5591
NTS server recvs w error: 38
NTS server sends: 5553
NTS make cookies: 6392
NTS decode cookies: 4734
NTS decode cookies old: 819
NTS decode cookies too old: 0
NTS decode cookies error: 0
NTS KE probes: 8
NTS KE probes_bad: 0
NTS KE serves: 75
NTS KE serves_bad: 56
------------------------------------------------------------
[[refer]]
== References
* https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp/[Current Status of NTS Draft]
* https://developers.cloudflare.com/time-services/nts/usage/[Cloudflare Public NTS Servers]
* https://www.netnod.se/blog/what-network-time-security-and-why-it-important[Netnod NTS Service]
* https://datatracker.ietf.org/meeting/106/materials/slides-106-ntp-nts-deployment-03.pdf[Deployment Review]
'''''
include::includes/footer.adoc[]
|
