idnits 2.17.00 (12 Aug 2021) /tmp/idnits52109/draft-aboba-pppext-key-problem-05.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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? == The page length should not exceed 58 lines per page, but there was 30 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 31 pages 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.) ** There are 4 instances of too long lines in the document, the longest one being 15 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 415 has weird spacing: '... to the opera...' == Line 1259 has weird spacing: '...imed to perta...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (21 December 2002) is 7091 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IEEE802' is mentioned on line 355, but not defined == Missing Reference: 'RFC3162' is mentioned on line 880, but not defined == Missing Reference: 'ECP' is mentioned on line 1035, but not defined == Unused Reference: 'RFC2104' is defined on line 946, but no explicit reference was found in the text == Unused Reference: 'RFC2409' is defined on line 952, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 961, but no explicit reference was found in the text == Unused Reference: 'RFC3079' is defined on line 978, but no explicit reference was found in the text == Unused Reference: 'RFC3394' is defined on line 981, but no explicit reference was found in the text == Unused Reference: 'FIPS197' is defined on line 990, but no explicit reference was found in the text == Unused Reference: 'SHA' is defined on line 993, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-pppext-rfc2284bis-08 -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 2716 (Obsoleted by RFC 5216) == Outdated reference: draft-aboba-radius-rfc2869bis has been published as RFC 3579 == Outdated reference: draft-ietf-aaa-eap has been published as RFC 4072 Summary: 5 errors (**), 0 flaws (~~), 20 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 EAP Working Group Bernard Aboba 3 INTERNET-DRAFT Dan Simon 4 Category: Informational Microsoft 5 6 21 December 2002 8 EAP Keying Framework 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC 2026. 15 Internet-Drafts are working documents of the Internet Engineering Task 16 Force (IETF), its areas, and its working groups. Note that other groups 17 may also distribute working documents as Internet- Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference material 22 or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Copyright Notice 32 Copyright (C) The Internet Society (2002). All Rights Reserved. 34 Abstract 36 This document describes the framework for key derivation by EAP methods 37 and provides guidelines for generation and usage of keys derived by EAP 38 methods requesting publication as an RFC. Algorithms for key derivation 39 or mechanisms for key transport are not specified in this document. 40 Rather, this document provides a framework within which derivation 41 algorithms and transport mechanisms can be discussed and evaluated. 43 Table of Contents 45 1. Introduction .......................................... 3 46 1.1 Requirements language ........................... 4 47 1.2 Terminology ..................................... 4 48 2. EAP architecture overview ............................. 7 49 2.1 Ciphersuite independence ........................ 10 50 3. EAP Exchanges ......................................... 12 51 3.1 Two-party exchange .............................. 12 52 3.2 Three-party exchange ............................ 14 53 3.3 EAP key hierarchy ............................... 17 54 4. Security considerations ............................... 17 55 4.1 Three-party exchange ............................ 17 56 4.2 EAP method requirements ......................... 18 57 4.3 AAA protocol requirements ....................... 19 58 4.4 Ciphersuite requirements ........................ 20 59 5. Normative references .................................. 21 60 6. Informative references ................................ 21 61 Appendix A - Ciphersuite keying requirements ................. 24 62 Appendix B - Example EMK hierarchy ........................... 25 63 Appendix C - Example MSK hierarchy ........................... 27 64 Acknowledgments .............................................. 29 65 Author's Addresses ........................................... 29 66 Intellectual Property Statement .............................. 30 67 Full Copyright Statement ..................................... 30 68 1. Introduction 70 The Extensible Authentication Protocol (EAP), defined in [RFC2284bis], 71 was originally developed to provide extensible authentication for use 72 with PPP [RFC1661]. Since then, new applications of EAP have emerged, 73 including IEEE 802.1X network port authentication [IEEE8021X]. 75 The primary purpose of EAP is to authenticate an EAP Client to an EAP 76 Server, as well as to provide keys for use with a link layer ciphersuite 77 negotiated between an EAP Client and a Network Access Server (NAS). EAP 78 can be deployed in configurations where the EAP Server and NAS are co- 79 located, supporting a two-party exchange; alternatively, it can be 80 deployed in configurations where the EAP Server is located on a separate 81 entity, known as an Authentication Server. In this case, EAP supports a 82 three-party exchange, where the Authentication Server acts as a Key 83 Distribution Center (KDC), and the Authentication Server and NAS 84 communicate using a AAA protocol supporting EAP as well as key wrap. 85 Examples of AAA protocols supporting EAP include RADIUS [RFC2869bis], 86 and Diameter [DiamEAP]; examples of AAA key wrap specifications include 87 [RFC2548] and [DiamCMS]. 89 EAP methods defined in [RFC2284bis] include EAP MD5, as well as One-Time 90 Password (OTP) and Generic Token Card methods. Each of these methods 91 supports one-way authentication only (EAP Client to EAP Server) but not 92 key derivation. Since those methods do not support key derivation and do 93 not provide for mutual authentication, they are only appropriate for use 94 in situations where the link layer can be assumed to be physically 95 secure. Where this is not the case, a session established over the link 96 subsequent to authentication would be subject to hijacking, since 97 without key derivation, it is not possible to tie the initial 98 authentication to subsequent data traffic on a per-packet basis. These 99 limitations can be overcome via negotiation of EAP methods such as EAP 100 TLS [RFC2716] that support mutual authentication, as well as key 101 derivation. 103 In order for EAP methods to provide appropriate keying material for link 104 layer ciphersuites, the keying requirements of the ciphersuites need to 105 be understood and provided for. These requirements are discussed in 106 Appendix A. With the increasing deployment of link layer ciphersuites, 107 particularly with wireless networks, there is a need for a clear 108 specification of what is expected of EAP methods deriving keys, as well 109 as of ciphersuites utilizing keying material provided by EAP methods. 111 An overview of the EAP architecture is provided in Section 2, including 112 in Section 2.1, a discussion of the implications for EAP methods 113 generating keys. Section 3 describes both the two-party (Section 3.1) 114 and the three-party (Section 3.2) exchanges. An introduction to the EAP 115 key hierarchy is provided in Section 3.3. 117 Keying requirements are discussed in Section 4. This includes 118 requirements for the EAP methods themselves (Section 4.1), the AAA 119 protocols (Section 4.2), and the link layer ciphersuites (Section 4.3). 120 Section 5 analyzes the security properties of both the two-way and 121 three-way exchanges. 123 Appendix A provides a summary of the keying requirements of link layer 124 ciphersuites supported on PPP and IEEE 802.11. Appendix B provides an 125 example EAP Master Key (EMK) hierarchy. Appendix C provides an example 126 Master Session Key (MSK) hierarchy. 128 1.1. Requirements language 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in BCP 14 [RFC2119]. 134 1.2. Terminology 136 This document frequently uses the following terms: 138 Client-Server Token (CS-Token) 139 The package within which the MSK is transported between the EAP 140 Server and the EAP Client. The package MUST be integrity 141 protected, authenticated and encrypted, so as to protect the MSK 142 from compromise. In addition to the MSK, the CS-Token MAY include 143 one or more attributes providing information on MSK usage. 144 Attributes may include the NAS layer 2 and layer 3 addresses, MSK 145 lifetime, etc. The format of the CS-Token is defined by the EAP 146 method. Support for the CS-Token is optional and most current EAP 147 methods do not support it, since they derive the MSK as part of the 148 EMK key hierarchy, and thus do not need to transport it separately. 149 However, in the case where an EAP Client needs to handle multiple 150 MSKs, such as when it is connected to multiple NASes 151 simultaneously, or where an Authentication Server is sending MSKs 152 to multiple NASes in order to support fast handoff, use of methods 153 supporting the CS-Token may be desirable. 155 AAA-NAS Token (AN-Token) 156 The package within which the Master Session Keys (MSKs) and one or 157 more AAA attributes is transported between the Authentication 158 Server and NAS. The AAA attributes provide the NAS with information 159 on MSK usage. For example, AAA attributes might include the Client 160 layer 2 address, the NAS layer 2 and layer 3 addresses, MSK 161 lifetime, etc. The format and wrapping of the AN-Token, which is 162 intended to be accessible only to the Authentication Server and 163 NAS, is defined by the AAA key distribution specification. 165 Authentication Server 166 An Authentication Server is an entity that provides an 167 Authentication Service to a Network Access Server (NAS). This 168 service verifies from the credentials provided by the Client, the 169 claim of identity made by the Client. Where an Authentication 170 Server is provided, it acts as the EAP Server, terminating EAP 171 conversation with the EAP Client. In the EAP Keying architecture 172 the Authentication Server acts as a KDC, distributing the Master 173 Session Keys (MSKs) to the EAP Client and NAS. 175 Cryptographic binding 176 The demonstration of the EAP Client to the EAP Server that a single 177 entity has acted as the EAP Client for all methods executed within 178 a sequence or tunnel. Binding MAY also imply that the EAP Server 179 demonstrates to the Client that a single entity has acted as the 180 EAP Server for all methods executed within a sequence or tunnel. If 181 executed correctly, binding serves to mitigate man-in-the-middle 182 vulnerabilities. 184 Cryptographic separation 185 Two keys (x and y) are "cryptographically separate" if an adversary 186 that knows all messages exchanged in the protocol cannot compute x 187 from y or y from x without "breaking" some cryptographic 188 assumption. In particular, this definition allows that the 189 adversary has the knowledge of all nonces sent in cleartext as well 190 as all predictable counter values used in the protocol. Breaking a 191 cryptographic assumption would typically require inverting a one- 192 way function or predicting the outcome of a cryptographic pseudo- 193 random number generator without knowledge of the secret state. In 194 other words, if the keys are cryptographically separate, there is 195 no shortcut to compute x from y or y from x, but the work an 196 adversary must do to perform this computation is equivalent to 197 performing exhaustive search for the secret state value. 199 EAP Master key (EMK) 200 The key derived between the EAP Client and Server during the EAP 201 authentication process. The EMK is unique to the EAP Client and 202 Server, and is not shared with any other parties. 204 Master Session Key (MSK) 205 Keying material provided to the EAP Client and NAS by the AAA 206 Server, acting as a Key Distribution Center (KDC). The MSK is used 207 in derivation of Transient Session Keys for the ciphersuite 208 negotiated between the EAP Client and NAS. So that the MSK is 209 usable with any ciphersuite, it is longer than necessary, and is 210 truncated to fit. 212 Note that an Authentication Server may simultaneously provide the EAP 213 Client with MSKs suitable for use with multiple APs, so as to enable 214 fast handoff. Similarly the AAA Server may send MSKs to multiple APs 215 simultaneously. Note that where the AP supports transport of multiple 216 MSK sets to the EAP Client and NASes, the MSKs MUST be kept 217 cryptographically separate from each other. 219 Network Access Server (NAS) 220 The device that provides access to the network. Where no 221 Authentication Server is present, the NAS acts as the EAP Server, 222 terminating the EAP conversation with the Client. Where an 223 Authentication Server is present, the NAS may act as a pass-through 224 for one or more authentication methods and for non-local users. 226 Pairwise Master Key (PMK) 227 As defined in [RFC2716], the MSK is 192 octets (1536 bits) in 228 length. Octets 0-31 of the MSK are known as the "Peer to 229 Authenticator Encryption Key" or Enc-RECV-Key (reception is defined 230 from the point of view of the EAP Authenticator or NAS). Within 231 IEEE 802.11, the Enc-RECV-Key is also known as the Pairwise Master 232 Key (PMK). IEEE 802.11 ciphersuites such as TKIP, WRAP and CCMP 233 derive their Transient Session Keys (TSKs) solely from the PMK, 234 whereas the WEP ciphersuite, when used with IEEE 802.1X-2002, 235 derives its TSKs from both the Enc-RECV-Key and the Enc-SEND-Key. 236 Octets 32-63 of the MSK are known as the "Authenticator to Peer 237 Encryption Key" or End-SEND-Key. Octets 64-95 are known as the 238 "Peer to Authenticator Authentication Key" or Auth-RECV-Key. 239 Octets 96-127 are known as the "Authenticator to Peer 240 Authentication Key" or Auth-SEND-Key. Octets 128-159 are known as 241 the "Peer to Authenticator IV" or RECV-IV, and Octets 160-191 are 242 known as the "Authenticator to Peer IV", or SEND-IV. 244 Within [IEEE80211i], the Enc-RECV-Key is also known as the Pairwise 245 Master Key (PMK). IEEE 802.11 ciphersuites such as TKIP, WRAP and 246 CCMP derive their Transient Session Keys (TSKs) solely from the 247 PMK, whereas the WEP ciphersuite, when used with IEEE 802.1X-2002, 248 derives its TSKs from both the Enc-RECV-Key and the Enc-SEND-Key. 249 IEEE 802.11 ciphersuites do not utilize the Auth-RECV-Key, Auth- 250 SEND-Key, RECV-IV or SEND-IV, largely because attributes supporting 251 transport of these portions of the MSK were not defined in 252 [RFC2548]. 254 Transient EAP Keys (TEKs) 255 Session keys which are used to establish a protected channel 256 between the EAP Client and Server during the EAP authentication 257 exchange. The TEKs are derived from the EMK, and are appropriate 258 for use with the ciphersuite negotiated between EAP Client and 259 Server as part the EAP authentication exchange. Note that the 260 ciphersuite used to set up the protected channel between the EAP 261 Client and Server during EAP authentication is unrelated to the 262 ciphersuite used to subsequently protect data sent between the EAP 263 Client and NAS. In particular, the TEKs used to protect the EAP 264 exchange MUST be cryptographically separate from TSKs used to 265 protect data. 267 Transient Session Keys (TSKs) 268 Session keys used to protect data which are appropriate for the 269 ciphersuite negotiated between the EAP Client and NAS. The TSKs are 270 derived from the MSK by a process defined by the link layer. In 271 the case of IEEE 802.11, TSK derivation is supported via a 4-way 272 handshake that supports mutual authentication between the EAP 273 Client and NAS. The 4-handshake also confirms mutual possession of 274 the PMK as well as supporting protected ciphersuite negotiation. 276 2. EAP architecture overview 278 EAP authentication involves a Client, NAS and (optionally) an 279 Authentication Server. One of the goals of EAP is to enable development 280 of new authentication methods without requiring deployment of new code 281 on the NAS. While the NAS may implement some methods locally and use 282 those methods to authenticate local users, it may at the same time act 283 as a pass-through for other users and methods. Supporting pass-through 284 of authentication to the Authentication Server enables the NAS to 285 support any authentication method implemented on the Authentication 286 Server and EAP Client, not just locally implemented methods. This 287 implies that the NAS need not implement code for each EAP method 288 required by authenticating Clients. 290 EAP presumes that prior to authentication, the EAP Client has located 291 the NAS, using an out-of-band mechanism. For example, for use with PPP, 292 the Client might be configured with a phone book providing phone numbers 293 for accessing the selected service. For use with IEEE 802.11 wireless 294 LANs, the Client (a Station (STA) in IEEE 802.11 terminology) may locate 295 NAS devices (an Access Point (AP) in IEEE 802.l1 terminology) using the 296 IEEE 802.11 Beacon and Probe Request/Response frames. 298 EAP also assumes that link layer ciphersuite negotiation is handled 299 within the link layer. For example, the EAP Client might be 300 preconfigured with policy indicating the ciphersuite to be used in 301 communicating with a given NAS, or alternatively, the link layer 302 protocol may support ciphersuite negotiation. Within PPP, the 303 ciphersuite is negotiated within the Encryption Control Protocol (ECP), 304 after EAP authentication is completed. Within IEEE 802.11i, the AP 305 capabilities (including ciphersuite) are advertised in the Beacon and 306 Probe Responses, and are verified during a 4-way exchange after EAP 307 authentication has completed. The desired ciphersuite is indicated 308 within the Association/Reassociation Request/Response exchange. 310 Figure 1 illustrates the relationship between the EAP Client, NAS and 311 Authentication Server (EAP Server) for the case where the NAS and 312 Authentication Server are located on separate hosts, and the NAS acts as 313 a pass-through. 315 +-+-+-+-+-+ +-+-+-+-+-+ 316 | | | | 317 | | | | 318 | Cipher- | | Cipher- | 319 | Suite | | Suite | 320 | | | | 321 +-+-+-+-+-+ +-+-+-+-+-+ 322 ^ ^ 323 | | 324 | | 325 | | 326 V V 327 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 328 | |===============| |========| | 329 | | EAP | | | | 330 | |<-------------------------------->| Authent.| 331 | Client | | NAS | | Server | 332 | |===============| |========| | 333 | | Link Layer | | AAA | (EAP | 334 | | (PPP,IEEE 802)| | | Server) | 335 | | | | | | 336 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 337 ^ ^ 338 | | 339 | EAP API | EAP API 340 | | 341 V V 342 +-+-+-+-+-+ +-+-+-+-+-+ 343 | | | | 344 | | | | 345 | EAP | | EAP | 346 | Method | | Method | 347 | | | | 348 +-+-+-+-+-+ +-+-+-+-+-+ 350 Figure 1 - Pass-through relationship between EAP Client, 351 NAS and Authentication Server. 353 In the illustration, EAP is spoken between the Client and NAS, 354 encapsulated within a link layer protocol, such as PPP, defined in 355 [RFC1661] and IEEE 802, defined in [IEEE802]. The NAS then encapsulates 356 EAP within a AAA protocol such as RADIUS [RFC2869bis] or Diameter 357 [DiamEAP], and transports this back and forth to the AAA Server, which 358 acts as an EAP Server. Since the NAS acts as a pass-through, EAP 359 methods reside only on the EAP Client and Server, interfacing to the 360 operating system via an EAP API. 362 +-+-+-+-+-+ +-+-+-+-+-+ 363 | | | | 364 | | | | 365 | Cipher- | | Cipher- | 366 | Suite | | Suite | 367 | | | | 368 +-+-+-+-+-+ +-+-+-+-+-+ 369 ^ ^ 370 | | 371 | | 372 | | 373 V V 374 +-+-+-+-+-+ +-+-+-+-+-+ 375 | | | | 376 | |===============| | 377 | | EAP | | 378 | |<------------->| NAS | 379 | Client | | (EAP | 380 | |===============| Server) | 381 | | Link layer | | 382 | | (PPP,IEEE802) | | 383 | | | | 384 +-+-+-+-+-+ +-+-+-+-+-+ 385 ^ ^ 386 | | 387 | EAP API | EAP API 388 | | 389 V V 390 +-+-+-+-+-+ +-+-+-+-+-+ 391 | | | | 392 | | | | 393 | EAP | | EAP | 394 | Method | | Method | 395 | | | | 396 +-+-+-+-+-+ +-+-+-+-+-+ 398 Figure 2 - Relationship between EAP Client and 399 NAS (acting as an EAP Server) where no 400 Authentication Server is present 402 Once EAP authentication is complete, the EAP Client and NAS pass data 403 between each other, encapsulated within the link layer protocol. In 404 order to protect the data, the Client and NAS may negotiate and 405 subsequently implement a ciphersuite. 407 While pass-through operation is common with EAP, it is optional, so that 408 EAP may also be implemented in situations where no Authentication Server 409 is present. This is illustrated in Figure 2. 411 In Figure 2, EAP is spoken between the Client and NAS, encapsulated 412 within a link layer protocol, such as PPP or IEEE 802. Since the NAS 413 terminates the EAP conversation rather than acting as a pass-through, 414 EAP methods are implemented on the NAS, as well as on the EAP Client, 415 interfacing to the operating system via an EAP API. 417 Once EAP authentication is complete, the EAP Client and NAS pass data, 418 encapsulated within the link layer protocol. In order to protect the 419 data, the Client and NAS may negotiate and subsequently implement a 420 ciphersuite. 422 2.1. Ciphersuite independence 424 Within the EAP authentication model, it is assumed that the ciphersuite 425 is negotiated between the EAP Client and NAS using link layer 426 mechanisms. While EAP methods which derive keys can be used to provide 427 automated keying, the EAP method SHOULD NOT generate ciphersuite- 428 specific keys or even contain ciphersuite-specific code. Since it is 429 the Client and NAS that negotiate and implement the ciphersuite, 430 knowledge of the ciphersusite is restricted to those entities. 432 Within the EAP 3-party model, the Authentication Server is not a party 433 to the ciphersuite negotiation that occurs between the EAP Client and 434 NAS, and neither is the Authentication Server involved in the passing of 435 data between the EAP Client and NAS. Since the Authentication Server is 436 not involved in the handling of data traffic, and may not even be aware 437 of the ciphersuite negotiated between the EAP Client and NAS, it cannot 438 be assumed to implement ciphersuite-specific code. In fact, the 439 Authentication Server cannot even be assumed to have knowledge of the 440 ciphersuites available on the NAS and EAP Client. 442 Since the Authentication Server may not know the ciphersuite negotiated 443 between EAP Client and NAS, it will not necessarily be able to make this 444 information available to a resident EAP method via the EAP APIs. As a 445 result, ciphersuite-specific key generation implemented within an EAP 446 method might not function correctly on every implementation. 448 Similarly, because the NAS is not required to implement any EAP methods, 449 the NAS cannot be assumed to implement code specific to any EAP method. 451 Since operating systems provide EAP APIs in order to remain "EAP-Method 452 Agnostic", EAP APIs cannot be assumed to implement EAP method-specific 453 code either. 455 EAP methods deriving keys MUST support mutual authentication and provide 456 for the derivation of an EAP Master Key (EMK), known only to the EAP 457 Client and Server. EAP methods deriving keys also MUST provide for the 458 distribution of the CS-Token between the AAA Server and EAP Client, and 459 the AN-Token between the AAA server and NAS. The MSK contained within 460 the CS-Token and AN-Tokens is suitable for use with any negotiated 461 ciphersuite, and therefore an EAP method MUST NOT directly use the MSK 462 as a Transient Session Key (TSK). Rather, the TSK(s) are derived from 463 the MSK in a separate step, once the negotiated ciphersuite is known. 465 Drawbacks to utilizing the MSK as a transient session key include: 467 Ciphersuite negotiation 468 Enabling derivation of the TSK(s) in a separate step 469 provides for additional security. For example, the TSK 470 derivation supported within IEEE 802.11i enables the EAP 471 Client and NAS to mutually authenticate and conduct a 472 protected ciphersuite negotiation. If the MSK is used 473 directly as a TSK, then the EAP Client and NAS may not 474 mutually authenticate each other, and a protected 475 ciphersuite negotiation, if it occurs at all, would 476 typically need to be supported within EAP itself. Since 477 the ciphersuite negotiation mechanisms are typically 478 particular to a given link layer, carrying this out 479 within EAP may not be appropriate. 481 Document Revision 482 If an EAP method specifies how to derive transient 483 session keys on a per-ciphersuite basis, the 484 specification will need to be revised each time a new 485 ciphersuite is developed. This would also imply that an 486 Authentication Server supporting an EAP method might not 487 be usable with all NASes supporting EAP, due to lack of 488 support for a new ciphersuite implemented on a NAS. 490 EAP method complexity 491 Requiring the EAP method to include ciphersuite-specific 492 code for transient session key derivation increases the 493 complexity of the EAP method, as well as Client and 494 Authentication Server implementations. 496 Knowledge asymmetry 497 In practice, an EAP method may not have knowledge of the 498 ciphersuite that has been negotiated between the EAP 499 Client and NAS. In PPP, ciphersuite negotiation occurs 500 via the Encryption Control Protocol (ECP), described in 501 [RFC1968]. Since ECP negotiation occurs after 502 authentication, unless an EAP method is utilized that 503 supports ciphersuite negotiation, the Client, NAS and 504 Authentication Server may not be able to anticipate the 505 negotiated ciphersuite and therefore this information 506 cannot be provided to the EAP method. Since ciphersuite 507 negotiation is assumed to occur out-of-band of EAP, there 508 is no need for ciphersuite negotiation within EAP. 510 3. EAP Exchanges 512 EAP supports two modes of exchange: 514 [a] Two-party exchange. The two-party exchange occurs where the EAP 515 Client and NAS act as the endpoints of the EAP conversation, and no 516 Authentication Server is present. Here the NAS implements the EAP 517 method locally, rather than acting as a pass-through. In this mode, 518 the EAP method used between the EAP Client and NAS (EAP Server) 519 derives the EMK, as well as providing for the distribution of the 520 Client-Server token containing the MSK. 522 [b] Three-party exchange. This mode is used where the NAS acts as a 523 pass-through and an Authentication Server (acting as an EAP Server) 524 is present. In this mode, the EAP Server and Client derive the EMK, 525 and the Authentication Server distributes to the CS-Token to the 526 EAP Client and the AN-Token to the NAS. Both the CS-Token and AN- 527 Token contain the embedded MSK. 529 3.1. Two-party exchange 531 Figure 3 illustrates the two-party exchange, where the Client is 532 authenticated locally by the NAS using a locally implemented 533 authentication method. In this case, the EAP Master Key (EMK) is derived 534 on the Client and the NAS, which acts as the EAP Server during the EAP 535 authentication exchange, and the Client-Server token is transported by 536 the NAS to the EAP Client. The Client and NAS then use the MSK 537 contained with the CS-Token to derive the transient session keys used 538 with the selected ciphersuite. It is assumed that ciphersuite 539 negotiation is handled out of band, rather than within EAP. For example, 540 Within an IEEE 802.11 Reliable Secure Network (RSN), the TSK derivation 541 occurs using the RSN 4-way handshake. 543 If the authentication occurs with a method not implemented on the NAS, 544 or involves a non-local user whose credentials the Server is unable to 545 validate, then the NAS functions as a "pass-through". For pass-through 546 authentication methods, instead of implementing the authentication 547 method locally, the NAS delegates the authentication to an 548 Authentication Server. The Authentication Server installs the desired 549 EAP method, typically by interfacing with the operating system via an 550 EAP API, such as that described in [EAPAPI]. 552 In order to allow the Client and Authentication Server to install new 553 EAP methods without requiring an operating system upgrade, operating 554 systems isolate EAP method-specific code within the installed EAP 555 methods, and thus largely operate as pass-through entities with respect 556 to EAP. 558 +-+-+-+-+-+ +-+-+-+-+-+ 559 | | | | 560 | | | | 561 | Cipher- | | Cipher- | 562 | Suite | | Suite | 563 | | | | 564 +-+-+-+-+-+ +-+-+-+-+-+ 565 ^ ^ 566 | | 567 | | 568 V V 569 +-+-+-+-+-+ +-+-+-+-+-+ 570 | | EMK | | 571 | |<=============>| NAS | 572 | Client | | (EAP | 573 | | CS-Token | Server) | 574 | |<==============| | 575 | | | | 576 | | TSK Deriv. | | 577 | |<=============>| | 578 +-+-+-+-+-+ +-+-+-+-+-+ 579 ^ ^ 580 | | 581 | EAP API | EAP API 582 | | 583 V V 584 +-+-+-+-+-+ +-+-+-+-+-+ 585 | | | | 586 | | | | 587 | EAP | | EAP | 588 | Method | | Method | 589 | | | | 590 +-+-+-+-+-+ +-+-+-+-+-+ 592 Figure 3 - Two-party exchange 593 3.2. Three-party exchange 595 Figure 4 illustrates a three-party exchange where the NAS acts as a 596 pass-through. As described in the figure, the EAP conversation "passes 597 through" the NAS on its way between the Client and the Authentication 598 Server (which acts as the EAP Server). 600 +-+-+-+-+-+ +-+-+-+-+-+ 601 | | | | 602 | | | | 603 | Cipher- | | Cipher- | 604 | Suite | | Suite | 605 | | | | 606 +-+-+-+-+-+ +-+-+-+-+-+ 607 ^ ^ 608 | | 609 | | 610 V V 611 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 612 | | | | | | 613 | | EMK | | | | 614 | |<================================>| Auth. | 615 | | | | | Server | 616 | Client | TSK Deriv. | NAS |AN-Token| | 617 | |<=============>| |<=======| (EAP | 618 | | | | | Server) | 619 | | CS-Token | | | | 620 | |<=================================| | 621 | | | | | | 622 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 623 ^ ^ 624 | | 625 | EAP API | EAP API 626 | | 627 V V 628 +-+-+-+-+-+ +-+-+-+-+-+ 629 | | | | 630 | | | | 631 | EAP | | EAP | 632 | Method | | Method | 633 | | | | 634 +-+-+-+-+-+ +-+-+-+-+-+ 636 Figure 4 - Three-way exchange 637 The three-way EAP exchange takes part in several phases: 639 [a] EAP authentication. During this phase, the EAP Client and Server 640 mutually authenticate and derive the EMK, which is known only to 641 the EAP Client and Server. Since possession of the EMK would enable 642 a third party to impersonate the EAP Client or Server, the EMK MUST 643 NOT be shared with any other party. Where the NAS acts as a pass- 644 through, it does not participate in the EAP conversation, except to 645 forward packets between the EAP Client and the Authentication 646 Server. As a result, the NAS does not possess the EMK and MUST NOT 647 be able to derive it, based on observing the EAP conversation, or 648 obtaining the MSK. 650 [b] Token distribution. During this phase, the AAA Server acts as a Key 651 Distribution Center (KDC), distributing the CS-Token to the EAP 652 Client and the AN-Token to the NAS. These tokens, which are 653 defined in the EAP Method and AAA key distribution specifications, 654 respectively, contain the MSK. 656 [c] TSK derivation. During this phase, the EAP Client and NAS confirm 657 mutual possession of the MSK, and derive the Transient Session Keys 658 used in the negotiated ciphersuite. TSK derivation occurs out of 659 band of EAP; an example is the 4-way handshake provided in IEEE 660 802.11 RSN. 662 Figure 5 below illustrates the relationship between the parties in the 663 three-way exchange. 665 EAP Client 666 /\ 667 / \ 668 Protocol: EAP / \ Protocol: TSK derivation 669 Auth: Mutual / \ Auth: Mutual 670 Unique key: EMK / \ Unique key: TSK 671 Token: CS-Token / \ 672 / \ 673 AAA Server +--------------+ NAS 674 Protocol: AAA 675 Auth: Mutual 676 Unique key: AAA session key 677 Token: AN-Token 679 Figure 5: Three-party EAP key distribution 681 Where key distribution is supported, the EAP Client and Authentication 682 Server (EAP Server) MUST mutually authenticate via the negotiated EAP 683 method, and derive keys only known between the EAP Client and Server, 684 known as the EMK. During EAP authentication, the CS-Token MAY be 685 transported from the EAP Server to the EAP Client, providing the Client 686 with the MSK. Alternatively, the MSK MAY be derived from the EMK, via a 687 one-way function. Whether the MSK is derived or transported, possession 688 of the MSK MUST NOT provide information useful in determining the EMK. 690 Utilizing the AAA protocol, the Authentication Server and NAS MUST 691 mutually authenticate, and derive a protected channel which MUST provide 692 per-packet integrity protection, authentication and confidentiality. The 693 AN-Token is distributed by the Authentication Server to the NAS over 694 this channel. Where possible, the channel between the Authentication 695 Server and NAS SHOULD be protected using a session key, as in [DiamEAP] 696 and RADIUS over IPsec [RFC3162], rather than using a static key, as in 697 RADIUS [RFC2865]. 699 During the (optional) TSK derivation step, the EAP Client and NAS MUST 700 mutually authenticate by providing mutual posession of the portion of 701 the MSK used in the derivation. The TSK derivation step SHOULD also 702 provide for a protected ciphersuite negotiation between the EAP Client 703 and NAS. 705 The security of the three-party exchange is highly dependent on the 706 security properties of the algorithms chosen. For example, if mutual 707 authentication is not completed between the EAP Client and 708 Authentication server, then the Client will be vulnerable to rogue 709 Authentication Servers and NASes. If the EMK is not derived between the 710 Client and Authentication Server, then there will be no binding between 711 the authentication and subsequent data traffic, leaving the session 712 vulnerable to hijack. 714 If the Authentication Server and NAS do not mutually authenticate, then 715 the the EAP Client will once again be vulnerable to rogue Authentication 716 Servers, NASes or both. If there is no per-packet authentication, 717 integrity and replay protection between the Authentication Server and 718 NAS, then the EAP conversation could be modified in transit, or packets 719 can spoofed. 721 If the TSK derivation does not support mutual authentication, then the 722 EAP Client will not have assurance that it is connected to the right 723 NAS, only that the NAS and AAA server share a trust relationship 724 (assuming that the AAA protocol supports mutual authentication). This 725 distinction can become important when multiple NASes receive MSKs from 726 the Authentication Server, as may be the case where fast handoff is 727 supported. If the TSK derivation does not provide for protected 728 ciphersuite negotiation, then downgrade attacks are possible. 730 3.3. EAP Key hierarchy 732 The EAP key hierarchy depends on two branches: 734 [a] EAP Master Key (EMK) branch. The EMK is derived during the EAP 735 conversation between the EAP Client and Server, and TEKs derived 736 from it are used to establish a protected channel between the EAP 737 Client and Server. Therefore, the EMK branch of the EAP key 738 hierarchy describes the derivation of keys used to protect the EAP 739 exchange itself. 741 Since the EMK is uniquely held by the EAP Client and Server, and 742 only mutually authenticating EAP methods may distribute keys, proof 743 of possession of the EMK is proof of a completed mutual 744 authentication. In order to ensure that the NAS does not possess 745 the EMK, which could be used to impersonate the EAP Client or EAP 746 Server, the EMK MUST NOT be provided to third parties such as the 747 NAS, or be derivable from other keying material such as the MSK. 748 In order to protect against compromise of the EMK, the EMK MUST NOT 749 be directly used to protect data; rather the TEKs derived from the 750 EMK are used for this purpose. Examples of the EMK branch of the 751 key hierarchy are given in Appendix A. 753 [b] Master Session Key (MSK) branch. The MSK is (optionally) 754 distributed by the Authentication Server to the EAP Client within 755 the CS-Token (or alternatively, derived from the EMK). It is 756 transported from the Authentication Server to the NAS within the 757 AN-Token. Since the MSK is not ciphersuite-specific, it is larger 758 than necessary, and is truncated to fit as part of the Transient 759 Session Key (TSK) derivation process. As with the EMK, the MSK MUST 760 NOT be directly used to protect data; rather TSKs derived from the 761 MSK are used for this purpose. Examples of the MSK hierarchy are 762 given in Appendix B. 764 4. Security considerations 766 This section describes the security requirements for EAP methods, AAA 767 protocols, TSK derivation mechanisms and Ciphersuites involved in three- 768 party EAP exchanges. These requirements MUST be met by specifications 769 requesting publication as an RFC. 771 4.1. Three-party exchange 773 The security of the three-party exchange is highly dependent on the 774 security properties of the each of the protocols. For example, if 775 mutual authentication is not completed between the EAP Client and 776 Authentication server, then the Client will be vulnerable to rogue 777 Authentication Servers and NASes. If the EMK is not derived between the 778 Client and Authentication Server, then there will be no binding between 779 the authentication and subsequent data traffic, leaving the session 780 vulnerable to hijack. 782 If the Authentication Server and NAS do not mutually authenticate, then 783 the the EAP Client will once again be vulnerable to rogue Authentication 784 Servers, NASes or both. If there is no per-packet authentication, 785 integrity and replay protection between the Authentication Server and 786 NAS, then the EAP conversation could be modified in transit, or packets 787 can spoofed. 789 If the TSK derivation does not support mutual authentication, then the 790 EAP Client will not have assurance that it is connected to the right 791 NAS, only that the NAS and AAA server share a trust relationship 792 (assuming that the AAA protocol supports mutual authentication). This 793 distinction can become important when multiple NASes receive MSKs from 794 the Authentication Server, as may be the case where fast handoff is 795 supported. If the TSK derivation does not provide for protected 796 ciphersuite negotiation, then downgrade attacks are possible. As a 797 result, where physical security cannot be assumed, or roaming is 798 supported, the TSK derivation step SHOULD NOT be ommitted. 800 4.2. EAP method requirements 802 EMK hierarchy 803 Methods deriving keys MUST support mutual authentication and 804 derivation of the EMK, as well as specifying how TEKs are derived 805 from the EMK. The EMK MUST NOT be used to directly protect data. 807 CS-Token specification 808 Methods supporting key derivation MUST specify the format of the 809 CS-Token containing the MSK. If no explicit CS-Token format is 810 used, then the formulas for derivation of the MSK MUST be provided. 812 MSK hierarchy 813 For a ciphersuite to be suitable for use with dynamic keying via 814 EAP a specification MUST be provided describing how TSKs are 815 derived from the MSK. 817 Cryptographic Separation 818 Methods supporting key derivation MUST demonstrate cryptographic 819 separation between the TEKs and TSKs. Also, it must be demonstrated 820 that possession of the MSK does not provide information useful in 821 determining the EMK. 823 Ciphersuite Independence 824 The MSK derivation SHOULD be ciphersuite-independent and the EAP 825 method SHOULD NOT assume knowledge of the ciphersuite. 827 Key size 828 An EAP method supporting key derivation MUST generate a 192 octet 829 MSK. 831 Key Entropy 832 The strength of session keys is dependent upon the security of the 833 EAP method. If the chosen EAP method has security vulnerabilities, 834 or does not produce an EMK and MSK of sufficient entropy then the 835 security of the three-party exchange is reduced. An EAP method 836 supporting key derivation SHOULD generate an EMK and MSK with at 837 least 128 bits of entropy. 839 Session Uniqueness 840 In order to assure non-repetition of TSKs even in cases where one 841 party may not have a high quality random number generator, the MSK 842 derivation SHOULD include a two-way nonce exchange, using nonces of 843 at least 128-bits. Note although the IEEE 802.11 RSN TSK derivation 844 includes a nonce exchange, the TSK derivation step is link layer 845 dependent, so that a link layer nonce exchange cannot be guaranteed 846 to occur. As a result, a nonce exchange is still needed within the 847 EAP method itself. A nonce exchange SHOULD also be included in the 848 derivation of the TEKs from the EMK. 850 Known-good algorithms 851 The development and validation of key derivation algorithms is 852 difficult, and as a result EAP methods SHOULD reuse existing 853 algorithms, rather than inventing new ones. EAP methods requesting 854 publication as an RFC MUST provide citations to literature 855 justifying the security of the chosen algorithms. EAP methods 856 SHOULD utilize well established and analyzed mechanisms for EMK and 857 MSK derivation. 859 4.3. AAA protocol requirements 861 AAA protocols suitable for use with EAP MUST provide the following 862 facilities: 864 AN-Token specification 865 In order to enable Authentication Servers to provide keying 866 material to the NAS in a well defined format, AAA protocols 867 suitable for use with EAP MUST define the format and wrapping of 868 the AN-Token. 870 AN-Token protection 871 To ensure against compromise, the AN-Token MUST be integrity 872 protected, authenticated and encrypted in transit, using well- 873 established cryptographic algorithms. In order to protect the AN- 874 Token from modification by AAA intermediaries, where untrusted 875 intermediaries are present, it SHOULD be protected using well- 876 established algorithms, such as is described in Diameter CMS 877 Security [DiamCMS], a work in progress. Proper key hygiene is 878 critical for protection of the AN-Token, which SHOULD protected 879 with session keys as in Diameter CMS Security [DiamCMS] (a work in 880 progress) or RADIUS over IPsec [RFC3162] rather than static keys, 881 as in [RFC2548]. 883 4.4. Ciphersuite requirements 885 Ciphersuites suitable for keying by EAP methods MUST provide the 886 following facilities: 888 TSK derivation 889 In order to key a ciphersuite with EAP, it is necessary to specify 890 how the TSKs required by the ciphersuite are derived from the MSK. 891 Derivation of the TSKs keys from MSK requires knowledge of the 892 negotiated ciphersuite. 894 TEK derivation 895 In order to establish a protected channel between the EAP Client 896 and Server as part of the EAP exchange, a ciphersuite needs to be 897 negotiated and keyed, using TEKs derived from the EMK. The 898 ciphersuite used to protect the EAP exchange is distinct from the 899 ciphersuite negotiated between the EAP client and NAS, used to 900 protect data. Where a protected channel is established within the 901 EAP method, the method specification MUST specify the mechanism by 902 which the EAP ciphersuite is negotiated, as well as the algorithms 903 for derivation of TEKs from the EMK during the EAP authentication 904 exchange. 906 EAP method independence 907 Algorithms for deriving TSKs from the MSK MUST NOT depend on the 908 EAP method. However, algorithms for deriving TEKs from the EMK MAY 909 be specific to the EAP method. 911 Cryptographic separation 912 The TSKs derived from the MSK MUST be cryptographically separate 913 from each other. Similarly, TEKs MUST be cryptographically separate 914 from each other. In addition, the TSKs MUST be cryptographically 915 separate from the TEKs. 917 5. Normative References 919 [RFC1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", 920 STD 51, RFC 1661, July 1994. 922 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 923 Requirement Levels", BCP 14, RFC 2119, March 1997. 925 [RFC2284bis] Blunk, L., Vollbrecht, J., Aboba, B., "Extensible 926 Authentication Protocol (EAP)", Internet draft (work in 927 progress), draft-ietf-pppext-rfc2284bis-08.txt, December 928 2002. 930 [IEEE80211] Information technology - Telecommunications and 931 information exchange between systems - Local and 932 metropolitan area networks - Specific Requirements Part 933 11: Wireless LAN Medium Access Control (MAC) and 934 Physical Layer (PHY) Specifications, IEEE Std. 935 802.11-1997, 1997. 937 [IEEE8021X] IEEE Standards for Local and Metropolitan Area Networks: 938 Port based Network Access Control, IEEE Std 802.1X-2001, 939 June 2002. 941 6. Informative References 943 [RFC1968] Meyer, G., "The PPP Encryption Protocol (ECP)", RFC 1968, 944 June 1996. 946 [RFC2104] Krawczyk, et al, "HMAC: Keyed-Hashing for Message 947 Authentication", RFC 2104, February 1997. 949 [RFC2246] Dierks, T. and Allen, C. "The TLS Protocol Version 1.0", 950 RFC 2246, November 1998. 952 [RFC2409] Harkins, D., Carrel, D., "The Internet Key Exchange 953 (IKE)", RFC 2409, November 1998. 955 [RFC2419] Sklower, K., Meyer, G., "The PPP DES Encryption Protocol, 956 Version 2 (DESE-bis)", RFC 2419, September 1998. 958 [RFC2420] Hummert, K., "The PPP Triple-DES Encryption Protocol 959 (3DESE)", RFC 2420, September 1998. 961 [RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an 962 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 963 October 1998. 965 [RFC2548] Zorn, G., "Microsoft Vendor-Specific RADIUS Attributes", 966 RFC 2548, March 1999. 968 [RFC2716] Aboba, B., Simon, D.,"PPP EAP TLS Authentication 969 Protocol", RFC 2716, October 1999. 971 [RFC2865] Rigney, C., Willens, S., Rubens, A., Simpson, W., "Remote 972 Authentication Dial In User Service (RADIUS)", RFC 2865, 973 June 2000. 975 [RFC3078] Pall, G. and Zorn, G. "Microsoft Point-to-Point 976 Encryption (MPPE) RFC 3078, March 2001. 978 [RFC3079] Zorn, G. "Deriving Keys for use with Microsoft Point-to- 979 Point Encryption (MPPE)," RFC 3079, March 2001. 981 [RFC3394] R. Housley, "Advance Encryption Standard (AES) Key Wrap 982 Algorithm", RFC 3394, September 2002. 984 [FIPSDES] National Bureau of Standards, "Data Encryption Standard", 985 FIPS PUB 46 (January 1977). 987 [DESMODES] National Bureau of Standards, "DES Modes of Operation", 988 FIPS PUB 81 (December 1980). 990 [FIPS197] FIPS PUB 197, Advanced Encryption Standard (AES), 2001 991 November 26H. 993 [SHA] National Institute of Standards and Technology (NIST), 994 "Announcing the Secure Hash Standard," FIPS 180-1, U.S. 995 Department of Commerce, 04/1995 997 [IEEE80211i] IEEE Draft 802.11i/D3, "Draft Supplement to STANDARD FOR 998 Telecommunications and Information Exchange between 999 Systems - LAN/MAN Specific Requirements - Part 11: 1000 Wireless Medium Access Control (MAC) and physical layer 1001 (PHY) specifications: Specification for Enhanced 1002 Security", November 2002. 1004 [EAPAPI] Microsoft Developer Network, "Windows 2000 EAP API", 1005 August 2000, http://msdn.microsoft.com/library/ 1006 default.asp?url=/library/en-us/eap/eapport_0fj9.asp 1008 [RFC2869bis] Aboba, B., Calhoun, P., "RADIUS Support For Extensible 1009 Authentication Protocol (EAP)", Internet draft (work in 1010 progress), draft-aboba-radius-rfc2869bis-05.txt, December 1011 2002. 1013 [DiamCMS] Calhoun, P., Farrell, S., Bulley, W., "Diameter CMS 1014 Security Application", Internet draft (work in progress), 1015 draft-ietf-aaa-diameter-cms-sec-04.txt, March 2002. 1017 [DiamEAP] Hiller, T., Zorn, G., "Diameter Extensible Authentication 1018 Protocol (EAP) Application", Internet draft (work in 1019 progress), draft-ietf-aaa-eap-00.txt, June 2002. 1021 Appendix A - Ciphersuite keying requirements 1023 To date, PPP and IEEE 802.11 ciphersuites are suitable for keying by 1024 EAP. This Appendix describes the transient session keying requirements 1025 of common PPP and 802.11 ciphersuites. 1027 PPP ciphersuites include DESEbis [RFC2419], 3DES [RFC2420], and MPPE 1028 [RFC3078]. The DES algorithm is described in [FIPSDES], and DES modes 1029 (such as CBC, used in RFC 2419 and DES-EDE3-CBC, used in RFC 2420) are 1030 described in [DESMODES]. For PPP DESEbis, a single 56-bit encryption 1031 key is required, used in both directions. For PPP 3DES, a 168-bit 1032 encryption key is needed, used in both directions. As described in 1033 [RFC2419] for DESEbis and [RFC2420] for 3DES, the IV, which is different 1034 in each direction, is "deduced from an explicit 64-bit nonce, which is 1035 exchanged in the clear during the [ECP] negotiation phase." 1037 For MPPE, 40-bit, 56-bit or 128-bit encryption keys can be required in 1038 each direction, as described in [RFC3078]. Since MPPE is based on the 1039 RC4 algorithm, no initialization vector is required. 1041 While these PPP ciphersuites provide encryption, they do not provide a 1042 per-packet keyed message integrity check (MIC). Thus, an authentication 1043 key is not required in either direction. 1045 Within 802.11, transient session keys are required both for unicast 1046 traffic as well as for multicast traffic, and therefore separate TSK 1047 hierarchies are required for unicast keys and multicast keys. IEEE 1048 802.11 ciphersuites include WEP-40, described in [IEEE80211], which 1049 requires a 40-bit encryption key, the same in either direction; and 1050 WEP-128, which requires a 104-bit encryption key, the same in either 1051 direction. These ciphersuites also do not include a keyed MIC, so that 1052 an authentication key is not required in either direction. However, in 1053 order to protect the transport of the multicast keys from the Access 1054 Point to the Station, additional authentication and encryption keys are 1055 required. 1057 Recently, new ciphersuites have been proposed for use with 802.11 that 1058 provide per-packet authentication as well as encryption [IEEE80211i]. 1059 This includes TKIP, which requires a single 128-bit encryption key and a 1060 128-bit authentication key (used in both directions); AES CCMP, which 1061 requires a single 128-bit key (used in both directions) in order to 1062 authenticate and encrypt data; and WRAP, which requires a single 128-bit 1063 key (used in both directions). 1065 Appendix B - Example EMK Hierarchy 1067 In EAP TLS [RFC2716], ciphersuite negotiation and derivation of the TEKs 1068 is provided using the Transport Layer Security (TLS) key hierarchy 1069 specified in [RFC2246]. The TLS-negotiated ciphersuite is used to set 1070 up a protected channel, keyed by derived TEKs. The TEK derivations 1071 proceeds as follows: 1073 Master_secret = TLS-PRF(Pre-Master-Secret, "master secret" || 1074 server.random || client.random) 1075 TEK = TLS-PRF-X(Master-Secret, "key expansion", server.random || client.random) 1077 Where: 1078 TLS-PRF-X = TLS pseudo-random function defined in [RFC2246], 1079 computed to X octets. 1080 Master-Secret = TLS term for the EMK. 1082 Figure B-1 illustrates the EMK key hierarchy, which is derived from the 1083 TLS key hierarchy described in [RFC2246]. 1085 | | | 1086 | | Pre-Master-Secret | 1087 Server| | | Client 1088 Random| V | Random 1089 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1090 | | | | 1091 | | | | 1092 +---->| Master-Secret |<------+ 1093 | | (EMK) | | 1094 | | | | 1095 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1096 | | | 1097 | | | 1098 | | | 1099 V V V 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 | | 1102 | | 1103 | Key Block | 1104 | (TEKs) | 1105 | | 1106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1107 | | | | | | 1108 | Client | Server | client | server | Client | Server 1109 | MAC | MAC | write | write | IV | IV 1110 | | | | | | 1111 | | | | | | 1112 V V V V V V 1113 +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ 1114 | | | | | | | | 1115 | Final | | Final | | Final | | Final | 1116 Export -------->| Client| | Server| | Client| | Server| 1117 | Write | | Write | | IV | | IV | 1118 | | | | | | | | 1119 +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ 1121 Figure B-1 - TLS [RFC2246] Key Hierarchy 1122 Appendix C - Example MSK Hierarchy 1124 In EAP TLS [RFC2716], the MSK is not transported within a CS-Token 1125 package. Rather, the MSK is derived from the EMK via a one-way 1126 function. This ensures that the EMK cannot be derived from the MSK 1127 unless the one-way function (TLS PRF) is broken. 1129 Since the MSK is derived from the EMK, if the EMK is compromised then 1130 the MSK is also compromised. However, this would be the case even if the 1131 MSK were cryptographically separate from the EMK, since TEKs derived 1132 from the EMK are used to protect the CS-Token containing the MSK. Thus 1133 if the EMK is compromised, so are the TEKs, the CS-token and ultimately 1134 the MSK. 1136 As described in [RFC2716], the formula for the derivation of the MSK 1137 from the EMK is as follows: 1139 MSK(0,127) = TLS-PRF-128(EMK, "client EAP encryption", client.random || server.random) 1140 MSK(128,191)= TLS-PRF-64("", "client EAP encryption", client.random || server.random) 1142 MSK(0,31) = Peer to Authenticator Encryption Key (Enc-RECV-Key) 1143 (MS-MPPE-Recv-Key in [RFC2548]) 1144 MSK(32,63) = Authenticator to Peer Encryption Key (Enc-SEND-Key) 1145 (MS-MPPE-Send-Key in [RFC2548]) 1146 MSK(64,95) = Peer to Authenticator Authentication Key (Auth-RECV-Key) 1147 MSK(96,127) = Authenticator to Peer Authentication Key (Auth-Send-Key) 1148 MSK(128,159)= Peer to Authenticator Initialization Vector (RECV-IV) 1149 MSK(160,191)= Authenticator to Peer Initialization vector (SEND-IV) 1151 Where: 1153 MSK(W,Z) = Octets W through Z inclusive of the MSK. 1154 EMK = TLS master secret 1155 TLS-PRF-X = TLS PRF function defined in [RFC2246] computed to X octets 1156 client.random = Nonce generated by the TLS client. 1157 server.random = Nonce generated by the TLS server. 1159 Figure C-1 describes the process by which the MSK, and ultimately the 1160 TSKs, are derived from the EMK. Note that in [RFC2716], the EMK is 1161 referred to as the "TLS Master Secret". 1163 ---+ 1164 | ^ 1165 | TLS Master Secret (EMK) | 1166 | | 1167 V | 1168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1169 | | EAP | 1170 | Master Session Key (MSK) | Method | 1171 | Derivation | | 1172 | | | 1173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1174 | | | 1175 | MSK (0,127) | MSK (128, 192) | 1176 | | | 1177 V V | 1178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1179 | | | | | 1180 | | | | | 1181 | Key Derivation | | IV Derivation | | 1182 | | | | | 1183 | | | | | 1184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1185 | P->A | A->P | P->A | A->P | P->A | A->P EAP V 1186 | Enc. | Enc. | Auth. | Auth. | IV | IV API ---+ 1187 | Key | Key | Key | Key | | ^ 1188 | (32B) | (32B) | (32B) | (32B) | (32B) | (32B) AAA | 1189 | | | | | | Keys V 1190 V V V V V V ---+ 1191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ 1192 | | | 1193 | Ciphersuite-Specific Truncation & | NAS | 1194 | Key utilization | | 1195 | | V 1196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 1198 Figure C-1 - EAP TLS [RFC2716] MSK hierarchy 1200 Within IEEE 802.11 RSN, the Pairwise Transient Key (PTK), a transient 1201 session key used to protect unicast traffic, is derived from the PMK 1202 (octets 0-31 of the MSK), otherwise known as the Peer to Authenticator 1203 Encryption Key. Within [RFC2548], the PMK is transported via the MS- 1204 MPPE-Recv-Key attribute. In IEEE 802.11 RSN, the PTK is derived from the 1205 PMK via the following formula: 1207 PTK = EAPOL-PRF-X(PMK, "Pairwise key expansion" || Min(AA,SA) || 1208 Max(AA, SA) || Min(ANonce,SNonce) || Max(ANonce,SNonce)) 1210 Where: 1212 PMK = MSK(0,31) 1213 SA = Station MAC address 1214 AA = AP MAC address 1215 ANonce = AP Nonce 1216 SNonce = Station Nonce 1217 EAPOL-PRF-X = Pseudo-Random Function based on HMAC-SHA1, generating 1218 a PTK of size X. 1220 TKIP uses X = 512, while CCMP, WRAP, and WEP use X = 384. 1222 The EAPOL-Key Confirmation Key (KCK) is used to provide data origin 1223 authenticity in the TSK derivation. It utilizes the first 128 bits (bits 1224 0-127) of the PTK. The EAPOL-Key Encr. Key (KEK) provides 1225 confidentiality in the TSK derivation. It utilizes bits 128-255 of the 1226 PTK. Bits 256-383 of the PTK are used by Temporal Key 1, and Bits 1227 384-511 are used by Temporal Key 2. Usage of TK1 and TK2 is ciphersuite 1228 specific. Additional details are available in [IEEE80211i]. 1230 Acknowledgments 1232 Thanks to Arun Ayyagari, Ashwin Palekar, and Tim Moore of Microsoft, 1233 Dorothy Stanley of Agere, Dave Halasz of Cisco Systems, and Russ Housley 1234 of RSA Security for useful feedback. 1236 Author Addresses 1238 Bernard Aboba 1239 Microsoft Corporation 1240 One Microsoft Way 1241 Redmond, WA 98052 1243 EMail: bernarda@microsoft.com 1244 Phone: +1 425 706 6605 1245 Fax: +1 425 936 7329 1247 Dan Simon 1248 Microsoft Research 1249 Microsoft Corporation 1250 One Microsoft Way 1251 Redmond, WA 98052 1253 EMail: dansimon@microsoft.com 1254 Phone: +1 425 706 6711 1255 Fax: +1 425 936 7329 1256 Intellectual Property Statement 1258 The IETF takes no position regarding the validity or scope of any 1259 intellectual property or other rights that might be claimed to pertain 1260 to the implementation or use of the technology described in this 1261 document or the extent to which any license under such rights might or 1262 might not be available; neither does it represent that it has made any 1263 effort to identify any such rights. Information on the IETF's 1264 procedures with respect to rights in standards-track and standards- 1265 related documentation can be found in BCP-11. Copies of claims of 1266 rights made available for publication and any assurances of licenses to 1267 be made available, or the result of an attempt made to obtain a general 1268 license or permission for the use of such proprietary rights by 1269 implementors or users of this specification can be obtained from the 1270 IETF Secretariat. 1272 The IETF invites any interested party to bring to its attention any 1273 copyrights, patents or patent applications, or other proprietary rights 1274 which may cover technology that may be required to practice this 1275 standard. Please address the information to the IETF Executive 1276 Director. 1278 Full Copyright Statement 1280 Copyright (C) The Internet Society (2002). All Rights Reserved. 1281 This document and translations of it may be copied and furnished to 1282 others, and derivative works that comment on or otherwise explain it or 1283 assist in its implementation may be prepared, copied, published and 1284 distributed, in whole or in part, without restriction of any kind, 1285 provided that the above copyright notice and this paragraph are included 1286 on all such copies and derivative works. However, this document itself 1287 may not be modified in any way, such as by removing the copyright notice 1288 or references to the Internet Society or other Internet organizations, 1289 except as needed for the purpose of developing Internet standards in 1290 which case the procedures for copyrights defined in the Internet 1291 Standards process must be followed, or as required to translate it into 1292 languages other than English. The limited permissions granted above are 1293 perpetual and will not be revoked by the Internet Society or its 1294 successors or assigns. This document and the information contained 1295 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 1296 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1297 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1298 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1299 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1300 Open issues 1302 Open issues relating to this specification are tracked on the following 1303 web site: 1305 http://www.drizzle.com/~aboba/EAP/eapissues.html 1307 Expiration Date 1309 This memo is filed as , and 1310 expires July 22, 2003.