-
Notifications
You must be signed in to change notification settings - Fork 10
/
draft-dfranke-nts.xml
1248 lines (1236 loc) · 54.7 KB
/
draft-dfranke-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 rfc3629 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3629.xml'>
<!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 rfc5297 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5297.xml'> <!--AES-SIV-->
<!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'> <!--Renegotition-->
<!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/>
<abstract>
<t>
This memo specifies Network Time Security (NTS), a mechanism for
using Datagram TLS to provide cryptographic security for the
Network Time Protocol or other network time synchronization
protocols.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
[[SEE https://github.com/dfoxfranke/nts FOR AN UP-TO-MINUTE
DRAFT OF THIS MEMO, AND https://github.com/dfoxfranke/nts/issues
FOR A LIST OF OUTSTANDING ISSUES.]]
</t>
<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 "DTLS-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
TLS to establish key material and negotiate some additional
protocol options, but then quickly closes the TLS 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="TLS profile for Network Time Security" anchor="tls-profile">
<t>
Network Time Security makes use of both TLS (for NTS Key
Establishment) and DTLS (for DTLS-encapsulated NTPv4). In
either case, the requirements and recommendations of this
section are similar. The notation "(D)TLS" refers to
both TLS and DTLS.
</t>
<t>
Since securing time protocols is (as of 2017) a novel
application of (D)TLS, no backward-compatibility concerns exist
to justify using obsolete, insecure, or otherwise broken TLS
features or versions. We therefore put forward the following
requirements and guidelines, roughly representing 2017's best
practices.
</t>
<t>
Implementations MUST NOT negotiate (D)TLS versions
earlier than 1.2.
</t>
<t>
Implementations willing to negotiate more than one possible
version of (D)TLS SHOULD NOT respond to handshake failures by
retrying with a downgraded protocol version. If they do, they
MUST implement <xref target="RFC7507"/>.
</t>
<t>
(D)TLS clients MUST NOT offer, and DTLS servers MUST not select,
RC4 cipher suites. <xref target="RFC7465"/>
</t>
<t>
(D)TLS clients SHOULD offer, and (D)TLS servers SHOULD accept, the
<xref target="RFC5746">TLS Renegotiation Indication
Extension</xref>. Regardless, they MUST NOT initiate or permit
insecure renegotiation. (*)
</t>
<t>
(D)TLS clients SHOULD offer, and (D)TLS 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 (D)TLS 1.3 or beyond may render the indicated
recommendations inapplicable.
</t>
</section>
<section title="The DTLS-encapsulated NTPv4 protocol">
<t>
The DTLS-encapsulated NTPv4 protocol is conducted on UDP port [TBD].
</t>
<t>
The DTLS-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="tls-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="tls-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 DTLS-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>
</t>
<t>
The NTS key establishment protocol is conducted via TCP port
[TBD]. 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
followed by a TLS "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.
</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 <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 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>
<t>
[[Ed. Note: the purpose of sending eight cookies is to
allow the client to recover from dropped packets without
reusing cookies or starting a new handshake. Discussion of
cookie management should probably be broken out into its
own section.]]
</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 Cookie Placeholder extension">
<t>
The NTS Cookie Placeholder extension has a Field Type of [[TBD]].
When this extension 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 MUST NOT
be included in NTP packets whose mode is other than 3.
</t>
<t>
Whenever an NTS Cookie Placeholder extension is present, it
MUST be accompanied by an NTS Cookie extension, and the body
length of the NTS Cookie Placeholder extension MUST be the
same as the body length of an NTS Cookie Extension previously
received from the server. (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's MUST be
all zero bytes and, aside from checking its length, MUST be
ignored by the server.
</t>
<t>
If a client wants multiple cookies, it should repeat this
extension for each cookie it wants.
</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]]. The client MUST NOT duplicate those of any previous
request.
</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 one or more NTS Cookie Placeholder
extensions, which MUST be authenticated and MAY be
encrypted. The number of NTS Cookie Placeholder extensions
that the client includes SHOULD be such that if the client
includes N placeholders and the server sends back N+1
cookies, the number of unused cookies stored by the client
will come to eight. When both the client and server adhere
to all cookie-management guidance provided in this memo, the
number of placeholder extensions will equal the number of
dropped packets since the last successful volley.
</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). In general, however, the server MUST discard
any unauthenticated extensions and process the packet as
though they were not present. Servers MAY implement
exceptions to this requirement for particular extensions
if their specification explicitly provides for such.
</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. The number of NTS Cookie
extensions included SHOULD be equal to, and MUST NOT
exceed, one plus the number of valid NTS Cookie
Placeholder extensions included in the request.
</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). In general, however, the client MUST discard
any unauthenticated extensions and process the packet as
though they were not present. Clients MAY implement
exceptions to this requirement for particular extensions
if their specification explicitly provides for such.
</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
verify that the Unique Identifier matches that of an
outstanding request, and that the packet is authentic under
the S2C key associated with that request. If either of these
checks fails, the packet MUST be discarded without further
processing.
</t>
<t>
Upon receiving an NTS NAK, the client MUST verify that the
Unique Identifier matches that of an outstanding request. If
this check fails, the packet MUST be discarded without
further processing. If this check passes, the client SHOULD
discard all cookies and AEAD keys associated with the server
which sent the NAK and initiate a fresh NTS-KE handshake.
</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 select an AEAD algorithm which they will use to
encrypt and authenticate cookies. The chosen algorithm should
be one such as <xref
target="RFC5297">AEAD_AES_SIV_CMAC_256</xref> which resists
accidential nonce reuse, and it need not be the same as the
one that was negotiated with the client. Servers should
randomly generate and store a master AEAD key `K`. Servers
should additionally choose a non-secret, unique value `I` as
key-identifier for `K`.
</t>
<t>
Servers should periodically (e.g., once daily) generate a new
pair (I,K) 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 the generate a nonce `N` uniformly at random,
and form AEAD output `C` by encrypting `P` under key `K` with
nonce `N` and no associated data.
</t>
<t>
The cookie should consist of the tuple `(I,N,C)`.
</t>
<t>
[[TODO: explicitly specify how to verify and decrypt a cookie,
not just how to form one]]
</t>
</section>
<section title="Security Considerations" anchor="security-considerations">
<t>[[TODO. Outline follows.]]
<list>
<t>
Cite <xref target="RFC7384">RFC 7384</xref> for general
considerations.
</t>
<t>
State security goals (authentication (defined in terms of
agreement), client privacy) and threat model (active network
adversary).
</t>
<t>
Incorporate content from "What Makes NTP Cryptographically Exceptional?"
of NTS design essay.
</t>
<t>
Address strategies for management of AEAD nonces and stress importance
of avoiding repetition.
</t>
<t>
Give recommendations for validating X.509 certificates
during the DTLS handshake. Discuss what to expect for the
CN/SANs, and how to deal with verifying the validity period
if correct time is not yet known.
</t>
<t>
Caution that NTS will not prevent an adversary from skewing
time by up to MAXDIST/2 and discuss why this limitation is
fundamental.
</t>
<t>
Possibly include informal security proofs.
</t>
</list>
</t>
</section>
<section title="IANA Considerations" anchor="iana-considerations">
<t>
IANA is requested to allocate an entry in the Service Name and
Transport Protocol Port Number Registry as follows:
<list>
<t>Service Name: nts</t>
<t>Transport Protocol: udp</t>
<t>Assignee: IESG <[email protected]></t>
<t>Contact: IETF Chair <[email protected]></t>
<t>Description: Network Time Security</t>
<t>Reference: [[this memo]]</t>
<t>Port Number: selected by IANA from the user port range</t>
</list>
</t>
<t>
IANA is requested to allocate the following two entries in the
Application-Layer Protocol Negotation (ALPN) Protocol IDs
registry:
<list>
<t>Protocol: Network Time Security Key Establishment, version 1</t>
<t>
Identification
Sequence:<vspace/> 0x6E 0x74 0x73 0x6B 0x65 0x2F 0x31 ("ntske/1")
</t>
<t>Reference: [[this memo]]</t>
</list>
<vspace/>
<list>
<t>Protocol: Network Time Protocol, version 4</t>
<t>
Identification
Sequence:<vspace/> 0x6E 0x74 0x70 0x2F 0x34 ("ntp/4")
</t>
<t>Reference: [[this memo]]</t>
</list>
</t>
<t>
IANA is requested to allocate the following entry in the TLS
Exporter Label Registry:
</t>
<texttable>
<ttcol>Value</ttcol>
<ttcol>DTLS-OK</ttcol>
<ttcol>Reference</ttcol>
<ttcol>Note</ttcol>
<c>EXPORTER-network-time-security/1</c>
<c>Y</c>
<c>[[this memo]]</c>
<c/>
</texttable>
<t>
IANA is requested to allocate the following entries in the registry
of NTP Kiss-o'-Death codes:
</t>
<texttable>
<ttcol>Code</ttcol><ttcol>Meaning</ttcol>
<c>DTLS</c><c>Packet conveys a DTLS record</c>