idnits 2.17.00 (12 Aug 2021) /tmp/idnits59401/draft-krawczyk-hkdf-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 (June 17, 2009) is 4720 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) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 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: December 19, 2009 Nokia 6 June 17, 2009 8 HMAC-based Extract-and-Expand Key Derivation Function (HKDF) 9 draft-krawczyk-hkdf-00.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in 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 This Internet-Draft will expire on December 19, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 This document specifies a simple HMAC-based key derivation function 48 (HKDF) which can be used as a building block in various protocols and 49 applications. The KDF is intended to support a wide range of 50 applications and requirements, and is conservative in its use of 51 cryptographic hash functions. 53 1. Introduction 55 A key derivation function (KDF) is a basic and essential component of 56 cryptographic systems. Its goal is to take some source of initial 57 keying material, and derive from it one or more cryptographically 58 strong secret keys. 60 This document specifies a simple HMAC-based [HMAC] KDF, named HKDF, 61 which can be used as a building block in various protocols and 62 applications, and is already used in several IETF protocols, 63 including [IKEv2], [PANA], and [EAP-AKA]. 65 HKDF follows the "extract-then-expand" paradigm where the KDF 66 logically consists of two modules. The first stage takes the input 67 keying material and "extracts" from it a fixed-length pseudorandom 68 key K. The second stage "expands" the key K into several additional 69 pseudorandom keys (the output of the KDF). 71 In many applications, the input keying material is not necessarily 72 distributed uniformly, and the attacker may have some partial 73 knowledge about it (for example, a Diffie-Hellman value computed by a 74 key exchange protocol) or even partial control of it (as in some 75 entropy-gathering applications). Thus, the goal of the "extract" 76 stage is to "concentrate" the possibly dispersed entropy of the input 77 keying material into a short, but cryptographically strong, 78 pseudorandom key. In some applications, the input may already be a 79 good pseudorandom key; in these cases, the "extract" stage is not 80 necessary, and the "expand" part can be used alone. 82 The second stage "expands" the pseudorandom key to the desired 83 length; the number and lengths of the output keys depend on the 84 specific cryptographic algorithms for which the keys are needed. 86 Note that some existing KDF specifications, such as NIST Special 87 Publication 800-56A [800-56A], NIST Special Publication 800-108 88 [800-108] and IEEE Standard 1363a-2004 [1363a], either only consider 89 the second stage (expanding a pseudorandom key), or do not explicitly 90 differentiate between the "extract" and "expand" stages, often 91 resulting in design shortcomings. The goal of this specification is 92 to accommodate a wide range of KDF requirements while minimizing the 93 assumptions about the underlying hash function. The "extract-then- 94 expand" paradigm supports well this goal (see [HKDF-paper] for more 95 information about the design rationale). 97 2. HMAC-based Key Derivation Function (HKDF) 99 2.1. Notation 101 HMAC-Hash denotes the HMAC function [HMAC] instantiated with hash 102 function 'Hash'. HMAC has always two arguments: the first is a key 103 and the second an input (or message). When the message is composed 104 of several elements we use concatenation (denoted |) in the second 105 argument; for example, HMAC(K, elem1 | elem2 | elem3). 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in [KEYWORDS]. 111 2.2. Step 1: Extract 113 PRK = HKDF-Extract(salt, IKM) 115 Options: 116 Hash a hash function; HashLen denotes the length of the 117 hash function output in octets 118 Inputs: 119 salt optional salt value (a non-secret random value); 120 if not provided, it is set to a string of HashLen zeros. 121 IKM input keying material 122 Output: 123 PRK a pseudo-random key (of HashLen octets) 125 The output PRK is calculated as follows: 127 PRK = HMAC-Hash(salt, IKM) 129 2.3. Step 2: Expand 131 OKM = HKDF-Expand(PRK, info, L) 133 Options: 134 Hash a hash function; HashLen denotes the length of the 135 hash function output in octets 136 Inputs: 137 PRK a pseudo-random key of HashLen octets 138 (usually, the output from the Extract step) 139 info optional context and application specific information 140 (can be a zero-length string) 141 L length of output keying material in octets 142 (<= 255*HashLen) 143 Output: 144 OKM output keying material (of L octets) 146 The output OKM is calculated as follows: 148 N = ceil(L/HashLen) 149 T = T(1) | T(2) | T(3) | ... | T(N) 150 OKM = first L octets of T 152 where: 153 T(0) = empty string (zero length) 154 T(1) = HMAC-Hash(PRK, T(0) | info | 0x01) 155 T(2) = HMAC-Hash(PRK, T(1) | info | 0x02) 156 T(3) = HMAC-Hash(PRK, T(2) | info | 0x03) 157 ... 159 (where the constant concatenated to the end of each T(n) is a 160 single octet.) 162 3. Notes to HKDF Users 164 This section contains a set of guiding principles regarding the use 165 of HKDF. A much more extensive account of such principles and design 166 rationale can be found in [HKDF-paper]. 168 3.1. To Salt or not to Salt 170 HKDF is defined to operate with and without random salt. This is 171 done to accommodate applications where a salt value is not available, 172 We stress, however, that the use of salt adds significantly to the 173 strength of HKDF, ensuring independence between different uses of the 174 hash function, supporting "source-independent" extraction, and 175 strengthening the analytical results that back the HKDF design. 177 Random salt differs fundamentally from the initial keying material in 178 two ways: it is non-secret and can be re-used. As such, salt values 179 are available to many applications. For example, a PRNG that 180 continuously produces outputs by applying HKDF to renewable pools of 181 entropy (e.g., sampled system events) can fix a salt value and use it 182 for multiple applications of HKDF without having to protect the 183 secrecy of the salt. In a different application domain, a key 184 agreement protocol deriving cryptographic keys from a Diffie-Hellman 185 exchange can derive a salt value from public nonces exchanged between 186 communicating parties as part of the key agreement (this is the 187 approach taken in [IKEv2]). 189 Ideally, the salt value is a random (or pseudorandom) string of the 190 length HashLen. Yet, even a salt value of less quality (shorter in 191 size or with limited entropy) may still make a significant 192 contribution to the security of the output keying material; designers 193 of applications are therefore encouraged to provide salt values to 194 HKDF if such values can be obtained by the application. 196 It is worth noting that, while not the typical case, some 197 applications may even have a secret salt value available for use; in 198 such a case, HKDF provides an even stronger security guarantee. An 199 example of such application is IKEv1 in its "public-key encryption 200 mode" or with a pre-shared secret where the "salt" to the extractor 201 is a secret key. 203 3.2. The 'info' Input to HKDF 205 While the 'info' value is optional in the definition of HKDF, it is 206 often of great importance in applications. Its main objective is to 207 bind the derived key material to application- and context-specific 208 information. For example, info may contain a protocol number, 209 algorithm identifiers, user identities, etc. In particular, it may 210 prevent the derivation of the same keying material for different 211 contexts (when the same input key material is used in such different 212 contexts). It may also accommodate additional inputs to the key 213 expansion part if so desired (e.g., an application may want to bind 214 the key material to its length L, thus making L part of the 'info' 215 field). There is one technical requirement from 'info': it should be 216 independent of the input key material value IKM. 218 3.3. To Skip or not to Skip 220 In some applications, the input key material IKM may already be 221 present as a cryptographically strong key (for example, this is the 222 case in TLS, with RSA, where keys are derived from the master secret 223 which in itself is a pseudorandom string). In this case, one can 224 skip the extract part and use IKM directly to key HMAC in the expand 225 step. On the other hand, applications may still use the extract part 226 for the sake of compatibility with the general case. In particular, 227 if IKM is random (or pseudorandom) but longer than an HMAC key, the 228 extract step can serve to output a suitable HMAC key (in the case of 229 HMAC this shortening via the extractor is not strictly necessary 230 since HMAC is defined to work with long keys too). Note, however, 231 that if the IKM is a Diffie-Hellman value, as in the case of TLS with 232 DH, then the extract part SHOULD NOT be skipped. Doing so would 233 result in using the Diffie-Hellman value g^{xy} itself (which is NOT 234 a uniformly random or pseudorandom string) as the key PRK for HMAC. 235 Instead, HKDF should apply the extractor step to g^{xy} (preferably 236 with a salt value) and use the resultant PRK as a key to HMAC in the 237 expansion part. 239 In the case that the amount of required key bits, L, is no more than 240 HashLen, one could use PRK directly as the OKM. This, however, is 241 NOT RECOMMENDED, especially that it would omit the use of 'info' as 242 part of the derivation process (and adding 'info' as an input to the 243 extract step is not advisable -- see [HKDF-paper]). 245 3.4. The Role of Independence 247 The analysis of key derivation functions assumes that the input 248 keying material (IKM) comes from some source modeled as a probability 249 distribution over bit streams of a certain length (e.g., streams 250 produced by an entropy pool, values derived from Diffie-Hellman 251 exponents chosen at random, etc.); each instance of IKM is a sample 252 from that distribution. A major goal of key derivation functions is 253 to ensure that when applying the KDF to any two values IKM and IKM' 254 sampled from the (same) source distribution, the resultant keys OKM 255 and OKM' are essentially independent of each other (in a statistical 256 or computational sense). To achieve this goal it is important that 257 inputs to KDF are selected from appropriate input distributions and 258 also that these inputs are chosen independent of each other 259 (technically, it is necessary that each sample will have sufficient 260 entropy even when conditioned on other inputs to KDF). 262 Independence is also an important aspect of the salt value provided 263 to a KDF. While there is no need to keep the salt secret, and the 264 same salt value can be used with multiple IKM values, it is assumed 265 that salt values are independent of the input keying material. In 266 particular, an application needs to make sure that salt values are 267 not chosen or manipulated by an attacker. As an example, consider 268 the case (as in IKE) where the salt is derived from nonces supplied 269 by the parties during a key exchange protocol. Before the protocol 270 can use such salt to derive keys, it needs to make sure that these 271 nonces are authenticated as coming from the legitimate parties rather 272 than selected by the attacker (in IKE, for example this 273 authentication is an integral part of the authenticated Diffie- 274 Hellman exchange). 276 4. Applications of HKDF 278 HKDF is intended for use in a wide variety of KDF applications. 279 These include the building of pseudorandom generators from imperfect 280 sources of randomness (such as a physical RNG); the generation of 281 pseudo-randomness out of weak sources of randomness such as entropy 282 collected from system events, user's keystrokes, etc.; the derivation 283 of cryptographic keys from a shared Diffie-Hellman value in a key 284 agreement protocol; derivation of symmetric keys from a hybrid 285 public-key encryption scheme; key derivation for key-wrapping 286 mechanisms; and more. All of these applications can benefit from the 287 simplicity and multi-purpose nature of HKDF, as well as from its 288 analytical foundation. 290 On the other hand, it is anticipated that some applications will not 291 be able to use HKDF "as-is" due to specific operational requirements, 292 or will be able to use it but without the full benefits of the 293 scheme. One significant example is the derivation of cryptographic 294 keys from a source of low entropy such as a user's password. The 295 extract step in HKDF can concentrate existing entropy but cannot 296 amplify entropy. In the case of password-based KDFs (PBKDF), a main 297 goal is to slow down dictionary attacks using two ingredients: a salt 298 value and the intentional slowing of the key derivation computation. 299 HKDF naturally accommodates the use of salt; however, slowing down 300 computation is not part of its specification (obviously, this would 301 be a wasteful design for most KDF applications). Therefore, PBKDF 302 applications interested in adapting HKDF to their setting can either 303 replace the extract step with an intentional slow-down mechanism 304 (e.g., applying repeated hashing) or can use both the extract and 305 expand mechanism of HKDF with a slowing-down mechanism applied after 306 the extract step and before expansion. 308 5. Security Considerations 310 In spite of the simplicity of HKDF there are many security 311 considerations that have been taken in the design and analysis of 312 this construction. An exposition of all these aspects is beyond the 313 scope of this document. Please refer to [HKDF-paper] for detailed 314 information, including rationale for the design and for the 315 guidelines presented in Section 3. 317 A major effort has been made in the above paper to provide a 318 cryptographic analysis of HKDF as a multi-purpose KDF that exercises 319 much care in the way it utilizes cryptographic hash functions. This 320 is particularly important due to the limited confidence we have in 321 the strength of current hash functions. This analysis, however, does 322 not imply the absolute security of any scheme and depends heavily on 323 modeling choices. Yet, it serves as a strong indication of the 324 correct structure of the HKDF design and its advantages over other 325 common KDF schemes. 327 6. IANA Considerations 329 This document has no IANA actions. 331 7. Acknowledgments 333 (To be added.) 335 8. References 337 8.1. Normative References 339 [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 340 Hashing for Message Authentication", RFC 2104, 341 February 1997. 343 [KEYWORDS] 344 Bradner, S., "Key words for use in RFCs to Indicate 345 Requirement Levels", RFC 2119, March 1997. 347 [SHS] National Institute of Standards and Technology, "Secure 348 Hash Standard", FIPS PUB 180-3, October 2008. 350 8.2. Informative References 352 [1363a] Institute of Electrical and Electronics Engineers, "IEEE 353 Standard Specifications for Public-Key Cryptography- 354 Amendment 1: Additional Techniques", IEEE Std 1363a-2004, 355 2004. 357 [800-108] National Institute of Standards and Technology, 358 "Recommendation for Key Derivation Using Pseudorandom 359 Functions", NIST Special Publication 800-108, 360 November 2008. 362 [800-56A] National Institute of Standards and Technology, 363 "Recommendation for Pair-Wise Key Establishment Schemes 364 Using Discrete Logarithm Cryptography", NIST Special 365 Publication 800-56A, March 2006. 367 [EAP-AKA] Arkko, J., Lehtovirta, V., and P. Eronen, "Improved 368 Extensible Authentication Protocol Method for 3rd 369 Generation Authentication and Key Agreement (EAP-AKA')", 370 RFC 5448, May 2009. 372 [HKDF-paper] 373 Krawczyk, H., "On Extract-then-Expand Key Derivation 374 Functions and an HMAC-based KDF", 375 URL http://www.ee.technion.ac.il/~hugo/kdf/kdf.pdf, 376 March 2008. 378 [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 379 RFC 4306, December 2005. 381 [PANA] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., 382 and A. Yegin, "Protocol for Carrying Authentication for 383 Network Access (PANA)", RFC 5191, December 2008. 385 Appendix A. Test Vectors 387 This appendix provides test vectors for SHA-256 and SHA-1 hash 388 functions [SHS]. 390 A.1. Test Case 1 392 Basic test case with SHA-256 394 Hash = SHA-256 395 IKM = 0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b (22 octets) 396 salt = 0x000102030405060708090a0b0c (14 octets) 397 info = 0xf0f1f2f3f4f5f6f7f8f9 (10 octets) 398 L = 42 400 PRK = <...to be added...> (32 octets) 401 OKM = <...to be added...> (42 octets) 403 A.2. Test Case 2 405 Test with SHA-256 and longer inputs/outputs 406 Hash = SHA-256 407 IKM = 0x000102030405060708090a0b0c0d0e0f 408 101112131415161718191a1b1c1d1e1f 409 202122232425262728292a2b2c2d2e2f 410 303132333435363738393a3b3c3d3e3f 411 404142434445464748494a4b4c4d4e4f (80 octets) 412 salt = 0x606162636465666768696a6b6c6d6e6f 413 707172737475767778797a7b7c7d7e7f 414 808182838485868788898a8b8c8d8e8f 415 909192939495969798999a9b9c9d9e9f 416 a0a1a2a3a4a5a6a7a8a9aaabacadaeaf (80 octets) 417 info = 0xb0b1b2b3b4b5b6b7b8b9babbbcbdbebf 418 c0c1c2c3c4c5c6c7c8c9cacbcccdcecf 419 d0d1d2d3d4d5d6d7d8d9dadbdcdddedf 420 e0e1e2e3e4e5e6e7e8e9eaebecedeeef 421 f0f1f2f3f4f5f6f7f8f9fafbfcfdfeff (80 octets) 422 L = 82 424 PRK = <...to be added...> (32 octets) 425 OKM = <...to be added...> (82 octets) 427 A.3. Test Case 3 429 Test with SHA-256 and empty salt/info 431 Hash = SHA-256 432 IKM = 0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b (22 octets) 433 salt = (0 octets) 434 info = (0 octets) 435 L = 42 437 PRK = <...to be added...> (32 octets) 438 OKM = <...to be added...> (42 octets) 440 A.4. Test Case 4 442 Basic test case with SHA-1 444 Hash = SHA-1 445 IKM = 0x0b0b0b0b0b0b0b0b0b0b0b (12 octets) 446 salt = 0x000102030405060708090a0b0c (14 octets) 447 info = 0xf0f1f2f3f4f5f6f7f8f9 (10 octets) 448 L = 42 450 PRK = <...to be added...> (20 octets) 451 OKM = <...to be added...> (42 octets) 453 A.5. Test Case 5 455 Test with SHA-1 and longer inputs/outputs 457 Hash = SHA-1 458 IKM = 0x000102030405060708090a0b0c0d0e0f 459 101112131415161718191a1b1c1d1e1f 460 202122232425262728292a2b2c2d2e2f 461 303132333435363738393a3b3c3d3e3f 462 404142434445464748494a4b4c4d4e4f (80 octets) 463 salt = 0x606162636465666768696a6b6c6d6e6f 464 707172737475767778797a7b7c7d7e7f 465 808182838485868788898a8b8c8d8e8f 466 909192939495969798999a9b9c9d9e9f 467 a0a1a2a3a4a5a6a7a8a9aaabacadaeaf (80 octets) 468 info = 0xb0b1b2b3b4b5b6b7b8b9babbbcbdbebf 469 c0c1c2c3c4c5c6c7c8c9cacbcccdcecf 470 d0d1d2d3d4d5d6d7d8d9dadbdcdddedf 471 e0e1e2e3e4e5e6e7e8e9eaebecedeeef 472 f0f1f2f3f4f5f6f7f8f9fafbfcfdfeff (80 octets) 473 L = 82 475 PRK = <...to be added...> (20 octets) 476 OKM = <...to be added...> (82 octets) 478 A.6. Test Case 6 480 Test with SHA-1 and empty salt/info 482 Hash = SHA-1 483 IKM = 0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b (22 octets) 484 salt = (0 octets) 485 info = (0 octets) 486 L = 42 488 PRK = <...to be added...> (20 octets) 489 OKM = <...to be added...> (42 octets) 491 Appendix B. Design Rationale 493 This sections briefely describes the goals of the design, and 494 rationale behind it. For a more comprehensive treatment, see 495 [HKDF-paper]. 497 (...to be written...) 499 Authors' Addresses 501 Hugo Krawczyk 502 IBM Research 503 19 Skyline Drive 504 Hawthorne, NY 10532 505 USA 507 Email: hugo@ee.technion.ac.il 509 Pasi Eronen 510 Nokia Research Center 511 P.O. Box 407 512 FI-00045 Nokia Group 513 Finland 515 Email: pasi.eronen@nokia.com