idnits 2.17.1 draft-aboba-pppext-key-problem-07.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 45 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 46 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 8 instances of too long lines in the document, the longest one being 4 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 847 has weird spacing: '...created as th...' == Line 1303 has weird spacing: '...ULD use sessi...' == Line 2028 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. (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 (9 August 2003) is 7565 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IEEE 80211' is mentioned on line 272, but not defined -- Looks like a reference, but probably isn't: '1' on line 833 -- Looks like a reference, but probably isn't: '2' on line 838 -- Looks like a reference, but probably isn't: '3' on line 846 -- Looks like a reference, but probably isn't: '4' on line 851 == Missing Reference: 'RFC 2716' is mentioned on line 887, but not defined ** Obsolete undefined reference: RFC 2716 (Obsoleted by RFC 5216) == Missing Reference: 'DiamBase' is mentioned on line 1571, but not defined == Missing Reference: 'ECP' is mentioned on line 1762, but not defined == Unused Reference: 'RFC2434' is defined on line 1621, but no explicit reference was found in the text == Unused Reference: 'RFC793' is defined on line 1596, but no explicit reference was found in the text == Unused Reference: 'RFC1321' is defined on line 1599, but no explicit reference was found in the text == Unused Reference: 'RFC2104' is defined on line 1605, but no explicit reference was found in the text == Unused Reference: 'RFC2409' is defined on line 1611, but no explicit reference was found in the text == Unused Reference: 'RFC2960' is defined on line 1641, but no explicit reference was found in the text == Unused Reference: 'RFC3079' is defined on line 1647, but no explicit reference was found in the text == Unused Reference: 'RFC3394' is defined on line 1650, but no explicit reference was found in the text == Unused Reference: 'FIPS197' is defined on line 1662, but no explicit reference was found in the text == Unused Reference: 'SHA' is defined on line 1665, but no explicit reference was found in the text == Unused Reference: 'IEEE80211f' is defined on line 1680, but no explicit reference was found in the text == Unused Reference: 'EAPAPI' is defined on line 1692, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) == Outdated reference: A later version (-09) exists of draft-ietf-eap-rfc2284bis-04 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- 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 2716 (Obsoleted by RFC 5216) -- Obsolete informational reference (is this intentional?): RFC 2960 (Obsoleted by RFC 4960) -- Unexpected draft version: The latest known version of draft-ietf-roamops-cert is -01, but you're referring to -02. -- Unexpected draft version: The latest known version of draft-ietf-aaa-diameter is -16, but you're referring to -17. == Outdated reference: A later version (-10) exists of draft-ietf-aaa-eap-02 == Outdated reference: A later version (-04) exists of draft-irtf-aaaarch-handoff-02 == Outdated reference: A later version (-08) exists of draft-orman-public-key-lengths-05 -- No information found for draft-puthekulam-eap-binding - is the name correct? Summary: 6 errors (**), 0 flaws (~~), 28 warnings (==), 14 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 9 August 2003 8 EAP Key Management 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 (2003). All Rights Reserved. 34 Abstract 36 This document provides a framework for EAP key management, including a 37 statement of applicability and guidelines for generation, transport and 38 usage of EAP keying material. Algorithms for key derivation or 39 mechanisms for key transport are not specified in this document. 40 Rather, this document provides a framework within which algorithms and 41 transport mechanisms can be discussed and evaluated. 43 Table of Contents 45 1. Introduction .......................................... 3 46 1.1 Requirements Language ........................... 3 47 1.2 Terminology ..................................... 3 48 1.3 Conversation Overview ........................... 5 49 2. EAP key hierarchy ..................................... 9 50 2.1 EAP Invariants .................................. 9 51 2.2 Key Hierarchy ................................... 11 52 2.3 Exchanges ....................................... 14 53 2.4 Security Relationships .......................... 18 54 3. Security associations ................................. 19 55 3.1 EAP SA .......................................... 19 56 3.2 AAA-Key SA ...................................... 20 57 3.3 Unicast Secure Association SA ................... 21 58 3.4 Multicast Secure Association SA ................. 22 59 3.5 Key Naming ...................................... 23 60 4. Threat model .......................................... 25 61 4.1 Security Assumptions ............................ 25 62 4.2 Security Requirements ........................... 26 63 5. IANA Considerations ................................... 32 64 6. Security Considerations ............................... 32 65 6.1 Key Strength .................................... 32 66 6.2 Key Wrap ........................................ 32 67 6.3 Man-in-the-middle Attacks ....................... 33 68 6.4 Impersonation ................................... 33 69 7. References ............................................ 34 70 7.1 Normative References ............................ 34 71 7.2 Informative References .......................... 35 72 Appendix A - Ciphersuite Keying Requirements ................. 39 73 Appendix B - TEK Hierarchy ................................... 40 74 Appendix C - MSK and EMSK Hierarchy .......................... 41 75 Appendix D - TSK Derivation .................................. 43 76 Appendix E - AAA-Key Key Derivation .......................... 44 77 Acknowledgments .............................................. 44 78 Author's Addresses ........................................... 44 79 Intellectual Property Statement .............................. 45 80 Full Copyright Statement ..................................... 45 81 1. Introduction 83 The Extensible Authentication Protocol (EAP), defined in [RFC2284bis], 84 was designed to enable extensible authentication for network access in 85 situations in which the IP protocol is not available. Originally 86 developed for use with PPP [RFC1661], it has subsequently also been 87 applied to IEEE 802 wired networks [IEEE8021X]. 89 This document provides a framework for the generation, transport and 90 usage of keying material generated by EAP authentication algorithms, 91 known as "methods". Since in EAP keying material is generated by EAP 92 methods, transported by AAA protocols, transformed into session keys by 93 secure association protocols and used by link layer ciphersuites, it is 94 necessary to describe each of these elements and provide a system-level 95 security analysis. 97 The document is organized as follows: 99 Section 1 provides an introduction and defines terminology. 100 Section 2 describes the EAP key hierarchy and exchanges. 101 Section 3 describes EAP security associations and key naming. 102 Section 4 describes the threat model and security requirements. 103 Section 5 describes the IANA considerations. 104 Section 6 describes security considerations. 105 Section 7 provides references. 106 Appendix A summarizes the keying requirements for link layer ciphersuites. 107 Appendix B provides an example transient EAP key (TEK) hierarchy. 108 Appendix C provides an example MSK and EMSK hierarchy. 109 Appendix D provides an example Transient Session Key (TSK) derivation. 110 Appendix E describes AAA-Key derivation, including fast handoff. 112 1.1. Requirements Language 114 In this document, several words are used to signify the requirements of 115 the specification. These words are often capitalized. The key words 116 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 117 NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 118 interpreted as described in BCP 14 [RFC2119]. 120 1.2. Terminology 122 This document frequently uses the following terms: 124 authenticator 125 The end of the link initiating EAP authentication. Where no 126 backend authentication server is present, the authenticator acts as 127 the EAP server, terminating the EAP conversation with the peer. 128 Where a backend authentication server is present, the authenticator 129 may act as a pass-through for one or more authentication methods 130 and for non-local users. This terminology is also used in 131 [IEEE8021X], and has the same meaning in this document. 133 backend authentication server 134 A backend authentication server is an entity that provides an 135 authentication service to an authenticator. When used, this server 136 typically executes EAP Methods for the authenticator. This 137 terminology is also used in [IEEE8021X]. 139 AAA-Token 140 The package within which keying material and one or more attributes 141 is transported between the backend authentication server and the 142 authenticator. The attributes provide the authenticator with usage 143 context and key names suitable to bind the key to the appropriate 144 context. For example, attributes might include the peer layer 2 145 address (Calling-Station-Id), the authenticator layer 2 address 146 (Called-Station-Id) and IP address (NAS-IP-Address), the key name, 147 etc. The format and wrapping of the AAA-Token, which is intended 148 to be accessible only to the backend authentication server and 149 authenticator, is defined by the AAA protocol. 151 Cryptographic binding 152 The demonstration of the EAP peer to the EAP server that a single 153 entity has acted as the EAP peer for all methods executed within a 154 sequence or tunnel. Binding MAY also imply that the EAP server 155 demonstrates to the peer that a single entity has acted as the EAP 156 server for all methods executed within a sequence or tunnel. If 157 executed correctly, binding serves to mitigate man-in-the-middle 158 vulnerabilities. 160 Cryptographic separation 161 Two keys (x and y) are "cryptographically separate" if an adversary 162 that knows all messages exchanged in the protocol cannot compute x 163 from y or y from x without "breaking" some cryptographic 164 assumption. In particular, this definition allows that the 165 adversary has the knowledge of all nonces sent in cleartext as well 166 as all predictable counter values used in the protocol. Breaking a 167 cryptographic assumption would typically require inverting a one- 168 way function or predicting the outcome of a cryptographic pseudo- 169 random number generator without knowledge of the secret state. In 170 other words, if the keys are cryptographically separate, there is 171 no shortcut to compute x from y or y from x, but the work an 172 adversary must do to perform this computation is equivalent to 173 performing exhaustive search for the secret state value. 175 EAP server 176 The entity which terminates EAP authentication with the peer is 177 known as the EAP server. Where pass-through is supported, the 178 backend authentication server functions as the EAP server; where 179 authentication occurs locally, the EAP server is the authenticator. 181 Key derivation 182 This refers to the ability of the EAP method to export a 183 ciphersuite-independent Master Session Key (MSK), Extended Master 184 Session Key (EMSK), and (optionally) an Initialization Vector (IV). 186 Key strength 187 If the effective key strength is N bits, the best currently known 188 methods to recover the key (with non-negligible probability) 189 require an effort comparable to 2^N operations of a typical block 190 cipher. 192 Mutual authentication 193 This refers to an EAP method in which, within an interlocked 194 exchange, the authenticator authenticates the peer and the peer 195 authenticates the authenticator. Two one-way conversations, 196 running in opposite directions do not provide mutual authentication 197 as defined here. 199 peer The end of the link that responds to the authenticator. In 200 [IEEE8021X], this end is known as the Supplicant. 202 1.3. Conversation Overview 204 Where EAP key derivation is supported, EAP authentication is typically a 205 component of a three phase exchange: 207 Discovery phase (phase 0) 208 EAP authentication, key derivation and transport (phase 1) 209 Unicast and multicast secure association establishment (phase 2) 211 In the discovery phase (phase 0), the EAP peers locate each other and 212 discover their capabilities. This can include an EAP peer locating 213 an authenticator suitable for access to a particular network, or 214 it could involve an EAP peer locating an authenticator behind 215 a bridge with which it desires to establish a secure association. Typically 216 the discovery phase takes place between the EAP peer and authenticator. 218 Once the EAP peer and authenticator discover each other, they 219 authenticate using EAP (phase 1a). EAP enables deployment of new 220 authentication methods without requiring development of new code on the 221 authenticator. While the authenticator may implement some EAP methods 222 locally and use those methods to authenticate local users, it may at the 223 same time act as a pass-through for other users and methods, forwarding 224 EAP packets back and forth between the backend authentication server and 225 the peer. 227 As described in Section 2, in addition to supporting authentication, 228 EAP methods may also support derivation of keying material for purposes 229 including protection of the EAP conversation and subsequent data 230 exchanges. EAP key derivation takes place between the EAP peer and EAP 231 server, and methods supporting key derivation MUST also support mutual 232 authentication. Where an authenticator server is present, it acts as 233 the EAP server and transports derived keying material (known as the AAA- 234 Key) to the authenticator (phase 1b). In 802.11 terminology, the first 235 32 octets of the AAA-Key is known as the Pairwise Master Key (PMK). 237 While EAP methods may be based on key management protocols, EAP itself 238 is not a key management protocol. Thus, while EAP may provide for 239 mutual authentication and derivation of keying material, it does not 240 provide for the derivation or naming of transient session keys, the 241 selection of traffic modes such as transport or tunnel mode, the secure 242 negotiation of capabilities such as ciphersuites or filters, or support 243 for key activation. As a result, where EAP is used for key derivation, 244 a secure association protocol (phase 2) should be provided, supporting 245 the creation and deletion of unicast (phase 2a) and multicast (phase 2b) 246 security associations used for the protection of data. 248 The phases and the relationship between the parties is illustrated 249 below. 251 EAP peer Authenticator Auth. Server 252 -------- ------------- ------------ 253 <-----------------------------> 254 Discovery (phase 0) 255 <-----------------------------><-------------------------------> 256 EAP auth (phase 1a) AAA pass-through (optional) 257 <-------------------------------- 258 AAA-Key transport (phase 1b) 259 <-----------------------------> 260 Unicast Secure association (phase 2a) 261 <-----------------------------> 262 Multicast Secure association (phase 2b) 264 Figure 1 - Conversation Overview 266 1.3.1. Discovery Phase 268 In the peer discovery exchange (phase 0), the EAP peer and 269 authenticator locate each other and discover each other's capabilities. 270 For example, PPPoE [RFC2516] includes support for a Discovery Stage to 271 allow a peer to identify the Ethernet MAC address of one or more 272 authenticators and establish a PPPoE SESSION_ID. In [IEEE 80211], the 273 EAP peer (also known as the Station or STA) discovers the authenticator 274 (Access Point or AP) and determines its capabilities using Beacon or 275 Probe Request/Response frames. Since device discovery is handled 276 outside of EAP, there is no need to provide this functionality within 277 EAP. 279 Device discovery can occur manually or automatically. In EAP 280 implementations running over PPP, the EAP peer might be configured with 281 a phone book providing phone numbers of authenticators and associated 282 capabilities such as supported rates, authentication protocols or 283 ciphersuites. 285 Since device discovery can occur prior to authentication and key 286 derivation, it may not be possible for the discovery phase to be 287 protected using keying material derived during an authentication 288 exchange. As a result, device discovery protocols may be insecure, 289 leaving them vulnerable to spoofing unless the discovered parameters can 290 subsequently be securely verified. 292 1.3.2. Authentication Phase 294 Once the EAP peer and authenticator discover each other, they 295 authenticate using EAP (phase 1a). Typically, the peer desires access 296 to the network, and the authenticators are Network Access Servers 297 (NASes) providing that access. In such a situation, access to the 298 network can be provided by any authenticator attaching to the desired 299 network, and the EAP peer is typically willing to send data traffic 300 through any authenticator that can demonstrate that it is authorized to 301 provide access to the desired network. 303 An EAP authenticator may handle the authentication locally, or it may 304 act as a pass-through to a backend authentication server. In the latter 305 case the EAP exchange occurs between the EAP peer and a backend 306 authenticator server, with the authenticator forwarding EAP packets 307 between the two. The entity which terminates EAP authentication with 308 the peer is known as the EAP server. Where pass-through is supported, 309 the backend authentication server functions as the EAP server; where 310 authentication occurs locally, the EAP server is the authenticator. 311 Where a backend authentication server is present, at the successful 312 completion of an authentication exchange, the AAA-Key is transported to 313 the authenticator (phase 1b). 315 EAP may also be used when it is desired for two network devices (e.g. 316 two switches or routers) to authenticate each other, or where two peers 317 desire to authenticate each other and set up a secure association 318 suitable for protecting data traffic. 320 EAP supports either one-way authentication (in which the peer 321 authenticates to the EAP server), or mutual authentication (in which the 322 peer and EAP server mutually authenticate). In either case, it can be 323 assumed that the parties do not utilize the link to exchange data 324 traffic unless their authentication requirements have been met. For 325 example, a peer completing mutual authentication with an EAP server will 326 not send data traffic over the link until the EAP server has 327 authenticated successfully to the peer, and a secure association has 328 been negotiated. 330 Since EAP is a peer-to-peer protocol, an independent and simultaneous 331 authentication may take place in the reverse direction. Both peers may 332 act as authenticators and authenticatees at the same time. 334 Successful completion of EAP authentication and key derivation by an EAP 335 peer and EAP server does not necessarily imply that the peer is 336 committed to joining the network associated with an EAP server. Rather, 337 this commitment is implied by the creation of a security association 338 between the EAP peer and authenticator, as part of the secure 339 association protocol (phase 2). As a result, EAP may be used for "pre- 340 authentication" in situations where it is necessary to pre-establish EAP 341 security associations in order to decrease handoff or roaming latency. 343 1.3.3. Secure Association Phase 345 While EAP methods may be based on key management protocols, EAP itself 346 is not a protocol for negotiation of security associations. While EAP 347 methods supporting key derivation provide for mutual authentication and 348 creation of EAP (phase 1) security associations, in order to preserve 349 media independence, they typically do not support generation of 350 transient session keys or negotiation of ciphersuites used in the 351 protection of data. As a result, where EAP is used for key derivation, 352 a secure association protocol (phase 2) should be provided, supporting 353 the creation and deletion of phase 2 security associations used for the 354 protection of data. 356 The secure association phase (phase 2) always occurs after the 357 completion of EAP authentication (phase 1a) and key transport (phase 358 1b), and typically supports the following features: 360 [1] The secure negotiation of capabilities. This includes usage modes, 361 session parameters and ciphersuites, and required filters, 362 including confirmation of the capabilities discovered during phase 363 0. By securely negotiating session parameters, the secure 364 association protocol protects against spoofing during the discovery 365 phase and ensures that the peer and authenticator are in agreement 366 about how data is to be secured. 368 [2] Generation of fresh transient session keys. This is typically 369 accomplished via the exchange of nonces within the secure 370 association protocol, and includes generation of both unicast 371 (phase 2a) and multicast (phase 2b) session keys. While multicast 372 traffic may only pass in one direction in certain cases (such as in 373 IEEE 802.11 infrastructure mode, where only the Access Point sends 374 multicast traffic), in other cases (such as IEEE 802.11 adhoc 375 mode), both endpoints may send multicast traffic. By not using the 376 AAA-Key directly to protect data, the secure association protocol 377 protects against compromise of the AAA-Key, and by guaranteeing the 378 freshness of transient session key, assures that session keys are 379 not reused. 381 [3] Key activation and deletion. 383 [4] Mutual proof of possession of the keying material generated during 384 EAP authentication (phase 1). By requiring a mutual proof of 385 possession of the AAA-Key, the secure association protocol 386 demonstrates that both the EAP peer and authenticator have been 387 authenticated and authorized by the AAA server. Note that mutual 388 proof of possession is not the same thing as mutual authentication. 389 For example, as a result of a secure association protocol exchange, 390 the EAP peer may not be able to confirm the identity of the 391 authenticator. 393 2. EAP Key Hierarchy 395 2.1. EAP Invariants 397 The EAP key management framework assumes that certain basic 398 characteristics, known as the "EAP Invariants" hold true for all 399 implementations of EAP. These include: 401 Media independence 402 Method independence 403 Ciphersuite independence 405 2.1.1. Media Independence 407 As described in [RFC2284bis], EAP authentication can run over multiple 408 lower layers, including PPP [RFC1661] and IEEE 802 wired networks 409 [IEEE8021X]. Use with IEEE 802.11 wireless LANs is also contemplated 410 [IEEE80211i]. Since EAP methods cannot be assumed to have knowledge of 411 the lower layer over which they are transported, EAP methods can 412 function on any lower layer meeting the criteria outlined in 413 [RFC2284bis], Section 3.1. 415 2.1.2. Method Independence 417 Supporting pass-through of authentication to the backend authentication 418 server enables the authenticator to support any authentication method 419 implemented on the backend authentication server and peer, not just 420 locally implemented methods. 422 This implies that the authenticator need not implement code for each EAP 423 method required by authenticating peers. In fact, the authenticator is 424 not required to implement any EAP methods at all, nor cannot it be 425 assumed to implement code specific to any EAP method. 427 This is useful where there is no single EAP method that is both 428 mandatory-to-implement and offers acceptable security for the media in 429 use. For example, the [RFC2284bis] mandatory-to-implement EAP method 430 (MD5-Challenge) does not provide dictionary attack resistance, mutual 431 authentication or key derivation, and as a result is not appropriate for 432 use in wireless authentication. 434 2.1.3. Ciphersuite Independence 436 While EAP methods may negotiate the ciphersuite used in protection of 437 the EAP conversation, the ciphersuite used for the protection of data is 438 negotiated within the secure association protocol, out-of-band of EAP. 439 The backend authentication server is not a party to this negotiation nor 440 is it an intermediary in the data flow between the EAP peer and 441 authenticator. The backend authentication server may not even have 442 knowledge of the ciphersuites implemented by the peer and authenticator, 443 or be aware of the ciphersuite negotiated between them, and therefore 444 does not implement ciphersuite-specific code. 446 Since ciphersuite negotiation occurs in the secure association protocol, 447 not in EAP, ciphersuite-specific key generation, if implemented within 448 an EAP method, would potentially conflict with the transient session key 449 derivation occurring in the secure association protocol. As a result, 450 EAP methods generate keying material that is ciphersuite-independent. 451 Additional advantages of ciphersuite-independence include: 453 Update requirements 454 If EAP methods were to specify how to derive transient session keys 455 for each ciphersuite, they would need to be updated each time a new 456 ciphersuite is developed. In addition, backend authentication 457 servers might not be usable with all EAP-capable authenticators, 458 since the backend authentication server would also need to be 459 updated each time support for a new ciphersuite is added to the 460 authenticator. 462 EAP method complexity 463 Requiring each EAP method to include ciphersuite-specific code for 464 transient session key derivation would increase the complexity of 465 each EAP method and would result in duplicated effort. 467 Ciphersuite negotiation 468 In practice, an EAP method may not have knowledge of the 469 ciphersuite that has been negotiated between the peer and 470 authenticator. In PPP, ciphersuite negotiation occurs in the 471 Encryption Control Protocol (ECP) [RFC1968]. Since ECP negotiation 472 occurs after authentication, unless an EAP method is utilized that 473 supports ciphersuite negotiation, the peer, authenticator and 474 backend authentication server may not be able to anticipate the 475 negotiated ciphersuite and therefore this information cannot be 476 provided to the EAP method. Since ciphersuite negotiation is 477 assumed to occur out-of-band, there is no need for ciphersuite 478 negotiation within EAP. 480 2.2. Key Hierarchy 482 The EAP keying hierarchy, illustrated in Figure 2, makes use of the 483 following types of keys: 485 EAP Master key (MK) 486 A key derived between the EAP client and server during the EAP 487 authentication process, and that is kept local to the EAP method 488 and not exported or made available to a third party. Since the MK 489 is a residue of a successful EAP authentication exchange, it is 490 possible to shorten future EAP exchanges between an EAP peer and 491 server by providing proof of MK possesion, a technique known as 492 "fast resume". 494 Master Session Key (MSK) 495 Keying material (at least 64 octets) that is derived between the 496 EAP client and server and exported by the EAP method. Whenever a 497 full EAP authentication is performed (not fast handoff), the MSK is 498 chosen as the AAA-Key (see Appendix E for details). 500 AAA-Key 501 Where a backend authentication server is present, acting as an EAP 502 server, keying material known as the AAA-Key is transported from 503 the authentication server to the authenticator wrapped within the 504 AAA-Token. The AAA-Key is used by the EAP peer and authenticator 505 in the derivation of Transient Session Keys (TSKs) for the 506 ciphersuite negotiated between the EAP peer and authenticator. As 507 a result, the AAA-Key is typically known by all parties in the EAP 508 exchange: the peer, authenticator and the authentication server (if 509 present). AAA-Key derivation is discussed in Appendix E. 511 Extended Master Session Key (EMSK) 512 Additional keying material (64 octets) derived between the EAP 513 client and server that is exported by the EAP method. Unlike the 514 MSK which is transported from the authentication server to the 515 authenticator, the EMSK is known only to the EAP peer and server 516 and is not provided to a third party. The EMSK therefore is not 517 transported by the backend authentication server to the 518 authenticator, although quantities derived from it may be used as 519 the AAA-Key in situations in which EAP authentication is bypassed 520 (e.g. fast handoff). 522 Currently the EMSK is reserved for future uses that are not defined 523 yet. For example, it could be used to derive additional keying 524 material for purposes such as fast handoff, man-in-the-middle 525 vulnerability protection, etc. 527 Initialization Vector (IV) 528 A quantity of at least 64 octets, suitable for use in an 529 initialization vector field, that is derived between the EAP client 530 and server. Since the IV is a known value in methods such as EAP- 531 TLS [RFC2716] it cannot be used in computation of any quantity that 532 needs to remain secret, and is not used with any known ciphersuite. 533 As a result, its use has been deprecated and EAP methods are not 534 required to generate it. 536 Pairwise Master Key (PMK) 537 The AAA-Key is divided into two halves, the "Peer to Authenticator 538 Encryption Key" (Enc-RECV-Key) and "Authenticator to Peer 539 Encryption Key" (Enc-SEND-Key) (reception is defined from the point 540 of view of the authenticator). Within [IEEE80211i] Octets 0-31 of 541 the AAA-Key (Enc-RECV-Key) are known as the Pairwise Master Key 542 (PMK). [IEEE80211i] ciphersuites derive their Transient Session 543 Keys (TSKs) solely from the PMK, whereas the WEP ciphersuite, when 544 used with [IEEE8021X], as noted in [RFC3580], derives its TSKs from 545 both halves of the AAA-Key, the Enc-RECV-Key and the Enc-SEND-Key. 547 Transient EAP Keys (TEKs) 548 Session keys which are used to establish a protected channel 549 between the EAP peer and server during the EAP authentication 550 exchange. The TEKs are appropriate for use with the ciphersuite 551 negotiated between EAP peer and server for use in protecting the 552 EAP conversation. Note that the ciphersuite used to set up the 553 protected channel between the EAP peer and server during EAP 554 authentication is unrelated to the ciphersuite used to subsequently 555 protect data sent between the EAP peer and authenticator. An 556 example TEK key hierarchy is described in Appendix C. 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 559 | | ^ 560 | EAP Method | | 561 | | | 562 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 563 | | | | | 564 | | EAP Method Key | | | 565 | | Derivation | | | 566 | | | | Local to | 567 | | | | EAP | 568 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Method | 569 | | | | | | 570 | | | 571 | | | | | | 572 | | | 573 | V | | | | 574 | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | | 575 | | TEK | | MSK | |EMSK | |IV | | | 576 | |Derivation | |Derivation | |Derivation | |Derivation | | | 577 | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | | 578 | | | | | | 579 | | | | | V 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 581 | | | ^ 582 | | | | 583 | MSK (64B) | EMSK (64B) | IV (64B) | 584 | | | Exported| 585 | | | by | 586 V V V EAP | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ Method| 588 | AAA Key Derivation, | | Known | | 589 | Naming & Binding | |(Not Secret) | | 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ V 591 | ---+ 592 | Transported | 593 | AAA-Key by AAA | 594 | Protocol | 595 V V 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 597 | | ^ 598 | TSK | Ciphersuite | 599 | Derivation | Specific | 600 | | V 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 603 Figure 2 - EAP Key Hierarchy 604 Transient Session Keys (TSKs) 605 Session keys used to protect data which are appropriate for the 606 ciphersuite negotiated between the EAP peer and authenticator. The 607 TSKs are derived from the keying material included in the AAA-Token 608 via the secure association protocol. In the case of IEEE 802.11, 609 the role of the secure association protocol is handled by the 4-way 610 handshake and group key derivation. An example TSK derivation is 611 provided in Appendix D. 613 2.3. Exchanges 615 EAP supports both a two party exchange between an EAP peer and an 616 authenticator, as well as a three party exchange between an EAP peer, an 617 authenticator and an EAP server. 619 Figure 3 illustrates the two party exchange. Here EAP is spoken between 620 the peer and authenticator, encapsulated within a lower layer protocol, 621 such as PPP, defined in [RFC1661] or IEEE 802, defined in [IEEE802]. 623 Since the authenticator acts as an endpoint of the EAP conversation 624 rather than a pass-through, EAP methods are implemented on the 625 authenticator as well as the peer. If the EAP method negotiated between 626 the EAP peer and authenticator supports mutual authentication and key 627 derivation, the EAP Master Session Key (MSK) and Extended Master Session 628 Key (EMSK) are derived on the EAP peer and authenticator and exported by 629 the EAP method. 631 Where no backend authentication server is present, the MSK and EMSK are 632 known only to the peer and authenticator and neither is transported to a 633 third party. As demonstrated in [RoamCERT], despite the absence of a 634 backend authentication server, such exchanges can support roaming 635 between providers; it is even possible to support fast handoff without 636 re-authentication. However, this is typically only possible where both 637 the EAP peer and authenticator support certificate-based authentication, 638 or where the user base is sufficiently small that EAP authentication can 639 occur locally. 641 In order to protect the EAP conversation, the EAP method may negotiate a 642 ciphersuite and derive Transient EAP Keys (TEKs) to provide keys for 643 that ciphersuite in order to protect some or all of the EAP exchange. 644 The TEKs are stored locally within the EAP method and are not exported. 646 Once EAP mutual authentication completes and is successful, the secure 647 association protocol is run between the peer and authenticator. This 648 derives fresh transient session keys (TSKs), provides for the secure 649 negotiation of the ciphersuite used to protect data, and supports mutual 650 proof of possession of the AAA-Key. 652 +-+-+-+-+-+ +-+-+-+-+-+ 653 | | | | 654 | | | | 655 | Cipher- | | Cipher- | 656 | Suite | | Suite | 657 | | | | 658 +-+-+-+-+-+ +-+-+-+-+-+ 659 ^ ^ 660 | | 661 | | 662 | | 663 V V 664 +-+-+-+-+-+ +-+-+-+-+-+ 665 | | | | 666 | |===============| | 667 | |EAP, TEK Deriv.|Authenti-| 668 | |<------------->| cator | 669 | | | | 670 | | Secure Assoc. | | 671 | peer |<------------->| (EAP | 672 | |===============| server) | 673 | | Link layer | | 674 | | (PPP,IEEE802) | | 675 | | | | 676 |MSK,EMSK | |MSK,EMSK | 677 | (TSKs) | | (TSKs) | 678 | | | | 679 +-+-+-+-+-+ +-+-+-+-+-+ 680 ^ ^ 681 | | 682 | MSK, EMSK | MSK, EMSK 683 | | 684 | | 685 +-+-+-+-+-+ +-+-+-+-+-+ 686 | | | | 687 | EAP | | EAP | 688 | Method | | Method | 689 | | | | 690 |(MK,TEKs)| |(MK,TEKs)| 691 | | | | 692 +-+-+-+-+-+ +-+-+-+-+-+ 694 Figure 3 - Relationship between EAP peer and authenticator 695 (acting as an EAP server), where no backend 696 authentication server is present. 698 +-+-+-+-+-+ +-+-+-+-+-+ 699 | | | | 700 | | | | 701 | Cipher- | | Cipher- | 702 | Suite | | Suite | 703 | | | | 704 +-+-+-+-+-+ +-+-+-+-+-+ 705 ^ ^ 706 | | 707 | | 708 | | 709 V V 710 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 711 | |===============| |========| | 712 | |EAP, TEK Deriv.| | | | 713 | |<-------------------------------->| backend | 714 | | | | | | 715 | | Secure Assoc. | | AAA-Key| | 716 | peer |<------------->|Authenti-|<-------| auth | 717 | |===============| cator |========| server | 718 | | Link Layer | | AAA | (EAP | 719 | | (PPP,IEEE 802)| |Protocol| server) | 720 | | | | | | 721 |MSK,EMSK | | MSK | |MSK,EMSK | 722 | (TSKs) | | (TSKs) | | | 723 | | | | | | 724 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 725 ^ ^ 726 | | 727 | MSK, EMSK | MSK, EMSK 728 | | 729 | | 730 +-+-+-+-+-+ +-+-+-+-+-+ 731 | | | | 732 | EAP | | EAP | 733 | Method | | Method | 734 | | | | 735 |(MK,TEKs)| |(MK,TEKs)| 736 | | | | 737 +-+-+-+-+-+ +-+-+-+-+-+ 739 Figure 4 - Pass-through relationship between EAP peer, 740 authenticator and backend authentication server. 742 Where these conditions cannot be met, a backend authentication server is 743 typically required. In this exchange, as described in [RFC3579], the 744 authenticator acts as a pass-through between the EAP peer and a backend 745 authentication server. In this model, the authenticator delegates the 746 access control decision to the backend authentication server, which acts 747 as a Key Distribution Center (KDC), supplying keying material to both 748 the EAP peer and authenticator. 750 Figure 4 illustrates the case where the authenticator acts as a pass- 751 through. Here EAP is spoken between the peer and authenticator as 752 before. The authenticator then encapsulates EAP packets within a AAA 753 protocol such as RADIUS [RFC3579] or Diameter [DiamEAP], and forwards 754 packets to and from the backend authentication server, which acts as the 755 EAP server. Since the authenticator acts as a pass-through, EAP methods 756 (as well as the derived EAP Master Key, and TEKs) reside only on the 757 peer and backend authentication server. 759 On completion of a successful authentication, EAP methods on the EAP 760 peer and EAP server export the Master Session Key (MSK) and Extended 761 Master Session Key (EMSK). The backend authentication server then sends 762 a message to the authenticator indicating that authentication has been 763 successful, providing the AAA-Key within a protected package known as 764 the AAA-Token. Along with the keying material, the AAA-Token contains 765 attributes naming the enclosed keys and providing context. 767 The MSK and EMSK are used to derive the AAA-Key and key name which are 768 enclosed within the AAA-Token, transported to the NAS by the AAA 769 server, and used within the secure association protocol for derivation 770 of Transient Session Keys (TSKs) required for the negotiated 771 ciphersuite. The TSKs are known only to the peer and authenticator. 773 2.4. Security Relationships 775 Figure 5 illustrates the relationship between the peer, authenticator 776 and backend authentication server. As noted in the figure, each party 777 in the exchange mutually authenticates with each of the other parties, 778 and derives a unique key. All parties in the diagram have access to the 779 AAA-Key. 781 EAP peer 782 /\ 783 / \ 784 Protocol: EAP / \ Protocol: Secure Association 785 Auth: Mutual / \ Auth: Mutual 786 Unique keys: MK, / \ Unique keys: TSKs 787 TEKs,EMSK / \ 788 / \ 789 Auth. server +--------------+ Authenticator 790 Protocol: AAA 791 Auth: Mutual 792 Unique key: AAA session key 794 Figure 5: Three-party EAP key distribution 796 The EAP peer and backend authentication server mutually authenticate via 797 the EAP method, and derive the MK, TEKs and EMSK which are known only to 798 them. The TEKs are used to protect some or all of the EAP conversation 799 between the peer and authenticator, so as to guard against modification 800 or insertion of EAP packets by an attacker. The degree of protection 801 afforded by the TEKs is determined by the EAP method; some methods may 802 protect the entire EAP packet, including the EAP header, while other 803 methods may only protect the contents of the Type-Data field, defined in 804 [RFC2284bis]. 806 Since EAP is spoken only between the EAP peer and server, if a backend 807 authentication server is present then the EAP conversation does not 808 provide mutual authentication between the peer and authenticator, only 809 between the EAP peer and EAP server (backend authentication server). As 810 a result, mutual authentication between the peer and authenticator only 811 occurs where a secure association protocol is used, such the unicast and 812 group key derivation handshake supported in [IEEE80211i]. This means 813 that absent use of a secure association protocol, from the point of view 814 of the peer, EAP mutual authentication only proves that the 815 authenticator is trusted by the backend authentication server; the 816 identity of the authenticator is not confirmed. 818 Utilizing the AAA protocol, the authenticator and backend authentication 819 server mutually authenticate and derive session keys known only to them, 820 used to provide per-packet integrity and replay protection, 821 authentication and confidentiality. The MSK is distributed by the 822 backend authentication server to the authenticator over this channel, 823 bound to attributes constraining its usage, as part of the AAA-Token. 824 The binding of attributes to the MSK within a protected package is 825 important so the authenticator receiving the AAA-Token can determine 826 that it has not been compromised, and that the keying material has not 827 been replayed, or mis-directed in some way. 829 3. Security Associations 831 The EAP model has four types of security associations (SAs): 833 [1] An EAP SA. This is an SA between the EAP peer and the EAP server, 834 created as the result of an EAP authentication exchange (phase 1a). 835 This is a bi-directional SA; that is, both parties use the 836 information in the SA for both sending and receiving. 838 [2] A AAA-Key SA, known in [IEEE80211i] as a PMK SA. This is a bi- 839 directional SA between the EAP peer and authenticator. The keying 840 material for the AAA-Key SA (known as the AAA-Key) is derived on 841 the EAP peer and server, and transported by the EAP server to the 842 authenticator (phase 1b). The choice of keying material is 843 proposed by the EAP peer and confirmed by the EAP authenticator 844 during the unicast secure association protocol (phase 2a). 846 [3] A unicast secure association SA. This is a bi-directional SA 847 created as the result of a successful unicast secure association 848 exchange (phase 2a). A unicast secure association SA is bound to a 849 single EAP SA and a single AAA-Key SA. 851 [4] A multicast secure association SA (phase 2b). This SA is created 852 as the result of a successful multicast secure association 853 exchange. This SA may be uni-directional (e.g. 802.11 group-key 854 exchange) or bi-directional depending on the design of the 855 multicast secure association protocol, and can be created either 856 from the unicast secure association SA (phase 2a) or directly as 857 the result of a multicast secure association exchange (phase 2b). 859 3.1. EAP SA 861 An EAP SA includes: 863 the EAP peer and EAP server identities 864 the EAP method type 865 the EAP peer and server nonces 866 the Transient EAP Keys (TEKs) 867 the Master Session Key (MSK) 868 the Extended Master Session Key (EMSK) 870 The EAP SA is not explicitly bound to a particular port on the EAP peer. 871 An EAP peer with multiple ports may create an EAP SA on one port and 872 then choose to use that SA to subsequently create a phase 2 SA on 873 another port. 875 It cannot be assumed that the EAP SA expires after the EAP 876 authentication and key derivation is complete. Some methods may be 877 support "fast resume" by caching EAP SA state on the EAP peer and 878 server. 880 EAP does not support SA lifetime negotiation or an SA "delete" 881 operation, although some EAP methods may support this. Either the EAP 882 peer or EAP server may delete an EAP SA at any time, and methods which 883 allow an EAP SA to persist need to permit the EAP peer and server to 884 recognize when they have gotten out of sync with respect to the EAP SA 885 state. 887 For example, EAP TLS [RFC 2716] supports "fast resume" (TLS session 888 resumption), which assumes that both the EAP peer and server cache EAP 889 master keys (the TLS master secret). An EAP peer attempting a fast 890 resume provides the session-id identifying the session that it wishes to 891 resume. If the EAP server retains the master key corresponding to this 892 session in its cache, then the "fast resume" can proceed; otherwise a 893 full TLS exchange ensues. 895 An EAP peer may negotiate EAP SAs with one or more EAP servers as the 896 result of pre-authentication or AAA load balancing and failover effects. 897 For example, an EAP peer may pre-authenticate to one or more EAP 898 servers, or may be directed to more than one EAP server as the result of 899 an authentication server becoming unreachable. In general, EAP servers 900 cannot be assumed to be synchronized with respect to EAP SA state, 901 particularly since they may not exist within the same administrative 902 domain. Since an EAP SA is typically created prior to secure 903 association, the EAP SA is not bound to a particular target network. 905 3.2. AAA-Key SA 907 An AAA-Key SA includes: 909 the EAP peer (Calling-Station-Id) identifier 910 the EAP authenticator (Called-Station-Id) identifier 911 the AAA-Key 912 the AAA-Key maximum lifetime (if known) 913 the advertised peer and authenticator capabilities 915 The AAA-Key SA is created as the result of the transport of the AAA- 916 Token from the authentication server to the NAS/authenticator. The AAA- 917 Key SA is distinct from the EAP SA in that it is bound to the EAP peer 918 and authenticator ports. This binding occurs during the unicast secure 919 association protocol (phase 2a) when the EAP peer and authenticator 920 prove possession of the AAA-Key, which is transported from the 921 authentication server to the NAS/EAP authenticator after completion of 922 EAP authentication. 924 Since the AAA-Key SA is bound to a particular authenticator port, a 925 NAS/authenticator that operates on a shared use network will share the 926 AAA-Key SA between multiple virtual NAS devices unless a separate port 927 (as identified by the Called-Station-Id) is used for each virtual NAS. 928 This would represent a security vulnerability. 930 In fast handoff, a single EAP SA may be used to establish multiple AAA- 931 Key SAs (see Appendix E for details). Although a AAA-Key SA may not 932 persist longer than the maximum SA lifetime negotiated for an EAP SA 933 (for methods that support such a negotiation), if an EAP SA is deleted 934 by an EAP peer or authenticator, this does not necessarily imply 935 deletion of the child AAA-Key SA. For example, fast handoff keying 936 material provided by an authentication server may continue to be cached 937 by NASes/authenticators after the corresponding EAP SA has been deleted 938 by the authentication server and/or peer. 940 3.3. Unicast Secure Association SA 942 The unicast secure association SA includes: 944 the EAP peer (Calling-Station-Id) identifier 945 the EAP authenticator (Called-Station-Id) identifier 946 the unicast Transient Session Keys (TSKs) 947 the unicast secure association peer nonce 948 the unicast secure association authenticator nonce 949 the negotiated unicast capabilities and unicast ciphersuite. 951 During the phase 2a exchange, the EAP peer and authenticator demonstrate 952 mutual possession of the AAA-Key derived and transported in phase 1; 953 securely negotiate the session capabilities (including unicast 954 ciphersuites), and derive fresh unicast transient session keys. The 955 AAA-Key SA (phase 1b) is therefore used to create the unicast secure 956 association SA (phase 2a), and in the process the phase 2a unicast 957 secure association SA is bound to ports on the EAP peer and 958 authenticator. However in order for a phase 2a security association to 959 be established, it is not necessary for the phase 1a exchange to be 960 rerun each time. This enables the EAP exchange to be bypassed when fast 961 handoff support is desired. 963 Since both peer and authenticator nonces are used in the creation of the 964 unicast secure association SA, the transient session keys (TSKs) are 965 guaranteed to be fresh, even if the AAA-Key is not. As a result one or 966 more unicast secure association SAs (phase 2a) may be derived from a 967 single AAA-Key SA (phase 1b). The phase 2a security associations may 968 utilize the same security parameters (e.g. mode, ciphersuite, etc.) or 969 they may utilize different parameters. 971 A unicast secure association SA (phase 2a) may not persist longer than 972 the maximum lifetime of its parent AAA-Key SA (if known). However, the 973 deletion of a parent EAP or AAA-Key SA does not necessarily imply 974 deletion of the corresponding unicast secure association SA. Similarly, 975 the deletion of a unicast secure association protocol SA does not imply 976 the deletion of the parent AAA-key SA or EAP SA. However, the failure 977 to mutually prove possession of the AAA-Key during the unicast secure 978 association protocol exchange (phase 2a) is grounds for removal of a 979 AAA-Key SA by both parties. 981 An EAP peer may be able to negotiate multiple phase 2a SAs with a single 982 EAP authenticator, or may be able to maintain multiple phase 2a SAs with 983 multiple authenticators, based on a single EAP SA derived in phase 1a. 984 For example, during a re-key of the secure association protocol SA, it 985 is possible for two phase 2a SAs to exist during the period between when 986 the new phase 2a SA parameters (such as the TSKs) are calculated and 987 when they are installed. Except where explicitly specified by the 988 semantics of the unicast secure association protocol, it should not be 989 assumed that the installation of a new phase 2a SA necessarily implies 990 deletion of the old phase 2a SA. 992 On some media (e.g. 802.11) a port on an EAP peer may only establish 993 phase 2a and 2b SAs with a single port of an authenticator within a 994 given Local Area Network (LAN). This implies that the successful 995 negotiation of phase 2a and/or 2b SAs between an EAP peer port and a new 996 authentiator port within a given LAN implies the deletion of existing 997 phase 2a and 2b SAs with authenticators offering access to that Local 998 Area Network (LAN). However, since a given IEEE 820.11 SSID may be 999 comprised of multiple LANs, this does not imply an implicit binding of 1000 phase 2a and 2b SAs to an SSID. 1002 3.4. Multicast Secure Association SA 1004 The multicast secure association SA includes: 1006 the multicast Transient Session Keys 1007 the direction vector (for a uni-directional SA) 1008 the negotiated multicast capabilities and multicast ciphersuite 1010 It is possible for more than one multicast secure association SA to be 1011 derived from a single unicast secure association SA. However, a 1012 multicast secure association SA is bound to a single EAP SA and a single 1013 AAA-Key SA. 1015 During a re-key of the multicast secure association protocol SA, it is 1016 possible for two phase 2b SAs to exist during the period between when 1017 the new phase 2b SA parameters (such as the multicast TSKs) are 1018 calculated and when they are installed. Except where explicitly 1019 specified by the semantics of the multicast secure association protocol, 1020 it should not be assumed that the installation of a new phase 2b SA 1021 necessarily implies deletion of the old phase 2b SA. 1023 A multicast secure association SA (phase 2b) may not persist longer than 1024 the maximum lifetime of its parent AAA-Key or unicast secure association 1025 SA. However, the deletion of a parent EAP, AAA-Key or unicast secure 1026 association SA does not necessarily imply deletion of the corresponding 1027 multicast secure association SA. For example, a unicast secure 1028 association SA may be rekeyed without implying a rekey of the multicast 1029 secure association SA. 1031 Similarly, the deletion of a multicast secure association protocol SA 1032 does not imply the deletion of the parent EAP, AAA-Key or unicast secure 1033 association SA. However, the failure to mutually prove possession of 1034 the AAA-Key during the unicast secure association protocol exchange 1035 (phase 2a) is grounds for removal of the AAA-Key, unicast secure 1036 association and multicast secure association SAs. 1038 3.5. Key Naming 1040 In order to support the correct processing of phase 2 security 1041 associations, the secure association (phase 2) protocol supports the 1042 naming of phase 2 security associations and associated transient session 1043 keys, so that the correct set of transient session keys can be 1044 identified for processing a given packet. Explicit creation and 1045 deletion operations are also typically supported so that establishment 1046 and re-establishment of transient session keys can be synchronized 1047 between the parties. 1049 In order to securely bind the EAP security association (phase 1) to its 1050 child phase 2 security association, the phase 2 secure association 1051 protocol allows the EAP peer and authenticator to mutually prove 1052 possession of the EAP (phase 1) keying material derived during the EAP 1053 exchange (phase 1). In order to avoid confusion in the case where an 1054 EAP peer has more than one EAP security association (phase 1) applicable 1055 to establishment of a given phase 2 security association, the secure 1056 association protocol (phase 2) supports key naming so that the 1057 appropriate phase 1 keying material can be utilized by both parties in 1058 the secure association protocol exchange. 1060 As noted earlier, the discovery phase (phase 0) may be insecure so that 1061 in order to prevent spoofing of discovery packets, the secure 1062 association (phase 2) protocol should support the secure verification of 1063 discovered capabilities, including ciphersuites and other security 1064 parameters. This is more scalable than attempting to configure the 1065 supported capabilities on each peer and authenticator and more secure 1066 than unprotected capabilities negotiation. 1068 For example, a peer might be pre-configured with policy indicating the 1069 ciphersuite to be used in communicating with a given authenticator. 1070 Within PPP, the ciphersuite is negotiated within the Encryption Control 1071 Protocol (ECP), after EAP authentication is completed. Within 1072 [IEEE80211i], the AP ciphersuites are advertised in the Beacon and Probe 1073 Responses, and are securely verified during a 4-way exchange after EAP 1074 authentication has completed. 1076 As part of the secure association protocol (phase 2), it is necessary to 1077 bind the Transient Session Keys (TSKs) to the keying material provided 1078 in the AAA-Token. This ensures that the EAP peer and authenticator are 1079 both clear about what key to use to provide mutual proof of possession. 1080 Keys within the EAP key hierarchy are named as follows: 1082 EAP SA name 1083 The EAP security association is negotiated between the EAP peer and 1084 EAP server, and is uniquely named as follows . 1086 Here the EAP peer name and EAP server name are the identifiers 1087 securely exchanged within the EAP method. Since multiple EAP SAs 1088 may exist between an EAP peer and EAP server, the EAP peer nonce 1089 and EAP server nonce allow EAP SAs to be differentiated. The 1090 inclusion of the Method Type in the EAP SA name ensures that each 1091 EAP method has a distinct EAP SA space. 1093 MK Name 1094 The EAP Master Key, if supported by an EAP method, is named by the 1095 concatenation of the EAP SA name and a method-specific session-id. 1097 MSK Name 1098 The MSK is named by the concatenation of the EAP SA name, "MSK" and 1099 the authenticator name, since the MSK may only be bound to a single 1100 authenticator. While the AAA server has several potentially unique 1101 authenticator identifiers (including the NAS-Identifier, NAS-IP- 1102 Address, and NAS-IPv6-Address attributes), only the Called-Station- 1103 Id is guaranteed to be known by the EAP peer, EAP server and 1104 authenticator and as a result, this is used as the NAS name. 1106 EMSK Name 1107 The EMSK is named by the concatenation of the EAP SA name and 1108 "EMSK". 1110 4. Threat Model 1112 4.1. Security Assumptions 1114 The security properties of the EAP exchange are dependent on each leg of 1115 the triangle: the selected EAP method, AAA protocol and the secure 1116 association protocol. 1118 Assuming that the AAA protocol provides protection against rogue 1119 authenticators forging their identity, then the AAA-Token can be assumed 1120 to be sent to the correct authenticator, and where it is wrapped 1121 appropriately, it can be assumed to be immune to compromise by a 1122 snooping attacker. 1124 Where an untrusted AAA intermediary is present, the AAA-Token must not 1125 be provided to the intermediary so as to avoid compromise of the AAA- 1126 Token. This can be avoided by use of re-direct as defined in 1127 [DiamBase]. 1129 When EAP is used for authentication on PPP or wired IEEE 802 networks, 1130 it is typically assumed that the link is physically secure, so that an 1131 attacker cannot gain access to the link, or insert a rogue device. EAP 1132 methods defined in [RFC2284bis] reflect this usage model. These include 1133 EAP MD5, as well as One-Time Password (OTP) and Generic Token Card. 1134 These methods support one-way authentication (from EAP peer to 1135 authenticator) but not mutual authentication or key derivation. As a 1136 result, these methods do not bind the initial authentication and 1137 subsequent data traffic, even when the the ciphersuite used to protect 1138 data supports per-packet authentication and integrity protection. As a 1139 result, EAP methods not supporting mutual authentication are vulnerable 1140 to session hijacking as well as attacks by rogue devices. 1142 On wireless networks such as IEEE 802.11 [IEEE80211], these attacks 1143 become easy to mount, since any attacker within range can access the 1144 wireless medium, or act as an access point. As a result, new 1145 ciphersuites have been proposed for use with wireless LANs [IEEE80211i] 1146 which provide per-packet authentication, integrity and replay 1147 protection. In addition, mutual authentication and key derivation, 1148 provided by methods such as EAP TLS [RFC2716] are required [IEEE80211i], 1149 so as to address the threat of rogue devices, and provide keying 1150 material to bind the initial authentication to subsequent data traffic. 1152 If the selected EAP method does not support mutual authentication, then 1153 the peer will be vulnerable to attack by rogue authenticators and 1154 backend authentication servers. If the EAP method does not derive keys, 1155 then TSKs will not be available for use with a negotiated ciphersuite, 1156 and there will be no binding between the initial EAP authentication and 1157 subsequent data traffic, leaving the session vulnerable to hijack. 1159 If the authenticator and backend authentication server do not mutually 1160 authenticate, then the peer will be vulnerable to rogue backend 1161 authentication servers, authenticators, or both. If there is no per- 1162 packet authentication, integrity and replay protection between the 1163 authenticator and backend authentication server, then an attacker can 1164 spoof or modify packets in transit. If the backend authentication 1165 server does not protect against authenticator masquerade, or provide the 1166 proper binding of the AAA-Key to the session within the AAA-Token, then 1167 one or more AAA-Keys may be sent to an unauthorized party, and an 1168 attacker may be able to gain access to the network. If the AAA-Token is 1169 provided to an untrusted AAA intermediary, then that intermediary may be 1170 able to modify the AAA-Key, or the attributes associated with it, as 1171 described in [RFC2607]. 1173 If the secure association protocol does not provide mutual proof of 1174 possession of the AAA-Key material, then the peer will not have 1175 assurance that it is connected to the correct authenticator, only that 1176 the authenticator and backend authentication server share a trust 1177 relationship (since AAA protocols support mutual authentication). This 1178 distinction can become important when multiple authenticators receive 1179 AAA-Keys from the backend authentication server, such as where fast 1180 handoff is supported. If the TSK derivation does not provide for 1181 protected ciphersuite and capabilities negotiation, then downgrade 1182 attacks are possible. 1184 4.2. Security Requirements 1186 This section describes the security requirements for EAP methods, AAA 1187 protocols, secure association protocols and Ciphersuites. These 1188 requirements MUST be met by specifications requesting publication as an 1189 RFC. Based on these requirements, the security properties of EAP 1190 exchanges are analyzed. 1192 4.2.1. EAP method requirements 1194 Key usage 1195 Key material exported by EAP methods MUST NOT be used directly to 1196 protect data. 1198 Mutual authentication 1199 EAP Methods deriving keys MUST provide for mutual authentication 1200 between the EAP peer and EAP Server. 1202 State synchronization 1203 EAP peers, authenticators and authentication servers MUST be 1204 prepared for situations in which one or more of the parties have 1205 discarded an EAP SA (phase 1), which is still valid on another 1206 party. 1208 TEK derivation 1209 Methods deriving keys MUST specify how Transient EAP Keys (TEKs) 1210 are derived. TEKs MUST remain local to the EAP method and MUST NOT 1211 be provided to third parties. 1213 MSK and EMSK 1214 EAP methods supporting key derivation MUST export two quantities of 1215 at least 64 octets each, known as the Master Session Key (MSK), and 1216 the Extended Master Session Key (EMSK). 1218 Cryptographic separation 1219 Methods supporting key derivation MUST demonstrate cryptographic 1220 separation between the TEK, MSK and EMSK branches of the EAP key 1221 hierarchy. Without violating a fundamental cryptographic 1222 assumption (such as the non-invertibility of a one-way function) an 1223 attacker recovering the TEKs, MSK or EMSK MUST NOT be able to 1224 recover the other quantities with a level of effort less than brute 1225 force. Since Transient Session Keys (TSKs) are derived from the 1226 MSK, if branch independence holds, then it is also true that the 1227 TSKs are cryptographically separate from the EMSK and TEKs. 1229 EMSK reservation 1230 While the EMSK is exported by the EAP method, its use is reserved, 1231 and as a result it MUST remain known only to the EAP peer and 1232 server and MUST NOT be provided to third parties. Since the EMSK is 1233 the only keying material exported by an EAP method that is neither 1234 provided to a third party nor a known quantity, it is attractive 1235 for use in future applications such as fast handoff or man-in-the- 1236 middle detection. Given its potential future uses, damage due to 1237 EMSK compromise is second only in effect to compromise of the MK, 1238 yielding an attacker the ability to access the network at will, and 1239 to decrypt past and future data traffic. 1241 TEK derivation 1242 In order to establish a protected channel between the EAP peer and 1243 server as part of the EAP exchange, a ciphersuite needs to be 1244 negotiated and suitable keys need to be provided (known as the 1245 transient EAP keys). The ciphersuite used to protect the EAP 1246 exchange between the peer and server is distinct from the 1247 ciphersuite negotiated between the peer and authenticator, used to 1248 protect data. Where a protected channel is established within the 1249 EAP method, the method specification MUST specify the mechanism by 1250 which the EAP ciphersuite is negotiated, as well as the algorithms 1251 for derivation of TEKs. 1253 Ciphersuite Independence 1254 Keying material exported by EAP methods MUST be independent of the 1255 ciphersuite negotiated to protect data. 1257 Key Strength 1258 The strength of Transient Session Keys (TSKs) and Transient EAP 1259 Keys (TEKs) used to protect data is ultimately dependent on the 1260 strength of keys generated by the EAP method. If EAP method does 1261 not produce keying material of sufficient strength, then the TSKs 1262 and TEKs may be subject to brute force attack. EAP methods 1263 supporting key derivation MUST be capable of generating an MSK and 1264 EMSK, each with an effective key strength of at least 128 bits. 1265 More details on key strength are provided in Section 6.1. 1267 Resilience against compromise 1268 In order to protect against compromise of the AAA-Token, EAP 1269 methods MUST demonstrate that compromise of the MSK or EMSK of a 1270 given EAP security association does not enable compromise of 1271 subsequent or prior MSKs or EMSKs derived between the EAP peer and 1272 EAP server. 1274 Freshness 1275 In order to support key naming and assure freshness of TSKs even in 1276 cases where one party may not have a high quality random number 1277 generator, EAP methods generating keys MUST support a two-nonce 1278 exchange in the derivation of the MSK and EMSK, using nonces of at 1279 least 128-bits. 1281 Known-good algorithms 1282 The development and validation of key derivation algorithms is 1283 difficult, and as a result EAP methods SHOULD reuse existing key 1284 derivation algorithms, rather than inventing new ones. EAP methods 1285 requesting publication as an RFC MUST provide citations to 1286 literature justifying the security of the chosen algorithms. EAP 1287 methods SHOULD utilize well established and analyzed mechanisms for 1288 MSK, EMSK, TSK and TEK derivation. 1290 4.2.2. AAA Protocol Requirements 1292 AAA protocols suitable for use in transporting EAP MUST provide the 1293 following facilities: 1295 Security services 1296 AAA protocols used for transport of EAP keying material MUST 1297 implement and SHOULD use per-packet integrity and authentication, 1298 replay protection and confidentiality. These requirements are met 1299 by Diameter EAP [DiamEAP], as well as RADIUS over IPsec [RFC3579]. 1301 Session Keys 1302 AAA protocols used for transport of EAP keying material MUST 1303 implement and SHOULD use session keys, as in Diameter EAP 1304 [DiamEAP] and RADIUS over IPsec [RFC3579], rather than using a 1305 static key, as originally defined in RADIUS [RFC2865]. 1307 Mutual authentication 1308 AAA protocols used for transport of EAP keying material MUST 1309 provide for mutual authentication between the authenticator and 1310 backend authentication server. These requirements are met by 1311 Diameter EAP [DiamEAP] as well as by RADIUS/EAP [RFC3579]. 1313 Forgery protection 1314 AAA protocols used for transport of EAP keying material SHOULD 1315 provide protection against rogue authenticators masquerading as 1316 other authenticators. This can be accomplished, for example, by 1317 requiring that AAA agents check the source address of packets 1318 against the origin attributes (Origin-Host AVP in Diameter, NAS-IP- 1319 Address, NAS-IPv6-Address, NAS-Identifier in RADIUS). For details, 1320 see Section 4.3.7 of [RFC3579]. 1322 Key transport 1323 Since EAP methods do not export Transient Session Keys (TSKs) in 1324 order to maintain media and ciphersuite independence, the AAA 1325 server MUST NOT transport TSKs from the backend authentication 1326 server to authenticator. 1328 Key transport specification 1329 In order to enable backend authentication servers to provide keying 1330 material to the authenticator in a well defined format, AAA 1331 protocols suitable for use with EAP MUST define the format and 1332 wrapping of the AAA-Token. 1334 EMSK transport 1335 Since the EMSK is a secret known only to the backend authentication 1336 server and peer, the AAA-Token MUST NOT transport the EMSK from the 1337 backend authentication server to the authenticator. 1339 AAA-Token protection 1340 To ensure against compromise, the AAA-Token MUST be integrity 1341 protected, authenticated, replay protected and encrypted in 1342 transit, using well-established cryptographic algorithms. 1344 Session Keys 1345 The AAA-Token SHOULD be protected with session keys as in Diameter 1346 [DiamBASE] or RADIUS over IPsec [RFC3579] rather than static keys, 1347 as in [RFC2548]. 1349 Key naming 1350 In order to ensure against confusion between the appropriate keying 1351 material to be used in a given secure association protocol 1352 exchange, the AAA-Token SHOULD include explicit key names and 1353 context appropriate for informing the authenticator how the keying 1354 material is to be used. 1356 Key Compromise 1357 Where untrusted intermediaries are present, the AAA-Token SHOULD 1358 NOT be provided to the intermediaries. In Diameter, handling of 1359 keys by intermediaries can be avoided using Redirect functionality 1360 [DiamBASE]. 1362 4.2.3. Secure Association Protocol Requirements 1364 The Secure Association Protocol supports the following: 1366 Mutual proof of possession 1367 The peer and authenticator MUST each demonstrate possession of the 1368 keying material transported between the AAA server and 1369 authenticator (AAA-Key). 1371 Key Naming 1372 The Secure Association Protocol MUST explicitly name the keys used 1373 in the proof of possession exchange, so as to prevent confusion 1374 when more than one set of keying material could potentially be used 1375 as the basis for the exchange. 1377 Creation and Deletion 1378 In order to support the correct processing of phase 2 security 1379 associations, the secure association (phase 2) protocol MUST 1380 support the naming of phase 2 security associations and associated 1381 transient session keys, so that the correct set of transient 1382 session keys can be identified for processing a given packet. The 1383 phase 2 secure association protocol also MUST support transient 1384 session key activation and SHOULD support deletion, so that 1385 establishment and re-establishment of transient session keys can be 1386 synchronized between the parties. 1388 Integrity and Replay Protection 1389 The Secure Association Protocol MUST support integrity and replay 1390 protection of all messages. 1392 Direct operation 1393 Since the phase 2 secure association protocol is concerned with the 1394 establishment of security associations between the EAP peer and 1395 authenticator, including the derivation of transient session keys, 1396 only those parties have "a need to know" the transient session 1397 keys. The secure association protocol MUST operate directly 1398 between the peer and authenticator, and MUST NOT be passed-through 1399 to the backend authentication server, or include additional 1400 parties. 1402 Derivation of transient session keys 1403 The secure association protocol negotiation MUST support derivation 1404 of unicast and multicast transient session keys suitable for use 1405 with the negotiated ciphersuite. 1407 TSK freshness 1408 The secure association (phase 2) protocol MUST support the 1409 derivation of fresh unicast and multicast transient session keys, 1410 even when the keying material provided by the AAA server is not 1411 fresh. This is typically supported by including an exchange of 1412 nonces within the secure association protocol. 1414 Bi-directional operation 1415 While some ciphersuites only require a single set of transient 1416 session keys to protect traffic in both directions, other 1417 ciphersuites require a unique set of transient session keys in each 1418 direction. The phase 2 secure association protocol SHOULD provide 1419 for the derivation of unicast and multicast keys in each direction, 1420 so as not to require two separate phase 2 exchanges in order to 1421 create a bi-directional phase 2 security association. 1423 Secure capabilities negotiation 1424 The Secure Association Protocol MUST support secure capabilities 1425 negotiation. This includes security parameters such as the security 1426 association identifier (SAID) and ciphersuites. It also includes 1427 confirmation of the capabilities discovered during the discovery 1428 phase (phase 0), so as to ensure that the announced capabilities 1429 have not been forged. 1431 4.2.4. Ciphersuite Requirements 1433 Ciphersuites suitable for keying by EAP methods MUST provide the 1434 following facilities: 1436 TSK derivation 1437 In order to allow a ciphersuite to be usable within the EAP keying 1438 framework, a specification MUST be provided describing how 1439 transient session keys suitable for use with the ciphersuite are 1440 derived from the AAA-Key. 1442 EAP method independence 1443 Algorithms for deriving transient session keys from the AAA-Key 1444 MUST NOT depend on the EAP method. However, algorithms for 1445 deriving TEKs MAY be specific to the EAP method. 1447 Cryptographic separation 1448 The TSKs derived from the AAA-Key MUST be cryptographically 1449 separate from each other. Similarly, TEKs MUST be 1450 cryptographically separate from each other. In addition, the TSKs 1451 MUST be cryptographically separate from the TEKs. 1453 5. IANA Considerations 1455 This specification does not create any new registries, or define any new 1456 EAP codes or types. 1458 6. Security Considerations 1460 6.1. Key Strength 1462 In order to guard against brute force attacks, EAP methods deriving keys 1463 need to be capable of generating keys with an appropriate effective 1464 symmetric key strength. In order to ensure that key generation is not 1465 the weakest link, it is necessary for EAP methods utilizing public key 1466 cryptography to choose a public key that has a cryptographic strength 1467 meeting the symmetric key strength requirement. 1469 As noted in Section 5 of [KeyLen], this results in the following 1470 required RSA or DH module and DSA subgroup size in bits, for a given 1471 level of attack resistance in bits: 1473 Attack Resistance RSA or DH Modulus DSA subgroup 1474 (bits) size (bits) size (bits) 1475 ----------------- ----------------- ------------ 1476 70 947 128 1477 80 1228 145 1478 90 1553 153 1479 100 1926 184 1480 150 4575 279 1481 200 8719 373 1482 250 14596 475 1484 6.2. Key Wrap 1486 As described in [RFC3579], Section 4.3, known problems exist in the key 1487 wrap specified in [RFC2548]. Where the same RADIUS shared secret is used 1488 by a PAP authenticator and an EAP authenticator, there is a 1489 vulnerability to known plaintext attack. Since RADIUS uses the shared 1490 secret for multiple purposes, including per-packet authentication, 1491 attribute hiding, considerable information is exposed about the shared 1492 secret with each packet. This exposes the shared secret to dictionary 1493 attacks. MD5 is used both to compute the RADIUS Response Authenticator 1494 and the Message-Authenticator attribute, and some concerns exist 1495 relating to the security of this hash [MD5Attack]. As discussed in 1496 [RFC3579], Section 4.2, these and other RADIUS vulnerabilities may be 1497 addressed by running RADIUS over IPsec. 1499 Where an untrusted AAA intermediary is present (such as a RADIUS proxy 1500 or a Diameter agent), and data object security is not used, the MSK may 1501 be recovered by an attacker in control of the untrusted intermediary. 1502 Possession of the MSK enables decryption of data traffic sent between 1503 the peer and a specific authenticator; however where Perfect Forward 1504 Secrecy (PFS) is implemented, compromise of the MSK does enable an 1505 attacker to impersonate the peer to another authenticator, since that 1506 requires possession of the MK or EMSK, which are not transported by the 1507 AAA protocol. This vulnerability may be mitigated by implementation of 1508 redirect functionality, as provided in [DiamBASE]. 1510 6.3. Man-in-the-middle Attacks 1512 As described in [MiTM], EAP method sequences and compound authentication 1513 mechanisms may be subject to man-in-the-middle attacks. When such 1514 attacks are successfully carried out, the attacker acts as an 1515 intermediary between a victim and a legitimate authenticator. This 1516 allows the attacker to authenticate successfully to the authenticator, 1517 as well as to obtain access to the network. 1519 In order to prevent these attacks, [MiTM] recommends derivation of a 1520 compound key by which the EAP peer and authenticator can prove that they 1521 have participated in the entire EAP exchange. Since the compound key 1522 must not be known to an attacker posing as an authenticator, and yet 1523 must be derived from quantities that are exported by EAP methods, it may 1524 be desirable to derive the compound key from a portion of the EMSK. In 1525 order to provide proper key hygiene, it is recommended that the compound 1526 key used for man-in-the-middle protection be cryptographically separate 1527 from other keys derived from the EMSK, such as fast handoff keys, 1528 discussed in Appendix E. 1530 6.4. Impersonation 1532 Both the RADIUS and Diameter protocols are potentially vulnerable to 1533 impersonation by a rogue authenticator. 1535 When RADIUS requests are forwarded by a proxy, the NAS-IP-Address or 1536 NAS-IPv6-Address attributes may not correspond to the source address. 1537 Since the NAS-Identifier attribute need not contain an FQDN, it also may 1538 not correspond to the source address, even indirectly. [RFC2865] 1539 Section 3 states: 1541 A RADIUS server MUST use the source IP address of the RADIUS 1542 UDP packet to decide which shared secret to use, so that 1543 RADIUS requests can be proxied. 1545 This implies that it is possible for a rogue authenticator to forge NAS- 1546 IP-Address, NAS-IPv6-Address or NAS-Identifier attributes within a 1547 RADIUS Access-Request in order to impersonate another authenticator. 1548 Among other things, this can result in messages (and MSKs) being sent to 1549 the wrong authenticator. Since the rogue authenticator is authenticated 1550 by the RADIUS proxy or server purely based on the source address, other 1551 mechanisms are required to detect the forgery. In addition, it is 1552 possible for attributes such as the Called-Station-Id and Calling- 1553 Station-Id to be forged as well. 1555 As recommended in [RFC3579], this vulnerability can be mitigated by 1556 having RADIUS proxies check authenticator identification attributes 1557 against the source address. 1559 To allow verification of session parameters such as the Called-Station- 1560 Id and Calling-Station-Id, these can be sent by the EAP peer to the 1561 server, protected by the TEKs. The RADIUS server can then check the 1562 parameters sent by the EAP peer against those claimed by the 1563 authenticator. If a discrepancy is found, an error can be logged. 1565 While [DiamBASE] requires use of the Route-Record AVP, this utilizes 1566 FQDNs, so that impersonation detection requires DNS A/AAAA and PTR RRs 1567 to be properly configured. As a result, it appears that Diameter is as 1568 vulnerable to this attack as RADIUS, if not more so. To address this 1569 vulnerability, it is necessary to allow the backend authentication 1570 server to communicate with the authenticator directly, such as via the 1571 redirect functionality supported in [DiamBase]. 1573 7. References 1575 7.1. Normative References 1577 [RFC1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", 1578 STD 51, RFC 1661, July 1994. 1580 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1581 Requirement Levels", BCP 14, RFC 2119, March 1997. 1583 [RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an 1584 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1585 October 1998. 1587 [RFC2284bis] Blunk, L., et al. "Extensible Authentication Protocol 1588 (EAP)", Internet draft (work in progress), draft-ietf- 1589 eap-rfc2284bis-04.txt, June 2003. 1591 [IEEE802] IEEE Standards for Local and Metropolitan Area Networks: 1592 Overview and Architecture, ANSI/IEEE Std 802, 1990. 1594 7.2. Informative References 1596 [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 1597 793, September 1981. 1599 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1600 April 1992. 1602 [RFC1968] Meyer, G., "The PPP Encryption Protocol (ECP)", RFC 1968, 1603 June 1996. 1605 [RFC2104] Krawczyk, et al., "HMAC: Keyed-Hashing for Message 1606 Authentication", RFC 2104, February 1997. 1608 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1609 RFC 2246, November 1998. 1611 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 1612 (IKE)", RFC 2409, November 1998. 1614 [RFC2419] Sklower, K. and G. Meyer, "The PPP DES Encryption 1615 Protocol, Version 2 (DESE-bis)", RFC 2419, September 1616 1998. 1618 [RFC2420] Hummert, K., "The PPP Triple-DES Encryption Protocol 1619 (3DESE)", RFC 2420, September 1998. 1621 [RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an 1622 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1623 October 1998. 1625 [RFC2516] Mamakos, L., "A Method for Transmitting PPP Over Ethernet 1626 (PPPoE)", RFC 2516, February 1999. 1628 [RFC2548] Zorn, G., "Microsoft Vendor-Specific RADIUS Attributes", 1629 RFC 2548, March 1999. 1631 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 1632 Implementation in Roaming", RFC 2607, June 1999. 1634 [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication 1635 Protocol", RFC 2716, October 1999. 1637 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, 1638 "Remote Authentication Dial In User Service (RADIUS)", 1639 RFC 2865, June 2000. 1641 [RFC2960] R. Stewart et al., "Stream Control Transmission 1642 Protocol", RFC 2960, October 2000. 1644 [RFC3078] Pall, G. and G. Zorn, "Microsoft Point-to-Point 1645 Encryption (MPPE) RFC 3078, March 2001. 1647 [RFC3079] Zorn, G. "Deriving Keys for use with Microsoft Point-to- 1648 Point Encryption (MPPE)," RFC 3079, March 2001. 1650 [RFC3394] R. Housley, "Advance Encryption Standard (AES) Key Wrap 1651 Algorithm", RFC 3394, September 2002. 1653 [RFC3580] Congdon, P., et al., "IEEE 802.1X RADIUS Usage 1654 Guidelines", RFC 3580, August 2003. 1656 [FIPSDES] National Bureau of Standards, "Data Encryption Standard", 1657 FIPS PUB 46 (January 1977). 1659 [DESMODES] National Bureau of Standards, "DES Modes of Operation", 1660 FIPS PUB 81 (December 1980). 1662 [FIPS197] FIPS PUB 197, Advanced Encryption Standard (AES), 2001 1663 November 26H. 1665 [SHA] National Institute of Standards and Technology (NIST), 1666 "Announcing the Secure Hash Standard," FIPS 180-1, U.S. 1667 Department of Commerce, 04/1995 1669 [IEEE80211] Information technology - Telecommunications and 1670 information exchange between systems - Local and 1671 metropolitan area networks - Specific Requirements Part 1672 11: Wireless LAN Medium Access Control (MAC) and 1673 Physical Layer (PHY) Specifications, IEEE Std. 1674 802.11-1997, 1997. 1676 [IEEE8021X] IEEE Standards for Local and Metropolitan Area Networks: 1677 Port based Network Access Control, IEEE Std 802.1X-2001, 1678 June 2002. 1680 [IEEE80211f] IEEE 802.11F, "Recommended Practice for Multi-Vendor 1681 Access Point Interoperability via an Inter-Access Point 1682 Protocol Across Distribution Systems Supporting IEEE 1683 802.11 Operation", July 2003. 1685 [IEEE80211i] IEEE Draft 802.11I/D5.0, "Draft Supplement to STANDARD 1686 FOR Telecommunications and Information Exchange between 1687 Systems - LAN/MAN Specific Requirements - Part 11: 1688 Wireless Medium Access Control (MAC) and physical layer 1689 (PHY) specifications: Specification for Enhanced 1690 Security", August 2003. 1692 [EAPAPI] Microsoft Developer Network, "Windows 2000 EAP API", 1693 August 2000, http://msdn.microsoft.com/library/ 1694 default.asp?url=/library/en-us/eap/eapport_0fj9.asp 1696 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support For Extensible 1697 Authentication Protocol (EAP)", RFC 3579, August 2003. 1699 [RoamCERT] Aboba, B., "Certificate-Based Roaming", Internet draft 1700 (work in progress), draft-ietf-roamops-cert-02.txt, April 1701 1999. 1703 [DiamBASE] Calhoun, P., et al., "Diameter Base Protocol", Internet 1704 draft (work in progress), draft-ietf-aaa-diameter-17.txt, 1705 December 2002. 1707 [DiamEAP] Eronen, P., et al., "Diameter Extensible Authentication 1708 Protocol (EAP) Application", Internet draft (work in 1709 progress), draft-ietf-aaa-eap-02.txt, June 2003. 1711 [Handoff] Arbaugh, B. and B. Aboba, "Experimental Handoff Extension 1712 to RADIUS", Internet draft (work in progress), draft- 1713 irtf-aaaarch-handoff-02.txt, June 2003. 1715 [IEEE-02-758] Mishra, A., Shin, M., Arbaugh, W., Lee, I., Jang, K., 1716 "Proactive Caching Strategies for IAPP Latency 1717 Improvement during 802.11 Handoff", IEEE 802.11 Working 1718 Group, IEEE-02-758r1-F, November 2002. 1720 [IEEE-03-084] Mishra, A., Shin, M., Arbaugh, W., Lee, I., Jang, K., 1721 "Proactive Key Distribution to support fast and secure 1722 roaming", IEEE 802.11 Working Group, IEEE-03-084r1-I, 1723 http://www.ieee802.org/11/Documents/DocumentHolder/3-084.zip, 1724 January 2003. 1726 [IEEE-03-155] Aboba, B., "Fast Handoff Issues", IEEE 802.11 Working 1727 Group, IEEE-03-155r0-I, 1728 http://www.ieee802.org/11/Documents/DocumentHolder/3-155.zip, 1729 March 2003. 1731 [KeyLen] Orman, H., and P. Hoffman, "Determining Strengths For 1732 Public Keys Used For Exchanging Symmetric Keys", Internet 1733 draft (work in progress), draft-orman-public-key- 1734 lengths-05.txt, December 2001. 1736 [8021XHandoff] Pack, S. and Y. Choi, "Pre-Authenticated Fast Handoff in 1737 a Public Wireless LAN Based on IEEE 802.1X Model", School 1738 of Computer Science and Engineering, Seoul National 1739 University, Seoul, Korea, 2002. 1741 [MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent Attack", 1742 CryptoBytes Vol.2 No.2, Summer 1996. 1744 [MiTM] Puthenkulam, J., et al, "The Compound Authentication 1745 Binding Problem", Internet draft (work in progress), 1746 draft-puthekulam-eap-binding-03.txt, June 2003. 1748 Appendix A - Ciphersuite Keying Requirements 1750 To date, PPP and IEEE 802.11 ciphersuites are suitable for keying by 1751 EAP. This Appendix describes the keying requirements of common PPP and 1752 802.11 ciphersuites. 1754 PPP ciphersuites include DESEbis [RFC2419], 3DES [RFC2420], and MPPE 1755 [RFC3078]. The DES algorithm is described in [FIPSDES], and DES modes 1756 (such as CBC, used in [RFC2419] and DES-EDE3-CBC, used in [RFC2420]) are 1757 described in [DESMODES]. For PPP DESEbis, a single 56-bit encryption 1758 key is required, used in both directions. For PPP 3DES, a 168-bit 1759 encryption key is needed, used in both directions. As described in 1760 [RFC2419] for DESEbis and [RFC2420] for 3DES, the IV, which is different 1761 in each direction, is "deduced from an explicit 64-bit nonce, which is 1762 exchanged in the clear during the [ECP] negotiation phase." There is 1763 therefore no need for the IV to be provided by EAP. 1765 For MPPE, 40-bit, 56-bit or 128-bit encryption keys are required in each 1766 direction, as described in [RFC3078]. No initialization vector is 1767 required. 1769 While these PPP ciphersuites provide encryption, they do not provide 1770 per-packet authentication or integrity protection, so an authentication 1771 key is not required in either direction. 1773 Within [IEEE80211], Transient Session Keys (TSKs) are required both for 1774 unicast traffic as well as for multicast traffic, and therefore separate 1775 key hierarchies are required for unicast keys and multicast keys. IEEE 1776 802.11 ciphersuites include WEP-40, described in [IEEE80211], which 1777 requires a 40-bit encryption key, the same in either direction; and 1778 WEP-128, which requires a 104-bit encryption key, the same in either 1779 direction. These ciphersuites also do not support per-packet 1780 authentication and integrity protection. In addition to these unicast 1781 keys, authentication and encryption keys are required to wrap the 1782 multicast encryption key. 1784 Recently, new ciphersuites have been proposed for use with IEEE 802.11 1785 that provide per-packet authentication and integrity protection as well 1786 as encryption [IEEE80211i]. These include TKIP, which requires a single 1787 128-bit encryption key and a 128-bit authentication key (used in both 1788 directions); AES CCMP, which requires a single 128-bit key (used in both 1789 directions) in order to authenticate and encrypt data; and WRAP, which 1790 requires a single 128-bit key (used in both directions). 1792 As with WEP, authentication and encryption keys are also required to 1793 wrap the multicast encryption (and possibly, authentication) keys. 1795 Appendix B - TEK Hierarchy 1797 Figure B-1 illustrates the TEK key hierarchy for EAP-TLS [RFC2716], 1798 which is based on the TLS key hierarchy described in [RFC2246]. The 1799 TLS-negotiated ciphersuite is used to set up a protected channel for use 1800 in protecting the EAP conversation, keyed by the derived TEKs. The TEK 1801 derivation proceeds as follows: 1803 master_secret = TLS-PRF-48(pre_master_secret, "master secret", 1804 client.random || server.random) 1805 TEK = TLS-PRF-X(master_secret, "key expansion", 1806 server.random || client.random) 1807 Where: 1808 TLS-PRF-X = TLS pseudo-random function defined in [RFC2246], 1809 computed to X octets. 1810 master_secret = TLS term for the MK. 1812 | | | 1813 | | pre_master_secret | 1814 server| | | client 1815 Random| V | Random 1816 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1817 | | | | 1818 | | | | 1819 +---->| master_secret |<------+ 1820 | | (MK) | | 1821 | | | | 1822 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1823 | | | 1824 | | | 1825 | | | 1826 V V V 1827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1828 | | 1829 | | 1830 | Key Block | 1831 | (TEKs) | 1832 | | 1833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1834 | | | | | | 1835 | client | server | client | server | client | server 1836 | MAC | MAC | write | write | IV | IV 1837 | | | | | | 1838 V V V V V V 1840 Figure B-1 - TLS [RFC2246] Key Hierarchy 1841 Appendix C - MSK and EMSK Hierarchy 1843 In EAP-TLS [RFC2716], the MSK is divided into two halves, corresponding 1844 to the "Peer to Authenticator Encryption Key" (Enc-RECV-Key, 32 octets, 1845 also known as the PMK) and "Authenticator to Peer Encryption Key" (Enc- 1846 SEND-Key, 32 octets). In [RFC2548], the Enc-RECV-Key (the PMK) is 1847 transported in the MS-MPPE-Recv-Key attribute, and the Enc-SEND-Key is 1848 transported in the MS-MPPE-Send-Key attribute. 1850 The EMSK is also divided into two halves, corresponding to the "Peer to 1851 Authenticator Authentication Key" (Auth-RECV-Key, 32 octets) and 1852 "Authenticator to Peer Authentication Key" (Auth-SEND-Key, 32 octets). 1853 The IV is a 64 octet quantity that is a known value; octets 0-31 are 1854 known as the "Peer to Authenticator IV" or RECV-IV, and Octets 32-63 are 1855 known as the "Authenticator to Peer IV", or SEND-IV. 1857 In EAP-TLS, the MSK, EMSK and IV are derived from the MK via a one-way 1858 function. This ensures that the MK cannot be derived from the MSK, EMSK 1859 or IV unless the one-way function (TLS PRF) is broken. Since the MSK is 1860 derived from the MK, if the MK is compromised then the MSK is also 1861 compromised. 1863 As described in [RFC2716], the formula for the derivation of the MSK, 1864 EMSK and IV from the MK is as follows: 1866 MSK = TLS-PRF-64(MK, "client EAP encryption", 1867 client.random || server.random) 1868 EMSK = second 64 octets of: 1869 TLS-PRF-128(MK, "client EAP encryption", 1870 client.random || server.random) 1871 IV = TLS-PRF-64("", "client EAP encryption", 1872 client.random || server.random) 1874 AAA-Key(0,31) = Peer to Authenticator Encryption Key (Enc-RECV-Key) 1875 (MS-MPPE-Recv-Key in [RFC2548]). Also known as the 1876 PMK. 1877 AAA-Key(32,63)= Authenticator to Peer Encryption Key (Enc-SEND-Key) 1878 (MS-MPPE-Send-Key in [RFC2548]) 1879 EMSK(0,31) = Peer to Authenticator Authentication Key (Auth-RECV-Key) 1880 EMSK(32,63) = Authenticator to Peer Authentication Key (Auth-Send-Key) 1881 IV(0,31) = Peer to Authenticator Initialization Vector (RECV-IV) 1882 IV(32,63) = Authenticator to Peer Initialization vector (SEND-IV) 1884 Where: 1886 AAA-Key(W,Z) = Octets W through Z includes of the AAA-Key. 1887 IV(W,Z) = Octets W through Z inclusive of the IV. 1889 MSK(W,Z) = Octets W through Z inclusive of the MSK. 1890 EMSK(W,Z) = Octets W through Z inclusive of the EMSK. 1891 MK = TLS master_secret 1892 TLS-PRF-X = TLS PRF function defined in [RFC2246] computed to X octets 1893 client.random = Nonce generated by the TLS client. 1894 server.random = Nonce generated by the TLS server. 1896 Figure C-1 describes the process by which the MSK,EMSK,IV and ultimately 1897 the TSKs, are derived from the MK. Note that in [RFC2716], the MK is 1898 referred to as the "TLS Master Secret". 1900 ---+ 1901 | ^ 1902 | TLS Master Secret (MK) | 1903 | | 1904 V | 1905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1906 | | EAP | 1907 | Master Session Key (MSK) | Method | 1908 | Derivation | | 1909 | | V 1910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ EAP ---+ 1911 | | | API ^ 1912 | MSK | EMSK | IV | 1913 | | | | 1914 V V V v 1915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 1916 | | | 1917 | | | 1918 | AAA server | | 1919 | | | 1920 | | V 1921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 1922 | | ^ 1923 | AAA-Key(0,31) | AAA-Key(32,63) | 1924 | (PMK) | Transported | 1925 | | via AAA | 1926 | | | 1927 V V V 1928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 1929 | | ^ 1930 | Ciphersuite-Specific Transient Session | Auth.| 1931 | Key Derivation | | 1932 | | V 1933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 1935 Figure C-1 - EAP TLS [RFC2716] Key hierarchy 1936 Appendix D - Transient Session Key (TSK) Derivation 1938 Within IEEE 802.11 RSN, the Pairwise Transient Key (PTK), a transient 1939 session key used to protect unicast traffic, is derived from the PMK 1940 (octets 0-31 of the MSK), known in [RFC2716] as the Peer to 1941 Authenticator Encryption Key. In [IEEE80211i], the PTK is derived from 1942 the PMK via the following formula: 1944 PTK = EAPOL-PRF-X(PMK, "Pairwise key expansion", Min(AA,SA) || 1945 Max(AA, SA) || Min(ANonce,SNonce) || Max(ANonce,SNonce)) 1947 Where: 1949 PMK = AAA-Key(0,31) 1950 SA = Station MAC address (Calling-Station-Id) 1951 AA = Access Point MAC address (Called-Station-Id) 1952 ANonce = Access Point Nonce 1953 SNonce = Station Nonce 1954 EAPOL-PRF-X = Pseudo-Random Function based on HMAC-SHA1, generating 1955 a PTK of size X octets. 1957 TKIP uses X = 64, while CCMP, WRAP, and WEP use X = 48. 1959 The EAPOL-Key Confirmation Key (KCK) is used to provide data origin 1960 authenticity in the TSK derivation. It utilizes the first 128 bits (bits 1961 0-127) of the PTK. The EAPOL-Key Encryption Key (KEK) provides 1962 confidentiality in the TSK derivation. It utilizes bits 128-255 of the 1963 PTK. Bits 256-383 of the PTK are used by Temporal Key 1, and Bits 1964 384-511 are used by Temporal Key 2. Usage of TK1 and TK2 is ciphersuite 1965 specific. Details are available in [IEEE80211i]. 1967 Appendix E - AAA-Key Derivation 1969 As discussed in [Handoff], [IEEE-02-758], [IEEE-03-084], and 1970 [8021XHandoff], keying material may be required for use in fast handoff 1971 between IEEE 802.11 authenticators. Where the backend authentication 1972 server provides keying material to multiple authenticators in order to 1973 fascilitate fast handoff, it is highly desirable for the keying material 1974 used on different authenticators to be cryptographically separate, so 1975 that if one authenticator is compromised, it does not lead to the 1976 compromise of other authenticators. Where keying material is provided 1977 by the backend authentication server, a key hierarchy derived from the 1978 EMSK, as suggested in [IEEE-03-155] can be used to provide 1979 cryptographically separate keying material for use in fast handoff: 1981 AAA-Key-A = MSK(0,63) 1982 AAA-Key-B = PRF(EMSK(0,63),AAA-Key-A,B-Called-Station-Id,Calling-Station-Id) 1983 AAA-Key-E = PRF(EMSK(0,63),AAA-Key-A,E-Called-Station-Id,Calling-Station-Id) 1985 Where: 1986 Calling-Station-Id = STA MAC address 1987 B-Called-Station-Id = AP B MAC address 1988 E-Called-Station-Id = AP E MAC address 1990 Here AAA-Key-A is the AAA-Key derived during the initial EAP 1991 authentication between the peer and authenticator A. Based on this 1992 initial EAP authentication, the EMSK is also derived, which can be used 1993 to derive AAA-Keys for fast authentication between the EAP peer and 1994 authenticators B and E. Since the EMSK is cryptographically separate 1995 from the MSK, each of these AAA-Keys is cryptographically separate from 1996 each other, and are guaranteed to be unique between the EAP peer (also 1997 known as the STA) and the authenticator (also known as the AP). 1999 Acknowledgments 2001 Thanks to Arun Ayyagari, Ashwin Palekar, and Tim Moore of Microsoft, 2002 Dorothy Stanley of Agere, Bob Moskowitz of TruSecure, and Russ Housley 2003 of Vigil Security for useful feedback. 2005 Author Addresses 2007 Bernard Aboba 2008 Microsoft Corporation 2009 One Microsoft Way 2010 Redmond, WA 98052 2012 EMail: bernarda@microsoft.com 2013 Phone: +1 425 706 6605 2014 Fax: +1 425 936 7329 2015 Dan Simon 2016 Microsoft Research 2017 Microsoft Corporation 2018 One Microsoft Way 2019 Redmond, WA 98052 2021 EMail: dansimon@microsoft.com 2022 Phone: +1 425 706 6711 2023 Fax: +1 425 936 7329 2025 Intellectual Property Statement 2027 The IETF takes no position regarding the validity or scope of any 2028 intellectual property or other rights that might be claimed to pertain 2029 to the implementation or use of the technology described in this 2030 document or the extent to which any license under such rights might or 2031 might not be available; neither does it represent that it has made any 2032 effort to identify any such rights. Information on the IETF's 2033 procedures with respect to rights in standards-track and standards- 2034 related documentation can be found in BCP-11. Copies of claims of 2035 rights made available for publication and any assurances of licenses to 2036 be made available, or the result of an attempt made to obtain a general 2037 license or permission for the use of such proprietary rights by 2038 implementors or users of this specification can be obtained from the 2039 IETF Secretariat. 2041 The IETF invites any interested party to bring to its attention any 2042 copyrights, patents or patent applications, or other proprietary rights 2043 which may cover technology that may be required to practice this 2044 standard. Please address the information to the IETF Executive 2045 Director. 2047 Full Copyright Statement 2049 Copyright (C) The Internet Society (2003). All Rights Reserved. 2050 This document and translations of it may be copied and furnished to 2051 others, and derivative works that comment on or otherwise explain it or 2052 assist in its implementation may be prepared, copied, published and 2053 distributed, in whole or in part, without restriction of any kind, 2054 provided that the above copyright notice and this paragraph are included 2055 on all such copies and derivative works. However, this document itself 2056 may not be modified in any way, such as by removing the copyright notice 2057 or references to the Internet Society or other Internet organizations, 2058 except as needed for the purpose of developing Internet standards in 2059 which case the procedures for copyrights defined in the Internet 2060 Standards process must be followed, or as required to translate it into 2061 languages other than English. The limited permissions granted above are 2062 perpetual and will not be revoked by the Internet Society or its 2063 successors or assigns. This document and the information contained 2064 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 2065 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 2066 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2067 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2068 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 2070 Open issues 2072 Open issues relating to this specification are tracked on the following 2073 web site: 2075 http://www.drizzle.com/~aboba/EAP/eapissues.html 2077 Expiration Date 2079 This memo is filed as , and 2080 expires February 22, 2004.