idnits 2.17.1 draft-fries-msec-bootstrapping-tesla-00.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.a on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 419. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 396. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 403. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 409. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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 uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 16, 2004) is 7125 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) == Outdated reference: A later version (-05) exists of draft-ietf-msec-srtp-tesla-01 == Outdated reference: A later version (-04) exists of draft-ietf-msec-tesla-intro-03 ** Downref: Normative reference to an Informational draft: draft-ietf-msec-tesla-intro (ref. 'I-D.ietf-msec-tesla-intro') == Outdated reference: A later version (-11) exists of draft-ietf-msec-mikey-dhhmac-06 Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 7 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: April 16, 2005 Siemens 5 October 16, 2004 7 Bootstrapping TESLA 8 draft-fries-msec-bootstrapping-tesla-00.txt 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of section 3 of RFC 3667. By submitting this Internet-Draft, each 14 author represents that any applicable patent or other IPR claims of 15 which he or she is aware have been or will be disclosed, and any of 16 which he or she become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 16, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). 41 Abstract 43 With the Timed Efficient Stream Loss-tolerant Authentication protocol 44 (TESLA) a protocol for providing source authentication in multicast 45 scenarios was introduced. A mapping for TESLA to the Secure 46 Real-time Transport Protocol (SRTP) has been published which assumes 47 that some TESLA parameters are made available by out-of-band 48 mechanisms. This document describes payloads for bootstrapping these 49 parameters with the help of the Multimedia Internet KEYing (MIKEY) 50 protocol. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. TESLA Parameter Overview . . . . . . . . . . . . . . . . . . . 3 57 4. Parameter encoding within MIKEY . . . . . . . . . . . . . . . 4 58 4.1 Security Policy payload (SP) . . . . . . . . . . . . . . . 4 59 4.2 TESLA policy . . . . . . . . . . . . . . . . . . . . . . . 6 60 4.3 Key data transport within MIKEY's General Extension 61 Payload . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 63 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 6.1 Normative References . . . . . . . . . . . . . . . . . . . . 9 65 6.2 Informative References . . . . . . . . . . . . . . . . . . . 9 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9 67 Intellectual Property and Copyright Statements . . . . . . . . 11 69 1. Introduction 71 [I-D.ietf-msec-srtp-tesla] describes extensions for SRTP [RFC3711] in 72 order to support TESLA [I-D.ietf-msec-tesla-intro] for source 73 authentication in multicast scenarios. Therefore the cryptographic 74 context needs to be enhanced with a set of TESLA parameters. It is 75 necessary to provide these parameters before the actual multicast 76 session starts. [I-D.ietf-msec-srtp-tesla] does not address the 77 bootstrapping for these parameters. 79 This document details bootstrapping of TESLA using the Multimedia 80 Internet Keying (MIKEY) [RFC3830] protocol. MIKEY defines an 81 authentication and key management framework that can be used for 82 real-time applications (both for peer-to-peer communication and group 83 communication). In particular, [RFC3830] is defined in a way to 84 support SRTP in the first place but is open to enhancements to be 85 used for other purposes too. 87 The three authentication and key exchange protocols defined in 88 [RFC3830] as well as the fourth protocol provided by 89 [I-D.ietf-msec-mikey-dhhmac] may be used to provide also the TESLA 90 parameters. The required TESLA parameters to be exchanged are 91 already described in [I-D.ietf-msec-srtp-tesla], while this document 92 describes their transport within MIKEY. 94 The following security requirements have to be placed on the exchange 95 of TESLA parameters: 96 o Integrity MUST be provided when sending the TESLA parameters, 97 especially for the initial key. 98 o Confidentiallity MAY be provided for the TESLA parameter 100 2. Terminology 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in [RFC2119]. 106 3. TESLA Parameter Overview 108 According to [I-D.ietf-msec-srtp-tesla] the following transform 109 dependent parameters need to be provided for proper TESLA operation: 111 1. An identifier for the PRF, f, implementing the one-way function 112 F(x) in TESLA (to derive the keys in the chain), e.g. to 113 indicate HMAC-SHA1. 115 2. A non-negative integer n_c, determining the length of the F 116 output, i.e. the length of the keys in the chain (that is also 117 the key disclosed in an SRTP packet). 119 3. An identifier for the PRF, f', implementing the one-way function 120 F'(x) in TESLA (to derive the keys for the TESLA MAC, from the 121 keys in the chain), e.g. to indicate HMAC-SHA1. 123 4. A non-negative integer n_f, determining the length of the output 124 of F', i.e. of the key for the TESLA MAC. 126 5. An identifier for the TESLA MAC, that accepts the output of F'(x) 127 as its key, e.g. to indicate HMAC-SHA1. 129 6. A non-negative integer n_m, determining the length of the output 130 of the TESLA MAC. 132 7. The beginning of the session T_0, 134 8. The interval duration T_int (in msec), 136 9. The key disclosure delay d (in number of intervals) 138 10. Non-negative integer n_c, determining the length of the key 139 chain, which is determined based up the expected duration of the 140 stream. 142 11. The initial key of the chain to which the sender has committed 143 himself. 145 Section 6.2 in [I-D.ietf-msec-srtp-tesla] provides information about 146 the default value for the above-listed parameters. 148 4. Parameter encoding within MIKEY 150 As mentioned in Section 3, TESLA parameters need to be transported 151 before actually starting a session. MIKEY currently only defines a 152 payload for transporting the SRTP policy (see Section 6.10 of 153 [RFC3830]). This section describes the enhancement of MIKEY to allow 154 the transport of a TESLA policy and additionally the initial TESLA 155 key. 157 4.1 Security Policy payload (SP) 159 The Security Policy payload defines a set of policies that apply to a 160 specific security protocol. The definition here relies on the 161 security policy payload definition in [RFC3830]. 163 0 1 2 3 164 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 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 ! Next payload ! Policy no ! Prot type ! Policy param ~ 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 ~ length (cont) ! Policy param ~ 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 * Next payload (8 bits): 172 Identifies the payload that is added after 173 this payload. See Section 6.1 of [RFC3830] for 174 more details. 176 * Policy no (8 bits): 177 Each security policy payload must be given a 178 distinct number for the current MIKEY session by the 179 local peer. This number is used to map a cryptographic session 180 to a specific policy (see also Section 6.1.1 of [RFC3830]). 182 * Prot type (8 bits): 183 This value defines the security protocol. 184 A second value needs to be defined as shown below: 186 Prot type | Value | 187 --------------------------- 188 SRTP | 0 | 189 TESLA | 1 | 191 * Policy param length (16 bits): 192 This field defines the total length of the 193 policy parameters for the selected security protocol. 195 * Policy param (variable length): 196 This field defines the policy for the specific 197 security protocol. 199 The Policy param part is built up by a set of Type/Length/Value (TLV) 200 payloads. For each security protocol, a set of possible type/value 201 pairs can be negotiated as defined. 203 0 1 2 3 204 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 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 ! Type ! Length ! Value ~ 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 * Type (8 bits): 210 Specifies the type of the parameter. 212 * Length (8 bits): 213 Specifies the length of the Value field (in bytes). 215 * Value (variable length): 216 Specifies the value of the parameter. 218 4.2 TESLA policy 220 This policy specifies the parameters for TESLA. The types/values 221 that can be negotiated are defined by the following table. The 222 concrete default values are taken from [I-D.ietf-msec-srtp-tesla], 223 but other values may also be used: 225 Type | Meaning | Possible values 226 --------------------------------------------------------------- 227 1 | PRF identifier for f, realising F(x) | see below 228 2 | Length of PRF f output | 160 229 3 | PRF identifier for f', realising F'(x) | see below 230 4 | Length of PRF f' output | 160 231 5 | Identifier for the TESLA MAC | see below 232 6 | Length of TESLA MAC output | 80 (trunkened) 233 7 | Start of session | in bytes 234 8 | Interval duration T_int (in msec) | in bytes 235 9 | Key disclosure delay d | in bytes 236 10| Key chain length (numer of intervals) | in bytes 238 For the PRF realising F(x), a one byte length is sufficient. 239 The currently defined possible values are: 241 TESLA PRF F(x) | Value 242 ----------------------- 243 NULL | 0 244 HMAC-SHA1 | 1 246 For the PRF realising F'(x), a one byte length is enough. 247 The currently defined possible values are: 249 TESLA PRF F'(x) | Value 250 ----------------------- 251 NULL | 0 252 HMAC-SHA1 | 1 254 For the TESLA MAC, a one byte length is enough. 255 The currently defined possible values are: 257 TESLA MAC | Value 258 ----------------------- 259 NULL | 0 260 HMAC-SHA1 | 1 262 4.3 Key data transport within MIKEY's General Extension Payload 264 The General Extensions Payload was defined to allow possible 265 extensions to MIKEY without the need for defining a completely new 266 payload each time. This payload can be used in any MIKEY message and 267 is part of the authenticated/signed data part. 269 0 1 2 3 270 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 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 ! Next payload ! Type ! Length ! 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 ! Data ~ 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 * Next payload (8 bits): 278 Identifies the payload following this payload. 280 * Type (8 bits): 281 Identifies the type of general payload. MIKEY 282 already defines the Values 0 and 1. 283 This document introduces a new value (2). 285 Type | Value | Comments 286 ---------------------------------------------------- 287 Vendor ID | 0 | Vendor specific byte string 288 SDP IDs | 1 | List of SDP key mgmt IDs 289 TESLA I-Key | 2 | TESLA initial key 291 * Length (16 bits): 292 The length in bytes of the Data field. 294 * Data (variable length): 295 The general payload data. 297 5. Security Considerations 299 The security properties of multi-media data in a multicast 300 environment depends on a number of building blocks. 302 SRTP-TESLA [I-D.ietf-msec-srtp-tesla] describes extensions for SRTP 303 [RFC3711] in order to support TESLA [I-D.ietf-msec-tesla-intro] for 304 source authentication in multicast scenarios. As such, security 305 considerations described with TESLA (see [PCST] and 306 [I-D.ietf-msec-tesla-intro]), the TESLA SRTP mapping 307 [I-D.ietf-msec-srtp-tesla] and SRTP [RFC3711] itself are relevant in 308 this context. 310 Furthermore, since this document details bootstrapping of TESLA using 311 the Multimedia Internet Keying (MIKEY) [RFC3830] protocol the 312 security considerations of MIKEY are immediately applicable to this 313 document. 315 As mentioned in Section 1 the TESLA parameters described in Section 3 316 MUST be integrity protected and MAY be confidentiality protected. 317 Integrity protection is necessary to avoid a man-in-the-middle 318 adversary to modify parameters to mount a number of attacks. 319 Confidentity protection, if desired, can be provided by a subset of 320 the available MIKEY authentication and key exchange protocols, namely 321 those providing public key encryption and symmetric key encryption. 322 Without confidentiality protection an adversary might be able to 323 learn the parameters later used to secure the end-to-end multi-media 324 communication (if the adversary is located along the signaling path). 325 This might be undesirable in high-security environments. Please note 326 that the initial hash key, which is also one of the TESLA 327 bootstrapping parameters, does not require confidentiality protection 328 due to the properties of a hash chain. This aspect is described in 329 great detail in the respective TESLA documents since hash chains 330 represent a core concept of TESLA. 332 6. References 334 6.1 Normative References 336 [I-D.ietf-msec-srtp-tesla] 337 Baugher, M., "The Use of TESLA in SRTP", 338 draft-ietf-msec-srtp-tesla-01 (work in progress), July 339 2004. 341 [I-D.ietf-msec-tesla-intro] 342 Perrig, A., Canetti, R., Song, D., Tygar, D. and B. 343 Briscoe, "TESLA: Multicast Source Authentication Transform 344 Introduction", draft-ietf-msec-tesla-intro-03 (work in 345 progress), August 2004. 347 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 348 Requirement Levels", BCP 14, RFC 2119, March 1997. 350 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M. and K. 351 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 352 August 2004. 354 6.2 Informative References 356 [I-D.ietf-msec-mikey-dhhmac] 357 Euchner, M., "HMAC-authenticated Diffie-Hellman for 358 MIKEY", draft-ietf-msec-mikey-dhhmac-06 (work in 359 progress), May 2004. 361 [PCST] Perrig, A., Canetti, R., Song, D. and D. Tygar, 362 ""Efficient and Secure Source Authentication for 363 Multicast", in Proc. of Network and Distributed System 364 Security Symposium NDSS 2001, pp. 35-46", 2001. 366 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E. and K. 367 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 368 RFC 3711, March 2004. 370 Authors' Addresses 372 Steffen Fries 373 Siemens 374 Otto-Hahn-Ring 6 375 Munich, Bayern 81739 376 Germany 378 EMail: steffen.fries@siemens.com 379 Hannes Tschofenig 380 Siemens 381 Otto-Hahn-Ring 6 382 Munich, Bayern 81739 383 Germany 385 EMail: Hannes.Tschofenig@siemens.com 387 Intellectual Property Statement 389 The IETF takes no position regarding the validity or scope of any 390 Intellectual Property Rights or other rights that might be claimed to 391 pertain to the implementation or use of the technology described in 392 this document or the extent to which any license under such rights 393 might or might not be available; nor does it represent that it has 394 made any independent effort to identify any such rights. Information 395 on the procedures with respect to rights in RFC documents can be 396 found in BCP 78 and BCP 79. 398 Copies of IPR disclosures made to the IETF Secretariat and any 399 assurances of licenses to be made available, or the result of an 400 attempt made to obtain a general license or permission for the use of 401 such proprietary rights by implementers or users of this 402 specification can be obtained from the IETF on-line IPR repository at 403 http://www.ietf.org/ipr. 405 The IETF invites any interested party to bring to its attention any 406 copyrights, patents or patent applications, or other proprietary 407 rights that may cover technology that may be required to implement 408 this standard. Please address the information to the IETF at 409 ietf-ipr@ietf.org. 411 Disclaimer of Validity 413 This document and the information contained herein are provided on an 414 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 415 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 416 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 417 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 418 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 419 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 421 Copyright Statement 423 Copyright (C) The Internet Society (2004). This document is subject 424 to the rights, licenses and restrictions contained in BCP 78, and 425 except as set forth therein, the authors retain all their rights. 427 Acknowledgment 429 Funding for the RFC Editor function is currently provided by the 430 Internet Society.