idnits 2.17.00 (12 Aug 2021) /tmp/idnits16739/draft-ietf-msec-srtp-tesla-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.5 on line 699. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 166: '... TESLA is an OPTIONAL authentication...' RFC 2119 keyword, line 202: '... SHALL be inserted before the (optio...' RFC 2119 keyword, line 239: '... that it is OPTIONAL to apply TESLA,...' RFC 2119 keyword, line 240: '... OPTIONAL....' RFC 2119 keyword, line 258: '...tion 3.2 of SRTP SHALL include the fol...' (23 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2004) is 6518 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2119' is mentioned on line 109, but not defined == Missing Reference: 'RFC2104' is mentioned on line 600, but not defined == Unused Reference: 'RFC1305' is defined on line 662, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'PCST' ** Obsolete normative reference: RFC 1305 (Obsoleted by RFC 5905) == Outdated reference: draft-ietf-msec-tesla-intro has been published as RFC 4082 ** Downref: Normative reference to an Informational draft: draft-ietf-msec-tesla-intro (ref. 'TESLA') -- Obsolete informational reference (is this intentional?): RFC 3547 (ref. 'GDOI') (Obsoleted by RFC 6407) Summary: 12 errors (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Baugher (Cisco) 3 MSEC Working Group Carrara (Ericsson) 4 INTERNET-DRAFT 5 EXPIRES: January 2005 July 2004 7 The Use of TESLA in SRTP 8 10 Status of this memo 12 By submitting this Internet-Draft, the authors certify that any 13 applicable patent or other IPR claims of which I am (we are) aware 14 have been disclosed, and any of which I (we) become aware will be 15 disclosed, in accordance with RFC 3668 (BCP 79). 17 By submitting this Internet-Draft, the authors accept the provisions 18 of Section 3 of RFC 3667 (BCP 78). 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as 23 reference material or cite them other than as "work in progress". 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 Abstract 33 This memo describes the use of the Timed Efficient Stream loss- 34 tolerant Authentication (TESLA) transform within the Secure Real- 35 time Transport Protocol (SRTP), to provide data origin 36 authentication for multicast and broadcast data streams. 38 TABLE OF CONTENTS 40 1. Introduction...................................................2 41 1.1. Notational Conventions.......................................3 42 2. SRTP...........................................................3 43 3. TESLA..........................................................4 44 4. Usage of TESLA within SRTP.....................................4 45 4.1. The TESLA extension..........................................4 46 4.2. SRTP Packet Format...........................................5 47 4.3. Extension of the SRTP Cryptographic Context..................7 48 4.4. SRTP Processing..............................................8 49 4.4.1 Sender Processing...........................................8 50 4.4.2 Receiver Processing.........................................9 51 4.5. SRTCP Packet Format.........................................10 52 4.6. TESLA MAC...................................................12 53 4.7. PRFs........................................................12 54 5. TESLA Bootstrapping...........................................13 55 6. SRTP TESLA Default parameters.................................13 56 6.2 Transform-dependent Parameters for TESLA MAC.................14 57 7. Security Considerations.......................................14 58 8. IANA Considerations...........................................15 59 9. Acknowledgements..............................................15 60 10. Author's Addresses...........................................15 61 11. References...................................................16 63 1. Introduction 65 Multicast and broadcast communication introduce some new security 66 challenges compared to unicast communication. Many multicast and 67 broadcast applications need "data origin authentication" (DOA), or 68 "source authentication", in order to guarantee that a received 69 message had originated from a given source, and was not manipulated 70 during the transmission. In unicast communication, a pairwise 71 security association between one sender and one receiver can provide 72 data origin authentication using symmetric-key cryptography (such as 73 a message authentication code, MAC). When the communication is 74 strictly pairwise, the sender and receiver agree upon a key that is 75 known only to them. 77 In groups, however, a key is shared among more than two members, and 78 this symmetric-key approach does not guarantee data origin 79 authentication. When there is a group security association 80 [gkmarch] instead of a pairwise security association, any of the 81 members can alter the packet and impersonate any other member. The 82 MAC in this case only guarantees that the packet was not manipulated 83 by an attacker outside the group (and hence not in possession of the 84 group key), and that the packet was sent by a source within the 85 group. 87 Some applications cannot tolerate source ambiguity and must discern 88 the true sender from any other group member. A common way to solve 89 the problem is by use of asymmetric cryptography, such as digital 90 signatures. This method, unfortunately, suffers from high overhead, 91 in terms of time (to sign and verify) and bandwidth (to convey the 92 signature in the packet). 94 Several schemes have been proposed to provide efficient data origin 95 authentication in multicast and broadcast scenarios. The Timed 96 Efficient Stream loss-tolerant Authentication (TESLA), is one such 97 scheme. 99 This memo specifies TESLA authentication for SRTP. SRTP TESLA can 100 provide data origin authentication to RTP applications that use 101 group security associations (such as multicast RTP applications) so 102 long as receivers abide by the TESLA security invariants [TESLA]. 104 1.1. Notational Conventions 106 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 This specification assumes the reader familiar with both SRTP and 111 TESLA. Few of their details are explained in this document, and the 112 reader can find them in their respective specifications [RFC3711], 113 [TESLA]. This specification uses the same definitions as TESLA for 114 common terms and assumes that the reader is familiar with the TESLA 115 algorithms and protocols [TESLA]. 117 2. SRTP 119 The Secure Real-time Transport Protocol (SRTP) [RFC3711] is a 120 profile of RTP, which can provide confidentiality, message 121 authentication, and replay protection to the RTP traffic and to the 122 RTP control protocol, the Real-time Transport Control Protocol 123 (RTCP). Note, the term SRTP may often used to indicate SRTCP as 124 well. 126 SRTP is a framework that allows new security functions and new 127 transforms to be added. SRTP currently does not define any 128 mechanism to provide data origin authentication for group security 129 associations. Fortunately, it is straightforward to add TESLA to 130 the SRTP cryptographic framework. 132 The TESLA extension to SRTP is defined in this specification, which 133 assumes that the reader is familiar with the SRTP specification 134 [RFC3711], its packet structure, and processing rules. 136 3. TESLA 138 TESLA provides delayed per-packet data authentication and is 139 specified in [TESLA]. This specification assumes that the reader is 140 familiar with TESLA [TESLA]. 142 In addition to its SRTP data-packet definition given here, TESLA 143 needs an initial synchronization protocol and initial bootstrapping 144 procedure. The synchronization protocol allows the sender and the 145 receiver to compare their clocks and determine an upper bound of the 146 difference. The synchronization protocol is outside the scope of 147 this document. 149 TESLA also requires an initial bootstrapping procedure to exchange 150 needed parameters and the initial commitment to the key chain 151 [TESLA]. For SRTP, it is assumed that the bootstrapping is 152 performed out-of-band, possibly using the key management protocol 153 that is exchanging the security parameters for SRTP, e.g. [GDOI], 154 [MIKEY]. Initial bootstrapping of TESLA is outside the scope of 155 this document. 157 4. Usage of TESLA within SRTP 159 The present specification is an extension to the SRTP specification 160 [RFC3711] and describes the use of TESLA with only a single key 161 chain, and the delayed-authentication TESLA elements of procedure 162 [TESLA]. 164 4.1. The TESLA extension 166 TESLA is an OPTIONAL authentication transform for SRTP. When used, 167 TESLA adds the fields showed in Figure 1 per-packet. The fields 168 added by TESLA are called "TESLA authentication extensions" 169 altogether, whereas "authentication tag" or "integrity protection 170 tag" indicate the normal SRTP integrity protection tag, when the 171 SRTP master key is shared by more than two endpoints [RFC3711]. 173 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 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | I | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 ~ Disclosed Key ~ 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 ~ TESLA MAC ~ 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 Figure 1: The "TESLA authentication extension". 184 I: 32 bit, MANDATORY 185 Identifier of the time interval I, corresponding to the key K_i 186 that is used to calculate the TESLA MAC present in the current 187 packet (and in the packets sent in the current time interval I). 189 Disclosed Key: variable length, MANDATORY 190 The disclosed key (K_i-d), that can be used to authenticate 191 previous packets from earlier time intervals [TESLA]. 193 TESLA MAC (Message Authentication Code): variable length, MANDATORY 194 The MAC computed using the key K'_i (derived from K_i) [TESLA], 195 which is disclosed in a subsequent packet (in the Disclosed Key 196 field). The MAC coverage is defined in Section 4.6. 198 4.2. SRTP Packet Format 200 Figure 2 illustrates the format of the SRTP packet when TESLA is 201 applied. When applied to RTP, the TESLA authentication extension 202 SHALL be inserted before the (optional) SRTP MKI and (recommended) 203 authentication tag. 205 0 1 2 3 206 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 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+<+ 208 |V=2|P|X| CC |M| PT | sequence number | | | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 210 | timestamp | | | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 212 | synchronization source (SSRC) identifier | | | 213 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | 214 | contributing source (CSRC) identifiers | | | 215 | .... | | | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 217 | RTP extension (OPTIONAL) | | | 218 +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 219 | | payload ... | | | 220 | | +-------------------------------+ | | 221 | | | RTP padding | RTP pad count | | | 222 +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 223 | | I | | | 224 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ | 225 | ~ Disclosed Key ~ | | 226 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 227 | ~ TESLA MAC ~ | | 228 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<|-+ 229 | ~ MKI ~ | | | 230 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 231 | ~ MAC ~ | | 232 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 233 | | | 234 +- Encrypted Portion TESLA Authenticated Portion ---+ | 235 | 236 Authenticated Portion ---+ 238 Figure 2. The format of the SRTP packet when TESLA is applied. Note 239 that it is OPTIONAL to apply TESLA, i.e. the TESLA fields are 240 OPTIONAL. 242 As in SRTP, the "Encrypted Portion" of an SRTP packet consists of 243 the encryption of the RTP payload (including RTP padding when 244 present) of the equivalent RTP packet. 246 The "Authenticated Portion" of an SRTP packet consists of the RTP 247 header, the Encrypted Portion of the SRTP packet, and the TESLA 248 authentication extension. Note that the definition is extended from 249 [RFC3711] by the inclusion of the TESLA authentication extension. 251 The "TESLA Authenticated Portion" of an SRTP packet consists of the 252 RTP header, the Encrypted Portion of the SRTP packet, and the TESLA 253 I field. 255 4.3. Extension of the SRTP Cryptographic Context 257 When TESLA is used, the definition of cryptographic context in 258 Section 3.2 of SRTP SHALL include the following extensions. 260 Transform-independent Parameter 262 a flag indicating the use of TESLA in SRTP. When this bit is set, 263 the following TESLA transform-dependent parameters define the 264 particular TESLA configuration. 266 Transform-dependent Parameters 268 1. an identifier for the PRF, f, implementing the one-way function 269 F(x) in TESLA (to derive the keys in the chain), e.g. to 270 indicate HMAC-SHA1, see Section 6.2 for the default value. 272 2. a non-negative integer n_c, determining the length of the F 273 output, i.e. the length of the keys in the chain (that is also 274 the key disclosed in an SRTP packet), see Section 6.2 for the 275 default value. 277 3. an identifier for the PRF, f', implementing the one-way 278 function F'(x) in TESLA (to derive the keys for the TESLA MAC, 279 from the keys in the chain), e.g. to indicate HMAC-SHA1, see 280 Section 6.2 for the default value. 282 4. a non-negative integer n_f, determining the length of the 283 output of F', i.e. of the key for the TESLA MAC, see Section 284 6.2 for the default value. 286 5. an identifier for the TESLA MAC, that accepts the output of 287 F'(x) as its key, e.g. to indicate HMAC-SHA1, see Section 6.2 288 for the default value. 290 6. a non-negative integer n_m, determining the length of the 291 output of the TESLA MAC, see Section 6.2 for the default value. 293 7. the beginning of the session T_0, 295 8. the interval duration T_int (in msec), 297 9. the key disclosure delay d (in number of intervals) 298 10. non-negative integer n_c, determining the length of the key 299 chain, which is determined based up the expected duration of 300 the stream. 302 11. the initial key of the chain to which the sender has 303 committed himself. 305 F(x) is used to compute a keychain of keys in SRTP TESLA, as defined 306 in Section 6. Also according to TESLA, F'(x) computes a TESLA MAC 307 key with inputs as defined in Section 6. 309 Section 6 of this document defines the default values for the 310 transform-independent and transform-specific TESLA parameters. 312 4.4. SRTP Processing 314 The SRTP packet processing is described in Section 3.3 of the SRTP 315 specification [RFC3711]. The use of TESLA slightly changes the 316 processing, as the SRTP MAC is checked upon packet arrival for DoS 317 prevention, but the current packet is not TESLA-authenticated. Each 318 packet is buffered until a subsequent packet discloses its TESLA 319 key. The TESLA verification itself consists of some steps, such as 320 tests of TESLA security invariants, that are described in Section 321 3.5-3.7 of [TESLA]. The words "TESLA computation" and "TESLA 322 verification" hereby imply all those steps, which are not all 323 spelled out in the following. In particular, notice that the TESLA 324 verification implies checking the safety condition (Section 3.5 of 325 [TESLA]). If the safe condition does not hold, the packet MUST be 326 discarded. 328 4.4.1 Sender Processing 330 The sender processing is as described in Section 3.3 of [RFC3711], 331 up to step 5 included. After that the following process is 332 followed: 334 6. When TESLA is applied, identify the key in the TESLA chain to be 335 used in the current time interval, and the TESLA MAC key derived 336 from it. Execute the TESLA computation to obtain the TESLA 337 authentication extension for the current packet, by appending the 338 current interval time (as I field), the disclosed key of the chain 339 for an earlier packet, and the TESLA MAC under the current key from 340 the chain. This step uses the related TESLA parameters from the 341 crypto context as for Step 4. 343 7. If the MKI indicator in the SRTP crypto context is set to one, 344 append the MKI to the packet. 346 8. When TESLA is applied, compute the authentication tag as 347 described in step 7 of Section 3.3 of the SRTP specification, but 348 with coverage as defined in this specification (see Section 4.6). 350 9. If necessary, update the ROC (step 8 in Section 3.3 of 351 [RFC3711]). 353 4.4.2 Receiver Processing 355 The receiver processing is as described in Section 3.3 of [RFC3711], 356 up to step 4 included. 358 To authenticate and replay-protect the current packet, the 359 processing is the following: 361 First check if the packet has been replayed (as for Section 3.3 of 362 [RFC3711]). The SRTP replay list contains SRTP indices of recently 363 received packets that have been authenticated by TESLA. (I.e. 364 replay list updates MUST NOT be based on SRTP MAC.) If the packet 365 is judged to be replayed, then the packet MUST be discarded, and 366 the event SHOULD be logged. 368 Next, perform verification of the SRTP integrity protection tag 369 (note, not the TESLA MAC), if present, using the rollover counter 370 from the current packet, the authentication algorithm indicated in 371 the cryptographic context, and the session authentication key. If 372 the verification is unsuccessful, the packet MUST be discarded 373 from further processing and the event SHOULD be logged. 375 If the verification is successful, remove and store the MKI (if 376 present) and authentication tag fields from the packet. The packet 377 is buffered, awaiting disclosure of the TESLA key in a subsequent 378 packet. 380 TESLA authentication is performed on a packet when the key is 381 disclosed in a subsequent packet. When such key is disclosed, 382 perform the TESLA verification of the packet using the rollover 383 counter from the packet, the TESLA security parameters from the 384 cryptographic context, and the disclosed key. If the verification 385 is unsuccessful, the packet MUST be discarded from further 386 processing and the event SHOULD be logged. If the TESLA 387 verification is successful, remove the TESLA authentication 388 extension from the packet. 390 To decrypt the current packet, the processing is the following: 392 Decrypt the Encrypted Portion of the packet, using the decryption 393 algorithm indicated in the cryptographic context, the session 394 encryption key and salt (if used) found in Step 4 with the index 395 from Step 2. 397 (Note that the order of decryption and TESLA verification is not 398 mandated. It is up to the application if to perform decryption 399 immediately after the successful SRTP integrity protection 400 verification and then get informed if the TESLA authentication for 401 that packet has failed, or if to wait and TESLA- verify the packet 402 before further processing). 404 Update the rollover counter and highest sequence number, s_l, in the 405 cryptographic context, using the packet index estimated in Step 2. 406 If replay protection is provided, also update the Replay List (i.e., 407 the Replay List is updated after the TESLA authentication is 408 successfully verified). 410 4.5. SRTCP Packet Format 412 Figure 3 illustrates the format of the SRTCP packet when TESLA is 413 applied. The TESLA authentication extension SHALL be inserted 414 before the MKI and authentication tag. Recall from [RFC3711] that 415 in SRTCP the MKI is OPTIONAL, while the E-bit, the SRTCP index, and 416 the authentication tag are MANDATORY. 418 As in SRTP, the "Encrypted Portion" of an SRTCP packet consists of 419 the encryption of the RTCP payload of the equivalent compound RTCP 420 packet, from the first RTCP packet, i.e., from the ninth (9) octet 421 to the end of the compound packet. 423 The "Authenticated Portion" of an SRTCP packet consists of the 424 entire equivalent (eventually compound) RTCP packet, the E flag, the 425 SRTCP index (after any encryption has been applied to the payload), 426 and the TESLA extension. Note that the definition is extended from 427 [RFC3711] by the inclusion of the TESLA authentication extension. 429 We define the "TESLA Authenticated Portion" of an SRTCP packet as 430 consisting of the RTCP header (first 8 bytes), the Encrypted Portion 431 of the SRTCP packet, and the I field. 433 Processing of an SRTCP packets is similar to the SRTP processing 434 (Section 4.3), but there are SRTCP-specific changes described in 435 Section 3.4 of the SRTP specification [RFC3711] and in Section 4.6 436 of this memo. 438 0 1 2 3 439 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 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+<+ 441 |V=2|P| RC | PT=SR or RR | length | | | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 443 | SSRC of sender | | | 444 +>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | 445 | ~ sender info ~ | | 446 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 447 | ~ report block 1 ~ | | 448 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 449 | ~ report block 2 ~ | | 450 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 451 | ~ ... ~ | | 452 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 453 | |V=2|P| SC | PT=SDES=202 | length | | | 454 | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | 455 | | SSRC/CSRC_1 | | | 456 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 457 | ~ SDES items ~ | | 458 | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | 459 | ~ ... ~ | | 460 +>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | 461 | |E| SRTCP index | | | 462 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 463 | | I | | | 464 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ | 465 | ~ Disclosed Key ~ | | 466 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 467 | ~ TESLA MAC ~ | | 468 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<|-+ 469 | ~ SRTCP MKI ~ | | 470 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 471 | : authentication tag : | | 472 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 473 | | | 474 +-- Encrypted Portion TESLA Authenticated Portion -----+ | 475 | 476 Authenticated Portion -------+ 478 Figure 3. The format of the SRTCP packet when TESLA is applied. 479 Note that it is OPTIONAL to apply TESLA, i.e. the TESLA fields are 480 OPTIONAL. 482 4.6. TESLA MAC 484 Let M' denote packet data to be TESLA-authenticated. In the case of 485 SRTP, M' SHALL consist of the SRTP TESLA Authenticated Portion (RTP 486 header, SRTP Encrypted Portion, and I field) shown in Figure 1 or 487 Figure 2) of the packet concatenated with the ROC of the same 488 packet: 490 M' = ROC || TESLA Authenticated Portion. 492 In the case of SRTCP, M' SHALL consist of the SRTCP TESLA 493 Authenticated Portion only (RTCP header, SRTCP Encrypted Portion, 494 and I field). 496 The normal authentication tag SHALL be applied with the same 497 coverage as specified in [RFC3711], i.e.: 499 - for SRTP: Authenticated Portion || ROC (with the extended 500 definition of SRTP Authentication Portion as for Section 4.2) 502 - for SRTCP: Authenticated Portion (with the extended definition of 503 SRTCP Authentication Portion as for Section 4.2). 505 The pre-defined authentication transform in SRTP, HMAC-SHA1 506 [RFC2104], is also used to generate the TESLA MAC. For SRTP 507 (respectively SRTCP), the HMAC SHALL be applied to the key in the 508 TESLA chain corresponding to a particular time interval, and M' as 509 specified above. The HMAC output SHALL then be truncated to the n_m 510 left-most bits. Default values are in Section 6.2. 512 4.7. PRFs 514 TESLA requires two pseudo-random functions (PRFs), f and f', to 515 implement 517 * one one-way function F(x) to derive the key chain, and 518 * one one-way function F'(x) to derive (from each key of the chain) 519 the key that is actually used to calculate the TESLA MAC. 521 When TESLA is used within SRTP, the default choice of the two PRFs 522 SHALL be HMAC-SHA1. Default values are in Section 6.2. 524 Other PRFs can be chosen, and their use SHALL follow the common 525 guidelines in [RFC3711] when adding new security parameters. 527 5. TESLA Bootstrapping 529 The extensions to the SRTP cryptographic context include a set of 530 TESLA parameters that are listed in section 4.3 of this document. 531 Furthermore, TESLA MUST be bootstrapped at session set-up (for the 532 parameter exchange and the initial key commitment) through a regular 533 data authentication system (a digital signature algorithm is 534 RECOMMENDED). Key management procedures can take care of this 535 bootstrapping prior to the commencement of an SRTP session where 536 TESLA authentication is used. The bootstrapping mechanism is out of 537 scope for this document. 539 A critical factor for the security of TESLA is that the sender and 540 receiver need to be loosely synchronized. TESLA assumes that the 541 local internal clocks do not drift too much during the session. Use 542 of TESLA in SRTP assumes that the time synchronization is guaranteed 543 by out-of-band schemes (e.g. key management), i.e. it is not in the 544 scope of SRTP. 546 6. SRTP TESLA Default parameters 548 Key management procedures establish SRTP TESLA operating parameters 549 listed in section 4.3 of this document. The operating parameters 550 appear in the SRTP cryptographic context and have the following 551 default values. In the future, an Internet RFC MAY define 552 alternative settings for SRTP TESLA that are different than those 553 specified here. In particular, it should be noted that the settings 554 defined in this memo can have a large impact on bandwidth, as it 555 adds 38 bytes to each packet (when the field length values are the 556 default ones). For certain applications, this overhead may 557 represent more than a 50% increase in packet size. Alternative 558 settings might seek to reduce the number and length of various TESLA 559 fields and outputs. No such optimizations are considered in this 560 memo. 562 It is RECOMMENDED that the SRTP MAC be truncated to 32 bits since the 563 SRTP MAC provides only group authentication and serves only as 564 protection against external DoS. 566 6.1 Transform-independent Parameters 568 The value of the flag indicating the use of TESLA in SRTP is by 569 default zero (TESLA not used). 571 6.2 Transform-dependent Parameters for TESLA MAC 573 The default values for the security parameters are listed in the 574 following. "OWF" denotes a one-way function. 576 Parameter Mandatory-to-support Default 577 --------- -------------------- ------- 578 TESLA KEYCHAIN OWF (F(x)) HMAC-SHA1 HMAC-SHA1 579 OUTPUT LENGTH 160 160 581 TESLA MAC KEY OWF (F'(F(x))) HMAC-SHA1 HMAC-SHA1 582 OUTPUT LENGTH n_f 160 160 584 TESLA MAC HMAC-SHA1 HMAC-SHA1 585 (TRUNCATED) OUTPUT LENGTH n_m 80 80 587 As shown above, TESLA implementations MUST support HMAC-SHA1 for the 588 TESLA MAC, the MAC key generator, and the TESLA keychain generator 589 one-way function. The TESLA keychain generator is recursively 590 defined as follows [TESLA]. 592 K_i=HMAC_SHA1(K_{i+1},0), i=0..N-1 594 where N-1=n_c from the cryptographic context. 596 The TESLA MAC key generator is defined as follows [TESLA]. 598 K'_i=HMAC_SHA1(K_i,1) 600 The TESLA MAC uses a truncated output of ten bytes [RFC2104] and is 601 defined as follows. 603 HMAC_SHA1(K'_i, M') 605 where M' is as specified in Section 4.6. 607 7. Security Considerations 609 Denial of Service (DoS) attacks when delayed authentication is used 610 are discussed in [PCST]. TESLA requires receiver's buffering before 611 authentication, therefore the receiver can suffer a denial of 612 service attack due to a flood of bogus packets. To address this 613 problem, the current specification REQUIRES the use of a 32-bit SRTP 614 MAC in addition to TESLA MAC. The shorter size of the SRTP MAC is 615 here motivated by the fact that that MAC served purely for DoS 616 prevention from attackers external to the group. 618 The use of TESLA in SRTP defined in this specification is subject to 619 the security considerations discussed in the SRTP specification 620 [RFC3711] an in the TESLA specification [TESLA]. In particular, it 621 must be noted that the all TESLA security is dependent on the 622 computation of the "safety condition" as defined in Section 3.5 of 623 [TESLA]. 625 SRTP TESLA depends on the effective security of the systems that 626 perform bootstrapping (time synchronization) and key management. 627 These systems are external to SRTP and are not considered in this 628 specification. 630 8. IANA Considerations 632 No IANA registration is required. 634 9. Acknowledgements 636 The authors would like to thanks Ran Canetti, Karl Norrman, Mats 637 N„slund, and Fredrik Lindholm for their valuable help. 639 10. Author's Addresses 641 Questions and comments should be directed to the authors and 642 msec@ietf.org: 644 Mark Baugher 645 Cisco Systems, Inc. 646 5510 SW Orchid Street Phone: +1 408-853-4418 647 Portland, OR 97219 USA Email: mbaugher@cisco.com 649 Elisabetta Carrara 650 Ericsson Research 651 SE-16480 Stockholm Phone: +46 8 50877040 652 Sweden EMail: elisabetta.carrara@ericsson.com 654 11. References 656 Normative 658 [PCST] Perrig, A., Canetti, R., Song, D., Tygar, D., "Efficient and 659 Secure Source Authentication for Multicast", in Proc. of Network and 660 Distributed System Security Symposium NDSS 2001, pp. 35-46, 2001. 662 [RFC1305] Mills D., Network Time Protocol (Version 3) 663 Specification, Implementation and Analysis, RFC 1305, March, 1992. 664 http://www.ietf.org/rfc/rfc1305.txt 666 [RFC3711] Baugher, McGrew, Naslund, Carrara, Norrman, "The Secure 667 Real-time Transport Protocol", RFC 3711, March 2004. 669 [TESLA] Perrig, Canetti, Song, Tygar, Briscoe, "TESLA: Multicast 670 Source Authentication Transform Introduction", October 2002, draft- 671 ietf-msec-tesla-intro-02.txt. 673 Informative 675 [gkmarch] Baugher, Canetti, Dondeti, Lindholm, "MSEC Group Key 676 Management Architecture", June 2004, . 679 [GDOI] Baugher, Weis, Hardjono, Harney, "The Group Domain of 680 Interpretation", RFC 3547, July 2003. 682 [MIKEY] Arkko et al., "MIKEY: Multimedia Internet KEYing", December 683 2003, 685 Copyright Notice 687 Copyright (C) The Internet Society (2004). This document is subject 688 to the rights, licenses and restrictions contained in BCP 78, and 689 except as set forth therein, the authors retain all their rights. 691 Disclaimer of Validity 693 This document and the information contained herein are provided on 694 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 695 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 696 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 697 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 698 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 699 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 701 This draft expires in January 2005.