forked from dfoxfranke/nts
-
Notifications
You must be signed in to change notification settings - Fork 0
/
nts.xml
1392 lines (1380 loc) · 61.7 KB
/
nts.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'?>
<?rfc toc="yes" comments="yes"?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' [
<!ENTITY rfc2119 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml'> <!--Requirements-->
<!ENTITY rfc3394 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3394.xml'> <!--Key wrap-->
<!ENTITY rfc3629 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3629.xml'>
<!ENTITY rfc4634 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4634.xml'> <!--HMAC-SHA-->
<!ENTITY rfc5077 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5077.xml'> <!--Session tickets-->
<!ENTITY rfc5116 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5116.xml'> <!--AEAD-->
<!ENTITY rfc5705 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5705.xml'> <!--Key export-->
<!ENTITY rfc5746 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5746.xml'> <!--Key export-->
<!ENTITY rfc5905 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5905.xml'> <!--NTP-->
<!ENTITY rfc6347 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6347.xml'> <!--DTLS-->
<!ENTITY rfc7301 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7301.xml'> <!--ALPN-->
<!ENTITY rfc7384 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7384.xml'> <!--Security considerations-->
<!ENTITY rfc7507 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7507.xml'>
<!ENTITY rfc7465 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7465.xml'>
<!ENTITY rfc7627 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7627.xml'>
<!ENTITY rfc7821 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7821.xml'>
<!ENTITY rfc7822 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7822.xml'>
]>
<rfc docName="draft-dfranke-nts-00"
category="std"
xml:lang="en">
<front>
<title>
Network Time Security
</title>
<author fullname="Daniel Fox Franke" initials="D" surname="Franke">
<organization abbrev="Akamai">Akamai Technologies, Inc.</organization>
<address>
<postal>
<street>150 Broadway</street>
<city>Cambridge</city>
<region>MA</region>
<code>02142</code>
<country>United States</country>
</postal>
<email>[email protected]</email>
<uri>https://www.dfranke.us</uri>
</address>
</author>
<date/>
</front>
<middle>
<section title="Introduction">
<t>
This memo specifies Network Time Security (NTS), a mechanism
for using <xref target="RFC6347">Datagram Transport Layer
Security</xref> (DTLS) to provide cryptographic security for
network time synchronization. A complete specification is
provided for applying NTS to the <xref target="RFC5905">Network
Time Protocol</xref>. Certain sections, however, are not
inherently NTP-specific and include guidance on how future
work may apply them to other time synchronization protocols
such as the <xref target="IEC.61588_2009">Precision Time
Protocol</xref>.
</t>
<t>
The Network Time Protocol includes many different operating
modes to support various network topologies. In addition to
its best-known and most-widely-used client/server mode, it
also includes modes for synchronization between symmetric
peers, a broadcast mode, and a control mode for server
monitoring and administration. These various modes have
differing and contradictory requirements for security and
performance. Symmetric and control modes demand mutual
authentication and mutual replay protection, and 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 servers to process
replayed packets.
</t>
<t>
The security demands of symmetric and control modes 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. Since therefore no single approach can
simultaneously satisfy the needs of all modes, Network Time
Security consists of not one protocol but a suite of them:
<list>
<t>
The "NTS-encapsulated NTPv4" protocol is little
more than "NTP over DTLS": the two endpoints
perform a DTLS handshake and then exchange NTP packets
encapsulated as DTLS Application Data. It is suitable for
symmetric and control modes, and is also secure for
client/server mode but relatively wasteful of server
resources.
</t>
<t>
The "NTS Key Establishment" protocol (NTS-KE) uses
DTLS to establish key material and negotiate some additional
protocol options, but then quickly closes the DTLS channel
and does not use it for the exchange of time packets. NTS-KE
is designed to be extensible, and might be extended to
support key establishment for other protocols such as PTP.
</t>
<t>
The "NTS extensions for NTPv4" are a collection of NTP
extension fields for cryptographically securing NTPv4 using
key material previously negotiated using NTS-KE. They are
suitable for securing client/server mode because the server
can implement them without retaining per-client state, but
on the other hand are suitable *only* for client/server mode
because only the client, and not the server, is protected
from replay.
</t>
</list>
</t>
</section>
<section title="Requirements Language">
<t>
The key words "MUST", "MUST NOT",
"REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as
described in <xref target="RFC2119">RFC 2119</xref>.
</t>
</section>
<section title="DTLS profile for Network Time Security" anchor="dtls-profile">
<t>
Since securing time protocols is (as of 2016) a novel
application of DTLS, no backward-compatibility concerns exist
to justify using obsolete, insecure, or otherwise broken DTLS
features or versions. We therefore put forward the following
requirements and guidelines, roughly representing 2016's best
practices.
</t>
<t>
Implementations MUST NOT negotiate DTLS versions earlier than
1.2.
</t>
<t>
Implementations willing to negotiate more than one possible
version of DTLS SHOULD NOT respond to handshake failures by
retrying with a downgraded protocol version. If they do, they
MUST implement <xref target="RFC7507"/>.
</t>
<t>
DTLS clients MUST NOT offer, and DTLS servers MUST not select,
RC4 cipher suites. <xref target="RFC7465"/>
</t>
<t>
DTLS clients SHOULD offer, and DTLS servers SHOULD accept, the
<xref target="RFC5746">TLS Renegotiation Indication
Extension</xref>. Regardless, they MUST NOT initiate or permit
insecure renegotiation. (*)
</t>
<t>
DTLS clients SHOULD offer, and DTLS servers SHOULD accept, the
<xref target="RFC7627">TLS Session Hash and Extended Master
Secret Extension</xref>. (*)
</t>
<t>
Use of the <xref target="RFC7301">Application-Layer Protocol
Negotation Extension</xref> is integral to NTS and support for
it is REQUIRED for interoperability.
</t>
<t>
(*): Note that DTLS 1.3 or beyond may render the indicated
recommendations inapplicable.
</t>
</section>
<section title="Transport mechanisms for DTLS records"
anchor="transport-mechanisms">
<t>
This section specifies two mechanisms, one REQUIRED and one
OPTIONAL, for exchanging NTS-related DTLS records. It is
intended that the choice of transport mechanism be orthogonal
to any concerns at the application layer: DTLS records SHOULD
receive identical disposition regardless of which mechanism
they arrive by.
</t>
<section title="Transport via NTS port">
<t>
In this transport mechanism, DTLS records, formatted
according to <xref target="RFC6347">RFC 6347</xref> or a
subsequent revision thereof, are exchanged directly on UDP
port [[TBD]], with one DTLS record per UDP packet and no
additional layer of encapsulation between the UDP header
and the DTLS record.
Servers which implement NTS MUST support this mechanism.
</t>
</section>
<section title="Transport via NTP extension field">
<t>
In this transport mechanism, DTLS records are exchanged
within extension fields of specially-formed NTP packets,
which are themselves exchanged via the usual NTP service
port (123/udp). NTP packets conveying DTLS records SHALL be
formatted as in <xref target="dtls-packet-layout"/>. They
MUST NOT contain any other extensions or a legacy MAC field.
</t>
<figure anchor="dtls-packet-layout"
title="Format of NTP packets conveying DTLS records">
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. NTP Header (48 octets) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension Type | Extension Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. DTLS Record (variable) .
. .
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+ +
| |
. .
. Padding (1-24 octets) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
<t>
Within the NTP header,
<list>
<t>The Leap Indicator field SHALL be set to 3 (unsynchronized).</t>
<t>The Version Number field SHALL be set to 4.</t>
<t>
DTLS clients SHALL set the Mode field to 3, and DTLS
servers SHALL set the Mode field to 4, even if the DTLS
record is being used (in the full-encapsulation
protocol) to protect some NTP mode other than
client/server.
</t>
<t>The Stratum field SHALL be set to 0 (unspecified or invalid).</t>
<t>
The Reference ID field (conveying a kiss code) SHALL be
set to "DTLS"
</t>
<t>
DTLS servers SHALL set the origin timestamp field from
the transmit timestamp field of the packet most recently
received from the client.
</t>
<t>
All other header fields MUST be ignored by the receiver,
and MAY contain arbitrary or bogus values.
</t>
</list>
</t>
<t>
The Extension Type field SHALL be set to [[TBD]]. The
Extension Length field SHALL be computed and set as per
<xref target="RFC7822">RFC 7822</xref>.
</t>
<t>
The DTLS Record field SHALL contain a DTLS Record formatted
as per <xref target="RFC6347">RFC 6347</xref> or a subsequent
revision thereof.
</t>
<t>
The Padding field SHALL contain between 1 and 24 octets of
padding, with every octet set to the number of padding
octets included, e.g., "01", "02 02", or
"03 03 03". The number of padding bytes should be
chosen in order to comply with the <xref
target="RFC7822">RFC 7822</xref> requirement that (in the
absence of a legacy MAC) extensions have a total length in
octets (including the four octets for the type and length
fields) which is at least 28 and divisible by
4. Furthermore, since future revisions of DTLS may employ
record formats that are not self-delimiting, at least one
octet of padding MUST be included so that receivers can
unambiguously determine where the DTLS record ends and the
padding begins. If the length of the DTLS record is already
at least 24 and a multiple of 4, then the correct amount of
padding to include is 4 octets.
</t>
<t>
The NTP header values specified above are selected such that
NTP implementations which do not understand NTS will
interpret the packet as an innocuous no-op and not attempt
to use it for time synchronization. To NTS-aware
implementations, however, these packets are best understood
as not being NTP packets at all, but simply a means of
"smuggling" arbitrary DTLS records across port
123/udp. Indeed, these records need not be pertinent to NTP
at all — for example, they could be NTS-KE messages
eventually intended for securing PTP traffic.
</t>
<t>
This transport mechanism is intended for use as a fallback
in situations where firewalls or other middleboxes are
preventing communication on the NTS port. Support for it is
OPTIONAL.
</t>
</section>
</section>
<section title="The NTS-encapsulated NTPv4 protocol">
<t>
The NTS-encapsulated NTPv4 protocol proceeds in two parts.
First, DTLS handshake records are exchanged using one of the
two transport mechanisms specified in <xref target="transport-mechanisms"/>.
The two endpoints carry out a DTLS handshake in conformance with <xref
target="dtls-profile"/>, with the client offering (via an <xref
target="RFC7301">ALPN</xref> extension), and the server
accepting, an application-layer protocol of "ntp/4".
Second, once the handshake is successfully completed, the two
endpoints use the established channel to exchange arbitrary
NTPv4 packets as DTLS-protected Application Data.
</t>
<t>
In addition to the requirements specified in <xref
target="dtls-profile"/>, implementations MUST enforce the
anti-replay mechanism specified in <xref target="RFC6347">
Section 4.1.2.6 of RFC 6347</xref> (or an equivalent mechanism
specified in a subsequent revision of DTLS). Servers wishing
to enforce access control SHOULD either demand a client
certificate or use a PSK-based handshake in order to establish
the client's identity.
</t>
<t>
The NTS-encapsulated NTPv4 protocol is the RECOMMENDED
mechanism for cryptographically securing mode 1 (symmetric
active), 2 (symmetric passive), and 6 (control) NTPv4 traffic.
It is equally safe for mode 3/4 (client/server) traffic, but
is NOT RECOMMENDED for this purpose because it scales poorly
compared to using <xref target="nts-extensions-for-ntpv4">NTS
Extensions for NTPv4</xref>.
</t>
</section>
<section title="The NTS Key Establishment protocol">
<t>
The NTS Key Establishment (NTS-KE) protocol is carried out by
exchanging DTLS records using one of the two transport mechanisms
specified in <xref target="transport-mechanisms"/>. The two
endpoints carry out a DTLS handshake in conformance with <xref
target="dtls-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 DTLS-protected channel),
then the server SHALL send a single response followed by a
"Close notify" alert and then discard the channel state.
</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 sequence SHALL be terminated by a
"End of Message" record, which has a Record Type of
zero and a zero-length body. Furthermore, requests and
non-error responses each SHALL include exactly one NTS Next
Protocol Negotiation record.
</t>
<figure anchor="ntske-record">
<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>
[[Ed. Note: this ad-hoc binary format should be fine as long
as we continue to keep things very simple. However, if we
think there's any reasonable probability of wanting to include
more complex data structures, we should consider using some
semi-structured data format such as JSON, Protocol Buffers, or
(ugh) ASN.1]]
</t>
<t>
The requirement that all NTS-KE messages be terminated by an
End of Message record makes them self-delimiting. One DTLS
record MAY, and typcially will, contain multiple NTS-KE
records. NTS-KE records MAY be split across DTLS record
boundaries. If, likely due to packet loss, an incomplete
NTS-KE message is received, implementations MUST treat this an
error, which clients SHOULD handle by restarting with a fresh
DTLS handshake and trying again.
</t>
<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.
</t>
<t>
Record Type: A 15-bit integer in network byte order (from
most-to-least significant, its bits are record bits 7–1
and then 15–8). The semantics of record types 0–5 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>
<section title="NTS-KE record types">
<t>The following NTS-KE Record Types are defined.</t>
<section title="End of Message">
<t>
The End of Message record has a Record Type number of 0
and an 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">
<t>
The NTS Next Protocol Negotiation record has a record
type of 1. It MUST occur exactly once in every NTS-KE
request and response. Its body consists of a sequence of
16-octet strings. Each 16-octet string represents a
Protocol Name from the IANA Network Time Security
Next Protocols registry. The Critical Bit MUST be
set.
</t>
<t>
The Protocol Names 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. The Protocol
Names listed in the server's response MUST comprise a
subset of those listed in the request, and denote those
protocols which the 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">
<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 negotiated key
material and MUST NOT proceed to the Next Protocol.
</t>
<t>
The following error code 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, upon the expiration
of an implementation-defined timeout, it has not yet
received a complete and syntactically well-formed
request from the client. This error is likely to be
the result of a dropped packet, so the client SHOULD
start over with a new DTLS handshake and retry its
request.
</t>
</list>
</t>
</section>
<section title="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 an
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">
<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="RFC5116">AEAD
registry</xref>. The Critical Bit MAY be set.
</t>
<t>
If the NTS Next Protocol Negotiation record offers
"ntp/4",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, or 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-extensions-for-ntpv4">NTS extensions for
NTPv4</xref> MUST support AEAD_AES_128_GCM (Numeric
Identifier 1). That is, if the client includes
AEAD_AES_128_GCM in its AEAD Algorithm Negotiation record,
and the server accepts the "ntp/4" protocol in
its NTS Next Protocol Negotiation record, then the
server's AEAD Algorithm Negotation record MUST NOT be
empty.
</t>
</section>
<section title="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 [[TODO]] for a RECOMMENDED
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 they accept "ntp/4" as a Next
Protocol. The Critical Bit SHOULD NOT be set.
</t>
</section>
</section>
<section title="Key Extraction (generally)">
<t>
Following a successful run of the NTS-KE protocol, key
material SHALL be extracted according to <xref
target="RFC5705">RFC 5705</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 disambiguating label string MUST be
"EXPORTER-network-time-security/1".
</t>
<t>
The per-association context value MUST be provided, and
MUST begin with the 16-octet Protocol Name which was
negotiated as a Next Protocol.
</t>
</list>
</t>
</section>
</section>
<section title="NTS Extensions for NTPv4" anchor="nts-extensions-for-ntpv4">
<section title="Key Extraction (for NTPv4)">
<t>
Following a successful run of the NTS-KE protocol wherein
"ntp/4" 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
according to <xref target="RFC5705">RFC 5705</xref>, using the
following inputs.
<list>
<t>
The disambiguating label string SHALL be
"EXPORTER-network-time-security/1".
</t>
<t>
The per-association context value SHALL consist of the
following 19 octets:
<list>
<t>
The first 16 octets SHALL be (in hexadecimal):<vspace blankLines="1"/>
6E 74 70 2F 34 00 00 00 00 00 00 00 00 00 00 00
</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 RFC 5705 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 extensions which are authenticated but not encrypted.
</t>
<t>
An NTS extension which contains AEAD output (i.e., an
authentication tag and possible ciphertext). The
corresponding plaintext, if non-empty, consists of some
extensions which benefit from both encryption and
authentication.
</t>
<t>
Possibly, some additional extensions which are neither
encrypted nor authenticated. These are discarded by the
receiver. [[Ed. Note: right now there's no good reason
for the sender to include anything here, but eventually
there might be. We've seen <xref
target="RFC7821">Checksum Complement</xref> and LAST-EF
as two examples of semantically-void extensions that are
included to satsify constraints imposed lower on the
protocol stack, and while there's no reason to use
either of these on NTS-protected packets, I think we
could see similar examples in the future. So, rejecting
packets with unauthenticated extensions could cause
interoperability problems, while accepting and
processing those extensions would of course be a
security risk. Thus, I think "allow and
discard" is the correct policy.]]
</t>
</list>
</t>
<t>
Always included among the authenticated or
authenticated-and-encrypted extensions are a cookie
extension and a unique-identifier extension. The purpose of
the cookie extension is to enable the server to offload
storage of session state onto the client. The purpose of the
unique-identifier extension is to protect the client from
replay attacks.
</t>
</section>
<section title="The Unique Identifier extension">
<t>
The Unique Identifier extension has a Field Type of
[[TBD]]. When the extension is included in a client packet
(mode 3), its body SHALL consist of a string of octets
generated uniformly at random. The string SHOULD be 32 octets
long. When the extension 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. Its use in modes other than client/server is not
defined.
</t>
<t>
The Unique Identifier extension provides the client with a
cryptographically strong means of detecting replayed
packets. It 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 enables a degree of unpredictability
and collision-resistance more consistent with cryptographic
best practice.
</t>
<t>
[[TODO: consider using separate extension types for request
and response, thus allowing for use in symmetric mode. But
proper handling in the presence of dropped packets needs to
be documented and involves a lot of subtlety.]]
</t>
</section>
<section title="The NTS Cookie extension">
<t>
The NTS Cookie extension has a Field Type of [[TBD]]. 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 [[TODO]] for a RECOMMENDED construction.
The NTS Cookie extension MUST NOT be included in NTP packets
whose mode is other than 3 (client) or 4 (server).
</t>
</section>
<section title="The NTS Authenticator and Encrypted Extensions extension">
<t>
The NTS Authenticator and Encrypted Extensions extension is
the central cryptographic element of an NTS-protected NTP
packet. Its Field Type is [[TBD]] and the format of its body
SHALL be as follows:
<list>
<t>
Nonce length: two octets in network byte order, giving
the length of the Nonce field.
</t>
<t>
Nonce: a nonce as required by the negotiated AEAD Algorithm.
</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.
</t>
<t>
Padding: between 1 and 24 octets of padding, with every
octet set to the number of padding octets included,
e.g., "01", "02 02", or "03 03
03". The number of padding bytes should be chosen
in order to comply with the <xref target="RFC7822">RFC
7822</xref> requirement that (in the absence of a legacy
MAC) extensions have a total length in octets (including
the four octets for the type and length fields) which is
at least 28 and divisible by 4. At least one octet of
padding MUST be included, so that implementations can
unambiguously delimit the end of the ciphertext from the
start of the padding.
</t>
</list>
</t>
<t>
The Ciphertext field SHALL be formed by providing the
following inputs to the negotiated AEAD Algorithm:
<list>
<t>
K: For packets sent from the client to the server, the
C2S key SHALL be used. For packets sent from the server
to the client, the S2C key SHALL be used.
</t>
<t>
A: The associated data SHALL consist of the portion of
the NTP packet beginning from the start of the NTP header
and ending at the end of the last extension which precedes
the NTS Authenticator and Encrypted Extensions extension.
</t>
<t>
P: The plaintext SHALL consist of all (if any)
extensions to be encrypted.
</t>
<t>
N: The nonce SHALL be formed however required by the
negotiated AEAD Algorithm.
</t>
</list>
</t>
<t>
The NTS Authenticator and Encrypted Extensions extension
MUST NOT be included in NTP packets whose mode is other than
3 (client) or 4 (server).
</t>
</section>
<section title="Protocol details">
<t>
A client sending an NTS-protected request SHALL include the
following extensions:
<list>
<t>
Exactly one Unique Identifier extension, which MUST be
authenticated and MUST NOT be encrypted [[Ed. Note: so
that if the server can't decrypt the request, it can
still echo back the Unique Identifier in the NTS NAK it
sends]]. MUST select the Unique Identifier as described in
<xref target="The Unique Identifier extension"/>
</t>
<t>
Exactly one NTS Cookie extension, which MUST be
authenticated and MUST NOT be encrypted. The cookie MUST
be one which the server previously provided the client;
it may have been provided during the NTS-KE handshake or
in response to a previous NTS-protected NTP request. To
protect client's privacy, the same cookie SHOULD NOT be
included in multiple requests. If the client does not
have any cookies that it has not already sent, it SHOULD
re-run the NTS-KE protocol before continuing.
</t>
<t>
Exactly one NTS Authenticator and Encrypted Extensions
extension, generated using an AEAD Algorithm and C2S key
established through NTS-KE.
</t>
</list>
</t>
<t>
The client MAY include additional (non-NTS-related)
extensions, which MAY appear prior to the NTS Authenticator
and Encrypted Extensions extension (therefore authenticated
but not encrypted), within it (therefore encrypted and
authenticated), or after it (therefore neither encrypted nor
authenticated). However, the server MUST discard any
unauthenticated extensions and process the packet as though
they were not present.
</t>
<t>
The client MUST store the value of Unique Identifier in "uid"
variable.
</t>
<t>
Upon receiving an NTS-protected request, the server SHALL
(through some implementation-defined mechanism) use the
cookie to recover the AEAD Algorithm, C2S key, and S2C key
associated with the request, and then use the C2S key to
authenticate the packet and decrypt the ciphertext. If the
cookie is valid and authentication and decryption succeed,
then the server SHALL include the following extensions in
its response:
<list>
<t>
Exactly one Unique Identifier extension, which MUST be
authenticated, MUST NOT be encrypted, and whose contents
SHALL echo those provided by the client.
</t>
<t>
Exactly one NTS Authenticator and Encrypted Extensions
extension, generated using the AEAD algorithm and S2C
key recovered from the cookie provided by the client.
</t>
<t>
One or more NTS Cookie extensions, which MUST be
authenticated and encrypted. Typically, multiple NTS
Cookie extensions SHOULD be included; however, see <xref
target="security-considerations"/> for discussion of
exceptional cases wherein including multiple cookies
could aggravate reflective DDoS attacks.
</t>
</list>
</t>
<t>
The server MAY include additional (non-NTS-related)
extensions, which MAY appear prior to the NTS Authenticator
and Encrypted Extensions extension (therefore authenticated
but not encrypted), within it (therefore encrypted and
authenticated), or after it (therefore neither encrypted nor
authenticated). However, the client MUST discard any
unauthenticated extensions and process the packet as though
they were not present.
</t>
<t>
If the server is unable to validate the cookie or
authenticate the request, it SHOULD respond with a
Kiss-o'-Death packet (see <xref target="RFC5905">RFC 5905,
Section 7.4)</xref>) with kiss code "NTSN"
(meaning "NTS NAK"). Such a response MUST
include exactly one Unique Identifier extension whose
contents SHALL echo those provided by the client. It MUST
NOT include any NTS Cookie or NTS Authenticator and
Encrypted Extensions extension. [[Ed. Note: RFC 5905 already
provides the kiss code "CRYP" meaning
"Cryptographic authentication or identification failed"
but I think this is meant to be Autokey-specific.]]
</t>
<t>
Upon receiving an NTS-protected response, the client MUST
perform the following strictly in the order mentioned.
<list style="numbers">
<t> Verify that the Unique Identifier matches the "uid" variable of an
outstanding request.</t>
<t> The packet is authentic under the S2C key associated with that request.</t>
</list>
If either of these checks fails, the packet MUST be discarded without further
processing.
</t>
<t>
The client MUST clear the "uid" variable to a random 32-octets long value.
</t>
</section>
</section>
<section title="Recommended format for NTS cookies" anchor="recommended-format-for-nts-cookies">
<t>
This section provides a RECOMMENDED way for servers to
construct NTS cookies. Clients MUST NOT examine the cookie
under the assumption that it is constructed according to this
section.
</t>
<t>
The role of cookies in NTS is closely analagous to that of
session cookies in TLS. Accordingly, the thematic resemblance
of this section to <xref target="RFC5077">RFC 5077</xref> is
deliberate, and the reader should likewise take heed of its
security considerations.
</t>
<t>
Servers should randomily generate and store a master <xref
target="AES">AES</xref> key `MEK` and a master <xref
target="RFC4634">HMAC-SHA-256</xref> key `MAK`. Servers should
additionally choose a non-secret, unique value `I` to identify
the pair (MEK,MAK).
</t>
<t>
Servers should periodically (e.g., once daily) generate a new
triplet (I,MEK,MAK) and immediately switch to using these
values for all newly-generated cookies. Immediately
following each such key rotation, servers should securely
erase any keys generated two or more rotation periods
prior. Servers should continue to accept any cookie generated
using keys that they have not yet erased, even if those keys are
no longer current. Erasing old keys provides for forward
secrecy, limiting the scope of what old information can be
stolen if a master key is somehow compromised. Holding on to a
limited number of old keys allows clients to seamlessly
transition from one generation to the next without having to
perform a new NTS-KE handshake.
</t>
<t>
[[TODO: discuss key management considerations for load-balanced
servers]]
</t>
<t>
To form a cookie, servers should first form a plaintext `P`
consisting of the following fields:
<list>
<t>The AEAD algorithm negotiated during NTS-KE</t>
<t>The S2C key</t>
<t>The C2S key</t>
</list>
</t>
<t>
Servers should then randomly generate an initialization vector
`IV`, form ciphertext `C` by encrypting `P` in <xref
target="CBC">CBC mode</xref> under key `MEK` with `IV` as the
initialization vector, and then MAC the message `IV || C`
(with || denoting concatenation) under key `MAK`, obtaining
tag `T`.
</t>
<t>
The cookie should consist of the tuple `(I,IV,C,T)`.
</t>
<t>
[[TODO: explicitly specify how to verify and decrypt a cookie,
not just how to form one]]
</t>
<t>
Implementors may choose to substitute alternative algorithms
in place of AES and SHA-256, but are discouraged from
abandoning the combination of CBC and HMAC. CBC has the
desirable property that the IV is random, is as wide as the
cipher block, and that occasional collisions are unlikely to
be fatal to security. In contrast, most IETF-standard AEAD
schemes use a 96-bit nonce, and a single collision can break
the security of everything ever authenticated under that key.
AEAD nonces are generally expected only to be unique, not
random, and 96 bits is too small for randomly-generated nonces
to necessarily have a negligible risk of collision. However,
use of sequential nonces in this context is a threat to
privacy: a passive adversary could then count the responses
emitted by the server and infer the nonces even though they
are encrypted, then use this information to identify the
client when it later returns the nonce in plaintext.
</t>
<t>
A possible alternative approach, which would enable use of
AEAD algorithms with short nonces without risk to security or
privacy, is to use sequential nonces but avoid directly
including them in the cookie; instead, protect them using a
key-wrapping scheme such as <xref target="RFC3394">RFC