idnits 2.17.1 draft-ietf-msec-srtp-tesla-05.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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 779. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 769), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 38. ** 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? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == In addition to RFC 3978, Section 5.1 boilerplate, a section with a similar start was also found: By submitting this Internet-Draft, the authors accept the provisions of BCP 78. == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 2005) is 6762 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) == Unused Reference: 'RFC1305' is defined on line 729, but no explicit reference was found in the text == Unused Reference: 'RFC3547' is defined on line 754, but no explicit reference was found in the text == Unused Reference: 'RFC3830' is defined on line 758, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1305 (Obsoleted by RFC 5905) ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Downref: Normative reference to an Informational RFC: RFC 4082 -- Obsolete informational reference (is this intentional?): RFC 3547 (Obsoleted by RFC 6407) Summary: 11 errors (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Baugher (Cisco) 3 MSEC Working Group Carrara (Ericsson) 4 INTERNET-DRAFT 5 EXPIRES: April 2006 October 2005 7 The Use of TESLA in SRTP 8 10 Status of this memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 By submitting this Internet-Draft, the authors accept the provisions 18 of BCP 78. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as 28 reference material or cite them other than as "work in progress". 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). All Rights Reserved. 40 Abstract 42 This memo describes the use of the Timed Efficient Stream Loss- 43 tolerant Authentication (RFC4082) transform within the Secure Real- 44 time Transport Protocol (SRTP), to provide data origin 45 authentication for multicast and broadcast data streams. 47 TABLE OF CONTENTS 49 1. Introduction...................................................2 50 1.1. Notational Conventions.......................................3 51 2. SRTP...........................................................3 52 3. TESLA..........................................................4 53 4. Usage of TESLA within SRTP.....................................4 54 4.1. The TESLA extension..........................................4 55 4.2. SRTP Packet Format...........................................5 56 4.3. Extension of the SRTP Cryptographic Context..................7 57 4.4. SRTP Processing..............................................8 58 4.4.1 Sender Processing...........................................9 59 4.4.2 Receiver Processing.........................................9 60 4.5. SRTCP Packet Format.........................................11 61 4.6. TESLA MAC...................................................13 62 4.7. PRFs........................................................13 63 5. TESLA Bootstrapping and Cleanup...............................14 64 6. SRTP TESLA Default parameters.................................14 65 7. Security Considerations.......................................15 66 8. IANA Considerations...........................................16 67 9. Acknowledgements..............................................16 68 10. Author's Addresses...........................................17 69 11. References...................................................17 71 1. Introduction 73 Multicast and broadcast communications introduce some new security 74 challenges compared to unicast communication. Many multicast and 75 broadcast applications need "data origin authentication" (DOA), or 76 "source authentication", in order to guarantee that a received 77 message had originated from a given source, and was not manipulated 78 during the transmission. In unicast communication, a pairwise 79 security association between one sender and one receiver can provide 80 data origin authentication using symmetric-key cryptography (such as 81 a message authentication code, MAC). When the communication is 82 strictly pairwise, the sender and receiver agree upon a key that is 83 known only to them. 85 In groups, however, a key is shared among more than two members, and 86 this symmetric-key approach does not guarantee data origin 87 authentication. When there is a group security association 88 [RFC4046] instead of a pairwise security association, any of the 89 members can alter the packet and impersonate any other member. The 90 MAC in this case only guarantees that the packet was not manipulated 91 by an attacker outside the group (and hence not in possession of the 92 group key), and that the packet was sent by a source within the 93 group. 95 Some applications cannot tolerate source ambiguity and need to 96 identify the true sender from any other group member. A common way 97 to solve the problem is by use of asymmetric cryptography, such as 98 digital signatures. This method, unfortunately, suffers from high 99 overhead, in terms of time (to sign and verify) and bandwidth (to 100 convey the signature in the packet). 102 Several schemes have been proposed to provide efficient data origin 103 authentication in multicast and broadcast scenarios. The Timed 104 Efficient Stream Loss-tolerant Authentication (TESLA) is one such 105 scheme. 107 This memo specifies TESLA authentication for SRTP. SRTP TESLA can 108 provide data origin authentication to RTP applications that use 109 group security associations (such as multicast RTP applications) so 110 long as receivers abide by the TESLA security invariants [RFC4082]. 112 1.1. Notational Conventions 114 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in [RFC2119]. 118 This specification assumes the reader is familiar with both SRTP and 119 TESLA. Few of their details are explained in this document, and the 120 reader can find them in their respective specifications, [RFC3711] 121 and [RFC4082]. This specification uses the same definitions as 122 TESLA for common terms and assumes that the reader is familiar with 123 the TESLA algorithms and protocols [RFC4082]. 125 2. SRTP 127 The Secure Real-time Transport Protocol (SRTP) [RFC3711] is a 128 profile of RTP, which can provide confidentiality, message 129 authentication, and replay protection to the RTP traffic and to the 130 RTP control protocol, the Real-time Transport Control Protocol 131 (RTCP). Note, the term "SRTP" may often be used to indicate SRTCP 132 as well. 134 SRTP is a framework that allows new security functions and new 135 transforms to be added. SRTP currently does not define any 136 mechanism to provide data origin authentication for group security 137 associations. Fortunately, it is straightforward to add TESLA to 138 the SRTP cryptographic framework. 140 The TESLA extension to SRTP is defined in this specification, which 141 assumes that the reader is familiar with the SRTP specification 142 [RFC3711], its packet structure, and processing rules. TESLA is an 143 alternative message-authentication algorithm that authenticates 144 messages from the source when a key is shared among two or more 145 receivers. 147 3. TESLA 149 TESLA provides delayed per-packet data authentication and is 150 specified in [RFC4082]. 152 In addition to its SRTP data-packet definition given here, TESLA 153 needs an initial synchronization protocol and initial bootstrapping 154 procedure. The synchronization protocol allows the sender and the 155 receiver to compare their clocks and determine an upper bound of the 156 difference. The synchronization protocol is outside the scope of 157 this document. 159 TESLA also requires an initial bootstrapping procedure to exchange 160 needed parameters and the initial commitment to the key chain 161 [RFC4082]. For SRTP, it is assumed that the bootstrapping is 162 performed out-of-band, possibly using the key management protocol 163 that is exchanging the security parameters for SRTP, e.g. [RFC3547, 164 RFC3830]. Initial bootstrapping of TESLA is outside the scope of 165 this document. 167 4. Usage of TESLA within SRTP 169 The present specification is an extension to the SRTP specification 170 [RFC3711] and describes the use of TESLA with only a single key 171 chain and delayed-authentication [RFC4082]. 173 4.1. The TESLA extension 175 TESLA is an OPTIONAL authentication transform for SRTP. When used, 176 TESLA adds the fields shown in Figure 1 per-packet. The fields 177 added by TESLA are called "TESLA authentication extensions," whereas 178 "authentication tag" or "integrity protection tag" indicate the 179 normal SRTP integrity protection tag, when the SRTP master key is 180 shared by more than two endpoints [RFC3711]. 182 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 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | i | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 ~ Disclosed Key ~ 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 ~ TESLA MAC ~ 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 Figure 1: The "TESLA authentication extension". 193 i: 32 bit, MANDATORY 194 Identifier of the time interval i, corresponding to the key K_i 195 that is used to calculate the TESLA MAC of the current packet 196 (and other packets sent in the current time interval i). 198 Disclosed Key: variable length, MANDATORY 199 The disclosed key (K_(i-d)), that can be used to authenticate 200 previous packets from earlier time intervals [RFC4082]. A 201 Section 4.3 parameter establishes the size of this field. 203 TESLA MAC (Message Authentication Code): variable length, MANDATORY 204 The MAC computed using the key K'_i (derived from K_i) 205 [RFC4082], which is disclosed in a subsequent packet (in the 206 Disclosed Key field). The MAC coverage is defined in Section 207 4.6. A Section 4.3 parameter establishes the size of this 208 field. 210 4.2. SRTP Packet Format 212 Figure 2 illustrates the format of the SRTP packet when TESLA is 213 applied. When applied to RTP, the TESLA authentication extension 214 SHALL be inserted before the (optional) SRTP MKI and (recommended) 215 authentication tag (SRTP MAC). 217 0 1 2 3 218 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 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+<+ 220 |V=2|P|X| CC |M| PT | sequence number | | | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 222 | timestamp | | | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 224 | synchronization source (SSRC) identifier | | | 225 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | 226 | contributing source (CSRC) identifiers | | | 227 | .... | | | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 229 | RTP extension (OPTIONAL) | | | 230 +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 231 | | payload ... | | | 232 | | +-------------------------------+ | | 233 | | | RTP padding | RTP pad count | | | 234 +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ | 235 | | i | | | 236 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 237 | ~ Disclosed Key ~ | | 238 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 239 | ~ TESLA MAC ~ | | 240 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<|-+ 241 | ~ MKI ~ | | 242 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 243 | ~ MAC ~ | | 244 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 245 | | | 246 +- Encrypted Portion TESLA Authenticated Portion ---+ | 247 | 248 Authenticated Portion ---+ 250 Figure 2. The format of the SRTP packet when TESLA is applied. 252 As in SRTP, the "Encrypted Portion" of an SRTP packet consists of 253 the encryption of the RTP payload (including RTP padding when 254 present) of the equivalent RTP packet. 256 The "Authenticated Portion" of an SRTP packet consists of the RTP 257 header, the Encrypted Portion of the SRTP packet, and the TESLA 258 authentication extension. Note that the definition is extended from 259 [RFC3711] by the inclusion of the TESLA authentication extension. 261 The "TESLA Authenticated Portion" of an SRTP packet consists of the 262 RTP header and the Encrypted Portion of the SRTP packet. As shown in 263 Figure 2, SRTP HMAC-SHA1 covers up to the MKI field but does not 264 include the MKI. It is necessary for packet integrity that the 265 SRTP-TESLA tag be covered by the SRTP integrity check. SRTP does 266 not cover the MKI field (because it does not need to be covered for 267 SRTP packet integrity). In order to make the two tags (SRTP-TESLA 268 and SRTP-HMAC_SHA1) contiguous, we would need to redefine the SRTP 269 specification to include the MKI in HMAC-SHA1 coverage. This change 270 is impossible and so the MKI field separates the TESLA MAC from the 271 SRTP MAC in the packet layout of Figure 2. This change to the 272 packet format presents no problem to an implementation that supports 273 the new SRTP-TESLA authentication transform. 275 The lengths of the Disclosed Key and TELSA MAC fields are Section 276 4.3 parameters. As in SRTP, fields that follow the packet payload 277 are not necessarily aligned on 32-bit boundaries. 279 4.3. Extension of the SRTP Cryptographic Context 281 When TESLA is used, the definition of cryptographic context in 282 Section 3.2 of SRTP SHALL include the following extensions. 284 Transform-dependent Parameters 286 1. an identifier for the PRF, f, implementing the one-way function 287 F(x) in TESLA (to derive the keys in the chain), e.g. to 288 indicate HMAC-SHA1, see Section 6 for the default value. 290 2. a non-negative integer n_p, determining the length of the F 291 output, i.e. the length of the keys in the chain (that is also 292 the key disclosed in an SRTP packet), see Section 6 for the 293 default value. 295 3. an identifier for the PRF, f', implementing the one-way 296 function F'(x) in TESLA (to derive the keys for the TESLA MAC, 297 from the keys in the chain), e.g. to indicate HMAC-SHA1, see 298 Section 6 for the default value. 300 4. a non-negative integer n_f, determining the length of the 301 output of F', i.e. of the key for the TESLA MAC, see Section 6 302 for the default value. 304 5. an identifier for the TESLA MAC, that accepts the output of 305 F'(x) as its key, e.g. to indicate HMAC-SHA1, see Section 6 for 306 the default value. 308 6. a non-negative integer n_m, determining the length of the 309 output of the TESLA MAC, see Section 6 for the default value. 311 7. the beginning of the session T_0, 313 8. the interval duration T_int (in msec), 315 9. the key disclosure delay d (in number of intervals) 317 10. the upper bound D_t (in sec) on the lag of the receiver clock 318 relative to the sender clock (this quantity has to be 319 calculated by the peers out-of-band) 321 11. non-negative integer n_c, determining the length of the key 322 chain, K_0...K_n-1 of [RFC4082] (see also Section 6 of this 323 document), which is determined based upon the expected duration 324 of the stream. 326 12. the initial key of the chain to which the sender has 327 committed himself. 329 F(x) is used to compute a keychain of keys in SRTP TESLA, as defined 330 in Section 6. Also according to TESLA, F'(x) computes a TESLA MAC 331 key with inputs as defined in Section 6. 333 Section 6 of this document defines the default values for the 334 transform-specific TESLA parameters. 336 4.4. SRTP Processing 338 The SRTP packet processing is described in Section 3.3 of the SRTP 339 specification [RFC3711]. The use of TESLA slightly changes the 340 processing, as the SRTP MAC is checked upon packet arrival for DoS 341 prevention, but the current packet is not TESLA-authenticated. Each 342 packet is buffered until a subsequent packet discloses its TESLA 343 key. The TESLA verification itself consists of some steps, such as 344 tests of TESLA security invariants, that are described in Section 345 3.5-3.7 of [RFC4082]. The words "TESLA computation" and "TESLA 346 verification" hereby imply all those steps, which are not all 347 spelled out in the following. In particular, notice that the TESLA 348 verification implies checking the safety condition (Section 3.5 of 349 [RFC4082]). 351 As pointed out in [RFC4082], if the packet is deemed "unsafe", then 352 the receiver considers the packet unauthenticated. It should discard 353 unsafe packets but, at its own risk, it may choose to use them 354 unverified. Hence, if the safe condition does not hold, it is 355 RECOMMENDED to discard the packet and log the event. 357 4.4.1 Sender Processing 359 The sender processing is as described in Section 3.3 of [RFC3711, up 360 to step 5 inclusive. After that the following process is followed: 362 6. When TESLA is applied, identify the key in the TESLA chain to be 363 used in the current time interval, and the TESLA MAC key derived 364 from it. Execute the TESLA computation to obtain the TESLA 365 authentication extension for the current packet, by appending the 366 current interval identifier (as i field), the disclosed key of the 367 chain for the previous disclosure interval (i.e. the key for 368 interval i is disclosed in interval i+d), and the TESLA MAC under 369 the current key from the chain. This step uses the related TESLA 370 parameters from the crypto context as for Step 4. 372 7. If the MKI indicator in the SRTP crypto context is set to one, 373 append the MKI to the packet. 375 8. When TESLA is applied, and if the SRTP authentication (external 376 tag) is required (for DoS), compute the authentication tag as 377 described in step 7 of Section 3.3 of the SRTP specification, but 378 with coverage as defined in this specification (see Section 4.6). 380 9. If necessary, update the rollover counter (step 8 in Section 3.3 381 of [RFC3711]). 383 4.4.2 Receiver Processing 385 The receiver processing is as described in Section 3.3 of [RFC3711], 386 up to step 4 inclusive. 388 To authenticate and replay-protect the current packet, the 389 processing is as follows: 391 First check if the packet has been replayed (as for Section 3.3 of 392 [RFC3711]). Note however, the SRTP replay list contains SRTP 393 indices of recently received packets that have been authenticated 394 by TESLA (i.e. replay list updates MUST NOT be based on SRTP MAC). 395 If the packet is judged to be replayed, then the packet MUST be 396 discarded, and the event SHOULD be logged. 398 Next, perform verification of the SRTP integrity protection tag 399 (note, not the TESLA MAC), if present, using the rollover counter 400 from the current packet, the authentication algorithm indicated in 401 the cryptographic context, and the session authentication key. If 402 the verification is unsuccessful, the packet MUST be discarded 403 from further processing and the event SHOULD be logged. 405 If the verification is successful, remove and store the MKI (if 406 present) and authentication tag fields from the packet. The packet 407 is buffered, awaiting disclosure of the TESLA key in a subsequent 408 packet. 410 TESLA authentication is performed on a packet when the key is 411 disclosed in a subsequent packet. Recall that a key for interval i 412 is disclosed during interval i+d, i.e. the same key is disclosed 413 in packets sent over d intervals of length t_int. If the interval 414 identifier i from the packet (Section 4.1) has advanced more than 415 d intervals from the highest value of i that has been received, 416 then packets have been lost and one or more keys MUST be computed 417 as described in Section 3.2, second paragraph, of the TESLA 418 specification [RFC4082]. The computation is performed recursively 419 for all disclosed keys that have been lost, from the newly- 420 received interval to the last-received interval. 422 When a newly-disclosed key is received or computed, perform the 423 TESLA verification of the packet using the rollover counter from 424 the packet, the TESLA security parameters from the cryptographic 425 context, and the disclosed key. If the verification is 426 unsuccessful, the packet MUST be discarded from further processing 427 and the event SHOULD be logged. If the TESLA verification is 428 successful, remove the TESLA authentication extension from the 429 packet. 431 To decrypt the current packet, the processing is the following: 433 Decrypt the Encrypted Portion of the packet, using the decryption 434 algorithm indicated in the cryptographic context, the session 435 encryption key and salt (if used) found in Step 4 with the index 436 from Step 2. 438 (Note that the order of decryption and TESLA verification is not 439 mandated. It is RECOMMENDED to perform the TESLA verification 440 before decryption. TESLA application designers might choose to 441 implement optimistic processing techniques such as notification of 442 TESLA verification results after decryption or even after plaintext 443 processing. Optimistic verification is beyond the scope of this 444 document.) 446 Update the rollover counter and highest sequence number, s_l, in the 447 cryptographic context, using the packet index estimated in Step 2. 448 If replay protection is provided, also update the Replay List (i.e., 449 the Replay List is updated after the TESLA authentication is 450 successfully verified). 452 4.5. SRTCP Packet Format 454 Figure 3 illustrates the format of the SRTCP packet when TESLA is 455 applied. The TESLA authentication extension SHALL be inserted 456 before the MKI and authentication tag. Recall from [RFC3711] that 457 in SRTCP the MKI is OPTIONAL, while the E-bit, the SRTCP index, and 458 the authentication tag are MANDATORY. This means that the SRTP 459 (external) MAC is MANDATORY also when TESLA is used. 461 As in SRTP, the "Encrypted Portion" of an SRTCP packet consists of 462 the encryption of the RTCP payload of the equivalent compound RTCP 463 packet, from the first RTCP packet, i.e., from the ninth (9) byte to 464 the end of the compound packet. 466 The "Authenticated Portion" of an SRTCP packet consists of the 467 entire equivalent (eventually compound) RTCP packet, the E flag, the 468 SRTCP index (after any encryption has been applied to the payload), 469 and the TESLA extension. Note that the definition is extended from 470 [RFC3711] by the inclusion of the TESLA authentication extension. 472 We define the "TESLA Authenticated Portion" of an SRTCP packet as 473 consisting of the RTCP header (first 8 bytes) and the Encrypted 474 Portion of the SRTCP packet. 476 Processing of an SRTCP packets is similar to the SRTP processing 477 (Section 4.3), but there are SRTCP-specific changes described in 478 Section 3.4 of the SRTP specification [RFC3711] and in Section 4.6 479 of this memo. 481 0 1 2 3 482 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 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+<+ 484 |V=2|P| RC | PT=SR or RR | length | | | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 486 | SSRC of sender | | | 487 +>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | 488 | ~ sender info ~ | | 489 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 490 | ~ report block 1 ~ | | 491 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 492 | ~ report block 2 ~ | | 493 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 494 | ~ ... ~ | | 495 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 496 | |V=2|P| SC | PT=SDES=202 | length | | | 497 | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | 498 | | SSRC/CSRC_1 | | | 499 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 500 | ~ SDES items ~ | | 501 | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | 502 | ~ ... ~ | | 503 +>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | 504 | |E| SRTCP index | | | 505 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ | 506 | | i | | | 507 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 508 | ~ Disclosed Key ~ | | 509 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 510 | ~ TESLA MAC ~ | | 511 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<|-+ 512 | ~ SRTCP MKI ~ | | 513 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 514 | : authentication tag : | | 515 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 516 | | | 517 +-- Encrypted Portion TESLA Authenticated Portion -----+ | 518 | 519 Authenticated Portion -------+ 521 Figure 3. The format of the SRTCP packet when TESLA is applied. 523 Note that when additional fields are added to a packet, it will 524 increase the packet size and thus the RTCP average packet size. 526 4.6. TESLA MAC 528 Let M' denote packet data to be TESLA-authenticated. In the case of 529 SRTP, M' SHALL consist of the SRTP TESLA Authenticated Portion (RTP 530 header and SRTP Encrypted Portion, see Figure 2) of the packet 531 concatenated with the rollover counter (ROC) of the same packet: 533 M' = ROC || TESLA Authenticated Portion. 535 In the case of SRTCP, M' SHALL consist of the SRTCP TESLA 536 Authenticated Portion only (RTCP header and SRTCP Encrypted 537 Portion). 539 The normal authentication tag (OPTIONAL for SRTP, MANDATORY for 540 SRTCP) SHALL be applied with the same coverage as specified in 541 [RFC3711], i.e.: 543 - for SRTP: Authenticated Portion || ROC (with the extended 544 definition of SRTP Authentication Portion as in Section 4.2) 546 - for SRTCP: Authenticated Portion (with the extended definition of 547 SRTCP Authentication Portion as in Section 4.2). 549 The pre-defined authentication transform in SRTP, HMAC-SHA1 550 [RFC2104], is also used to generate the TESLA MAC. For SRTP 551 (respectively SRTCP), the HMAC SHALL be applied to the key in the 552 TESLA chain corresponding to a particular time interval, and M' as 553 specified above. The HMAC output SHALL then be truncated to the n_m 554 left-most bits. Default values are in Section 6. 556 As with SRTP, the pre-defined HMAC-SHA1 authentication algorithm MAY 557 be replaced with an alternative algorithm that is specified in a 558 future Internet RFC. 560 4.7. PRFs 562 TESLA requires two pseudo-random functions (PRFs), f and f', to 563 implement 565 * one one-way function F(x) to derive the key chain, and 566 * one one-way function F'(x) to derive (from each key of the chain) 567 the key that is actually used to calculate the TESLA MAC. 569 When TESLA is used within SRTP, the default choice of the two PRFs 570 SHALL be HMAC-SHA1. Default values are in Section 6. 572 Other PRFs can be chosen, and their use SHALL follow the common 573 guidelines in [RFC3711] when adding new security parameters. 575 5. TESLA Bootstrapping and Cleanup 577 The extensions to the SRTP cryptographic context include a set of 578 TESLA parameters that are listed in section 4.3 of this document. 579 Furthermore, TESLA MUST be bootstrapped at session set-up (for the 580 parameter exchange and the initial key commitment) through a regular 581 data authentication system (a digital signature algorithm is 582 RECOMMENDED). Key management procedures can take care of this 583 bootstrapping prior to the commencement of an SRTP session where 584 TESLA authentication is used. The bootstrapping mechanism is out of 585 scope for this document (it could for example be part of the key 586 management protocol). 588 A critical factor for the security of TESLA is that the sender and 589 receiver need to be loosely synchronized. TESLA requires a bound on 590 clock drift to be known (D_t). Use of TESLA in SRTP assumes that 591 the time synchronization is guaranteed by out-of-band schemes (e.g. 592 key management), i.e. it is not in the scope of SRTP. 594 It also should be noted that TESLA has some reliability requirements 595 in that a key is disclosed for a packet in a subsequent packet, 596 which can get lost. Since a key in a lost packet can be derived from 597 a future packet, TESLA is robust to packet loss. This key stream 598 stops, however, when the key-bearing data stream packets stop at the 599 conclusion of the RTP session. To avoid this nasty boundary 600 condition, send null packets with TESLA keys for one entire key- 601 disclosure period following the interval in which the stream ceases: 602 Null packets SHOULD be sent for d intervals of duration t_int (items 603 8 and 9 of Section 4.3). The rate of null packets SHOULD be the 604 average rate of the session media stream. 606 6. SRTP TESLA Default parameters 608 Key management procedures establish SRTP TESLA operating parameters, 609 which are listed in section 4.3 of this document. The operating 610 parameters appear in the SRTP cryptographic context and have the 611 default values that are described in this section. In the future, 612 an Internet RFC MAY define alternative settings for SRTP TESLA that 613 are different than those specified here. In particular, it should 614 be noted that the settings defined in this memo can have a large 615 impact on bandwidth, as it adds 38 bytes to each packet (when the 616 field length values are the default ones). For certain 617 applications, this overhead may represent more than a 50% increase 618 in packet size. Alternative settings might seek to reduce the 619 number and length of various TESLA fields and outputs. No such 620 optimizations are considered in this memo. 622 It is RECOMMENDED that the SRTP MAC be truncated to 32 bits since the 623 SRTP MAC provides only group authentication and serves only as 624 protection against external DoS. 626 The default values for the security parameters are listed in the 627 following. "OWF" denotes a one-way function. 629 Parameter Mandatory-to-support Default 630 --------- -------------------- ------- 631 TESLA KEYCHAIN OWF (F(x)) HMAC-SHA1 HMAC-SHA1 632 BIT-OUTPUT LENGTH n_p 160 160 634 TESLA MAC KEY OWF (F'(F(x))) HMAC-SHA1 HMAC-SHA1 635 BIT-OUTPUT LENGTH n_f 160 160 637 TESLA MAC HMAC-SHA1 HMAC-SHA1 638 (TRUNCATED) BIT-OUTPUT LENGTH n_m 80 80 640 As shown above, TESLA implementations MUST support HMAC-SHA1 641 [RFC2104] for the TESLA MAC, the MAC key generator, and the TESLA 642 keychain generator one-way function. The TESLA keychain generator is 643 recursively defined as follows [RFC4082]. 645 K_i=HMAC_SHA1(K_{i+1},0), i=0..N-1 647 where N-1=n_c from the cryptographic context. 649 The TESLA MAC key generator is defined as follows [RFC4082]. 651 K'_i=HMAC_SHA1(K_i,1) 653 The TESLA MAC uses a truncated output of ten bytes [RFC2104] and is 654 defined as follows. 656 HMAC_SHA1(K'_i, M') 658 where M' is as specified in Section 4.6. 660 7. Security Considerations 662 Denial of Service (DoS) attacks on delayed authentication are 663 discussed in [PCST]. TESLA requires receiver buffering before 664 authentication, therefore the receiver can suffer a denial of 665 service attack due to a flood of bogus packets. To address this 666 problem, the external SRTP MAC, based on the group key, MAY be used 667 in addition to the TESLA MAC. The short size of the SRTP MAC 668 (default 32 bits) is motivated by the fact that that MAC is purely 669 for DoS prevention from attackers external to the group. The shorter 670 output tag means that an attacker has a better chance of getting a 671 forged packet accepted, which is about 2^31 attempts on average. As 672 a first line of defense against a denial of service attack, a short 673 tag is probably adequate; a victim will likely have ample evidence 674 that it is under attack before accepting a forged packet, which will 675 subsequently fail the TESLA check. [RFC4082] describes other 676 mechanisms that can be used to prevent DoS, in place of the external 677 group-key MAC. If used, they need to be added as processing steps 678 (following the guidelines of [RFC4082]). 680 The use of TESLA in SRTP defined in this specification is subject to 681 the security considerations discussed in the SRTP specification 682 [RFC3711] and in the TESLA specification [RFC4082]. In particular, 683 the TESLA security is dependent on the computation of the "safety 684 condition" as defined in Section 3.5 of [RFC4082]. 686 SRTP TESLA depends on the effective security of the systems that 687 perform bootstrapping (time synchronization) and key management. 688 These systems are external to SRTP and are not considered in this 689 specification. 691 The length of the TESLA MAC is by default 80 bits. RFC 2104 requires 692 the MAC length to be at least 80 bits and at least half the output 693 size of the underlying hash function. The SHA-1 output size is 160 694 bits, so both of these requirements are met with the 80 bit MAC 695 specified in this document. Note that IPsec implementations tend to 696 use 96 bits for their MAC values to align the header with a 64 bit 697 boundary. Both MAC sizes are well beyond the reach of current 698 cryptanalytic techniques. 700 8. IANA Considerations 702 No IANA registration is required. 704 9. Acknowledgements 706 The authors would like to thanks Ran Canetti, Karl Norrman, Mats 707 Naslund, Fredrik Lindholm, David McGrew, and Bob Briscoe for their 708 valuable help. 710 10. Author's Addresses 712 Questions and comments should be directed to the authors and 713 msec@ietf.org: 715 Mark Baugher 716 Cisco Systems, Inc. 717 5510 SW Orchid Street Phone: +1 408-853-4418 718 Portland, OR 97219 USA Email: mbaugher@cisco.com 720 Elisabetta Carrara 721 Ericsson 722 SE-16480 Stockholm Phone: +46 8 50877040 723 Sweden EMail: elisabetta.carrara@ericsson.com 725 11. References 727 Normative 729 [RFC1305] Mills D., Network Time Protocol (Version 3) Specification, 730 Implementation and Analysis, Internet Engineering Task Force, RFC 731 1305, March, 1992. 733 [RFC2104] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for 734 Message Authentication," Internet Engineering Task Force, RFC 2104, 735 February, 1997. 737 [RFC2119] Bradner, Keywords to Use in RFCs to Indicate Requirement 738 Levels, Internet Engineering Task Force, RFC 2119, March 1997. 740 [RFC3711] Baugher, McGrew, Naslund, Carrara, Norrman, "The Secure 741 Real-time Transport Protocol", Internet Engineering Task Force, RFC 742 3711, March 2004. 744 [RFC4082] Perrig, Song, Canetti, Tygar, Briscoe, "TESLA: Multicast 745 Source Authentication Transform Introduction", Internet Engineering 746 Task Force, RFC 4082, June 2005. 748 Informative 750 [PCST] Perrig, A., Canetti, R., Song, D., Tygar, D., "Efficient and 751 Secure Source Authentication for Multicast", in Proc. of Network and 752 Distributed System Security Symposium NDSS 2001, pp. 35-46, 2001. 754 [RFC3547] Baugher, Weis, Hardjono, Harney, "The Group Domain of 755 Interpretation", Internet Engineering Task Force, RFC 3547, July 756 2003. 758 [RFC3830] Arkko et al., "MIKEY: Multimedia Internet KEYing", RFC 759 3830, Internet Engineering Task Force, August 2004. 761 [RFC4046] Baugher, Canetti, Dondeti, Lindholm, "MSEC Group Key 762 Management Architecture", Internet Engineering Task Force, April 763 2005. 765 Copyright Notice 767 Copyright (C) The Internet Society (2005). This document is subject 768 to the rights, licenses and restrictions contained in BCP 78, and 769 except as set forth therein, the authors retain all their rights. 771 Disclaimer of Validity 773 This document and the information contained herein are provided on 774 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 775 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 776 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 777 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 778 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 779 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 781 This draft expires in April 2006.