idnits 2.17.1 draft-ietf-eap-keying-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2517. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2494. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2501. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2507. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 53 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 54 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC3748]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'IEEE-802.11i' is mentioned on line 1931, but not defined == Missing Reference: 'RFC2230' is mentioned on line 318, but not defined -- Looks like a reference, but probably isn't: '1' on line 1656 -- Looks like a reference, but probably isn't: '2' on line 1660 -- Looks like a reference, but probably isn't: '3' on line 1667 -- Looks like a reference, but probably isn't: '4' on line 1670 == Missing Reference: 'RFC 3748' is mentioned on line 1244, but not defined == Missing Reference: 'RFC3759' is mentioned on line 1399, but not defined == Missing Reference: 'RFC3784' is mentioned on line 1647, but not defined ** Obsolete undefined reference: RFC 3784 (Obsoleted by RFC 5305) -- Looks like a reference, but probably isn't: '5' on line 1674 -- Looks like a reference, but probably isn't: '6' on line 1679 -- Looks like a reference, but probably isn't: '7' on line 1681 -- Looks like a reference, but probably isn't: '8' on line 1688 == Missing Reference: 'RFC3162' is mentioned on line 2117, but not defined == Missing Reference: 'I-D.draft-ohba-eap-aaakey-binding' is mentioned on line 2125, but not defined == Missing Reference: 'IEEE802.11i' is mentioned on line 2198, but not defined == Missing Reference: 'RC3748' is mentioned on line 2424, but not defined == Unused Reference: 'IEEE-03-084' is defined on line 2227, but no explicit reference was found in the text == Unused Reference: 'I-D.arkko-eap-service-identity-auth' is defined on line 2239, but no explicit reference was found in the text == Unused Reference: 'I-D.ohba-eap-aaakey-binding' is defined on line 2245, but no explicit reference was found in the text == Unused Reference: 'RFC4046' is defined on line 2328, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-housley-aaa-key-mgmt-01 == Outdated reference: A later version (-04) exists of draft-arkko-eap-service-identity-auth-02 == Outdated reference: A later version (-01) exists of draft-ohba-eap-aaakey-binding-00 -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Obsolete informational reference (is this intentional?): RFC 2716 (Obsoleted by RFC 5216) -- Obsolete informational reference (is this intentional?): RFC 2845 (Obsoleted by RFC 8945) -- Obsolete informational reference (is this intentional?): RFC 3547 (Obsoleted by RFC 6407) -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) Summary: 5 errors (**), 0 flaws (~~), 20 warnings (==), 22 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: Standards Track Microsoft 5 J. Arkko 6 3 April 2006 Ericsson 7 P. Eronen 8 Nokia 9 H. Levkowetz, Ed. 10 ipUnplugged 12 Extensible Authentication Protocol (EAP) Key Management Framework 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on October 10, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society 2006. 41 Abstract 43 The Extensible Authentication Protocol (EAP), defined in [RFC3748], 44 enables extensible network access authentication. This document 45 provides a framework for the transport and usage of keying material 46 generated by EAP authentication algorithms, known as "methods". It 47 also specifies the EAP key hierarchy. 49 Table of Contents 51 1. Introduction .......................................... 3 52 1.1 Requirements Language ........................... 3 53 1.2 Terminology ..................................... 3 54 1.3 Overview ........................................ 5 55 1.4 EAP Key Hierarchy ............................... 8 56 1.5 Security Goals .................................. 11 57 1.6 EAP Invariants .................................. 12 58 2. Lower Layer Operation ................................. 15 59 2.1 Transient Session Keys .......................... 16 60 2.2 Authenticator Architecture ...................... 18 61 3. Key Management ........................................ 22 62 3.1 Secure Association Protocol ..................... 22 63 3.2 Key Scope ....................................... 25 64 3.3 Parent-Child Relationships ...................... 26 65 3.4 Local Key Lifetimes ............................. 26 66 3.5 Exported and Calculated Key Lifetimes ........... 27 67 3.6 Key Cache Synchronization ....................... 28 68 3.7 Key Strength .................................... 29 69 3.8 Key Wrap ........................................ 29 70 4. Handoff Vulnerabilities ............................... 30 71 4.1 Authorization ................................... 30 72 4.2 Correctness ..................................... 32 73 5. Security Considerations .............................. 34 74 5.1 Threat Model .................................... 35 75 5.2 Authenticator Compromise ........................ 36 76 5.3 Spoofing ........................................ 36 77 5.4 Downgrade Attacks ............................... 37 78 5.5 Unauthorized Disclosure ......................... 38 79 5.6 Replay Protection ............................... 39 80 5.7 Key Freshness ................................... 40 81 5.8 Elevation of Privilege .......................... 41 82 5.9 Man-in-the-Middle Attacks ....................... 42 83 5.10 Denial of Service Attacks ....................... 42 84 5.11 Impersonation ................................... 43 85 5.12 Channel Binding ................................. 44 86 6. IANA Considerations ................................... 45 87 7. References ............................................ 45 88 7.1 Normative References ............................ 45 89 7.2 Informative References .......................... 46 90 Acknowledgments .............................................. 50 91 Author's Addresses ........................................... 50 92 Appendix A - Exported Parameters in Existing Methods ......... 52 93 Intellectual Property Statement .............................. 53 94 Disclaimer of Validity ....................................... 54 95 Copyright Statement .......................................... 54 97 1. Introduction 99 The Extensible Authentication Protocol (EAP), defined in [RFC3748], 100 was designed to enable extensible authentication for network access 101 in situations in which the IP protocol is not available. Originally 102 developed for use with PPP [RFC1661], it has subsequently also been 103 applied to IEEE 802 wired networks [IEEE-802.1X], wireless networks 104 such as [IEEE-802.11i] and [IEEE-802.16e], and IKEv2 [RFC4306]. 106 This document provides a framework for the transport and usage of 107 keying material generated by EAP authentication algorithms, known as 108 "methods". In EAP, keying material is generated by EAP methods. 109 Part of this keying material may be used by EAP methods themselves 110 and part of this material may be exported. The exported keying 111 material may be transported by AAA protocols and used by Secure 112 Association Protocols in the generation or transport of session keys 113 which are used by lower layer ciphersuites. This document describes 114 each of these elements and provides a system-level security analysis. 115 It also specifies the EAP key hierarchy. 117 1.1. Requirements Language 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119]. 123 1.2. Terminology 125 This document frequently uses the following terms: 127 AAA Authentication, Authorization and Accounting. AAA protocols with 128 EAP support include RADIUS [RFC3579] and Diameter [RFC4072]. In 129 this document, the terms "AAA server" and "backend authentication 130 server" are used interchangeably. 132 authenticator 133 The end of the link initiating EAP authentication. The term 134 Authenticator is used in [IEEE-802.1X], and authenticator has the 135 same meaning in this document. 137 peer The end of the link that responds to the authenticator. 139 backend authentication server 140 A backend authentication server is an entity that provides an 141 authentication service to an authenticator. When used, this server 142 typically executes EAP methods for the authenticator. This 143 terminology is also used in [IEEE-802.1X]. 145 Channel Binding 146 The communication within an EAP method of integrity-protected 147 channel properties such as endpoint identifiers which can be 148 compared to values communicated via out of band mechanisms (such as 149 via a AAA or lower layer protocol). 151 EAP server 152 The entity that terminates the EAP authentication method with the 153 peer. In the case where no backend authentication server is used, 154 the EAP server is part of the authenticator. In the case where the 155 authenticator operates in pass-through mode, the EAP server is 156 located on the backend authentication server. 158 Long Term Credential 159 EAP methods frequently make use of long term secrets in order to 160 enable authentication between the peer and server. In the case of 161 a method based on pre-shared key authentication, the long term 162 credential is the pre-shared key. In the case of a public-key 163 based method, the long term credential is the corresponding private 164 key. 166 Master Session Key (MSK) 167 Keying material that is derived between the EAP peer and server and 168 exported by the EAP method. The MSK is at least 64 octets in 169 length. 171 AAA-Key 172 The term AAA-Key is synonymous with MSK. 174 Extended Master Session Key (EMSK) 175 Additional keying material derived between the peer and server that 176 is exported by the EAP method. The EMSK is at least 64 octets in 177 length, and is never shared with a third party. 179 Initialization Vector (IV) 180 A quantity of at least 64 octets, suitable for use in an 181 initialization vector field, that is derived between the peer and 182 EAP server. Since the IV is a known value in methods such as EAP- 183 TLS [RFC2716], it cannot be used by itself for computation of any 184 quantity that needs to remain secret. As a result, its use has 185 been deprecated and EAP methods are not required to generate it. 186 However, when it is generated it MUST be unpredictable. 188 Pairwise Master Key (PMK) 189 Lower layers use the MSK in lower-layer dependent manner. For 190 instance, in [IEEE-802.11i] Octets 0-31 of the MSK are known as the 191 Pairwise Master Key (PMK). In [IEEE-802.11i] the TKIP and AES CCMP 192 ciphersuites derive their Transient Session Keys (TSKs) solely from 193 the PMK, whereas the WEP ciphersuite as noted in [RFC3580], derives 194 its TSKs from both halves of the MSK. In [802.16e], the MSK is 195 truncated to 20 octets for PMK and 20 octets for PMK2. 197 security association 198 A set of policies and cryptographic state used to protect 199 information. Elements of a security association may include 200 cryptographic keys, negotiated ciphersuites and other parameters, 201 counters, sequence spaces, authorization attributes, etc. 203 Transient EAP Keys (TEKs) 204 Session keys which are used to establish a protected channel 205 between the EAP peer and server during the EAP authentication 206 exchange. The TEKs are appropriate for use with the ciphersuite 207 negotiated between EAP peer and server for use in protecting the 208 EAP conversation. The TEKs are stored locally by the EAP method 209 and are not exported. Note that the ciphersuite used to set up the 210 protected channel between the EAP peer and server during EAP 211 authentication is unrelated to the ciphersuite used to subsequently 212 protect data sent between the EAP peer and authenticator. 214 Transient Session Keys (TSKs) 215 Session keys used to protect data exchanged after EAP 216 authentication has successfully completed, using the ciphersuite 217 negotiated between the EAP peer and authenticator. 219 1.3. Overview 221 Where EAP key derivation is supported, the conversation typically 222 takes place in three phases: 224 Phase 0: Discovery 225 Phase 1: Authentication 226 1a: EAP authentication 227 1b: AAA Key Transport (optional) 228 Phase 2: Secure Association Protocol 229 2a: Unicast Secure Association 230 2b: Multicast Secure Association (optional) 232 Of these phases, Phase 0, 1b and Phase 2 are handled external to EAP. 233 Phases 0 and 2 are handled by the lower layer protocol and phase 1b 234 is typically handled by a AAA protocol. 236 In the discovery phase (phase 0), peers locate authenticators and 237 discover their capabilities. A peer may locate an authenticator 238 providing access to a particular network, or a peer may locate an 239 authenticator behind a bridge with which it desires to establish a 240 Secure Association. Discovery can occur manually or automatically, 241 depending on the lower layer over which EAP runs. 243 EAP peer Authenticator Auth. Server 244 -------- ------------- ------------ 245 |<----------------------------->| | 246 | Discovery (phase 0) | | 247 |<----------------------------->|<----------------------------->| 248 | EAP auth (phase 1a) | AAA pass-through (optional) | 249 | | | 250 | |<----------------------------->| 251 | | AAA Key transport | 252 | | (optional; phase 1b) | 253 |<----------------------------->| | 254 | Unicast Secure association | | 255 | (phase 2a) | | 256 | | | 257 |<----------------------------->| | 258 | Multicast Secure association | | 259 | (optional; phase 2b) | | 260 | | | 262 Figure 1: Conversation Overview 264 The authentication phase (phase 1) may begin once the peer and 265 authenticator discover each other. This phase, if it occurs, always 266 includes EAP authentication (phase 1a). Where the chosen EAP method 267 supports key derivation, in phase 1a EAP keying material is derived 268 on both the peer and the EAP server. 270 An additional step (phase 1b) is required in deployments which 271 include a backend authentication server, in order to transport keying 272 material from the backend authentication server to the authenticator. 273 In order to obey the principle of Mode Independence (see Section 274 1.6.1), where a backend server is present, all keying material which 275 is required by the lower layer needs to be transported from the EAP 276 server to the authenticator. Since existing TSK derivation and 277 transport techniques depend solely on the MSK, in existing 278 implementations, this is the only keying material replicated in the 279 AAA key transport phase 1b. 281 Successful completion of EAP authentication and key derivation by a 282 peer and EAP server does not necessarily imply that the peer is 283 committed to joining the network associated with an EAP server. 284 Rather, this commitment is implied by the creation of a security 285 association between the EAP peer and authenticator, as part of the 286 Secure Association Protocol (phase 2). The Secure Association 287 Protocol exchange (phase 2) occurs between the peer and authenticator 288 in order to manage the creation and deletion of unicast (phase 2a) 289 and multicast (phase 2b) security associations between the peer and 290 authenticator. The conversation between the parties is shown in 291 Figure 1. 293 1.3.1. Examples 295 Existing EAP lower layers implement phase 0, 2a and 2b in different 296 ways: 298 PPP PPP, defined in [RFC1661] does not support discovery, nor does it 299 include a Secure Association Protocol. 301 PPPOE 302 PPPOE, defined in [RFC2516], includes support for a Discovery stage 303 (phase 0). In this step, the EAP peer sends a PPPoE Active 304 Discovery Initiation (PADI) packet to the broadcast address, 305 indicating the service it is requesting. The Access Concentrator 306 replies with a PPPOE Active Discovery Offer (PADO) packet 307 containing its name, the service name and an indication of the 308 services offered by the concentrator. The discovery phase is not 309 secured. PPPOE, like PPP, does not include a Secure Association 310 Protocol. 312 IKEv2 313 IKEv2, defined in [RFC4306], handles the establishment of unicast 314 security associations (phase 2a), while the establishment of 315 multicast security associations (phase 2b) may be handled by a 316 group key management protocol such as GDOI [RFC3547], GSAKMP 317 [GSAKMP], MIKEY [RFC3830], or GKDP [GKDP]. Several mechanisms have 318 been proposed for discovery of IPsec security gateways. [RFC2230] 319 discusses the use of KX Resource Records (RRs) for IPsec gateway 320 discovery; while KX RRs are supported by many DNS server 321 implementations, they have not yet been widely deployed. 322 Alternatively, DNS SRV [RFC2782] can be used for this purpose. 323 Where DNS is used for gateway location, DNS security mechanisms 324 such as DNSSEC ([RFC2535], [RFC2931]), TSIG [RFC2845], and Simple 325 Secure Dynamic Update [RFC3007] are available. 327 IEEE 802.11i 328 IEEE 802.11, defined in [IEEE-802.11], handles discovery via the 329 Beacon and Probe Request/Response mechanisms. IEEE 802.11 access 330 points periodically announce their Service Set Identifiers (SSIDs) 331 as well as capabilities using Beacon frames. Stations can query 332 for access points by sending a Probe Request to the broadcast 333 address. Neither Beacon nor Probe Request/Response frames are 334 secured. The 4-way handshake defined in [IEEE-802.11i] enables the 335 derivation of unicast (phase 2a) and multicast/broadcast (phase 2b) 336 secure associations. Since the group key exchange transports a 337 group key from the access point to the station, two 4-way 338 handshakes may be required in order to support peer-to-peer 339 communications. A proof of the security of the IEEE 802.11i 4-way 340 handshake when used with EAP-TLS [RFC2716], is provided in [He]. 342 IEEE 802.1X 343 IEEE 802.1X-2004, defined in [IEEE-802.1X] does not support 344 discovery (phase 0), nor does it provide for derivation of unicast 345 or multicast secure associations. 347 1.4. EAP Key Hierarchy 349 EAP, defined in [RFC3748], is a two-party protocol spoken between the 350 EAP peer and server. Within EAP, keying material is generated by EAP 351 methods. Part of this keying material may be used by EAP methods 352 themselves and part of this material may be exported. In addition to 353 export of keying material, EAP methods may also export associated 354 parameters, and may import and export Channel Bindings from the lower 355 layer. 357 As illustrated in Figure 2, the EAP method key derivation has at the 358 root the long term credential utilized by the selected EAP method. 359 If authentication is based on a pre-shared key, the parties store the 360 EAP method to be used and the pre-shared key. The EAP server also 361 stores the peer's identity as well as other information associated 362 with it. This information may be used to determine whether access to 363 some service should be granted. The peer stores information necessary 364 to choose which secret to use for which service. 366 If authentication is based on proof of possession of the private key 367 corresponding to the public key contained within a certificate, the 368 parties store the EAP method to be used and the trust anchors used to 369 validate the certificates. The EAP server also stores the peer's 370 identity and the peer stores information necessary to choose which 371 certificate to use for which service. 373 Based on the long term credential established between the peer and 374 the server, EAP methods derive two types of keys: 376 [1] Keys calculated locally by the EAP method but not exported 377 by the EAP method, such as the TEKs. 378 [2] Keying material exported by the EAP method: MSK, EMSK, IV. 380 As noted in [RFC3748] Section 7.10, EAP methods generating keys are 381 required to calculate and export the MSK and EMSK, which must be at 382 least 64 octets in length. EAP methods also may export the IV; 383 however, the use of the IV is deprecated. 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 386 | | ^ 387 | EAP Method | | 388 | | | 389 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | | 390 | | | | | | | 391 | | EAP Method Key |<->| Long-Term | | | 392 | | Derivation | | Credential | | | 393 | | | | | | | 394 | | | +-+-+-+-+-+-+-+ | Local to | 395 | | | | EAP | 396 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Method | 397 | | | | | | 398 | | | | | | 399 | | | | | | 400 | | | | | | 401 | | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | | 402 | | | TEK | |MSK, EMSK | |IV | | | 403 | | |Derivation | |Derivation | |Derivation | | | 404 | | | | | | |(Deprecated) | | | 405 | | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | | 406 | | ^ | | | | 407 | | | | | | V 408 +-+-|-+-+-+-+-+-+-+-+-|-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+ ---+ 409 | | | | ^ 410 | Peer-ID, | | | Exported | 411 | Server-ID, | Channel | MSK (64+B) | IV (64B) by | 412 | Session-ID, | Bindings | EMSK (64+B) | (Optional) EAP | 413 | Key-Lifetime | & Result | | Method | 414 V V V V V 416 Figure 2: EAP Method Parameter Import/Export 418 EAP methods also MAY export method-specific peer and server 419 identifiers (peer-ID and server-ID), a method-specific EAP 420 conversation identifier known as the Session-ID, and the lifetime of 421 the exported keys, known as the Key-Lifetime. EAP methods MAY also 422 support the import and export of Channel Bindings. New EAP method 423 specifications MUST define the Peer-ID, Server-ID and Method-ID. The 424 combination of the Peer-ID and Server-ID uniquely specifies the 425 endpoints of the EAP method exchange when they are provided. The 426 Peer-ID, Server-ID, and Method-ID for existing EAP methods is defined 427 in Appendix A. 429 Peer-ID 431 As described in [RFC3748] Section 7.3, the identity provided in the 432 EAP-Response/Identity, may be different from the peer identity 433 authenticated by the EAP method. Where the EAP method authenticates 434 the peer identity, that identity is exported by the method as the 435 Peer-ID. A suitable EAP peer name may not always be available. 436 Where an EAP method does not define a method-specific peer identity, 437 the Peer-ID is the null string. 439 Server-ID 441 Where the EAP method authenticates the server identity, that identity 442 is exported by the method as the Server-ID. A suitable EAP server 443 name may not always be available. Where an EAP method does not 444 define a method-specific peer identity, the Server-ID is the null 445 string. 447 Method-ID 449 EAP method specifications deriving keys MUST specify a temporally 450 unique method identifier known as the Method-ID. The EAP Method-ID 451 uniquely identifies an EAP session of a given Type between an EAP 452 peer and server. The Method-ID is typically constructed from nonces 453 or counters used within the EAP method exchange. 455 Session-ID 457 The Session-ID uniquely identifies an EAP session between an EAP peer 458 (as identified by the Peer-ID) and server (as identified by the 459 Server-ID). The EAP Session-ID consists of the concatenation of the 460 Expanded EAP Type Code (including the Type, Vendor-ID and Vendor-Type 461 fields defined in [RFC3748] Section 5.7) and the Method-ID. The 462 inclusion of the Expanded Type Code in the EAP Session-ID ensures 463 that each EAP method has a distinct Session-ID space. Since an EAP 464 session is not bound to a particular authenticator or specific ports 465 on the peer and authenticator, the authenticator port or identity are 466 not included in the Session-ID. 468 Key-Lifetime 470 While EAP itself does not support key lifetime negotiation, it is 471 possible to specify methods that do. However, systems that rely on 472 such negotiation for exported keys would only function with these 473 methods. As a result, it is NOT RECOMMENDED to use this approach as 474 the sole way to determine key lifetimes. 476 Channel Bindings 478 Channel Bindings include lower layer parameters that are verified for 479 consistency between the EAP peer and server. In order to avoid 480 introducing media dependencies, EAP methods that transport Channel 481 Binding data MUST treat this data as opaque octets. Typically the 482 EAP method imports Channel Bindings from the lower layer on the peer, 483 and transmits them securely to the EAP server, which exports them to 484 the lower layer or AAA layer. However, transport may occur from EAP 485 server to peer, or may be bi-directional. On the side of the 486 exchange (peer or server) where Channel Bindings are verified, the 487 lower layer or AAA layer passes the result of the verification (TRUE 488 or FALSE) up to the EAP method. While the verification can be done 489 either by the peer or the server, typically only the server has the 490 knowledge to determine the correctness of the values, as opposed to 491 merely verifying their equality. 493 1.4.1. Key Naming 495 Each key created within the EAP key management framework has a name 496 (a unique identifier), as well as a scope (the parties to whom the 497 key is available). The scope of exported parameters is defined by 498 the EAP peer name (if securely exchanged within the method) and the 499 EAP server name (also only if securely exchanged). Where a peer or 500 server name is missing the null string is used. 502 MSK and EMSK Names 503 These parameters are exported by the EAP peer and EAP server, and 504 can be referred to using the EAP Session-ID and a binary or textual 505 indication of the parameter being referred to. 507 PMK Name 508 This document does not specify a naming scheme for the PMK. The 509 PMK is only identified by the key from which it is derived. 511 Note: IEEE 802.11i names the PMKID for the purposes of being able 512 to refer to it in the Secure Association protocol; this naming is 513 based on a hash of the PMK itself as well as some other parameters 514 (see Section 8.5.1.2 [IEEE-802.11i]). 516 TEK Name 517 The TEKs may or may not be named. Their naming is specified in the 518 EAP method. 520 TSK Name 521 The TSKs are typically named. Their naming is specified in the 522 lower layer so that the correct set of transient session keys can 523 be identified for processing a given packet. 525 1.5. Security Goals 527 The goal of the EAP conversation is to derive fresh session keys 528 between the EAP peer and authenticator that are known only to those 529 parties, and for both the EAP peer and authenticator to demonstrate 530 that they are authorized to perform their roles either by each other 531 or by a trusted third party (the backend authentication server). 533 Completion of an EAP method exchange (Phase 1a) supporting key 534 derivation results in the derivation of EAP keying material (MSK, 535 EMSK, TEKs) known only to the EAP peer (identified by the Peer-ID) 536 and server (identified by the Server-ID). Both the EAP peer and EAP 537 server know the exported keying material to be fresh. Key freshness 538 is discussed in Sections 3.4, 3.5 and 5.7. 540 Completion of the AAA exchange (Phase 1b) results in the transport of 541 EAP keying material from the EAP server (identified by the Server-ID) 542 to the EAP authenticator (identified by the NAS-Identifier) without 543 disclosure to any other party. Both the EAP server and EAP 544 authenticator know this keying material to be fresh. Disclosure 545 issues are discussed in Section 5.6; security properties of AAA 546 protocols are discussed in Sections 5.2-5.8, and 5.11. 548 Completion of the Secure Association Protocol (Phase 2) results in 549 the derivation or transport of Transient Session Keys (TSKs) known 550 only to the EAP peer (identified by the Peer-ID) and authenticator 551 (identified by the NAS-Identifier). Both the EAP peer and 552 authenticator know the TSKs to be fresh. Both the EAP peer and 553 authenticator demonstrate that they are authorized to perform their 554 roles. Authorization issues are discussed in Section 5.8 and 5.9; 555 security properties of Secure Association Protocols are discussed in 556 Section 3.1. 558 1.6. EAP Invariants 560 Certain basic characteristics, known as "EAP Invariants", hold true 561 for EAP implementations on all media: 563 Mode independence 564 Media independence 565 Method independence 566 Ciphersuite independence 568 1.6.1. Mode Independence 570 EAP is typically deployed to support extensible network access 571 authentication in situations where a peer desires network access via 572 one or more authenticators. Where authenticators are deployed 573 standalone, the EAP conversation occurs between the peer and 574 authenticator, and the authenticator must locally implement an EAP 575 method acceptable to the peer. However, when utilized in "pass- 576 through" mode, EAP enables deployment of new authentication methods 577 without requiring development of new code on the authenticator. 579 While the authenticator may implement some EAP methods locally and 580 use those methods to authenticate local users, it may at the same 581 time act as a pass-through for other users and methods, forwarding 582 EAP packets back and forth between the backend authentication server 583 and the peer. This is accomplished by encapsulating EAP packets 584 within the Authentication, Authorization and Accounting (AAA) 585 protocol, spoken between the authenticator and backend authentication 586 server. AAA protocols supporting EAP include RADIUS [RFC3579] and 587 Diameter [RFC4072]. 589 It is a fundamental property of EAP that at the EAP method layer, the 590 conversation between the EAP peer and server is unaffected by whether 591 the EAP authenticator is operating in "pass-through" mode. EAP 592 methods operate identically in all aspects, including key derivation 593 and parameter import/export, regardless of whether the authenticator 594 is operating as a pass-through or not. 596 The successful completion of an EAP method that supports key 597 derivation results in the export of keying material and parameters on 598 the EAP peer and server. Even though the EAP peer or server may 599 import Channel-Bindings that may include the identity of the EAP 600 authenticator, this information is treated as opaque octets. As a 601 result, within EAP the only relevant identities are the Peer-ID and 602 Server-ID. Channel Bindings are only interpreted by the lower layer. 604 Within EAP, the primary function of the AAA protocol is to maintain 605 the principle of Mode Independence, so that as far as the EAP peer is 606 concerned, its conversation with the EAP authenticator, and all 607 consequences of that conversation, are identical, regardless of the 608 authenticator mode of operation. 610 1.6.2. Media Independence 612 One of the goals of EAP is to allow EAP methods to function on any 613 lower layer meeting the criteria outlined in [RFC3748], Section 3.1. 614 For example, as described in [RFC3748], EAP authentication can be run 615 over PPP [RFC1661], IEEE 802 wired networks [IEEE-802.1X], and 616 wireless networks such as 802.11 [IEEE-802.11i] and 802.16 617 [IEEE-802.16e]. 619 In order to maintain media independence, it is necessary for EAP to 620 avoid consideration of media-specific elements. For example, EAP 621 methods cannot be assumed to have knowledge of the lower layer over 622 which they are transported, and cannot be restricted to identifiers 623 associated with a particular usage environment (e.g. MAC addresses). 625 Note that media independence may be retained within EAP methods that 626 support Channel-Bindings or method-specific identification. An EAP 627 method need not be aware of the content of an identifier in order to 628 use it. This enables an EAP method to use media-specific identifiers 629 such as MAC addresses without compromising media independence. 630 Channel-Bindings are treated as opaque octets by EAP methods, so that 631 handling them does not require media-specific knowledge. 633 1.6.3. Method Independence 635 By enabling pass-through, authenticators can support any method 636 implemented on the peer and server, not just locally implemented 637 methods. This allows the authenticator to avoid implementing code 638 for each EAP method required by peers. In fact, since a pass-through 639 authenticator is not required to implement any EAP methods at all, it 640 cannot be assumed to support any EAP method-specific code. 642 As a result, as noted in [RFC3748], authenticators must by default be 643 capable of supporting any EAP method. This is useful where there is 644 no single EAP method that is both mandatory-to-implement and offers 645 acceptable security for the media in use. For example, the [RFC3748] 646 mandatory-to-implement EAP method (MD5-Challenge) does not provide 647 dictionary attack resistance, mutual authentication or key 648 derivation, and as a result is not appropriate for use in wireless 649 LAN authentication [RFC4017]. However, despite this it is possible 650 for the peer and authenticator to interoperate as long as a suitable 651 EAP method is supported on the EAP server. 653 1.6.4. Ciphersuite Independence 655 Ciphersuite Independence is a requirement for Media Independence. 656 Since lower layer ciphersuites vary between media, media independence 657 requires that EAP keying material needs to be large enough (with 658 sufficient entropy) to handle any ciphersuite. 660 While EAP methods may negotiate the ciphersuite used in protection of 661 the EAP conversation, the ciphersuite used for the protection of the 662 data exchanged after EAP authentication has completed is negotiated 663 between the peer and authenticator within the lower layer, outside of 664 EAP. 666 For example, within PPP, the ciphersuite is negotiated within the 667 Encryption Control Protocol (ECP) defined in [RFC1968], after EAP 668 authentication is completed. Within [IEEE-802.11i], the AP 669 ciphersuites are advertised in the Beacon and Probe Responses prior 670 to EAP authentication, and are securely verified during a 4-way 671 handshake exchange. 673 Since the ciphersuites used to protect data depend on the lower 674 layer, requiring EAP methods have knowledge of lower layer 675 ciphersuites would compromise the principle of Media Independence. 676 Since ciphersuite negotiation occurs in the lower layer, there is no 677 need for lower layer ciphersuite negotiation within EAP, and EAP 678 methods generate keying material that is ciphersuite-independent. 680 In order to allow a ciphersuite to be usable within the EAP keying 681 framework, a specification MUST be provided describing how TSKs 682 suitable for use with the ciphersuite are derived from exported EAP 683 keying parameters. To maintain Method Independence, algorithms for 684 deriving TSKs MUST NOT depend on the EAP method, although algorithms 685 for TEK derivation MAY be specific to the EAP method. 687 Advantages of ciphersuite-independence include: 689 Reduced update requirements 690 If EAP methods were to specify how to derive transient session keys 691 for each ciphersuite, they would need to be updated each time a new 692 ciphersuite is developed. In addition, backend authentication 693 servers might not be usable with all EAP-capable authenticators, 694 since the backend authentication server would also need to be 695 updated each time support for a new ciphersuite is added to the 696 authenticator. 698 Reduced EAP method complexity 699 Requiring each EAP method to include ciphersuite-specific code for 700 transient session key derivation would increase method complexity 701 and result in duplicated effort. 703 Simplified configuration 704 The ciphersuite is negotiated between the peer and authenticator 705 outside of EAP. Where the authenticator operates in "pass-through" 706 mode, the EAP server is not a party to this negotiation, nor is it 707 involved in the data flow between the EAP peer and authenticator. 708 As a result, the EAP server may not have knowledge of the 709 ciphersuites and negotiation policies implemented by the peer and 710 authenticator, or be aware of the ciphersuite negotiated between 711 them. For example, since ECP negotiation occurs after 712 authentication, when run over PPP, the EAP peer and server may not 713 anticipate the negotiated ciphersuite and therefore this 714 information cannot be provided to the EAP method. 716 2. Lower Layer Operation 718 On completion of EAP authentication, keying material and material and 719 parameters exported by the EAP method are provided to the lower layer 720 and AAA layer (if present). These include the Master Session Key 721 (MSK), Extended Master Session Key (EMSK), Peer-ID, Server-ID, 722 Session-ID and Key-Lifetime. The Initialization Vector (IV) is 723 deprecated. 725 In order to preserve the security of keys derived within EAP methods, 726 lower layers MUST NOT export keys passed down by EAP methods. This 727 implies that EAP keying material or parameters passed down to a lower 728 layer are for the exclusive use of that lower layer and MUST NOT be 729 used within another lower layer. This prevents compromise of one 730 lower layer from compromising other applications using EAP keying 731 parameters. 733 EAP keying material and parameters provided to a lower layer MUST NOT 734 be transported to another entity. For example, EAP keying material 735 and parameters passed down to the EAP peer lower layer MUST NOT leave 736 the peer; EAP keying material and parameters passed down or 737 transported to the EAP authenticator lower layer MUST NOT leave the 738 authenticator. 740 On the EAP server, keying material requested by and passed down to 741 the AAA layer may be replicated to the AAA layer on the 742 authenticator. On the authenticator, the AAA layer provides the 743 replicated keying material to the lower layer over which the EAP 744 authentication conversation took place. This enables "mode 745 independence" to be maintained. 747 The EMSK MUST NOT be provided to an entity outside the EAP server or 748 peer, nor is it permitted to pass any quantity to an entity outside 749 the EAP server or peer from which the EMSK could be computed without 750 breaking some cryptographic assumption, such as inverting a one-way 751 function. The EMSK MUST NOT be transported by the AAA layer. As 752 noted in [RFC3748] Section 7.10: 754 The EMSK is reserved for future use and MUST remain on the EAP 755 peer and EAP server where it is derived; it MUST NOT be 756 transported to, or shared with, additional parties, or used to 757 derive any other keys. 759 The EAP layer as well as the peer and authenticator layers MUST NOT 760 modify or cache keying material or parameters (including Channel 761 Bindings) passing in either direction between the EAP method layer 762 and the lower layer or AAA layer. 764 2.1. Transient Session Keys 766 Where explicitly supported by the lower layer, lower layers MAY cache 767 the exported EAP keying material and parameters and/or TSKs. The 768 structure of this key cache is defined by the lower layer. So as to 769 enable interoperability, new lower layer specifications MUST describe 770 EAP key caching behavior. Unless explicitly specified by the lower 771 layer, the EAP peer, server and authenticator MUST assume that peers 772 and authenticators do not cache exported EAP keying parameters or 773 TSKs. Existing EAP lower layers and AAA layers handle the caching of 774 EAP keying material and the generation of transient session keys in 775 different ways: 777 IEEE 802.1X-2004 778 IEEE 802.1X-2004, defined in [IEEE-802.1X] does not support caching 779 of EAP keying material or parameters. Once EAP authentication 780 completes, it is assumed that EAP keying material and parameters 781 are discarded. 783 PPP PPP, defined in [RFC1661] does not support caching of EAP keying 784 material or parameters. PPP ciphersuites derive their TSKs 785 directly from the MSK, as described in [RFC2716]. This method is 786 NOT RECOMMENDED, since were PPP to support caching, this could 787 result in stale TSKs. As a result, once the PPP session is 788 terminated, EAP keying material and parameters MUST be discarded. 789 Since caching of EAP keying material is not permitted, within PPP 790 there is no way to handle TSK rekey without EAP re-authentication. 791 Perfect Forward Secrecy (PFS) is only possible within PPP if the 792 negotiated EAP method supports this. 794 IKEv2 795 IKEv2, defined in [RFC4306] only uses the MSK for authentication 796 purposes and not key derivation. The EMSK, IV, Peer-ID, Server-ID 797 or Session-ID are not used. As a result, the keying material 798 derived within IKEv2 is independent of the EAP keying material and 799 rekey of IPsec SAs can be handled without requiring EAP re- 800 authentication. Since generation of keying material is independent 801 of EAP, within IKEv2 it is possible to negotiate PFS, regardless of 802 the EAP method that is used. IKEv2 does not cache EAP keying 803 material or parameters; once IKEv2 authentication completes it is 804 assumed that EAP keying material and parameters are discarded. The 805 Session-Timeout attribute is therefore interpreted as a limit on 806 the VPN session time, rather than an indication of the MSK key 807 lifetime. 809 IEEE 802.11i 810 IEEE 802.11i enables caching of the MSK, but not the EMSK, IV, 811 Peer-ID, Server-ID, or Session-ID. More details about the 812 structure of the cache are available in [IEEE-802.11i]. In IEEE 813 802.11i, TSKs are derived from the MSK using the 4-way handshake, 814 which includes a nonce exchange. This guarantees TSK freshness 815 even if the MSK is reused. The 4-way handshake also enables TSK 816 rekey without EAP re-authentication. PFS is only possible within 817 IEEE 802.11i if the negotiated EAP method supports this. 819 IEEE 802.16e 820 IEEE 802.16e, defined in [IEEE-802.16e] supports caching of the 821 MSK, but not the EMSK, IV, Peer-ID, Server-ID or Session-ID. In 822 IEEE 802.16e, TSKs are generated by the authenticator without any 823 contribution by the peer. The TSKs are encrypted, authenticated 824 and integrity protected using the MSK. As a result, TSK rekey is 825 possible without EAP re-authentication. PFS is not possible even 826 if the negotiated EAP method supports it. 828 AAA Existing implementations of RADIUS/EAP [RFC3579] or Diameter EAP 829 [RFC4072] do not support caching of EAP keying material or 830 parameters. In existing AAA client, proxy and server 831 implementations, exported EAP keying material (MSK, EMSK and IV) as 832 well as parameters and derived keys are not cached and MUST be 833 presumed lost after the AAA exchange completes. 835 In order to avoid key reuse, the AAA layer MUST delete transported 836 keys once they are sent. The AAA layer MUST NOT retain keys that 837 it has previously sent. For example, a AAA layer that has 838 transported the MSK MUST delete it, and keys MUST NOT be derived 839 from the MSK from that point forward. 841 2.2. Authenticator Architecture 843 This specification does not impose constraints on the architecture of 844 the EAP authenticator or peer. Any of the authenticator 845 architectures described in [RFC4118] can be used. For example, it is 846 possible for multiple base stations and a "controller" (e.g. WLAN 847 switch) to comprise a single EAP authenticator. In such a situation, 848 the "base station identity" is irrelevant to the EAP method 849 conversation, except perhaps as an opaque blob to be used in Channel 850 Bindings. Many base stations can share the same authenticator 851 identity. As a result, lower layers need to identify EAP peers and 852 authenticators unambiguously, without incorporating implicit 853 assumptions about peer and authenticator architectures. 855 It should be understood that an EAP authenticator or peer: 857 [a] may contain one or more physical or logical ports; 858 [b] may advertise itself as one or more "virtual" 859 authenticators or peers; 860 [c] may utilize multiple CPUs; 861 [d] may support clustering services for load balancing or failover. 863 Both the EAP peer and authenticator may have more than one physical 864 or logical port. A peer may simultaneously access the network via 865 multiple authenticators, or via multiple physical or logical ports on 866 a given authenticator. Similarly, an authenticator may offer network 867 access to multiple peers, each via a separate physical or logical 868 port. When a single physical authenticator advertises itself as 869 multiple "virtual authenticators", it is possible for a single 870 physical port to belong to multiple "virtual authenticators". The 871 situation is illustrated in Figure 3. 873 +-+-+-+-+ 874 | EAP | 875 | Peer | 876 +-+-+-+-+ 877 | | | Peer Ports 878 / | \ 879 / | \ 880 / | \ 881 / | \ 882 / | \ 883 / | \ 884 / | \ 885 / | \ 886 | | | | | | | | | Authenticator Ports 887 +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ 888 | | | | | | 889 | Auth. | | Auth. | | Auth. | 890 | | | | | | 891 +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ 892 \ | / 893 \ | / 894 \ | / 895 EAP over AAA \ | / 896 (optional) \ | / 897 \ | / 898 \ | / 899 \ | / 900 +-+-+-+-+ 901 | EAP | 902 |Server | 903 +-+-+-+-+ 905 Figure 3: Relationship between EAP peer, authenticator and server 907 2.2.1. Authenticator Identification 909 The EAP method conversation is between the EAP peer and server, as 910 identified by the Peer-ID and Server-ID. The authenticator identity, 911 if considered at all by the EAP method, is treated as an opaque blob 912 for the purposes of Channel bindings. However, the Secure 913 Association Protocol conversation is between the peer and the 914 authenticator, and therefore the authenticator and peer identities 915 are relevant to that exchange, and define the scope of use of the EAP 916 keying material passed down to the lower layer. 918 Where the EAP peer and authenticator cannot unambiguously identify 919 each other they may not be able to determine the scope of transported 920 EAP keying material. This is particularly problematic for lower 921 layers where key caching is supported. 923 For example, if the EAP peer cannot identify the EAP authenticator, 924 it will be unable to determine whether transported EAP keying 925 material has been shared outside of its authorized scope, and 926 therefore needs to be considered compromised. There is also a 927 practical problem because the EAP peer will be unable to utilize the 928 EAP authenticator key cache in an efficient way. Where the peer and 929 authenticator identify themselves within the lower layer using a port 930 identifier such as a link layer address, this creates a number of 931 problems: 933 [1] It may not be obvious to the peer which authenticator ports are 934 associated with which authenticators. 936 [2] It may not be obvious to the authenticator which peer ports are 937 associated with which peers. 939 [3] It may not be obvious to the peer which "virtual authenticator" it 940 is communicating with. 942 [4] It may not be obvious to the authenticator which "virtual peer" it 943 is communicating with. 945 Since an authenticator may have multiple ports, the authenticator 946 identifier used within the Secure Association Protocol exchange 947 SHOULD be distinct from any port identifier (e.g. MAC address). 948 Similarly, where a peer may have multiple ports, and sharing of EAP 949 keying material and parameters between peer ports of the same link 950 type is allowed, the peer identifier used within the Secure 951 Association Protocol exchange SHOULD also be distinct from any port 952 identifier. 954 AAA protocols such as RADIUS [RFC3579] and Diameter [RFC4072] 955 provide a mechanism for the identification of AAA clients; since 956 the EAP authenticator and AAA client are always co-resident, this 957 mechanism is applicable to the identification of EAP 958 authenticators. 960 RADIUS [RFC2865] requires that an Access-Request packet contain one 961 or more of the NAS-Identifier, NAS-IP-Address and NAS-IPv6-Address 962 attributes. Since a NAS may have more than one IP address, the 963 NAS-Identifier attribute is RECOMMENDED for the unambiguous 964 identification of the EAP authenticator. 966 From the point of view of the AAA server, EAP keying material and 967 parameters are transported to the EAP authenticator identified by 968 the NAS-Identifier attribute. Since an EAP authenticator MUST NOT 969 share EAP keying material or parameters with another party, if the 970 EAP peer or AAA server detects use of EAP keying material and 971 parameters outside the scope defined by the NAS-Identifier, the 972 keying material MUST be considered compromised. 974 In order to ensure that lower layer identifies are securely 975 verified by all parties, it is recommended that lower layers: 977 [a] Specify the lower layer parameters used to identify the 978 authenticator and peer; 980 [b] Communicate the lower layer identities between the peer and 981 authenticator within phase 0; 983 [c] Communicate the lower layer authenticator identity between the 984 authenticator and backend server within the NAS-Identifier 985 attribute; 987 [d] Include the lower layer identities within channel bindings (if 988 supported) in phase 1a, ensuring that they are communicated between 989 the EAP peer and server; 991 [e] Securely verify the lower layer identities within phase 2a; 993 [f] Utilize the advertised lower layer identities to enable the peer 994 and authenticator to verify that keys are maintained within the 995 advertised scope; 997 2.2.2. Virtual Authenticators 999 When a single physical authenticator advertises itself as multiple 1000 "virtual authenticators", the EAP peer and authenticator may not be 1001 able to agree on the scope of the EAP keying material, creating a 1002 security vulnerability. For example, the peer may assume that the 1003 "virtual authenticators" are distinct and do not share a key cache, 1004 whereas, depending on the architecture of the physical authenticator, 1005 a shared key cache may or may not be implemented. 1007 Where EAP keying material is shared between "virtual authenticators" 1008 an attacker acting as a peer could authenticate with the "Guest" 1009 "virtual authenticator" and derive EAP keying material. If the 1010 virtual authenticators share a key cache, then the peer can utilize 1011 the EAP keying material derived for the "Guest" network to obtain 1012 access to the "Corporate Intranet" virtual authenticator. 1014 Several measures are recommended to address these issues: 1016 [g] Authenticators are REQUIRED to cache associated authorizations 1017 along with EAP keying material and parameters and to apply 1018 authorizations consistently. This ensures that an attacker cannot 1019 obtain elevated privileges even where the key cache is shared 1020 between "virtual authenticators". 1022 [h] It is RECOMMENDED that physical authenticators maintain separate 1023 key caches for each "virtual authenticator". 1025 [i] It is RECOMMENDED that each "virtual authenticator" identify itself 1026 distinctly to the backend authentication server, such as by 1027 utilizing a distinct NAS-Identifier attribute. This enables the 1028 backend authentication server to utilize a separate credential to 1029 authenticate each "virtual authenticator". 1031 3. Key Management 1033 EAP as defined in [RFC3748] supports key derivation, but not key 1034 management. While EAP methods may derive keying material, EAP does 1035 not provide for the management of exported or derived keys. Although 1036 EAP methods may support "fast reconnect" as defined in [RFC3748] 1037 Section 7.2.1, EAP does not support re-key of exported keys without 1038 re-authentication. Existing EAP methods do not export the Key- 1039 Lifetime parameter; in the interest of method independence, key 1040 management of exported or derived keys SHOULD NOT be provided within 1041 EAP methods. 1043 3.1. Secure Association Protocol 1045 Since neither EAP nor EAP methods provide key management support, it 1046 is RECOMMENDED that key management facilities be provided within the 1047 Secure Association Protocol. This includes: 1049 [a] Entity Naming. A basic feature of a Secure Association Protocol is 1050 the explicit naming of the parties engaged in the exchange. 1051 Without explicit identification, the parties engaged in the 1052 exchange are not identified and the scope of the EAP keying 1053 parameters negotiated during the EAP exchange is undefined. As 1054 shown in Figure 3, both the peer and authenticator may have more 1055 than one physical or virtual port, and as a result SHOULD identify 1056 themselves in a manner that is independent of their attached ports. 1058 [b] Mutual proof of possession of EAP keying material. During the 1059 Secure Association Protocol the EAP peer and authenticator MUST 1060 demonstrate possession of the keying material transported between 1061 the backend authentication server and authenticator (e.g. MSK), in 1062 order to demonstrate that the peer and authenticator have been 1063 authorized. Since mutual proof of possession is not the same as 1064 mutual authentication, the peer cannot verify authenticator 1065 assertions (including the authenticator identity) as a result of 1066 this exchange. 1068 [c] Secure capabilities negotiation. In order to protect against 1069 spoofing during the discovery phase, ensure selection of the "best" 1070 ciphersuite, and protect against forging of negotiated security 1071 parameters, the Secure Association Protocol MUST support secure 1072 capabilities negotiation. This includes the secure negotiation of 1073 usage modes, session parameters (such as security association 1074 identifiers (SAIDs) and key lifetimes), ciphersuites and required 1075 filters, including confirmation of security-relevant capabilities 1076 discovered during phase 0. As part of secure capabilities 1077 negotiation, the Secure Association Protocol MUST support integrity 1078 and replay protection of all messages. 1080 [d] Key naming and selection. Where key caching is supported, it may 1081 be possible for the EAP peer and authenticator to share more than 1082 one key of a given type. As a result, the Secure Association 1083 Protocol MUST explicitly name the keys used in the proof of 1084 possession exchange, so as to prevent confusion when more than one 1085 set of keying material could potentially be used as the basis for 1086 the exchange. Use of the key naming mechanism described in this 1087 document is RECOMMENDED. 1089 In order to support the correct processing of phase 2 security 1090 associations, the Secure Association (phase 2) protocol MUST 1091 support the naming of phase 2 security associations and associated 1092 transient session keys, so that the correct set of transient 1093 session keys can be identified for processing a given packet. The 1094 phase 2 Secure Association Protocol also MUST support transient 1095 session key activation and SHOULD support deletion, so that 1096 establishment and re-establishment of transient session keys can be 1097 synchronized between the parties. 1099 [e] Generation of fresh transient session keys (TSKs). Where the lower 1100 layer supports caching of exported EAP keying material, the EAP 1101 peer lower layer may initiate a new session using keying material 1102 that was derived in a previous session. Were the TSKs to be 1103 derived from a portion of the exported EAP keying material, this 1104 would result in reuse of the session keys which could expose the 1105 underlying ciphersuite to attack. 1107 In lower layers where caching of EAP keying material is supported, 1108 the Secure Association Protocol phase is REQUIRED, and MUST support 1109 the derivation of fresh unicast and multicast TSKs, even when the 1110 keying material provided by the backend authentication server is 1111 not fresh. This is typically supported via the exchange of nonces 1112 or counters, which are then mixed with the exported keying material 1113 in order to generate fresh unicast (phase 2a) and possibly 1114 multicast (phase 2b) session keys. By not using EAP keying 1115 material directly to protect data, the Secure Association Protocol 1116 protects it against compromise. 1118 [f] Key lifetime management. This includes explicit key lifetime 1119 negotiation or seamless re-key. EAP does not support re-key 1120 without re-authentication and existing EAP methods do not support 1121 key lifetime negotiation. As a result, the Secure Association 1122 Protocol may handle re-key and determination of the key lifetime. 1123 Where key caching is supported, secure negotiation of key lifetimes 1124 is RECOMMENDED. Lower layers that support re-key, but not key 1125 caching, may not require key lifetime negotiation. For example, a 1126 difference between IKEv1 [RFC2409] and IKEv2 [RFC4306] is that in 1127 IKEv1 SA lifetimes were negotiated; in IKEv2, each end of the SA is 1128 responsible for enforcing its own lifetime policy on the SA and re- 1129 keying the SA when necessary. 1131 [g] Key resynchronization. It is possible for the peer or 1132 authenticator to reboot or reclaim resources, clearing portions or 1133 all of the key cache. Therefore, key lifetime negotiation cannot 1134 guarantee that the key cache will remain synchronized, and the peer 1135 may not be able to determine before attempting to use a key whether 1136 it exists within the authenticator cache. It is therefore 1137 RECOMMENDED for the Secure Association Protocol to provide a 1138 mechanism for key state resynchronization. Since in this situation 1139 one or more of the parties initially do not possess a key with 1140 which to protect the resynchronization exchange, securing this 1141 mechanism may be difficult. 1143 [h] Key scope synchronization. To support key scope determination, the 1144 Secure Association Protocol SHOULD provide a mechanism by which the 1145 peer can determine the scope of the key cache on each 1146 authenticator, and by which the authenticator can determine the 1147 scope of the key cache on a peer. This includes negotiation of 1148 restrictions on key usage. 1150 [i] Direct operation. Since the phase 2 Secure Association Protocol is 1151 concerned with the establishment of security associations between 1152 the EAP peer and authenticator, including the derivation of 1153 transient session keys, only those parties have "a need to know" 1154 the transient session keys. The Secure Association Protocol MUST 1155 operate directly between the peer and authenticator, and MUST NOT 1156 be passed-through to the backend authentication server, or include 1157 additional parties. 1159 [j] Bi-directional operation. While some ciphersuites only require a 1160 single set of transient session keys to protect traffic in both 1161 directions, other ciphersuites require a unique set of transient 1162 session keys in each direction. The phase 2 Secure Association 1163 Protocol SHOULD provide for the derivation of unicast and multicast 1164 keys in each direction, so as not to require two separate phase 2 1165 exchanges in order to create a bi-directional phase 2 security 1166 association. 1168 3.2. Key Scope 1170 Absent explicit specification within the lower layer, after the 1171 completion of phase 1b, EAP keying material and parameters are bound 1172 to the EAP peer and authenticator, but are not bound to a specific 1173 peer or authenticator port. 1175 While EAP Keying Material passed down to the lower layer is not 1176 intrinsically bound to particular authenticator and peer ports, 1177 Transient Session Keys MAY be bound to particular authenticator and 1178 peer ports by the Secure Association Protocol. However, a lower 1179 layer MAY also permit TSKs to be used on multiple peer and/or 1180 authenticator ports, providing that TSK freshness is guaranteed (such 1181 as by keeping replay counter state within the authenticator). 1183 In order to further limit the key scope the following measures are 1184 suggested: 1186 [a] The lower layer MAY specify additional restrictions on key usage, 1187 such as limiting the use of EAP keying material and parameters on 1188 the EAP peer to the port over which on the EAP conversation was 1189 conducted. 1191 [b] The backend authentication server and authenticator MAY implement 1192 additional attributes in order to further restrict the scope of EAP 1193 keying material. For example, in 802.11, the backend 1194 authentication server may provide the authenticator with a list of 1195 authorized Called or Calling-Station-Ids and/or SSIDs for which EAP 1196 keying material is valid. 1198 [c] Where the backend authentication server provides attributes 1199 restricting the key scope, it is RECOMMENDED that restrictions be 1200 securely communicated by the authenticator to the peer. This can 1201 be accomplished using the Secure Association Protocol, but also 1202 can be accomplished via the EAP method or the lower layer. 1204 3.3. Parent-Child Relationships 1206 When keying material exported by EAP methods expires, all keying 1207 material derived from the exported keying material expires, including 1208 the TSKs. 1210 When an EAP re-authentication takes place, new keying material is 1211 derived and exported by the EAP method, which eventually results in 1212 replacement of calculated keys, including the TSKs. 1214 As a result, while the lifetime of calculated keys can be less than 1215 or equal that of the exported keys they are derived from, it cannot 1216 be greater. For example, when EAP re-authentication occurs, TSK re- 1217 key will also occur. However, this does not prohibit TSK re-key from 1218 occurring prior to expiration of the lifetime of exported keys. For 1219 example, TSK re-key may occur prior to EAP re-authentication. 1221 Failure to mutually prove possession of keying material during the 1222 Secure Association Protocol exchange need not be grounds for deletion 1223 of the keying material by both parties; rate-limiting Secure 1224 Association Protocol exchanges could be used to prevent a brute force 1225 attack. 1227 3.4. Local Key Lifetimes 1229 The Transient EAP Keys (TEKs) are session keys used to protect the 1230 EAP conversation. The TEKs are internal to the EAP method and are 1231 not exported. TEKs are typically created during an EAP conversation, 1232 used until the end of the conversation and then discarded. However, 1233 methods may re-key TEKs during a conversation. 1235 When using TEKs within an EAP conversation or across conversations, 1236 it is necessary to ensure that replay protection and key separation 1237 requirements are fulfilled. For instance, if a replay counter is 1238 used, TEK re-key MUST occur prior to wrapping of the counter. 1239 Similarly, TSKs MUST remain cryptographically separate from TEKs 1240 despite TEK re-keying or caching. This prevents TEK compromise from 1241 leading directly to compromise of the TSKs and vice versa. 1243 EAP methods may cache local keying material which may persist for 1244 multiple EAP conversations when fast reconnect is used [RFC 3748]. 1245 For example, EAP methods based on TLS (such as EAP-TLS [RFC2716]) 1246 derive and cache the TLS Master Secret, typically for substantial 1247 time periods. The lifetime of other local keying material calculated 1248 within the EAP method is defined by the method. Note that in 1249 general, when using fast reconnect, there is no guarantee to that the 1250 original long-term credentials are still in the possession of the 1251 peer. For instance, a card hold holding the private key for EAP-TLS 1252 may have been removed. EAP servers SHOULD also verify that the long- 1253 term credentials are still valid, such as by checking that 1254 certificate used in the original authentication has not yet expired. 1256 3.5. Exported and Calculated Key Lifetimes 1258 All EAP methods generating keys are required to generate the MSK and 1259 EMSK, and may optionally generate the IV. However, EAP, defined in 1260 [RFC3748], does not itself support the negotiation of lifetimes for 1261 exported keying material such as the MSK, EMSK and IV. 1263 Several mechanisms exist for managing key lifetimes: 1265 [a] AAA attributes. AAA protocols such as RADIUS [RFC2865] and 1266 Diameter [RFC4072] support the Session-Timeout attribute. The 1267 Session-Timeout value represents the maximum lifetime of the 1268 exported keys, and all keys calculated from it, on the 1269 authenticator. Since existing backend authentication servers do 1270 not cache keys exported by EAP methods, or keys calculated from 1271 exported keys, the value of the Session-Timeout attribute has no 1272 bearing on the key lifetime within the backend authentication 1273 server. 1275 On the authenticator, where EAP is used for authentication, the 1276 Session-Timeout value represents the maximum session time prior to 1277 re-authentication, as described in [RFC3580]. Where EAP is used 1278 for pre-authentication, the session may not start until some future 1279 time, or may never occur. Nevertheless, the Session-Timeout value 1280 represents the maximum time after which transported EAP keying 1281 material, and all keys calculated from it, will have expired on the 1282 authenticator. If the session subsequently starts, re- 1283 authentication will be initiated once the Session-Time has expired. 1284 If the session never started, or started and ended, by default keys 1285 transported by AAA and all keys calculated from them will be 1286 expired by the authenticator prior to the future time indicated by 1287 Session-Timeout. Note that in future additional attributes may be 1288 specified to control the lifetime of cached keys; these attributes 1289 may modify the meaning of the Session-Timeout attribute in specific 1290 circumstances. 1292 Since the TSK lifetime is often determined by authenticator 1293 resources, the backend authentication server has no insight into 1294 the TSK derivation process, and by the principle of ciphersuite 1295 independence, it is not appropriate for the backend authentication 1296 server to manage any aspect of the TSK derivation process, 1297 including the TSK lifetime. 1299 [b] Lower layer mechanisms. While AAA attributes can communicate the 1300 maximum exported key lifetime, this only serves to synchronize the 1301 key lifetime between the backend authentication server and the 1302 authenticator. Lower layer mechanisms such as the Secure 1303 Association Protocol can then be used to enable the lifetime of 1304 exported and calculated keys to be negotiated between the peer and 1305 authenticator. 1307 Where TSKs are established as the result of a Secure Association 1308 Protocol exchange, it is RECOMMENDED that the Secure Association 1309 Protocol include support for TSK resynchronization. Where the TSK 1310 is taken from the MSK, there is no need to manage the TSK lifetime 1311 as a separate parameter, since the TSK lifetime and MSK lifetime 1312 are identical. 1314 [c] System defaults. Where the EAP method does not support the 1315 negotiation of the exported key lifetime, and a key lifetime 1316 negotiation mechanism is not provided by the lower lower, there may 1317 be no way for the peer to learn the exported key lifetime. In this 1318 case it is RECOMMENDED that the peer assume a default value of the 1319 exported key lifetime; 8 hours is recommended. Similarly, the 1320 lifetime of calculated keys can also be managed as a system 1321 parameter on the authenticator. 1323 [d] Method specific negotiation within EAP. While EAP itself does not 1324 support lifetime negotiation, it would be possible to specify 1325 methods that do. However, systems that rely on such negotiation 1326 for exported keys would only function with these methods. As a 1327 result, it is NOT RECOMMENDED to use this approach as the sole way 1328 to determine key lifetimes. 1330 3.6. Key cache synchronization 1332 Issues arise when attempting to synchronize the key cache on the peer 1333 and authenticator. 1335 While the AAA protocol can enable the backend authentication server 1336 to provide guidance on the lifetime of transported EAP keying 1337 material to the authenticator, this does not address the problem of 1338 key lifetime synchronization between the peer and authenticator. 1339 Where the EAP method does not export the Key-Lifetime parameter, the 1340 lifetime of the EAP keying material may not be defined until 1341 completion of the Secure Association Protocol, if ever. This can 1342 leave the peer uncertain how long the authenticator will maintain EAP 1343 keying material within the key cache. 1345 However, key lifetime negotiation alone cannot guarantee key cache 1346 synchronization. Even where the Secure Association Protocol is run 1347 immediately after EAP and determines the lifetime of EAP keying 1348 material, it is still possible for the authenticator to reclaim 1349 resources. 1351 The lower layer may utilize the Discovery phase 0 to improve key 1352 cache synchronization. For example, if the authenticator manages the 1353 key cache by deleting the oldest key first (LIFO), the relative 1354 creation time of the last key to be deleted could be advertised 1355 within the Discovery phase, enabling the peer to determine whether 1356 keying material had been prematurely expired from the authenticator 1357 key cache. 1359 3.7. Key Strength 1361 In order to guard against brute force attacks, EAP methods deriving 1362 keys need to be capable of generating keys with an appropriate 1363 effective symmetric key strength. In order to ensure that key 1364 generation is not the weakest link, it is RECOMMENDED that EAP 1365 methods utilizing public key cryptography choose a public key that 1366 has a cryptographic strength meeting the symmetric key strength 1367 requirement. 1369 As noted in [RFC3766] Section 5, this results in the following 1370 required RSA or DH module and DSA subgroup size in bits, for a given 1371 level of attack resistance in bits: 1373 Attack Resistance RSA or DH Modulus DSA subgroup 1374 (bits) size (bits) size (bits) 1375 ----------------- ----------------- ------------ 1376 70 947 128 1377 80 1228 145 1378 90 1553 153 1379 100 1926 184 1380 150 4575 279 1381 200 8719 373 1382 250 14596 475 1384 3.8. Key Wrap 1386 The key wrap specified in [RFC2548], which is based on an MD5-based 1387 stream cipher, has known problems, as described in [RFC3579] Section 1388 4.3. RADIUS uses the shared secret for multiple purposes, including 1389 per-packet authentication and attribute hiding, considerable 1390 information is exposed about the shared secret with each packet. 1391 This exposes the shared secret to dictionary attacks. MD5 is used 1392 both to compute the RADIUS Response Authenticator and the Message- 1393 Authenticator attribute, and concerns exist relating to the security 1394 of this hash [MD5Collision]. 1396 As discussed in [RFC3579] Section 4.3, the security vulnerabilities 1397 of RADIUS are extensive, and therefore development of an alternative 1398 key wrap technique based on the RADIUS shared secret would not 1399 substantially improve security. As a result, [RFC3759] Section 4.2 1400 recommends running RADIUS over IPsec. The same approach is taken in 1401 Diameter EAP [RFC4072], which defines cleartext key attributes, to be 1402 protected by IPsec or TLS. 1404 Where an untrusted AAA intermediary is present (such as a RADIUS 1405 proxy or a Diameter agent), and data object security is not used, 1406 transported keying material may be recovered by an attacker in 1407 control of the untrusted intermediary. Possession of transported 1408 keying material enables decryption of data traffic sent between the 1409 peer and a specific authenticator. However, as long as EAP keying 1410 material or keys derived from it are only utilized by a single 1411 authenticator, compromise of the transported keying material does not 1412 enable an attacker to impersonate the peer to another authenticator. 1413 Vulnerability to an untrusted AAA intermediary can be mitigated by 1414 implementation of redirect functionality, as described in [RFC3588] 1415 and [RFC4072]. 1417 4. Handoff Vulnerabilities 1419 With EAP, several mechanisms are available to reduce the latency in 1420 handoff between authenticators: 1422 [1] EAP pre-authentication. This utilizes EAP to pre-establish EAP 1423 keying material on an authenticator prior to arrival of the peer. 1424 Use of pre-authentication within IEEE 802.11 is described in 1425 [8021XHandoff] and [IEEE-802.11i]. 1427 [2] Key caching. This mechanism enables an EAP peer to re-attach to an 1428 authenticator without requiring EAP re-authentication. 1430 [3] Context transfer, such as is defined in [IEEE-802.11F] (now 1431 deprecated) and [RFC4067]. Use of context transfer for handoff 1432 latency improvement is described in [IEEE-02-758]. 1434 [4] Proactive key distribution, such as is described in [IEEE-02-758] 1435 and [I-D.irtf-aaaarch-handoff]. 1437 The sections that follow discuss the security vulnerabilities 1438 introduced by the above mechanisms. 1440 4.1. Authorization 1442 In a typical network access scenario (dial-in, wireless LAN, etc.) 1443 access control mechanisms are typically applied. These mechanisms 1444 include user authentication as well as authorization for the offered 1445 service. 1447 As a part of the authentication process, the backend authentication 1448 server determines the user's authorization profile. The user 1449 authorizations are transmitted by the backend authentication server 1450 to the EAP authenticator (also known as the Network Access Server or 1451 authenticator) along with the transported EAP keying material, in 1452 Phase 1b of the EAP conversation. Typically, the profile is 1453 determined based on the user identity, but a certificate presented by 1454 the user may also provide authorization information. 1456 The backend authentication server is responsible for making a user 1457 authorization decision, which requires answering the following 1458 questions: 1460 [a] Is this a legitimate user for this particular network? 1462 [b] Is the user allowed the type of access he or she is requesting? 1464 [c] Are there any specific parameters (mandatory tunneling, bandwidth, 1465 filters, and so on) that the access network should be aware of for 1466 this user? 1468 [d] Is the user operating within the time of day subscription rules? 1470 [e] Is the user within his limits for concurrent sessions? 1472 [f] Are there any fraud, credit limit, or other concerns that indicate 1473 that access should be denied? 1475 While the authorization decision is in principle simple, the process 1476 is complicated by the distributed nature of the decision making. 1477 Where brokering entities or proxies are involved, all of the AAA 1478 entities in the chain from the authenticator to the home backend 1479 authentication server are involved in the decision. For instance, a 1480 broker can disallow access even if the home backend authentication 1481 server would allow it, or a proxy can add authorizations (e.g., 1482 bandwidth limits). 1484 Decisions can be based on static policy definitions and profiles as 1485 well as dynamic state (e.g. time of day or limits on the number of 1486 concurrent sessions). In addition to the Accept/Reject decision made 1487 by the AAA chain, parameters or constraints can be communicated to 1488 the authenticator. 1490 The criteria for Accept/Reject decisions or the reasons for choosing 1491 particular authorizations are typically not communicated to the 1492 authenticator, only the final result. As a result, the authenticator 1493 has no way to know what the decision was based on. Was a set of 1494 authorization parameters sent because this service is always provided 1495 to the user, or was the decision based on the time/day and the 1496 capabilities of the requesting authenticator device? 1498 4.2. Correctness 1500 When the AAA exchange is bypassed via use of techniques such as key 1501 caching, it can be challenging to ensure that authorization is 1502 properly handled. Challenges include: 1504 [a] Consistent application of session time limits. Bypassing AAA 1505 should not automatically increase the available session time, 1506 allowing a user to endlessly extend their network access by 1507 changing the point of attachment. 1509 [b] Avoidance of privilege elevation. Bypassing AAA should not result 1510 in a user being granted access to services which they are not 1511 entitled to. 1513 [c] Consideration of dynamic state. In situations in which dynamic 1514 state is involved in the access decision (day/time, simultaneous 1515 session limit) it should be possible to take this state into 1516 account either before or after access is granted. Note that 1517 consideration of network-wide state such as simultaneous session 1518 limits can typically only be taken into account by the backend 1519 authentication server. 1521 [d] Encoding of restrictions. Since a authenticator may not be aware 1522 of the criteria considered by a backend authentication server when 1523 allowing access, in order to ensure consistent authorization during 1524 a fast handoff it may be necessary to explicitly encode the 1525 restrictions within the authorizations provided by the backend 1526 authentication server. 1528 [e] State validity. The introduction of fast handoff should not render 1529 the authentication server incapable of keeping track of network- 1530 wide state. 1532 A handoff mechanism capable of addressing these concerns is said to 1533 be "correct". One condition for correctness is as follows: 1535 For a handoff to be "correct" it MUST establish on the new device 1536 the same context as would have been created had the new device 1537 completed a AAA conversation with the backend authentication 1538 server. 1540 A properly designed handoff scheme will only succeed if it is 1541 "correct" in this way. If a successful handoff would establish 1542 "incorrect" state, it is preferable for it to fail, in order to avoid 1543 creation of incorrect context. 1545 Some authenticator and backend authentication server configurations 1546 are incapable of meeting this definition of "correctness". For 1547 example, if the old and new device differ in their capabilities, a 1548 handoff mechanism that bypasses AAA may find it difficult to meet 1549 this definition of correctness. Backend authentication servers often 1550 perform conditional evaluation, in which the authorizations returned 1551 in an Access-Accept message are contingent on the authenticator or on 1552 dynamic state such as the time of day or number of simultaneous 1553 sessions. For example, in a heterogeneous deployment, the backend 1554 authentication server might return different authorizations depending 1555 on the authenticator making the request, in order to make sure that 1556 the requested service is consistent with the authenticator 1557 capabilities. 1559 If differences between the new and old device would result in the 1560 backend authentication server sending a different set of messages to 1561 the new device than were sent to the old device, then if the handoff 1562 mechanism bypasses AAA, the handoff cannot be carried out correctly. 1564 For example, if some authenticators support dynamic VLANs while 1565 others do not, then attributes present in the Access-Request (such as 1566 the NAS-IP-Address, NAS-IPv6-Address, NAS-Identifier, etc.) could be 1567 examined to determine when VLAN attributes will be returned, as 1568 described in [RFC3580]. VLAN support is defined in [IEEE-802.1Q]. 1569 If a handoff bypassing the backend authentication server were to 1570 occur between a authenticator supporting dynamic VLANs and another 1571 authenticator which does not, then a guest user with access 1572 restricted to a guest VLAN could be given unrestricted access to the 1573 network. 1575 Similarly, in a network where access is restricted based on the day 1576 and time, Service Set Identifier (SSID), Calling-Station-Id or other 1577 factors, unless the restrictions are encoded within the 1578 authorizations, or a partial AAA conversation is included, then a 1579 handoff could result in the user bypassing the restrictions. 1581 In practice, these considerations limit the situations in which fast 1582 handoff mechanisms bypassing AAA can be expected to be successful. 1583 Where the deployed devices implement the same set of services, it may 1584 be possible to do successful handoffs within such mechanisms. 1585 However, where the supported services differ between devices, the 1586 handoff may not succeed. For example, [RFC2865] section 1.1 states: 1588 "A authenticator that does not implement a given service MUST NOT 1589 implement the RADIUS attributes for that service. For example, a 1590 authenticator that is unable to offer ARAP service MUST NOT 1591 implement the RADIUS attributes for ARAP. A authenticator MUST 1592 treat a RADIUS access-accept authorizing an unavailable service as 1593 an access-reject instead." 1595 Note that this behavior only applies to attributes that are known, 1596 but not implemented. For attributes that are unknown, [RFC2865] 1597 Section 5 states: 1599 "A RADIUS server MAY ignore Attributes with an unknown Type. A 1600 RADIUS client MAY ignore Attributes with an unknown Type." 1602 In order to perform a correct handoff, if a new device is provided 1603 with RADIUS context for a known but unavailable service, then it MUST 1604 process this context the same way it would handle a RADIUS Access- 1605 Accept requesting an unavailable service. This MUST cause the 1606 handoff to fail. However, if a new device is provided with RADIUS 1607 context that indicates an unknown attribute, then this attribute MAY 1608 be ignored. 1610 Although it may seem somewhat counter-intuitive, failure is indeed 1611 the "correct" result where a known but unsupported service is 1612 requested. Presumably a correctly configured backend authentication 1613 server would not request that a device carry out a service that it 1614 does not implement. This implies that if the new device were to 1615 complete a AAA conversation that it would be likely to receive 1616 different service instructions. In such a case, failure of the 1617 handoff is the desired result. This will cause the new device to go 1618 back to the backend server in order to receive the appropriate 1619 service definition. 1621 In practice, this implies that handoff mechanisms which bypass AAA 1622 are most likely to be successful within a homogeneous device 1623 deployment within a single administrative domain. For example, it 1624 would not be advisable to carry out a fast handoff bypassing AAA 1625 between a authenticator providing confidentiality and another 1626 authenticator that does not support this service. The correct result 1627 of such a handoff would be a failure, since if the handoff were 1628 blindly carried out, then the user would be moved from a secure to an 1629 insecure channel without permission from the backend authentication 1630 server. Thus the definition of a "known but unsupported service" 1631 MUST encompass requests for unavailable security services. This 1632 includes vendor-specific attributes related to security, such as 1633 those described in [RFC2548]. 1635 5. Security Considerations 1637 In order to analyze whether the EAP conversation achieves its 1638 security goals, it is first necessary to describe the threat model. 1639 The terms "Cryptographic binding", "Cryptographic separation", "Key 1640 strength" and "Mutual authentication" are defined in [RFC3748] and 1641 are used with the same meaning here. 1643 5.1. Threat Model 1645 The EAP threat model is described in [RFC3748] Section 7.1. The 1646 security properties of EAP methods (known as "security claims", 1647 described in [RFC3784] Section 7.2.1), address these threats. EAP 1648 method requirements for applications such as Wireless LAN 1649 authentication are described in [RFC4017]. The RADIUS threat model 1650 is described in [RFC3579] Section 4.1, and responses to these threats 1651 are described in [RFC3579] Sections 4.2 and 4.3. 1653 However, in addition to threats against EAP and AAA, there are other 1654 system-level threats worth discussing. These include: 1656 [1] An attacker may compromise or steal an EAP authenticator, in an 1657 attempt to gain access to other EAP authenticators or obtain long- 1658 term secrets. 1660 [2] An attacker may compromise an EAP authenticator in an effort to 1661 commit fraud. For example, a compromised authenticator may provide 1662 incorrect information to the EAP peer and/or server via out-of-band 1663 mechanisms (such as via a AAA or lower layer protocol). This 1664 includes impersonating another authenticator, or providing 1665 inconsistent information to the peer and EAP server. 1667 [3] An attacker may try to modify or spoof packets, including Discovery 1668 or Secure Association Protocol frames, EAP or AAA packets. 1670 [4] An attacker may attempt a downgrade attack in order to exploit 1671 known weaknesses in an authentication method or cryptographic 1672 transform. 1674 [5] An attacker may attempt to induce an EAP peer, authenticator or 1675 server to disclose keying material to an unauthorized party, or 1676 utilize keying material outside the context that it was intended 1677 for. 1679 [6] An attacker may replay packets. 1681 [7] An attacker may cause an EAP peer, authenticator or server to reuse 1682 an stale key. Use of stale keys may also occur unintentionally. 1684 For example, a poorly implemented backend authentication server may 1685 provide stale keying material to an authenticator, or a poorly 1686 implemented authenticator may reuse nonces. 1688 [8] An authenticated attacker may attempt to obtain elevated privilege 1689 in order to access information that it does not have rights to. 1691 In order to address these threats, [Housley] provides a description 1692 of mandatory system security properties. Issues relating system 1693 security requirements are discussed in the sections that follow. 1695 5.2. Authenticator Compromise 1697 In the event that an authenticator is compromised or stolen, an 1698 attacker may gain access to the network via that authenticator, or 1699 may obtain the credentials required for that authenticator/AAA client 1700 to communicate with one or more backend authentication servers. 1701 However, this should not allow the attacker to compromise other 1702 authenticators or the backend authentication server, or obtain long- 1703 term user credentials. 1705 The implications of this requirement are many, but some of the more 1706 important are as follows: 1708 No Key Sharing 1709 An EAP authenticator MUST NOT share any keying material with 1710 another EAP authenticator, since if one EAP authenticator were 1711 compromised, this would enable the compromise of keying material on 1712 another authenticator. In order to be able to determine whether 1713 keying material has been shared, it is necessary for the identity 1714 of the EAP authenticator to be defined and understood by all 1715 parties that communicate with it. 1717 No AAA Credential Sharing 1718 AAA credentials (such as RADIUS shared secrets, IPsec pre-shared 1719 keys or certificates) MUST NOT be shared between AAA clients, since 1720 if one AAA client were compromised, this would enable an attacker 1721 to impersonate other AAA clients to the backend authentication 1722 server, or even to impersonate a backend authentication server to 1723 other AAA clients. 1725 No Compromise of Long-Term Credentials 1726 An attacker obtaining TSKs, TEKs or EAP keying material such as the 1727 MSK MUST NOT be able to obtain long-term user credentials such as 1728 pre-shared keys, passwords or private-keys without breaking a 1729 fundamental cryptographic assumption. 1731 5.3. Spoofing 1733 The use of per-packet authentication and integrity protection 1734 provides protection against spoofing attacks. Diameter [RFC3588] 1735 provides support for per-packet authentication and integrity 1736 protection via use of IPsec or TLS. RADIUS/EAP [RFC3579] provides 1737 for per-packet authentication and integrity protection via use of the 1738 Message-Authenticator attribute. 1740 [RFC3748] Section 7.2.1 describes the "integrity protection" security 1741 claim and [RFC4017] requires use of EAP methods supporting this 1742 claim. 1744 In order to prevent forgery of Secure Association Protocol frames, 1745 per-frame authentication and integrity protection is RECOMMENDED on 1746 all messages. [IEEE-802.11i] supports per-frame integrity protection 1747 and authentication on all messages within the 4-way handshake except 1748 the first message. An attack leveraging this ommission is described 1749 in [Analysis]. 1751 5.4. Downgrade Attacks 1753 The ability to negotiate the use of a particular cryptographic 1754 algorithm provides resilience against compromise of a particular 1755 cryptographic algorithm. This is usually accomplished by including 1756 an algorithm identifier in the protocol, and by specifying the 1757 algorithm requirements in the protocol specification. In order to 1758 prevent downgrade attacks, secure confirmation of the "best" 1759 ciphersuite is required. 1761 [RFC3748] Section 7.2.1 describes the "protected ciphersuite 1762 negotiation" security claim that refers to the ability of an EAP 1763 method to negotiate the ciphersuite used to protect the EAP 1764 conversation, as well as to integrity protect the negotiation. 1765 [RFC4017] requires EAP methods satisfying this security claim. 1767 Diameter [RFC3588] provides support for cryptographic algorithm 1768 negotiation via use of IPsec or TLS. RADIUS [RFC3579] does not 1769 support the negotiation of cryptographic algorithms, and relies on 1770 MD5 for integrity protection, authentication and confidentiality, 1771 despite known weaknesses in the algorithm [MD5Collision]. This issue 1772 can be addressed via use of RADIUS over IPsec, as described in 1773 [RFC3579] Section 4.2. 1775 As a result, EAP methods and AAA protocols are capable of addressing 1776 downgrade attacks. To ensure against downgrade attacks within lower 1777 layer protocols, algorithm independence is REQUIRED with lower layers 1778 using EAP for key derivation. For interoperability, at least one 1779 suite of mandatory-to-implement algorithm MUST be selected. Lower 1780 layer protocols supporting EAP for key derivation SHOULD also support 1781 secure ciphersuite negotiation. As described in [RFC1968], PPP ECP 1782 does not provide support for secure ciphersuite negotiation. 1783 However, [IEEE-802.11i] does support secure ciphersuite negotiation. 1785 5.5. Unauthorized Disclosure 1787 While preserving algorithm independence, confidentiality of all 1788 keying material MUST be maintained. To prevent unauthorized disclose 1789 of keys, each party in the EAP conversation MUST be authenticated to 1790 the other parties with whom it communicates. Keying material MUST be 1791 bound to the appropriate context. 1793 [RFC3748] Section 7.2.1 describes the "mutual authentication" and 1794 "dictionary attack resistance" claims, and [RFC4017] requires EAP 1795 methods satisfying these claims. EAP methods complying with 1796 [RFC4017] therefore provide for mutual authentication between the EAP 1797 peer and server. Binding of EAP keying material (MSK, EMSK) to the 1798 appropriate context is provided by the Peer-ID and Server-ID which 1799 are exported along with the keying material. 1801 Diameter [RFC3588] provides for per-packet authentication and 1802 integrity protection via IPsec or TLS, and RADIUS/EAP [RFC3579] also 1803 provides for per-packet authentication and integrity protection. 1804 Where the NAS/authenticator and backend authentication server 1805 communicate directly and credible keywrap is used (see Section 3.8), 1806 this ensures that the AAA Key Transport phase achieves its security 1807 objectives: mutually authenticating the AAA client/authenticator and 1808 backend authentication server and providing EAP keying material to 1809 the EAP authenticator and to no other party. [RFC2607] Section 7 1810 describes the security issues ocurring when the authenticator and 1811 backend authentication server do not communicate directly. 1813 As noted in Section 3.1, the Secure Association Protocol does not by 1814 itself provide for mutual authentication between the EAP peer and 1815 authenticator, even if mutual possession of EAP keying material is 1816 proven. Where the NAS/authenticator and backend authentication 1817 server communicate directly, the backend authentication server can 1818 verify the correspondence between NAS identification attributes, the 1819 source address of packets sent by the NAS, and the AAA credentials. 1820 As long as the NAS has not shared its AAA credentials with another 1821 NAS, this allows the backend authentication server to authenticate 1822 the NAS. Using Channel Bindings, the EAP peer can then determine 1823 whether the NAS/authenticator has provided the same identifying 1824 information to the EAP peer and backend authentication server. 1826 Peer and authenticator authorization MUST be performed. 1828 Authorization is REQUIRED whenever a peer associates with a new 1829 authenticator. Authorization checking prevents an elevation of 1830 privilege attack, and ensures that an unauthorized authenticator is 1831 detected. Authorizations SHOULD be synchronized between the EAP 1832 peer, server, authenticator. Once the EAP conversation exchanges are 1833 complete, all of these parties should hold the same view of the 1834 authorizations associated the other parties. If peer authorization 1835 is restricted, then the peer SHOULD be made aware of the restriction. 1837 The AAA exchange provides the EAP authenticator with authorizations 1838 relating to the EAP peer. However, neither the EAP nor AAA exchanges 1839 provides authorizations to the EAP peer. In order to ensure that all 1840 parties hold the same view of the authorizations it is RECOMMENDED 1841 that the Secure Association Protocol enable communication of 1842 authorizations between the EAP authenticator and peer. 1844 In order to enable key binding and authorization of all parties, it 1845 is RECOMMENDED that the parties use a set of identities that are 1846 consistent between the conversation phases. Consistently identifying 1847 the EAP authenticator enables the EAP peer to determine whether EAP 1848 keying material has been shared between EAP authenticators as well as 1849 to confirm with the backend authentication server that an EAP 1850 authenticator proving possession of EAP keying material during the 1851 Secure Association Protocol was authorized to obtain it. 1852 Identification issues are discussed in Section 2.2 and key scope 1853 issues are discussed in Section 3.2. 1855 5.6. Replay Protection 1857 Replay protection allows a protocol message recipient to discard any 1858 message that was recorded during a previous legitimate dialogue and 1859 presented as though it belonged to the current dialogue. 1861 [RFC3748] Section 7.2.1 describes the "replay protection" security 1862 claim and [RFC4017] requires use of EAP methods supporting this 1863 claim. 1865 Diameter [RFC3588] provides support for replay protection via use of 1866 IPsec or TLS. RADIUS/EAP [RFC3579] protects against replay of keying 1867 material via the Request Authenticator. However, some RADIUS packets 1868 are not replay protected. In Accounting, Disconnect and CoA-Request 1869 packets the Request Authenticator contains a keyed MAC rather than a 1870 Nonce. The Response Authenticator in Accounting, Disconnect and CoA 1871 Response packets also contains a keyed MAC whose calculation does not 1872 depend on a Nonce in either the Request or Response packets. 1873 Therefore unless an Event-Timestamp attribute is included or IPsec is 1874 used, the recipient may not be able to determine whether these 1875 packets have been replayed. 1877 In order to prevent replay of Secure Association Protocol frames, 1878 replay protection is REQUIRED on all messages. [IEEE-802.11i] 1879 supports replay protection on all messages within the 4-way 1880 handshake. 1882 5.7. Key Freshness 1884 A session key should be considered compromised if it remains in use 1885 too long. As noted in [Housley], session keys MUST be strong and 1886 fresh, while preserving algorithm independence. A fresh 1887 cryptographic key is one that is generated specifically for the 1888 intended use. Each session deserves an independent session key; 1889 disclosure of one session key MUST NOT aid the attacker in 1890 discovering any other session keys. 1892 Fresh keys are required even when a long replay counter (that is, one 1893 that "will never wrap") is used to ensure that loss of state does not 1894 cause the same counter value to be used more than once with the same 1895 session key. 1897 EAP, AAA and the lower layer each bear responsibility for ensuring 1898 the use of fresh, strong session keys: 1900 EAP EAP methods need to ensure the freshness and strength of EAP keying 1901 material provided as an input to session key derivation. [RFC3748] 1902 Section 7.10 states that "EAP methods SHOULD ensure the freshness 1903 of the MSK and EMSK, even in cases where one party may not have a 1904 high quality random number generator. A RECOMMENDED method is for 1905 each party to provide a nonce of at least 128 bits, used in the 1906 derivation of the MSK and EMSK." The contribution of nonces 1907 enables the EAP peer and server to ensure that exported EAP keying 1908 material is fresh. 1910 [RFC3748] Section 7.2.1 describes the "key strength" and "session 1911 independence" security claims, and and [RFC4017] requires use of 1912 EAP methods supporting these claims as well as being capable of 1913 providing an equivalent key strength of 128 bits or greater. 1915 AAA The AAA protocol needs to ensure that transported keying material 1916 is fresh and is not utilized outside its recommended lifetime. 1917 Replay protection is necessary for key freshness, but an attacker 1918 can deliver a stale (and therefore potentially compromised) key in 1919 a replay-protected message, so replay protection is not sufficient. 1921 The EAP Session-ID, derived from the EAP Type and Method-ID (based 1922 on the nonces contributed by the peer and server) enables the EAP 1923 peer, authenticator and server to distinguish EAP conversations. 1924 However, unless the authenticator keeps track of EAP Session-IDs, 1925 the authenticator cannot use the Session-ID to guarantee the 1926 freshness of EAP keying material. 1928 As described in [RFC3580] Section 3.17, When sent in an Access- 1929 Accept along with a Termination-Action value of RADIUS-Request, the 1930 Session-Timeout attribute specifies the maximum number of seconds 1931 of service provided prior to re-authentication. [IEEE-802.11i] 1932 also utilizes the Session-Timeout attribute to limit the maximum 1933 time that EAP keying material may be cached. Therefore the use of 1934 the Session-Timeout attribute enables the backend authentication 1935 server to limit the exposure of EAP keying material. 1937 Lower Layer 1938 As described in Section 3.1, the lower layer Secure Association 1939 Protocol MUST generate a fresh session key for each session, even 1940 if the keying material and parameters provided by EAP methods are 1941 cached, or either the peer or authenticator lack a high entropy 1942 random number generator. A RECOMMENDED method is for the peer and 1943 authenticator to each provide a nonce or counter used in session 1944 key derivation. If a nonce is used, it is RECOMMENDED that it be 1945 at least 128 bits. 1947 5.8. Elevation of Privilege 1949 Parties MUST NOT have access to keying material that is not needed to 1950 perform their own role. A party has access to a particular key if it 1951 has access to all of the secret information needed to derive it. If 1952 a Secure Association Protocol is used to establish session keys, it 1953 MUST specify the scope for session keys. 1955 Transported EAP keying material is permitted to be accessed by the 1956 EAP peer, authenticator and server. The EAP peer and server derive 1957 the transported keying material during the process of mutually 1958 authenticating each other using the selected EAP method. During the 1959 Secure Association Protocol, the EAP peer utilizes the transported 1960 EAP keying material to demonstrate to the authenticator that it is 1961 the same party that authenticated to the EAP server and was 1962 authorized by it. The EAP authenticator utilizes the transported EAP 1963 keying material to prove to the peer not only that the EAP 1964 conversation was transported through it (this could be demonstrated 1965 by a man-in-the-middle), but that it was uniquely authorized by the 1966 EAP server to provide the peer with access to the network. Unique 1967 authorization can only be demonstrated if the EAP authenticator does 1968 not share the transported keying material with a party other than the 1969 EAP peer and server. 1971 TSKs are permitted to be accessed only by the EAP peer and 1972 authenticator (see Section 1.5). As discussed in Section 2.1, PPP 1973 and 802.11i derive the TSKs from transported EAP keying material; 1974 802.16e utilizes transported EAP keying material for TSK keywrap; 1975 IKEv2 utilizes transported EAP keying material only to authenticate 1976 the derivation of TSKs. 1978 Where demonstration of authorization depends entirely on possession 1979 of transported EAP keying material (such as in PPP, 802.11i and 1980 802.16e), this enables the backend server to masquerade as the 1981 authenticator, and possibly to obtain the TSKs unless the backend 1982 server deletes the transported EAP keying material after sending it. 1984 5.9. Man-in-the-middle Attacks 1986 As described in [I-D.puthenkulam-eap-binding], EAP method sequences 1987 and compound authentication mechanisms may be subject to man-in-the- 1988 middle attacks. When such attacks are successfully carried out, the 1989 attacker acts as an intermediary between a victim and a legitimate 1990 authenticator. This allows the attacker to authenticate successfully 1991 to the authenticator, as well as to obtain access to the network. 1993 In order to prevent these attacks, [I-D.puthenkulam-eap-binding] 1994 recommends derivation of a compound key by which the EAP peer and 1995 server can prove that they have participated in the entire EAP 1996 exchange. Since the compound key must not be known to an attacker 1997 posing as an authenticator, and yet must be derived from quantities 1998 that are exported by EAP methods, it may be desirable to derive the 1999 compound key from a portion of the EMSK. In order to provide proper 2000 key hygiene, it is recommended that the compound key used for man-in- 2001 the-middle protection be cryptographically separate from other keys 2002 derived from the EMSK. 2004 5.10. Denial of Service Attacks 2006 Key caching may result in vulnerability to denial of service attacks. 2007 For example, EAP methods that create persistent state may be 2008 vulnerable to denial of service attacks on the EAP server by a rogue 2009 EAP peer. 2011 To address this vulnerability, EAP methods creating persistent state 2012 may wish to limit the persistent state created by an EAP peer. For 2013 example, for each peer an EAP server may choose to limit persistent 2014 state to a few EAP conversations, distinguished by the EAP Session- 2015 ID. This prevents a rogue peer from denying access to other peers. 2017 Similarly, to conserve resources an authenticator may choose to limit 2018 the persistent state corresponding to each peer. This can be 2019 accomplished by limiting each peer to persistent state corresponding 2020 to a few EAP conversations, distinguished by the EAP Session-ID. 2022 Depending on the media, creation of new TSKs may or may not imply 2023 deletion of previously derived TSKs. Where there is no implied 2024 deletion, the authenticator may choose to limit the number of TSKs 2025 and associated state that can be stored for each peer. 2027 5.11. Impersonation 2029 Both the RADIUS [RFC2865] and Diameter [RFC3588] protocols are 2030 potentially vulnerable to impersonation by a rogue authenticator. 2031 While both protocols support mutual authentication between the 2032 authenticator (known as the AAA client) and the backend 2033 authentication server (known as the backend authentication server), 2034 the security mechanisms vary. 2036 In RADIUS, the shared secret used for authentication is determined by 2037 the source address of the RADIUS packet. As noted in [RFC3579] 2038 Section 4.3.7, it is highly desirable that the source address be 2039 checked against one or more NAS identification attributes so as to 2040 detect and prevent impersonation attacks. 2042 When RADIUS Access-Requests are forwarded by a proxy, the NAS-IP- 2043 Address or NAS-IPv6-Address attributes may not correspond to the 2044 source address. Since the NAS-Identifier attribute need not contain 2045 an FQDN, it also may not correspond to the source address, even 2046 indirectly. [RFC2865] Section 3 states: 2048 A RADIUS server MUST use the source IP address of the RADIUS 2049 UDP packet to decide which shared secret to use, so that 2050 RADIUS requests can be proxied. 2052 This implies that it is possible for a rogue authenticator to forge 2053 NAS-IP-Address, NAS-IPv6-Address or NAS-Identifier attributes within 2054 a RADIUS Access-Request in order to impersonate another 2055 authenticator. Among other things, this can result in messages (and 2056 transported keying material) being sent to the wrong authenticator. 2057 Since the rogue authenticator is authenticated by the RADIUS proxy or 2058 server purely based on the source address, other mechanisms are 2059 required to detect the forgery. In addition, it is possible for 2060 attributes such as the Called-Station-Id and Calling-Station-Id to be 2061 forged as well. 2063 [RFC3579] Section 4.3.7 describes how an EAP pass-through 2064 authenticator acting as a AAA client can be detected if it attempts 2065 to impersonate another authenticator (such by sending incorrect 2066 Called-Station-ID [RFC2865], NAS-Identifier [RFC2865], NAS-IP-Address 2067 [RFC2865] or NAS-IPv6-Address [RFC3162] attributes via the AAA 2068 protocol). This vulnerabilityh can be mitigated by having RADIUS 2069 proxies check NAS identification attributes against the source 2070 address. 2072 While [RFC3588] requires use of the Route-Record AVP, this utilizes 2073 FQDNs, so that impersonation detection requires DNS A, AAAA and PTR 2074 Resource Records (RRs) to be properly configured. As a result, 2075 Diameter is as vulnerable to this attack as RADIUS, if not more so. 2076 To address this vulnerability, it is necessary to allow the backend 2077 authentication server to communicate with the authenticator directly, 2078 such as via the redirect functionality supported in [RFC3588]. 2080 5.12. Channel Binding 2082 It is possible for a compromised or poorly implemented EAP 2083 authenticator to communicate incorrect information to the EAP peer 2084 and/or server. This may enable an authenticator to impersonate 2085 another authenticator or communicate incorrect information via out- 2086 of-band mechanisms (such as via AAA or the lower layer). 2088 Where EAP is used in pass-through mode, the EAP peer does not verify 2089 the identity of the pass-through authenticator. Within the Secure 2090 Association Protocol, the EAP peer and authenticator only demonstrate 2091 mutual possession of the transported EAP keying material. This 2092 creates a potential security vulnerability, described in [RFC3748] 2093 Section 7.15. 2095 As described in the previous section, it is possible for a proxy to 2096 detect a AAA client attempting to impersonate another authenticator 2097 (such by sending incorrect Called-Station-ID [RFC2865], NAS- 2098 Identifier [RFC2865], NAS-IP-Address [RFC2865] or NAS-IPv6-Address 2099 [RFC3162] attributes via the AAA protocol). However, it is possible 2100 for a pass-through authenticator acting as a AAA client to provide 2101 correct information to the backend authentication server while 2102 communicating misleading information to the EAP peer via the lower 2103 layer. 2105 For example, a compromised authenticator can utilize another 2106 authenticator's Called-Station-Id or NAS-Identifier in communicating 2107 with the EAP peer via the lower layer. Also, a pass-through 2108 authenticator acting as a AAA client can provide an incorrect peer 2109 Calling-Station-Id [RFC2865][RFC3580] to the AAA server via the AAA 2110 protocol. 2112 As noted in [RFC3748] Section 7.15, this vulnerability can be 2113 addressed by EAP methods that support a protected exchange of channel 2114 properties such as endpoint identifiers, including (but not limited 2115 to): Called-Station-Id [RFC2865][RFC3580], Calling-Station-Id 2116 [RFC2865][RFC3580], NAS-Identifier [RFC2865], NAS-IP-Address 2117 [RFC2865], and NAS-IPv6-Address [RFC3162]. 2119 Using such a protected exchange, it is possible to match the channel 2120 properties provided by the authenticator via out-of-band mechanisms 2121 against those exchanged within the EAP method. For example, see [I- 2122 D.arkko-eap-service-identity-auth]. 2124 It is also possible to achieve Channel Bindings without transporting 2125 data over EAP. For example, see [I-D.draft-ohba-eap-aaakey-binding]. 2126 In this approach the authenticator informs the backend server about 2127 the Channel Binding parameters using AAA, and the backend server 2128 calculates transported keying material based on this parameter set, 2129 making it impossible for the peer and authenticator to complete the 2130 Secure Association Protocol if there was a mismatch in the 2131 parameters. 2133 The main difference between these approaches is that Channel Binding 2134 support within an EAP method may require upgrading or changing the 2135 EAP method, impacting both the peer and the server. Where Channel 2136 Bindings are implemented in AAA, the peer, authenticator and the 2137 backend server need to be upgraded, but the EAP method need not be 2138 modified. 2140 6. IANA Considerations 2142 This specification does not request the creation of any new parameter 2143 registries, nor does it require any other IANA assignments. 2145 7. References 2147 7.1. Normative References 2149 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2150 Requirement Levels", BCP 14, RFC 2119, March 1997. 2152 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 2153 Lefkowetz, "Extensible Authentication Protocol (EAP)", RFC 2154 3748, June 2004. 2156 7.2. Informative References 2158 [Analysis] He, C. and J. Mitchell, "Analysis of the 802.11i 4-Way 2159 Handshake", Proceedings of the 2004 ACM Workshop on 2160 Wireless Security, pp. 43-50, ISBN: 1-58113-925-X. 2162 [GKDP] Dondeti, L., Xiang, J. and S. Rowles, "GKDP: Group Key 2163 Distribution Protocol", Internet draft (work in progress), 2164 draft-ietf-msec-gkdp-01, March 2006. 2166 [GSAKMP] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP: 2167 Group Secure Association Group Management Protocol", 2168 Internet draft (work in progress), draft-ietf-msec-gsakmp- 2169 sec-10, May 2005. 2171 [He] He, C., Sundararajan, M., Datta, A. Derek, A. and J. C. 2172 Mitchell, "A Modular Correctness Proof of TLS and IEEE 2173 802.11i", ACM Conference on Computer and Communications 2174 Security (CCS '05), November, 2005. 2176 [Housley] Housley, R. and B. Aboba, "AAA Key Management", draft- 2177 housley-aaa-key-mgmt-01.txt, Internet draft (work in 2178 progress), November 2005. 2180 [IEEE-802.11] 2181 Institute of Electrical and Electronics Engineers, 2182 "Information technology - Telecommunications and 2183 information exchange between systems - Local and 2184 metropolitan area networks - Specific Requirements Part 11: 2185 Wireless LAN Medium Access Control (MAC) and Physical Layer 2186 (PHY) Specifications", IEEE IEEE Standard 802.11-2003, 2187 2003. 2189 [IEEE-802.1X] 2190 Institute of Electrical and Electronics Engineers, "Local 2191 and Metropolitan Area Networks: Port-Based Network Access 2192 Control", IEEE Standard 802.1X-2004, December 2004. 2194 [IEEE-802.1Q] 2195 Institute of Electrical and Electronics Engineers, "IEEE 2196 Standards for Local and Metropolitan Area Networks: Draft 2197 Standard for Virtual Bridged Local Area Networks", IEEE 2198 Standard 802.1Q/D8, January 1998. [IEEE802.11i] Institute 2199 of Electrical and Electronics Engineers, "Supplement to 2200 Standard for Telecommunications and Information Exchange 2201 Between Systems - LAN/MAN Specific Requirements - Part 11: 2202 Wireless LAN Medium Access Control (MAC) and Physical Layer 2203 (PHY) Specifications: Specification for Enhanced Security", 2204 IEEE 802.11i, July 2004. 2206 [IEEE-802.11F] 2207 Institute of Electrical and Electronics Engineers, 2208 "Recommended Practice for Multi-Vendor Access Point 2209 Interoperability via an Inter-Access Point Protocol Across 2210 Distribution Systems Supporting IEEE 802.11 Operation", 2211 IEEE 802.11F, July 2003 (now deprecated). 2213 [IEEE-802.16e] 2214 Institute of Electrical and Electronics Engineers, "IEEE 2215 Standard for Local and Metropolitan Area Networks: Part 16: 2216 Air Interface for Fixed and Mobile Broadband Wireless 2217 Access Systems: Amendment for Physical and Medium Access 2218 Control Layers for Combined Fixed and Mobile Operations in 2219 Licensed Bands" IEEE 802.16e, August 2005. 2221 [IEEE-02-758] 2222 Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, 2223 "Proactive Caching Strategies for IAPP Latency Improvement 2224 during 802.11 Handoff", IEEE 802.11 Working Group, 2225 IEEE-02-758r1-F Draft 802.11I/D5.0, November 2002. 2227 [IEEE-03-084] 2228 Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, 2229 "Proactive Key Distribution to support fast and secure 2230 roaming", IEEE 802.11 Working Group, IEEE-03-084r1-I, 2231 http://www.ieee802.org/11/Documents/DocumentHolder/ 2232 3-084.zip, January 2003. 2234 [I-D.puthenkulam-eap-binding] 2235 Puthenkulam, J., "The Compound Authentication Binding 2236 Problem", draft-puthenkulam-eap-binding-04 (work in 2237 progress), October 2003. 2239 [I-D.arkko-eap-service-identity-auth] 2240 Arkko, J. and P. Eronen, "Authenticated Service Information 2241 for the Extensible Authentication Protocol (EAP)", draft- 2242 arkko-eap-service-identity-auth-02.txt (work in progress), 2243 May 2005. 2245 [I-D.ohba-eap-aaakey-binding] 2246 Ohba, Y., "AAA-Key Derivation with Channel Binding", draft- 2247 ohba-eap-aaakey-binding-00.txt (work in progress), May 2248 2005. 2250 [I-D.irtf-aaaarch-handoff] 2251 Arbaugh, W. and B. Aboba, "Handoff Extension to RADIUS", 2252 draft-irtf-aaaarch-handoff-04.txt (work in progress), 2253 October 2003. 2255 [MD5Collision] 2256 Klima, V., "Tunnels in Hash Functions: MD5 Collisions 2257 Within a Minute", Cryptology ePrint Archive, March 2006, 2258 http://eprint.iacr.org/2006/105.pdf 2260 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 2261 RFC 1661, July 1994. 2263 [RFC1968] Meyer, G. and K. Fox, "The PPP Encryption Control Protocol 2264 (ECP)", RFC 1968, June 1996. 2266 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 2267 (IKE)", RFC 2409, November 1998. 2269 [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D. 2270 and R. Wheeler, "A Method for Transmitting PPP Over 2271 Ethernet (PPPoE)", RFC 2516, February 1999. 2273 [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2274 2535, March 1999. 2276 [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", 2277 RFC 2548, March 1999. 2279 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 2280 Implementation in Roaming", RFC 2607, June 1999. 2282 [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication 2283 Protocol", RFC 2716, October 1999. 2285 [RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for 2286 specifying the location of services (DNS SRV)", RFC 2782, 2287 February 2000. 2289 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. 2290 Wellington, "Secret Key Transaction Authentication for DNS 2291 (TSIG)", RFC 2845, May 2000. 2293 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 2294 Authentication Dial In User Service (RADIUS)", RFC 2865, 2295 June 2000. 2297 [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures 2298 (SIG(0)s )", RFC 2931, September 2000. 2300 [RFC3007] Wellington, B., "Simple Secure Domain Name System (DNS) 2301 Dynamic Update", RFC 3007, November 2000. 2303 [RFC3547] Baugher, M., Weis, B., Hardjono, T. and H. Harney, "The 2304 Group Domain of Interpretation", RFC 3547, July 2003. 2306 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 2307 Dial In User Service) Support For Extensible Authentication 2308 Protocol (EAP)", RFC 3579, September 2003. 2310 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese, 2311 "IEEE 802.1X Remote Authentication Dial In User Service 2312 (RADIUS) Usage Guidelines", RFC 3580, September 2003. 2314 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. 2315 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 2317 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public 2318 Keys Used For Exchanging Symmetric Keys", RFC 3766, April 2319 2004. 2321 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M. and K. 2322 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 2323 August 2004. 2325 [RFC4017] Stanley, D., Walker, J. and B. Aboba, "EAP Method 2326 Requirements for Wireless LANs", RFC 4017, March 2005. 2328 [RFC4046] Baugher, M., Canetti, R., Dondeti, L. and F. Lindholm, 2329 "Multicast Security (MSEC) Group Key Management 2330 Architecture", RFC 4046, April 2005. 2332 [RFC4067] Loughney, J., Nakhjiri, M., Perkins, C. and R. Koodli, 2333 "Context Transfer Protocol (CXTP)", RFC 4067, July 2005. 2335 [RFC4072] Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible 2336 Authentication Protocol (EAP) Application", RFC 4072, 2337 August 2005. 2339 [RFC4118] Yang, L., Zerfos, P. and E. Sadot, "Architecture Taxonomy 2340 for Control and Provisioning of Wireless Access Points 2341 (CAPWAP)", RFC 4118, June 2005. 2343 [RFC4186] Haverinen, H. and J. Salowey, "Extensible Authentication 2344 Protocol Method for Global System for Mobile Communications 2345 (GSM) Subscriber Identity Modules (EAP-SIM)", RFC 4186, 2346 January 2006. 2348 [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication 2349 Protocol Method for 3rd Generation Authentication and Key 2350 Agreement (EAP-AKA)", RFC 4187, January 2006. 2352 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 2353 4306, December 2005. 2355 [8021XHandoff] 2356 Pack, S. and Y. Choi, "Pre-Authenticated Fast Handoff in a 2357 Public Wireless LAN Based on IEEE 802.1X Model", School of 2358 Computer Science and Engineering, Seoul National 2359 University, Seoul, Korea, 2002. 2361 Acknowledgments 2363 Thanks to Arun Ayyagari, Ashwin Palekar, and Tim Moore of Microsoft, 2364 Dorothy Stanley of Agere, Bob Moskowitz of TruSecure, Jesse Walker of 2365 Intel, Joe Salowey of Cisco and Russ Housley of Vigil Security for 2366 useful feedback. 2368 Authors' Addresses 2370 Bernard Aboba 2371 Microsoft Corporation 2372 One Microsoft Way 2373 Redmond, WA 98052 2375 EMail: bernarda@microsoft.com 2376 Phone: +1 425 706 6605 2377 Fax: +1 425 936 7329 2379 Dan Simon 2380 Microsoft Research 2381 Microsoft Corporation 2382 One Microsoft Way 2383 Redmond, WA 98052 2385 EMail: dansimon@microsoft.com 2386 Phone: +1 425 706 6711 2387 Fax: +1 425 936 7329 2389 Jari Arkko 2390 Ericsson 2391 Jorvas 02420 2392 Finland 2394 Phone: 2395 EMail: jari.arkko@ericsson.com 2397 Pasi Eronen 2398 Nokia Research Center 2399 P.O. Box 407 2400 FIN-00045 Nokia Group 2401 Finland 2402 EMail: pasi.eronen@nokia.com 2404 Henrik Levkowetz (editor) 2405 ipUnplugged AB 2406 Arenavagen 27 2407 Stockholm S-121 28 2408 SWEDEN 2410 Phone: +46 708 32 16 08 2411 EMail: henrik@levkowetz.com 2413 Appendix A - Exported Parameters in Existing Methods 2415 This Appendix specifies Method-ID, Peer-ID, Server-ID and Key- 2416 Lifetime for EAP methods that have been published prior to this 2417 specification. Future EAP method specifications MUST include a 2418 definition of the Method-ID, Peer-ID, and Server-ID (could be the 2419 empty string) and MAY also define the Key-Lifetime (assumed to be 2420 indeterminate if not described). 2422 EAP-Identity 2424 The EAP-Identity method is defined in [RC3748]. It does not 2425 derive keys, and therefore does not define the Key-Lifetime or 2426 Method-ID. The Peer-ID exported by the Identity method is 2427 determined by the octets included within the EAP- 2428 Response/Identity. The Server-ID is the empty string (zero 2429 length). 2431 EAP-Notification 2433 The EAP-Notification method is defined in [RFC3748]. It does not 2434 derive keys and therefore does not define the Key-Lifetime and 2435 Method-ID. The Peer-ID and Server-ID are the empty string (zero 2436 length). 2438 EAP-GTC 2440 The EAP-GTC method is defined in [RFC3748]. It does not derive 2441 keys and therefore does not define the Key-Lifetime and Method-ID. 2442 The Peer-ID and Server-ID are the empty string. 2444 EAP-OTP 2446 The EAP-OTP method is defined in [RFC3748]. It does not derive 2447 keys and therefore does not define the Key-Lifetime and Method-ID. 2448 The Peer-ID and Server-ID are the empty string. 2450 EAP-TLS 2452 EAP-TLS is defined in [RFC2716]. The EAP-TLS Method-Id is the 2453 concatenation of the peer and server nonces. The Peer-ID and 2454 Server-ID are the contents of the altSubjectName in the peer and 2455 server certificates. EAP-TLS does not negotiate a Key-Lifetime. 2457 EAP-AKA 2459 EAP-AKA is defined in [RFC4187]. The EAP-AKA Method-Id is the 2460 contents of the RAND field from the AT_RAND attribute, followed by 2461 the contents of the AUTN field in the AT_AUTN attribute. 2463 The Peer-ID is the contents of the Identity field from the 2464 AT_IDENTITY attribute, using only the Actual Identity Length 2465 octets from the beginning, however. Note that the contents are 2466 used as they are transmitted, regardless of whether the 2467 transmitted identity was a permanent, pseudonym, or fast re- 2468 authentication identity. The Server-ID is an empty string. EAP- 2469 AKA does not negotiate a key lifetime. 2471 EAP-SIM 2473 EAP-SIM is defined in [RFC4186]. The EAP-SIM Method-Id is the 2474 contents of the RAND field from the AT_RAND attribute, followed by 2475 the contents of the NONCE_MT field in the AT_NONCE_MT attribute. 2477 The Peer-ID is the contents of the Identity field from the 2478 AT_IDENTITY attribute, using only the Actual Identity Length 2479 octets from the beginning, however. Note that the contents are 2480 used as they are transmitted, regardless of whether the 2481 transmitted identity was a permanent, pseudonym, or fast re- 2482 authentication identity. The Server-ID is an empty string. EAP- 2483 SIM does not negotiate a key lifetime. 2485 Intellectual Property Statement 2487 The IETF takes no position regarding the validity or scope of any 2488 Intellectual Property Rights or other rights that might be claimed to 2489 pertain to the implementation or use of the technology described in 2490 this document or the extent to which any license under such rights 2491 might or might not be available; nor does it represent that it has 2492 made any independent effort to identify any such rights. Information 2493 on the procedures with respect to rights in RFC documents can be 2494 found in BCP 78 and BCP 79. 2496 Copies of IPR disclosures made to the IETF Secretariat and any 2497 assurances of licenses to be made available, or the result of an 2498 attempt made to obtain a general license or permission for the use of 2499 such proprietary rights by implementers or users of this 2500 specification can be obtained from the IETF on-line IPR repository at 2501 http://www.ietf.org/ipr. 2503 The IETF invites any interested party to bring to its attention any 2504 copyrights, patents or patent applications, or other proprietary 2505 rights that may cover technology that may be required to implement 2506 this standard. Please address the information to the IETF at ietf- 2507 ipr@ietf.org. 2509 Disclaimer of Validity 2511 This document and the information contained herein are provided on an 2512 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2513 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2514 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2515 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2516 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2517 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2519 Copyright Statement 2521 Copyright (C) The Internet Society (2006). This document is subject 2522 to the rights, licenses and restrictions contained in BCP 78, and 2523 except as set forth therein, the authors retain all their rights. 2525 Acknowledgment 2527 Funding for the RFC Editor function is currently provided by the 2528 Internet Society. 2530 Open Issues 2532 Open issues relating to this specification are tracked on the 2533 following web site: 2535 http://www.drizzle.com/~aboba/EAP/eapissues.html