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