idnits 2.17.00 (12 Aug 2021) /tmp/idnits16088/draft-ietf-msec-srtp-tesla-03.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 725. ** 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 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 169: '... TESLA is an OPTIONAL authentication...' RFC 2119 keyword, line 205: '... SHALL be inserted before the (optio...' RFC 2119 keyword, line 242: '... that it is OPTIONAL to apply TESLA,...' RFC 2119 keyword, line 243: '... OPTIONAL....' RFC 2119 keyword, line 260: '...tion 3.2 of SRTP SHALL include the fol...' (25 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 (February 2005) is 6303 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 114, but not defined == Missing Reference: 'RFC2104' is mentioned on line 624, but not defined == Unused Reference: 'RFC1305' is defined on line 690, but no explicit reference was found in the text == Unused Reference: 'GDOI' is defined on line 706, but no explicit reference was found in the text == Unused Reference: 'RFC3830' is defined on line 709, 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: 11 errors (**), 0 flaws (~~), 9 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: August 2005 February 2005 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 working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as 28 reference material or cite them other than as "work in progress". 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 Abstract 38 This memo describes the use of the Timed Efficient Stream loss- 39 tolerant Authentication (TESLA) transform within the Secure Real- 40 time Transport Protocol (SRTP), to provide data origin 41 authentication for multicast and broadcast data streams. 43 TABLE OF CONTENTS 45 1. Introduction...................................................2 46 1.1. Notational Conventions.......................................3 47 2. SRTP...........................................................3 48 3. TESLA..........................................................4 49 4. Usage of TESLA within SRTP.....................................4 50 4.1. The TESLA extension..........................................4 51 4.2. SRTP Packet Format...........................................5 52 4.3. Extension of the SRTP Cryptographic Context..................7 53 4.4. SRTP Processing..............................................8 54 4.4.1 Sender Processing...........................................8 55 4.4.2 Receiver Processing.........................................9 56 4.5. SRTCP Packet Format.........................................10 57 4.6. TESLA MAC...................................................12 58 4.7. PRFs........................................................12 59 5. TESLA Bootstrapping and Cleanup...............................13 60 6. SRTP TESLA Default parameters.................................13 61 6.2 Transform-dependent Parameters for TESLA MAC.................14 62 7. Security Considerations.......................................15 63 8. IANA Considerations...........................................15 64 9. Acknowledgements..............................................15 65 10. Author's Addresses...........................................15 66 11. References...................................................16 68 1. Introduction 70 Multicast and broadcast communications introduce some new security 71 challenges compared to unicast communication. Many multicast and 72 broadcast applications need "data origin authentication" (DOA), or 73 "source authentication", in order to guarantee that a received 74 message had originated from a given source, and was not manipulated 75 during the transmission. In unicast communication, a pairwise 76 security association between one sender and one receiver can provide 77 data origin authentication using symmetric-key cryptography (such as 78 a message authentication code, MAC). When the communication is 79 strictly pairwise, the sender and receiver agree upon a key that is 80 known only to them. 82 In groups, however, a key is shared among more than two members, and 83 this symmetric-key approach does not guarantee data origin 84 authentication. When there is a group security association 85 [gkmarch] instead of a pairwise security association, any of the 86 members can alter the packet and impersonate any other member. The 87 MAC in this case only guarantees that the packet was not manipulated 88 by an attacker outside the group (and hence not in possession of the 89 group key), and that the packet was sent by a source within the 90 group. 92 Some applications cannot tolerate source ambiguity and must discern 93 the true sender from any other group member. A common way to solve 94 the problem is by use of asymmetric cryptography, such as digital 95 signatures. This method, unfortunately, suffers from high overhead, 96 in terms of time (to sign and verify) and bandwidth (to convey the 97 signature in the packet). 99 Several schemes have been proposed to provide efficient data origin 100 authentication in multicast and broadcast scenarios. The Timed 101 Efficient Stream loss-tolerant Authentication (TESLA) is one such 102 scheme. 104 This memo specifies TESLA authentication for SRTP. SRTP TESLA can 105 provide data origin authentication to RTP applications that use 106 group security associations (such as multicast RTP applications) so 107 long as receivers abide by the TESLA security invariants [TESLA]. 109 1.1. Notational Conventions 111 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 This specification assumes the reader familiar with both SRTP and 116 TESLA. Few of their details are explained in this document, and the 117 reader can find them in their respective specifications, [RFC3711] 118 and [TESLA]. This specification uses the same definitions as TESLA 119 for common terms and assumes that the reader is familiar with the 120 TESLA algorithms and protocols [TESLA]. 122 2. SRTP 124 The Secure Real-time Transport Protocol (SRTP) [RFC3711] is a 125 profile of RTP, which can provide confidentiality, message 126 authentication, and replay protection to the RTP traffic and to the 127 RTP control protocol, the Real-time Transport Control Protocol 128 (RTCP). Note, the term "SRTP" may often be used to indicate SRTCP 129 as well. 131 SRTP is a framework that allows new security functions and new 132 transforms to be added. SRTP currently does not define any 133 mechanism to provide data origin authentication for group security 134 associations. Fortunately, it is straightforward to add TESLA to 135 the SRTP cryptographic framework. 137 The TESLA extension to SRTP is defined in this specification, which 138 assumes that the reader is familiar with the SRTP specification 139 [RFC3711], its packet structure, and processing rules. 141 3. TESLA 143 TESLA provides delayed per-packet data authentication and is 144 specified in [TESLA]. 146 In addition to its SRTP data-packet definition given here, TESLA 147 needs an initial synchronization protocol and initial bootstrapping 148 procedure. The synchronization protocol allows the sender and the 149 receiver to compare their clocks and determine an upper bound of the 150 difference. The synchronization protocol is outside the scope of 151 this document. 153 TESLA also requires an initial bootstrapping procedure to exchange 154 needed parameters and the initial commitment to the key chain 155 [TESLA]. For SRTP, it is assumed that the bootstrapping is 156 performed out-of-band, possibly using the key management protocol 157 that is exchanging the security parameters for SRTP, e.g. [GDOI, 158 RFC3830]. Initial bootstrapping of TESLA is outside the scope of 159 this document. 161 4. Usage of TESLA within SRTP 163 The present specification is an extension to the SRTP specification 164 [RFC3711] and describes the use of TESLA with only a single key 165 chain and delayed-authentication [TESLA]. 167 4.1. The TESLA extension 169 TESLA is an OPTIONAL authentication transform for SRTP. When used, 170 TESLA adds the fields shown in Figure 1 per-packet. The fields 171 added by TESLA are called "TESLA authentication extensions" 172 altogether, whereas "authentication tag" or "integrity protection 173 tag" indicate the normal SRTP integrity protection tag, when the 174 SRTP master key is shared by more than two endpoints [RFC3711]. 176 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 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | i | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 ~ Disclosed Key ~ 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 ~ TESLA MAC ~ 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 Figure 1: The "TESLA authentication extension". 187 i: 32 bit, MANDATORY 188 Identifier of the time interval i, corresponding to the key K_i 189 that is used to calculate the TESLA MAC of the current packet 190 (and other packets sent in the current time interval i). 192 Disclosed Key: variable length, MANDATORY 193 The disclosed key (K_(i-d)), that can be used to authenticate 194 previous packets from earlier time intervals [TESLA]. 196 TESLA MAC (Message Authentication Code): variable length, MANDATORY 197 The MAC computed using the key K'_i (derived from K_i) [TESLA], 198 which is disclosed in a subsequent packet (in the Disclosed Key 199 field). The MAC coverage is defined in Section 4.6. 201 4.2. SRTP Packet Format 203 Figure 2 illustrates the format of the SRTP packet when TESLA is 204 applied. When applied to RTP, the TESLA authentication extension 205 SHALL be inserted before the (optional) SRTP MKI and (recommended) 206 authentication tag (SRTP MAC). 208 0 1 2 3 209 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 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+<+ 211 |V=2|P|X| CC |M| PT | sequence number | | | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 213 | timestamp | | | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 215 | synchronization source (SSRC) identifier | | | 216 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | 217 | contributing source (CSRC) identifiers | | | 218 | .... | | | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 220 | RTP extension (OPTIONAL) | | | 221 +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 222 | | payload ... | | | 223 | | +-------------------------------+ | | 224 | | | RTP padding | RTP pad count | | | 225 +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ | 226 | | i | | | 227 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 228 | ~ Disclosed Key ~ | | 229 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 230 | ~ TESLA MAC ~ | | 231 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<|-+ 232 | ~ MKI ~ | | 233 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 234 | ~ MAC ~ | | 235 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 236 | | | 237 +- Encrypted Portion TESLA Authenticated Portion ---+ | 238 | 239 Authenticated Portion ---+ 241 Figure 2. The format of the SRTP packet when TESLA is applied. Note 242 that it is OPTIONAL to apply TESLA, i.e. the TESLA fields are 243 OPTIONAL. 245 As in SRTP, the "Encrypted Portion" of an SRTP packet consists of 246 the encryption of the RTP payload (including RTP padding when 247 present) of the equivalent RTP packet. 249 The "Authenticated Portion" of an SRTP packet consists of the RTP 250 header, the Encrypted Portion of the SRTP packet, and the TESLA 251 authentication extension. Note that the definition is extended from 252 [RFC3711] by the inclusion of the TESLA authentication extension. 254 The "TESLA Authenticated Portion" of an SRTP packet consists of the 255 RTP header and the Encrypted Portion of the SRTP packet. 257 4.3. Extension of the SRTP Cryptographic Context 259 When TESLA is used, the definition of cryptographic context in 260 Section 3.2 of SRTP SHALL include the following extensions. 262 Transform-independent Parameter 264 a flag indicating the use of TESLA in SRTP. When this bit is set, 265 the following TESLA transform-dependent parameters define the 266 particular TESLA configuration (see [TESLA] for the TESLA- 267 parameter definition). 269 Transform-dependent Parameters 271 1. an identifier for the PRF, f, implementing the one-way function 272 F(x) in TESLA (to derive the keys in the chain), e.g. to 273 indicate HMAC-SHA1, see Section 6.2 for the default value. 275 2. a non-negative integer n_p, determining the length of the F 276 output, i.e. the length of the keys in the chain (that is also 277 the key disclosed in an SRTP packet), see Section 6.2 for the 278 default value. 280 3. an identifier for the PRF, f', implementing the one-way 281 function F'(x) in TESLA (to derive the keys for the TESLA MAC, 282 from the keys in the chain), e.g. to indicate HMAC-SHA1, see 283 Section 6.2 for the default value. 285 4. a non-negative integer n_f, determining the length of the 286 output of F', i.e. of the key for the TESLA MAC, see Section 287 6.2 for the default value. 289 5. an identifier for the TESLA MAC, that accepts the output of 290 F'(x) as its key, e.g. to indicate HMAC-SHA1, see Section 6.2 291 for the default value. 293 6. a non-negative integer n_m, determining the length of the 294 output of the TESLA MAC, see Section 6.2 for the default value. 296 7. the beginning of the session T_0, 298 8. the interval duration T_int (in msec), 300 9. the key disclosure delay d (in number of intervals) 301 10. the upper bound D_t (in sec) on the lag of the receiver clock 302 relative to the sender clock (this quantity has to be 303 calculated by the peers out-of-band) 305 11. non-negative integer n_c, determining the length of the key 306 chain, which is determined based upon the expected duration of 307 the stream. 309 12. the initial key of the chain to which the sender has 310 committed himself. 312 F(x) is used to compute a keychain of keys in SRTP TESLA, as defined 313 in Section 6. Also according to TESLA, F'(x) computes a TESLA MAC 314 key with inputs as defined in Section 6. 316 Section 6 of this document defines the default values for the 317 transform-independent and transform-specific TESLA parameters. 319 4.4. SRTP Processing 321 The SRTP packet processing is described in Section 3.3 of the SRTP 322 specification [RFC3711]. The use of TESLA slightly changes the 323 processing, as the SRTP MAC is checked upon packet arrival for DoS 324 prevention, but the current packet is not TESLA-authenticated. Each 325 packet is buffered until a subsequent packet discloses its TESLA 326 key. The TESLA verification itself consists of some steps, such as 327 tests of TESLA security invariants, that are described in Section 328 3.5-3.7 of [TESLA]. The words "TESLA computation" and "TESLA 329 verification" hereby imply all those steps, which are not all 330 spelled out in the following. In particular, notice that the TESLA 331 verification implies checking the safety condition (Section 3.5 of 332 [TESLA]). 334 As pointed out in [TESLA], if the packet is deemed "unsafe", then 335 the receiver considers the packet unauthenticated. It should discard 336 unsafe packets but, at its own risk, it may choose to use them 337 unverified. Hence, if the safe condition does not hold, it is 338 RECOMMENDED to discard the packet and log the event. 340 4.4.1 Sender Processing 342 The sender processing is as described in Section 3.3 of [RFC3711], 343 up to step 5 included. After that the following process is 344 followed: 346 6. When TESLA is applied, identify the key in the TESLA chain to be 347 used in the current time interval, and the TESLA MAC key derived 348 from it. Execute the TESLA computation to obtain the TESLA 349 authentication extension for the current packet, by appending the 350 current interval identifier (as i field), the disclosed key of the 351 chain for an earlier interval, and the TESLA MAC under the current 352 key from the chain. This step uses the related TESLA parameters from 353 the crypto context as for Step 4. 355 7. If the MKI indicator in the SRTP crypto context is set to one, 356 append the MKI to the packet. 358 8. When TESLA is applied, and if the SRTP authentication (external 359 tag) is required (for DoS), compute the authentication tag as 360 described in step 7 of Section 3.3 of the SRTP specification, but 361 with coverage as defined in this specification (see Section 4.6). 363 9. If necessary, update the ROC (step 8 in Section 3.3 of 364 [RFC3711]). 366 4.4.2 Receiver Processing 368 The receiver processing is as described in Section 3.3 of [RFC3711], 369 up to step 4 included. 371 To authenticate and replay-protect the current packet, the 372 processing is the following: 374 First check if the packet has been replayed (as for Section 3.3 of 375 [RFC3711]). Note however, the SRTP replay list contains SRTP 376 indices of recently received packets that have been authenticated 377 by TESLA (i.e. replay list updates MUST NOT be based on SRTP MAC). 378 If the packet is judged to be replayed, then the packet MUST be 379 discarded, and the event SHOULD be logged. 381 Next, perform verification of the SRTP integrity protection tag 382 (note, not the TESLA MAC), if present, using the rollover counter 383 from the current packet, the authentication algorithm indicated in 384 the cryptographic context, and the session authentication key. If 385 the verification is unsuccessful, the packet MUST be discarded 386 from further processing and the event SHOULD be logged. 388 If the verification is successful, remove and store the MKI (if 389 present) and authentication tag fields from the packet. The packet 390 is buffered, awaiting disclosure of the TESLA key in a subsequent 391 packet. 393 TESLA authentication is performed on a packet when the key is 394 disclosed in a subsequent packet. When such key is disclosed, 395 perform the TESLA verification of the packet using the rollover 396 counter from the packet, the TESLA security parameters from the 397 cryptographic context, and the disclosed key. If the verification 398 is unsuccessful, the packet MUST be discarded from further 399 processing and the event SHOULD be logged. If the TESLA 400 verification is successful, remove the TESLA authentication 401 extension from the packet. 403 To decrypt the current packet, the processing is the following: 405 Decrypt the Encrypted Portion of the packet, using the decryption 406 algorithm indicated in the cryptographic context, the session 407 encryption key and salt (if used) found in Step 4 with the index 408 from Step 2. 410 (Note that the order of decryption and TESLA verification is not 411 mandated. It is RECOMMENDED to perform the TESLA verification 412 before decryption. TESLA application designers might choose to 413 implement optimistic processing techniques such as notification of 414 TESLA verification results after decryption or even after plaintext 415 processing. Optimistic verification is beyond the scope of this 416 document.) 418 Update the rollover counter and highest sequence number, s_l, in the 419 cryptographic context, using the packet index estimated in Step 2. 420 If replay protection is provided, also update the Replay List (i.e., 421 the Replay List is updated after the TESLA authentication is 422 successfully verified). 424 4.5. SRTCP Packet Format 426 Figure 3 illustrates the format of the SRTCP packet when TESLA is 427 applied. The TESLA authentication extension SHALL be inserted 428 before the MKI and authentication tag. Recall from [RFC3711] that 429 in SRTCP the MKI is OPTIONAL, while the E-bit, the SRTCP index, and 430 the authentication tag are MANDATORY. This means that the SRTP 431 (external) MAC is MANDATORY also when TESLA is used. 433 As in SRTP, the "Encrypted Portion" of an SRTCP packet consists of 434 the encryption of the RTCP payload of the equivalent compound RTCP 435 packet, from the first RTCP packet, i.e., from the ninth (9) octet 436 to the end of the compound packet. 438 The "Authenticated Portion" of an SRTCP packet consists of the 439 entire equivalent (eventually compound) RTCP packet, the E flag, the 440 SRTCP index (after any encryption has been applied to the payload), 441 and the TESLA extension. Note that the definition is extended from 442 [RFC3711] by the inclusion of the TESLA authentication extension. 444 We define the "TESLA Authenticated Portion" of an SRTCP packet as 445 consisting of the RTCP header (first 8 bytes) and the Encrypted 446 Portion of the SRTCP packet. 448 Processing of an SRTCP packets is similar to the SRTP processing 449 (Section 4.3), but there are SRTCP-specific changes described in 450 Section 3.4 of the SRTP specification [RFC3711] and in Section 4.6 451 of this memo. 453 0 1 2 3 454 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 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+<+ 456 |V=2|P| RC | PT=SR or RR | length | | | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 458 | SSRC of sender | | | 459 +>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | 460 | ~ sender info ~ | | 461 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 462 | ~ report block 1 ~ | | 463 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 464 | ~ report block 2 ~ | | 465 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 466 | ~ ... ~ | | 467 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 468 | |V=2|P| SC | PT=SDES=202 | length | | | 469 | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | 470 | | SSRC/CSRC_1 | | | 471 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 472 | ~ SDES items ~ | | 473 | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | 474 | ~ ... ~ | | 475 +>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | 476 | |E| SRTCP index | | | 477 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ | 478 | | i | | | 479 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 480 | ~ Disclosed Key ~ | | 481 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 482 | ~ TESLA MAC ~ | | 483 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<|-+ 484 | ~ SRTCP MKI ~ | | 485 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 486 | : authentication tag : | | 487 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 488 | | | 489 +-- Encrypted Portion TESLA Authenticated Portion -----+ | 490 | 491 Authenticated Portion -------+ 493 Figure 3. The format of the SRTCP packet when TESLA is applied. 494 Note that it is OPTIONAL to apply TESLA, i.e. the TESLA fields are 495 OPTIONAL. 497 4.6. TESLA MAC 499 Let M' denote packet data to be TESLA-authenticated. In the case of 500 SRTP, M' SHALL consist of the SRTP TESLA Authenticated Portion (RTP 501 header and SRTP Encrypted Portion, see Figure 2) of the packet 502 concatenated with the ROC of the same packet: 504 M' = ROC || TESLA Authenticated Portion. 506 In the case of SRTCP, M' SHALL consist of the SRTCP TESLA 507 Authenticated Portion only (RTCP header and SRTCP Encrypted 508 Portion). 510 The normal authentication tag (OPTIONAL for SRTP, MANDATORY for 511 SRTCP) SHALL be applied with the same coverage as specified in 512 [RFC3711], i.e.: 514 - for SRTP: Authenticated Portion || ROC (with the extended 515 definition of SRTP Authentication Portion as for Section 4.2) 517 - for SRTCP: Authenticated Portion (with the extended definition of 518 SRTCP Authentication Portion as for Section 4.2). 520 The pre-defined authentication transform in SRTP, HMAC-SHA1 521 [RFC2104], is also used to generate the TESLA MAC. For SRTP 522 (respectively SRTCP), the HMAC SHALL be applied to the key in the 523 TESLA chain corresponding to a particular time interval, and M' as 524 specified above. The HMAC output SHALL then be truncated to the n_m 525 left-most bits. Default values are in Section 6.2. 527 4.7. PRFs 529 TESLA requires two pseudo-random functions (PRFs), f and f', to 530 implement 532 * one one-way function F(x) to derive the key chain, and 533 * one one-way function F'(x) to derive (from each key of the chain) 534 the key that is actually used to calculate the TESLA MAC. 536 When TESLA is used within SRTP, the default choice of the two PRFs 537 SHALL be HMAC-SHA1. Default values are in Section 6.2. 539 Other PRFs can be chosen, and their use SHALL follow the common 540 guidelines in [RFC3711] when adding new security parameters. 542 5. TESLA Bootstrapping and Cleanup 544 The extensions to the SRTP cryptographic context include a set of 545 TESLA parameters that are listed in section 4.3 of this document. 546 Furthermore, TESLA MUST be bootstrapped at session set-up (for the 547 parameter exchange and the initial key commitment) through a regular 548 data authentication system (a digital signature algorithm is 549 RECOMMENDED). Key management procedures can take care of this 550 bootstrapping prior to the commencement of an SRTP session where 551 TESLA authentication is used. The bootstrapping mechanism is out of 552 scope for this document (it could for example be part of the key 553 management protocol). 555 A critical factor for the security of TESLA is that the sender and 556 receiver need to be loosely synchronized. TESLA requires a bound on 557 clock drift to be known (D_t). Use of TESLA in SRTP assumes that 558 the time synchronization is guaranteed by out-of-band schemes (e.g. 559 key management), i.e. it is not in the scope of SRTP. 561 It also should be noted that TESLA has some reliability requirements 562 in that a key is disclosed for a packet in a subsequent packet, 563 which can get lost. Since a key in a lost packet can be derived from 564 a future packet, TESLA is robust to packet loss. This repetition 565 might abruptly stop, however, if the key-bearing packets stop 566 abruptly at the end of the stream. To avoid this nasty boundary 567 condition, send null packets with TESLA keys for one entire interval 568 following the interval in which the stream ceases. 570 6. SRTP TESLA Default parameters 572 Key management procedures establish SRTP TESLA operating parameters, 573 which are listed in section 4.3 of this document. The operating 574 parameters appear in the SRTP cryptographic context and have the 575 default values that are described in this section. In the future, 576 an Internet RFC MAY define alternative settings for SRTP TESLA that 577 are different than those specified here. In particular, it should 578 be noted that the settings defined in this memo can have a large 579 impact on bandwidth, as it adds 38 bytes to each packet (when the 580 field length values are the default ones). For certain 581 applications, this overhead may represent more than a 50% increase 582 in packet size. Alternative settings might seek to reduce the 583 number and length of various TESLA fields and outputs. No such 584 optimizations are considered in this memo. 586 It is RECOMMENDED that the SRTP MAC be truncated to 32 bits since the 587 SRTP MAC provides only group authentication and serves only as 588 protection against external DoS. 590 6.1 Transform-independent Parameters 592 The value of the flag indicating the use of TESLA in SRTP is by 593 default zero (TESLA not used). 595 6.2 Transform-dependent Parameters for TESLA MAC 597 The default values for the security parameters are listed in the 598 following. "OWF" denotes a one-way function. 600 Parameter Mandatory-to-support Default 601 --------- -------------------- ------- 602 TESLA KEYCHAIN OWF (F(x)) HMAC-SHA1 HMAC-SHA1 603 OUTPUT LENGTH 160 160 605 TESLA MAC KEY OWF (F'(F(x))) HMAC-SHA1 HMAC-SHA1 606 OUTPUT LENGTH n_f 160 160 608 TESLA MAC HMAC-SHA1 HMAC-SHA1 609 (TRUNCATED) OUTPUT LENGTH n_m 80 80 611 As shown above, TESLA implementations MUST support HMAC-SHA1 for the 612 TESLA MAC, the MAC key generator, and the TESLA keychain generator 613 one-way function. The TESLA keychain generator is recursively 614 defined as follows [TESLA]. 616 K_i=HMAC_SHA1(K_{i+1},0), i=0..N-1 618 where N-1=n_c from the cryptographic context. 620 The TESLA MAC key generator is defined as follows [TESLA]. 622 K'_i=HMAC_SHA1(K_i,1) 624 The TESLA MAC uses a truncated output of ten bytes [RFC2104] and is 625 defined as follows. 627 HMAC_SHA1(K'_i, M') 629 where M' is as specified in Section 4.6. 631 7. Security Considerations 633 Denial of Service (DoS) attacks on delayed authentication are 634 discussed in [PCST]. TESLA requires receiver buffering before 635 authentication, therefore the receiver can suffer a denial of 636 service attack due to a flood of bogus packets. To address this 637 problem, the external SRTP MAC, based on the group key, MAY be used 638 in addition to the TESLA MAC. The short size of the SRTP MAC 639 (default 32 bits) is here motivated by the fact that that MAC served 640 purely for DoS prevention from attackers external to the group. 641 [TESLA] describes other mechanisms that can be used to prevent DoS, 642 in alternative to the external group-key MAC. Where these are used, 643 they need to be add as processing steps (following the guidelines of 644 [TESLA]). 646 The use of TESLA in SRTP defined in this specification is subject to 647 the security considerations discussed in the SRTP specification 648 [RFC3711] and in the TESLA specification [TESLA]. In particular, the 649 TESLA security is dependent on the computation of the "safety 650 condition" as defined in Section 3.5 of [TESLA]. 652 SRTP TESLA depends on the effective security of the systems that 653 perform bootstrapping (time synchronization) and key management. 654 These systems are external to SRTP and are not considered in this 655 specification. 657 8. IANA Considerations 659 No IANA registration is required. 661 9. Acknowledgements 663 The authors would like to thanks Ran Canetti, Karl Norrman, Mats 664 N„slund, Fredrik Lindholm, David McGrew, and Bob Briscoe for their 665 valuable help. 667 10. Author's Addresses 669 Questions and comments should be directed to the authors and 670 msec@ietf.org: 672 Mark Baugher 673 Cisco Systems, Inc. 674 5510 SW Orchid Street Phone: +1 408-853-4418 675 Portland, OR 97219 USA Email: mbaugher@cisco.com 677 Elisabetta Carrara 678 Ericsson Research 679 SE-16480 Stockholm Phone: +46 8 50877040 680 Sweden EMail: elisabetta.carrara@ericsson.com 682 11. References 684 Normative 686 [PCST] Perrig, A., Canetti, R., Song, D., Tygar, D., "Efficient and 687 Secure Source Authentication for Multicast", in Proc. of Network and 688 Distributed System Security Symposium NDSS 2001, pp. 35-46, 2001. 690 [RFC1305] Mills D., Network Time Protocol (Version 3) Specification, 691 Implementation and Analysis, RFC 1305, March, 1992. 693 [RFC3711] Baugher, McGrew, Naslund, Carrara, Norrman, "The Secure 694 Real-time Transport Protocol", RFC 3711, March 2004. 696 [TESLA] Perrig, Canetti, Song, Tygar, Briscoe, "TESLA: Multicast 697 Source Authentication Transform Introduction", December 2004, draft- 698 ietf-msec-tesla-intro-04.txt. 700 Informative 702 [gkmarch] Baugher, Canetti, Dondeti, Lindholm, "MSEC Group Key 703 Management Architecture", June 2004, . 706 [GDOI] Baugher, Weis, Hardjono, Harney, "The Group Domain of 707 Interpretation", RFC 3547, July 2003. 709 [RFC3830] Arkko et al., "MIKEY: Multimedia Internet KEYing", 710 December 2003, RFC 3830, August 2004. 712 Copyright Notice 714 Copyright (C) The Internet Society (2004). This document is subject 715 to the rights, licenses and restrictions contained in BCP 78, and 716 except as set forth therein, the authors retain all their rights. 718 Disclaimer of Validity 719 This document and the information contained herein are provided on 720 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 721 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 722 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 723 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 724 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 725 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 727 This draft expires in August 2005.