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