idnits 2.17.1 draft-ietf-msec-bootstrapping-tesla-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 792. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 769. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 776. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 782. ** 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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: ---------------------------------------------------------------------------- == 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 (January 11, 2006) is 6677 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) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Downref: Normative reference to an Informational RFC: RFC 4082 == Outdated reference: A later version (-07) exists of draft-ietf-msec-mikey-rsa-r-01 -- Obsolete informational reference (is this intentional?): RFC 1305 (Obsoleted by RFC 5905) -- Obsolete informational reference (is this intentional?): RFC 2327 (Obsoleted by RFC 4566) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MSEC S. Fries 3 Internet-Draft H. Tschofenig 4 Expires: July 15, 2006 Siemens 5 January 11, 2006 7 Bootstrapping TESLA 8 draft-ietf-msec-bootstrapping-tesla-03.txt 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 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on July 15, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 TESLA, the Timed Efficient Stream Loss-tolerant Authentication 42 protocol is a protocol for providing source authentication in 43 multicast scenarios. TESLA is an efficient protocol with low 44 communication and computation overhead, which scales to large numbers 45 of receivers, and also tolerates packet loss. TESLA is based on 46 loose time synchronization between the sender and the receivers. 47 Source authentication is realized in TESLA by using Message 48 Authentication Code (MAC) chaining. The use of TESLA within the 49 Secure Real-time Transport Protocol (SRTP) has been published 50 targeting multicast authentication in scenarios, where SRTP is 51 applied to protect the multimedia data. This solution assumes that 52 TESLA parameters are made available by out-of-band mechanisms. 54 This document specifies payloads for the Multimedia Internet Keying 55 (MIKEY) protocol for bootstrapping TESLA for source authentication of 56 secure group communications using SRTP. TESLA may be bootstrapped 57 using one of the MIKEY key management approaches, e.g., by using a 58 digitally signed MIKEY message sent via unicast, multicast or 59 broadcast. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. TESLA Parameter Overview . . . . . . . . . . . . . . . . . . . 4 66 4. Parameter encoding within MIKEY . . . . . . . . . . . . . . . 6 67 4.1. Security Policy payload (SP) . . . . . . . . . . . . . . . 6 68 4.2. TESLA policy . . . . . . . . . . . . . . . . . . . . . . . 7 69 4.3. Time synchronization . . . . . . . . . . . . . . . . . . . 9 70 4.4. Key data transport within MIKEY's General Extension 71 Payload . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 73 5.1. Man-in-the-Middle (MitM) Attack . . . . . . . . . . . . . 11 74 5.2. Downgrading Attack . . . . . . . . . . . . . . . . . . . . 12 75 5.3. Denial of Service Attack . . . . . . . . . . . . . . . . . 12 76 5.4. Replay Attack . . . . . . . . . . . . . . . . . . . . . . 13 77 5.5. Traffic Analysis . . . . . . . . . . . . . . . . . . . . . 13 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 79 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 81 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 82 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 84 Intellectual Property and Copyright Statements . . . . . . . . . . 19 86 1. Introduction 88 In many multicast, broadcast, and also unicast communication 89 scenarios it is necessary to guarantee that a recieved message has 90 been sent from a dedicated source and has not been altered while in 91 transfer. In unicast communication commonly a pairwise security 92 association exists, which enables the validation of message integrity 93 and data origin. The approach in group based communication is 94 different as here a key is normally shared between the members of a 95 group and thus this key may not be used for data origin 96 authentication. As in some applications a dedicated identification 97 of a sender is required, there exists the requirement to support data 98 origin authentication also in multicast scenarios. One of the 99 methods supporting this is TESLA [RFC4082]. TESLA provides source 100 authentication in multicast scenarios by using MAC chaining. It is 101 based on loose time synchronization between the sender and the 102 receivers. 104 [I-D.ietf-msec-srtp-tesla] describes extensions for SRTP [RFC3711] in 105 order to support TESLA [RFC4082] for source authentication in 106 multicast scenarios. SRTP needs dedicated cryptographic context 107 describing the security parameter and security policy per multimedia 108 session to be protected. This cryptographic context needs to be 109 enhanced with a set of TESLA parameters. It is necessary to provide 110 these parameters before the actual multicast session starts. 111 [I-D.ietf-msec-srtp-tesla] does not address the bootstrapping for 112 these parameters. 114 This document details bootstrapping of TESLA parameters in terms of 115 parameter distribution for TESLA policy as well as the initial key, 116 using the Multimedia Internet Keying (MIKEY) [RFC3830] protocol. 117 MIKEY defines an authentication and key management framework that can 118 be used for real-time applications (both for peer-to-peer 119 communication and group communication). In particular, [RFC3830] is 120 defined in a way that is intended to support SRTP in the first place 121 but is open to enhancements to be used for other purposes too. 122 Following the description in RFC 3830 [RFC3830] MIKEY is targeted for 123 point-to-point as well as for group communication. In the context of 124 group communication an administrator entity can distribute session 125 keys to the associated entities participating in the communication 126 session. This scenario is also applicable for TESLA where one entity 127 may provide information to many others in a way that the integrity of 128 the communicated information can be assured. The combination of 129 MIKEY and TESLA supports this group-based approach by utilizing the 130 MIKEY framework to distribute TESLA parameter information to all 131 involved entities. Note that this document only focuses on the 132 distribution of the parameters, not on the generation of those 133 parameters. 135 MIKEY [RFC3830] itself describes three authentication and key 136 exchange protocols (symmetric key enryption, public key encryption, 137 and signed Diffie-Hellman) Extensions to the MIKEY key exchange 138 methods have been defined. A fourth key distribution method is 139 provided by [I-D.ietf-msec-mikey-dhhmac] and describes a symetrically 140 protected Diffie-Hellman key agreement. A further option has been 141 proposed in [I-D.ietf-msec-mikey-rsa-r] describing an enhanced 142 asymmetric exchange variant, supporting also inband certificate 143 exchange. All of the different key management schemes mentioned 144 above may be used to provide the TESLA parameters. The required 145 TESLA parameters to be exchanged are already described in [I-D.ietf- 146 msec-srtp-tesla], while this document describes their transport 147 within MIKEY. 149 The following security requirements have to be placed on the exchange 150 of TESLA parameters: 152 o Authentication and Integrity MUST be provided when sending the 153 TESLA parameters, especially for the initial key. 154 o Confidentiality MAY be provided for the TESLA parameters 156 These security requirements apply to the TESLA bootstrapping 157 procedure only. Security requirements for applications using TESLA 158 are beyond the scope of this document. Security aspects that relate 159 to TESLA itself are described in [RFC4082] and security issues for 160 TESLA usage for SRTP are covered in [I-D.ietf-msec-srtp-tesla]. 162 It is important to note that this document is one piece of a complete 163 solution. Assuming that media traffic is to be secured using TESLA 164 as described in [I-D.ietf-msec-srtp-tesla] then (a) keying material 165 is required and (b) parameters for TESLA. This document contributes 166 the parameters and the authentication methods used in MIKEY to 167 provide the keying material. The parameter exchange for TESLA also 168 needs to be secured against tampering. This protection is provided 169 also by MIKEY. 171 2. Terminology 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 175 document are to be interpreted as described in RFC 2119 [RFC2119]. 177 3. TESLA Parameter Overview 179 According to [I-D.ietf-msec-srtp-tesla] a number of transform 180 dependent parameters need to be provided for proper TESLA operation. 182 The complete list of parameters can be found in Section 4.3 of 183 [I-D.ietf-msec-srtp-tesla]. Note, that the parameter 10 of 184 [I-D.ietf-msec-srtp-tesla], describing the lag of the receiver clock 185 relative to the sender clock, is omitted in this document since it 186 can be computed. 188 MIKEY already requires synchronized clocks, which also provides for 189 synchronization for TESLA. Moreover, Section 4.3, states an option 190 to use MIKEY for clock drift determination between sender and 191 receiver. Thus, this parameter does not need to be transmitted in 192 MIKEY directly. 194 The information in brackets provides the default values as specified 195 in Section 6.2 of [I-D.ietf-msec-srtp-tesla]. 197 1. An identifier for the Pseudo Random Function (PRF), implementing 198 the one-way function F(x) in TESLA (F(x) is used to calculate 199 keys using a hash chain), e.g. to indicate a keyed hashing 200 function (default HMAC-SHA1). 202 2. A non-negative integer, determining the length of the F output, 203 i.e. the length of the keys in the chain (that is also the key 204 disclosed in an SRTP packet if TESLA is used in the SRTP 205 context) (default 160 bit). 207 3. An identifier for the PRF, implementing the one-way function 208 F'(x) in TESLA (to derive the keys for the TESLA MAC, from the 209 keys in the chain), e.g. to indicate a keyed hashing function 210 (default HMAC-SHA1). 212 4. A non-negative integer, determining the length of the output of 213 F', i.e. the length of the key for the TESLA MAC (default 160 214 bit). 216 5. An identifier for the TESLA MAC, that accepts the output of 217 F'(x) as its key, e.g. to indicate a keyed hashing function 218 (default HMAC-SHA1). 220 6. A non-negative integer, determining the length of the output of 221 the TESLA MAC (default 80 bit). 223 7. The beginning of the session for which a key will be applied. 225 8. The interval duration (in milliseconds), for which a dedicated 226 key will be used. 228 9. The key disclosure delay (in number of intervals), characterizes 229 the period after which the key will be sent to the involved 230 entities (e.g., as part of SRTP packets). 232 10. Non-negative integer, determining the length of the key chain, 233 which is determined based up the expected duration of the 234 stream. 236 11. The initial key of the chain to which the sender has committed 237 himself. 239 4. Parameter encoding within MIKEY 241 As mentioned in Section 3, TESLA parameters need to be transported 242 before actually starting a session. MIKEY currently only defines a 243 payload for transporting the SRTP policy (see Section 6.10 of 244 [RFC3830]). This section describes the enhancement of MIKEY to allow 245 the transport of a TESLA policy and additionally the initial TESLA 246 key. 248 4.1. Security Policy payload (SP) 250 The Security Policy payload defines a set of policies that apply to a 251 specific security protocol. The definition here relies on the 252 security policy payload definition in [RFC3830]. 254 0 1 2 3 255 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 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 ! Next payload ! Policy no ! Prot type ! Policy param ~ 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 ~ length (cont) ! Policy param ~ 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 * Next payload (8 bits): 263 Identifies the payload that is added after 264 this payload. See Section 6.1 of [RFC3830] for 265 more details. 267 * Policy no (8 bits): 268 Each security policy payload must be given a 269 distinct number for the current MIKEY session by the 270 local peer. This number is used to map a cryptographic session 271 to a specific policy (see also Section 6.1.1 of [RFC3830]). 273 * Prot type (8 bits): 274 This value defines the security protocol. 275 A second value needs to be defined as shown below: 276 (MIKEY already defines the value 0.) 278 Prot type | Value | 279 --------------------------- 280 SRTP | 0 | 281 TESLA | 1 | 283 * Policy param length (16 bits): 284 This field defines the total length of the 285 policy parameters for the selected security protocol. 287 * Policy param (variable length): 288 This field defines the policy for the specific 289 security protocol. 291 The Policy param part is built up by a set of Type/Length/Value (TLV) 292 payloads. For each security protocol, a set of possible type/value 293 pairs can be negotiated as defined. 295 0 1 2 3 296 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 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 ! Type ! Length ! Value ~ 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 * Type (8 bits): 302 Specifies the type of the parameter. 304 * Length (8 bits): 305 Specifies the length of the Value field (in bytes). 307 * Value (variable length): 308 Specifies the value of the parameter. 310 4.2. TESLA policy 312 This policy specifies the parameters for TESLA. The types/values 313 that can be negotiated are defined by the following table. The 314 concrete default values are taken from [I-D.ietf-msec-srtp-tesla], 315 but other values may also be used: 317 Type | Meaning | Possible values 318 --------------------------------------------------------------- 319 1 | PRF identifier for f, realising F(x) | see below 320 2 | Length of PRF f output | 160 321 3 | PRF identifier for f', realising F'(x) | see below 322 4 | Length of PRF f' output | 160 323 5 | Identifier for the TESLA MAC | see below 324 6 | Length of TESLA MAC output | 80 (truncated) 325 7 | Start of session | in bytes 326 8 | Interval duration (in msec) | in bytes 327 9 | Key disclosure delay | in bytes 328 10| Key chain length (numer of intervals) | in bytes 329 11| local timestamp media receiver | see below 331 The time values stated in items 7 and 11 SHALL be transported in NTP- 332 UTC format, which is one of the three options described in Section 333 6.6 of [RFC3830]. For the policy item 8 a four-byte integer value 334 and for the policy item 9 a two-byte integer value is RECOMMENDED 335 carrying interval and key disclosure delay. Note that the policy 336 type 11 does NOT correspond to the TESLA parameter 11 stated in 337 Section 3, which is actually discussed in Section 4.4. Moreover, the 338 policy type 11 stated above is optional and SHOULD be used, if the 339 time synchronization described in Section 4.3 point two is used. 340 Otherwise it SHOULD be omitted. 342 For the PRF realising F(x), a one byte length is sufficient. 343 The currently defined possible values are: 345 TESLA PRF F(x) | Value 346 ----------------------- 347 HMAC-SHA1 | 0 349 For the PRF realising F'(x), a one byte length is enough. 350 The currently defined possible values are: 352 TESLA PRF F'(x) | Value 353 ----------------------- 354 HMAC-SHA1 | 0 356 For the TESLA MAC, a one byte length is enough. 357 The currently defined possible values are: 359 TESLA MAC | Value 360 ----------------------- 361 HMAC-SHA1 | 0 363 4.3. Time synchronization 365 MIKEY as well as TESLA require the time synchronization of the 366 communicating peers. MIKEY requires time sychronization to provide 367 timestamp-based replay protection for the one-roundtrip 368 authentication and key exchange protocols. TESLA, on the other hand, 369 needs this information to determine the clock drift between the 370 senders and the receivers in order to appropriately release the 371 disclosed key. Two alternatives are available for time 372 synchronization: 373 1. Usage of out-of-band synchronization using NTP [RFC1305]. This 374 approach is already recommended within [RFC3830]. The advantage 375 of this approach is the option to use the MIKEY key management 376 variants that perform within a half-roundtrip. The disadvantage 377 is the required time synchronization via an additional protocol. 378 2. [RFC4082] also sketches a possible inband synchronization in 379 Section 3.3.1. This approach is summarized here in the context 380 of MIKEY. Note, that here the actual TESLA policy payload is 381 transmitted as part of the MIKEY responder message. 382 * The data receiver, which would be the MIKEY initiator sets the 383 local time parameter t_r and sends it as part of the timestamp 384 payload as described in [RFC3830]. This value t_r needs to be 385 stored locally. 386 * Upon receipt of the MIKEY initiator message the data sender 387 replies with the MIKEY responder message, setting the local 388 time stamp at data receiver (parameter 11) to the value t_r 389 received in the MIKEY initiator message and sets his local 390 time as 64 bit UTC value t_s in the timestamp payload as 391 described in [RFC3830]. 393 MIKEY initiator message 394 [MIKEY parameter incl. local timestamp (t_r)] 395 ------------------> 397 MIKEY responder message 398 [MIKEY parameter incl. local timestamp (t_s), TESLA policy 399 payload, received local time stamp t_r] 400 <------------------ 402 * Upon receiving the MIKEY responder message the data receiver 403 sets D_t = t_s - t_r + S, where S is an estimated bound on the 404 clock drift throughout the duration of the session. 405 This approach has the advantage that it does not require an 406 additional time synchronization protocol. The disadvantage is 407 the necessity to perform a full MIKEY handshake, to enable 408 correct parameter transport. Moreover this approach is direction 409 dependent, as it may only be applied if the media receiver is 410 also the MIKEY initiator. 412 Out-of-band synchronization using NTP (i.e., alternative 1) is the 413 RECOMMENDED approach for clock synchronization. In scenarios where 414 the media receiver is also the MIKEY initiator piggybacking timestamp 415 information in MIKEY (i.e., alternative 2) MAY be used to allow for 416 inband determination of the clock drift between sender and receiver. 418 4.4. Key data transport within MIKEY's General Extension Payload 420 The General Extensions Payload was defined to allow possible 421 extensions to MIKEY without the need for defining a completely new 422 payload each time. This payload can be used in any MIKEY message and 423 is part of the authenticated/signed data part. 425 0 1 2 3 426 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 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 ! Next payload ! Type ! Length ! 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 ! Data ~ 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 * Next payload (8 bits): 434 Identifies the payload following this payload. 436 * Type (8 bits): 437 Identifies the type of general payload. MIKEY 438 already defines the Values 0 and 1. 439 This document introduces a new value (2). 441 Type | Value | Comments 442 ---------------------------------------------------- 443 Vendor ID | 0 | Vendor specific byte string 444 SDP IDs | 1 | List of SDP key mgmt IDs 445 TESLA I-Key | 2 | TESLA initial key 447 * Length (16 bits): 448 The length in bytes of the Data field. 450 * Data (variable length): 451 The general payload data. 453 5. Security Considerations 455 The security properties of multi-media data in a multicast 456 environment depends on a number of building blocks. 458 SRTP-TESLA [I-D.ietf-msec-srtp-tesla] describes extensions for SRTP 459 [RFC3711] in order to support TESLA [RFC4082] for source 460 authentication in multicast scenarios. As such, security 461 considerations described with TESLA (see [PCST] and [RFC4082]), the 462 TESLA SRTP mapping [I-D.ietf-msec-srtp-tesla] and SRTP [RFC3711] 463 itself are relevant in this context. 465 Furthermore, since this document details bootstrapping of TESLA using 466 the Multimedia Internet Keying (MIKEY) [RFC3830] protocol the 467 security considerations of MIKEY are applicable to this document. 469 As a summary, in order for a multi-media application to support TESLA 470 the following protocol interactions (in relationship to this document 471 are necessary): 473 o MIKEY [RFC3830] is executed between the desired entities to 474 perform authentication and a secure distribution of keying 475 material. In order to subsequently use TESLA the parameters 476 described in this document are distributed using MIKEY. MIKEY 477 itself uses another protocol for parameter transport, namely the 478 Session Description Protocol (SDP, [RFC2327]), that might again be 479 used within Session Initiation Protocol (SIP, [RFC3261]) to setup 480 a session between the desired entities. 481 o After the algorithms, parameters and the session keys are 482 available at the respective communication entities data traffic 483 protection via SRTP-TESLA [I-D.ietf-msec-srtp-tesla] can be used. 484 SRTP-TESLA itself applies TESLA to the SRTP protocol and as such 485 the processing guidelines of TESLA need to be followed. 487 5.1. Man-in-the-Middle (MitM) Attack 489 Threat: 491 The exchange of security related parameters and algorithms without 492 mutual authentication of the two peers can allow an adversary to 493 perform a man-in-the-middle attack. The mechanisms described in 494 this document do not itself provide such an authentication and 495 integrity protection. 497 Countermeasures: 499 Throughout the document it is assumed that the parameter exchange 500 is secured using another protocol, i.e., the exchange parameters 501 and algorithms are part of a authentication and key exchange 502 protocol, namely MIKEY. Source authentication of group and 503 multicast communication cannot be provided for the data traffic if 504 the prior signaling exchange did not provide facilities to 505 authenticate the source. Using an authentication protocol that 506 does not provide session keys as part of a successful protocol 507 exchange will make it impossible to derive the necessary 508 parameters required by TESLA. MIKEY provides session key 509 establishment. Additionally, the exchange of parameters and 510 algorithms MUST be authenticated and integrity protected. The 511 security protection of the parameter exchange needs to provide the 512 same level or a higher level of security. 514 5.2. Downgrading Attack 516 Threat: 518 The exchange of security-related parameters and algorithms is 519 always subject to downgrading whereby an adversary modifies some 520 (or all) of the provided parameters. For example, a few 521 parameters require that a supported hash algorithm is listed. To 522 mount an attack the adversary has to modify the list of provided 523 algorithms and to select the weakest one. 525 Countermeasures: 527 TESLA parameter bootstrapping MUST be integrity protected to 528 prevent modification of the parameters and their values. 529 Moreover, since unmodified parameters from an unknown source are 530 not useful, authentication MUST be provided. This functionality 531 is not provided by mechanisms described in this document. Instead 532 the capabilities of the underlying authentication and key exchange 533 protocol (MIKEY) are reused for this purpose. 535 5.3. Denial of Service Attack 537 Threat: 539 An adversary might want to modify parameters exchange between the 540 communicating entities in order to establish different state 541 information at the respective communication entities. For 542 example, an adversary might want to modify the key disclosure 543 delay or the interval duration in order to disrupt the 544 communication at a later state since the TESLA algorithm assumes 545 that the participating communication entities know the same 546 parameter set. 548 Countermeasures: 550 The exchanged parameters and the parameters and algorithms MUST be 551 integrity protected to allow the recipient to detect whether an 552 adversary attempted to modify the exchanged information. 553 Authentication and key exchange algorithms provided by MIKEY offer 554 this protection. 556 5.4. Replay Attack 558 Threat: 560 An adversary who is able to eavesdrop one or multiple protocol 561 exchanges (MIKEY exchanges with the parameters described in this 562 document) might be able to replay the payloads in a later protocol 563 exchange. If the recipients accept the parameters and algorithms 564 (or even the messages that carry these payloads as well then a 565 Denial of Service, downgrading or a man-in-the-middle attack might 566 be the consequence (depending on the entire set of replayed 567 attributes and messages). 569 Countermeasures: 571 In order to prevent replay attacks a freshness guarantee MUST be 572 provided. As such, the TESLA bootstrapping message exchange MUST 573 be unique and fresh and the corresponding authentication and key 574 exchange protocol MUST provide the same properties. In fact, it 575 is essential to derive a unique and fresh session key as part of 576 the authentication and key exchange protocol run that MUST be 577 bound to the protocol session. This includes the exchanged 578 parameters. 580 5.5. Traffic Analysis 582 Threat: 584 An adversary might be able to learn parameters and algorithms, if 585 located along the signaling path. This information can then later 586 be used to mount attacks against the end-to-end multi-media 587 communication. In some high-security and military environments it 588 might even be desirable not to reveal information about the used 589 parameters to make it more difficult to launch an attack. 591 Countermeasures: 593 Confidentity protection can be provided by a subset of the 594 available MIKEY authentication and key exchange protocols, namely 595 those providing public key encryption and symmetric key 596 encryption. The initial hash key, which is also one of the TESLA 597 bootstrapping parameters, does not require confidentiality 598 protection due to the properties of a hash chain. 600 6. IANA Considerations 602 This document requires an IANA registration for the following 603 attributes. The registries are provided by MIKEY [RFC3830]. 605 Prot Type: 607 This attribute specifies the protocol type for the security 608 protocol as described in Section 4.1. 610 Type: 612 Identifies the type of the general payload. The General 613 Extensions Payload was defined to allow possible extensions to 614 MIKEY without the need for defining a completely new payload each 615 time. Section 4.4 describes this attribute in more detail. 617 Following the policies outlined in [RFC3830] the values in the range 618 up to 240 (including 240) for the above attributes are assigned after 619 Expert Review by the MSEC working group or its designated successor. 620 The values in the range from 241 to 255 are reserved for Private Use. 622 IANA needs to add the following attributes and their respective 623 values to an existing registry created in [RFC3830]: 625 Prot Type: 627 Prot Type | Value | Description 628 ----------------------------------------------------- 629 TESLA | 1 | TESLA as a security protocol 631 The value of 1 for the 'Prot Type' must be added to the 'Prot 632 type' registry created by [RFC3830]. 634 Type: 636 Type | Value | Description 637 ------------------------------------------- 638 TESLA I-Key | 2 | TESLA initial key 640 The value of 2 for the 'Type' must be added to the 'Type' registry 641 created by [RFC3830]. The values of 0 and 1 are already 642 registered in [RFC3830]. 644 Furthermore, this document requires IANA to create two new 645 registries: 647 TESLA-PRF: Pseudo-random Function (PRF) used in the TESLA policy: 649 This attribute specifies values for pseudo-random functions used 650 in the the TESLA policy (see Section 4.2). 652 TESLA-MAC: MAC Function used in TESLA: 654 This attribute specifies values for pseudo-random functions used 655 in the the TESLA policy (see Section 4.2). 657 Following the policies outlined in [RFC2434] the values for the 658 TESLA-PRF and the TESLA-MAC registry in the range up to 240 659 (including 240) for the above attributes are assigned after Expert 660 Review by the MSEC working group or its designated successor. The 661 values in the range from 241 to 255 are reserved for Private Use. 663 IANA is requested to add the following values to the TESLA-PRF and 664 the TESLA-MAC registry: 666 TESLA-PRF: 668 PRF Function | Value 669 -------------------------- 670 HMAC-SHA1 | 0 672 TESLA-MAC: 674 MAC Function | Value 675 -------------------------- 676 HMAC-SHA1 | 0 678 7. Acknowledgments 680 The authors would like to thank Mark Baugher and Ran Canetti for the 681 discussions in context of time synchronization. Additionally, we 682 would like to thank Lakshminath Dondeti, Russ Housley and Allison 683 Mankin for their document reviews and for their guidance. 685 8. References 687 8.1. Normative References 689 [I-D.ietf-msec-srtp-tesla] 690 Carrara, E. and M. Baugher, "The Use of TESLA in SRTP", 691 draft-ietf-msec-srtp-tesla-05 (work in progress), 692 October 2005. 694 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 695 Requirement Levels", BCP 14, RFC 2119, March 1997. 697 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 698 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 699 October 1998. 701 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 702 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 703 August 2004. 705 [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. 706 Briscoe, "Timed Efficient Stream Loss-Tolerant 707 Authentication (TESLA): Multicast Source Authentication 708 Transform Introduction", RFC 4082, June 2005. 710 8.2. Informative References 712 [I-D.ietf-msec-mikey-dhhmac] 713 Euchner, M., "HMAC-authenticated Diffie-Hellman for 714 MIKEY", draft-ietf-msec-mikey-dhhmac-11 (work in 715 progress), April 2005. 717 [I-D.ietf-msec-mikey-rsa-r] 718 Ignjatic, D., "An additional mode of key distribution in 719 MIKEY: MIKEY-RSA-R", draft-ietf-msec-mikey-rsa-r-01 (work 720 in progress), October 2005. 722 [PCST] Perrig, A., Canetti, R., Song, D., and D. Tygar, 723 ""Efficient and Secure Source Authentication for 724 Multicast", in Proc. of Network and Distributed System 725 Security Symposium NDSS 2001, pp. 35-46", 2001. 727 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 728 Specification, Implementation", RFC 1305, March 1992. 730 [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description 731 Protocol", RFC 2327, April 1998. 733 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 734 A., Peterson, J., Sparks, R., Handley, M., and E. 735 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 736 June 2002. 738 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 739 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 740 RFC 3711, March 2004. 742 Authors' Addresses 744 Steffen Fries 745 Siemens 746 Otto-Hahn-Ring 6 747 Munich, Bavaria 81739 748 Germany 750 Email: steffen.fries@siemens.com 752 Hannes Tschofenig 753 Siemens 754 Otto-Hahn-Ring 6 755 Munich, Bavaria 81739 756 Germany 758 Email: Hannes.Tschofenig@siemens.com 760 Intellectual Property Statement 762 The IETF takes no position regarding the validity or scope of any 763 Intellectual Property Rights or other rights that might be claimed to 764 pertain to the implementation or use of the technology described in 765 this document or the extent to which any license under such rights 766 might or might not be available; nor does it represent that it has 767 made any independent effort to identify any such rights. Information 768 on the procedures with respect to rights in RFC documents can be 769 found in BCP 78 and BCP 79. 771 Copies of IPR disclosures made to the IETF Secretariat and any 772 assurances of licenses to be made available, or the result of an 773 attempt made to obtain a general license or permission for the use of 774 such proprietary rights by implementers or users of this 775 specification can be obtained from the IETF on-line IPR repository at 776 http://www.ietf.org/ipr. 778 The IETF invites any interested party to bring to its attention any 779 copyrights, patents or patent applications, or other proprietary 780 rights that may cover technology that may be required to implement 781 this standard. Please address the information to the IETF at 782 ietf-ipr@ietf.org. 784 Disclaimer of Validity 786 This document and the information contained herein are provided on an 787 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 788 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 789 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 790 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 791 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 792 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 794 Copyright Statement 796 Copyright (C) The Internet Society (2006). This document is subject 797 to the rights, licenses and restrictions contained in BCP 78, and 798 except as set forth therein, the authors retain all their rights. 800 Acknowledgment 802 Funding for the RFC Editor function is currently provided by the 803 Internet Society.