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
1001
1002
1003
1004
1005
|
<pre>Network Working Group S. Fries
Request for Comments: 4442 H. Tschofenig
Category: Standards Track Siemens
March 2006
<span class="h1">Bootstrapping</span>
<span class="h1">Timed Efficient Stream Loss-Tolerant Authentication (TESLA)</span>
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
TESLA, the Timed Efficient Stream Loss-tolerant Authentication
protocol, provides source authentication in multicast scenarios.
TESLA is an efficient protocol with low communication and computation
overhead that scales to large numbers of receivers and also tolerates
packet loss. TESLA is based on loose time synchronization between
the sender and the receivers. Source authentication is realized in
TESLA by using Message Authentication Code (MAC) chaining. The use
of TESLA within the Secure Real-time Transport Protocol (SRTP) has
been published, targeting multicast authentication in scenarios where
SRTP is applied to protect the multimedia data. This solution
assumes that TESLA parameters are made available by out-of-band
mechanisms.
This document specifies payloads for the Multimedia Internet Keying
(MIKEY) protocol for bootstrapping TESLA for source authentication of
secure group communications using SRTP. TESLA may be bootstrapped
using one of the MIKEY key management approaches, e.g., by using a
digitally signed MIKEY message sent via unicast, multicast, or
broadcast.
<span class="grey">Fries & Tschofenig Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc4442">RFC 4442</a> Bootstrapping TESLA March 2006</span>
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
<a href="#section-2">2</a>. Terminology .....................................................<a href="#page-4">4</a>
<a href="#section-3">3</a>. TESLA Parameter Overview ........................................<a href="#page-4">4</a>
<a href="#section-4">4</a>. Parameter Encoding within MIKEY .................................<a href="#page-6">6</a>
<a href="#section-4.1">4.1</a>. Security Policy (SP) Payload ...............................<a href="#page-6">6</a>
<a href="#section-4.2">4.2</a>. TESLA Policy ...............................................<a href="#page-7">7</a>
<a href="#section-4.3">4.3</a>. Time Synchronization .......................................<a href="#page-8">8</a>
4.4. Key Data Transport within MIKEY's General
Extension Payload .........................................<a href="#page-10">10</a>
<a href="#section-5">5</a>. Security Considerations ........................................<a href="#page-11">11</a>
<a href="#section-5.1">5.1</a>. Man-in-the-Middle Attack ..................................<a href="#page-11">11</a>
<a href="#section-5.2">5.2</a>. Downgrading Attack ........................................<a href="#page-12">12</a>
<a href="#section-5.3">5.3</a>. Denial of Service Attack ..................................<a href="#page-12">12</a>
<a href="#section-5.4">5.4</a>. Replay Attack .............................................<a href="#page-13">13</a>
<a href="#section-5.5">5.5</a>. Traffic Analysis ..........................................<a href="#page-13">13</a>
<a href="#section-6">6</a>. IANA Considerations ............................................<a href="#page-14">14</a>
<a href="#section-7">7</a>. Acknowledgements ...............................................<a href="#page-15">15</a>
<a href="#section-8">8</a>. References .....................................................<a href="#page-16">16</a>
<a href="#section-8.1">8.1</a>. Normative References ......................................<a href="#page-16">16</a>
<a href="#section-8.2">8.2</a>. Informative References ....................................<a href="#page-16">16</a>
<span class="grey">Fries & Tschofenig Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc4442">RFC 4442</a> Bootstrapping TESLA March 2006</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
In many multicast, broadcast, and unicast communication scenarios, it
is necessary to guarantee that a received message has been sent from
a dedicated source and has not been altered in transit. In unicast
communication, commonly a pairwise security association exists that
enables the validation of message integrity and data origin. The
approach in group-based communication is different, as here a key is
normally shared between the members of a group and thus may not be
used for data origin authentication. As in some applications a
dedicated identification of a sender is required, there exists the
requirement to support data origin authentication also in multicast
scenarios. One of the methods supporting this is TESLA [<a href="./rfc4082" title=""Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction"">RFC4082</a>].
TESLA provides source authentication in multicast scenarios by using
MAC chaining. It is based on loose time synchronization between the
sender and the receivers.
[<a id="ref-RFC4383">RFC4383</a>] describes extensions for SRTP [<a href="./rfc3711" title=""The Secure Real-time Transport Protocol (SRTP)"">RFC3711</a>] in order to support
TESLA [<a href="./rfc4082" title=""Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction"">RFC4082</a>] for source authentication in multicast scenarios.
SRTP needs dedicated cryptographic context describing the security
parameter and security policy per multimedia session to be protected.
This cryptographic context needs to be enhanced with a set of TESLA
parameters. It is necessary to provide these parameters before the
actual multicast session starts. [<a href="./rfc4383" title=""The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Secure Real-time Transport Protocol (SRTP)"">RFC4383</a>] does not address the
bootstrapping for these parameters.
This document details bootstrapping of TESLA parameters in terms of
parameter distribution for TESLA policy as well as the initial key,
using the Multimedia Internet Keying (MIKEY) [<a href="./rfc3830" title=""MIKEY: Multimedia Internet KEYing"">RFC3830</a>] protocol.
MIKEY defines an authentication and key management framework that can
be used for real-time applications (both for peer-to-peer
communication and group communication). In particular, [<a href="./rfc3830" title=""MIKEY: Multimedia Internet KEYing"">RFC3830</a>] is
defined in a way that is intended to support SRTP in the first place
but is open to enhancements to be used for other purposes too.
Following the description in [<a href="./rfc3830" title=""MIKEY: Multimedia Internet KEYing"">RFC3830</a>], MIKEY is targeted for point-
to-point as well as group communication. In the context of group
communication, an administrator entity can distribute session keys to
the associated entities participating in the communication session.
This scenario is also applicable for TESLA where one entity may
provide information to many others in a way that the integrity of the
communicated information can be assured. The combination of MIKEY
and TESLA supports this group-based approach by utilizing the MIKEY
framework to distribute TESLA parameter information to all involved
entities. Note that this document focuses only on the distribution
of the parameters, not on the generation of those parameters.
MIKEY [<a href="./rfc3830" title=""MIKEY: Multimedia Internet KEYing"">RFC3830</a>] itself describes three authentication and key
exchange protocols (symmetric key encryption, public key encryption,
<span class="grey">Fries & Tschofenig Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc4442">RFC 4442</a> Bootstrapping TESLA March 2006</span>
and signed Diffie-Hellman). Extensions to the MIKEY key exchange
methods have been defined. A fourth key distribution method is
provided by [<a href="#ref-DHHMAC" title=""HMAC-authenticated Diffie-Hellman for MIKEY"">DHHMAC</a>] and describes a symmetrically protected Diffie-
Hellman key agreement. A further option has been proposed in [<a href="#ref-RSA-R" title=""An additional mode of key distribution in MIKEY: MIKEY-RSA-R"">RSA-R</a>]
that describes an enhanced asymmetric exchange variant, also
supporting inband certificate exchange. All the different key
management schemes mentioned above may be used to provide the TESLA
parameters. The required TESLA parameters to be exchanged are
already described in [<a href="./rfc4383" title=""The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Secure Real-time Transport Protocol (SRTP)"">RFC4383</a>], while this document describes their
transport within MIKEY.
The following security requirements have to be placed on the exchange
of TESLA parameters:
o Authentication and Integrity MUST be provided when sending the
TESLA parameters, especially for the initial key.
o Confidentiality MAY be provided for the TESLA parameters.
These security requirements apply to the TESLA bootstrapping
procedure only. Security requirements for applications using TESLA
are beyond the scope of this document. Security aspects that relate
to TESLA itself are described in [<a href="./rfc4082" title=""Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction"">RFC4082</a>], and security issues for
TESLA usage for SRTP are covered in [<a href="./rfc4383" title=""The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Secure Real-time Transport Protocol (SRTP)"">RFC4383</a>].
It is important to note that this document is one piece of a complete
solution. Assuming that media traffic is to be secured using TESLA
as described in [<a href="./rfc4383" title=""The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Secure Real-time Transport Protocol (SRTP)"">RFC4383</a>], then (a) keying material and (b)
parameters for TESLA are required. This document contributes the
parameters and the authentication methods used in MIKEY to provide
the keying material. The parameter exchange for TESLA also needs to
be secured against tampering. This protection is also provided by
MIKEY.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology</span>
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 <a href="./rfc2119">RFC 2119</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. TESLA Parameter Overview</span>
According to [<a href="./rfc4383" title=""The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Secure Real-time Transport Protocol (SRTP)"">RFC4383</a>], a number of transform-dependent parameters
need to be provided for proper TESLA operation. The complete list of
parameters can be found in <a href="./rfc4383#section-4.3">Section 4.3 of [RFC4383]</a>. Note that
parameter 10 of [<a href="./rfc4383" title=""The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Secure Real-time Transport Protocol (SRTP)"">RFC4383</a>], describing the lag of the receiver clock
relative to the sender clock, is omitted in this document since it
can be computed.
<span class="grey">Fries & Tschofenig Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc4442">RFC 4442</a> Bootstrapping TESLA March 2006</span>
MIKEY already requires synchronized clocks, which also provides for
synchronization for TESLA. Moreover, <a href="#section-4.3">Section 4.3</a> states an option to
use MIKEY for clock drift determination between the sender and
receiver. Thus, this parameter does not need to be transmitted in
MIKEY directly.
The information in brackets provides the default values as specified
in <a href="./rfc4383#section-6.2">Section 6.2 of [RFC4383]</a>.
1. An identifier for the PRF (TESLA PRF), implementing the one-way
function F(x) in TESLA (to derive the keys in the chain), and
the one-way function F'(x) in TESLA (to derive the keys for the
TESLA MAC, from the keys in the chain), e.g., to indicate the
keyed hash function (default HMAC-SHA1).
2. A non-negative integer, determining the length of the F output,
i.e., the length of the keys in the chain, which is also the key
disclosed in an SRTP packet if TESLA is used in the SRTP context
(default 160 bit).
3. A non-negative integer, determining the length of the output of
F', i.e., the length of the key for the TESLA MAC (default 160
bit).
4. An identifier for the TESLA MAC that accepts the output of F'(x)
as its key, e.g., to indicate a keyed hashing function (default
HMAC-SHA1).
5. A non-negative integer, determining the length of the output of
the TESLA MAC (default 80 bit).
6. The beginning of the session for which a key will be applied.
7. The interval duration (in milliseconds) for which a dedicated
key will be used.
8. The key disclosure delay (in number of intervals) characterizes
the period after which the key will be sent to the involved
entities (e.g., as part of SRTP packets).
9. Non-negative integer, determining the length of the key chain,
which is determined based on the expected duration of the
stream.
10. The initial key of the chain to which the sender has committed
himself.
<span class="grey">Fries & Tschofenig Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc4442">RFC 4442</a> Bootstrapping TESLA March 2006</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Parameter Encoding within MIKEY</span>
As mentioned in <a href="#section-3">Section 3</a>, TESLA parameters need to be transported
before actually starting a session. MIKEY currently only defines a
payload for transporting the SRTP policy (see <a href="./rfc3830#section-6.10">Section 6.10 of
[RFC3830]</a>). This section describes the enhancement of MIKEY to allow
the transport of a TESLA policy and additionally the initial TESLA
key.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Security Policy (SP) Payload</span>
The Security Policy payload defines a set of policies that apply to a
specific security protocol. The definition here relies on the
security policy payload definition in [<a href="./rfc3830" title=""MIKEY: Multimedia Internet KEYing"">RFC3830</a>].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next payload ! Policy no ! Prot type ! Policy param ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ length (cont) ! Policy param ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next payload (8 bits):
Identifies the payload that is added after
this payload. See <a href="./rfc3830#section-6.1">Section 6.1 of [RFC3830]</a> for
more details.
* Policy no (8 bits):
Each security policy payload must be given a
distinct number for the current MIKEY session by the
local peer. This number is used to map a cryptographic session
to a specific policy (see also <a href="./rfc3830#section-6.1.1">Section 6.1.1 of [RFC3830]</a>).
* Prot type (8 bits):
This value defines the security protocol.
A second value needs to be defined as shown below:
(MIKEY already defines the value 0.)
Prot type | Value |
---------------------------
SRTP | 0 |
TESLA | 1 |
* Policy param length (16 bits):
This field defines the total length of the
policy parameters for the selected security protocol.
<span class="grey">Fries & Tschofenig Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc4442">RFC 4442</a> Bootstrapping TESLA March 2006</span>
* Policy param (variable length):
This field defines the policy for the specific
security protocol.
The Policy param part is built up by a set of Type/Length/Value (TLV)
payloads. For each security protocol, a set of possible type/value
pairs can be negotiated as defined.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Type ! Length ! Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Type (8 bits):
Specifies the type of the parameter.
* Length (8 bits):
Specifies the length of the Value field (in bytes).
* Value (variable length):
Specifies the value of the parameter.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. TESLA Policy</span>
This policy specifies the parameters for TESLA. The types/values
that can be negotiated are defined by the following table. The
concrete default values are taken from [<a href="./rfc4383" title=""The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Secure Real-time Transport Protocol (SRTP)"">RFC4383</a>], but other values
may also be used:
Type | Meaning | Possible values
---------------------------------------------------------------
1 | PRF identifier for f and f', realising | see below
F(x) and F'(x)
2 | Length of PRF f' output | 160
3 | Identifier for the TESLA MAC | see below
4 | Length of TESLA MAC output | 80 (truncated)
5 | Start of session | in bytes
6 | Interval duration (in msec) | in bytes
7 | Key disclosure delay | in bytes
8 | Key chain length (number of intervals) | in bytes
9 | Local timestamp media receiver | see below
The time values stated in items 5 and 9 SHALL be transported in NTP-
UTC format, which is one of the three options described in <a href="./rfc3830#section-6.6">Section</a>
<a href="./rfc3830#section-6.6">6.6 of [RFC3830]</a>. A four-byte integer value for policy item 6 and a
two-byte integer value for policy item 7 are RECOMMENDED, carrying
interval duration and key disclosure delay. Policy type 9 stated
<span class="grey">Fries & Tschofenig Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc4442">RFC 4442</a> Bootstrapping TESLA March 2006</span>
above is optional and SHOULD be used if the time synchronization
described in <a href="#section-4.3">Section 4.3</a>, point two, is used. Otherwise, it SHOULD
be omitted.
For the PRF realizing F(x) and F'(x), a one-byte length is
sufficient. The currently defined possible values are:
TESLA PRF F(x), F'(x) | Value
------------------------------
HMAC-SHA1 | 0
For the TESLA MAC, a one-byte length is enough.
The currently defined possible values are:
TESLA MAC | Value
-----------------------
HMAC-SHA1 | 0
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. Time Synchronization</span>
MIKEY as well as TESLA require the time synchronization of the
communicating peers. MIKEY requires time synchronization to provide
timestamp-based replay protection for the one-roundtrip
authentication and key exchange protocols. TESLA, on the other hand,
needs this information to determine the clock drift between the
senders and the receivers in order to release the disclosed key
appropriately. Two alternatives are available for time
synchronization:
1. Usage of out-of-band synchronization using NTP [<a href="./rfc1305" title=""Network Time Protocol (Version 3) Specification, Implementation"">RFC1305</a>]. This
approach is already recommended within [<a href="./rfc3830" title=""MIKEY: Multimedia Internet KEYing"">RFC3830</a>]. The advantage
of this approach is the option to use the MIKEY key management
variants that perform within a half-roundtrip. The disadvantage
is the required time synchronization via an additional protocol.
2. [<a href="./rfc4082" title=""Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction"">RFC4082</a>] also sketches a possible inband synchronization in
<a href="#section-3.3.1">Section 3.3.1</a>. This approach is summarized here in the context
of MIKEY. Note that here the actual TESLA policy payload is
transmitted as part of the MIKEY responder message.
* The data receiver, which would be the MIKEY initiator, sets
the local time parameter t_r and sends it as part of the
timestamp payload as described in [<a href="./rfc3830" title=""MIKEY: Multimedia Internet KEYing"">RFC3830</a>]. This value t_r
needs to be stored locally.
* Upon receipt of the MIKEY initiator message, the data sender
replies with the MIKEY responder message, setting the local
time stamp at data receiver (parameter 11) to the value t_r
<span class="grey">Fries & Tschofenig Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc4442">RFC 4442</a> Bootstrapping TESLA March 2006</span>
received in the MIKEY initiator message, and sets his local
time as a 64-bit UTC value t_s in the timestamp payload as
described in [<a href="./rfc3830" title=""MIKEY: Multimedia Internet KEYing"">RFC3830</a>].
MIKEY initiator message
[MIKEY parameter incl. local timestamp (t_r)]
------------------>
MIKEY responder message
[MIKEY parameter incl. local timestamp (t_s), TESLA policy
payload, received local time stamp t_r]
<------------------
* Upon receiving the MIKEY responder message the data receiver
sets D_t = t_s - t_r + S, where S is an estimated bound on the
clock drift throughout the duration of the session.
This approach has the advantage that it does not require an
additional time synchronization protocol. The disadvantage is
the necessity to perform a full MIKEY handshake, to enable
correct parameter transport. Moreover this approach is direction
dependent, as it may only be applied if the media receiver is
also the MIKEY initiator.
Out-of-band synchronization using NTP (i.e., alternative 1) is the
RECOMMENDED approach for clock synchronization. In scenarios where
the media receiver is also the MIKEY initiator piggybacking timestamp
information in MIKEY (i.e., alternative 2) MAY be used to allow for
inband determination of the clock drift between sender and receiver.
<span class="grey">Fries & Tschofenig Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc4442">RFC 4442</a> Bootstrapping TESLA March 2006</span>
<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>. Key Data Transport within MIKEY's General Extension Payload</span>
The General Extensions Payload was defined to allow possible
extensions to MIKEY without the need for defining a completely new
payload each time. This payload can be used in any MIKEY message and
is part of the authenticated/signed data part.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next payload ! Type ! Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next payload (8 bits):
Identifies the payload following this payload.
* Type (8 bits):
Identifies the type of general payload.
MIKEY already defines the values 0 and 1.
This document introduces a new value (2).
Type | Value | Comments
----------------------------------------------------
Vendor ID | 0 | Vendor specific byte string
SDP IDs | 1 | List of SDP key mgmt IDs
TESLA I-Key | 2 | TESLA initial key
* Length (16 bits):
The length in bytes of the Data field.
* Data (variable length):
The general payload data.
<span class="grey">Fries & Tschofenig Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc4442">RFC 4442</a> Bootstrapping TESLA March 2006</span>
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Security Considerations</span>
The security properties of multi-media data in a multicast
environment depends on a number of building blocks.
SRTP-TESLA [<a href="./rfc4383" title=""The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Secure Real-time Transport Protocol (SRTP)"">RFC4383</a>] describes extensions for SRTP [<a href="./rfc3711" title=""The Secure Real-time Transport Protocol (SRTP)"">RFC3711</a>] in order
to support TESLA [<a href="./rfc4082" title=""Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction"">RFC4082</a>] for source authentication in multicast
scenarios. As such, security considerations described with TESLA
(see [<a href="#ref-PCST" title=""Efficient and Secure Source Authentication for Multicast"">PCST</a>] and [<a href="./rfc4082" title=""Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction"">RFC4082</a>]), the TESLA SRTP mapping [<a href="./rfc4383" title=""The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Secure Real-time Transport Protocol (SRTP)"">RFC4383</a>], and
SRTP [<a href="./rfc3711" title=""The Secure Real-time Transport Protocol (SRTP)"">RFC3711</a>] itself are relevant in this context.
Furthermore, since this document details bootstrapping of TESLA using
the Multimedia Internet Keying (MIKEY) [<a href="./rfc3830" title=""MIKEY: Multimedia Internet KEYing"">RFC3830</a>] protocol, the
security considerations of MIKEY are applicable to this document.
As a summary, in order for a multi-media application to support
TESLA, the following protocol interactions (in relationship to this
document) are necessary:
o MIKEY [<a href="./rfc3830" title=""MIKEY: Multimedia Internet KEYing"">RFC3830</a>] is executed between the desired entities to
perform authentication and a secure distribution of keying
material. In order to subsequently use TESLA, the parameters
described in this document are distributed using MIKEY. MIKEY
itself uses another protocol for parameter transport, namely, the
Session Description Protocol (SDP) [<a href="./rfc2327" title=""SDP: Session Description Protocol"">RFC2327</a>]. SDP might again be
used within Session Initiation Protocol (SIP, [<a href="./rfc3261" title=""SIP: Session Initiation Protocol"">RFC3261</a>]) to set up
a session between the desired entities.
o After the algorithms, parameters, and session keys are available
at the respective communication entities, data traffic protection
via SRTP-TESLA [<a href="./rfc4383" title=""The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Secure Real-time Transport Protocol (SRTP)"">RFC4383</a>] can be used. SRTP-TESLA itself applies
TESLA to the SRTP protocol, and as such the processing guidelines
of TESLA need to be followed.
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Man-in-the-Middle Attack</span>
Threat:
The exchange of security-related parameters and algorithms without
mutual authentication of the two peers can allow an adversary to
perform a man-in-the-middle attack. The mechanisms described in
this document do not themselves provide such an authentication and
integrity protection.
Countermeasures:
Throughout the document, it is assumed that the parameter exchange
is secured using another protocol, i.e., the exchange parameters
<span class="grey">Fries & Tschofenig Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc4442">RFC 4442</a> Bootstrapping TESLA March 2006</span>
and algorithms are part of a authentication and key exchange
protocol (namely, MIKEY). Source authentication of group and
multicast communication cannot be provided for the data traffic if
the prior signaling exchange did not provide facilities to
authenticate the source. Using an authentication protocol that
does not provide session keys as part of a successful protocol
exchange will make it impossible to derive the necessary
parameters required by TESLA. MIKEY provides session key
establishment. Additionally, the exchange of parameters and
algorithms MUST be authenticated and integrity protected. The
security protection of the parameter exchange needs to provide the
same level or a higher level of security.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Downgrading Attack</span>
Threat:
The exchange of security-related parameters and algorithms is
always subject to downgrading whereby an adversary modifies some
(or all) of the provided parameters. For example, a few
parameters require that a supported hash algorithm be listed. To
mount an attack, the adversary has to modify the list of provided
algorithms and to select the weakest one.
Countermeasures:
TESLA parameter bootstrapping MUST be integrity protected to
prevent modification of the parameters and their values.
Moreover, since unmodified parameters from an unknown source are
not useful, authentication MUST be provided. This functionality
is not provided by mechanisms described in this document.
Instead, the capabilities of the underlying authentication and key
exchange protocol (MIKEY) are reused for this purpose.
<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>. Denial of Service Attack</span>
Threat:
An adversary might want to modify parameters exchanged between the
communicating entities in order to establish different state
information at the respective communication entities. For
example, an adversary might want to modify the key disclosure
delay or the interval duration in order to disrupt the
communication at a later state since the TESLA algorithm assumes
that the participating communication entities know the same
parameter set.
<span class="grey">Fries & Tschofenig Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc4442">RFC 4442</a> Bootstrapping TESLA March 2006</span>
Countermeasures:
The exchanged parameters and the parameters and algorithms MUST be
integrity protected to allow the recipient to detect whether an
adversary attempted to modify the exchanged information.
Authentication and key exchange algorithms provided by MIKEY offer
this protection.
<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a>. Replay Attack</span>
Threat:
An adversary who is able to eavesdrop on one or multiple protocol
exchanges (MIKEY exchanges with the parameters described in this
document) might be able to replay the payloads in a later protocol
exchange. If the recipients accept the parameters and algorithms
(or even the messages that carry these payloads), then a denial of
service, downgrading, or a man-in-the-middle attack might be the
consequence (depending on the entire set of replayed attributes
and messages).
Countermeasures:
In order to prevent replay attacks, a freshness guarantee MUST be
provided. As such, the TESLA bootstrapping message exchange MUST
be unique and fresh, and the corresponding authentication and key
exchange protocol MUST provide the same properties. In fact, it
is essential to derive a unique and fresh session key as part of
the authentication and key exchange protocol run that MUST be
bound to the protocol session. This includes the exchanged
parameters.
<span class="h3"><a class="selflink" id="section-5.5" href="#section-5.5">5.5</a>. Traffic Analysis</span>
Threat:
An adversary might be able to learn parameters and algorithms if
he is located along the signaling path. This information can then
later be used to mount attacks against the end-to-end multimedia
communication. In some high-security and military environments,
it might even be desirable not to reveal information about the
used parameters to make it more difficult to launch an attack.
Countermeasures:
Confidentiality protection can be provided by a subset of the
available MIKEY authentication and key exchange protocols, namely,
those providing public key encryption and symmetric key
<span class="grey">Fries & Tschofenig Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc4442">RFC 4442</a> Bootstrapping TESLA March 2006</span>
encryption. The initial hash key, which is also one of the TESLA
bootstrapping parameters, does not require confidentiality
protection due to the properties of a hash chain.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. IANA Considerations</span>
This document requires an IANA registration for the following
attributes. The registries are provided by MIKEY [<a href="./rfc3830" title=""MIKEY: Multimedia Internet KEYing"">RFC3830</a>].
Prot Type:
This attribute specifies the protocol type for the security
protocol as described in <a href="#section-4.1">Section 4.1</a>.
Type:
Identifies the type of the general payload. The General
Extensions Payload was defined to allow possible extensions to
MIKEY without the need for defining a completely new payload each
time. <a href="#section-4.4">Section 4.4</a> describes this attribute in more detail.
Following the policies outlined in [<a href="./rfc3830" title=""MIKEY: Multimedia Internet KEYing"">RFC3830</a>], the values in the range
up to 240 (including 240) for the above attributes are assigned after
expert review by the MSEC working group or its designated successor.
The values in the range from 241 to 255 are reserved for private use.
The IANA has added the following attributes and their respective
values to an existing registry created in [<a href="./rfc3830" title=""MIKEY: Multimedia Internet KEYing"">RFC3830</a>]:
Prot Type:
Prot Type | Value | Description
-----------------------------------------------------
TESLA | 1 | TESLA as a security protocol
The value of 1 for the 'Prot Type' must be added to the 'Prot type'
registry created by [<a href="./rfc3830" title=""MIKEY: Multimedia Internet KEYing"">RFC3830</a>].
Type:
Type | Value | Description
-------------------------------------------
TESLA I-Key | 2 | TESLA initial key
The value of 2 for the 'Type' must be added to the 'Type' registry
created by [<a href="./rfc3830" title=""MIKEY: Multimedia Internet KEYing"">RFC3830</a>]. The values of 0 and 1 are already registered
in [<a href="./rfc3830" title=""MIKEY: Multimedia Internet KEYing"">RFC3830</a>].
<span class="grey">Fries & Tschofenig Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc4442">RFC 4442</a> Bootstrapping TESLA March 2006</span>
Also, the IANA has created two new registries:
TESLA-PRF: Pseudo-random Function (PRF) used in the TESLA policy:
This attribute specifies values for pseudo-random functions used
in the TESLA policy (see <a href="#section-4.2">Section 4.2</a>).
TESLA-MAC: MAC Function used in TESLA:
This attribute specifies values for pseudo-random functions used
in the TESLA policy (see <a href="#section-4.2">Section 4.2</a>).
Following the policies outlined in [<a href="./rfc2434" title="">RFC2434</a>], the values for the
TESLA-PRF and the TESLA-MAC registry in the range up to 240
(including 240) for the above attributes are assigned after expert
review by the MSEC working group or its designated successor. The
values in the range from 241 to 255 are reserved for private use.
IANA has added the following values to the TESLA-PRF and the
TESLA-MAC registry:
TESLA-PRF:
PRF Function | Value
--------------------------
HMAC-SHA1 | 0
TESLA-MAC:
MAC Function | Value
--------------------------
HMAC-SHA1 | 0
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Acknowledgements</span>
The authors would like to thank Mark Baugher and Ran Canetti for the
discussions in context of time synchronization. Additionally, we
would like to thank Lakshminath Dondeti, Russ Housley, and Allison
Mankin for their document reviews and for their guidance.
<span class="grey">Fries & Tschofenig Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc4442">RFC 4442</a> Bootstrapping TESLA March 2006</span>
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. References</span>
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-RFC2434">RFC2434</a>] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", <a href="https://www.rfc-editor.org/bcp/bcp26">BCP 26</a>, <a href="./rfc2434">RFC 2434</a>,
October 1998.
[<a id="ref-RFC3830">RFC3830</a>] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing", <a href="./rfc3830">RFC 3830</a>,
August 2004.
[<a id="ref-RFC4082">RFC4082</a>] Perrig, A., Song, D., Canetti, R., Tygar, J., and B.
Briscoe, "Timed Efficient Stream Loss-Tolerant
Authentication (TESLA): Multicast Source Authentication
Transform Introduction", <a href="./rfc4082">RFC 4082</a>, June 2005.
[<a id="ref-RFC4383">RFC4383</a>] Baugher, M. and E. Carrara, "The Use of Timed Efficient
Stream Loss-Tolerant Authentication (TESLA) in the Secure
Real-time Transport Protocol (SRTP)", <a href="./rfc4383">RFC 4383</a>,
February 2006.
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. Informative References</span>
[<a id="ref-DHHMAC">DHHMAC</a>] Euchner, M., "HMAC-authenticated Diffie-Hellman for
MIKEY", Work in Progress, April 2005.
[<a id="ref-PCST">PCST</a>] Perrig, A., Canetti, R., Song, D., and D. Tygar,
"Efficient and Secure Source Authentication for
Multicast", in Proc. of Network and Distributed System
Security Symposium NDSS 2001, pp. 35-46, 2001.
[<a id="ref-RFC1305">RFC1305</a>] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation", <a href="./rfc1305">RFC 1305</a>, March 1992.
[<a id="ref-RFC2327">RFC2327</a>] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", <a href="./rfc2327">RFC 2327</a>, April 1998.
[<a id="ref-RFC3261">RFC3261</a>] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", <a href="./rfc3261">RFC 3261</a>,
June 2002.
<span class="grey">Fries & Tschofenig Standards Track [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc4442">RFC 4442</a> Bootstrapping TESLA March 2006</span>
[<a id="ref-RFC3711">RFC3711</a>] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
<a href="./rfc3711">RFC 3711</a>, March 2004.
[<a id="ref-RSA-R">RSA-R</a>] Ignjatic, D., "An additional mode of key distribution in
MIKEY: MIKEY-RSA-R", Work in Progress, February 2006.
Authors' Addresses
Steffen Fries
Siemens
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
EMail: steffen.fries@siemens.com
Hannes Tschofenig
Siemens
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
EMail: Hannes.Tschofenig@siemens.com
<span class="grey">Fries & Tschofenig Standards Track [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc4442">RFC 4442</a> Bootstrapping TESLA March 2006</span>
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Fries & Tschofenig Standards Track [Page 18]
</pre>
|
