-
Notifications
You must be signed in to change notification settings - Fork 10
/
draft-ietf-ntp-using-nts-for-ntp.xml
2283 lines (2111 loc) · 103 KB
/
draft-ietf-ntp-using-nts-for-ntp.xml
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
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-ntp-using-nts-for-ntp-28"
ipr="trust200902" submissionType="IETF">
<front>
<title abbrev="Network Time Security for NTP">Network Time Security for the Network Time
Protocol</title>
<author fullname="Daniel Fox Franke" initials="D." surname="Franke">
<organization abbrev="Akamai">Akamai Technologies</organization>
<address>
<postal>
<street>145 Broadway</street>
<city>Cambridge</city>
<region>MA</region>
<code>02142</code>
<country>United States</country>
</postal>
<email>dafranke@akamai.com</email>
</address>
</author>
<author fullname="Dieter Sibold" initials="D." surname="Sibold">
<organization abbrev="PTB">Physikalisch-Technische
Bundesanstalt</organization>
<address>
<postal>
<street>Bundesallee 100</street>
<city>Braunschweig</city>
<code>D-38116</code>
<region/>
<country>Germany</country>
</postal>
<phone>+49-(0)531-592-8420</phone>
<facsimile>+49-531-592-698420</facsimile>
<email>dieter.sibold@ptb.de</email>
</address>
</author>
<author fullname="Kristof Teichel" initials="K." surname="Teichel">
<organization abbrev="PTB">Physikalisch-Technische
Bundesanstalt</organization>
<address>
<postal>
<street>Bundesallee 100</street>
<city>Braunschweig</city>
<region/>
<code>D-38116</code>
<country>Germany</country>
</postal>
<phone>+49-(0)531-592-4471</phone>
<facsimile/>
<email>kristof.teichel@ptb.de</email>
<uri/>
</address>
</author>
<author fullname="Marcus Dansarie" initials="M." surname="Dansarie">
<address>
<postal>
<street />
<city />
<region />
<code />
<country>Sweden</country>
</postal>
<email>marcus@dansarie.se</email>
<uri>https://orcid.org/0000-0001-9246-0263</uri>
</address>
</author>
<author fullname="Ragnar Sundblad" initials="R." surname="Sundblad">
<organization>Netnod</organization>
<address>
<postal>
<street />
<city />
<region />
<code />
<country>Sweden</country>
</postal>
<email>ragge@netnod.se</email>
</address>
</author>
<date day="25" month="March" year="2020"/>
<area>Internet Area</area>
<workgroup>NTP Working Group</workgroup>
<keyword>Integrity</keyword>
<keyword>Authentication</keyword>
<keyword>NTP</keyword>
<keyword>Security</keyword>
<abstract>
<t>
This memo specifies Network Time Security (NTS), a mechanism
for using Transport Layer Security (TLS) and Authenticated
Encryption with Associated Data (AEAD) to provide
cryptographic security for the client-server mode of the
Network Time Protocol (NTP).
</t>
<t>
NTS is structured as a suite of two loosely coupled sub-protocols.
The first (NTS-KE) handles initial authentication and key
establishment over TLS. The second handles encryption and
authentication during NTP time synchronization via extension fields in the
NTP packets, and holds all required state only on the
client via opaque cookies.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
This memo specifies Network Time Security (NTS), a
cryptographic security mechanism for network time
synchronization. A complete specification is provided for
application of NTS to the client-server mode of the
<xref target="RFC5905">Network Time Protocol (NTP)</xref>.
</t>
<section title="Objectives">
<t>
The objectives of NTS are as follows:
<list style="symbols">
<t>
Identity: Through the use of a X.509 public key infrastructure,
implementations can cryptographically establish the identity of
the parties they are communicating with.
</t>
<t>
Authentication: Implementations can cryptographically
verify that any time synchronization packets are
authentic, i.e., that they were produced by an
identified party and have not been modified in transit.
</t>
<t>
Confidentiality: Although basic time synchronization
data is considered non-confidential and sent in the
clear, NTS includes support for encrypting NTP extension
fields.
</t>
<t>
Replay prevention: Client implementations can detect when
a received time synchronization packet is a replay of
a previous packet.
</t>
<t>
Request-response consistency: Client implementations can
verify that a time synchronization packet received from
a server was sent in response to a particular request from
the client.
</t>
<t>
Unlinkability: For mobile clients, NTS will not leak any
information additional to NTP which would permit a
passive adversary to determine that two packets sent
over different networks came from the same client.
</t>
<t>
Non-amplification: Implementations (especially server
implementations) can avoid acting as distributed
denial-of-service (DDoS) amplifiers by never responding to a
request with a packet larger than the request packet.
</t>
<t>
Scalability: Server implementations can serve large
numbers of clients without having to retain any
client-specific state.
</t>
<t>
Performance: NTS must not significantly degrade the
quality of the time transfer. The encryption and
authentication used when actually transferring time
should be lightweight (see <xref target="RFC7384">RFC
7384, Section 5.7</xref>).
</t>
</list>
</t>
</section>
<section title="Protocol Overview" anchor="sec-protocol-overview">
<t>
The Network Time Protocol includes many different operating modes to
support various network topologies (see <xref target="RFC5905">RFC 5905,
Section 3</xref>). In addition to its best-known and
most-widely-used client-server mode, it also includes modes for
synchronization between symmetric peers, a control mode for server
monitoring and administration, and a broadcast mode. These various
modes have differing and partly contradictory requirements for
security and performance. Symmetric and control modes demand mutual
authentication and mutual replay protection. Additionally, for certain
message types control mode may require confidentiality as well as
authentication. Client-server mode places more stringent requirements
on resource utilization than other modes, because servers may have
vast number of clients and be unable to afford to maintain per-client
state. However, client-server mode also has more relaxed security
needs, because only the client requires replay protection: it is
harmless for stateless servers to process replayed packets. The
security demands of symmetric and control modes, on the other hand,
are in conflict with the resource-utilization demands of client-server
mode: any scheme which provides replay protection inherently involves
maintaining some state to keep track of what messages have already
been seen.
</t>
<t>
This memo specifies NTS exclusively for the client-server mode of NTP.
To this end, NTS is structured as a suite of two protocols:
<list>
<t>
The "NTS Extensions for NTPv4" define a collection of NTP
extension fields for cryptographically securing NTPv4 using
previously-established key material. They are suitable for
securing client-server mode because the server can implement them
without retaining per-client state. All state is kept by the
client and provided to the server in the form of an encrypted
cookie supplied with each request. On the other hand, the NTS
Extension Fields are suitable *only* for client-server mode
because only the client, and not the server, is protected from
replay.
</t>
<t>
The "NTS Key Establishment" protocol (NTS-KE) is a
mechanism for establishing key material for use with the NTS
Extension Fields for NTPv4. It uses TLS to establish keys, provide
the client with an initial supply of cookies, and negotiate some
additional protocol options. After this, the TLS channel
is closed with no per-client state remaining on the server side.
</t>
</list>
</t>
<t>
The typical protocol flow is as follows: The client connects to an
NTS-KE server on the NTS TCP port and the two parties perform a TLS
handshake. Via the TLS channel, the parties negotiate some additional
protocol parameters and the server sends the client a supply of
cookies along with an address and port of an NTP server
for which the cookies are valid. The parties use
<xref target="RFC5705">TLS key export</xref> to extract key material
which will be used in the next phase of the protocol. This negotiation
takes only a single round trip, after which the server closes the
connection and discards all associated state. At this point the NTS-KE
phase of the protocol is complete. Ideally, the client never needs to
connect to the NTS-KE server again.
</t>
<t>
Time synchronization proceeds with the indicated NTP server.
The client sends the server an NTP client
packet which includes several extension fields. Included among these
fields are a cookie (previously provided by the key establishment server)
and an authentication tag, computed using key material extracted from
the NTS-KE handshake. The NTP server uses the cookie to recover this
key material and send back an authenticated response. The response
includes a fresh, encrypted cookie which the client then sends back in
the clear in a subsequent request. (This constant refreshing of
cookies is necessary in order to achieve NTS's unlinkability goal.)
</t>
<t>
<xref target="protocol-overview"/> provides an overview of the
high-level interaction between the client, the NTS-KE server, and the
NTP server. Note that the cookies' data format and the exchange of
secrets between NTS-KE and NTP servers are not part of this
specification and are implementation dependent. However, a suggested
format for NTS cookies is provided in
<xref target="suggested-format-for-nts-cookies"/>.
</t>
<figure anchor="protocol-overview"
title="Overview of High-Level Interactions in NTS">
<artwork><![CDATA[
+--------------+
| |
+-> | NTP Server 1 |
| | |
Shared cookie | +--------------+
+---------------+ encryption parameters | +--------------+
| | (Implementation dependent) | | |
| NTS-KE Server | <------------------------------+-> | NTP Server 2 |
| | | | |
+---------------+ | +--------------+
^ | .
| | .
| 1. Negotiate parameters, | .
| receive initial cookie | +--------------+
| supply, generate AEAD keys, | | |
| and receive NTP server IP +-> | NTP Server N |
| addresses using "NTS Key | |
| Establishment" protocol. +--------------+
| ^
| |
| +----------+ |
| | | |
+-----------> | Client | <-------------------------+
| | 2. Perform authenticated
+----------+ time synchronization
and generate new
cookies using "NTS
Extension Fields for
NTPv4".]]>
</artwork>
</figure>
</section>
</section>
<section title="Requirements Language">
<t>
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 <xref target="RFC2119" /> <xref target="RFC8174" /> when,
and only when, they appear in all capitals, as shown here.
</t>
</section>
<section title="TLS profile for Network Time Security" anchor="tls-profile">
<t>
Network Time Security makes use of TLS for NTS key establishment.
</t>
<t>
Since the NTS protocol is new as of this publication, no
backward-compatibility concerns exist to justify using
obsolete, insecure, or otherwise broken TLS features or
versions. Implementations MUST conform with <xref
target="RFC7525">RFC 7525</xref> or with a later revision of BCP
195.
</t>
<t>
Implementations MUST NOT negotiate TLS versions earlier than 1.3
<xref target="RFC8446"/> and MAY refuse to negotiate any TLS version
which has been superseded by a later supported version.
</t>
<t>
Use of the <xref target="RFC7301">Application-Layer Protocol
Negotiation Extension</xref> is integral to NTS and support for
it is REQUIRED for interoperability.
</t>
<t>
Implementations MUST follow the rules in <xref target="RFC5280">
RFC 5280</xref> and <xref target="RFC6125">RFC 6125</xref> for the
representation and verification of the application's service identity.
When NTS-KE service discovery (out of scope for this document)
produces one or more host names, use of the
<xref target="RFC6125">DNS-ID identifier type</xref> is RECOMMENDED;
specifications for service discovery mechanisms can provide additional
guidance for certificate validation based on the results of
discovery. <xref target="sec-cert-verification" /> of this memo
discusses particular considerations for certificate verification in
the context of NTS.
</t>
</section>
<section title="The NTS Key Establishment Protocol" anchor="nts-ke">
<t>
The NTS key establishment protocol is conducted via TCP port [[TBD1]].
The two endpoints carry out a TLS handshake in conformance with
<xref target="tls-profile"/>, with the client offering (via an
<xref target="RFC7301">ALPN</xref> extension), and the server accepting,
an application-layer protocol of "ntske/1". Immediately
following a successful handshake, the client SHALL send a single request
as Application Data encapsulated in the TLS-protected channel. Then, the
server SHALL send a single response. After sending their respective
request and response, the client and server SHALL send TLS
"close_notify" alerts in accordance with
<xref target="RFC8446">RFC 8446, Section 6.1</xref>.
</t>
<t>
The client's request and the server's response each SHALL consist of a
sequence of records formatted according to
<xref target="ntske-record"/>. The request and a non-error response each
SHALL include exactly one NTS Next Protocol Negotiation record. The
sequence SHALL be terminated by a "End of Message" record. The
requirement that all NTS-KE messages be terminated by an End of Message
record makes them self-delimiting.
</t>
<t>
Clients and servers MAY enforce length limits on requests and responses,
however, servers MUST accept requests of at least 1024 octets and
clients SHOULD accept responses of at least 65536 octets.
</t>
<figure anchor="ntske-record" title="NTS-KE Record Format">
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| Record Type | Body Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Record Body .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
<t>
The fields of an NTS-KE record are defined as follows:
<list>
<t>
C (Critical Bit): Determines the disposition of unrecognized Record
Types. Implementations which receive a record with an unrecognized
Record Type MUST ignore the record if the Critical Bit is 0 and MUST
treat it as an error if the Critical Bit is 1 (see <xref target="nts-error"/>).
</t>
<t>
Record Type Number: A 15-bit integer in network byte order. The
semantics of record types 0–7 are specified in this memo.
Additional type numbers SHALL be tracked through the IANA Network
Time Security Key Establishment Record Types registry.
</t>
<t>
Body Length: The length of the Record Body field, in octets, as a
16-bit integer in network byte order. Record bodies MAY have any
representable length and need not be aligned to a word boundary.
</t>
<t>
Record Body: The syntax and semantics of this field SHALL be
determined by the Record Type.
</t>
</list>
</t>
<t>
For clarity regarding bit-endianness: the Critical Bit is the
most-significant bit of the first octet. In the C programming language,
given a network buffer
`unsigned char b[]` containing an NTS-KE record, the critical bit is
`b[0] >> 7` while the record type is
`((b[0] & 0x7f) << 8) + b[1]`.
</t>
<t>
Note that, although the Type-Length-Body format of an NTS-KE record is
similar to that of an NTP extension field, the semantics of the length
field differ. While the length subfield of an NTP extension field gives
the length of the entire extension field including the type and length
subfields, the length field of an NTS-KE record gives just the length
of the body.
</t>
<t>
<xref target="fig_NTSKeyEstablishment"/> provides a schematic overview of the
key establishment. It displays the protocol steps to be performed by the NTS
client and server and record types to be exchanged.
</t>
<figure anchor="fig_NTSKeyEstablishment" title="NTS Key Establishment Messages">
<artwork><![CDATA[
+---------------------------------------+
| - Verify client request message. |
| - Extract TLS key material. |
| - Generate KE response message. |
| - Include Record Types: |
| o NTS Next Protocol Negotiation |
| o AEAD Algorithm Negotiation |
| o <NTPv4 Server Negotiation> |
| o <NTPv4 Port Negotiation> |
| o New Cookie for NTPv4 |
| o <New Cookie for NTPv4> |
| o End of Message |
+-----------------+---------------------+
|
|
Server -----------+---------------+-----+----------------------->
^ \
/ \
/ TLS application \
/ data \
/ \
/ V
Client -----+---------------------------------+----------------->
| |
| |
| |
+-----------+----------------------+ +------+-----------------+
|- Generate KE request message. | |- Verify server response|
| - Include Record Types: | | message. |
| o NTS Next Protocol Negotiation | |- Extract cookie(s). |
| o AEAD Algorithm Negotiation | +------------------------+
| o <NTPv4 Server Negotiation> |
| o <NTPv4 Port Negotiation> |
| o End of Message |
+----------------------------------+]]>
</artwork>
</figure>
<section title="NTS-KE Record Types">
<t>The following NTS-KE Record Types are defined:</t>
<section title="End of Message" anchor="end-of-message">
<t>
The End of Message record has a Record Type number of 0 and a
zero-length body. It MUST occur exactly once as the final record of
every NTS-KE request and response. The Critical Bit MUST be set.
</t>
</section>
<section title="NTS Next Protocol Negotiation"
anchor="nts-next-protocol-negotiation">
<t>
The NTS Next Protocol Negotiation record has a Record Type number
of 1. It MUST occur exactly once in every NTS-KE request and
response. Its body consists of a sequence of 16-bit unsigned
integers in network byte order. Each integer represents a Protocol
ID from the IANA Network Time Security Next Protocols registry. The
Critical Bit MUST be set.
</t>
<t>
The Protocol IDs listed in the client's NTS Next Protocol
Negotiation record denote those protocols which the client wishes to
speak using the key material established through this NTS-KE
session. Protocol IDs listed in the NTS-KE server's response MUST
comprise a subset of those listed in the request and
denote those protocols which the NTP server is willing and
able to speak using the key material established through
this NTS-KE session. The client MAY
proceed with one or more of them. The request MUST list at least one
protocol, but the response MAY be empty.
</t>
</section>
<section title="Error" anchor="nts-error">
<t>
The Error record has a Record Type number of 2. Its body is exactly
two octets long, consisting of an unsigned 16-bit integer in network
byte order, denoting an error code. The Critical Bit MUST be set.
</t>
<t>
Clients MUST NOT include Error records in their request. If clients
receive a server response which includes an Error record, they MUST
discard any key material negotiated during the initial TLS exchange
and MUST NOT proceed to the Next Protocol. Requirements for retry
intervals are described in <xref target="nts-ke-retry" />.
</t>
<t>
The following error codes are defined:
<list>
<t>
Error code 0 means "Unrecognized Critical Record". The
server MUST respond with this error code if the request included
a record which the server did not understand and which had its
Critical Bit set. The client SHOULD NOT retry its request
without modification.
</t>
<t>
Error code 1 means "Bad Request". The server MUST
respond with this error if the request is not complete
and syntactically well-formed, or, upon the expiration
of an implementation-defined timeout, it has not yet
received such a request. The client SHOULD NOT retry its
request without modification.
</t>
<t>
Error code 2 means "Internal Server Error". The server
MUST respond with this error if it is unable to respond properly
due to an internal condition. The client MAY retry its request.
</t>
</list>
</t>
</section>
<section title="Warning" anchor="nts-warning">
<t>
The Warning record has a Record Type number of 3. Its body is
exactly two octets long, consisting of an unsigned 16-bit integer in
network byte order, denoting a warning code. The Critical Bit MUST
be set.
</t>
<t>
Clients MUST NOT include Warning records in their request. If
clients receive a server response which includes a Warning record,
they MAY discard any negotiated key material and abort without
proceeding to the Next Protocol. Unrecognized warning codes MUST be
treated as errors.
</t>
<t>
This memo defines no warning codes.
</t>
</section>
<section title="AEAD Algorithm Negotiation"
anchor="aead-algorithm-negotiation">
<t>
The AEAD Algorithm Negotiation record has a Record Type number of 4.
Its body consists of a sequence of unsigned 16-bit integers in
network byte order, denoting Numeric Identifiers from the IANA
<xref target="IANA-AEAD">AEAD Algorithms registry</xref>. The
Critical Bit MAY be set.
</t>
<t>
If the NTS Next Protocol Negotiation record offers Protocol ID 0
(for NTPv4), then this record MUST be included exactly once. Other
protocols MAY require it as well.
</t>
<t>
When included in a request, this record denotes which AEAD
algorithms the client is willing to use to secure the Next Protocol,
in decreasing preference order. When included in a response, this
record denotes which algorithm the server chooses to use. It is
empty if the server supports none of the algorithms offered. In
requests, the list MUST include at least one algorithm. In
responses, it MUST include at most one. Honoring the client's
preference order is OPTIONAL: servers may select among any of the
client's offered choices, even if they are able to support some
other algorithm which the client prefers more.
</t>
<t>
Server implementations of <xref
target="nts-extension-fields-for-ntpv4">NTS extension fields for
NTPv4</xref> MUST support <xref
target="RFC5297">AEAD_AES_SIV_CMAC_256</xref> (Numeric Identifier
15). That is, if the client includes AEAD_AES_SIV_CMAC_256 in its
AEAD Algorithm Negotiation record and the server accepts Protocol
ID 0 (NTPv4) in its NTS Next Protocol Negotiation record, then the
server's AEAD Algorithm Negotiation record MUST NOT be empty.
</t>
</section>
<section title="New Cookie for NTPv4" anchor="new-cookie-for-ntpv4">
<t>
The New Cookie for NTPv4 record has a Record Type number of 5. The
contents of its body SHALL be implementation-defined and clients
MUST NOT attempt to interpret them. See <xref
target="suggested-format-for-nts-cookies"/> for a suggested
construction.
</t>
<t>
Clients MUST NOT send records of this type. Servers MUST send at
least one record of this type, and SHOULD send eight of them, if the
Next Protocol Negotiation response record contains Protocol ID 0
(NTPv4) and the AEAD Algorithm Negotiation response record is not
empty. The Critical Bit SHOULD NOT be set.
</t>
</section>
<section title="NTPv4 Server Negotiation"
anchor="ntp-server-negotiation">
<t>
The NTPv4 Server Negotiation record has a Record Type number of 6.
Its body consists of an
<xref target="RFC0020">ASCII-encoded</xref> string. The
contents of the string SHALL be either an IPv4 address, an IPv6
address, or a fully qualified domain name (FQDN). IPv4 addresses
MUST be in dotted decimal notation. IPv6 addresses MUST conform to
the "Text Representation of Addresses" as specified in
<xref target="RFC4291">RFC 4291</xref> and MUST NOT include zone
identifiers <xref target="RFC6874"/>. If a label contains at least
one non-ASCII character, it is an internationalized domain name
and an A-LABEL MUST be used as defined in
Section 2.3.2.1 of <xref target="RFC5890">RFC 5890</xref>.
If the record contains a domain name, the recipient MUST treat it
as a FQDN, e.g. by making sure it ends with a dot.
</t>
<t>
When NTPv4 is negotiated as a Next Protocol and this
record is sent by the server, the body specifies the
hostname or IP address of the NTPv4 server with which the
client should associate and which will accept the supplied
cookies. If no record of this type is sent, the client
SHALL interpret this as a directive to associate with an
NTPv4 server at the same IP address as the NTS-KE server.
Servers MUST NOT send more than one record of this type.
</t>
<t>
When this record is sent by the client, it indicates that
the client wishes to associate with the specified NTP
server. The NTS-KE server MAY incorporate this request when
deciding what NTPv4 Server Negotiation records to respond
with, but honoring the client's preference is
OPTIONAL. The client MUST NOT send more than one record of
this type.
</t>
<t>
If the client has sent a record of this type, the NTS-KE server
SHOULD reply with the same record if it is valid and the server is
able to supply cookies for it. If the client has not sent any
record of this type, the NTS-KE server SHOULD respond with either
an NTP server address in the same family as the NTS-KE session or
a FQDN that can be resolved to an address in that family, if such
alternatives are available.
</t>
<t>
Servers MAY set the Critical Bit on records of this type;
clients SHOULD NOT.
</t>
</section>
<section title="NTPv4 Port Negotiation"
anchor="ntp-port-negotiation">
<t>
The NTPv4 Port Negotiation record has a Record Type number
of 7. Its body consists of a 16-bit unsigned integer in
network byte order, denoting a UDP port number.
</t>
<t>
When NTPv4 is negotiated as a Next Protocol and this
record is sent by the server, the body specifies the port
number of the NTPv4 server with which the client should
associate and which will accept the supplied cookies. If
no record of this type is sent, the client SHALL assume
a default of 123 (the registered port number for NTP).
</t>
<t>
When this record is sent by the client in conjunction with
a NTPv4 Server Negotiation record, it indicates that the
client wishes to associate with the NTP server at the
specified port. The NTS-KE server MAY incorporate this
request when deciding what NTPv4 Server Negotiation and
NTPv4 Port Negotiation records to respond with, but
honoring the client's preference is OPTIONAL.
</t>
<t>
Servers MAY set the Critical Bit on records of this type;
clients SHOULD NOT.
</t>
</section>
</section>
<section title="Retry Intervals" anchor="nts-ke-retry">
<t>
A mechanism for not unnecessarily overloading the NTS-KE server is
REQUIRED when retrying the key establishment process due to protocol,
communication, or other errors. The exact workings of this will be
dependent on the application and operational experience gathered over
time. Until such experience is available, this memo provides the
following suggestion.
</t>
<t>
Clients SHOULD use exponential backoff, with an initial and minimum
retry interval of 10 seconds, a maximum retry interval of 5 days, and
a base of 1.5. Thus, the minimum interval in seconds, `t`, for the nth
retry is calculated with
<list style="empty">
<t>
t = min(10 * 1.5^(n-1), 432000).
</t>
</list>
</t>
<t>
Clients MUST NOT reset the retry interval until they have performed
a successful key establishment with the NTS-KE server, followed by a
successful use of the negotiated next protocol with the keys and data
established during that transaction.
</t>
</section>
<section title="Key Extraction (generally)" anchor="key-extraction">
<t>
Following a successful run of the NTS-KE protocol, key material SHALL
be extracted using <xref target="RFC5869">the HMAC-based
Extract-and-Expand Key Derivation Function (HKDF)</xref> in
accordance with <xref target="RFC8446">RFC 8446, Section 7.5</xref>.
Inputs to the exporter function are to be constructed in a manner
specific to the negotiated Next Protocol. However, all protocols which
utilize NTS-KE MUST conform to the following two rules:
<list>
<t>
The <xref target="RFC5705">disambiguating label string</xref> MUST
be "EXPORTER-network-time-security".
</t>
<t>
The <xref target="RFC5705">per-association context value</xref>
MUST be provided and MUST begin with the two-octet Protocol ID
which was negotiated as a Next Protocol.
</t>
</list>
</t>
</section>
</section>
<section title="NTS Extension Fields for NTPv4"
anchor="nts-extension-fields-for-ntpv4">
<section title="Key Extraction (for NTPv4)">
<t>
Following a successful run of the NTS-KE protocol wherein Protocol
ID 0 (NTPv4) is selected as a Next Protocol, two AEAD keys SHALL be
extracted: a client-to-server (C2S) key and a server-to-client (S2C)
key. These keys SHALL be computed with the HKDF defined in
<xref target="RFC8446">RFC 8446, Section 7.5</xref> using the
following inputs.
<list>
<t>
The <xref target="RFC5705">disambiguating label string</xref>
SHALL be "EXPORTER-network-time-security".
</t>
<t>
The <xref target="RFC5705">per-association context value</xref>
SHALL consist of the following five octets:
<list>
<t>
The first two octets SHALL be zero (the Protocol ID for
NTPv4).
</t>
<t>
The next two octets SHALL be the Numeric Identifier of the
negotiated AEAD Algorithm in network byte order.
</t>
<t>
The final octet SHALL be 0x00 for the C2S key and 0x01 for the
S2C key.
</t>
</list>
</t>
</list>
Implementations wishing to derive additional keys for private or
experimental use MUST NOT do so by extending the above-specified
syntax for per-association context values. Instead, they SHOULD use
their own disambiguating label string. Note that <xref
target="RFC5705">RFC 5705</xref> provides that disambiguating label
strings beginning with "EXPERIMENTAL" MAY be used without
IANA registration.
</t>
</section>
<section title="Packet Structure Overview">
<t>
In general, an NTS-protected NTPv4 packet consists of:
<list>
<t>
The usual 48-octet NTP header which is authenticated but not
encrypted.
</t>
<t>
Some extension fields which are authenticated but not encrypted.
</t>
<t>
An extension field which contains AEAD output (i.e., an
authentication tag and possible ciphertext). The corresponding
plaintext, if non-empty, consists of some extension fields which
benefit from both encryption and authentication.
</t>
<t>
Possibly, some additional extension fields which are neither
encrypted nor authenticated. In general, these are discarded by the
receiver.
</t>
</list>
</t>
<t>
Always included among the authenticated or authenticated-and-encrypted
extension fields are a cookie extension field and a unique identifier
extension field, as described in Section 5.7. The purpose of the
cookie extension field is to enable the server to offload storage of
session state onto the client. The purpose of the unique identifier
extension field is to protect the client from replay attacks.
</t>
</section>
<section title="The Unique Identifier Extension Field"
anchor="unique-identifier-extension-field">
<t>
The Unique Identifier extension field provides the client with a
cryptographically strong means of detecting replayed packets. It has a
Field Type of [[TBD2]]. When the extension field is included in a
client packet (mode 3), its body SHALL consist of a string of octets
generated by a <xref target="RFC4086">cryptographically secure random
number generator</xref>. The string MUST be at least 32 octets
long. When the extension field is included in a server packet
(mode 4), its body SHALL contain the same octet string as was provided
in the client packet to which the server is responding. All server
packets generated by NTS-implementing servers in response to client
packets containing this extension field MUST also contain this field
with the same content as in the client's request. The field's use in
modes other than client-server is not defined.
</t>
<t>
This extension field MAY also be used standalone, without NTS, in
which case it provides the client with a means of detecting spoofed
packets from off-path attackers. Historically, NTP's origin timestamp
field has played both these roles, but for cryptographic purposes this
is suboptimal because it is only 64 bits long and, depending on
implementation details, most of those bits may be predictable. In
contrast, the Unique Identifier extension field enables a degree of
unpredictability and collision resistance more consistent with
cryptographic best practice.
</t>
</section>
<section title="The NTS Cookie Extension Field"
anchor="nts-cookie-extension-field">
<t>
The NTS Cookie extension field has a Field Type of [[TBD3]]. Its
purpose is to carry information which enables the server to recompute
keys and other session state without having to store any per-client
state. The contents of its body SHALL be implementation-defined and
clients MUST NOT attempt to interpret them. See <xref
target="suggested-format-for-nts-cookies"/> for a suggested
construction. The NTS Cookie extension field MUST NOT be included in
NTP packets whose mode is other than 3 (client) or 4 (server).
</t>
</section>
<section title="The NTS Cookie Placeholder Extension Field"
anchor="nts-cookie-placeholder-extension-field">
<t>
The NTS Cookie Placeholder extension field has a Field Type of
[[TBD4]]. When this extension field is included in a client packet
(mode 3), it communicates to the server that the client wishes it to
send additional cookies in its response. This extension field MUST NOT
be included in NTP packets whose mode is other than 3.
</t>
<t>
Whenever an NTS Cookie Placeholder extension field is present, it MUST
be accompanied by an NTS Cookie extension field. The body length of
the NTS Cookie Placeholder extension field MUST be the same as the
body length of the NTS Cookie extension field. This length requirement
serves to ensure that the response will not be larger than the
request, in order to improve timekeeping precision and prevent DDoS
amplification. The contents of the NTS Cookie Placeholder extension
field's body SHOULD be all zeros and, aside from checking its length,
MUST be ignored by the server.
</t>
</section>
<section title="The NTS Authenticator and Encrypted Extension Fields Extension Field"
anchor="nts-aeef-extension-field">
<t>
The NTS Authenticator and Encrypted Extension Fields extension field
is the central cryptographic element of an NTS-protected NTP packet.
Its Field Type is [[TBD5]]. It SHALL be formatted according to
<xref target="fig-aeef-field"/> and include the following fields:
<list>
<t>
Nonce Length: Two octets in network byte order, giving the length
of the Nonce field, excluding any padding, interpreted as an
unsigned integer.
</t>
<t>
Ciphertext Length: Two octets in network byte order, giving the
length of the Ciphertext field, excluding any padding, interpreted
as an unsigned integer.
</t>
<t>
Nonce: A nonce as required by the negotiated AEAD Algorithm. The
end of the field is zero-padded to a word (four octets) boundary.
</t>
<t>
Ciphertext: The output of the negotiated AEAD Algorithm. The
structure of this field is determined by the negotiated algorithm,
but it typically contains an authentication tag in addition to the
actual ciphertext. The end of the field is zero-padded to a word
(four octets) boundary.
</t>
<t>
Additional Padding: Clients which use a nonce length shorter than
the maximum allowed by the negotiated AEAD algorithm may be required
to include additional zero-padding. The necessary length of this
field is specified below.
</t>
</list>
</t>
<figure anchor="fig-aeef-field"
title="NTS Authenticator and Encrypted Extension Fields Extension Field Format">
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce Length | Ciphertext Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Nonce, including up to 3 octets padding .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+