-
Notifications
You must be signed in to change notification settings - Fork 10
/
draft-ietf-ntp-network-time-security.xml
2065 lines (1630 loc) · 86.5 KB
/
draft-ietf-ntp-network-time-security.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-network-time-security-14"
ipr="trust200902" submissionType="IETF">
<front>
<title abbrev="NTS">Network Time Security</title>
<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>[email protected]</email>
</address>
</author>
<author fullname="Stephen Röttger" initials="S."
surname="Röttger">
<organization>Google Inc.</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<facsimile/>
<email>[email protected]</email>
<uri/>
</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-8421</phone>
<facsimile/>
<email>[email protected]</email>
<uri/>
</address>
</author>
<date day="21" month="March" year="2016"/>
<area>Internet Area</area>
<workgroup>NTP Working Group</workgroup>
<keyword>Integrity</keyword>
<keyword>Authentication</keyword>
<keyword>NTP</keyword>
<keyword>PTP</keyword>
<keyword>Security</keyword>
<keyword>Time synchronization</keyword>
<abstract>
<t>This document describes Network Time Security (NTS), a collection of
measures that enable secure time synchronization with time servers using
protocols like the Network Time Protocol (NTP) or the Precision Time
Protocol (PTP). Its design considers the special requirements of precise
timekeeping which are described in Security Requirements of Time
Protocols in Packet Switched Networks <xref target="RFC7384"/>.</t>
</abstract>
<note 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>
</note>
</front>
<middle>
<section title="Introduction">
<t>Time synchronization protocols are increasingly utilized to
synchronize clocks in networked infrastructures. Successful attacks
against the time synchronization protocol can seriously degrade the
reliable performance of such infrastructures. Therefore, time
synchronization protocols have to be secured if they are applied in
environments that are prone to malicious attacks. This can be
accomplished either by utilization of external security protocols, like
IPsec or TLS, or by intrinsic security measures of the time
synchronization protocol.</t>
<t>The two most popular time synchronization protocols, the Network Time
Protocol (NTP) <xref target="RFC5905"/> and the Precision Time Protocol
(PTP) <xref target="IEEE1588"/>, currently do not provide adequate
intrinsic security precautions. This document specifies generic security
measures which enable these and possibly other protocols to verify the
authenticity of the time server/master and the integrity of the time
synchronization protocol packets. The utilization of these measures for
a given specific time synchronization protocol has to be described in a
separate document.</t>
<t><xref target="RFC7384"/> specifies that a security mechanism for
timekeeping must be designed in such a way that it does not degrade the
quality of the time transfer. This implies that for time keeping the
increase in bandwidth and message latency caused by the security
measures should be small. Also, NTP as well as PTP work via UDP and
connections are stateless on the server/master side. Therefore, all
security measures in this document are designed in such a way that they
add little demand for bandwidth, that the necessary calculations can be
executed in a fast manner, and that the measures do not require a
server/master to keep state of a connection.</t>
</section>
<section title="Terminology">
<section title="Terms and Abbreviations">
<t><list style="hanging">
<t hangText="MITM ">Man In The Middle</t>
<t hangText="NTS ">Network Time Security</t>
<t hangText="TESLA">Timed Efficient Stream Loss-tolerant
Authentication</t>
<t hangText="MAC">Message Authentication Code</t>
</list></t>
</section>
<section title="Common Terminology for PTP and NTP">
<t>This document refers to different time synchronization protocols,
in particular to both the PTP and the NTP. Throughout the document the
term "server" applies to both a PTP master and an NTP server.
Accordingly, the term "client" applies to both a PTP slave and an NTP
client.</t>
</section>
</section>
<section title="Security Threats">
<t>The document "Security Requirements of Time Protocols in Packet
Switched Networks" <xref target="RFC7384"/> contains a profound analysis
of security threats and requirements for time synchronization
protocols.</t>
</section>
<section anchor="sec.objectives" title="Objectives">
<t>The objectives of the NTS specification are as follows:<list
style="symbols">
<t>Authenticity: NTS enables the client to authenticate its time
server(s).</t>
<t>Integrity: NTS protects the integrity of time synchronization
protocol packets via a message authentication code (MAC).</t>
<t>Confidentiality: NTS does not provide confidentiality protection
of the time synchronization packets.<?xxe-remark teiche04
2016-09-08T12:27:55Z
Possibly confusing interaction with the non-traceability goal.
Needs language to clear this out, or deletion.?></t>
<t>Authorization: NTS enables the client to verify its time server's
authorization. NTS optionally enables the server to verify the
client's authorization as well.</t>
<t>Request-Response-Consistency: NTS enables a client to match an
incoming response to a request it has sent. NTS also enables the
client to deduce from the response whether its request to the server
has arrived without alteration.</t>
<t>Client-Side Non-traceability: NTS prevents an attacker from
tracing a client device over changes in routing data via any data
sent in the course of NTS' own security measures.<list
style="hanging">
<t hangText="Note:">This objective is still under discussion.
The main issue is whether this from of the objective is worth
the effort or if it needs to have the appendix "or using data
sent by the time synchronization protocol that NTS is applied
to".</t>
</list></t>
<t>Applicability to Protocols: NTS can be used to secure different
time synchronization protocols, specifically at least NTP and
PTP.</t>
<t>Integration with Protocols: A client or server running an
NTS-secured version of a time protocol does not negatively affect
other participants who are running unsecured versions of that
protocol.</t>
<t>Server-Side Statelessness: All security measures of NTS work
without creating the necessity for a server to keep any long-term
state of a connection.</t>
<t>Prevention of Amplification Attacks: All communication introduced
by NTS offers protection against abuse for amplification
denial-of-service attacks.</t>
</list></t>
</section>
<section anchor="overview" title="NTS Overview">
<t>NTS initially verifies the authenticity of the time server and
exchanges a symmetric key, the so-called cookie, as well as a key input
value (KIV). The KIV can be opaque for the client. After the cookie and
the KIV are exchanged, the client then uses them to protect the
authenticity and the integrity of subsequent unicast-type time
synchronization packets. In order to do this, a Message Authentication
Code (MAC) is attached to each time synchronization packet. The
calculation of the MAC includes the whole time synchronization packet
and the cookie which is shared between client and server.</t>
<t>The cookie deterministically depends on KIV as long as the server
seed stays the same. <?xxe-remark teiche04
2016-09-08T12:29:09Z
Is server seed freshness still an objective that should be mentioned here??>The
server seed has to be refreshed periodically in order to provide key
freshness as required in <xref target="RFC7384"/>. See <xref
target="serverseedconsiderations"/> for details on seed refreshing.</t>
<t>Since the server does not keep a state of the client, it has to
recalculate the cookie each time it receives a unicast time
synchronization request from the client. To this end, the client has to
attach its KIV to each request (see <xref target="timerequest"/>).<list
style="hanging">
<t hangText="Note:">The communication of the KIV and the cookie can
be performed between client and server directly, or via a third
party key distribution entity.</t>
</list></t>
<t>For broadcast-type messages, authenticity and integrity of the time
synchronization packets are also ensured by a MAC, which is attached to
the time synchronization packet by the sender. Verification of the
broadcast-type packets' authenticity is based on the TESLA protocol, in
particular on its "not re-using keys" scheme, see Section 3.7.2 of <xref
target="RFC4082"/>. TESLA uses a one-way chain of keys, where each key
is the output of a one-way function applied to the previous key in the
chain. The server securely shares the last element of the chain with all
clients. The server splits time into intervals of uniform duration and
assigns each key to an interval in reverse order. At each time interval,
the server sends a broadcast packet appended by a MAC, calculated using
the corresponding key, and the key of the previous disclosure interval.
The client verifies the MAC by buffering the packet until disclosure of
the key in its associated disclosure interval occurs. In order to be
able to verify the timeliness of the packets, the client has to be
loosely time synchronized with the server. This has to be accomplished
before broadcast associations can be used. For checking timeliness of
packets, NTS uses another, more rigorous check in addition to just the
clock lookup used in the TESLA protocol. For a more detailed description
of how NTS employs and customizes TESLA, see <xref
target="appBroadcast"/>.</t>
</section>
<section anchor="protsec" title="Protocol Messages">
<t>This section describes the types of messages needed for secure time
synchronization with NTS.</t>
<t>For some guidance on how these message types can be realized in
practice, and integrated into the communication flow of existing time
synchronization protocols, see <xref
target="I-D.ietf-ntp-cms-for-nts-message"/>, a companion document for
NTS. Said document describes ASN.1 encodings for those message parts
that have to be added to a time synchronization protocol for security
reasons.</t>
<section anchor="timerequest"
title="Unicast Time Synchronisation Messages">
<t>In this message exchange, the usual time synchronization process is
executed, with the addition of integrity protection for all messages
that the server sends. This message exchange can be repeatedly
performed as often as the client desires and as long as the integrity
of the server's time responses is verified successfully.</t>
<section anchor="sssec.preconditions.unicast"
title="Preconditions for the Unicast Time Synchronization Exchange">
<t>Before this message exchange is available, there are some
requirements that the client and server need to meet:<list
style="symbols">
<t>They MUST negotiate the algorithm for the MAC used in the
time synchronization messages. Authenticity and integrity of the
communication MUST be ensured.</t>
<t>The client MUST know a key input value KIV. Authenticity and
integrity of the communication MUST be ensured.</t>
<t>Client and server MUST exchange the cookie (which depends on
the KIV as described in section <xref target="overview"/>).
Authenticity, confidentiality and integrity of the communication
MUST be ensured.</t>
</list></t>
<t>One way of realizing these requirements is to use the Association
and Cookie Message Exchanges described in <xref
target="Appendix_Bootstrapping"/>.</t>
</section>
<section title="Goals of the Unicast Time Synchronization Exchange">
<t>The unicast time synchronization exchange:<list style="symbols">
<t>exchanges time synchronization data as specified by the
appropriate time synchronization protocol,</t>
<t>guarantees authenticity and integrity of the request to the
server,</t>
<t>guarantees authenticity and integrity of the response to the
client,</t>
<t>guarantees request-response-consistency to the client.</t>
</list></t>
</section>
<section anchor="time_request"
title="Message Type: "time_request"">
<t>This message is sent by the client when it requests a time
exchange. It contains<list style="symbols">
<t>the NTS message ID "time_request",</t>
<t>the negotiated version number,</t>
<t>a nonce,</t>
<t>the negotiated MAC algorithm,</t>
<t>the client's key input value (for which the client knows the
associated cookie),</t>
<t>optional: a MAC (generated with the cookie as key) for
verification of all of the above data.</t>
</list></t>
</section>
<section anchor="time_response"
title="Message Type: "time_response"">
<t>This message is sent by the server after it has received a
time_request message. Prior to this the server MUST recalculate the
client's cookie by using the received key input value and the
transmitted MAC algorithm. The message contains<list style="symbols">
<t>the NTS message ID "time_response",</t>
<t>the version number as transmitted in time_request,</t>
<t>the server's time synchronization response data,</t>
<t>the nonce transmitted in time_request,</t>
<t>a MAC (generated with the cookie as key) for verification of
all of the above data.</t>
</list></t>
</section>
<section title="Procedure Overview of the Unicast Time Synchronization Exchange">
<t>For a unicast time synchronization exchange, the following steps
are performed:<list style="numbers">
<t>The client sends a time_request message to the server. The
client MUST save the included nonce and the transmit_timestamp
(from the time synchronization data) as a correlated pair for
later verification steps. Optionally, the client protects the
request message with an appended MAC.</t>
<t>Upon receipt of a time_request message, the server performs
the following steps:<list style="symbols">
<t>It re-calculates the cookie.</t>
<t>If the request message contains a MAC the server
re-calculates the MAC and compares this value with the MAC
in the received data.<list style="symbols">
<t>If the re-calculated MAC does not match the MAC in
the received data the server MUST stop the processing of
the request.</t>
<t>If the re-calculated MAC matches the MAC in the
received data the server continues to process the
request.</t>
</list></t>
<t>The server computes the necessary time synchronization
data and constructs a time_response message as given in
<xref target="time_response"/>.</t>
</list></t>
<t>The client awaits a reply in the form of a time_response
message. Upon receipt, it checks: <list style="symbols">
<t>that the transmitted version number matches the one
negotiated previously,</t>
<t>that the transmitted nonce belongs to a previous
time_request message,</t>
<t>that the transmit_timestamp in that time_request message
matches the corresponding time stamp from the
synchronization data received in the time_response, and</t>
<t>that the appended MAC verifies the received
synchronization data, version number and nonce.</t>
</list>If at least one of the first three checks fails (i.e.
if the version number does not match, if the client has never
used the nonce transmitted in the time_response message, or if
it has used the nonce with initial time synchronization data
different from that in the response), then the client MUST
ignore this time_response message. If the MAC is invalid, the
client MUST do one of the following: abort the run or send
another cookie request (because the cookie might have changed
due to a server seed refresh). If both checks are successful,
the client SHOULD continue time synchronization.</t>
</list></t>
<figure>
<artwork><![CDATA[ +-----------------------+
| o Re-generate cookie |
| o Assemble response |
| o Generate MAC |
+-----------+-----------+
|
<-+->
Server ----------------------------------------------->
/| \
time_ / \ time_
request / \ response
/ \|
Client ----------------------------------------------->
<------ Unicast time ------> <- Client-side ->
synchronization validity
exchange checks
]]></artwork>
<postamble>Procedure for unicast time synchronization
exchange.</postamble>
</figure>
</section>
</section>
<section anchor="broadmessage"
title="Broadcast Time Synchronization Exchange">
<section anchor="sssec.preconditions.broadcasttimesync"
title="Preconditions for the Broadcast Time Synchronization Exchange">
<t>Before this message exchange is available, there are some
requirements that the client and server need to meet:<list
style="symbols">
<t>The client MUST receive all the information necessary to
process broadcast time synchronization messages from the server.
This includes<list style="symbols">
<t>the one-way functions used for building the key
chain,</t>
<t>the last key of the key chain,</t>
<t>time interval duration,</t>
<t>the disclosure delay (number of intervals between use and
disclosure of a key),</t>
<t>the time at which the next time interval will start,
and</t>
<t>the next interval's associated index.</t>
</list></t>
<t>The communication of the data listed above MUST guarantee
authenticity of the server, as well as integrity and freshness
of the broadcast parameters to the client.</t>
</list></t>
</section>
<section title="Goals of the Broadcast Time Synchronization Exchange">
<t>The broadcast time synchronization exchange:<list style="symbols">
<t>transmits (broadcast) time synchronization data from the
server to the client as specified by the appropriate time
synchronization protocol,</t>
<t>guarantees to the client that the received synchronization
data has arrived in a timely manner as required by the TESLA
protocol and is trustworthy enough to be stored for later
checks,</t>
<t>additionally guarantees authenticity of a certain broadcast
synchronization message in the client's storage.</t>
</list></t>
</section>
<section anchor="server_broad"
title="Message Type: "server_broad"">
<t>This message is sent by the server over the course of its
broadcast schedule. It is part of any broadcast association. It
contains<list style="symbols">
<t>the NTS message ID "server_broad",</t>
<t>the version number that the server is working under,</t>
<t>time broadcast data,</t>
<t>the index that belongs to the current interval (and therefore
identifies the current, yet undisclosed, key),</t>
<t>the disclosed key of the previous disclosure interval
(current time interval minus disclosure delay),</t>
<t>a MAC, calculated with the key for the current time interval,
verifying <list style="symbols">
<t>the message ID,</t>
<t>the version number, and</t>
<t>the time data.</t>
</list></t>
</list></t>
</section>
<section title="Procedure Overview of Broadcast Time Synchronization Exchange">
<t>A broadcast time synchronization message exchange consists of the
following steps:<list style="numbers">
<t>The server follows the TESLA protocol by regularly sending
server_broad messages as described in <xref
target="server_broad"/>, adhering to its own disclosure
schedule.</t>
<t>The client awaits time synchronization data in the form of a
server_broadcast message. Upon receipt, it performs the
following checks: <list style="symbols">
<t>Proof that the MAC is based on a key that is not yet
disclosed (packet timeliness). This is achieved via a
combination of checks. First, the disclosure schedule is
used, which requires loose time synchronization. If this is
successful, the client obtains a stronger guarantee via a
key check exchange (see below). If its timeliness is
verified, the packet will be buffered for later
authentication. Otherwise, the client MUST discard it. Note
that the time information included in the packet will not be
used for synchronization until its authenticity could also
be verified.</t>
<t>The client checks that it does not already know the
disclosed key. Otherwise, the client SHOULD discard the
packet to avoid a buffer overrun. If this check is
successful, the client ensures that the disclosed key
belongs to the one-way key chain by applying the one-way
function until equality with a previous disclosed key is
shown. If it is falsified, the client MUST discard the
packet.</t>
<t>If the disclosed key is legitimate, then the client
verifies the authenticity of any packet that it has received
during the corresponding time interval. If authenticity of a
packet is verified, then it is released from the buffer and
its time information can be utilized. If the verification
fails, then authenticity is not given. In this case, the
client MUST request authentic time from the server by means
other than broadcast messages. Also, the client MUST
re-initialize the broadcast sequence with a "client_bpar"
message if the one-way key chain expires, which it can check
via the disclosure schedule.</t>
</list>See RFC 4082<xref target="RFC4082"/> for a detailed
description of the packet verification process.</t>
</list></t>
<figure>
<artwork><![CDATA[ Server ---------------------------------->
\
\ server_
\ broad
\|
Client ---------------------------------->
< Broadcast > <- Client-side ->
time sync. validity and
exchange timeliness
checks
]]></artwork>
<postamble>Procedure for broadcast time synchronization
exchange.</postamble>
</figure>
</section>
</section>
<section title="Broadcast Keycheck">
<t>This message exchange is performed for an additional check of
packet timeliness in the course of the TESLA scheme, see <xref
target="appBroadcast"/>.</t>
<section anchor="sssec.preconditions.broadcastkeycheck"
title="Preconditions for the Broadcast Keycheck Exchange">
<t>Before this message exchange is available, there are some
requirements that the client and server need to meet:<list
style="symbols">
<t>They MUST negotiate the algorithm for the MAC used in the
time synchronization messages. Authenticity and integrity of the
communication MUST be ensured.</t>
<t>The client MUST know a key input value KIV. Authenticity and
integrity of the communication MUST be ensured.</t>
<t>Client and server MUST exchange the cookie (which depends on
the KIV as described in section <xref target="overview"/>).
Authenticity, confidentiality and integrity of the communication
MUST be ensured.</t>
</list></t>
<t>These requirements conform to those for the unicast time
synchronization exchange. Accordingly, they too can be realized via
the Association and Cookie Message Exchanges described in <xref
target="Appendix_Bootstrapping">Appendix B</xref>.</t>
</section>
<section title="Goals of the Broadcast Keycheck Exchange">
<t>The keycheck exchange:<list style="symbols">
<t>guarantees to the client that the key belonging to the
respective TESLA interval communicated in the exchange had not
been disclosed before the client_keycheck message was sent.</t>
<t>guarantees to the client the timeliness of any broadcast
packet secured with this key if it arrived before
client_keycheck was sent.</t>
</list></t>
</section>
<section title="Message Type: "client_keycheck"">
<t>A message of this type is sent by the client in order to initiate
an additional check of packet timeliness for the TESLA scheme. It
contains<list style="symbols">
<t>the NTS message ID "client_keycheck",</t>
<t>the NTS version number negotiated during association,</t>
<t>a nonce,</t>
<t>an interval number from the TESLA disclosure schedule,</t>
<t>the MAC algorithm negotiated during association,</t>
<t>the client's key input value KIV, and</t>
<t>optional: a MAC (generated with the cookie as key) for
verification of all of the above data.</t>
</list></t>
</section>
<section anchor="server_keycheck"
title="Message Type: "server_keycheck"">
<t>A message of this type is sent by the server upon receipt of a
client_keycheck message during the broadcast loop of the server.
Prior to this, the server MUST recalculate the client's cookie by
using the received key input value and the transmitted MAC
algorithm. It contains<list style="symbols">
<t>the NTS message ID "server_keycheck"</t>
<t>the version number as transmitted in "client_keycheck,</t>
<t>the nonce transmitted in the client_keycheck message,</t>
<t>the interval number transmitted in the client_keycheck
message, and</t>
<t>a MAC (generated with the cookie as key) for verification of
all of the above data.</t>
</list></t>
</section>
<section title="Procedure Overview of the Broadcast Keycheck Exchange">
<t>A broadcast keycheck message exchange consists of the following
steps: <list style="numbers">
<t>The client sends a client_keycheck message. It MUST memorize
the nonce and the time interval number that it sends as a
correlated pair.</t>
<t>Upon receipt of a client_keycheck message the server performs
as follows: If the client_keycheck message contains a MAC the
server re-calculates the MAC and compares this value with the
MAC in the received data.<list style="symbols">
<t>If the re-calculated MAC does not match the MAC in the
received data the server MUST stop the processing of the
request.</t>
<t>If the re-calculated MAC matches the MAC in the received
data the server continues to process the request: It looks
up whether it has already disclosed the key associated with
the interval number transmitted in that message. If it has
not disclosed it, it constructs and sends the appropriate
server_keycheck message as described in <xref
target="server_keycheck"/>. For more details, see also <xref
target="appBroadcast"/>.</t>
</list></t>
<t>The client awaits a reply in the form of a server_keycheck
message. On receipt, it performs the following checks:<list
style="symbols">
<t>that the transmitted version number matches the one
negotiated previously,</t>
<t>that the transmitted nonce belongs to a previous
client_keycheck message,</t>
<t>that the TESLA interval number in that client_keycheck
message matches the corresponding interval number from the
server_keycheck, and</t>
<t>that the appended MAC verifies the received data.</t>
</list></t>
</list></t>
<figure>
<artwork><![CDATA[ +----------------------+
| o Assemble response |
| o Re-generate cookie |
| o Generate MAC |
+-----------+----------+
|
<-+->
Server --------------------------------------------->
\ /| \
\ server_ client_ / \ server_
\ broad keycheck / \ keycheck
\| / \|
Client --------------------------------------------->
<-------- Extended broadcast time ------->
synchronization exchange
<---- Keycheck exchange --->
]]></artwork>
<postamble>Procedure for extended broadcast time synchronization
exchange.</postamble>
</figure>
</section>
</section>
</section>
<section anchor="serverseedconsiderations"
title="Server Seed, MAC Algorithms and Generating MACs">
<section title="Server Seed">
<t>The server has to calculate a random seed which has to be kept
secret. The server MUST generate a seed for each supported MAC
algorithm, see <xref target="hash"/>.</t>
<t>According to the requirements in <xref target="RFC7384"/>, the
server MUST refresh each server seed periodically. Consequently, the
cookie memorized by the client becomes obsolete. In this case, the
client cannot verify the MAC attached to subsequent time response
messages and has to respond accordingly by re-initiating the protocol
with a cookie request (<xref target="cookiemessage"/>).</t>
</section>
<section anchor="hash" title="MAC Algorithms">
<t>MAC algorithms are used for calculation of the cookie and the
actual MAC. The client and the server negotiate a MAC algorithm during
the association phase at the beginning. The selected algorithm MUST be
used for all cookie and MAC creation processes in that run.</t>
<t><list style="hanging">
<t hangText="Note:">Any MAC algorithm is prone to be compromised
in the future. A successful attack on a MAC algorithm would enable
any NTS client to derive the server seed from its own cookie.
Therefore, the server MUST have separate seed values for its
different supported MAC algorithms. This way, knowledge gained
from an attack on a MAC algorithm can at least only be used to
compromise such clients who use this algorithm as well.</t>
</list></t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>As mentioned, this document generically specifies security measures
whose utilization for any given specific time synchronization protocol
requires a separate document. Consequently, this document itself does
not have any IANA actions (TO BE REVIEWED).</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>Aspects of security for time synchronization protocols are treated
throughout this document. For a comprehensive discussion of security
requirements in time synchronization contexts, refer to <xref
target="RFC7384"/>. See <xref target="appSecurityRequirements"/> for a
tabular overview of how NTS deals with those requirements.</t>
<t>Additional NTS specific discussion of security issues can be found in
the following subsections. <list style="hanging">
<t hangText="Note:">Any separate document describing the utilization
of NTS to a specific time synchronization protocol may additionally
introduce discussion of its own specific security
considerations.</t>
</list></t>
<section title="Privacy">
<t>The payload of time synchronization protocol packets of two-way
time transfer approaches like NTP and PTP consists basically of time
stamps, which are not considered secret <xref target="RFC7384"/>.
Therefore, encryption of the time synchronization protocol packet's
payload is not considered in this document. However, an attacker can
exploit the exchange of time synchronization protocol packets for
topology detection and inference attacks as described in <xref
target="RFC7624"/>. To make such attacks more difficult, that draft
recommends the encryption of the packet payload. Yet, in the case of
time synchronization protocols the confidentiality protection of time
synchronization packet's payload is of secondary importance since the
packet's meta data (IP addresses, port numbers, possibly packet size
and regular sending intervals) carry more information than the
payload. To enhance the privacy of the time synchronization partners,
the usage of tunnel protocols such as IPsec and MACsec, where
applicable, is therefore more suited than confidentiality protection
of the payload.</t>
</section>
<section title="Initial Verification of the Server Certificates">
<t>The client may wish to verify the validity of certificates during
the initial association phase. Since it generally has no reliable time
during this initial communication phase, it is impossible to verify
the period of validity of the certificates. To solve this
chicken-and-egg problem, the client has to rely on external means.</t>
</section>
<section title="Revocation of Server Certificates">
<t>According to <xref target="serverseedconsiderations"/>, it is the
client's responsibility to initiate a new association with the server
after the server's certificate expires. To this end, the client reads
the expiration date of the certificate during the certificate message
exchange (<xref target="server_assoc"/>). Furthermore, certificates
may also be revoked prior to the normal expiration date. To increase
security the client MAY periodically verify the state of the server's
certificate via Online Certificate Status Protocol (OCSP) <xref
target="RFC6960">Online Certificate Status Protocol (OCSP)</xref>.</t>
</section>
<section anchor="secBroadcast"
title="Mitigating Denial-of-Service for broadcast packets">
<t>TESLA authentication buffers packets for delayed authentication.
This makes the protocol vulnerable to flooding attacks, causing the
client to buffer excessive numbers of packets. To add stronger DoS
protection to the protocol, the client and the server use the "not
re-using keys" scheme of TESLA as pointed out in Section 3.7.2 of
<xref target="RFC4082">RFC 4082</xref>. In this scheme the server
never uses a key for the MAC generation more than once. Therefore, the
client can discard any packet that contains a disclosed key it already
knows, thus preventing memory flooding attacks.</t>
<t><list style="hanging">
<t hangText="Discussion:">Note that an alternative approach to
enhance TESLA's resistance against DoS attacks involves the
addition of a group MAC to each packet. This requires the exchange
of an additional shared key common to the whole group. This adds
additional complexity to the protocol and hence is currently not
considered in this document.</t>
</list></t>
</section>
<section anchor="DelayAttack" title="Delay Attack">
<t>In a packet delay attack, an adversary with the ability to act as a
MITM delays time synchronization packets between client and server
asymmetrically <xref target="RFC7384"/>. This prevents the client from
accurately measuring the network delay, and hence its time offset to
the server <xref target="Mizrahi"/>. The delay attack does not modify
the content of the exchanged synchronization packets. Therefore,
cryptographic means do not provide a feasible way to mitigate this
attack. However, several non-cryptographic precautions can be taken in
order to detect this attack.</t>
<t><list style="numbers">
<t>Usage of multiple time servers: this enables the client to
detect the attack, provided that the adversary is unable to delay
the synchronization packets between the majority of servers. This
approach is commonly used in NTP to exclude incorrect time servers
<xref target="RFC5905"/>.</t>
<t>Multiple communication paths: The client and server utilize
different paths for packet exchange as described in the I-D <xref
target="I-D.ietf-tictoc-multi-path-synchronization"/>. The client
can detect the attack, provided that the adversary is unable to
manipulate the majority of the available paths <xref
target="Shpiner"/>. Note that this approach is not yet available,
neither for NTP nor for PTP.</t>
<t>Usage of an encrypted connection: the client exchanges all
packets with the time server over an encrypted connection (e.g.
IPsec). This measure does not mitigate the delay attack, but it
makes it more difficult for the adversary to identify the time
synchronization packets.</t>
<t>For unicast-type messages: Introduction of a threshold value
for the delay time of the synchronization packets. The client can
discard a time server if the packet delay time of this time server
is larger than the threshold value.</t>
</list></t>
<t>Additional provision against delay attacks has to be taken for
broadcast-type messages. This mode relies on the TESLA scheme which is
based on the requirement that a client and the broadcast server are
loosely time synchronized. Therefore, a broadcast client has to
establish time synchronization with its broadcast server before it
starts utilizing broadcast messages for time synchronization.</t>
<t>One possible way to achieve this initial synchronization is to
establish a unicast association with its broadcast server until time
synchronization and calibration of the packet delay time is achieved.
After that, the client can establish a broadcast association with the
broadcast server and utilizes TESLA to verify integrity and
authenticity of any received broadcast packets.</t>
<t>An adversary who is able to delay broadcast packets can cause a
time adjustment at the receiving broadcast clients. If the adversary
delays broadcast packets continuously, then the time adjustment will
accumulate until the loose time synchronization requirement is
violated, which breaks the TESLA scheme. To mitigate this
vulnerability the security condition in TESLA has to be supplemented
by an additional check in which the client, upon receipt of a
broadcast message, verifies the status of the corresponding key via a
unicast message exchange with the broadcast server (see <xref
target="authenticateRxPackets"/> for a detailed description of this
check). Note that a broadcast client should also apply the
above-mentioned precautions as far as possible.</t>
</section>
<section title="Random Number Generation">
<t>At various points of the protocol, the generation of random numbers
is required. The employed methods of generation need to be
cryptographically secure. See <xref target="RFC4086"/> for guidelines
concerning this topic.</t>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors would like to thank Tal Mizrahi, Russ Housley, Steven
Bellovin, David Mills, Kurt Roeckx, Rainer Bermbach, Martin Langer and
Florian Weimer for discussions and comments on the design of NTS. Also,
thanks go to Harlan Stenn and Richard Welty for their technical review
and specific text contributions to this document.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include='reference.RFC.4082'?>
<?rfc include='reference.RFC.2104'?>
<?rfc include='reference.RFC.7384'?>
</references>
<references title="Informative References">
<reference anchor="Mizrahi" target="">
<front>
<title>A game theoretic analysis of delay attacks against time
synchronization protocols</title>
<author fullname="Tal Mizrahi" initials="T" surname="Mizrahi">
<organization abbrev=""/>
</author>
<date day="" month="September" year="2012"/>
</front>