idnits 2.17.1 draft-krawczyk-hkdf-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (January 25, 2010) is 5205 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4306 (ref. 'IKEv2') (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 2898 (ref. 'PKCS5') (Obsoleted by RFC 8018) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Krawczyk 3 Internet-Draft IBM Research 4 Intended status: Informational P. Eronen 5 Expires: July 29, 2010 Nokia 6 January 25, 2010 8 HMAC-based Extract-and-Expand Key Derivation Function (HKDF) 9 draft-krawczyk-hkdf-01.txt 11 Abstract 13 This document specifies a simple HMAC-based key derivation function 14 (HKDF) which can be used as a building block in various protocols and 15 applications. The KDF is intended to support a wide range of 16 applications and requirements, and is conservative in its use of 17 cryptographic hash functions. 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on July 29, 2010. 42 Copyright Notice 44 Copyright (c) 2010 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the BSD License. 57 1. Introduction 59 A key derivation function (KDF) is a basic and essential component of 60 cryptographic systems. Its goal is to take some source of initial 61 keying material and derive from it one or more cryptographically 62 strong secret keys. 64 This document specifies a simple HMAC-based [HMAC] KDF, named HKDF, 65 which can be used as a building block in various protocols and 66 applications, and is already used in several IETF protocols, 67 including [IKEv2], [PANA], and [EAP-AKA]. The purpose is to document 68 this KDF in a general way to facilitate adoption in future protocols 69 and applications, and to discourage the proliferation of multiple KDF 70 mechanisms. It is not intended as a call to change existing 71 protocols. 73 HKDF follows the "extract-then-expand" paradigm where the KDF 74 logically consists of two modules. The first stage takes the input 75 keying material and "extracts" from it a fixed-length pseudorandom 76 key K. The second stage "expands" the key K into several additional 77 pseudorandom keys (the output of the KDF). 79 In many applications, the input keying material is not necessarily 80 distributed uniformly, and the attacker may have some partial 81 knowledge about it (for example, a Diffie-Hellman value computed by a 82 key exchange protocol) or even partial control of it (as in some 83 entropy-gathering applications). Thus, the goal of the "extract" 84 stage is to "concentrate" the possibly dispersed entropy of the input 85 keying material into a short, but cryptographically strong, 86 pseudorandom key. In some applications, the input may already be a 87 good pseudorandom key; in these cases, the "extract" stage is not 88 necessary, and the "expand" part can be used alone. 90 The second stage "expands" the pseudorandom key to the desired 91 length; the number and lengths of the output keys depend on the 92 specific cryptographic algorithms for which the keys are needed. 94 Note that some existing KDF specifications, such as NIST Special 95 Publication 800-56A [800-56A], NIST Special Publication 800-108 97 [800-108] and IEEE Standard 1363a-2004 [1363a], either only consider 98 the second stage (expanding a pseudorandom key), or do not explicitly 99 differentiate between the "extract" and "expand" stages, often 100 resulting in design shortcomings. The goal of this specification is 101 to accommodate a wide range of KDF requirements while minimizing the 102 assumptions about the underlying hash function. The "extract-then- 103 expand" paradigm supports well this goal (see [HKDF-paper] for more 104 information about the design rationale). 106 2. HMAC-based Key Derivation Function (HKDF) 108 2.1. Notation 110 HMAC-Hash denotes the HMAC function [HMAC] instantiated with hash 111 function 'Hash'. HMAC has always two arguments: the first is a key 112 and the second an input (or message). When the message is composed 113 of several elements we use concatenation (denoted |) in the second 114 argument; for example, HMAC(K, elem1 | elem2 | elem3). 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in [KEYWORDS]. 120 2.2. Step 1: Extract 122 PRK = HKDF-Extract(salt, IKM) 124 Options: 125 Hash a hash function; HashLen denotes the length of the 126 hash function output in octets 127 Inputs: 128 salt optional salt value (a non-secret random value); 129 if not provided, it is set to a string of HashLen zeros. 130 IKM input keying material 131 Output: 132 PRK a pseudo-random key (of HashLen octets) 134 The output PRK is calculated as follows: 136 PRK = HMAC-Hash(salt, IKM) 138 2.3. Step 2: Expand 140 OKM = HKDF-Expand(PRK, info, L) 142 Options: 143 Hash a hash function; HashLen denotes the length of the 144 hash function output in octets 145 Inputs: 146 PRK a pseudo-random key of at least HashLen octets 147 (usually, the output from the Extract step) 148 info optional context and application specific information 149 (can be a zero-length string) 150 L length of output keying material in octets 151 (<= 255*HashLen) 152 Output: 153 OKM output keying material (of L octets) 155 The output OKM is calculated as follows: 157 N = ceil(L/HashLen) 158 T = T(1) | T(2) | T(3) | ... | T(N) 159 OKM = first L octets of T 161 where: 162 T(0) = empty string (zero length) 163 T(1) = HMAC-Hash(PRK, T(0) | info | 0x01) 164 T(2) = HMAC-Hash(PRK, T(1) | info | 0x02) 165 T(3) = HMAC-Hash(PRK, T(2) | info | 0x03) 166 ... 168 (where the constant concatenated to the end of each T(n) is a 169 single octet.) 171 3. Notes to HKDF Users 173 This section contains a set of guiding principles regarding the use 174 of HKDF. A much more extensive account of such principles and design 175 rationale can be found in [HKDF-paper]. 177 3.1. To Salt or not to Salt 179 HKDF is defined to operate with and without random salt. This is 180 done to accommodate applications where a salt value is not available. 181 We stress, however, that the use of salt adds significantly to the 182 strength of HKDF, ensuring independence between different uses of the 183 hash function, supporting "source-independent" extraction, and 184 strengthening the analytical results that back the HKDF design. 186 Random salt differs fundamentally from the initial keying material in 187 two ways: it is non-secret and can be re-used. As such, salt values 188 are available to many applications. For example, a PRNG that 189 continuously produces outputs by applying HKDF to renewable pools of 190 entropy (e.g., sampled system events) can fix a salt value and use it 191 for multiple applications of HKDF without having to protect the 192 secrecy of the salt. In a different application domain, a key 193 agreement protocol deriving cryptographic keys from a Diffie-Hellman 194 exchange can derive a salt value from public nonces exchanged and 195 authenticated between communicating parties as part of the key 196 agreement (this is the approach taken in [IKEv2]). 198 Ideally, the salt value is a random (or pseudorandom) string of the 199 length HashLen. Yet, even a salt value of less quality (shorter in 200 size or with limited entropy) may still make a significant 201 contribution to the security of the output keying material; designers 202 of applications are therefore encouraged to provide salt values to 203 HKDF if such values can be obtained by the application. 205 It is worth noting that, while not the typical case, some 206 applications may even have a secret salt value available for use; in 207 such a case, HKDF provides an even stronger security guarantee. An 208 example of such application is IKEv1 in its "public-key encryption 209 mode" or with a pre-shared secret where the "salt" to the extractor 210 is a secret key. 212 3.2. The 'info' Input to HKDF 214 While the 'info' value is optional in the definition of HKDF, it is 215 often of great importance in applications. Its main objective is to 216 bind the derived key material to application- and context-specific 217 information. For example, info may contain a protocol number, 218 algorithm identifiers, user identities, etc. In particular, it may 219 prevent the derivation of the same keying material for different 220 contexts (when the same input key material is used in such different 221 contexts). It may also accommodate additional inputs to the key 222 expansion part if so desired (e.g., an application may want to bind 223 the key material to its length L, thus making L part of the 'info' 224 field). There is one technical requirement from 'info': it should be 225 independent of the input key material value IKM. 227 3.3. To Skip or not to Skip 229 In some applications, the input key material IKM may already be 230 present as a cryptographically strong key (for example, this is the 231 case in TLS, with RSA, where keys are derived from the master secret 232 which in itself is a pseudorandom string). In this case, one can 233 skip the extract part and use IKM directly to key HMAC in the expand 234 step. On the other hand, applications may still use the extract part 235 for the sake of compatibility with the general case. In particular, 236 if IKM is random (or pseudorandom) but longer than an HMAC key, the 237 extract step can serve to output a suitable HMAC key (in the case of 238 HMAC this shortening via the extractor is not strictly necessary 239 since HMAC is defined to work with long keys too). Note, however, 240 that if the IKM is a Diffie-Hellman value, as in the case of TLS with 241 DH, then the extract part SHOULD NOT be skipped. Doing so would 242 result in using the Diffie-Hellman value g^{xy} itself (which is NOT 243 a uniformly random or pseudorandom string) as the key PRK for HMAC. 244 Instead, HKDF should apply the extractor step to g^{xy} (preferably 245 with a salt value) and use the resultant PRK as a key to HMAC in the 246 expansion part. 248 In the case that the amount of required key bits, L, is no more than 249 HashLen, one could use PRK directly as the OKM. This, however, is 250 NOT RECOMMENDED, especially that it would omit the use of 'info' as 251 part of the derivation process (and adding 'info' as an input to the 252 extract step is not advisable -- see [HKDF-paper]). 254 3.4. The Role of Independence 256 The analysis of key derivation functions assumes that the input 257 keying material (IKM) comes from some source modeled as a probability 258 distribution over bit streams of a certain length (e.g., streams 259 produced by an entropy pool, values derived from Diffie-Hellman 260 exponents chosen at random, etc.); each instance of IKM is a sample 261 from that distribution. A major goal of key derivation functions is 262 to ensure that when applying the KDF to any two values IKM and IKM' 263 sampled from the (same) source distribution, the resultant keys OKM 264 and OKM' are essentially independent of each other (in a statistical 265 or computational sense). To achieve this goal it is important that 266 inputs to KDF are selected from appropriate input distributions and 267 also that inputs are chosen independent of each other (technically, 268 it is necessary that each sample will have sufficient entropy even 269 when conditioned on other inputs to KDF). 271 Independence is also an important aspect of the salt value provided 272 to a KDF. While there is no need to keep the salt secret, and the 273 same salt value can be used with multiple IKM values, it is assumed 274 that salt values are independent of the input keying material. In 275 particular, an application needs to make sure that salt values are 276 not chosen or manipulated by an attacker. As an example, consider 277 the case (as in IKE) where the salt is derived from nonces supplied 278 by the parties during a key exchange protocol. Before the protocol 279 can use such salt to derive keys, it needs to make sure that these 280 nonces are authenticated as coming from the legitimate parties rather 281 than selected by the attacker (in IKE, for example this 282 authentication is an integral part of the authenticated Diffie- 283 Hellman exchange). 285 4. Applications of HKDF 287 HKDF is intended for use in a wide variety of KDF applications. 288 These include the building of pseudorandom generators from imperfect 289 sources of randomness (such as a physical RNG); the generation of 290 pseudo-randomness out of weak sources of randomness such as entropy 291 collected from system events, user's keystrokes, etc.; the derivation 292 of cryptographic keys from a shared Diffie-Hellman value in a key 293 agreement protocol; derivation of symmetric keys from a hybrid 294 public-key encryption scheme; key derivation for key-wrapping 295 mechanisms; and more. All of these applications can benefit from the 296 simplicity and multi-purpose nature of HKDF, as well as from its 297 analytical foundation. 299 On the other hand, it is anticipated that some applications will not 300 be able to use HKDF "as-is" due to specific operational requirements, 301 or will be able to use it but without the full benefits of the 302 scheme. One significant example is the derivation of cryptographic 303 keys from a source of low entropy, such as a user's password. The 304 extract step in HKDF can concentrate existing entropy but cannot 305 amplify entropy. In the case of password-based KDFs, a main goal is 306 to slow down dictionary attacks using two ingredients: a salt value 307 and the intentional slowing of the key derivation computation. HKDF 308 naturally accommodates the use of salt; however, a slowing down 309 mechanism is not part of this specification. Applications interested 310 in a password-based KDF should consider whether, for example, [PKCS5] 311 meets their needs better than HKDF. 313 5. Security Considerations 315 In spite of the simplicity of HKDF there are many security 316 considerations that have been taken in the design and analysis of 317 this construction. An exposition of all these aspects is beyond the 318 scope of this document. Please refer to [HKDF-paper] for detailed 319 information, including rationale for the design and for the 320 guidelines presented in Section 3. 322 A major effort has been made in the above paper to provide a 323 cryptographic analysis of HKDF as a multi-purpose KDF that exercises 324 much care in the way it utilizes cryptographic hash functions. This 325 is particularly important due to the limited confidence we have in 326 the strength of current hash functions. This analysis, however, does 327 not imply the absolute security of any scheme and it depends heavily 328 on the strength of the underlying hash function and on modeling 329 choices. Yet, it serves as a strong indication of the correct 330 structure of the HKDF design and its advantages over other common KDF 331 schemes. 333 6. IANA Considerations 335 This document has no IANA actions. 337 7. Acknowledgments 339 The authors would like to thank members of the CFRG (Crypto Forum 340 Research Group) list for their useful comments, and to Dan Harkins 341 for providing test vectors. 343 8. References 345 8.1. Normative References 347 [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 348 Hashing for Message Authentication", RFC 2104, 349 February 1997. 351 [KEYWORDS] 352 Bradner, S., "Key words for use in RFCs to Indicate 353 Requirement Levels", RFC 2119, March 1997. 355 [SHS] National Institute of Standards and Technology, "Secure 356 Hash Standard", FIPS PUB 180-3, October 2008. 358 8.2. Informative References 360 [1363a] Institute of Electrical and Electronics Engineers, "IEEE 361 Standard Specifications for Public-Key Cryptography- 362 Amendment 1: Additional Techniques", IEEE Std 1363a-2004, 363 2004. 365 [800-108] National Institute of Standards and Technology, 366 "Recommendation for Key Derivation Using Pseudorandom 367 Functions", NIST Special Publication 800-108, 368 November 2008. 370 [800-56A] National Institute of Standards and Technology, 371 "Recommendation for Pair-Wise Key Establishment Schemes 372 Using Discrete Logarithm Cryptography (Revised)", NIST 373 Special Publication 800-56A, March 2007. 375 [EAP-AKA] Arkko, J., Lehtovirta, V., and P. Eronen, "Improved 376 Extensible Authentication Protocol Method for 3rd 377 Generation Authentication and Key Agreement (EAP-AKA')", 378 RFC 5448, May 2009. 380 [HKDF-paper] 381 Krawczyk, H., "On Extract-then-Expand Key Derivation 382 Functions and an HMAC-based KDF", 383 URL http://www.ee.technion.ac.il/~hugo/kdf/kdf.pdf, 384 March 2008. 386 [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 387 RFC 4306, December 2005. 389 [PANA] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., 390 and A. Yegin, "Protocol for Carrying Authentication for 391 Network Access (PANA)", RFC 5191, December 2008. 393 [PKCS5] Kaliski, B., "PKCS #5: Password-Based Cryptography 394 Specification Version 2.0", RFC 2898, September 2000. 396 Appendix A. Test Vectors 398 This appendix provides test vectors for SHA-256 and SHA-1 hash 399 functions [SHS]. 401 A.1. Test Case 1 403 Basic test case with SHA-256 405 Hash = SHA-256 406 IKM = 0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b (22 octets) 407 salt = 0x000102030405060708090a0b0c (13 octets) 408 info = 0xf0f1f2f3f4f5f6f7f8f9 (10 octets) 409 L = 42 411 PRK = 0x077709362c2e32df0ddc3f0dc47bba63 412 90b6c73bb50f9c3122ec844ad7c2b3e5 (32 octets) 413 OKM = 0x3cb25f25faacd57a90434f64d0362f2a 414 2d2d0a90cf1a5a4c5db02d56ecc4c5bf 415 34007208d5b887185865 (42 octets) 417 A.2. Test Case 2 419 Test with SHA-256 and longer inputs/outputs 421 Hash = SHA-256 422 IKM = 0x000102030405060708090a0b0c0d0e0f 423 101112131415161718191a1b1c1d1e1f 424 202122232425262728292a2b2c2d2e2f 425 303132333435363738393a3b3c3d3e3f 426 404142434445464748494a4b4c4d4e4f (80 octets) 427 salt = 0x606162636465666768696a6b6c6d6e6f 428 707172737475767778797a7b7c7d7e7f 429 808182838485868788898a8b8c8d8e8f 430 909192939495969798999a9b9c9d9e9f 431 a0a1a2a3a4a5a6a7a8a9aaabacadaeaf (80 octets) 432 info = 0xb0b1b2b3b4b5b6b7b8b9babbbcbdbebf 433 c0c1c2c3c4c5c6c7c8c9cacbcccdcecf 434 d0d1d2d3d4d5d6d7d8d9dadbdcdddedf 435 e0e1e2e3e4e5e6e7e8e9eaebecedeeef 436 f0f1f2f3f4f5f6f7f8f9fafbfcfdfeff (80 octets) 437 L = 82 439 PRK = 0x06a6b88c5853361a06104c9ceb35b45c 440 ef760014904671014a193f40c15fc244 (32 octets) 441 OKM = 0xb11e398dc80327a1c8e7f78c596a4934 442 4f012eda2d4efad8a050cc4c19afa97c 443 59045a99cac7827271cb41c65e590e09 444 da3275600c2f09b8367793a9aca3db71 445 cc30c58179ec3e87c14c01d5c1f3434f 446 1d87 (82 octets) 448 A.3. Test Case 3 450 Test with SHA-256 and empty salt/info 452 Hash = SHA-256 453 IKM = 0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b (22 octets) 454 salt = (0 octets) 455 info = (0 octets) 456 L = 42 458 PRK = 0x19ef24a32c717b167f33a91d6f648bdf 459 96596776afdb6377ac434c1c293ccb04 (32 octets) 460 OKM = 0x8da4e775a563c18f715f802a063c5a31 461 b8a11f5c5ee1879ec3454e5f3c738d2d 462 9d201395faa4b61a96c8 (42 octets) 464 A.4. Test Case 4 466 Basic test case with SHA-1 468 Hash = SHA-1 469 IKM = 0x0b0b0b0b0b0b0b0b0b0b0b (11 octets) 470 salt = 0x000102030405060708090a0b0c (13 octets) 471 info = 0xf0f1f2f3f4f5f6f7f8f9 (10 octets) 472 L = 42 474 PRK = 0x9b6c18c432a7bf8f0e71c8eb88f4b30baa2ba243 (20 octets) 475 OKM = 0x085a01ea1b10f36933068b56efa5ad81 476 a4f14b822f5b091568a9cdd4f155fda2 477 c22e422478d305f3f896 (42 octets) 479 A.5. Test Case 5 481 Test with SHA-1 and longer inputs/outputs 483 Hash = SHA-1 484 IKM = 0x000102030405060708090a0b0c0d0e0f 485 101112131415161718191a1b1c1d1e1f 486 202122232425262728292a2b2c2d2e2f 487 303132333435363738393a3b3c3d3e3f 488 404142434445464748494a4b4c4d4e4f (80 octets) 489 salt = 0x606162636465666768696a6b6c6d6e6f 490 707172737475767778797a7b7c7d7e7f 491 808182838485868788898a8b8c8d8e8f 492 909192939495969798999a9b9c9d9e9f 493 a0a1a2a3a4a5a6a7a8a9aaabacadaeaf (80 octets) 494 info = 0xb0b1b2b3b4b5b6b7b8b9babbbcbdbebf 495 c0c1c2c3c4c5c6c7c8c9cacbcccdcecf 496 d0d1d2d3d4d5d6d7d8d9dadbdcdddedf 497 e0e1e2e3e4e5e6e7e8e9eaebecedeeef 498 f0f1f2f3f4f5f6f7f8f9fafbfcfdfeff (80 octets) 499 L = 82 501 PRK = 0x8adae09a2a307059478d309b26c4115a224cfaf6 (20 octets) 502 OKM = 0x0bd770a74d1160f7c9f12cd5912a06eb 503 ff6adcae899d92191fe4305673ba2ffe 504 8fa3f1a4e5ad79f3f334b3b202b2173c 505 486ea37ce3d397ed034c7f9dfeb15c5e 506 927336d0441f4c4300e2cff0d0900b52 507 d3b4 (82 octets) 509 A.6. Test Case 6 511 Test with SHA-1 and empty salt/info 513 Hash = SHA-1 514 IKM = 0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b (22 octets) 515 salt = (0 octets) 516 info = (0 octets) 517 L = 42 519 PRK = 0xda8c8a73c7fa77288ec6f5e7c297786aa0d32d01 (20 octets) 520 OKM = 0x0ac1af7002b3d761d1e55298da9d0506 521 b9ae52057220a306e07b6b87e8df21d0 522 ea00033de03984d34918 (42 octets) 524 Authors' Addresses 526 Hugo Krawczyk 527 IBM Research 528 19 Skyline Drive 529 Hawthorne, NY 10532 530 USA 532 Email: hugo@ee.technion.ac.il 534 Pasi Eronen 535 Nokia Research Center 536 P.O. Box 407 537 FI-00045 Nokia Group 538 Finland 540 Email: pasi.eronen@nokia.com