idnits 2.17.1 draft-ietf-eap-keying-17.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, updated by RFC 4748 on line 2972. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2949. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2956. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2962. 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 IETF Trust 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 2283, but not defined == Missing Reference: 'IEEE802.11i' is mentioned on line 2602, but not defined == Unused Reference: 'I-D.arkko-eap-service-identity-auth' is defined on line 2640, but no explicit reference was found in the text == Unused Reference: 'I-D.friedman-ike-short-term-certs' is defined on line 2646, but no explicit reference was found in the text == Unused Reference: 'I-D.ohba-eap-channel-binding' is defined on line 2656, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-housley-aaa-key-mgmt-06 == Outdated reference: A later version (-04) exists of draft-arkko-eap-service-identity-auth-02 == Outdated reference: A later version (-02) exists of draft-friedman-ike-short-term-certs-01 == Outdated reference: A later version (-02) exists of draft-ohba-eap-channel-binding-00 == Outdated reference: A later version (-13) exists of draft-simon-emu-rfc2716bis-07 -- 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 2845 (Obsoleted by RFC 8945) -- Obsolete informational reference (is this intentional?): RFC 3547 (Obsoleted by RFC 6407) -- Obsolete informational reference (is this intentional?): RFC 3576 (Obsoleted by RFC 5176) -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 4005 (Obsoleted by RFC 7155) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) Summary: 2 errors (**), 0 flaws (~~), 12 warnings (==), 15 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 19 January 2007 Nokia 7 H. Levkowetz 8 Ericsson Research 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 July 18, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). All rights reserved. 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 ............................... 9 54 1.5 Security Goals .................................. 13 55 1.6 EAP Invariants .................................. 14 56 2. Lower Layer Operation ................................. 17 57 2.1 Transient Session Keys .......................... 18 58 2.2 Authenticator and Peer Architecture ............. 19 59 2.3 Server Identification ........................... 24 60 3. Security Association Management ....................... 26 61 3.1 Secure Association Protocol ..................... 26 62 3.2 Key Scope ....................................... 29 63 3.3 Parent-Child Relationships ...................... 30 64 3.4 Local Key Lifetimes ............................. 31 65 3.5 Exported and Calculated Key Lifetimes ........... 31 66 3.6 Key Cache Synchronization ....................... 33 67 3.7 Key Strength .................................... 34 68 3.8 Key Wrap ........................................ 34 69 4. Handoff Vulnerabilities ............................... 35 70 4.1 EAP Pre-authentication .......................... 36 71 4.2 Proactive Key Distribution ...................... 37 72 4.3 AAA Bypass ...................................... 39 73 5. Security Considerations .............................. 43 74 5.1 Authenticator Compromise ........................ 44 75 5.2 Spoofing ........................................ 45 76 5.3 Downgrade Attacks ............................... 45 77 5.4 Unauthorized Disclosure ......................... 46 78 5.5 Replay Protection ............................... 48 79 5.6 Key Freshness ................................... 48 80 5.7 Elevation of Privilege .......................... 49 81 5.8 Man-in-the-Middle Attacks ....................... 50 82 5.9 Denial of Service Attacks ....................... 51 83 5.10 Impersonation ................................... 51 84 5.11 Channel Binding ................................. 52 85 6. IANA Considerations ................................... 54 86 7. References ............................................ 54 87 7.1 Normative References ............................ 54 88 7.2 Informative References .......................... 54 89 Acknowledgments .............................................. 60 90 Author's Addresses ........................................... 60 91 Appendix A - Exported Parameters in Existing Methods ......... 61 92 Intellectual Property Statement .............................. 63 93 Disclaimer of Validity ....................................... 63 94 Copyright Statement .......................................... 63 96 1. Introduction 98 The Extensible Authentication Protocol (EAP), defined in [RFC3748], 99 was designed to enable extensible authentication for network access 100 in situations in which the Internet Protocol (IP) protocol is not 101 available. Originally developed for use with Point-to-Point Protocol 102 (PPP) [RFC1661], it has subsequently also been applied to IEEE 802 103 wired networks [IEEE-802.1X], IKEv2 [RFC4306] and wireless networks 104 such as [IEEE-802.11i] and [IEEE-802.16e]. 106 EAP is a two-party protocol spoken between the EAP peer and server. 107 Within EAP, keying material is generated by EAP authentication 108 algorithms, known as "methods". Part of this keying material may be 109 used by EAP methods themselves and part of this material may be 110 exported. In addition to export of keying material, EAP methods may 111 also export associated parameters such as authenticated peer and 112 server identities and a unique EAP conversation identifier, and may 113 import and export lower layer parameters known as "Channel Bindings". 115 This document provides a framework for the transport and usage of 116 keying material and parameters generated by EAP methods, as well as 117 specifying the EAP key hierarchy. It also provides a system-level 118 security analysis. 120 1.1. Requirements Language 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in [RFC2119]. 126 1.2. Terminology 128 The terms "Cryptographic binding", "Cryptographic separation", "Key 129 strength" and "Mutual authentication" are defined in [RFC3748] and 130 are used with the same meaning in this document, which also 131 frequently uses the following terms: 133 4-Way Handshake 134 A pairwise Authentication and Key Management Protocol (AKMP) 135 defined in [IEE-802.11i], which confirms mutual possession of a 136 Pairwise Master Key by two parties and distributes a Group Key. 138 AAA Authentication, Authorization and Accounting. AAA protocols with 139 EAP support include RADIUS [RFC3579] and Diameter [RFC4072]. In 140 this document, the terms "AAA server" and "backend authentication 141 server" are used interchangeably. 143 AAA-Key 144 The term AAA-Key is synonymous with MSK. Since multiple keys may 145 be transported by AAA, the term is potentially confusing and is not 146 used in this document. 148 authenticator 149 The end of the link initiating EAP authentication. The term 150 Authenticator is used in [IEEE-802.1X], and authenticator has the 151 same meaning in this document. 153 backend authentication server 154 A backend authentication server is an entity that provides an 155 authentication service to an authenticator. When used, this server 156 typically executes EAP methods for the authenticator. This 157 terminology is also used in [IEEE-802.1X]. 159 Channel Binding 160 A secure mechanism for ensuring that a subset of the parameters 161 transmitted by the authenticator (such as authenticator identifiers 162 and properties) are agreed upon by the EAP peer and server. It is 163 expected that the parameters are also securely agreed upon by the 164 EAP peer and authenticator via the lower layer if the authenticator 165 advertised the parameters. 167 EAP pre-authentication 168 The use of EAP to pre-establish EAP keying material on an 169 authenticator prior to arrival of the peer at the access network 170 managed by that authenticator. 172 EAP re-authentication 173 EAP authentication between an EAP peer and a server with whom the 174 EAP peer shares valid unexpired keying material. 176 EAP server 177 The entity that terminates the EAP authentication method with the 178 peer. In the case where no backend authentication server is used, 179 the EAP server is part of the authenticator. In the case where the 180 authenticator operates in pass-through mode, the EAP server is 181 located on the backend authentication server. 183 Extended Master Session Key (EMSK) 184 Additional keying material derived between the peer and server that 185 is exported by the EAP method. The EMSK is at least 64 octets in 186 length, and is never shared with a third party. The EMSK MUST be 187 at least as long as the MSK in size. 189 Initialization Vector (IV) 190 A quantity of at least 64 octets, suitable for use in an 191 initialization vector field, that is derived between the peer and 192 EAP server. Since the IV is a known value in methods such as EAP- 193 TLS [I-D.simon-emu-rfc2716bis], it cannot be used by itself for 194 computation of any quantity that needs to remain secret. As a 195 result, its use has been deprecated and EAP methods are not 196 required to generate it. However, when it is generated it MUST be 197 unpredictable. 199 Key Scope 200 The parties to whom a key is available. 202 Key Wrap 203 The encryption of one symmetric cryptographic key in another. The 204 algorithm used for the encryption is called a key wrap algorithm or 205 a key encryption algorithm. The key used in the encryption process 206 is called a key-encryption key (KEK). 208 Long Term Credential 209 EAP methods frequently make use of long term secrets in order to 210 enable authentication between the peer and server. In the case of 211 a method based on pre-shared key authentication, the long term 212 credential is the pre-shared key. In the case of a public-key 213 based method, the long term credential is the corresponding private 214 key. 216 Lower Layer 217 The lower layer is responsible for carrying EAP frames between the 218 peer and authenticator. 220 Lower Layer Identity 221 A name used to identify the EAP peer and authenticator within the 222 lower layer. 224 Master Session Key (MSK) 225 Keying material that is derived between the EAP peer and server and 226 exported by the EAP method. The MSK is at least 64 octets in 227 length. 229 Network Access Server (NAS) 230 A device that provides an access service for a user to a network. 232 Pairwise Master Key (PMK) 233 Lower layers use the MSK in lower-layer dependent manner. For 234 instance, in [IEEE-802.11i] Octets 0-31 of the MSK are known as the 235 Pairwise Master Key (PMK). In [IEEE-802.11i] the TKIP and AES CCMP 236 ciphersuites derive their Transient Session Keys (TSKs) solely from 237 the PMK, whereas the WEP ciphersuite as noted in [RFC3580], derives 238 its TSKs from both halves of the MSK. In [802.16e], the MSK is 239 truncated to 20 octets for PMK and 20 octets for PMK2. 241 peer The end of the link that responds to the authenticator. 243 security association 244 A set of policies and cryptographic state used to protect 245 information. Elements of a security association may include 246 cryptographic keys, negotiated ciphersuites and other parameters, 247 counters, sequence spaces, authorization attributes, etc. 249 Secure Association Protocol 250 An exchange that occurs between the EAP peer and authenticator in 251 order to manage security associations derived from EAP exchanges. 252 The protocol establishes unicast and (optionally) multicast 253 security associations, which include symmetric keys and a context 254 for the use of the keys. An example of a Secure Association 255 Protocol is the 4-way handshake defined within [IEEE-802.11i]. 257 Session-Id 258 The EAP Session-Id uniquely identifies an EAP authentication 259 exchange between an EAP peer (as identified by the Peer-Id) and 260 server (as identified by the Server-Id). For more information, see 261 Section 1.4. 263 Transient EAP Keys (TEKs) 264 Session keys which are used to establish a protected channel 265 between the EAP peer and server during the EAP authentication 266 exchange. The TEKs are appropriate for use with the ciphersuite 267 negotiated between EAP peer and server for use in protecting the 268 EAP conversation. The TEKs are stored locally by the EAP method 269 and are not exported. Note that the ciphersuite used to set up the 270 protected channel between the EAP peer and server during EAP 271 authentication is unrelated to the ciphersuite used to subsequently 272 protect data sent between the EAP peer and authenticator. 274 Transient Session Keys (TSKs) 275 Keys used to protect data exchanged after EAP authentication has 276 successfully completed, using the ciphersuite negotiated between 277 the EAP peer and authenticator. 279 1.3. Overview 281 Where EAP key derivation is supported, the conversation typically 282 takes place in three phases: 284 Phase 0: Discovery 285 Phase 1: Authentication 286 1a: EAP authentication 287 1b: AAA Key Transport (optional) 288 Phase 2: Secure Association Protocol 289 2a: Unicast Secure Association 290 2b: Multicast Secure Association (optional) 292 Of these phases, Phase 0, 1b and Phase 2 are handled external to EAP. 293 Phases 0 and 2 are handled by the lower layer protocol and phase 1b 294 is typically handled by a AAA protocol. 296 In the discovery phase (phase 0), peers locate authenticators and 297 discover their capabilities. A peer may locate an authenticator 298 providing access to a particular network, or a peer may locate an 299 authenticator behind a bridge with which it desires to establish a 300 Secure Association. Discovery can occur manually or automatically, 301 depending on the lower layer over which EAP runs. 303 The authentication phase (phase 1) may begin once the peer and 304 authenticator discover each other. This phase, if it occurs, always 305 includes EAP authentication (phase 1a). Where the chosen EAP method 306 supports key derivation, in phase 1a EAP keying material is derived 307 on both the peer and the EAP server. 309 An additional step (phase 1b) is required in deployments which 310 include a backend authentication server, in order to transport keying 311 material from the backend authentication server to the authenticator. 312 In order to obey the principle of mode independence (see Section 313 1.6.1), where a backend server is present, all keying material which 314 is required by the lower layer needs to be transported from the EAP 315 server to the authenticator. Since existing TSK derivation and 316 transport techniques depend solely on the MSK, in existing 317 implementations, this is the only keying material replicated in the 318 AAA key transport phase 1b. 320 Successful completion of EAP authentication and key derivation by a 321 peer and EAP server does not necessarily imply that the peer is 322 committed to joining the network associated with an EAP server. 323 Rather, this commitment is implied by the creation of a security 324 association between the EAP peer and authenticator, as part of the 325 Secure Association Protocol (phase 2). The Secure Association 326 Protocol exchange (phase 2) occurs between the peer and authenticator 327 in order to manage the creation and deletion of unicast (phase 2a) 328 and multicast (phase 2b) security associations between the peer and 329 authenticator. The conversation between the parties is shown in 330 Figure 1. 332 EAP peer Authenticator Auth. Server 333 -------- ------------- ------------ 334 |<----------------------------->| | 335 | Discovery (phase 0) | | 336 |<----------------------------->|<----------------------------->| 337 | EAP auth (phase 1a) | AAA pass-through (optional) | 338 | | | 339 | |<----------------------------->| 340 | | AAA Key transport | 341 | | (optional; phase 1b) | 342 |<----------------------------->| | 343 | Unicast Secure association | | 344 | (phase 2a) | | 345 | | | 346 |<----------------------------->| | 347 | Multicast Secure association | | 348 | (optional; phase 2b) | | 349 | | | 351 Figure 1: Conversation Overview 353 1.3.1. Examples 355 Existing EAP lower layers implement phase 0, 2a and 2b in different 356 ways: 358 PPP Point-to-Point Protocol (PPP), defined in [RFC1661] does not 359 support discovery, nor does it include a Secure Association 360 Protocol. 362 PPPoE 363 PPP over Ethernet (PPPoE), defined in [RFC2516], includes support 364 for a Discovery stage (phase 0). In this step, the EAP peer sends 365 a PPPoE Active Discovery Initiation (PADI) packet to the broadcast 366 address, indicating the service it is requesting. The Access 367 Concentrator replies with a PPPoE Active Discovery Offer (PADO) 368 packet containing its name, the service name and an indication of 369 the services offered by the concentrator. The discovery phase is 370 not secured. PPPoE, like PPP, does not include a Secure 371 Association Protocol. 373 IKEv2 374 IKEv2, defined in [RFC4306], includes support for EAP and handles 375 the establishment of unicast security associations (phase 2a). 376 However, the establishment of multicast security associations 377 (phase 2b) typically does not involve EAP and needs to be handled 378 by a group key management protocol such as GDOI [RFC3547], GSAKMP 379 [GSAKMP], MIKEY [RFC3830], or GKDP [GKDP]. Several mechanisms have 380 been proposed for discovery of IPsec security gateways. [RFC2230] 381 discusses the use of KX Resource Records (RRs) for IPsec gateway 382 discovery; while KX RRs are supported by many DNS server 383 implementations, they have not yet been widely deployed. 384 Alternatively, DNS SRV [RFC2782] can be used for this purpose. 385 Where DNS is used for gateway location, DNS security mechanisms 386 such as DNSSEC ([RFC2535], [RFC2931]), TSIG [RFC2845], and Simple 387 Secure Dynamic Update [RFC3007] are available. 389 IEEE 802.11i 390 IEEE 802.11, defined in [IEEE-802.11], handles discovery via the 391 Beacon and Probe Request/Response mechanisms. IEEE 802.11 access 392 points periodically announce their Service Set Identifiers (SSIDs) 393 as well as capabilities using Beacon frames. Stations can query 394 for access points by sending a Probe Request to the broadcast 395 address. Neither Beacon nor Probe Request/Response frames are 396 secured. The 4-way handshake defined in [IEEE-802.11i] enables the 397 derivation of unicast (phase 2a) and multicast/broadcast (phase 2b) 398 secure associations. Since the group key exchange transports a 399 group key from the access point to the station, two 4-way 400 handshakes may be required in order to support peer-to-peer 401 communications. A proof of the security of the IEEE 802.11i 4-way 402 handshake when used with EAP-TLS is provided in [He]. 404 IEEE 802.1X 405 IEEE 802.1X-2004, defined in [IEEE-802.1X] does not support 406 discovery (phase 0), nor does it provide for derivation of unicast 407 or multicast secure associations. 409 1.4. EAP Key Hierarchy 411 As illustrated in Figure 2, the EAP method key derivation has at the 412 root the long term credential utilized by the selected EAP method. 413 If authentication is based on a pre-shared key, the parties store the 414 EAP method to be used and the pre-shared key. The EAP server also 415 stores the peer's identity as well as additional information. This 416 information is typically used outside of the EAP method to determine 417 if access to some service should be granted. The peer stores 418 information necessary to choose which secret to use for which 419 service. 421 If authentication is based on proof of possession of the private key 422 corresponding to the public key contained within a certificate, the 423 parties store the EAP method to be used and the trust anchors used to 424 validate the certificates. The EAP server may also store additional 425 information associated with the peer's identity and the peer stores 426 information necessary to choose which certificate to use for which 427 service. 429 If authentication is based on proof of possession of the private key 430 corresponding to the public key contained within a certificate, the 431 parties store the EAP method to be used and the trust anchors used to 432 validate the certificates. The EAP server also stores the peer's 433 identity and the peer stores information necessary to choose which 434 certificate to use for which service. Based on the long term 435 credential established between the peer and the server, EAP methods 436 derive two types of keys: 438 [a] Keys calculated locally by the EAP method but not exported 439 by the EAP method, such as the TEKs. 440 [b] Keying material exported by the EAP method: MSK, EMSK, IV. 442 As noted in [RFC3748] Section 7.10, EAP methods generating keys are 443 required to calculate and export the MSK and EMSK, which must be at 444 least 64 octets in length. EAP methods also may export the IV; 445 however, the use of the IV is deprecated. 447 The EMSK MUST NOT be provided to an entity outside the EAP server or 448 peer, nor is it permitted to pass any quantity to an entity outside 449 the EAP server or peer from which the EMSK could be computed without 450 breaking some cryptographic assumption, such as inverting a one-way 451 function. 453 EAP methods also MAY export method-specific peer and server 454 identifiers (Peer-Id and Server-Id) and a method-specific EAP 455 conversation identifier known as the Session-Id. EAP methods MAY 456 also support the import and export of Channel Bindings. New EAP 457 method specifications MUST define the Peer-Id, Server-Id and Session- 458 Id. The combination of the Peer-Id and Server-Id uniquely specifies 459 the endpoints of the EAP method exchange when they are provided. The 460 Peer-Id, Server-Id, and Session-Id for existing EAP methods is 461 defined in Appendix A. 463 Peer-Id 465 As described in [RFC3748] Section 7.3, the identity provided in 466 the EAP-Response/Identity, may be different from the peer identity 467 authenticated by the EAP method. Where the EAP method 468 authenticates the peer identity, that identity is exported by the 469 method as the Peer-Id. A suitable EAP peer name may not always be 470 available. Where an EAP method does not define a method-specific 471 peer identity, the Peer-Id is the null string. 473 Server-Id 475 Where the EAP method authenticates the server identity, that 476 identity is exported by the method as the Server-Id. A suitable 477 EAP server name may not always be available. Where an EAP method 478 does not define a method-specific server identity, the Server-Id 479 is the null string. 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 482 | | ^ 483 | EAP Method | | 484 | | | 485 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | | 486 | | | | | | | 487 | | EAP Method Key |<->| Long-Term | | | 488 | | Derivation | | Credential | | | 489 | | | | | | | 490 | | | +-+-+-+-+-+-+-+ | Local to | 491 | | | | EAP | 492 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Method | 493 | | | | | | 494 | | | | | | 495 | | | | | | 496 | | | | | | 497 | | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | | 498 | | | TEK | |MSK, EMSK | |IV | | | 499 | | |Derivation | |Derivation | |Derivation | | | 500 | | | | | | |(Deprecated) | | | 501 | | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | | 502 | | ^ | | | | 503 | | | | | | V 504 +-+-|-+-+-+-+-+-+-+-+-|-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+ ---+ 505 | | | | ^ 506 | Peer-Id, | | | Exported | 507 | Server-Id, | Channel | MSK (64+B) | IV (64B) by | 508 | Session-Id | Bindings | EMSK (64+B) | (Optional) EAP | 509 | | & Result | | Method | 510 V V V V V 512 Figure 2: EAP Method Parameter Import/Export 514 Session-Id 516 The Session-Id uniquely identifies an EAP session between an EAP 517 peer (as identified by the Peer-Id) and server (as identified by 518 the Server-Id). Where the EAP Type Code is less than 255, the EAP 519 Session-Id consists of the concatenation of the EAP Type Code and 520 a temporally unique identifier obtained from the method (known as 521 the Method-Id). Where expanded EAP Type Codes are used, the EAP 522 Session-Id consists of the Expanded Type Code (including the Type, 523 Vendor-Id and Vendor-Type fields defined in [RFC3748] Section 5.7) 524 concatenated with a temporally unique identifier obtained from the 525 method (Method-Id). This unique identifier is typically 526 constructed from nonces or counters used within the EAP method 527 exchange. The inclusion of the Type Code in the EAP Session-Id 528 ensures that each EAP method has a distinct Session-Id space. 529 Since an EAP session is not bound to a particular authenticator or 530 specific ports on the peer and authenticator, the authenticator 531 port or identity are not included in the Session-Id. 533 Channel Bindings 535 Channel Bindings include lower layer parameters that are verified 536 for consistency between the EAP peer and server. In order to 537 avoid introducing media dependencies, EAP methods that transport 538 Channel Binding data MUST treat this data as opaque octets. See 539 Section 5.11 for further discussion. 541 1.4.1. Key Naming 543 Each key created within the EAP key management framework has a name 544 (a unique identifier), as well as a scope (the parties to whom the 545 key is available). The scope of exported parameters is defined by 546 the EAP Peer-Id (if securely exchanged within the method) and the EAP 547 Server-Id (also only if securely exchanged). Where a peer or server 548 name is missing the null string is used. 550 MSK and EMSK Names 551 These parameters are exported by the EAP peer and EAP server, and 552 can be referred to using the EAP Session-Id and a binary or textual 553 indication of the parameter being referred to. 555 PMK Name 556 This document does not specify a naming scheme for the PMK. The 557 PMK is only identified by the name of the key from which it is 558 derived. 560 Note: IEEE 802.11i names the PMKID for the purposes of being able 561 to refer to it in the Secure Association protocol; this naming is 562 based on a hash of the PMK itself as well as some other parameters 563 (see Section 8.5.1.2 [IEEE-802.11i]). 565 TEK Name 566 The TEKs may or may not be named. Their naming is specified in the 567 EAP method. 569 TSK Name 570 The TSKs are typically named. Their naming is specified in the 571 lower layer so that the correct set of transient session keys can 572 be identified for processing a given packet. 574 1.5. Security Goals 576 The goal of the EAP conversation is to derive fresh session keys 577 between the EAP peer and authenticator that are known only to those 578 parties, and for both the EAP peer and authenticator to demonstrate 579 that they are authorized to perform their roles either by each other 580 or by a trusted third party (the backend authentication server). 582 Completion of an EAP method exchange (Phase 1a) supporting key 583 derivation results in the derivation of EAP keying material (MSK, 584 EMSK, TEKs) known only to the EAP peer (identified by the Peer-Id) 585 and server (identified by the Server-Id). Both the EAP peer and EAP 586 server know the exported keying material to be fresh. Key freshness 587 is discussed in Sections 3.4, 3.5 and 5.6. 589 Completion of the AAA exchange (Phase 1b) results in the transport of 590 EAP keying material from the EAP server (identified by the Server-Id) 591 to the EAP authenticator (identified by the NAS-Identifier) without 592 disclosure to any other party. Both the EAP server and EAP 593 authenticator know this keying material to be fresh. Disclosure 594 issues are discussed in Section 5.4; security properties of AAA 595 protocols are discussed in Sections 5.1-5.7, and 5.10. 597 The backend authentication server is trusted to only transport EAP 598 keying material to the authenticator that was established with the 599 peer, and it is trusted to transport that EAP keying material to no 600 other parties. In many systems, EAP keying material established by 601 the EAP peer and EAP server are combined with publicly available data 602 to derive other keys. The backend authentication server is trusted 603 to refrain from deriving these same keys or acting as a man-in-the- 604 middle even though it has access to the EAP keying material that is 605 needed to do so. The authenticator is also a trusted party. It is 606 trusted not to provide EAP keying material it obtains from the 607 backend authentication server to any other parties. 609 Completion of the Secure Association Protocol (Phase 2) results in 610 the derivation or transport of Transient Session Keys (TSKs) known 611 only to the EAP peer (identified by the Peer-Id) and authenticator 612 (identified by the NAS-Identifier). Both the EAP peer and 613 authenticator know the TSKs to be fresh. Both the EAP peer and 614 authenticator demonstrate that they are authorized to perform their 615 roles. Authorization issues are discussed in Section 5.7 and 5.8; 616 security properties of Secure Association Protocols are discussed in 617 Section 3.1. 619 1.6. EAP Invariants 621 Certain basic characteristics, known as "EAP Invariants", hold true 622 for EAP implementations on all media: 624 Mode independence 625 Media independence 626 Method independence 627 Ciphersuite independence 629 1.6.1. Mode Independence 631 EAP is typically deployed to support extensible network access 632 authentication in situations where a peer desires network access via 633 one or more authenticators. Where authenticators are deployed 634 standalone, the EAP conversation occurs between the peer and 635 authenticator, and the authenticator must locally implement an EAP 636 method acceptable to the peer. However, when utilized in "pass- 637 through" mode, EAP enables deployment of new authentication methods 638 without requiring development of new code on the authenticator. 640 While the authenticator may implement some EAP methods locally and 641 use those methods to authenticate local users, it may at the same 642 time act as a pass-through for other users and methods, forwarding 643 EAP packets back and forth between the backend authentication server 644 and the peer. This is accomplished by encapsulating EAP packets 645 within the Authentication, Authorization and Accounting (AAA) 646 protocol, spoken between the authenticator and backend authentication 647 server. AAA protocols supporting EAP include RADIUS [RFC3579] and 648 Diameter [RFC4072]. 650 It is a fundamental property of EAP that at the EAP method layer, the 651 conversation between the EAP peer and server is unaffected by whether 652 the EAP authenticator is operating in "pass-through" mode. EAP 653 methods operate identically in all aspects, including key derivation 654 and parameter import/export, regardless of whether the authenticator 655 is operating as a pass-through or not. 657 The successful completion of an EAP method that supports key 658 derivation results in the export of keying material and parameters on 659 the EAP peer and server. Even though the EAP peer or server may 660 import Channel Bindings that may include the identity of the EAP 661 authenticator, this information is treated as opaque octets. As a 662 result, within EAP the only relevant identities are the Peer-Id and 663 Server-Id. Channel Bindings are only interpreted by the lower layer. 665 Within EAP, the primary function of the AAA protocol is to maintain 666 the principle of mode independence, so that as far as the EAP peer is 667 concerned, its conversation with the EAP authenticator, and all 668 consequences of that conversation, are identical, regardless of the 669 authenticator mode of operation. 671 1.6.2. Media Independence 673 One of the goals of EAP is to allow EAP methods to function on any 674 lower layer meeting the criteria outlined in [RFC3748], Section 3.1. 675 For example, as described in [RFC3748], EAP authentication can be run 676 over PPP [RFC1661], IEEE 802 wired networks [IEEE-802.1X], and 677 wireless networks such as 802.11 [IEEE-802.11i] and 802.16 678 [IEEE-802.16e]. 680 In order to maintain media independence, it is necessary for EAP to 681 avoid consideration of media-specific elements. For example, EAP 682 methods cannot be assumed to have knowledge of the lower layer over 683 which they are transported, and cannot be restricted to identifiers 684 associated with a particular usage environment (e.g. MAC addresses). 686 Note that media independence may be retained within EAP methods that 687 support Channel Bindings or method-specific identification. An EAP 688 method need not be aware of the content of an identifier in order to 689 use it. This enables an EAP method to use media-specific identifiers 690 such as MAC addresses without compromising media independence. 691 Channel Bindings are treated as opaque octets by EAP methods, so that 692 handling them does not require media-specific knowledge. 694 1.6.3. Method Independence 696 By enabling pass-through, authenticators can support any method 697 implemented on the peer and server, not just locally implemented 698 methods. This allows the authenticator to avoid implementing code 699 for each EAP method required by peers. In fact, since a pass-through 700 authenticator is not required to implement any EAP methods at all, it 701 cannot be assumed to support any EAP method-specific code. 703 As a result, as noted in [RFC3748], authenticators must by default be 704 capable of supporting any EAP method. This is useful where there is 705 no single EAP method that is both mandatory-to-implement and offers 706 acceptable security for the media in use. For example, the [RFC3748] 707 mandatory-to-implement EAP method (MD5-Challenge) does not provide 708 dictionary attack resistance, mutual authentication or key 709 derivation, and as a result is not appropriate for use in wireless 710 LAN authentication [RFC4017]. However, despite this it is possible 711 for the peer and authenticator to interoperate as long as a suitable 712 EAP method is supported on the EAP server. 714 1.6.4. Ciphersuite Independence 716 Ciphersuite Independence is a requirement for Media Independence. 717 Since lower layer ciphersuites vary between media, media independence 718 requires that EAP keying material needs to be large enough (with 719 sufficient entropy) to handle any ciphersuite. 721 While EAP methods may negotiate the ciphersuite used in protection of 722 the EAP conversation, the ciphersuite used for the protection of the 723 data exchanged after EAP authentication has completed is negotiated 724 between the peer and authenticator within the lower layer, outside of 725 EAP. 727 For example, within PPP, the ciphersuite is negotiated within the 728 Encryption Control Protocol (ECP) defined in [RFC1968], after EAP 729 authentication is completed. Within [IEEE-802.11i], the AP 730 ciphersuites are advertised in the Beacon and Probe Responses prior 731 to EAP authentication, and are securely verified during a 4-way 732 handshake exchange. 734 Since the ciphersuites used to protect data depend on the lower 735 layer, requiring EAP methods have knowledge of lower layer 736 ciphersuites would compromise the principle of Media Independence. 737 Since ciphersuite negotiation occurs in the lower layer, there is no 738 need for lower layer ciphersuite negotiation within EAP, and EAP 739 methods generate keying material that is ciphersuite-independent. 741 In order to allow a ciphersuite to be usable within the EAP keying 742 framework, a specification MUST be provided describing how TSKs 743 suitable for use with the ciphersuite are derived from exported EAP 744 keying parameters. To maintain Method Independence, algorithms for 745 deriving TSKs MUST NOT depend on the EAP method, although algorithms 746 for TEK derivation MAY be specific to the EAP method. 748 Advantages of ciphersuite-independence include: 750 Reduced update requirements 751 If EAP methods were to specify how to derive transient session keys 752 for each ciphersuite, they would need to be updated each time a new 753 ciphersuite is developed. In addition, backend authentication 754 servers might not be usable with all EAP-capable authenticators, 755 since the backend authentication server would also need to be 756 updated each time support for a new ciphersuite is added to the 757 authenticator. 759 Reduced EAP method complexity 760 Requiring each EAP method to include ciphersuite-specific code for 761 transient session key derivation would increase method complexity 762 and result in duplicated effort. 764 Simplified configuration 765 The ciphersuite is negotiated between the peer and authenticator 766 outside of EAP. Where the authenticator operates in "pass-through" 767 mode, the EAP server is not a party to this negotiation, nor is it 768 involved in the data flow between the EAP peer and authenticator. 769 As a result, the EAP server may not have knowledge of the 770 ciphersuites and negotiation policies implemented by the peer and 771 authenticator, or be aware of the ciphersuite negotiated between 772 them. For example, since ECP negotiation occurs after 773 authentication, when run over PPP, the EAP peer and server may not 774 anticipate the negotiated ciphersuite and therefore this 775 information cannot be provided to the EAP method. 777 2. Lower Layer Operation 779 On completion of EAP authentication, keying material and material and 780 parameters exported by the EAP method are provided to the lower layer 781 and AAA layer (if present). These include the Master Session Key 782 (MSK), Extended Master Session Key (EMSK), Peer-Id, Server-Id and 783 Session-Id. The Initialization Vector (IV) is deprecated. 785 In order to preserve the security of keys derived within EAP methods, 786 lower layers MUST NOT export keys passed down by EAP methods. This 787 implies that EAP keying material passed down to a lower layer is for 788 the exclusive use of that lower layer and MUST NOT be used within 789 another lower layer. This prevents compromise of one lower layer 790 from compromising other applications using EAP keying parameters. 792 EAP keying material provided to a lower layer MUST NOT be transported 793 to another entity. For example, EAP keying material passed down to 794 the EAP peer lower layer MUST NOT leave the peer; EAP keying 795 material passed down or transported to the EAP authenticator lower 796 layer MUST NOT leave the authenticator. 798 On the EAP server, keying material and parameters requested by and 799 passed down to the AAA layer may be replicated to the AAA layer on 800 the authenticator (with the exception of the EMSK). On the 801 authenticator, the AAA layer provides the replicated keying material 802 and parameters to the lower layer over which the EAP authentication 803 conversation took place. This enables mode independence to be 804 maintained. 806 The EAP layer as well as the peer and authenticator layers MUST NOT 807 modify or cache keying material or parameters (including Channel 808 Bindings) passing in either direction between the EAP method layer 809 and the lower layer or AAA layer. 811 2.1. Transient Session Keys 813 Where explicitly supported by the lower layer, lower layers MAY cache 814 the exported EAP keying material and parameters and/or TSKs. The 815 structure of this key cache is defined by the lower layer. So as to 816 enable interoperability, new lower layer specifications MUST describe 817 EAP key caching behavior. Unless explicitly specified by the lower 818 layer, the EAP peer, server and authenticator MUST assume that peers 819 and authenticators do not cache exported EAP keying parameters or 820 TSKs. Existing EAP lower layers and AAA layers handle the caching of 821 EAP keying material and the generation of transient session keys in 822 different ways: 824 IEEE 802.1X-2004 825 IEEE 802.1X-2004, defined in [IEEE-802.1X] does not support caching 826 of EAP keying material or parameters. Once EAP authentication 827 completes, it is assumed that EAP keying material and parameters 828 are discarded. 830 PPP PPP, defined in [RFC1661] does not support caching of EAP keying 831 material or parameters. PPP ciphersuites derive their TSKs 832 directly from the MSK, as described in [I-D.simon-emu-rfc2716bis]. 833 This method is NOT RECOMMENDED, since if PPP were to support 834 caching, this could result in TSK reuse. As a result, once the PPP 835 session is terminated, EAP keying material and parameters MUST be 836 discarded. Since caching of EAP keying material is not permitted, 837 within PPP there is no way to handle TSK re-key without EAP re- 838 authentication. Perfect Forward Secrecy (PFS) is only possible if 839 the negotiated EAP method supports this. 841 IKEv2 842 IKEv2, defined in [RFC4306] only uses the MSK for authentication 843 purposes and not key derivation. The EMSK, IV, Peer-Id, Server-Id 844 or Session-Id are not used. As a result, the keying material 845 derived within IKEv2 is independent of the EAP keying material and 846 re-key of IPsec SAs can be handled without requiring EAP re- 847 authentication. Since generation of keying material is independent 848 of EAP, within IKEv2 it is possible to negotiate PFS, regardless of 849 the EAP method that is used. IKEv2 as specified in [RFC4306] does 850 not cache EAP keying material or parameters; once IKEv2 851 authentication completes it is assumed that EAP keying material and 852 parameters are discarded. The Session-Timeout attribute is 853 therefore interpreted as a limit on the VPN session time, rather 854 than an indication of the MSK key lifetime. 856 IEEE 802.11i 857 IEEE 802.11i enables caching of the MSK, but not the EMSK, IV, 858 Peer-Id, Server-Id, or Session-Id. More details about the 859 structure of the cache are available in [IEEE-802.11i]. In IEEE 860 802.11i, TSKs are derived from the MSK using the 4-way handshake, 861 which includes a nonce exchange. This guarantees TSK freshness 862 even if the MSK is reused. The 4-way handshake also enables TSK 863 re-key without EAP re-authentication. PFS is only possible within 864 IEEE 802.11i if caching is not enabled and the negotiated EAP 865 method supports PFS. 867 IEEE 802.16e 868 IEEE 802.16e, defined in [IEEE-802.16e] supports caching of the 869 MSK, but not the EMSK, IV, Peer-Id, Server-Id or Session-Id. In 870 IEEE 802.16e, TSKs are generated by the authenticator without any 871 contribution by the peer. The TSKs are encrypted, authenticated 872 and integrity protected using the MSK. As a result, TSK re-key is 873 possible without EAP re-authentication. PFS is not possible even 874 if the negotiated EAP method supports it. 876 AAA Existing implementations of RADIUS/EAP [RFC3579] or Diameter EAP 877 [RFC4072] do not support caching of EAP keying material or 878 parameters. In existing AAA client, proxy and server 879 implementations, exported EAP keying material (MSK, EMSK and IV) as 880 well as parameters and derived keys are not cached and MUST be 881 presumed lost after the AAA exchange completes. 883 In order to avoid key reuse, the AAA layer MUST delete transported 884 keys once they are sent. The AAA layer MUST NOT retain keys that 885 it has previously sent. For example, a AAA layer that has 886 transported the MSK MUST delete it, and keys MUST NOT be derived 887 from the MSK from that point forward. 889 2.2. Authenticator and Peer Architecture 891 This specification does not impose constraints on the architecture of 892 the EAP authenticator or peer. Any of the authenticator 893 architectures described in [RFC4118] can be used. As a result, lower 894 layers need to identify EAP peers and authenticators unambiguously, 895 without incorporating implicit assumptions about peer and 896 authenticator architectures. 898 For example, it is possible for multiple base stations and a 899 "controller" (e.g. WLAN switch) to comprise a single EAP 900 authenticator. In such a situation, the "base station identity" is 901 irrelevant to the EAP method conversation, except perhaps as an 902 opaque blob to be used in Channel Bindings. Many base stations can 903 share the same authenticator identity. It should be understood that 904 an EAP authenticator or peer: 906 [a] may contain one or more physical or logical ports; 908 [b] may advertise itself as one or more "virtual" 909 authenticators or peers; 910 [c] may utilize multiple CPUs; 911 [d] may support clustering services for load balancing or failover. 913 Both the EAP peer and authenticator may have more than one physical 914 or logical port. A peer may simultaneously access the network via 915 multiple authenticators, or via multiple physical or logical ports on 916 a given authenticator. Similarly, an authenticator may offer network 917 access to multiple peers, each via a separate physical or logical 918 port. When a single physical authenticator advertises itself as 919 multiple "virtual authenticators", it is possible for a single 920 physical port to belong to multiple "virtual authenticators". 922 An authenticator may be configured to communicate with more than one 923 EAP server, each of which is configured to communicate with a subset 924 of the authenticators. The situation is illustrated in Figure 3. 926 2.2.1. Authenticator and Peer Identification 928 The EAP method conversation is between the EAP peer and server. The 929 authenticator identity, if considered at all by the EAP method, is 930 treated as an opaque blob for the purposes of Channel Bindings (see 931 Section 5.12). However, the authenticator identity is important in 932 two other exchanges - the AAA protocol exchange and the Secure 933 Association Protocol conversation. 935 The AAA conversation is between the EAP authenticator and the backend 936 authentication server. From the point of view of the backend 937 authentication server, EAP keying material and parameters are 938 transported to the EAP authenticator identified by the NAS-Identifier 939 attribute. Since an EAP authenticator MUST NOT share EAP keying 940 material or parameters with another party, if the EAP peer or backend 941 authentication server detects use of EAP keying material and 942 parameters outside the scope defined by the NAS-Identifier, the 943 keying material MUST be considered compromised. 945 The Secure Association Protocol conversation is between the peer and 946 the authenticator. For lower layers which support key caching it is 947 particularly important for the EAP peer, authenticator and backend 948 server to have a consistent view of the usage scope of the 949 transported EAP keying material. In order to enable this, it is 950 RECOMMENDED that the Secure Association Protocol explicitly 951 communicate the usage scope of the EAP keying material passed down to 952 the lower layer, rather than implicitly assuming that this is defined 953 by the authenticator and peer endpoint addresses. 955 Since an authenticator may have multiple ports, the scope of the 956 authenticator key cache may not be described by a single endpoint 957 address. Similarly, where a peer may have multiple ports and sharing 958 of EAP keying material and parameters between peer ports of the same 959 link type is allowed, the extent of the peer key cache cannot be 960 communicated by using a single endpoint address. Instead, it is 961 RECOMMENDED that the EAP peer and authenticator consistently identify 962 themselves utilizing explicit identifiers, rather than endpoint 963 addresses or port identifiers. 965 AAA protocols such as RADIUS [RFC3579] and Diameter [RFC4072] provide 966 a mechanism for the identification of AAA clients; since the EAP 967 authenticator and AAA client are always co-resident, this mechanism 968 is applicable to the identification of EAP authenticators. 970 +-+-+-+-+ 971 | EAP | 972 | Peer | 973 +-+-+-+-+ 974 | | | Peer Ports 975 / | \ 976 / | \ 977 / | \ 978 / | \ 979 / | \ 980 / | \ 981 / | \ 982 / | \ Authenticator 983 | | | | | | | | | Ports 984 +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ 985 | | | | | | 986 | Auth1 | | Auth2 | | Auth3 | 987 | | | | | | 988 +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ 989 \ | \ | 990 \ | \ | 991 \ | \ | 992 EAP over AAA \ | \ | 993 (optional) \ | \ | 994 \ | \ | 995 \ | \ | 996 \ | \ | 997 +-+-+-+-+-+ +-+-+-+-+-+ Backend 998 | EAP | | EAP | Authentication 999 | Server1 | | Server2 | Servers 1000 +-+-+-+-+-+ +-+-+-+-+-+ 1002 Figure 3: Relationship between EAP peer, authenticator and server 1003 RADIUS [RFC2865] requires that an Access-Request packet contain one 1004 or more of the NAS-Identifier, NAS-IP-Address and NAS-IPv6-Address 1005 attributes. Since a NAS may have more than one IP address, the NAS- 1006 Identifier attribute is RECOMMENDED for explicit identification of 1007 the authenticator, both within the AAA protocol exchange and the 1008 Secure Association Protocol conversation. 1010 Problems which may arise where the peer and authenticator implicitly 1011 identify themselves using endpoint addresses include the following: 1013 [a] It may not be obvious to the peer which authenticator ports are 1014 associated with which authenticators. The EAP peer will be unable 1015 to determine whether EAP keying material has been shared outside 1016 its authorized scope, and needs to be considered compromised. The 1017 EAP peer may also be unable to utilize the authenticator key cache 1018 in an efficient way. 1020 [b] It may not be obvious to the authenticator which peer ports are 1021 associated with which peers. As a result, the authenticator may 1022 not be able to enable a peer to communicate with it utilizing 1023 multiple peer ports. 1025 [c] It may not be obvious to the peer which "virtual authenticator" it 1026 is communicating with. For example, multiple "virtual 1027 authenticators" may share a MAC address, but utilize different NAS- 1028 Identifiers. 1030 [d] It may not be obvious to the authenticator which "virtual peer" it 1031 is communicating with. Multiple "virtual peers" may share a MAC 1032 address, but utilize different Peer-Ids. 1034 [e] It may not be possible for the EAP peer and server to verify the 1035 authenticator identity via channel bindings. 1037 For example, problems [a], [c] and [e] occur in [IEEE-802.11i], which 1038 utilizes peer and authenticator MAC addresses within the 4-way 1039 handshake. Problems [b] and [d] do not occur since [IEEE-802.11i] 1040 only allows a peer to utilize a single port. 1042 The following steps enable lower layer identities to be securely 1043 verified by all parties: 1045 [f] Specifying the lower layer parameters used to identify the 1046 authenticator and peer. As noted earlier, endpoint or port 1047 identifiers are not recommended for identification of the 1048 authenticator or peer when it is possible for them to have multiple 1049 ports. 1051 [g] Communicating the lower layer identities between the peer and 1052 authenticator within phase 0. This allows the peer and 1053 authenticator to determine the key scope if a key cache is 1054 utilized. 1056 [h] Communicating the lower layer authenticator identity between the 1057 authenticator and backend server within the NAS-Identifier 1058 attribute. 1060 [i] Including the lower layer identities within Channel Bindings (if 1061 supported) in phase 1a, ensuring that they are communicated between 1062 the EAP peer and server. 1064 [j] Supporting the integrity-protected exchange of identities within 1065 phase 2a. 1067 [k] Utilizing the advertised lower layer identities to enable the peer 1068 and authenticator to verify that keys are maintained within the 1069 advertised scope. 1071 2.2.2. Virtual Authenticators 1073 When a single physical authenticator advertises itself as multiple 1074 "virtual authenticators", if the virtual authenticators do not 1075 maintain logically separate key caches, then by authenticating to one 1076 virtual authenticator, the peer can gain access to the other virtual 1077 authenticators sharing a key cache. 1079 For example, where a physical authenticator implements "Guest" and 1080 "Corporate Intranet" virtual authenticators, an attacker acting as a 1081 peer could authenticate with the "Guest" "virtual authenticator" and 1082 derive EAP keying material. If the "Guest" and "Corporate Intranet" 1083 virtual authenticators share a key cache, then the peer can utilize 1084 the EAP keying material derived for the "Guest" network to obtain 1085 access to the "Corporate Intranet" network. 1087 In order to address this vulnerability: 1089 [a] Authenticators are REQUIRED to cache associated authorizations 1090 along with EAP keying material and parameters and to apply 1091 authorizations consistently. This ensures that an attacker cannot 1092 obtain elevated privileges even where the key cache is shared 1093 between "virtual authenticators". 1095 [b] It is RECOMMENDED that physical authenticators maintain separate 1096 key caches for each "virtual authenticator". 1098 [c] It is RECOMMENDED that each "virtual authenticator" identify itself 1099 consistently to the peer and to the backend authentication server, 1100 so as to enable the peer to verify the authenticator identity via 1101 Channel Bindings (see Section 5.11). 1103 [d] It is RECOMMENDED that each "virtual authenticator" identify itself 1104 distinctly, in order to enable the peer and backend server to tell 1105 them apart. For example, this can be accomplished by utilizing a 1106 distinct NAS-Identifier attribute. 1108 2.3. Server Identification 1110 The EAP method conversation is between the EAP peer and server, as 1111 identified by the Peer-Id and Server-Id. As shown in Figure 3, an 1112 authenticator may be configured to communicate with multiple EAP 1113 servers; the EAP server that an authenticator communicates with may 1114 vary according to configuration and network and server availability. 1115 While the EAP peer can assume that all EAP servers within a realm 1116 have access to the credentials necessary to validate an 1117 authentication attempt, it cannot assume that all EAP servers share 1118 persistent state. 1120 Authenticators may be configured with different primary or secondary 1121 EAP servers, in order to balance the load. Also, the authenticator 1122 can dynamically determine the EAP server to which requests will be 1123 sent; in event of a communication failure, the authenticator may fail 1124 over to another EAP server. For example, in Figure 3, Authenticator2 1125 may be initially configured with EAP server1 as its primary backend 1126 authentication server, and EAP server2 as the backup, but if EAP 1127 server1 becomes unavailable, EAP server2 may become the primary 1128 server. 1130 In general, the EAP peer cannot direct an authentication attempt to a 1131 particular EAP server within a realm; this decision is made solely by 1132 the authenticator. Nor can it determine which EAP server it will be 1133 communicating with, prior to the start of the EAP method 1134 conversation. The Server-Id is not included in the EAP- 1135 Request/Identity, and since the authenticator determines the EAP 1136 server dynamically, it typically is not possible for the 1137 authenticator to advertise the Server-Id during the discovery phase. 1138 EAP methods may or may not export the Server-Id, and as a result, the 1139 EAP peer may not even learn which server it was conversing with after 1140 the EAP conversation completes successfully. 1142 As a result, an EAP peer, on connecting to a new authenticator or 1143 reconnecting to the same authenticator, may find itself communicating 1144 with a different EAP server. Fast reconnect, defined in [RFC3748] 1145 Section 7.2, may fail if the EAP server that the peer communicates 1146 with is not the same one with which it initially established a 1147 security association. For example, an EAP peer attempting an EAP-TLS 1148 session resume may find that the new EAP-TLS server will not have 1149 access to the TLS Master Key identified by the TLS Session-Id, and 1150 therefore the session resumption attempt will fail, requiring 1151 completion of a full EAP-TLS exchange. 1153 EAP methods that support mutual authentication may not allow the EAP 1154 peer to verify the EAP server identity. For example, the EAP peer 1155 may only verify that the EAP server possesses a long-term secret; in 1156 this case the EAP peer will only know that an authenticator has been 1157 authorized by an EAP server, but will not confirm the identity of the 1158 EAP server. 1160 EAP methods that export the Server-Id MUST verify the server 1161 identity. As noted in Appendix A, existing EAP methods exporting the 1162 Server-Id determine this from the subjectAltName in the server 1163 certificate, and as a result, the peer determines the identity of the 1164 server (expressed as a Fully Qualified Domain Name (FQDN)) by 1165 validating the server certificate. 1167 Validating the EAP server identity may help the EAP peer to decide 1168 whether a specific EAP server is authorized, and to determine whether 1169 the EAP server is sharing keying material outside the intended scope. 1170 In some cases, such as where the certificate extensions defined in 1171 [RFC4334] are included in the server certificate, it may even be 1172 possible for the peer to verify some Channel Binding parameters from 1173 the server certificate. Where the EAP peer does not verify the EAP 1174 server identity, it is not possible for the peer to determine whether 1175 the EAP server has shared keying material outside its authorized 1176 scope. 1178 It is possible for problems to arise in situations where the EAP 1179 server identifies itself differently to the EAP peer and 1180 authenticator. For example, the Server-Id exported by EAP methods 1181 may not be identical to the Fully Qualified Domain Name (FQDN) of the 1182 backend authentication server. Where certificate-based 1183 authentication is used within RADIUS or Diameter, the subjectAltName 1184 used in the backend server certificate may not be identical to the 1185 Server-Id or backend server FQDN. 1187 Where the backend server FQDN differs from the subjectAltName in the 1188 certificate, the AAA client may not be able to successfully determine 1189 whether it is talking to the correct backend authentication server. 1190 Where the Server-Id and backend server FQDN differ, the combination 1191 of the key scope (Peer-Id, Server-Id) and EAP conversation identifier 1192 (Session-Id) may not be sufficient for the authenticator to determine 1193 where the key resides. For example, the authenticator may identify 1194 backend servers by their IP address (as occurs in RADIUS), or using a 1195 Fully Qualified Domain Name (as in Diameter). If the Server-Id does 1196 not correspond to the IP address or FQDN of a known backend 1197 authentication server, then the authenticator will not know which 1198 backend authentication server possesses the key. 1200 3. Security Association Management 1202 EAP as defined in [RFC3748] supports key derivation, but does not 1203 provide for the management of lower layer security associations. 1204 Missing functionality includes: 1206 [a] Security Association negotiation. EAP does not negotiate lower 1207 layer unicast or multicast security associations, including 1208 cryptographic algorithms or traffic profiles. EAP methods only 1209 negotiate cryptographic algorithms for their own use, not for the 1210 underlying lower layers. EAP also does not negotiate the traffic 1211 profiles to be protected with the negotiated ciphersuites; in some 1212 cases the traffic to be protected may have lower layer source and 1213 destination addresses different from the lower layer peer or 1214 authenticator addresses. 1216 [b] Re-key. EAP does not support re-key of exported keys without EAP 1217 re-authentication, although EAP methods may support "fast 1218 reconnect" as defined in [RFC3748] Section 7.2.1. 1220 [c] Key delete/install semantics. EAP does not synchronize 1221 installation or deletion of keying material on the EAP peer and 1222 authenticator. 1224 [d] Lifetime negotiation. EAP does not support lifetime negotiation 1225 for exported keys, and existing EAP methods also do not support key 1226 lifetime negotiation. 1228 [e] Guaranteed TSK freshness. Without a post-EAP handshake, TSKs can 1229 be reused if EAP keying material is cached. 1231 These deficiencies are typically addressed via a post-EAP handshake 1232 known as the Secure Association Protocol. 1234 3.1. Secure Association Protocol 1236 Since neither EAP nor EAP methods provide for establishment of lower 1237 layer security associations, it is RECOMMENDED that these facilities 1238 be provided within the Secure Association Protocol. This includes: 1240 [a] Entity Naming. A basic feature of a Secure Association Protocol is 1241 the explicit naming of the parties engaged in the exchange. 1243 Without explicit identification, the parties engaged in the 1244 exchange are not identified and the scope of the EAP keying 1245 parameters negotiated during the EAP exchange is undefined. 1247 [b] Mutual proof of possession of EAP keying material. During the 1248 Secure Association Protocol the EAP peer and authenticator MUST 1249 demonstrate possession of the keying material transported between 1250 the backend authentication server and authenticator (e.g. MSK), in 1251 order to demonstrate that the peer and authenticator have been 1252 authorized. Since mutual proof of possession is not the same as 1253 mutual authentication, the peer cannot verify authenticator 1254 assertions (including the authenticator identity) as a result of 1255 this exchange. Identity verification is discussed in Section 1256 2.2.1. 1258 [c] Secure capabilities negotiation. In order to protect against 1259 spoofing during the discovery phase, ensure selection of the "best" 1260 ciphersuite, and protect against forging of negotiated security 1261 parameters, the Secure Association Protocol MUST support secure 1262 capabilities negotiation. This includes the secure negotiation of 1263 usage modes, session parameters (such as security association 1264 identifiers (SAIDs) and key lifetimes), ciphersuites and required 1265 filters, including confirmation of security-relevant capabilities 1266 discovered during phase 0. The Secure Association Protocol MUST 1267 support integrity and replay protection of all capability 1268 negotiation messages. 1270 [d] Key naming and selection. Where key caching is supported, it may 1271 be possible for the EAP peer and authenticator to share more than 1272 one key of a given type. As a result, the Secure Association 1273 Protocol MUST explicitly name the keys used in the proof of 1274 possession exchange, so as to prevent confusion when more than one 1275 set of keying material could potentially be used as the basis for 1276 the exchange. Use of the key naming mechanism described in Section 1277 1.4.1 is RECOMMENDED. 1279 In order to support the correct processing of phase 2 security 1280 associations, the Secure Association (phase 2) protocol MUST 1281 support the naming of phase 2 security associations and associated 1282 transient session keys, so that the correct set of transient 1283 session keys can be identified for processing a given packet. The 1284 phase 2 Secure Association Protocol also MUST support transient 1285 session key activation and SHOULD support deletion, so that 1286 establishment and re-establishment of transient session keys can be 1287 synchronized between the parties. 1289 [e] Generation of fresh transient session keys (TSKs). Where the lower 1290 layer supports caching of exported EAP keying material, the EAP 1291 peer lower layer may initiate a new session using keying material 1292 that was derived in a previous session. Were the TSKs to be 1293 derived from a portion of the exported EAP keying material, this 1294 would result in reuse of the session keys which could expose the 1295 underlying ciphersuite to attack. 1297 In lower layers where caching of EAP keying material is supported, 1298 the Secure Association Protocol phase is REQUIRED, and MUST support 1299 the derivation of fresh unicast and multicast TSKs, even when the 1300 keying material provided by the backend authentication server is 1301 not fresh. This is typically supported via the exchange of nonces 1302 or counters, which are then mixed with the exported keying material 1303 in order to generate fresh unicast (phase 2a) and possibly 1304 multicast (phase 2b) session keys. By not using EAP keying 1305 material directly to protect data, the Secure Association Protocol 1306 protects it against compromise. 1308 [f] Key lifetime management. This includes explicit key lifetime 1309 negotiation or seamless re-key. EAP does not support re-key 1310 without re-authentication and existing EAP methods do not support 1311 key lifetime negotiation. As a result, the Secure Association 1312 Protocol may handle re-key and determination of the key lifetime. 1313 Where key caching is supported, secure negotiation of key lifetimes 1314 is RECOMMENDED. Lower layers that support re-key, but not key 1315 caching, may not require key lifetime negotiation. For example, a 1316 difference between IKEv1 [RFC2409] and IKEv2 [RFC4306] is that in 1317 IKEv1 SA lifetimes were negotiated; in IKEv2, each end of the SA is 1318 responsible for enforcing its own lifetime policy on the SA and re- 1319 keying the SA when necessary. 1321 [g] Key state resynchronization. It is possible for the peer or 1322 authenticator to reboot or reclaim resources, clearing portions or 1323 all of the key cache. Therefore, key lifetime negotiation cannot 1324 guarantee that the key cache will remain synchronized, and the peer 1325 may not be able to determine before attempting to use a key whether 1326 it exists within the authenticator cache. It is therefore 1327 RECOMMENDED for the Secure Association Protocol to provide a 1328 mechanism for key state resynchronization. Since in this situation 1329 one or more of the parties initially do not possess a key with 1330 which to protect the resynchronization exchange, securing this 1331 mechanism may be difficult. 1333 [h] Key scope synchronization. To support key scope determination, the 1334 Secure Association Protocol SHOULD provide a mechanism by which the 1335 peer can determine the scope of the key cache on each 1336 authenticator, and by which the authenticator can determine the 1337 scope of the key cache on a peer. This includes negotiation of 1338 restrictions on key usage. 1340 [i] Traffic profile negotiation. The traffic to be protected by a 1341 lower layer security association may not necessarily have the same 1342 lower layer source or destination address as the EAP peer and 1343 authenticator, and it is possible for the peer and authenticator to 1344 negotiate multiple security associations, each with a different 1345 traffic profile. Where this is the case, the profile of protected 1346 traffic SHOULD be explicitly negotiated. For example, in IKEv2 it 1347 is possible for an Initiator and Responder to utilize EAP for 1348 authentication, then negotiate a Tunnel Mode Security Association 1349 (SA) which permits passing of traffic originating from hosts other 1350 than the Initiator and Responder. Similarly, in IEEE 802.16e a 1351 Subscriber Station (SS) may forward traffic to the Base Station 1352 (BS) which originates from the Local Area Network (LAN) to which it 1353 is attached. To enable this, Security Associations within IEEE 1354 802.16e are identified by the Connection Identifier (CID), not by 1355 the EAP peer and authenticator MAC addresses. In both IKEv2 and 1356 IEEE 802.16e, multiple security associations may exist between the 1357 EAP peer and authenticator, each with their own traffic profile and 1358 quality of service parameters. 1360 [j] Direct operation. Since the phase 2 Secure Association Protocol is 1361 concerned with the establishment of security associations between 1362 the EAP peer and authenticator, including the derivation of 1363 transient session keys, only those parties have "a need to know" 1364 the transient session keys. The Secure Association Protocol MUST 1365 operate directly between the peer and authenticator, and MUST NOT 1366 be passed-through to the backend authentication server, or include 1367 additional parties. 1369 [k] Bi-directional operation. While some ciphersuites only require a 1370 single set of transient session keys to protect traffic in both 1371 directions, other ciphersuites require a unique set of transient 1372 session keys in each direction. The phase 2 Secure Association 1373 Protocol SHOULD provide for the derivation of unicast and multicast 1374 keys in each direction, so as not to require two separate phase 2 1375 exchanges in order to create a bi-directional phase 2 security 1376 association. See [RFC3748] Section 2.4 for more discussion. 1378 3.2. Key Scope 1380 Absent explicit specification within the lower layer, after the 1381 completion of phase 1b, EAP keying material and parameters are bound 1382 to the EAP peer and authenticator, but are not bound to a specific 1383 peer or authenticator port. 1385 While EAP Keying Material passed down to the lower layer is not 1386 intrinsically bound to particular authenticator and peer ports, 1387 Transient Session Keys MAY be bound to particular authenticator and 1388 peer ports by the Secure Association Protocol. However, a lower 1389 layer MAY also permit TSKs to be used on multiple peer and/or 1390 authenticator ports, providing that TSK freshness is guaranteed (such 1391 as by keeping replay counter state within the authenticator). 1393 In order to further limit the key scope the following measures are 1394 suggested: 1396 [a] The lower layer MAY specify additional restrictions on key usage, 1397 such as limiting the use of EAP keying material and parameters on 1398 the EAP peer to the port over which on the EAP conversation was 1399 conducted. 1401 [b] The backend authentication server and authenticator MAY implement 1402 additional attributes in order to further restrict the scope of EAP 1403 keying material. For example, in 802.11, the backend 1404 authentication server may provide the authenticator with a list of 1405 authorized Called or Calling-Station-Ids and/or SSIDs for which EAP 1406 keying material is valid. 1408 [c] Where the backend authentication server provides attributes 1409 restricting the key scope, it is RECOMMENDED that restrictions be 1410 securely communicated by the authenticator to the peer. This can 1411 be accomplished using the Secure Association Protocol, but also 1412 can be accomplished via the EAP method or the lower layer. 1414 3.3. Parent-Child Relationships 1416 When an EAP re-authentication takes place, new keying material is 1417 derived and exported by the EAP method, which eventually results in 1418 replacement of TSKs, regardless of the way they are derived (see 1419 Section 2.1). While the maximum lifetime of TSKs or child keys can 1420 be less than or equal to that of the MSK/EMSK, it cannot be greater. 1421 This is true even where exported EAP keying material is only used for 1422 entity authentication and is not used for key derivation (such as in 1423 IKEv2), so that compromise of exported EAP keying material does not 1424 imply compromise of the TSKs or child keys. However, where child 1425 keys are derived from or are wrapped by EAP keying material, 1426 compromise of the MSK/EMSK does imply compromise of the child keys. 1428 Child keys that are used frequently (such as TSKs which are used for 1429 traffic protection) can expire sooner than the exported EAP keying 1430 material they are dependent on, so that it is advantageous to support 1431 re-key of child keys prior to EAP re-authentication. Note that 1432 deletion of the MSK/EMSK does not necessarily imply deletion of TSKs 1433 or child keys. 1435 Failure to mutually prove possession of exported EAP keying material 1436 during the Secure Association Protocol exchange need not be grounds 1437 for deletion of the keying material by both parties; rate-limiting 1438 Secure Association Protocol exchanges could be used to prevent a 1439 brute force attack. 1441 3.4. Local Key Lifetimes 1443 The Transient EAP Keys (TEKs) are session keys used to protect the 1444 EAP conversation. The TEKs are internal to the EAP method and are 1445 not exported. TEKs are typically created during an EAP conversation, 1446 used until the end of the conversation and then discarded. However, 1447 methods may re-key TEKs during an EAP conversation. 1449 When using TEKs within an EAP conversation or across conversations, 1450 it is necessary to ensure that replay protection and key separation 1451 requirements are fulfilled. For instance, if a replay counter is 1452 used, TEK re-key MUST occur prior to wrapping of the counter. 1453 Similarly, TSKs MUST remain cryptographically separate from TEKs 1454 despite TEK re-keying or caching. This prevents TEK compromise from 1455 leading directly to compromise of the TSKs and vice versa. 1457 EAP methods may cache local keying material which may persist for 1458 multiple EAP conversations when fast reconnect is used [RFC3748]. 1459 For example, EAP methods based on TLS (such as EAP-TLS [I-D.simon- 1460 emu-rfc2716bis]) derive and cache the TLS Master Secret, typically 1461 for substantial time periods. The lifetime of other local keying 1462 material calculated within the EAP method is defined by the method. 1463 Note that in general, when using fast reconnect, there is no 1464 guarantee to that the original long-term credentials are still in the 1465 possession of the peer. For instance, a card hold holding the 1466 private key for EAP-TLS may have been removed. EAP servers SHOULD 1467 also verify that the long-term credentials are still valid, such as 1468 by checking that certificate used in the original authentication has 1469 not yet expired. 1471 3.5. Exported and Calculated Key Lifetimes 1473 The following mechanisms are available for communicating the lifetime 1474 of exported and calculated keying material between the EAP peer, 1475 server and authenticator: 1477 AAA protocols (backend server and authenticator) 1478 Lower layer mechanisms (authenticator and peer) 1479 EAP method-specific negotiation (peer and server) 1481 Where the EAP method does not support the negotiation of the lifetime 1482 of exported keys, and a key lifetime negotiation mechanism is not 1483 provided by the lower layer, there may be no way for the peer to 1484 learn the lifetime of exported and calculated keys. This can leave 1485 the peer uncertain how long the authenticator will maintain EAP 1486 keying material within the key cache. In this case the lifetime of 1487 exported keys can be managed as a system parameter on the peer and 1488 authenticator; a default lifetime of 8 hours is RECOMMENDED. 1490 3.5.1. AAA Protocols 1492 AAA protocols such as RADIUS [RFC2865] and Diameter [RFC4072] can be 1493 used to communicate the maximum exported key lifetime from the 1494 backend authentication server to the authenticator. 1496 The Session-Timeout attribute is defined for RADIUS in [RFC2865] and 1497 for Diameter in [RFC4005]. Where EAP is used for authentication, 1498 [RFC3580] Section 3.17 indicates that a Session-Timeout attribute 1499 sent in an Access-Accept along with a Termination-Action value of 1500 RADIUS-Request specifies the maximum number of seconds of service 1501 provided prior to EAP re-authentication. 1503 However, there is also a need to be able to specify the maximum 1504 lifetime of cached keying material. Where EAP pre-authentication is 1505 supported, cached keys can be pre-established on the authenticator 1506 prior to session start, and will remain there until they expire. EAP 1507 lower layers supporting caching of exported keying material may also 1508 persist that material after the end of a session, enabling the peer 1509 to subsequently resume communication utilizing the cached keying 1510 material. In these situations it may be desirable for the backend 1511 authentication server to specify the maximum lifetime of cached 1512 keying material. 1514 To accomplish this, [IEEE-802.11i] overloaded the Session-Timeout 1515 attribute, assuming that it represents the maximum time after which 1516 transported EAP keying material will expire on the authenticator, 1517 regardless of whether transported keying material is cached. 1519 An IEEE 802.11 authenticator receiving keying material is expected to 1520 initialize a timer to the Session-Timeout value, and once the timer 1521 expires, the exported keying material expires. Whether this results 1522 in session termination or EAP re-authentication is controlled by the 1523 value of the Termination-Action attribute. Where EAP re- 1524 authentication occurs the exported keying material is replaced, and 1525 with it, new calculated keys are put in place. Where session 1526 termination occurs, exported and calculated keying material is 1527 deleted. 1529 Overloading the Session-Timeout attribute is problematic in 1530 situations where it is necessary to control the maximum session time 1531 and key lifetime independently. For example, it might be desirable 1532 to limit the lifetime of cached keys to 5 minutes while permitting a 1533 user once authenticated to remain connected for up to an hour without 1534 re-authenticating. As a result, in the future additional attributes 1535 may be specified to control the lifetime of cached keys; these 1536 attributes may modify the meaning of the Session-Timeout attribute in 1537 specific circumstances. 1539 Since the TSK lifetime is often determined by authenticator 1540 resources, and the backend authentication server has no insight into 1541 the TSK derivation process, by the principle of ciphersuite 1542 independence, it is not appropriate for the backend authentication 1543 server to manage any aspect of the TSK derivation process, including 1544 the TSK lifetime. 1546 3.5.2. Lower Layer Mechanisms 1548 Lower layer mechanisms can be used to enable the lifetime of exported 1549 and calculated keys to be negotiated between the peer and 1550 authenticator. This can be accomplished either using the Secure 1551 Association Protocol or within the lower layer transport. 1553 Where TSKs are established as the result of a Secure Association 1554 Protocol exchange, it is RECOMMENDED that the Secure Association 1555 Protocol include support for TSK re-key. Where the TSK is taken 1556 directly from the MSK, there is no need to manage the TSK lifetime as 1557 a separate parameter, since the TSK lifetime and MSK lifetime are 1558 identical. 1560 3.5.3. EAP Method-Specific Negotiation 1562 All EAP methods generating keys are required to generate the MSK and 1563 EMSK, and may optionally generate the IV. However, EAP, defined in 1564 [RFC3748], does not itself support the negotiation of lifetimes for 1565 exported keying material such as the MSK, EMSK and IV. 1567 While EAP itself does not support lifetime negotiation, it would be 1568 possible to specify methods that do. However, systems that rely on 1569 such negotiation for exported keys would only function with these 1570 methods. Also, there is no guarantee that the lifetime negotiated 1571 within the EAP method would be compatible with backend authentication 1572 server policy. In the interest of method independence and 1573 compatibility with backend server implementations, key management of 1574 exported or derived keys SHOULD NOT be provided within EAP methods. 1576 3.6. Key Cache Synchronization 1578 Key lifetime negotiation alone cannot guarantee key cache 1579 synchronization. Even where a lower layer exchange is run 1580 immediately after EAP in order to determine the lifetime of EAP 1581 keying material, it is still possible for the authenticator to purge 1582 all or part of the key cache prematurely (e.g. due to reboot or need 1583 to reclaim memory). 1585 The lower layer may utilize the Discovery phase 0 to improve key 1586 cache synchronization. For example, if the authenticator manages the 1587 key cache by deleting the oldest key first, the relative creation 1588 time of the last key to be deleted could be advertised within the 1589 Discovery phase, enabling the peer to determine whether keying 1590 material had been prematurely expired from the authenticator key 1591 cache. 1593 3.7. Key Strength 1595 As noted in Section 2.1, EAP lower layers determine TSKs in different 1596 ways. Where EAP keying material is utilized in the derivation, 1597 encryption or authentication of TSKs, it is possible for EAP key 1598 generation to represent the weakest link. 1600 In order to ensure that EAP methods produce keying material of an 1601 appropriate symmetric key strength, it is RECOMMENDED that EAP 1602 methods utilizing public key cryptography choose a public key that 1603 has a cryptographic strength providing the required level of attack 1604 resistance. This is typically provided by configuring EAP methods, 1605 since there is no coordination between the lower layer and EAP method 1606 with respect to minimum required symmetric key strength. 1608 BCP 86 [RFC3766] Section 5 offers advice on the required RSA or DH 1609 module and DSA subgroup size in bits, for a given level of attack 1610 resistance in bits. The National Institute for Standards and 1611 Technology (NIST) also offers advice on appropriate key sizes in 1612 [SP800-57]. 1614 3.8. Key Wrap 1616 The key wrap specified in [RFC2548], which is based on an MD5-based 1617 stream cipher, has known problems, as described in [RFC3579] Section 1618 4.3. RADIUS uses the shared secret for multiple purposes, including 1619 per-packet authentication and attribute hiding, considerable 1620 information is exposed about the shared secret with each packet. 1621 This exposes the shared secret to dictionary attacks. MD5 is used 1622 both to compute the RADIUS Response Authenticator and the Message- 1623 Authenticator attribute, and concerns exist relating to the security 1624 of this hash [MD5Collision]. 1626 As discussed in [RFC3579] Section 4.3, the security vulnerabilities 1627 of RADIUS are extensive, and therefore development of an alternative 1628 key wrap technique based on the RADIUS shared secret would not 1629 substantially improve security. As a result, [RFC3579] Section 4.2 1630 recommends running RADIUS over IPsec. The same approach is taken in 1631 Diameter EAP [RFC4072], which defines clear-text key attributes, to 1632 be protected by IPsec or TLS. 1634 4. Handoff Vulnerabilities 1636 Several mechanisms have been proposed for reducing handoff latency 1637 within networks utilizing EAP. These include: 1639 EAP pre-authentication 1640 In EAP pre-authentication, an EAP peer pre-establishes EAP keying 1641 material with an authenticator prior to arrival. EAP pre- 1642 authentication only affects the timing of EAP authentication, but 1643 does not shorten or eliminate EAP (phase 1a) or AAA (phase 1b) 1644 exchanges; Discovery (phase 0) and Secure Association Protocol 1645 (phase 2) exchanges occur as described in Section 1.3. As a 1646 result, the primary benefit is to enable EAP authentication to be 1647 removed from the handoff critical path, thereby reducing latency. 1648 Use of EAP pre-authentication within IEEE 802.11 is described in 1649 [8021XPreAuth] and [IEEE-802.11i]. 1651 Proactive key distribution 1652 In proactive key distribution, derived keying material and 1653 authorizations are transported from the backend authentication 1654 server to a candidate authenticator in advance of a handoff. As a 1655 result, EAP (phase 1a) is not required, but the Discovery (phase 1656 0), and Secure Association Protocol exchanges (phase 2) are still 1657 necessary. Within the AAA exchange (phase 1b), authorization and 1658 key distribution functions are typically supported, but not 1659 authentication. Proactive key distribution is described in 1660 [MishraPro], [IEEE-03-084] and [I-D.irtf-aaaarch-handoff]. 1662 Key caching 1663 Caching of EAP keying material enables an EAP peer to re-attach to 1664 an authenticator without requiring EAP (phase 1a) or AAA (phase 1b) 1665 exchanges. However, Discovery (phase 0) and Secure Association 1666 Protocol (phase 2) exchanges are still required. Use of key 1667 caching within IEEE 802.11 is described in [IEEE-802.11i]. 1669 Context transfer 1670 In context transfer schemes, keying material and authorizations are 1671 transferred between a previous authenticator and a new 1672 authenticator. This can occur in response to a handoff request by 1673 the EAP peer, or in advance, as in proactive key distribution. As 1674 a result, EAP (phase 1a) is eliminated, but not the Discovery 1675 (phase 0) or Secure Association Protocol exchanges (phase 2). If a 1676 secure channel can be established between the new and previous 1677 authenticator without assistance from the backend authentication 1678 server, then the AAA exchange (phase 1b) can be eliminated; 1679 otherwise, it is still required, although it may be shortened. 1680 Context transfer protocols are described in [IEEE-802.11F] (now 1681 deprecated) and "Context Transfer Protocol (CXTP)" [RFC4067]. 1682 "Fast Authentication Methods for Handovers between IEEE 802.11 1683 Wireless LANs" [Bargh] analyzes fast handoff techniques, including 1684 context transfer mechanisms. 1686 Token distribution 1687 In token distribution schemes the EAP peer is provided with a 1688 credential, subsequently enabling it to authenticate with one or 1689 more additional authenticators. During the subsequent 1690 authentications, EAP (phase 1a) is eliminated or shortened; the 1691 Discovery (phase 0) and Secure Association Protocol exchanges 1692 (phase 2) still occur, although the latter may be shortened. If 1693 the token includes authorizations and can be validated by an 1694 authenticator without assistance from the backend authentication 1695 server, then the AAA exchange (phase 1b) can be eliminated; 1696 otherwise it is still required, although it may be shortened. 1697 Token-based schemes are described in [Token] and [I-D.friedman-ike- 1698 short-term-certs]. 1700 The sections that follow discuss the security vulnerabilities 1701 introduced by the above schemes. 1703 4.1. EAP Pre-authentication 1705 EAP pre-authentication differs from a normal EAP conversation 1706 primarily with respect to the lower layer encapsulation. For 1707 example, in [IEEE-802.11i], EAP pre-authentication frames utilize a 1708 distinct Ethertype, but otherwise conform to the encapsulation 1709 described in [IEEE-802.1X]. As a result, an EAP pre-authentication 1710 conversation differs little from the model described in Section 1.3, 1711 other than the introduction of a delay between phase 1 and phase 2. 1713 EAP pre-authentication relies on lower layer mechanisms for discovery 1714 of candidate authenticators. Where discovery can provide information 1715 on candidate authenticators outside the immediate listening range, 1716 and the peer can determine whether it already possesses valid keying 1717 material with candidate authenticators, the peer can avoid 1718 unnecessary EAP pre-authentications and can establish keying material 1719 well in advance, regardless of the coverage overlap between 1720 authenticators. However, if the peer can only discover candidate 1721 authenticators within listening range and cannot determine whether it 1722 can reuse existing key material, then peer may not be able to 1723 complete EAP pre-authentication prior to connectivity loss or may 1724 pre-authenticate multiple times with the same authenticator, 1725 increasing backend authentication server load. 1727 Since a peer may complete EAP pre-authentication with an 1728 authenticator without eventually attaching to it, phase 2 may never 1729 occur. As a result, an Accounting-Request signifying the start of 1730 service may never be sent, or may only be sent with a substantial 1731 delay after the completion of authentication. 1733 As noted in "IEEE 802.1X RADIUS Usage Guidelines" [RFC3580], the AAA 1734 exchange resulting from EAP pre-authentication differs little from an 1735 ordinary exchange described in "RADIUS Support for EAP" [RFC3579]. 1736 For example, since in IEEE 802.11i an Association exchange does not 1737 occur prior to EAP pre-authentication, the SSID is not known by the 1738 authenticator at authentication time, so that an Access-Request 1739 cannot include the SSID within the Called-Station-Id attribute as 1740 described in [RFC3580] Section 3.20. 1742 Since only the absence of an SSID in the Called-Station-Id attribute 1743 distinguishes an EAP pre-authentication attempt, if the authenticator 1744 does not always include the SSID for a normal EAP authentication 1745 attempt, the backend authentication server may not be able to 1746 determine whether a session constitutes an EAP pre-authentication 1747 attempt, potentially resulting in authorization or accounting 1748 problems. Where the number of simultaneous sessions is limited, the 1749 backend authentication server may refuse to authorize a valid EAP 1750 pre-authentication attempt or may enable the peer to engage in more 1751 simultaneous sessions than they are authorized for. Where EAP pre- 1752 authentication occurs with an authenticator which the peer never 1753 attaches to, the backend accounting server may not be able to 1754 determine whether the absence of an Accounting-Request was due to 1755 packet loss or a session that never started. 1757 In order to enable pre-authentication requests to be handled more 1758 reliably, it is RECOMMENDED that AAA protocols explicitly identify 1759 EAP pre-authentication. In order to suppress unnecessary EAP pre- 1760 authentication exchanges, it is RECOMMENDED that authenticators 1761 unambiguously identify themselves as described in Section 2.2.1. 1763 4.2. Proactive Key Distribution 1765 In proactive key distribution schemes, the backend authentication 1766 server transports keying material and authorizations to an 1767 authenticator in advance of the arrival of the peer. The 1768 authenticators selected to receive the transported key material are 1769 selected based on past patterns of peer movement between 1770 authenticators known as the "neighbor graph". Since proactive key 1771 distribution schemes typically only demonstrate proof of possession 1772 of transported keying material between the EAP peer and 1773 authenticator, the backend authentication server may not be provided 1774 with proof that the peer successfully authenticated to an 1775 authenticator. To compute the "neighbor graph" the backend 1776 authentication server therefore may need to rely on a stream of 1777 accounting messages without a corresponding set of authentication 1778 exchanges. 1780 In order to prevent compromise of one authenticator from resulting in 1781 compromise of other authenticators, cryptographic separation needs 1782 to be maintained between the keying material transported to each 1783 authenticator. However, even where cryptographic separation is 1784 maintained, an attacker compromising an authenticator may still 1785 disrupt the operation of other authenticators. Since proactive key 1786 distribution schemes typically only demonstrate proof of possession 1787 of transported keying material between the EAP peer and 1788 authenticator, the backend authentication server is typically not 1789 provided with proof that the peer actually connected to an 1790 authenticator. To compute the "neighbor graph" it therefore may be 1791 necessary to rely on a stream of accounting messages without a 1792 corresponding set of authentication exchanges to verify against. 1794 As noted in [RFC3579] Section 4.3.7, in the absence of spoofing 1795 detection within the AAA infrastructure, it is possible for EAP 1796 authenticators to impersonate each other. By forging NAS 1797 identification attributes within accounting messages, an attacker 1798 compromising one authenticator could corrupt the neighbor graph, 1799 tricking the backend authentication server into transporting keying 1800 material to arbitrary authenticators. While this would not enable 1801 recovery of EAP keying material without breaking fundamental 1802 cryptographic assumptions, it could enable fraudulent charges or 1803 allow an attacker to disrupt service by increasing load on the 1804 backend authentication server or thrashing the authenticator key 1805 cache. 1807 Since proactive key distribution requires the distribution of derived 1808 keying material to candidate authenticators, the effectiveness of 1809 this scheme depends on the ability of backend authentication server 1810 to anticipate the movement of the EAP peer. As described in [Mishra- 1811 Pro], knowledge of the "neighbor graph" can be established via static 1812 configuration or analysis of accounting messages. Since proactive 1813 key distribution relies on backend authentication server knowledge of 1814 the "neighbor graph" it is most applicable to intra-domain handoff 1815 scenarios. However, in inter-domain handoff where there may be many 1816 authenticators, the "neighbor graph" may not be readily derived on 1817 the backend authentication server, since peers may frequently connect 1818 to authenticators that have not previously been encountered. 1820 Since proactive key distribution schemes typically require 1821 introduction of server-initiated messages as described in [RFC3576] 1822 and [I-D.irtf-aaaarch-handoff], security issues described in 1823 [RFC3576] Section 5 are applicable, including authorization (Section 1824 5.1) and replay detection (Section 5.4) problems. 1826 4.3. AAA Bypass 1828 Fast handoff techniques which enable elimination of the AAA exchange 1829 (phase 1b) differ fundamentally from typical network access scenarios 1830 (dial-up, wired LAN, etc.) which include user authentication as well 1831 as authorization for the offered service. Where the AAA exchange 1832 (phase 1b) is omitted, authorizations and keying material are not 1833 provided by the backend authentication server, and as a result they 1834 need to be supplied by other means. This section describes some of 1835 the implications. 1837 4.3.1. Key Transport 1839 Where transported keying material is not supplied by the backend 1840 authentication server, it needs to be provided by another party 1841 authorized to access that keying material. As noted in Section 1.5, 1842 only the EAP peer, authenticator and server are authorized to possess 1843 transported EAP keying material. Since EAP peers do not trust each 1844 other, if the backend authentication server does not supply 1845 transported keying material to a new authenticator, it can only be 1846 provided by a previous authenticator. 1848 As noted in Section 1.5, the goal of the EAP conversation is to 1849 derive session keys known only to the peer and the authenticator. If 1850 EAP keying material is replicated between a previous authenticator 1851 and a new authenticator, then the previous authenticator may 1852 potentially know the session keys used between the peer and new 1853 authenticator. Also, the new authenticator may potentially know the 1854 session keys used between the peer and the previous authenticator. 1856 If a one-way function is used to derive the keying material to be 1857 transported to the new authenticator, then the new authenticator is 1858 not longer able to know previous session keys without breaking a 1859 fundamental cryptographic assumption. 1861 4.3.2. Authorization 1863 As a part of the authentication process, the backend authentication 1864 server determines the user's authorization profile and transmits the 1865 authorizations to the authenticator along with the transported EAP 1866 key material. Typically, the profile is determined based on the user 1867 identity, but a certificate presented by the user may also provide 1868 authorization information. 1870 The backend authentication server is responsible for making a user 1871 authorization decision, which requires answering the following 1872 questions: 1874 [a] Is this a legitimate user of this network? 1876 [b] Is the user allowed to access this network? 1878 [c] Is the user permitted to access this network on this day and at 1879 this time? 1881 [d] Is the user within the concurrent session limit? 1883 [e] Are there any fraud, credit limit, or other concerns indicating 1884 that access should be denied? 1886 [f] If access is to be granted, what are the service parameters 1887 (mandatory tunneling, bandwidth, filters, and so on) to be 1888 provisioned for the user? 1890 While the authorization decision is in principle simple, the 1891 distributed decision making process may add complexity. Where 1892 brokers or proxies are involved, all of the AAA entities in the chain 1893 from the authenticator to the home backend authentication server are 1894 involved in the decision. For example, a broker can deny access even 1895 if the home backend authentication server would allow it, or a proxy 1896 can add authorizations (e.g., bandwidth limits). 1898 Decisions can be based on static policy definitions and profiles as 1899 well as dynamic state (e.g. time of day or concurrent session 1900 limits). In addition to the Accept/Reject decisions made by AAA 1901 entities, service parameters or constraints may be communicated to 1902 the authenticator. 1904 The criteria for Accept/Reject decisions or the reasons for choosing 1905 particular authorizations are typically not communicated to the 1906 authenticator, only the final result. As a result, the authenticator 1907 has no way to know what the decision was based on. Was a set of 1908 authorization parameters sent because this service is always provided 1909 to the user, or was the decision based on the time of day and the 1910 capabilities of the authenticator? 1912 4.3.3. Correctness 1914 When the AAA exchange (phase 1b) is bypassed, several challenges 1915 arise in ensuring correct authorization: 1917 [a] Theft of service. Bypassing the AAA exchange (phase 1b) should not 1918 enable a user to extend their network access or gain access to 1919 services they are not entitled to. 1921 [b] Consideration of network-wide state. Handoff techniques should not 1922 render the backend authentication server incapable of keeping track 1923 of network-wide state. For example, a backend authentication 1924 server may need to keep track of simultaneous user sessions. 1926 [c] Elevation of privilege. Backend authentication servers often 1927 perform conditional evaluation, in which the authorizations 1928 returned in an Access-Accept message are contingent on the 1929 authenticator or on dynamic state such as the time of day. In this 1930 situation, bypassing the AAA exchange could enable unauthorized 1931 access unless the restrictions are explicitly encoded within the 1932 authorizations provided by the backend authentication server. 1934 A handoff mechanism that provides proper authorization is said to be 1935 "correct". One condition for correctness is as follows: 1937 For a handoff to be "correct" it MUST establish on the new 1938 authenticator the same authorizations as would have been created 1939 had the new authenticator completed a AAA conversation with the 1940 backend authentication server. 1942 A properly designed handoff scheme will only succeed if it is 1943 "correct" in this way. If a successful handoff would establish 1944 "incorrect" authorizations, it is preferable for it to fail. Where 1945 the supported services differ between authenticators, a handoff that 1946 bypasses the backend authentication server is likely to fail. 1947 [RFC2865] section 1.1 states: 1949 A authenticator that does not implement a given service MUST NOT 1950 implement the RADIUS attributes for that service. For example, a 1951 authenticator that is unable to offer ARAP service MUST NOT 1952 implement the RADIUS attributes for ARAP. A authenticator MUST 1953 treat a RADIUS access-accept authorizing an unavailable service as 1954 an access-reject instead. 1956 This behavior applies to attributes that are known, but not 1957 implemented. For attributes that are unknown, [RFC2865] Section 5 1958 states: 1960 A RADIUS server MAY ignore Attributes with an unknown Type. A 1961 RADIUS client MAY ignore Attributes with an unknown Type. 1963 In order to perform a correct handoff, if a new authenticator is 1964 provided with RADIUS authorizations for a known but unavailable 1965 service, then it MUST process these authorizations the same way it 1966 would handle a RADIUS Access-Accept requesting an unavailable 1967 service; this MUST cause the handoff to fail. However, if a new 1968 authenticator is provided with authorizations including unknown 1969 attributes, then these attributes MAY be ignored. The definition of 1970 a "known but unsupported service" MUST encompass requests for 1971 unavailable security services. This includes vendor-specific 1972 attributes related to security, such as those described in [RFC2548]. 1973 Although it may seem somewhat counter-intuitive, failure is indeed 1974 the "correct" result where a known but unsupported service is 1975 requested. 1977 Presumably a correctly configured backend authentication server would 1978 not request that an authenticator provide a service that it does not 1979 implement. This implies that if the new authenticator were to 1980 complete a AAA conversation, it would be likely to receive different 1981 service instructions. Failure of the handoff is the desired result 1982 since it will cause the new authenticator to go back to the backend 1983 server in order to receive the appropriate service definition. 1985 Handoff mechanisms which bypass the backend authentication server are 1986 most likely to be successful when employed in a homogeneous 1987 deployment within a single administrative domain. In a heterogeneous 1988 deployment, the backend authentication server may return different 1989 authorizations depending on the authenticator making the request, in 1990 order to make sure that the requested service is consistent with the 1991 authenticator capabilities. Where a backend authentication server 1992 would send different authorizations to the new authenticator than 1993 were sent to a previous authenticator, transferring authorizations 1994 between the previous authenticator and the new authenticator will 1995 result in incorrect authorization. 1997 Virtual LAN (VLAN) support is defined in [IEEE-802.1Q]; RADIUS 1998 support for dynamic VLANs is described in [RFC3580] and [RFC4675]. 1999 If some authenticators support dynamic VLANs while others do not, 2000 then attributes present in the Access-Request (such as the NAS-Port- 2001 Type, NAS-IP-Address, NAS-IPv6-Address and NAS-Identifier) could be 2002 examined by the backend authentication server to determine when VLAN 2003 attributes will be returned, and if so, which ones. However, if the 2004 backend authenticator is bypassed, then a handoff occurring between 2005 authenticators supporting different VLAN capabilities could result in 2006 a user obtaining access to an unauthorized VLAN (e.g. a user with 2007 access to a guest VLAN being given unrestricted access to the 2008 network). 2010 Similarly, a handoff between an authenticator providing 2011 confidentiality and another that does not should fail, since if the 2012 handoff were successful, the user would be moved from a secure to an 2013 insecure channel without permission from the backend authentication 2014 server. 2016 5. Security Considerations 2018 The EAP threat model is described in [RFC3748] Section 7.1. The 2019 security properties of EAP methods (known as "security claims") are 2020 described in [RFC3748] Section 7.2.1. EAP method requirements for 2021 applications such as Wireless LAN authentication are described in 2022 [RFC4017]. The RADIUS threat model is described in [RFC3579] Section 2023 4.1, and responses to these threats are described in [RFC3579] 2024 Sections 4.2 and 4.3. 2026 However, in addition to threats against EAP and AAA, there are other 2027 system level threats. In developing the threat model, it is assumed 2028 that: 2030 All traffic is visible to the attacker. 2031 The attacker can alter, forge or replay messages. 2032 The attacker can reroute messages to another principal. 2033 The attacker may be a principal or an outsider. 2034 The attacker can compromise any key that is sufficiently old. 2036 Threats arising from these assumptions include: 2038 [a] An attacker may compromise or steal an EAP authenticator, in an 2039 attempt to gain access to other EAP authenticators or obtain long- 2040 term secrets. 2042 [b] An attacker may try to modify or spoof packets, including Discovery 2043 or Secure Association Protocol frames, EAP or AAA packets. 2045 [c] An attacker may attempt a downgrade attack in order to exploit 2046 known weaknesses in an authentication method or cryptographic 2047 transform. 2049 [d] An attacker may attempt to induce an EAP peer, authenticator or 2050 server to disclose keying material to an unauthorized party, or 2051 utilize keying material outside the context that it was intended 2052 for. 2054 [e] An attacker may alter, forge or replay packets. 2056 [f] An attacker may cause an EAP peer, authenticator or server to reuse 2057 an stale key. Use of stale keys may also occur unintentionally. 2058 For example, a poorly implemented backend authentication server may 2059 provide stale keying material to an authenticator, or a poorly 2060 implemented authenticator may reuse nonces. 2062 [g] An authenticated attacker may attempt to obtain elevated privilege 2063 in order to access information that it does not have rights to. 2065 [h] An attacker may attempt a man-in-the-middle attack in order to gain 2066 access to the network. 2068 [i] An attacker may launch a denial of service attack against the EAP 2069 peer, authenticator or backend authentication server. 2071 [j] An attacker may compromise an EAP authenticator in an effort to 2072 commit fraud. For example, a compromised authenticator may provide 2073 incorrect information to the EAP peer and/or server via out-of-band 2074 mechanisms (such as via a AAA or lower layer protocol). This 2075 includes impersonating another authenticator, or providing 2076 inconsistent information to the peer and EAP server. 2078 In order to address these threats, [I-D.housley-aaa-key-mgmt] 2079 provides a description of mandatory system security properties. 2080 Issues relating to system security requirements are discussed in the 2081 sections that follow. 2083 5.1. Authenticator Compromise 2085 In the event that an authenticator is compromised or stolen, an 2086 attacker may gain access to the network via that authenticator, or 2087 may obtain the credentials required for that authenticator/AAA client 2088 to communicate with one or more backend authentication servers. 2089 However, this should not allow the attacker to compromise other 2090 authenticators or the backend authentication server, or obtain long- 2091 term user credentials. 2093 The implications of this requirement are many, but some of the more 2094 important are as follows: 2096 No Key Sharing 2097 An EAP authenticator MUST NOT share any keying material with 2098 another EAP authenticator, since if one EAP authenticator were 2099 compromised, this would enable the compromise of keying material on 2100 another authenticator. In order to be able to determine whether 2101 keying material has been shared, it is necessary for the identity 2102 of the EAP authenticator to be defined and understood by all 2103 parties that communicate with it. 2105 No AAA Credential Sharing 2106 AAA credentials (such as RADIUS shared secrets, IPsec pre-shared 2107 keys or certificates) MUST NOT be shared between AAA clients, since 2108 if one AAA client were compromised, this would enable an attacker 2109 to impersonate other AAA clients to the backend authentication 2110 server, or even to impersonate a backend authentication server to 2111 other AAA clients. 2113 No Compromise of Long-Term Credentials 2114 An attacker obtaining TSKs, TEKs or EAP keying material such as the 2115 MSK MUST NOT be able to obtain long-term user credentials such as 2116 pre-shared keys, passwords or private-keys without breaking a 2117 fundamental cryptographic assumption. 2119 5.2. Spoofing 2121 The use of per-packet authentication and integrity protection 2122 provides protection against spoofing attacks. Diameter [RFC3588] 2123 provides support for per-packet authentication and integrity 2124 protection via use of IPsec or TLS. RADIUS/EAP [RFC3579] provides 2125 for per-packet authentication and integrity protection via use of the 2126 Message-Authenticator attribute. 2128 [RFC3748] Section 7.2.1 describes the "integrity protection" security 2129 claim and [RFC4017] requires use of EAP methods supporting this 2130 claim. 2132 In order to prevent forgery of Secure Association Protocol frames, 2133 per-frame authentication and integrity protection is RECOMMENDED on 2134 all messages. [IEEE-802.11i] supports per-frame integrity protection 2135 and authentication on all messages within the 4-way handshake except 2136 the first message. An attack leveraging this ommission is described 2137 in [Analysis]. 2139 5.3. Downgrade Attacks 2141 The ability to negotiate the use of a particular cryptographic 2142 algorithm provides resilience against compromise of a particular 2143 cryptographic algorithm. This is usually accomplished by including 2144 an algorithm identifier in the protocol, and by specifying the 2145 algorithm requirements in the protocol specification. In order to 2146 prevent downgrade attacks, secure confirmation of the "best" 2147 ciphersuite is required. 2149 [RFC3748] Section 7.2.1 describes the "protected ciphersuite 2150 negotiation" security claim that refers to the ability of an EAP 2151 method to negotiate the ciphersuite used to protect the EAP 2152 conversation, as well as to integrity protect the negotiation. 2153 [RFC4017] requires EAP methods satisfying this security claim. 2155 Diameter [RFC3588] provides support for cryptographic algorithm 2156 negotiation via use of IPsec or TLS. RADIUS [RFC3579] does not 2157 support the negotiation of cryptographic algorithms, and relies on 2158 MD5 for integrity protection, authentication and confidentiality, 2159 despite known weaknesses in the algorithm [MD5Collision]. This issue 2160 can be addressed via use of RADIUS over IPsec, as described in 2161 [RFC3579] Section 4.2. 2163 As a result, EAP methods and AAA protocols are capable of addressing 2164 downgrade attacks. To ensure against downgrade attacks within lower 2165 layer protocols, algorithm independence is REQUIRED with lower layers 2166 using EAP for key derivation. For interoperability, at least one 2167 suite of mandatory-to-implement algorithm MUST be selected. Lower 2168 layer protocols supporting EAP for key derivation SHOULD also support 2169 secure ciphersuite negotiation. As described in [RFC1968], PPP ECP 2170 does not provide support for secure ciphersuite negotiation. 2171 However, [IEEE-802.11i] does support secure ciphersuite negotiation. 2173 5.4. Unauthorized Disclosure 2175 While preserving algorithm independence, confidentiality of all 2176 keying material MUST be maintained. To prevent unauthorized disclose 2177 of keys, each party in the EAP conversation MUST be authenticated to 2178 the other parties with whom it communicates. Keying material MUST be 2179 bound to the appropriate context. 2181 [RFC3748] Section 7.2.1 describes the "mutual authentication" and 2182 "dictionary attack resistance" claims, and [RFC4017] requires EAP 2183 methods satisfying these claims. EAP methods complying with 2184 [RFC4017] therefore provide for mutual authentication between the EAP 2185 peer and server. Within EAP, binding of EAP keying material (MSK, 2186 EMSK) to the appropriate context is provided by the Peer-Id and 2187 Server-Id which are exported along with the keying material. 2189 Diameter [RFC3588] provides for per-packet authentication and 2190 integrity protection via IPsec or TLS, and RADIUS/EAP [RFC3579] also 2191 provides for per-packet authentication and integrity protection. 2192 Where the NAS/authenticator and backend authentication server 2193 communicate directly and credible keywrap is used (see Section 3.8), 2194 this ensures that the AAA Key Transport phase achieves its security 2195 objectives: mutually authenticating the AAA client/authenticator and 2196 backend authentication server and providing EAP keying material to 2197 the EAP authenticator and to no other party. Within the AAA 2198 protocol, the authorization attributes provide the information 2199 binding the transported keying material to the appropriate context. 2200 For example, transported keying material is destined for the EAP 2201 authenticator identified by the NAS-Identifier attribute within the 2202 request, and relates to the EAP peer identified by the Peer-Id, User- 2203 Name [RFC2865] or CUI [RFC4372] attributes. 2205 [RFC2607] Section 7 describes the security issues occurring when the 2206 authenticator and backend authentication server do not communicate 2207 directly. Where an untrusted AAA intermediary is present (such as a 2208 RADIUS proxy or a Diameter agent), and data object security is not 2209 used, transported keying material may be recovered by an attacker in 2210 control of the untrusted intermediary. As discussed in Section 2.1, 2211 unless the TSKs are derived independently from EAP keying material 2212 (as in IKEv2), possession of transported keying material enables 2213 decryption of data traffic sent between the peer and a specific 2214 authenticator. However, as long as EAP keying material or keys 2215 derived from it are only utilized by a single authenticator, 2216 compromise of the transported keying material does not enable an 2217 attacker to impersonate the peer to another authenticator. 2218 Vulnerability to an untrusted AAA intermediary can be mitigated by 2219 implementation of redirect functionality, as described in [RFC3588] 2220 and [RFC4072]. 2222 As noted in Section 3.1, the Secure Association Protocol does not by 2223 itself provide for mutual authentication between the EAP peer and 2224 authenticator, even if mutual possession of EAP keying material is 2225 proven. Where the NAS/authenticator and backend authentication 2226 server communicate directly, the backend authentication server can 2227 verify the correspondence between NAS identification attributes, the 2228 source address of packets sent by the NAS, and the AAA credentials. 2229 As long as the NAS has not shared its AAA credentials with another 2230 NAS, this allows the backend authentication server to authenticate 2231 the NAS. Using Channel Bindings, the EAP peer can then determine 2232 whether the NAS/authenticator has provided the same identifying 2233 information to the EAP peer and backend authentication server. 2235 Peer and authenticator authorization MUST be performed. 2236 Authorization is REQUIRED whenever a peer associates with a new 2237 authenticator. Authorization checking prevents an elevation of 2238 privilege attack, and ensures that an unauthorized authenticator is 2239 detected. Authorizations SHOULD be synchronized between the EAP 2240 peer, server, authenticator. Once the EAP conversation exchanges are 2241 complete, all of these parties should hold the same view of the 2242 authorizations associated the other parties. If peer authorization 2243 is restricted, then the peer SHOULD be made aware of the restriction. 2245 The AAA exchange provides the EAP authenticator with authorizations 2246 relating to the EAP peer. However, neither the EAP nor AAA exchanges 2247 provides authorizations to the EAP peer. In order to ensure that all 2248 parties hold the same view of the authorizations it is RECOMMENDED 2249 that the Secure Association Protocol enable communication of 2250 authorizations between the EAP authenticator and peer. 2252 Consistently identifying the EAP authenticator enables the EAP peer 2253 to determine whether EAP keying material has been shared between EAP 2254 authenticators as well as to confirm with the backend authentication 2255 server that an EAP authenticator proving possession of EAP keying 2256 material during the Secure Association Protocol was authorized to 2257 obtain it. Identification issues are discussed in Section 2.2 and 2258 key scope issues are discussed in Section 3.2. 2260 5.5. Replay Protection 2262 Replay protection allows a protocol message recipient to discard any 2263 message that was recorded during a previous legitimate dialogue and 2264 presented as though it belonged to the current dialogue. 2266 [RFC3748] Section 7.2.1 describes the "replay protection" security 2267 claim and [RFC4017] requires use of EAP methods supporting this 2268 claim. 2270 Diameter [RFC3588] provides support for replay protection via use of 2271 IPsec or TLS. RADIUS/EAP [RFC3579] protects against replay of keying 2272 material via the Request Authenticator. However, some RADIUS packets 2273 are not replay protected. In Accounting, Disconnect and CoA-Request 2274 packets the Request Authenticator contains a keyed MAC rather than a 2275 Nonce. The Response Authenticator in Accounting, Disconnect and CoA 2276 Response packets also contains a keyed MAC whose calculation does not 2277 depend on a Nonce in either the Request or Response packets. 2278 Therefore unless an Event-Timestamp attribute is included or IPsec is 2279 used, the recipient may not be able to determine whether these 2280 packets have been replayed. 2282 In order to prevent replay of Secure Association Protocol frames, 2283 replay protection is REQUIRED on all messages. [IEEE-802.11i] 2284 supports replay protection on all messages within the 4-way 2285 handshake. 2287 5.6. Key Freshness 2289 A session key should be considered compromised if it remains in use 2290 too long. As noted in [I-D.housley-aaa-key-mgmt]], session keys MUST 2291 be strong and fresh, while preserving algorithm independence. A 2292 fresh cryptographic key is one that is generated specifically for the 2293 intended use. Each session deserves an independent session key; 2294 disclosure of one session key MUST NOT aid the attacker in 2295 discovering any other session keys. 2297 Fresh keys are required even when a long replay counter (that is, one 2298 that "will never wrap") is used to ensure that loss of state does not 2299 cause the same counter value to be used more than once with the same 2300 session key. 2302 EAP, AAA and the lower layer each bear responsibility for ensuring 2303 the use of fresh, strong session keys: 2305 EAP EAP methods need to ensure the freshness and strength of EAP keying 2306 material provided as an input to session key derivation. [RFC3748] 2307 Section 7.10 states that "EAP methods SHOULD ensure the freshness 2308 of the MSK and EMSK, even in cases where one party may not have a 2309 high quality random number generator. A RECOMMENDED method is for 2310 each party to provide a nonce of at least 128 bits, used in the 2311 derivation of the MSK and EMSK." The contribution of nonces 2312 enables the EAP peer and server to ensure that exported EAP keying 2313 material is fresh. 2315 [RFC3748] Section 7.2.1 describes the "key strength" and "session 2316 independence" security claims, and and [RFC4017] requires use of 2317 EAP methods supporting these claims as well as being capable of 2318 providing an equivalent key strength of 128 bits or greater. 2320 AAA The AAA protocol needs to ensure that transported keying material 2321 is fresh and is not utilized outside its recommended lifetime. 2322 Replay protection is necessary for key freshness, but an attacker 2323 can deliver a stale (and therefore potentially compromised) key in 2324 a replay-protected message, so replay protection is not sufficient. 2325 As discussed in Section 3.5, the Session-Timeout attribute enables 2326 the backend authentication server to limit the exposure of 2327 transported EAP keying material. 2329 The EAP Session-Id, derived as described in Section 1.4, enables 2330 the EAP peer, authenticator and server to distinguish EAP 2331 conversations. However, unless the authenticator keeps track of 2332 EAP Session-Ids, the authenticator cannot use the Session-Id to 2333 guarantee the freshness of EAP keying material. 2335 Lower Layer 2336 As described in Section 3.1, the lower layer Secure Association 2337 Protocol MUST generate a fresh session key for each session, even 2338 if the keying material and parameters provided by EAP methods are 2339 cached, or either the peer or authenticator lack a high entropy 2340 random number generator. A RECOMMENDED method is for the peer and 2341 authenticator to each provide a nonce or counter used in session 2342 key derivation. If a nonce is used, it is RECOMMENDED that it be 2343 at least 128 bits. 2345 5.7. Elevation of Privilege 2347 Parties MUST NOT have access to keying material that is not needed to 2348 perform their own role. A party has access to a particular key if it 2349 has access to all of the secret information needed to derive it. If 2350 a Secure Association Protocol is used to establish session keys, it 2351 MUST specify the scope for session keys. 2353 Transported EAP keying material is permitted to be accessed by the 2354 EAP peer, authenticator and server. The EAP peer and server derive 2355 the transported keying material during the process of mutually 2356 authenticating each other using the selected EAP method. During the 2357 Secure Association Protocol, the EAP peer utilizes the transported 2358 EAP keying material to demonstrate to the authenticator that it is 2359 the same party that authenticated to the EAP server and was 2360 authorized by it. The EAP authenticator utilizes the transported EAP 2361 keying material to prove to the peer not only that the EAP 2362 conversation was transported through it (this could be demonstrated 2363 by a man-in-the-middle), but that it was uniquely authorized by the 2364 EAP server to provide the peer with access to the network. Unique 2365 authorization can only be demonstrated if the EAP authenticator does 2366 not share the transported keying material with a party other than the 2367 EAP peer and server. 2369 TSKs are permitted to be accessed only by the EAP peer and 2370 authenticator (see Section 1.5). As discussed in Section 2.1, PPP 2371 and 802.11i derive the TSKs from transported EAP keying material; 2372 802.16e utilizes transported EAP keying material for TSK keywrap; 2373 IKEv2 utilizes transported EAP keying material only to authenticate 2374 the derivation of TSKs. 2376 Where demonstration of authorization depends entirely on possession 2377 of transported EAP keying material (such as in PPP, 802.11i and 2378 802.16e), this enables the backend server to masquerade as the 2379 authenticator, and possibly to obtain the TSKs unless the backend 2380 server deletes the transported EAP keying material after sending it. 2382 5.8. Man-in-the-middle Attacks 2384 As described in [I-D.puthenkulam-eap-binding], EAP method sequences 2385 and compound authentication mechanisms may be subject to man-in-the- 2386 middle attacks. When such attacks are successfully carried out, the 2387 attacker acts as an intermediary between a victim and a legitimate 2388 authenticator. This allows the attacker to authenticate successfully 2389 to the authenticator, as well as to obtain access to the network. 2391 In order to prevent these attacks, [I-D.puthenkulam-eap-binding] 2392 recommends derivation of a compound key by which the EAP peer and 2393 server can prove that they have participated in the entire EAP 2394 exchange. Since the compound key must not be known to an attacker 2395 posing as an authenticator, and yet must be derived from quantities 2396 that are exported by EAP methods, it may be desirable to derive the 2397 compound key from a portion of the EMSK. In order to provide proper 2398 key hygiene, it is recommended that the compound key used for man-in- 2399 the-middle protection be cryptographically separate from other keys 2400 derived from the EMSK. 2402 5.9. Denial of Service Attacks 2404 Key caching may result in vulnerability to denial of service attacks. 2405 For example, EAP methods that create persistent state may be 2406 vulnerable to denial of service attacks on the EAP server by a rogue 2407 EAP peer. 2409 To address this vulnerability, EAP methods creating persistent state 2410 may wish to limit the persistent state created by an EAP peer. For 2411 example, for each peer an EAP server may choose to limit persistent 2412 state to a few EAP conversations, distinguished by the EAP Session- 2413 Id. This prevents a rogue peer from denying access to other peers. 2415 Similarly, to conserve resources an authenticator may choose to limit 2416 the persistent state corresponding to each peer. This can be 2417 accomplished by limiting each peer to persistent state corresponding 2418 to a few EAP conversations, distinguished by the EAP Session-Id. 2420 Depending on the media, creation of new TSKs may or may not imply 2421 deletion of previously derived TSKs. Where there is no implied 2422 deletion, the authenticator may choose to limit the number of TSKs 2423 and associated state that can be stored for each peer. 2425 5.10. Impersonation 2427 Both the RADIUS [RFC2865] and Diameter [RFC3588] protocols are 2428 potentially vulnerable to impersonation by a rogue authenticator. 2429 While both protocols support mutual authentication between the 2430 authenticator/AAA client and the backend authentication server, the 2431 security mechanisms vary. 2433 In RADIUS, the shared secret used for authentication is determined by 2434 the source address of the RADIUS packet. As noted in [RFC3579] 2435 Section 4.3.7, it is highly desirable that the source address be 2436 checked against one or more NAS identification attributes so as to 2437 detect and prevent impersonation attacks. 2439 When RADIUS Access-Requests are forwarded by a proxy, the NAS-IP- 2440 Address or NAS-IPv6-Address attributes may not correspond to the 2441 source address. Since the NAS-Identifier attribute need not contain 2442 an FQDN, it also may not correspond to the source address, even 2443 indirectly. [RFC2865] Section 3 states: 2445 A RADIUS server MUST use the source IP address of the RADIUS 2446 UDP packet to decide which shared secret to use, so that 2447 RADIUS requests can be proxied. 2449 This implies that it is possible for a rogue authenticator to forge 2450 NAS-IP-Address, NAS-IPv6-Address or NAS-Identifier attributes within 2451 a RADIUS Access-Request in order to impersonate another 2452 authenticator. Among other things, this can result in messages (and 2453 transported keying material) being sent to the wrong authenticator. 2454 Since the rogue authenticator is authenticated by the RADIUS proxy or 2455 server purely based on the source address, other mechanisms are 2456 required to detect the forgery. In addition, it is possible for 2457 attributes such as the Called-Station-Id and Calling-Station-Id to be 2458 forged as well. 2460 [RFC3579] Section 4.3.7 describes how an EAP pass-through 2461 authenticator acting as a AAA client can be detected if it attempts 2462 to impersonate another authenticator (such by sending incorrect 2463 Called-Station-Id [RFC2865], NAS-Identifier [RFC2865], NAS-IP-Address 2464 [RFC2865] or NAS-IPv6-Address [RFC3162] attributes via the AAA 2465 protocol). This vulnerability can be mitigated by having RADIUS 2466 proxies check NAS identification attributes against the source 2467 address. 2469 While [RFC3588] requires use of the Route-Record AVP, this utilizes 2470 Fully Qualified Domain Names (FQDNs), so that impersonation detection 2471 requires DNS A, AAAA and PTR Resource Records (RRs) to be properly 2472 configured. As a result, Diameter is as vulnerable to this attack as 2473 RADIUS, if not more so. To address this vulnerability, it is 2474 necessary to allow the backend authentication server to communicate 2475 with the authenticator directly, such as via the redirect 2476 functionality supported in [RFC3588]. 2478 5.11. Channel Binding 2480 It is possible for a compromised or poorly implemented EAP 2481 authenticator to communicate incorrect information to the EAP peer 2482 and/or server. This may enable an authenticator to impersonate 2483 another authenticator or communicate incorrect information via out- 2484 of-band mechanisms (such as via AAA or the lower layer). 2486 Where EAP is used in pass-through mode, the EAP peer does not verify 2487 the identity of the pass-through authenticator. Within the Secure 2488 Association Protocol, the EAP peer and authenticator only demonstrate 2489 mutual possession of the transported EAP keying material. This 2490 creates a potential security vulnerability, described in [RFC3748] 2491 Section 7.15. 2493 As described in the previous section, it is possible for a proxy to 2494 detect a AAA client attempting to impersonate another authenticator 2495 (such by sending incorrect Called-Station-Id [RFC2865], NAS- 2496 Identifier [RFC2865], NAS-IP-Address [RFC2865] or NAS-IPv6-Address 2497 [RFC3162] attributes via the AAA protocol). However, it is possible 2498 for a pass-through authenticator acting as a AAA client to provide 2499 correct information to the backend authentication server while 2500 communicating misleading information to the EAP peer via the lower 2501 layer. 2503 For example, a compromised authenticator can utilize another 2504 authenticator's Called-Station-Id or NAS-Identifier in communicating 2505 with the EAP peer via the lower layer. Also, a pass-through 2506 authenticator acting as a AAA client can provide an incorrect peer 2507 Calling-Station-Id [RFC2865][RFC3580] to the backend authentication 2508 server via the AAA protocol. 2510 As noted in [RFC3748] Section 7.15, this vulnerability can be 2511 addressed by EAP methods that support a protected exchange of channel 2512 properties such as endpoint identifiers, including (but not limited 2513 to): Called-Station-Id [RFC2865][RFC3580], Calling-Station-Id 2514 [RFC2865][RFC3580], NAS-Identifier [RFC2865], NAS-IP-Address 2515 [RFC2865], and NAS-IPv6-Address [RFC3162]. 2517 Using such a protected exchange, it is possible to match the channel 2518 properties provided by the authenticator via out-of-band mechanisms 2519 against those exchanged within the EAP method. Typically the EAP 2520 method imports Channel Bindings from the lower layer on the peer, and 2521 transmits them securely to the EAP server, which exports them to the 2522 lower layer or AAA layer. However, transport may occur from EAP 2523 server to peer, or may be bi-directional. On the side of the 2524 exchange (peer or server) where Channel Bindings are verified, the 2525 lower layer or AAA layer passes the result of the verification (TRUE 2526 or FALSE) up to the EAP method. While the verification can be done 2527 either by the peer or the server, typically only the server has the 2528 knowledge to determine the correctness of the values, as opposed to 2529 merely verifying their equality. For further discussion, see [I- 2530 D.arkko-eap-service-identity-auth]. 2532 It is also possible to achieve Channel Bindings without transporting 2533 data over EAP. For example, see [I-D.draft-ohba-eap-channel- 2534 binding]. In this approach the EAP method includes Channel Bindings 2535 in the calculation of exported EAP keying material, making it 2536 impossible for the peer and authenticator to complete the Secure 2537 Association Protocol if there is a mismatch in the Channel Bindings. 2538 However, this approach can only be applied where EAP methods 2539 generating key material are used along with lower layers that utilize 2540 the keying material. For example, this mechanism would not enable 2541 verification of Channel Bindings on wired IEEE 802 networks using 2542 IEEE 802.1X. 2544 6. IANA Considerations 2546 This specification does not request the creation of any new parameter 2547 registries, nor does it require any other IANA assignments. 2549 7. References 2551 7.1. Normative References 2553 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2554 Requirement Levels", BCP 14, RFC 2119, March 1997. 2556 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 2557 Lefkowetz, "Extensible Authentication Protocol (EAP)", 2558 RFC 3748, June 2004. 2560 7.2. Informative References 2562 [Analysis] He, C. and J. Mitchell, "Analysis of the 802.11i 4-Way 2563 Handshake", Proceedings of the 2004 ACM Workshop on 2564 Wireless Security, pp. 43-50, ISBN: 1-58113-925-X. 2566 [Bargh] Bargh, M., Hulsebosch, R., Eertink, E., Prasad, A., Wang, 2567 H. and P. Schoo, "Fast Authentication Methods for 2568 Handovers between IEEE 802.11 Wireless LANs", Proceedings 2569 of the 2nd ACM international workshop on Wireless mobile 2570 applications and services on WLAN hotspots, October, 2571 2004. 2573 [GKDP] Dondeti, L., Xiang, J. and S. Rowles, "GKDP: Group Key 2574 Distribution Protocol", Internet draft (work in 2575 progress), draft-ietf-msec-gkdp-01, March 2006. 2577 [GSAKMP] Harney, H., Meth, U., Colegrove, A., and G. Gross, 2578 "GSAKMP: Group Secure Association Group Management 2579 Protocol", Internet draft (work in progress), draft-ietf- 2580 msec-gsakmp-sec-10, May 2005. 2582 [He] He, C., Sundararajan, M., Datta, A. Derek, A. and J. C. 2583 Mitchell, "A Modular Correctness Proof of TLS and IEEE 2584 802.11i", ACM Conference on Computer and Communications 2585 Security (CCS '05), November, 2005. 2587 [IEEE-802.11] Institute of Electrical and Electronics Engineers, 2588 "Information technology - Telecommunications and 2589 information exchange between systems - Local and 2590 metropolitan area networks - Specific Requirements Part 2591 11: Wireless LAN Medium Access Control (MAC) and 2592 Physical Layer (PHY) Specifications", IEEE IEEE Standard 2593 802.11-2003, 2003. 2595 [IEEE-802.1X] Institute of Electrical and Electronics Engineers, "Local 2596 and Metropolitan Area Networks: Port-Based Network Access 2597 Control", IEEE Standard 802.1X-2004, December 2004. 2599 [IEEE-802.1Q] Institute of Electrical and Electronics Engineers, "IEEE 2600 Standards for Local and Metropolitan Area Networks: Draft 2601 Standard for Virtual Bridged Local Area Networks", IEEE 2602 Standard 802.1Q/D8, January 1998. [IEEE802.11i] 2603 Institute of Electrical and Electronics Engineers, 2604 "Supplement to Standard for Telecommunications and 2605 Information Exchange Between Systems - LAN/MAN Specific 2606 Requirements - Part 11: Wireless LAN Medium Access 2607 Control (MAC) and Physical Layer (PHY) Specifications: 2608 Specification for Enhanced Security", IEEE 802.11i, July 2609 2004. 2611 [IEEE-802.11F] Institute of Electrical and Electronics Engineers, 2612 "Recommended Practice for Multi-Vendor Access Point 2613 Interoperability via an Inter-Access Point Protocol 2614 Across Distribution Systems Supporting IEEE 802.11 2615 Operation", IEEE 802.11F, July 2003 (now deprecated). 2617 [IEEE-802.16e] Institute of Electrical and Electronics Engineers, "IEEE 2618 Standard for Local and Metropolitan Area Networks: Part 2619 16: Air Interface for Fixed and Mobile Broadband Wireless 2620 Access Systems: Amendment for Physical and Medium Access 2621 Control Layers for Combined Fixed and Mobile Operations 2622 in Licensed Bands" IEEE 802.16e, August 2005. 2624 [IEEE-03-084] Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, 2625 "Proactive Key Distribution to support fast and secure 2626 roaming", IEEE 802.11 Working Group, IEEE-03-084r1-I, 2627 http://www.ieee802.org/11/Documents/DocumentHolder/ 2628 3-084.zip, January 2003. 2630 [I-D.housley-aaa-key-mgmt] 2631 Housley, R. and B. Aboba, "Guidance for AAA Key 2632 Management", draft-housley-aaa-key-mgmt-06.txt, Internet 2633 draft (work in progress), November 2006. 2635 [I-D.puthenkulam-eap-binding] 2636 Puthenkulam, J., "The Compound Authentication Binding 2637 Problem", draft-puthenkulam-eap-binding-04, Internet 2638 draft (work in progress), October 2003. 2640 [I-D.arkko-eap-service-identity-auth] 2641 Arkko, J. and P. Eronen, "Authenticated Service 2642 Information for the Extensible Authentication Protocol 2643 (EAP)", draft-arkko-eap-service-identity-auth-02.txt 2644 Internet draft (work in progress), May 2005. 2646 [I-D.friedman-ike-short-term-certs] 2647 Friedman, A., Sheffer, Y. and A. Shaqed, "Short Term 2648 Certificates", draft-friedman-ike-short-term-certs-01, 2649 Internet draft (work in progress), December 2006. 2651 [I-D.irtf-aaaarch-handoff] 2652 Arbaugh, W. and B. Aboba, "Handoff Extension to RADIUS", 2653 draft-irtf-aaaarch-handoff-04.txt, Internet Draft (work 2654 in progress), October 2003. 2656 [I-D.ohba-eap-channel-binding] 2657 Ohba, Y., Parthasrathy, M. and M. Yanagiya, "Channel 2658 Binding Mechanism Based on Parameter Binding in Key 2659 Derivation", draft-ohba-eap-channel-binding-00.txt, 2660 Internet draft (work in progress), January 2006. 2662 [I-D.simon-emu-rfc2716bis] 2663 Simon, D. and B. Aboba, "EAP TLS Authentication 2664 Protocol", draft-simon-emu-rfc2716bis-07.txt, Internet 2665 Draft (work in progress), January 2007. 2667 [MD5Collision] Klima, V., "Tunnels in Hash Functions: MD5 Collisions 2668 Within a Minute", Cryptology ePrint Archive, March 2006, 2669 http://eprint.iacr.org/2006/105.pdf 2671 [MishraPro] Mishra, A., Shin, M. and W. Arbaugh, "Pro-active Key 2672 Distribution using Neighbor Graphs", IEEE Wireless 2673 Communications, vol. 11, February 2004. 2675 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 2676 RFC 1661, July 1994. 2678 [RFC1968] Meyer, G. and K. Fox, "The PPP Encryption Control 2679 Protocol (ECP)", RFC 1968, June 1996. 2681 [RFC2230] Atkinson, R., "Key Exchange Delegation Record for the 2682 DNS", RFC 2230, November 1997. 2684 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 2685 (IKE)", RFC 2409, November 1998. 2687 [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D. 2688 and R. Wheeler, "A Method for Transmitting PPP Over 2689 Ethernet (PPPoE)", RFC 2516, February 1999. 2691 [RFC2535] Eastlake, D., "Domain Name System Security Extensions", 2692 RFC 2535, March 1999. 2694 [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", 2695 RFC 2548, March 1999. 2697 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 2698 Implementation in Roaming", RFC 2607, June 1999. 2700 [RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for 2701 specifying the location of services (DNS SRV)", RFC 2782, 2702 February 2000. 2704 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. 2705 Wellington, "Secret Key Transaction Authentication for 2706 DNS (TSIG)", RFC 2845, May 2000. 2708 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, 2709 "Remote Authentication Dial In User Service (RADIUS)", 2710 RFC 2865, June 2000. 2712 [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures 2713 (SIG(0)s )", RFC 2931, September 2000. 2715 [RFC3007] Wellington, B., "Simple Secure Domain Name System (DNS) 2716 Dynamic Update", RFC 3007, November 2000. 2718 [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 2719 3162, August 2001. 2721 [RFC3547] Baugher, M., Weis, B., Hardjono, T. and H. Harney, "The 2722 Group Domain of Interpretation", RFC 3547, July 2003. 2724 [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. 2725 Aboba, "Dynamic Authorization Extensions to Remote 2726 Authentication Dial In User Service (RADIUS)", RFC 3576, 2727 July 2003. 2729 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 2730 Dial In User Service) Support For Extensible 2731 Authentication Protocol (EAP)", RFC 3579, September 2003. 2733 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese, 2734 "IEEE 802.1X Remote Authentication Dial In User Service 2735 (RADIUS) Usage Guidelines", RFC 3580, September 2003. 2737 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. 2738 Arkko, "Diameter Base Protocol", RFC 3588, September 2739 2003. 2741 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 2742 Public Keys Used For Exchanging Symmetric Keys", RFC 2743 3766, April 2004. 2745 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M. and K. 2746 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 2747 August 2004. 2749 [RFC4005] Calhoun, P., Zorn, G., Spence, D. and D. Mitton, 2750 "Diameter Network Access Server Application", RFC 4005, 2751 August 2005 2753 [RFC4017] Stanley, D., Walker, J. and B. Aboba, "EAP Method 2754 Requirements for Wireless LANs", RFC 4017, March 2005. 2756 [RFC4067] Loughney, J., Nakhjiri, M., Perkins, C. and R. Koodli, 2757 "Context Transfer Protocol (CXTP)", RFC 4067, July 2005. 2759 [RFC4072] Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible 2760 Authentication Protocol (EAP) Application", RFC 4072, 2761 August 2005. 2763 [RFC4118] Yang, L., Zerfos, P. and E. Sadot, "Architecture Taxonomy 2764 for Control and Provisioning of Wireless Access Points 2765 (CAPWAP)", RFC 4118, June 2005. 2767 [RFC4186] Haverinen, H. and J. Salowey, "Extensible Authentication 2768 Protocol Method for Global System for Mobile 2769 Communications (GSM) Subscriber Identity Modules (EAP- 2770 SIM)", RFC 4186, January 2006. 2772 [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication 2773 Protocol Method for 3rd Generation Authentication and Key 2774 Agreement (EAP-AKA)", RFC 4187, January 2006. 2776 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 2777 RFC 4306, December 2005. 2779 [RFC4372] Adrangi, F., Lior, A., Korhonen, J. and J. Loughney, 2780 "Chargeable User Identity", RFC 4372, January 2006. 2782 [RFC4334] Housley, R. and T. Moore, "Certificate Extensions and 2783 Attributes Suporting Authentication in Point-to-Point 2784 Protocol (PPP) and Wireless Local Area Neworks (WLAN)", 2785 RFC 4334, February 2006. 2787 [RFC4763] Vanderveen, M. and H. Soliman, "Extensible Authentication 2788 Protocol Method for Shared-secret Authentication and Key 2789 Establishment (EAP-SAKE)", RFC 4763, November 2006. 2791 [RFC4675] Congdon, P., Sanchez, M. and B. Aboba, "RADIUS Attributes 2792 for Virtual LAN and Priority Support", RFC 4675, 2793 September 2006. 2795 [RFCPSK] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: a 2796 Pre-Shared Key EAP Method", Internet draft (work in 2797 progress), draft-bersani-eap-psk-11.txt, June 2006. 2799 [SP800-57] National Institute of Standards and Technology, 2800 "Recommendation for Key Management", Special Publication 2801 800-57, May 2006. 2803 [Token] Fantacci, R., Maccari, L., Pecorella, T. and F. Frosali, 2804 "A secure and performant token-based authentication for 2805 infrastructure and mesh 802.1X networks", IEEE 2806 Conference on Computer Communications, June 2006. 2808 [8021XPreAuth] Pack, S. and Y. Choi, "Pre-Authenticated Fast Handoff in 2809 a Public Wireless LAN Based on IEEE 802.1x Model", 2810 Proceedings of the IFIP TC6/WG6.8 Working Conference on 2811 Personal Wireless Communications, p.175-182, October 2812 23-25, 2002. 2814 Acknowledgments 2816 Thanks to Ashwin Palekar, and Tim Moore of Microsoft, Jari Arkko of 2817 Ericsson, Dorothy Stanley of Aruba Networks, Bob Moskowitz of 2818 TruSecure, Jesse Walker of Intel, Joe Salowey of Cisco and Russ 2819 Housley of Vigil Security for useful feedback. 2821 Authors' Addresses 2823 Bernard Aboba 2824 Microsoft Corporation 2825 One Microsoft Way 2826 Redmond, WA 98052 2828 EMail: bernarda@microsoft.com 2829 Phone: +1 425 706 6605 2830 Fax: +1 425 936 7329 2832 Dan Simon 2833 Microsoft Research 2834 Microsoft Corporation 2835 One Microsoft Way 2836 Redmond, WA 98052 2838 EMail: dansimon@microsoft.com 2839 Phone: +1 425 706 6711 2840 Fax: +1 425 936 7329 2842 Pasi Eronen 2843 Nokia Research Center 2844 P.O. Box 407 2845 FIN-00045 Nokia Group 2846 Finland 2848 EMail: pasi.eronen@nokia.com 2850 Henrik Levkowetz 2851 Ericsson Research 2852 Torshamsgatan 23 2853 SE-164 80 Stockholm 2854 SWEDEN 2856 Phone: +46 7 08 32 16 08 2857 EMail: henrik@levkowetz.com 2859 Appendix A - Exported Parameters in Existing Methods 2861 This Appendix specifies Session-Id, Peer-Id, Server-Id and Key- 2862 Lifetime for EAP methods that have been published prior to this 2863 specification. Future EAP method specifications MUST include a 2864 definition of the Session-Id, Peer-Id, and Server-Id (could be the 2865 empty string). 2867 EAP-Identity 2869 The EAP-Identity method is defined in [RFC3748]. It does not derive 2870 keys, and therefore does not define the Session-Id. The Peer-Id 2871 exported by the Identity method is determined by the octets included 2872 within the EAP- Response/Identity. The Server-Id is the empty string 2873 (zero length). 2875 EAP-Notification 2877 The EAP-Notification method is defined in [RFC3748]. It does not 2878 derive keys and therefore does not define the Session-Id. The Peer- 2879 Id and Server-Id are the empty string (zero length). 2881 EAP-GTC 2883 The EAP-GTC method is defined in [RFC3748]. It does not derive keys 2884 and therefore does not define the Session-Id. The Peer-Id and 2885 Server-Id are the empty string. 2887 EAP-OTP 2889 The EAP-OTP method is defined in [RFC3748]. It does not derive keys 2890 and therefore does not define the Session-Id. The Peer-Id and 2891 Server-Id are the empty string. 2893 EAP-AKA 2895 EAP-AKA is defined in [RFC4187]. The EAP-AKA Session-Id is the 2896 concatenation of the EAP Type Code (0x17) with the contents of the 2897 RAND field from the AT_RAND attribute, followed by the contents of 2898 the AUTN field in the AT_AUTN attribute. 2900 The Peer-Id is the contents of the Identity field from the 2901 AT_IDENTITY attribute, using only the Actual Identity Length octets 2902 from the beginning, however. Note that the contents are used as they 2903 are transmitted, regardless of whether the transmitted identity was a 2904 permanent, pseudonym, or fast EAP re-authentication identity. The 2905 Server-Id is an empty string. 2907 EAP-SIM 2909 EAP-SIM is defined in [RFC4186]. The EAP-SIM Session-Id is the 2910 concatenation of the EAP Type Code (0x12) with the contents of the 2911 RAND field from the AT_RAND attribute, followed by the contents of 2912 the NONCE_MT field in the AT_NONCE_MT attribute. 2914 The Peer-Id is the contents of the Identity field from the 2915 AT_IDENTITY attribute, using only the Actual Identity Length octets 2916 from the beginning, however. Note that the contents are used as they 2917 are transmitted, regardless of whether the transmitted identity was a 2918 permanent, pseudonym, or fast EAP re-authentication identity. The 2919 Server-Id is an empty string. 2921 EAP-PSK 2923 EAP-PSK is defined in [RFCPSK]. The EAP-PSK Session-Id is the 2924 concatenation of the EAP Type Code (0x2F) with the peer (RAND_P) and 2925 server (RAND_S) nonces. The Peer-Id is the contents of the ID_P 2926 field and the Server-Id is the contents of the ID_S field. 2928 EAP-SAKE 2930 EAP-SAKE is defined in [RFC4763]. The EAP-SAKE Session-Id is the 2931 concatenation of the EAP Type Code (0x30) with the contents of the 2932 RAND_S field from the AT_RAND_S attribute, followed by the contents 2933 of the RAND_P field in the AT_RAND_P attribute. Note that the EAP- 2934 SAKE Session-Id is not the same as the "Session ID" parameter chosen 2935 by the Server, which is sent in the first message, and replicated in 2936 subsequent messages. The Peer-Id is contained within the value field 2937 of the AT_PEERID attibute and the Server-Id, if available, is 2938 contained in the value field of the AT_SERVERID attribute. 2940 Intellectual Property Statement 2942 The IETF takes no position regarding the validity or scope of any 2943 Intellectual Property Rights or other rights that might be claimed to 2944 pertain to the implementation or use of the technology described in 2945 this document or the extent to which any license under such rights 2946 might or might not be available; nor does it represent that it has 2947 made any independent effort to identify any such rights. Information 2948 on the procedures with respect to rights in RFC documents can be 2949 found in BCP 78 and BCP 79. 2951 Copies of IPR disclosures made to the IETF Secretariat and any 2952 assurances of licenses to be made available, or the result of an 2953 attempt made to obtain a general license or permission for the use of 2954 such proprietary rights by implementers or users of this 2955 specification can be obtained from the IETF on-line IPR repository at 2956 http://www.ietf.org/ipr. 2958 The IETF invites any interested party to bring to its attention any 2959 copyrights, patents or patent applications, or other proprietary 2960 rights that may cover technology that may be required to implement 2961 this standard. Please address the information to the IETF at ietf- 2962 ipr@ietf.org. 2964 Disclaimer of Validity 2966 This document and the information contained herein are provided on an 2967 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2968 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2969 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2970 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2971 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2972 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2974 Copyright Statement 2976 Copyright (C) The IETF Trust (2007). This document is subject to the 2977 rights, licenses and restrictions contained in BCP 78, and except as 2978 set forth therein, the authors retain all their rights. 2980 Acknowledgment 2982 Funding for the RFC Editor function is currently provided by the 2983 Internet Society. 2985 Open Issues 2987 Open issues relating to this specification are tracked on the 2988 following web site: 2990 http://www.drizzle.com/~aboba/EAP/