idnits 2.17.1 draft-euchner-mikey-dhhmac-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? ** Bad filename characters: the document name given in the document, 'draft-euchner-mikey-dhhmac-00.txt)', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-euchner-mikey-dhhmac-00.txt)', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-euchner-mikey-dhhmac-00.txt)', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-euchner-mikey-dhhmac-00.txt)', but the file name used is 'draft-euchner-mikey-dhhmac-00' == 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.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 238: '...ion, the initial Diffie-Hellman MAY be...' RFC 2119 keyword, line 239: '...management transaction and thereby MAY...' RFC 2119 keyword, line 243: '...ssing of the TEK SHALL be accomplished...' RFC 2119 keyword, line 246: '...C result A or B' SHALL be conveyed in ...' RFC 2119 keyword, line 259: '...the following data type SHALL be used:...' (7 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 162 has weird spacing: '...uth-key pre-s...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (February 2002) is 8103 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) -- Looks like a reference, but probably isn't: 'SHA1' on line 272 -- Looks like a reference, but probably isn't: 'RFC-2026' on line 425 == Unused Reference: '2' is defined on line 442, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 445, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '2') -- Possible downref: Non-RFC (?) normative reference: ref. '3' Summary: 7 errors (**), 1 flaw (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Euchner 3 Internet Draft Siemens AG 4 Expires: August 2002 5 February 2002 7 HMAC-authenticated Diffie-Hellman for MIKEY 8 (draft-euchner-mikey-dhhmac-00.txt) 10 Status of this memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet-Drafts 23 as reference material or to cite them other than as "work in 24 progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 The distribution of this memo is unlimited. 34 Comments should be sent to the MSEC WG mailing list at 35 msec@securemulticast.org and to the author. 37 Abstract 39 This document describes a key management protocol variant for the 40 multimedia Internet keying (MIKEY). In particular, the classic 41 Diffie-Hellman key agreement protocol is used for key 42 establishment in conjunction with a keyed hash (HMAC-SHA1) for 43 achieving mutual authentication and message integrity of the key 44 management messages exchanged. This MIKEY variant is called the 45 HMAC-authenticated Diffie-Hellmann. It addresses the real-time 46 aspects of multimedia key management in MIKEY. 48 HMAC-authenticated Diffie-Hellman for MIKEY February 2002 50 Table of Contents 52 1. Introduction....................................2 53 1.1. Notational Conventions..........................3 54 1.2. Definitions.....................................4 55 1.3. Abbreviations...................................4 56 2. Scenario........................................4 57 2.1. DH-HMAC Security Protocol.......................5 58 3. DH-HMAC payload formats.........................6 59 3.1. Common header payload...........................6 60 3.2. DH-HMAC data payload............................6 61 3.3. HMAC payload....................................6 62 4. Security Considerations.........................8 63 5. Acknowledgements................................9 64 6. Intellectual Property Rights....................9 65 7. Normative References............................9 66 8. Informative References.........................10 67 9. Author's Address...............................10 68 10. Expiration Date................................10 70 1. Introduction 72 As pointed out in MIKEY (see [1]), secure real-time multimedia 73 applications demand a particular adequate key management scheme that 74 cares for how to securely and efficiently establish dynamic session 75 keys in a conversational multimedia scenario. 77 In general, MIKEY scenarios cover peer-to-peer, simple-one-to-many 78 and small-sized groups. MIKEY in particular, describes three key 79 management schemes for the peer-to-peer case that all finish their 80 task within one round trip: 81 - a symmetric key distribution protocol based upon pre-shared 82 master keys; 84 - a public-key encryption-based key distribution protocol 85 assuming a public-key infrastructure with RSA-based private/public 86 keys and digital certificates; 88 - and a Diffie-Hellman key agreement protocol deploying digital 89 signatures and certificates. 91 All these three key management protocols are designed such that they 92 complete their work within just one round trip. This requires 93 depending on loosely synchronized clocks and deploying timestamps 94 within the key management protocols. 96 However, it is known [4] that each of the three key management 97 schemes has its subtle constraints and limitations: 98 - The symmetric key distribution protocol is simple to 99 implement but does not nicely scale in any larger configuration of 100 potential peer entities due to the need of mutually pre-assigned 101 shared master secrets. 103 HMAC-authenticated Diffie-Hellman for MIKEY February 2002 105 Moreover, the security provided does not achieve the property of 106 perfect forward secrecy; i.e. compromise of the shared master 107 secret would render past and even future session keys susceptible 108 to compromise. 109 Further, the generation of the session key happens just at the 110 initiator. Thus, the responder has to fully trust the initiator on 111 choosing a good and secure session secret; the responder neither 112 is able to participate in the key generation nor to influence that 113 process. This is considered as a specific limitation in less 114 trusted environments. 116 - The public-key encryption scheme depends upon a public-key 117 infrastructure that certifies the private-public keys by issuing 118 and maintaining digital certificates. While such a key management 119 scheme provides full scalability in large networked 120 configurations, public-key infrastructures are still not widely 121 available and in general, implementations are significantly more 122 complex. 123 Further additional round trips might be necessary for each side in 124 order to ascertain verification of the digital certificates. 125 Finally, as in the symmetric case, the responder depends 126 completely upon the initiator choosing good and secure session 127 keys. 129 - The third MIKEY key management protocol deploys the Diffie- 130 Hellman key agreement scheme and authenticates the exchange of the 131 Diffie-Hellman half-keys in each direction by using a digital 132 signature upon. As in the previous method, this introduces the 133 dependency upon a public-key infrastructure with its strength on 134 scalability but also the limitations on computational costs in 135 performing the asymmetric long-integer operations and the 136 potential need for additional communication for verification of 137 the digital certificates. 138 However, the Diffie-Hellman key agreement protocol is known for 139 its subtle security strengths in that it is able to provide full 140 perfect secrecy and further have both parties actively involved in 141 session key generation. 143 This document describes a fourth key management scheme for MIKEY that 144 could somehow be seen as a synergetic optimization among the pre- 145 shared key distribution scheme and the Diffie-Hellman key agreement. 146 The idea of that protocol is to apply the Diffie-Hellman key 147 agreement but instead of deploying a digital signature for 148 authenticity of the exchanged keying material rather uses a keyed- 149 hash upon using symmetrically pre-assigned shared secrets. This 150 combination of security mechanisms is called the HMAC-authenticated 151 Diffie-Hellman key agreement for MIKEY (DH-HMAC). 153 1.1. Notational Conventions 154 HMAC-authenticated Diffie-Hellman for MIKEY February 2002 156 The key word "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 158 this document are to be interpreted as described in RFC-2119. 160 1.2. Definitions 162 auth-key pre-shared authentication key 163 IDa, IDb Identity of sender and receiver 164 k_p common Diffie-Hellman shared secret 165 T timestamp 166 x, y secret, random value 168 1.3. Abbreviations 170 DH Diffie-Hellman 171 DH-HMAC HMAC-authenticated Diffie-Hellman 172 HMAC keyed Hash Message Authentication 173 HMAC-SHA1 HMAC using SHA1 as hash function 174 MIKEY Multimedia Internet KEYing 175 PMK Pre-Master Key 176 RSA Rivest, Shamir and Adleman 177 TEK Traffic Encryption Key 179 2. Scenario 181 The HMAC-authenticated Diffie-Hellman key agreement protocol (DH- 182 HMAC) for MIKEY addresses the same scenarios and scope as the other 183 three key management schemes in MIKEY address. 185 DH-HMAC is applicable in a small-sized, peer-to-peer group where no 186 access to a public-key infrastructure can be assumed available. 187 Rather, pre-shared master secrets are available among the entities in 188 such a small-sized group. 190 In a small-sized group, it is assumed that each client will be 191 setting up a session key for its outgoing links with its peer using 192 the DH-MAC key agreement protocol. 194 As is the case for the other three MIKEY key management protocol, 195 DH-HMAC assumes loosely synchronized clocks among the entities in the 196 small group. 198 HMAC-authenticated Diffie-Hellman for MIKEY February 2002 200 2.1. DH-HMAC Security Protocol 202 A B 204 I = (IDa) 205 K = g**x || T [|| I] 206 A = HMAC (auth-key,K) 207 K,A I' = (IDb) 208 ----------------------> K' = g**y || T [|| I'] 209 B' = HMAC (auth-key,K') 210 K',B' 211 <---------------------- 213 k_p= g**(xy) k_p=g**(xy) 215 Figure 1: HMAC-authenticated Diffie-Hellman key based exchange, where x 216 and y are randomly chosen respectively by A and B. 218 The key exchange is done according to Figure 1. The initiator 219 chooses a random value x, and sends an HMACed message including 220 g**x and a timestamp to the responder (optionally also including 221 its identity). 223 The group parameters (e.g., the group G) are a set of parameters 224 chosen by the initiator. The responder chooses a random positive 225 integer y, and sends an HMACed message including g**y and the 226 timestamp to the initiator (optionally also providing its 227 identity). 229 Both parties then calculate the PMK, g**(xy). 231 The HMAC authentication is due to provide authentication of the DH 232 half-keys, and is necessary to avoid man-in-the-middle attacks. 234 This approach is the less expensive than digitally signed Diffie- 235 Hellman. It requires first of all, that both sides compute one 236 exponentiation and one HMAC, then one HMAC verification and 237 finally another Diffie-Hellman exponentiation. 238 With off-line pre-computation, the initial Diffie-Hellman MAY be 239 computed before the key management transaction and thereby MAY 240 further reduce the overall round trip delay as well as reduce the 241 risk of denial-of-service attacks. 243 Processing of the TEK SHALL be accomplished as described in MIKEY 244 chapter 4. 246 The computed HMAC result A or B' SHALL be conveyed in the DH-HMAC 247 payload field of the MIKEY payload as specified in chapter 5 of 248 MIKEY. 250 HMAC-authenticated Diffie-Hellman for MIKEY February 2002 252 3. DH-HMAC payload formats 254 This section specifies the payload formats and data type values for 255 DH-HMAC. 257 3.1. Common header payload 259 For DH-HMAC the following data type SHALL be used: 261 Data type | Value | Comment 262 -------------------------------------- 263 DHHMAC init | 7 | Initiator's DH-HMAC exchange message 264 DHMHAC resp | 8 | Responder's DH-HMAC exchange message 266 The Error payload data type SHALL be applied by the responder in 267 case of a decoding error or of a failed HMAC authentication 268 verification. 270 Hash func | Value | Comments 271 -------------------------------------------------------- 272 SHA-1 | 0 | Mandatory, Default (see [SHA1]) 273 SHA-1-96 | 5 | Optional, SHA1 truncated to the 96 274 leftmost bits of SHA-1 result when represented in network byte 275 order. 277 SHA-1 is the default hash function that MUST be implemented as 278 part of the DH-HMAC. The length of the HMAC result is 160 bits. 279 SHA-1-96 produces a slightly shorter HMAC result where the SHA-1 280 result SHALL be truncated to the 96 leftmost bits when represented 281 in network byte order. This will save some bandwidth. 283 3.2. DH-HMAC data payload 285 There is no separate payload defined for DH-HMAC. Rather, the DH 286 payload data as defined in MIKEY Appendix A.4 SHALL be used. 288 3.3. HMAC payload 290 The HMAC payload carries the computed HMAC value upon the DH-MAC 291 message and corresponding payload data. The HMAC MUST always be 292 the last payload in the DH-HMAC exchange messages. 294 1 2 3 295 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 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 ~ HMAC ~ 298 ! ! 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 HMAC-authenticated Diffie-Hellman for MIKEY February 2002 302 * HMAC: The computed HMAC upon the entire message. The hashing 303 function within HMAC shall be used as indicated by the hash func value 304 (0 or 5). 306 Appendix B. - Payload usage summary 308 This section describes the relationship of DH-HMAC messages and 309 the MIKEY payload types. 311 Depending on the type of message, different payloads MUST and MAY 312 be included. There are six distinct types of messages: 314 * Pre-shared key transport message 316 * Public key transport message 318 * Verification message (for either pre-shared key or public 319 key) 321 * DH exchange message (bi-directional) 323 * DH-HMAC exchange message (bi-directional) 325 * Error message 327 | Message Type 328 Payload type | PS | PK | DH | DH-HMAC | Ver | Error 329 ----------------------------------------------------------- 330 PS data | M - - - - - 331 PK data | - M* - - - - 332 DH data | - - M M - - 333 Ver msg | - - - - M - 334 Error | - - - - - M 335 Timestamp | M M M O - O 336 ID | O O O O O O 337 Signature | - O M - - - 338 HMAC | - - - M - - 339 Certificate | - O O - - - 340 Cert hash | - O O - - - 341 n_start | O O O O - - 342 n_end | O O O O - - 343 SPI | O O O O - - 344 SP | O O O O - O 346 When a payload is not included, the default values for the 347 information carried by it SHALL be used (when applicable). The 348 following table summarizes what messages may be included in a 349 specific message. 351 HMAC-authenticated Diffie-Hellman for MIKEY February 2002 353 4. Security Considerations 355 This document addresses key management security issues throughout. 356 For a comprehensive explanation of security considerations, please 357 refer to MIKEY section 10. In addition to that, the following 358 security considerations apply in particular to this document: 360 Other than the MIKEY pre-shared and public-key based key distribution 361 protocols, the Diffie-Hellman key agreement protocol features a 362 security property called perfect forward secrecy. That is, that even 363 if the long-term master would be compromised at some point in time, 364 this would not render past session keys compromised. 366 Further, Diffie-Hellman key management protocol is not a strict key 367 distribution protocol per se. Actually, both parties involved in the 368 protocol exchange are able to equally contribute to the common 369 Diffie-Hellman master session key. This reduces the risk of either 370 party cheating or unintentionally generating a weak session key. In 371 order for Diffie-Hellman key agreement to be secure, each party shall 372 generate its x or y values using a strong, unpredictable pseudo- 373 random generator. Further these values x or y shall be kept private. 374 It is recommended that these secret values be destroyed once the 375 common Diffie-Hellman shared secret key has been established. 377 For the sake of improved performance and reduced round trip delay 378 either party may off-line pre-compute its public Diffie-Hellman half- 379 key. 381 As such, DH-HMAC but also digitally signed DH provides a far superior 382 security level over the pre-shared or public-key based key 383 distribution protocol in that respect. 385 This document describes the HMAC-authenticated Diffie-Hellman key 386 agreement protocol that completely avoids digital signatures and the 387 associated public-key infrastructure as would be necessary for the 388 X.509 RSA public-key based key distribution protocol or the digitally 389 signed Diffie-Hellman key agreement protocol as described in MIKEY. 390 Public-key infrastructures may not always be available in certain 391 environments nor may they be deemed adequate for real-time multimedia 392 applications when taking additional steps for certificate validation 393 and certificate revocation methods with additional round-trips into 394 account. 396 The HMAC computation corroborates for authentication and message 397 integrity of the exchanged Diffie-Hellman half-keys and associated 398 messages. The authentication is absolute necessary in order to avoid 399 man-in-the-middle attacks on the exchanged messages in transit. 401 HMAC-authenticated Diffie-Hellman for MIKEY February 2002 403 Using HMAC in conjunction with a strong one-way hash function such as 404 SHA1 may be achieved more efficiently in software than expensive 405 public-key operations. This yields a particular performance benefit 406 of DH-HMAC over signed DH or the public-key encryption protocol. 408 DH-HMAC optionally features a variant where the HMAC-SHA-1 result is 409 truncated to 96-bit instead of 160 bits. It is believed that although 410 the truncated HMAC appears significantly shorter, the security 411 provided would not suffer; it appears even reasonable that the 412 shorter HMAC could provide increased security against known-plaintext 413 crypt-analysis, see RFC 2104 for more details. In any way, truncated 414 DH-HMAC is able to reduce the bandwidth during Diffie-Hellman key 415 agreement and yield better round trip delay on low-bandwidth links. 416 If very high security level is desired for long-term secrecy of the 417 negotiated Diffie-Hellman shared secret, longer hash values may be 418 deployed such as SHA256, SHA384 or SHA512 provide, possibly in 419 conjunction with stronger Diffie-Hellman groups. 421 5. Acknowledgements 423 6. Intellectual Property Rights 425 This proposal is in full conformity with [RFC-2026]. 427 Siemens may have patent rights on technology described in this 428 document which employees of Siemens contribute for use in IETF 429 standards discussions. In relation to any IETF standard 430 incorporating any such technology, Siemens hereby agrees to 431 license on fair, reasonable and non-discriminatory terms, based on 432 reciprocity, any patent claims it owns covering such technology, 433 to the extent such technology is essential to comply with such 434 standard. 436 7. Normative References 438 [1] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Norrman; 439 "MIKEY:Multimedia Internet KEYing", Internet Draft, Work in Progress 440 (MSEC WG) 442 [2] H. Krawczyk, M. Bellare, R. Canetti; "HMAC: Keyed-Hashing for 443 Message Authentication", RFC 2104, February 1997. 445 [3] NIST, FIBS-PUB 180-1, "Secure Hash Standard", April 1995, 446 http://csrc.nist.gov/fips/fip180-1.ps 447 HMAC-authenticated Diffie-Hellman for MIKEY February 2002 449 8. Informative References 451 [4] A.J. Menezes, P v. Oorschot, S. Vanstone: "Applied Cryptography", 452 CRC Press, 1996 454 9. Author's Address 456 Please address all comments to: 458 Martin Euchner Siemens AG 459 Email: martin.euchner@icn.siemens.de ICN M SR 3 460 Phone: +49 89 722 55790 Hofmannstr. 51 461 Fax: +49 89 722 47713 81359 Munich, Germany 463 10. Expiration Date 465 This Internet Draft expires on 30 August 2002.