idnits 2.17.1 draft-salowey-eap-key-deriv-02.txt: -(220): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(348): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. == 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 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 (November 2003) is 7468 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) == Missing Reference: 'IEEE-02-758' is mentioned on line 148, but not defined == Missing Reference: 'TLS' is mentioned on line 325, but not defined == Unused Reference: 'EAP' is defined on line 404, but no explicit reference was found in the text == Unused Reference: 'EAP-Key' is defined on line 434, but no explicit reference was found in the text == Unused Reference: 'RFC2246' is defined on line 449, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 453, but no explicit reference was found in the text == Unused Reference: '80211i' is defined on line 461, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-eap-rfc2284bis-06 -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA1' ** Downref: Normative reference to an Informational RFC: RFC 2104 == Outdated reference: A later version (-22) exists of draft-ietf-eap-keying-00 -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) == Outdated reference: A later version (-04) exists of draft-irtf-aaaarch-handoff-03 Summary: 2 errors (**), 0 flaws (~~), 12 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group 3 INTERNET-DRAFT J. Salowey 4 Document: draft-salowey-eap-key-deriv-02.txt Cisco 5 P. Eronen 6 Nokia 7 Expires: June 2004 November 2003 9 Guidelines for using the EAP Extended Master Session Key (EMSK) 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 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 Abstract 34 The Extensible Authentication Protocol (EAP) provides an extensible 35 interface to various authentication mechanisms. Some EAP methods 36 derive cryptographic material between the EAP peers. EAP defines an 37 Extended Master Session Key (EMSK) that is reserved. This document 38 provides guidelines for using the EMSK to avoid conflicts between 39 applications requiring different key material. This document proposes 40 a mechanism that can be used to derive cryptographically separate 41 keys for more than one cryptographic application, such as protecting 42 subsequent EAP messages, distributing credentials for re- 43 authentication, or handoff mechanisms involving multiple WLAN access 44 points. 46 Table of Contents 48 1. Introduction...................................................2 49 1.1 Cryptographic separation between applications..............3 50 1.2 Cryptographic separation between devices...................3 51 1.4 Motivation.................................................4 52 1.5 Terminology................................................4 53 2. Requirements for EAP methods and applications..................5 54 2.1 Requirements for EAP methods...............................5 55 2.2 Requirements for EAP applications..........................6 56 3. EAP AMSK Key Derivation Framework..............................6 57 3.1 The EAP AMSK Key Derivation Function.......................7 58 3.2 Naming the EMSK............................................8 59 3.3 Obtaining Keys.............................................8 60 4. Security Considerations........................................8 61 4.1 Key strength...............................................8 62 4.2 Cryptographic separation of keys...........................8 63 4.3 Implementation.............................................9 64 5. IANA Considerations............................................9 65 Normative References..............................................9 66 Informative References............................................9 67 Acknowledgments..................................................11 68 Author's Addresses...............................................11 69 Appendix A: Test vectors for KDF.................................11 71 1. Introduction 73 EAP provides a consistent interface for exchanging authentication 74 messages. It is also possible for some EAP methods to generate 75 keying material that will be used to protect some subsequent 76 application (e.g. 802.11i encryption). 78 Typically, an EAP method produces a Master Session Key (MSK), which 79 is sent by the EAP server to the authenticator (e.g. NAS, WLAN access 80 point). The authenticator then uses the MSK to derive Transient 81 Session Keys (TSKs), which are used to protect the actual 82 communication. This derivation is specific to the particular 83 application (e.g. MPPE, 802.11i encryption) and cipher suites used. 84 The derivation is done by the authenticator, so the EAP server does 85 not have to know about the applications and cipher suites. 87 In addition, an EAP method may internally use some keys (Transient 88 EAP Keys or TEKs) to protect its communication. In this document, we 89 are not interested in these keys, only keys that are used after an 90 EAP method has finished and exported some keying material. 92 The current EAP specifications implicitly assume that the keying 93 material produced by EAP will be used for a single application at a 94 single device, however it does define an Extended Master Session Key 95 (EMSK). This document provides guidelines on how to use this key to 96 derive keys for specific applications. 98 1.1 Cryptographic separation between applications 100 If the keying material is used to provide keys for multiple 101 applications, it is desired that the keys will be cryptographically 102 separate. Cryptographic separation means that knowledge of one key 103 does not provide an easy way to determine another key derived from 104 the same key material. This is also known as computationally 105 independent. 107 This separation currently depends on the individual key derivation 108 functions (KDF) and protocols, which take the MSK and possibly via 109 some intermediate steps, produce TSKs. Specifications such as 110 [802.11i] and [MPPE] specify such functions. 112 If multiple applications are used, it is important that these KDFs 113 actually provide separate keys. How should this be done, i.e., who 114 should coordinate that these KDFs actually achieve this? 116 o Not EAP methods. The methods should be independent of the 117 applications their keys will be used for. 119 o Not the application specifications. All applications would have 120 to know what other current and future applications could be used 121 together. 123 This document provides guidelines for a mechanism, which can be used 124 with existing and new EAP methods and applications to provide 125 cryptographic separation between applications. 127 1.2 Cryptographic separation between devices 129 A related issue is that the keys could be used by separate devices. 130 In this case, it is desirable that their knowledge is 131 cryptographically separate. 133 This implies that some key derivation must be done at the EAP server 134 instead of the authenticator and that authenticator should be sent 135 only keys derived that are derived for it. This means that the EAP 136 server has to know what the keys will be used for, which is a change 137 from the current practice. 139 This document attempts to specify a mechanism that allows the EAP 140 server to derive cryptographically separate keys from the EMSK 142 1.3 Use cases 144 There are several applications for ciphering keys outside of link 145 layer protection as in 802.11 already being defined. This 146 specification could derive keys to protect credentials distributed to 147 an EAP peer in a protected TLV [PRO-TLV]. A recent proposals for 148 802.11 handoff in [I-D.irtf-aaaarch-handoff], [IEEE-02-758],[IEEE-03- 149 084], and [IEEE-03-155] provide examples where cryptographic 150 separation between different devices was required. To derive 151 cryptographically separate keys for different WLAN access points some 152 of the specifications specify the use of the EMSK. 154 1.4 Motivation 156 Cryptographic separation between devices within a single application 157 can be addressed by existing specs, simply by considering the device- 158 specific master keys to be just one kind of TSK. Cryptographic 159 separation between different applications CANNOT be addressed by 160 existing solutions UNLESS we require that the derivation of TSKs is 161 somehow coordinated. This document specifies a way of coordinating 162 these. 164 We want to have a mechanism for deriving independent keys which (1) 165 does not depend on a single EAP method, and (2) allows development of 166 new applications without cumbersome coordination between different 167 application specifications. 169 1.5 Terminology 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 173 document are to be interpreted as described in [RFC2119]. 175 Some of the following terms are taken from RFC 2284bis: 177 EAP Peer 179 The end of the EAP Link that responds to the authenticator. 181 EAP server 183 The entity that terminates the EAP authentication with the peer. 184 In the case where there is no backend authentication server, this 185 term refers to the authenticator. Where the authenticator operates 186 in pass-through, it refers to the backend authentication server. 188 EAP application 190 A consumer of EAP keying material. Examples include link layer 191 encryption such as 802.11i encryption, MPPE, etc. 193 Master Session Key (MSK) 194 Keying material exported by an EAP method. Usually sent to the 195 NAS. 197 Extended Master Session Key (EMSK) 199 Keying material exported by an EAP method for use in deriving keys 200 used by other applications. 202 Transient Session Key (TSK) 204 Session keys used to protect communication in some particular 205 application. They are derived from MSK(0,63) or an AMSK in an 206 application-specific way. 208 Application Master Session Key (AMSK) 210 Keying material derived from the EMSK for a particular application 211 as specified in this document. It is used to derive TSKs for the 212 application in an application specific way. 214 Cryptographic separation 216 Two keys (X and Y) are "cryptographically separate" (or 217 "independent") if an adversary that knows all messages exchanged 218 in the protocol (and other public information) cannot compute X 219 from Y or Y from X without "breaking" some cryptographic 220 assumption. This is also known as �computationally independent.� 222 2. Requirements for EAP methods and applications 224 2.1 Requirements for EAP methods 226 In order for an EAP method to meet the guidelines for EMSK usage it 227 must meet the following requirements. 229 o It must specify how to derive the EMSK 231 o The key material used for the EMSK MUST be independent of the 232 MSK and TEKs. 234 o The EMSK MUST NOT be used for any other purpose than the key 235 derivation described in this document. 237 o The EMSK MUST be secret and not known to someone observing the 238 authentication mechanism protocol exchange. 240 o The EMSK MSUT be maintained within the EAP server. Only keys 241 (AMSKs) derived according to this specification may be exported 242 from the EAP server. 244 o The EMSK MUST be unique for each session. 246 o The EAP mechanism SHOULD provide a way of naming the EMSK. 248 2.2 Requirements for EAP applications 250 In order for an application to meet the guidelines for EMSK usage it 251 must meet the following, 253 o The application MAY use the MSK transmitted to the NAS in any 254 way it chooses. This is required for backward compatibility. New 255 applications following this specification SHOULD NOT use the 256 MSK. If more than one application uses the MSK, then the 257 cryptographic separation is not achieved. Implementations SHOULD 258 prevent such combinations. 260 o The application MUST NOT use the EMSK in any other way except to 261 derive Application Master Session Keys (AMSK) using the key 262 derivation specified in section 3 this document. They MUST NOT 263 use the EMSK directly. 265 o Applications MUST define distinct key labels and application 266 specific data used in the key derivation described in section 3. 268 o Applications MUST define how they use their AMSK to derive TSKs 269 for their use. 271 3. EAP AMSK Key Derivation Framework 273 The EAP EMSK usage guidelines provide a means for generating multiple 274 application-specific master keys (AMSKs). These AMSKs are then used 275 to derive transient session keys (TSKs), which are used as actual 276 ciphering keys. This allows multiple applications to use keys 277 independently derived from the EAP method. 279 The EAP EMSK usage guidelines AMSK key derivation function (KDF) 280 derives an AMSK from the Extended Master Session Key (EMSK) described 281 above, an application key label, optional application data, and 282 output length. 284 AMSK = KDF(EMSK, key label, optional application data, length) 285 The key labels are printable ASCII strings unique for each 286 application (see Section 5 for IANA Considerations). 288 Additional ciphering keys (TSKs) can be derived from the AMSK using 289 an application specific key derivation mechanism. In many cases, this 290 AMSK->TSK derivation can simply split the AMSK to pieces of correct 291 length. In particular, it is not necessary to use a cryptographic 292 one-way function. Note that the length of the AMSK must be specified 293 by the application. 295 3.1 The EAP AMSK Key Derivation Function 297 The EAP key derivation function is taken from the PRF+ key expansion 298 PRF from [IKEv2]. This KDF takes 4 parameters as input: secret, 299 label, application data, and output length. It is only defined for 300 255 iterations so it may produce up to 5100 bytes of key material. 302 For the purposes of this specification the secret is taken as the 303 EMSK, the label is the key label described above concatenated with a 304 NUL byte, the application data is also described above and the output 305 length is two bytes. The application data is optional and may not be 306 used by some applications. The KDF is based on HMAC-SHA1 [RFC2104] 307 [SHA1]. For this specification we have: 309 KDF (K,L,D,O) = T1 | T2 | T3 | T4 | ... 311 where: 312 T1 = prf (K, S | 0x01) 313 T2 = prf (K, T1 | S | 0x02) 314 T3 = prf (K, T2 | S | 0x03) 315 T4 = prf (K, T3 | S | 0x04) 317 prf = HMAC-SHA1 318 K = EMSK 319 L = key label 320 D = application data 321 O = OutputLength (2 bytes) 322 S = L | "\0" | D | O 324 The prf+ construction was chosen because of its simplicity and 325 efficiency over other PRFs such as those used in [TLS]. The 326 motivation for the design of this PRF is described in [SIGMA]. 328 The NUL byte after the key label is used to avoid collisions if one 329 key label is a prefix of another label (e.g. "foobar" and 330 "foobarExtendedV2"). This is considered a simpler solution than 331 requiring a key label assignment policy that prevents prefixes from 332 occurring. 334 3.2 Naming the EMSK 336 The EAP mechanism should provide a name for the context that contains 337 the EMSK key material so it can be referenced if needed. If a name 338 is not provided by the mechanism, then a name may be derived from the 339 EMSK using the KDF defined above: 341 EMSK name = KDF(EMSK, "EAP-EMSK-Key name", "", 128 bits) 343 If the name needs to be represented as a string then it should be 344 converted to a lowercase ASCII representation of the hex values of 345 each byte. 347 352 355 3.3 Obtaining Keys 357 Implementations of EAP frameworks on the EAP-Peer and EAP-Server MUST 358 provide an interface to obtain AMSKs. The implementation MAY 359 restrict which callers can obtain which keys. 361 4. Security Considerations 363 4.1 Key strength 365 The effective key strength of the derived keys will never be greater 366 than the strength of the EMSK (or a master key internal to an EAP 367 mechanism). 369 4.2 Cryptographic separation of keys 371 The intent of the KDF is to derive keys that are cryptographically 372 separate: the compromise of one of the application master keys 373 (AMSKs) should not compromise the security of other AMSKs or the 374 EMSK. It is believed that the KDF chosen provides the desired 375 separation. 377 4.3 Implementation 379 An implementation of an EAP framework SHOULD keep the EMSK internally 380 and only provide an interface to KDF for applications to obtain 381 derived keys. It may also choose to restrict which callers have 382 access to which keys. 384 5. IANA Considerations 386 This specification introduces a new name space for "key labels". Key 387 labels are ASCII strings and are assigned on a first come first 388 served basis. It is RECOMMENDED that a reference to a specification 389 that provides the following information 391 o A description of the application 392 o The key label to be used 393 o How TSKs will be derived from the AMSK and how they will be used 394 o If application specific data is used, what it is and how it is 395 maintained 396 o Where the AMSKs or TSKs will be used and how they are 397 communicated if necessary. 399 The String "EAP-EMSK-Key name" is reserved for key naming in section 400 3.2. 402 Normative References 404 [EAP] 405 Blunk, L., J. Vollbrecht, B. Aboba, J. Carlson, "Extensible 406 Authentication Protocol (EAP)", draft-ietf-eap-rfc2284bis-06, 407 September 2003 (work in progress). 408 [RFC2119] 409 Bradner, S., "Key words for use in RFCs to indicate 410 Requirement Levels", RFC 2119, March 1997. 412 [SHA1] 413 NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995. 414 http://csrc.nist.gov/fips/fip180-1.txt (ascii) 415 http://csrc.nist.gov/fips/fip180-1.ps (postscript) 417 [RFC2104] 418 Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing 419 for Message Authentication", RFC 2104, February 1997. 421 Informative References 423 [IKEv2] 424 C. Kaufman, "Internet Key Exchange (IKEv2) Protocol", , 2003 427 [SIGMA] 428 Krawczyk, H., "SIGMA: the `SIGn-and-MAc' Approach to 429 Authenticated Diffie-Hellman and its Use in the IKE 430 Protocols", in Advances in Cryptography - CRYPTO 2003 431 Proceedings, LNCS 2729, Springer, 2003. Available at: 432 http://www.ee.technion.ac.il/~hugo/sigma.html 434 [EAP-Key] 435 Aboba, B. et. al., "EAP Key Management Framework", draft-ietf- 436 eap-keying-00.txt, October 2003 (work in progress). 438 [PRO-TLV] 439 Salowey, J., "Protected EAP TLV", draft-salowey-eap- 440 protectedtlv-02.txt, January 2003 (work in progress) 442 [IEEE-03-084] 443 Mishra, A., M. Shin, W. Arbaugh, I. Lee, and K. Jang, 444 "Proactive Key Distribution to support fast and secure 445 roaming", IEEE 802.11 Working Group, IEEE-03-84r1-I, 446 http://www.ieee802.org/11/Documents/DocumentHolder/3-084.zip, 447 January 2003. 449 [RFC2246] 450 Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 451 2246, January 1999. 453 [RFC2434] 454 Narten, T., and H. Alvestrand, "Guidelines for Writing an IANA 455 Considerations Section in RFCs", RFC 2434, October 1998. 457 [MPPE] 458 Zorn, G., "Deriving Keys for use with Microsoft-to-Point 459 Encryption (MPPE)", RFC 3079, March 2001. 461 [80211i] 462 Institute of Electrical and Electronics Engineers, "Draft 463 Supplement to STANDARD FOR Telecommunications and 464 Information Exchange between Systems - LAN/MAN Specific 465 Requirements - Part 11: Wireless Medium Access Control 466 (MAC) and physical layer (PHY) specifications: 467 Specification for Enhanced Security", IEEE Draft 802.11I/ 468 D6.1, August 2003. 470 [I-D.irtf-aaaarch-handoff] 471 Arbaugh, W. and B. Aboba, "Experimental Handoff Extension to 472 RADIUS", draft-irtf-aaaarch-handoff-03 (work in progress), 473 October 2003. 475 [IEEE-03-155] 476 Aboba, B., "Fast Handoff Issues", IEEE 802.11 Working Group, 477 IEEE-03-155r0-I, 478 http://www.ieee802.org/11/Documents/DocumentHolder/3-155.zip, 479 March 2003. 481 Acknowledgments 483 This document expands upon ideas from conversations with Bernard 484 Aboba, Jari Arkko, and Henry Haverinen. 486 Author's Addresses 488 Joseph Salowey 489 Cisco Systems 490 2901 3rd Ave 491 Seattle, WA 98121 492 US 493 Phone: +1 206 256 3380 494 Email: jsalowey@cisco.com 496 Pasi Eronen 497 Nokia Research Center 498 P.O. Box 407 499 FIN-00045 Nokia Group 500 Finland 501 Email: pasi.eronen@nokia.com 503 Appendix A: Test vectors for KDF 505