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