idnits 2.17.00 (12 Aug 2021) /tmp/idnits14637/draft-ietf-msec-srtp-tesla-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 203: '... SHALL be inserted before the (optio...' RFC 2119 keyword, line 253: '... that it is OPTIONAL to apply TESLA,...' RFC 2119 keyword, line 254: '... OPTIONAL....' RFC 2119 keyword, line 259: '...tion 3.2 of SRTP SHALL include the fol...' (22 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 71 has weird spacing: '...n order to gu...' -- 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 2004) is 6669 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 113, but not defined == Missing Reference: 'RFC2104' is mentioned on line 583, but not defined == Unused Reference: 'GDOI' is defined on line 660, but no explicit reference was found in the text == Unused Reference: 'MESP' is defined on line 663, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'PCST' -- Possible downref: Non-RFC (?) normative reference: ref. 'SRTP' == 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. 'TESLA1') -- Obsolete informational reference (is this intentional?): RFC 3547 (ref. 'GDOI') (Obsoleted by RFC 6407) Summary: 4 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 2004 February 2004 7 The Use of TESLA in SRTP 8 10 Status of this memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 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..................6 48 4.4. SRTP Processing..............................................7 49 4.4.1 Sender Processing...........................................8 50 4.4.2 Receiver Processing.........................................8 51 4.5. SRTCP Packet Format..........................................9 52 4.6. TESLA MAC...................................................11 53 4.7. PRFs........................................................11 54 5. TESLA Bootstrapping...........................................12 55 6. SRTP TESLA Default parameters.................................12 56 6.1 Transform-independent Parameter: SRTP MAC with TESLA MAC.....13 57 6.2 Transform-dependent Parameters for TESLA MAC.................13 58 7. Security Considerations.......................................14 59 8. IANA Considerations...........................................14 60 9. Acknowledgements..............................................14 61 10. Author's Addresses...........................................15 62 11. References...................................................15 63 Intellectual Property Right Considerations.......................16 64 Full Copyright Statement.........................................16 66 1. Introduction 68 Multicast and broadcast communication introduce some new security 69 challenges compared to unicast communication. Many multicast and 70 broadcast applications need "data origin authentication" (DOA), or 71 "source authentication", in order to guarantee that a received 72 message originated from a given source, and was not manipulated 73 during the transmission. In unicast communication, a pairwise 74 security association between one sender and one receiver can provide 75 data origin authentication using symmetric-key cryptography (such as 76 a message authentication code, MAC). When the communication is 77 strictly pairwise, the sender and receiver agree upon a key that is 78 known only to them. 80 In groups, however, a key is shared among more than two members, and 81 this symmetric-key approach does not guarantee data origin 82 authentication. When there is a group security association 83 [gkmarch] instead of a pairwise security association, any of the 84 members can alter the packet and impersonate any other member. The 85 MAC in this case only guarantees that the packet was not manipulated 86 by an attacker outside the group (and hence not in possession of the 87 group key), and that the packet was sent by a source within the 88 group. 90 Some applications cannot tolerate source ambiguity and must discern 91 the true sender from any other group member. A common way to solve 92 the problem is by use of asymmetric cryptography, such as digital 93 signatures. This method, unfortunately, suffers from high overhead, 94 in terms of time (to sign and verify) and bandwidth (to convey the 95 signature in the packet). 97 Several schemes have been proposed to provide efficient data origin 98 authentication in multicast and broadcast scenarios. The Timed 99 Efficient Stream loss-tolerant Authentication (TESLA), is one such 100 scheme. 102 This memo specifies TESLA authentication for SRTP. SRTP TESLA can 103 provide data origin authentication to RTP applications that use 104 group security associations (such as multicast RTP applications) so 105 long as receivers abide by the TESLA security invariants [TESLA1, 106 TESLA2]. 108 1.1. Notational Conventions 110 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in [RFC2119]. 114 This specification assumes the reader familiar with both SRTP and 115 TESLA. Almost none of their details will be explained, and the 116 reader can find them in their respective specifications [SRTP, 117 TESLA1, TESLA2]. Also, this specification uses the same definitions 118 as TESLA for common terms. 120 2. SRTP 122 The Secure Real-time Transport Protocol (SRTP) [SRTP] is a profile 123 of RTP, which can provide confidentiality, message authentication, 124 and replay protection to the RTP traffic and to the RTP control 125 protocol, the Real-time Transport Control Protocol (RTCP). 127 SRTP is a framework that allows new security functions and new 128 transforms to be added. SRTP currently does not define any 129 mechanism to provide data origin authentication for group security 130 associations. Fortunately, it is straightforward to add TESLA to 131 the SRTP cryptographic framework. 133 The TESLA extension to SRTP is defined in this specification, which 134 assumes that the reader is familiar with the SRTP specification 135 [SRTP], its packet structure, and processing rules. 137 3. TESLA 139 TESLA provides delayed per-packet data authentication and is 140 specified in two documents, an introductory overview [TESLA1] and a 141 second specification that defines signaling and data packet 142 parameters [TESLA2]. This specification assumes that the reader is 143 familiar with these two documents. 145 In addition to its SRTP data-packet definition given here, TESLA 146 needs an initial synchronization protocol and initial bootstrapping 147 procedure. The synchronization protocol allows the sender and the 148 receiver to compare their clocks and determine an upper bound of the 149 difference. The synchronization protocol is outside the scope of 150 this document. 152 TESLA also requires an initial bootstrapping procedure to exchange 153 needed parameters and the initial commitment to the key chain 154 [TESLA2]. For SRTP, it is assumed that the bootstrapping is 155 performed out-of-band, possibly using the key management protocol 156 that is exchanging the security parameters for SRTP, e.g. [GDOI, 157 MIKEY]. Initial bootstrapping of TESLA is outside the scope of this 158 document. 160 4. Usage of TESLA within SRTP 162 The present specification is an extension to the SRTP specification 163 [SRTP] and describes the use of TESLA with only a single key chain, 164 and the delayed-authentication TESLA elements of procedure [TESLA1, 165 TESLA2]. 167 4.1. The TESLA extension 169 TESLA is an OPTIONAL authentication algorithm for SRTP. When used, 170 TESLA adds the fields showed 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 integrity protection tag when the SRTP 174 master key is shared by more than two endpoints [SRTP]. 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 | Id | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 ~ Disclosed Key ~ 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 ~ TESLA MAC ~ 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 Figure 1: The "TESLA authentication extension". 187 Id: identifier of K_i, MANDATORY 188 The identifier of the key that was used to calculate the MAC 189 present in the packet during interval i. 191 Disclosed Key: variable length, MANDATORY 192 The disclosed key, that can be used to authenticate previous 193 packets from earlier time intervals, i.e. K_{i-d}. 195 TESLA MAC (Message Authentication Code): variable length, MANDATORY 196 The MAC computed using K'_i, which is disclosed in a subsequent 197 packet. The MAC coverage is defined in Section 4.6. 199 4.2. SRTP Packet Format 201 Figure 2 illustrates the format of the SRTP packet when TESLA is 202 applied. When applied to RTP, the TESLA authentication extension 203 SHALL be inserted before the (optional) SRTP MKI and (recommended) 204 authentication tag. 206 As in SRTP, the "Encrypted Portion" of an SRTP packet consists of 207 the encryption of the RTP payload (including RTP padding when 208 present) of the equivalent RTP packet. 210 The "Authenticated Portion" of an SRTP packet consists of the RTP 211 header, the Encrypted Portion of the SRTP packet, and the TESLA 212 authentication extension. Note that the definition is extended from 213 [SRTP] by the inclusion of the TESLA authentication extension. 215 The "TESLA Authenticated Portion" of an SRTP packet consists of the 216 RTP header, the Encrypted Portion of the SRTP packet, the TESLA Id 217 field, and the TESLA disclosed key. 219 0 1 2 3 220 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 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+<+ 222 |V=2|P|X| CC |M| PT | sequence number | | | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 224 | timestamp | | | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 226 | synchronization source (SSRC) identifier | | | 227 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | 228 | contributing source (CSRC) identifiers | | | 229 | .... | | | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 231 | RTP extension (OPTIONAL) | | | 232 +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 233 | | payload ... | | | 234 | | +-------------------------------+ | | 235 | | | RTP padding | RTP pad count | | | 236 +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 237 | | Id | | | 238 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 239 | ~ Disclosed Key ~ | | 240 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ | 241 | ~ TESLA MAC ~ | | 242 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<|-+ 243 | ~ MKI ~ | | | 244 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 245 | ~ MAC ~ | | 246 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 247 | | | 248 +- Encrypted Portion TESLA Authenticated Portion ---+ | 249 | 250 Authenticated Portion ---+ 252 Figure 2. The format of the SRTP packet when TESLA is applied. Note 253 that it is OPTIONAL to apply TESLA, i.e. the TESLA fields are 254 OPTIONAL. 256 4.3. Extension of the SRTP Cryptographic Context 258 When TESLA is used, the definition of cryptographic context in 259 Section 3.2 of SRTP SHALL include the following extensions: 261 1. an identifier for the PRF, f, implementing the one-way function 262 F(x) in TESLA (to derive the keys in the chain), e.g. HMAC- 263 SHA1, 265 2. a non-negative integer n_c, determining the length of the F 266 output, i.e. the length of the keys in the chain (that is also 267 the key disclosed in an SRTP packet), 269 3. an identifier for the PRF, f', implementing the one-way 270 function F'(x) in TESLA (to derive the keys for the TESLA MAC, 271 from the keys in the chain), e.g. HMAC-SHA1, 273 4. a non-negative integer n_f, determining the length of the 274 output of F', i.e. of the key for the TESLA MAC, 276 5. an identifier for the TESLA MAC, that accepts the output of 277 F'(x) as its key, 279 6. a non-negative integer n_m, determining the length of the 280 output of the TESLA MAC, 282 7. the identifier id_j of a specific time interval I_j, 284 8. an NTP timestamp TI_j describing the beginning of I_j, 286 9. an NTP timestamp T_int describing the interval duration, 288 10. the key-disclosure interval, d, 290 11. the id_n of the final key in the keychain, K_n, 292 12. the interval d_n of the last key chain element. 294 F(x) is used to compute a keychain of keys in SRTP TESLA, as defined 295 in Section 6. Also according to TESLA, F'(x) computes a TESLA MAC 296 key with inputs as defined in Section 6. 298 Note that the replay list is now containing indices of recently 299 received packets that have been authenticated by TESLA. I.e. replay 300 list updates MUST NOT be based on SRTP MAC. 302 These parameters are all "transform-specific" parameters. There is 303 one transform-independent parameter that declares that SRTP message 304 authentication is extended with TESLA DOA authentication. Section 6 305 of this document defines the default values for the transform- 306 independent and transform-specific TESLA parameters. 308 4.4. SRTP Processing 310 The SRTP packet processing is described in Section 3.3 of the SRTP 311 specification [SRTP]. The use of TESLA slightly changes the 312 processing, as the SRTP MAC is checked upon packet arrival for DoS 313 prevention, but the current packet is not TESLA-authenticated. Each 314 packet is buffered until a subsequent packet discloses its TESLA 315 key. The TESLA verification itself consists of some steps, such as 316 tests of TESLA security invariants, that are described in Section 4 317 of [TESLA1]. The words "TESLA computation" and "TESLA verification" 318 hereby imply all those steps, which are not all spelled out in the 319 following. 321 4.4.1 Sender Processing 323 The sender processing is as described in Section 3.3 of [SRTP], up 324 to step 5 included. After that the following process is followed: 326 6. When TESLA is applied, identify the key in the TESLA chain to be 327 used in the current time interval, and the TESLA MAC key derived 328 from it. Execute the TESLA computation to obtain the TESLA 329 authentication extension for the current packet, by appending the 330 key Id, the disclosed key of the chain for an earlier packet, and 331 the TESLA MAC under the current key from the chain. This step uses 332 the related TESLA parameters from the crypto context as for Step 4. 334 7. If the MKI indicator is set to one, append the MKI to the packet. 336 8. When TESLA is applied, compute the authentication tag as 337 described in step 7 of Section 3.3 of the SRTP specification, but 338 with coverage as defined in this specification (see Section 4.6). 340 9. If necessary, update the ROC (step 9 in Section 3.3 of [SRTP]). 342 4.4.2 Receiver Processing 344 The receiver processing is as described in Section 3.3 of [SRTP], up 345 to step 4 included. 347 To authenticate and replay-protect the current packet, the 348 processing is the following: 350 First check if the packet has been replayed (as for Section 3.3 of 351 [SRTP]). If the packet is judged to be replayed, then the packet 352 MUST be discarded, and the event SHOULD be logged. 354 Next, perform verification of the SRTP integrity protection tag 355 (note, not the TESLA MAC), if present, using the rollover counter 356 from the current packet, the authentication algorithm indicated in 357 the cryptographic context, and the session authentication key. If 358 the verification is unsuccessful, the packet MUST be discarded 359 from further processing and the event SHOULD be logged. 361 If the verification is successful, remove the MKI (if present) and 362 authentication tag fields from the packet. The packet is buffered, 363 awaiting disclosure of the TESLA key in a subsequent packet. 365 TESLA authentication is performed on a packet when the key is 366 disclosed in a subsequent packet. When such key is disclosed, 367 perform the TESLA verification of the packet using the rollover 368 counter from the packet, the TESLA security parameters from the 369 cryptographic context, and the disclosed key. If the verification 370 is unsuccessful, the packet MUST be discarded from further 371 processing and the event SHOULD be logged. If the TESLA 372 verification is successful, remove the TESLA authentication 373 extension from the packet. 375 To decrypt the current packet, the processing is the following: 377 Decrypt the Encrypted Portion of the packet, using the decryption 378 algorithm indicated in the cryptographic context, the session 379 encryption key and salt (if used) found in Step 4 with the index 380 from Step 2. 382 Update the rollover counter and highest sequence number, s_l, in the 383 cryptographic context, using the packet index estimated in Step 2. 384 If replay protection is provided, also update the Replay List (i.e., 385 the Replay List is updated after the TESLA authentication is 386 successfully verified). 388 4.5. SRTCP Packet Format 390 Figure 3 illustrates the format of the SRTCP packet when TESLA is 391 applied. The TESLA authentication extension SHALL be inserted 392 before the MKI and authentication tag. Recall from [SRTP] that in 393 SRTCP the MKI is OPTIONAL, while the E-bit, the SRTCP index, and the 394 authentication tag are MANDATORY. 396 0 1 2 3 397 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 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+<+ 399 |V=2|P| RC | PT=SR or RR | length | | | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 401 | SSRC of sender | | | 402 +>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | 403 | ~ sender info ~ | | 404 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 405 | ~ report block 1 ~ | | 406 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 407 | ~ report block 2 ~ | | 408 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 409 | ~ ... ~ | | 410 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 411 | |V=2|P| SC | PT=SDES=202 | length | | | 412 | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | 413 | | SSRC/CSRC_1 | | | 414 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 415 | ~ SDES items ~ | | 416 | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | 417 | ~ ... ~ | | 418 +>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | 419 | |E| SRTCP index | | | 420 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 421 | | Id (OPTIONAL) | | | 422 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 423 | ~ Disclosed Key ~ | | 424 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ | 425 | ~ TESLA MAC ~ | | 426 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<|-+ 427 | ~ SRTCP MKI ~ | | 428 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 429 | : authentication tag : | | 430 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 431 | | | 432 +-- Encrypted Portion TESLA Authenticated Portion -----+ | 433 | 434 Authenticated Portion -------+ 436 Figure 3. The format of the SRTCP packet when TESLA is applied. 437 Note that it is OPTIONAL to apply TESLA, i.e. the TESLA fields are 438 OPTIONAL. 440 As in SRTP, the "Encrypted Portion" of an SRTCP packet consists of 441 the encryption of the RTCP payload of the equivalent compound RTCP 442 packet, from the first RTCP packet, i.e., from the ninth (9) octet 443 to the end of the compound packet. 445 The "Authenticated Portion" of an SRTCP packet consists of the 446 entire equivalent (eventually compound) RTCP packet, the E flag, the 447 SRTCP index (after any encryption has been applied to the payload), 448 and the TESLA extension. Note that the definition is extended from 449 [SRTP] by the inclusion of the TESLA authentication extension. 451 We define the "TESLA Authenticated Portion" of an SRTCP packet as 452 consisting of the RTCP header (first 8 bytes), the Encrypted Portion 453 of the SRTCP packet, the Id field, and the TESLA disclosed key. 455 Processing of an SRTCP packets is similar to the SRTP processing 456 (Section 4.3), but there are SRTCP-specific changes described in 457 Section 3.4 of the SRTP specification [SRTP] and in Section 4.6 of 458 this memo. 460 4.6. TESLA MAC 462 Let M' denote packet data to be TESLA-authenticated. In the case of 463 SRTP, M' SHALL consist of the SRTP TESLA Authenticated Portion (RTP 464 header, SRTP Encrypted Portion, TESLA Id, and disclosed key) of the 465 packet concatenated with the ROC of the same packet: 467 M' = ROC || TESLA Authenticated Portion. 469 In the case of SRTCP, M' SHALL consist of the SRTCP TESLA 470 Authenticated Portion only (RTCP header, SRTCP Encrypted Portion, 471 TESLA Id, and disclosed key). 473 The normal authentication tag SHALL be applied with the same 474 coverage as specified in [SRTP], i.e. Authenticated Portion || ROC 475 for SRTP, and Authenticated Portion for SRTCP. 477 The pre-defined authentication transform in SRTP, HMAC-SHA1 478 [RFC2104], is also used to generate the TESLA MAC. For SRTP 479 (respectively SRTCP), the HMAC SHALL be applied to the key in the 480 TESLA chain corresponding to a particular time interval, and M' as 481 specified above. The HMAC output SHALL then be truncated to the n_m 482 left-most bits. Default values are in Section 6.2. 484 4.7. PRFs 486 TESLA requires two pseudo-random functions (PRFs), f and f', to 487 implement 488 * one one-way function F(x) to derive the key chain, and 489 * one one-way function F'(x) to derive (from each key of the chain) 490 the key that is actually used to calculate the TESLA MAC. 492 When TESLA is used within SRTP, the default choice of the two PRFs 493 SHALL be HMAC-SHA1. Default values are in Section 6.2. 495 Other PRFs can be chosen, and their use SHALL follow the common 496 guidelines in [SRTP] when adding new security parameter. 498 5. TESLA Bootstrapping 500 The extensions to the SRTP cryptographic context include a set of 501 TESLA parameters that are listed in section 4.3 of this document. 502 Key management procedures establish these parameters prior to the 503 commencement of an SRTP session where TESLA authentication is used. 505 A critical factor for the security of TESLA is that the sender and 506 receiver need to be loosely synchronized. TESLA assumes that the 507 local internal clocks do not drift too much during the session. Use 508 of TESLA in SRTP assumes that the time synchronization is guaranteed 509 by out-of-band schemes, i.e. it is not in the scope of SRTP. The 510 TESLA overview specification [TESLA2] describes some methods, which 511 might be accomplished as part of SRTP key management. At least one 512 SRTP key management protocol, MIKEY, requires time synchronization 513 [MIKEY]. 515 6. SRTP TESLA Default parameters 517 Key management procedures establish SRTP TESLA operating parameters 518 listed in section 4.3 of this document. The operating parameters 519 appear in the SRTP cryptographic context and have the following 520 default values. In the future, an Internet RFC MAY define 521 alternative settings for SRTP TESLA that are different than those 522 specified here. In particular, it should be noted that the settings 523 defined in this memo can have a large impact on bandwidth, as it 524 adds 38 bytes to each packet (when the field length values are the 525 default ones) . For certain applications, this overhead may 526 represent more than a 50% increase in packet size. Alternative 527 settings might seek to reduce the number and length of various TESLA 528 fields and outputs. No such optimizations are considered in this 529 memo. 531 6.1 Transform-independent Parameter: SRTP MAC with TESLA MAC 533 Section 3.2.1 of the SRTP specification identifies "message 534 authentication" as one of the transform-independent parameters. By 535 default, this is HMAC-SHA1 for SRTP. With the addition of TESLA, 536 SRTP message authentication becomes a compound parameter since it is 537 necessary to identify two message authentication algorithms, one for 538 the SRTP MAC and one for the TESLA MAC. Thus, the use or non-use of 539 TESLA SHALL be indicated by the presence of a TESLA bit in the SRTP 540 cryptographic context. When this bit is set, the SRTP 541 implementation MUST inspect the TESLA transform-dependent parameters 542 to determine the particular TESLA configuration. 544 It is RECOMMENDED that the SRTP MAC be truncated to four bytes since 545 the SRTP MAC provides only group authentication and serves only as 546 protection against DoS. 548 6.2 Transform-dependent Parameters for TESLA MAC 550 The default values for the security parameters are listed in the 551 following. "OWF" denotes a one-way function. 553 Parameter Mandatory-to-support Default 554 --------- -------------------- ------- 555 TESLA KEYCHAIN OWF (F(x)) HMAC-SHA1 HMAC-SHA1 556 OUTPUT LENGTH 160 160 558 TESLA MAC KEY OWF (F'(F(x))) HMAC-SHA1 HMAC-SHA1 559 OUTPUT LENGTH n_f 160 160 561 TESLA MAC HMAC-SHA1 HMAC-SHA1 562 (TRUNCATED) OUTPUT LENGTH n_m 80 80 564 id_j 566 TI_j 567 T_int 569 id_n 570 d_n 572 As shown above, TESLA implementations MUST support HMAC-SHA1 for the 573 TESLA MAC, the MAC key generator, and the TESLA keychain generator 574 one-way function. The TESLA keychain generator is recursively 575 defined as follows. 577 K_i=HMAC_SHA1(K_{i+1},0), i=0..N-1 579 The TESLA MAC key generator is defined as follows. 581 K'_i=HMAC_SHA1(K_i,1) 583 The TESLA MAC uses a truncated output of ten bytes [RFC2104] and is 584 defined as follows. 586 HMAC_SHA1(K'_i, M') 588 where M' is as specified in Section 4.6. 590 The TESLA interval parameters are id_j and id_n, both are 32 bits in 591 length. The times associated with the intervals are TI_j, T_int, 592 and d_n, which are 64-bit values in Network Time Protocol (NTP) 593 format. 595 7. Security Considerations 597 Denial of Service (DoS) attacks when delayed authentication is used 598 are discussed in [PCST]. TESLA requires receiver's buffering before 599 authentication, therefore the receiver can suffer a denial of 600 service attack due to a flood of bogus packets. To address this 601 problem, the current specification REQUIRES the use of a four-byte 602 SRTP MAC in addition to TESLA MAC. The shorter size of the SRTP MAC 603 is here motivated by the fact that that MAC served purely for DoS 604 prevention from attackers external to the group. 606 SRTP TESLA depends on the effective security of the systems that 607 perform bootstrapping (time synchronization) and key management. 608 These systems are external to SRTP and are not considered in this 609 specification. 611 8. IANA Considerations 613 No IANA registration is required. 615 9. Acknowledgements 617 The authors would like to thanks Karl Norrman, Mats Näslund, and Ran 618 Canetti, for their valuable help. 620 10. Author's Addresses 622 Questions and comments should be directed to the authors and 623 msec@ietf.org: 625 Mark Baugher 626 Cisco Systems, Inc. 627 5510 SW Orchid Street Phone: +1 408-853-4418 628 Portland, OR 97219 USA Email: mbaugher@cisco.com 630 Elisabetta Carrara 631 Ericsson Research 632 SE-16480 Stockholm Phone: +46 8 50877040 633 Sweden EMail: elisabetta.carrara@ericsson.com 635 11. References 637 Normative 639 [PCST] Perrig, A., Canetti, R., Song, D., Tygar, D., "Efficient and 640 Secure Source Authentication for Multicast", in Proc. of Network and 641 Distributed System Security Symposium NDSS 2001, pp. 35-46, 2001. 643 [SRTP] Baugher, McGrew, Carrara, Naslund, Norrman, "The Secure Real- 644 time Transport Protocol", July 2003, . 646 [TESLA1] Perrig, Canetti, Song, Tygar, Briscoe, "TESLA: Multicast 647 Source Authentication Transform Introduction", October 2002, draft- 648 ietf-msec-tesla-intro-01.txt. 650 [TESLA2] Perrig, Canetti, Whillock, "TESLA: Multicast Source 651 Authentication Transform Specification", October 2002, draft-ietf- 652 msec-tesla-spec-00.txt 654 Informative 656 [gkmarch] Baugher, Canetti, Dondeti, Lindholm, "MSEC Group Key 657 Management Architecture", January 2003, . 660 [GDOI] Baugher, Weis, Hardjono, Harney, "The Group Domain of 661 Interpretation", RFC 3547, July 2003. 663 [MESP] Baugher, Canetti, Cheng, Rohatgi, "MESP: A Multicast 664 Framework for the IPsec ESP", March 2003, . 667 [MIKEY] Arkko, Carrara, Lindholm, Naslund, Norrman, "MIKEY: 668 Multimedia Internet KEYing", December 2003, 671 Intellectual Property Right Considerations 673 The IETF takes no position regarding the validity or scope of any 674 intellectual property or other rights that might be claimed to 675 pertain to the implementation or use of the technology described in 676 this document or the extent to which any license under such rights 677 might or might not be available; neither does it represent that it 678 has made any effort to identify any such rights. Information on the 679 IETF's procedures with respect to rights in standards-track and 680 standards-related documentation can be found in BCP-11. Copies of 681 claims of rights made available for publication and any assurances 682 of licenses to be made available, or the result of an attempt made 683 to obtain a general license or permission for the use of such 684 proprietary rights by implementors or users of this specification 685 can be obtained from the IETF Secretariat. 687 The IETF invites any interested party to bring to its attention any 688 copyrights, patents or patent applications, or other proprietary 689 rights which may cover technology that may be required to practice 690 this standard. Please address the information to the IETF Executive 691 Director. 693 Full Copyright Statement 695 Copyright (C) The Internet Society (2004). All Rights Reserved. 696 This document and translations of it may be copied and furnished to 697 others, and derivative works that comment on or otherwise explain it 698 or assist in its implementation may be prepared, copied, published 699 and distributed, in whole or in part, without restriction of any 700 kind, provided that the above copyright notice and this paragraph 701 are included on all such copies and derivative works. However, this 702 document itself may not be modified in any way, such as by removing 703 the copyright notice or references to the Internet Society or other 704 Internet organizations, except as needed for the purpose of 705 developing Internet standards in which case the procedures for 706 copyrights defined in the Internet Standards process must be 707 followed, or as required to translate it into languages other than 708 English. 710 The limited permissions granted above are perpetual and will not be 711 revoked by the Internet Society or its successors or assigns. 713 This document and the information contained herein is provided on an 714 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 715 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 716 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 717 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 718 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 720 This draft expires in August 2004.