idnits 2.17.1 draft-ietf-eap-keying-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2743. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2719. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2726. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2732. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC3748]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 465 has weird spacing: '...pically const...' == Line 1035 has weird spacing: '...icating to...' == 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 2101, but not defined == Missing Reference: 'RFC 3748' is mentioned on line 1392, but not defined == Missing Reference: 'IEEE802.11i' is mentioned on line 2417, but not defined == Missing Reference: 'RC3748' is mentioned on line 2651, but not defined == Unused Reference: 'I-D.arkko-eap-service-identity-auth' is defined on line 2463, but no explicit reference was found in the text == Unused Reference: 'I-D.ohba-eap-channel-binding' is defined on line 2469, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-housley-aaa-key-mgmt-02 == Outdated reference: A later version (-04) exists of draft-arkko-eap-service-identity-auth-02 == Outdated reference: A later version (-02) exists of draft-ohba-eap-channel-binding-00 -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Obsolete informational reference (is this intentional?): RFC 2716 (Obsoleted by RFC 5216) -- Obsolete informational reference (is this intentional?): RFC 2845 (Obsoleted by RFC 8945) -- Obsolete informational reference (is this intentional?): RFC 3547 (Obsoleted by RFC 6407) -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) Summary: 4 errors (**), 0 flaws (~~), 13 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 EAP Working Group Bernard Aboba 3 INTERNET-DRAFT Dan Simon 4 Category: Standards Track Microsoft 5 P. Eronen 6 25 June 2006 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 December 10, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society 2006. 39 Abstract 41 The Extensible Authentication Protocol (EAP), defined in [RFC3748], 42 enables extensible network access authentication. This document 43 provides a framework for the transport and usage of keying material 44 generated by EAP authentication algorithms, known as "methods". It 45 also specifies the EAP key hierarchy. 47 Table of Contents 49 1. Introduction .......................................... 3 50 1.1 Requirements Language ........................... 3 51 1.2 Terminology ..................................... 3 52 1.3 Overview ........................................ 6 53 1.4 EAP Key Hierarchy ............................... 8 54 1.5 Security Goals .................................. 12 55 1.6 EAP Invariants .................................. 13 56 2. Lower Layer Operation ................................. 16 57 2.1 Transient Session Keys .......................... 17 58 2.2 Authenticator and Peer Architecture ............. 18 59 2.3 Server Identification ........................... 23 60 3. Key Management ........................................ 25 61 3.1 Secure Association Protocol ..................... 25 62 3.2 Key Scope ....................................... 28 63 3.3 Parent-Child Relationships ...................... 29 64 3.4 Local Key Lifetimes ............................. 29 65 3.5 Exported and Calculated Key Lifetimes ........... 30 66 3.6 Key Cache Synchronization ....................... 31 67 3.7 Key Strength .................................... 32 68 3.8 Key Wrap ........................................ 33 69 4. Handoff Vulnerabilities ............................... 33 70 4.1 EAP Pre-authentication .......................... 34 71 4.2 Authorization ................................... 35 72 4.3 Correctness ..................................... 36 73 5. Security Considerations .............................. 39 74 5.1 Authenticator Compromise ........................ 40 75 5.2 Spoofing ........................................ 41 76 5.3 Downgrade Attacks ............................... 41 77 5.4 Unauthorized Disclosure ......................... 42 78 5.5 Replay Protection ............................... 44 79 5.6 Key Freshness ................................... 45 80 5.7 Elevation of Privilege .......................... 46 81 5.8 Man-in-the-Middle Attacks ....................... 47 82 5.9 Denial of Service Attacks ....................... 47 83 5.10 Impersonation ................................... 47 84 5.11 Channel Binding ................................. 49 85 6. IANA Considerations ................................... 50 86 7. References ............................................ 50 87 7.1 Normative References ............................ 50 88 7.2 Informative References .......................... 50 89 Acknowledgments .............................................. 55 90 Author's Addresses ........................................... 56 91 Appendix A - Exported Parameters in Existing Methods ......... 57 92 Intellectual Property Statement .............................. 58 93 Disclaimer of Validity ....................................... 59 94 Copyright Statement .......................................... 59 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], wireless networks such as 104 [IEEE-802.11i] d [IEEE-802.16e], and IKEv2 [RFC4306]. 106 This document provides a framework for the transport and usage of 107 keying material generated by EAP authentication algorithms, known as 108 "methods". In EAP, keying material is generated by EAP methods. 109 Part of this keying material may be used by EAP methods themselves 110 and part of this material may be exported. The exported keying 111 material may be transported by Authentication, Authorization and 112 Accounting (AAA) protocols and used by Secure Association Protocols 113 in the generation or transport of session keys which are used by 114 lower layer ciphersuites. This document describes each of these 115 elements and provides a system-level security analysis. It also 116 specifies the EAP key hierarchy. 118 1.1. Requirements Language 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in [RFC2119]. 124 1.2. Terminology 126 The terms "Cryptographic binding", "Cryptographic separation", "Key 127 strength" and "Mutual authentication" are defined in [RFC3748] and 128 are used with the same meaning in this document, which also 129 frequently uses the following terms: 131 AAA Authentication, Authorization and Accounting. AAA protocols with 132 EAP support include RADIUS [RFC3579] and Diameter [RFC4072]. In 133 this document, the terms "AAA server" and "backend authentication 134 server" are used interchangeably. 136 authenticator 137 The end of the link initiating EAP authentication. The term 138 Authenticator is used in [IEEE-802.1X], and authenticator has the 139 same meaning in this document. 141 peer The end of the link that responds to the authenticator. 143 backend authentication server 144 A backend authentication server is an entity that provides an 145 authentication service to an authenticator. When used, this server 146 typically executes EAP methods for the authenticator. This 147 terminology is also used in [IEEE-802.1X]. 149 Channel Binding 150 A secure mechanism for ensuring that a subset of the parameters 151 transmitted by the authenticator (such as authenticator identifiers 152 and properties) are agreed upon by the EAP peer and server. It is 153 expected that the parameters are also securely agreed upon by the 154 EAP peer and authenticator via the lower layer if the authenticator 155 advertised the parameters. 157 EAP server 158 The entity that terminates the EAP authentication method with the 159 peer. In the case where no backend authentication server is used, 160 the EAP server is part of the authenticator. In the case where the 161 authenticator operates in pass-through mode, the EAP server is 162 located on the backend authentication server. 164 Lower Layer 165 The lower layer is responsible for carrying EAP frames between the 166 peer and authenticator. 168 Long Term Credential 169 EAP methods frequently make use of long term secrets in order to 170 enable authentication between the peer and server. In the case of 171 a method based on pre-shared key authentication, the long term 172 credential is the pre-shared key. In the case of a public-key 173 based method, the long term credential is the corresponding private 174 key. 176 Master Session Key (MSK) 177 Keying material that is derived between the EAP peer and server and 178 exported by the EAP method. The MSK is at least 64 octets in 179 length. 181 AAA-Key 182 The term AAA-Key is synonymous with MSK. Since multiple keys may 183 be transported by AAA, the term is potentially confusing and is not 184 used in this document. 186 Extended Master Session Key (EMSK) 187 Additional keying material derived between the peer and server that 188 is exported by the EAP method. The EMSK is at least 64 octets in 189 length, and is never shared with a third party. 191 Initialization Vector (IV) 192 A quantity of at least 64 octets, suitable for use in an 193 initialization vector field, that is derived between the peer and 194 EAP server. Since the IV is a known value in methods such as EAP- 195 TLS [RFC2716], it cannot be used by itself for computation of any 196 quantity that needs to remain secret. As a result, its use has 197 been deprecated and EAP methods are not required to generate it. 198 However, when it is generated it MUST be unpredictable. 200 Network Access Server (NAS) 201 A device that provides an access service for a user to a network. 203 Pairwise Master Key (PMK) 204 Lower layers use the MSK in lower-layer dependent manner. For 205 instance, in [IEEE-802.11i] Octets 0-31 of the MSK are known as the 206 Pairwise Master Key (PMK). In [IEEE-802.11i] the TKIP and AES CCMP 207 ciphersuites derive their Transient Session Keys (TSKs) solely from 208 the PMK, whereas the WEP ciphersuite as noted in [RFC3580], derives 209 its TSKs from both halves of the MSK. In [802.16e], the MSK is 210 truncated to 20 octets for PMK and 20 octets for PMK2. 212 security association 213 A set of policies and cryptographic state used to protect 214 information. Elements of a security association may include 215 cryptographic keys, negotiated ciphersuites and other parameters, 216 counters, sequence spaces, authorization attributes, etc. 218 Secure Association Protocol 219 An exchange that occurs between the EAP peer and authenticator in 220 order to manage the creation and deletion of unicast and multicast 221 security associations. 223 Session-Id 224 The EAP Session-Id uniquely identifies an EAP session between an 225 EAP peer (as identified by the Peer-Id) and server (as identified 226 by the Server-Id). For more information, see Section 1.4. 228 Transient EAP Keys (TEKs) 229 Session keys which are used to establish a protected channel 230 between the EAP peer and server during the EAP authentication 231 exchange. The TEKs are appropriate for use with the ciphersuite 232 negotiated between EAP peer and server for use in protecting the 233 EAP conversation. The TEKs are stored locally by the EAP method 234 and are not exported. Note that the ciphersuite used to set up the 235 protected channel between the EAP peer and server during EAP 236 authentication is unrelated to the ciphersuite used to subsequently 237 protect data sent between the EAP peer and authenticator. 239 Transient Session Keys (TSKs) 240 Session keys used to protect data exchanged after EAP 241 authentication has successfully completed, using the ciphersuite 242 negotiated between the EAP peer and authenticator. 244 1.3. Overview 246 Where EAP key derivation is supported, the conversation typically 247 takes place in three phases: 249 Phase 0: Discovery 250 Phase 1: Authentication 251 1a: EAP authentication 252 1b: AAA Key Transport (optional) 253 Phase 2: Secure Association Protocol 254 2a: Unicast Secure Association 255 2b: Multicast Secure Association (optional) 257 Of these phases, Phase 0, 1b and Phase 2 are handled external to EAP. 258 Phases 0 and 2 are handled by the lower layer protocol and phase 1b 259 is typically handled by a AAA protocol. 261 In the discovery phase (phase 0), peers locate authenticators and 262 discover their capabilities. A peer may locate an authenticator 263 providing access to a particular network, or a peer may locate an 264 authenticator behind a bridge with which it desires to establish a 265 Secure Association. Discovery can occur manually or automatically, 266 depending on the lower layer over which EAP runs. 268 The authentication phase (phase 1) may begin once the peer and 269 authenticator discover each other. This phase, if it occurs, always 270 includes EAP authentication (phase 1a). Where the chosen EAP method 271 supports key derivation, in phase 1a EAP keying material is derived 272 on both the peer and the EAP server. 274 An additional step (phase 1b) is required in deployments which 275 include a backend authentication server, in order to transport keying 276 material from the backend authentication server to the authenticator. 277 In order to obey the principle of Mode Independence (see Section 278 1.6.1), where a backend server is present, all keying material which 279 is required by the lower layer needs to be transported from the EAP 280 server to the authenticator. Since existing TSK derivation and 281 transport techniques depend solely on the MSK, in existing 282 implementations, this is the only keying material replicated in the 283 AAA key transport phase 1b. 285 EAP peer Authenticator Auth. Server 286 -------- ------------- ------------ 287 |<----------------------------->| | 288 | Discovery (phase 0) | | 289 |<----------------------------->|<----------------------------->| 290 | EAP auth (phase 1a) | AAA pass-through (optional) | 291 | | | 292 | |<----------------------------->| 293 | | AAA Key transport | 294 | | (optional; phase 1b) | 295 |<----------------------------->| | 296 | Unicast Secure association | | 297 | (phase 2a) | | 298 | | | 299 |<----------------------------->| | 300 | Multicast Secure association | | 301 | (optional; phase 2b) | | 302 | | | 304 Figure 1: Conversation Overview 306 Successful completion of EAP authentication and key derivation by a 307 peer and EAP server does not necessarily imply that the peer is 308 committed to joining the network associated with an EAP server. 309 Rather, this commitment is implied by the creation of a security 310 association between the EAP peer and authenticator, as part of the 311 Secure Association Protocol (phase 2). The Secure Association 312 Protocol exchange (phase 2) occurs between the peer and authenticator 313 in order to manage the creation and deletion of unicast (phase 2a) 314 and multicast (phase 2b) security associations between the peer and 315 authenticator. The conversation between the parties is shown in 316 Figure 1. 318 1.3.1. Examples 320 Existing EAP lower layers implement phase 0, 2a and 2b in different 321 ways: 323 PPP Point-to-Point Protocol (PPP), defined in [RFC1661] does not 324 support discovery, nor does it include a Secure Association 325 Protocol. 327 PPPoE 328 PPP over Ethernet (PPPoE), defined in [RFC2516], includes support 329 for a Discovery stage (phase 0). In this step, the EAP peer sends 330 a PPPoE Active Discovery Initiation (PADI) packet to the broadcast 331 address, indicating the service it is requesting. The Access 332 Concentrator replies with a PPPoE Active Discovery Offer (PADO) 333 packet containing its name, the service name and an indication of 334 the services offered by the concentrator. The discovery phase is 335 not secured. PPPoE, like PPP, does not include a Secure 336 Association Protocol. 338 IKEv2 339 IKEv2, defined in [RFC4306], includes support for EAP and handles 340 the establishment of unicast security associations (phase 2a). 341 However, the establishment of multicast security associations 342 (phase 2b) typically does not involve EAP and needs to be handled 343 by a group key management protocol such as GDOI [RFC3547], GSAKMP 344 [GSAKMP], MIKEY [RFC3830], or GKDP [GKDP]. Several mechanisms have 345 been proposed for discovery of IPsec security gateways. [RFC2230] 346 discusses the use of KX Resource Records (RRs) for IPsec gateway 347 discovery; while KX RRs are supported by many DNS server 348 implementations, they have not yet been widely deployed. 349 Alternatively, DNS SRV [RFC2782] can be used for this purpose. 350 Where DNS is used for gateway location, DNS security mechanisms 351 such as DNSSEC ([RFC2535], [RFC2931]), TSIG [RFC2845], and Simple 352 Secure Dynamic Update [RFC3007] are available. 354 IEEE 802.11i 355 IEEE 802.11, defined in [IEEE-802.11], handles discovery via the 356 Beacon and Probe Request/Response mechanisms. IEEE 802.11 access 357 points periodically announce their Service Set Identifiers (SSIDs) 358 as well as capabilities using Beacon frames. Stations can query 359 for access points by sending a Probe Request to the broadcast 360 address. Neither Beacon nor Probe Request/Response frames are 361 secured. The 4-way handshake defined in [IEEE-802.11i] enables the 362 derivation of unicast (phase 2a) and multicast/broadcast (phase 2b) 363 secure associations. Since the group key exchange transports a 364 group key from the access point to the station, two 4-way 365 handshakes may be required in order to support peer-to-peer 366 communications. A proof of the security of the IEEE 802.11i 4-way 367 handshake when used with EAP-TLS [RFC2716], is provided in [He]. 369 IEEE 802.1X 370 IEEE 802.1X-2004, defined in [IEEE-802.1X] does not support 371 discovery (phase 0), nor does it provide for derivation of unicast 372 or multicast secure associations. 374 1.4. EAP Key Hierarchy 376 EAP, defined in [RFC3748], is a two-party protocol spoken between the 377 EAP peer and server. Within EAP, keying material is generated by EAP 378 methods. Part of this keying material may be used by EAP methods 379 themselves and part of this material may be exported. In addition to 380 export of keying material, EAP methods may also export associated 381 parameters, and may import and export Channel Bindings from the lower 382 layer. 384 As illustrated in Figure 2, the EAP method key derivation has at the 385 root the long term credential utilized by the selected EAP method. 386 If authentication is based on a pre-shared key, the parties store the 387 EAP method to be used and the pre-shared key. The EAP server also 388 stores the peer's identity as well as additional information. This 389 information is typically used outside of the EAP method to determine 390 if access to some service should be granted. The peer stores 391 information necessary to choose which secret to use for which 392 service. 394 If authentication is based on proof of possession of the private key 395 corresponding to the public key contained within a certificate, the 396 parties store the EAP method to be used and the trust anchors used to 397 validate the certificates. The EAP server may also store additional 398 information associated with the peer's identity and the peer stores 399 information necessary to choose which certificate to use for which 400 service. 402 If authentication is based on proof of possession of the private key 403 corresponding to the public key contained within a certificate, the 404 parties store the EAP method to be used and the trust anchors used to 405 validate the certificates. The EAP server also stores the peer's 406 identity and the peer stores information necessary to choose which 407 certificate to use for which service. Based on the long term 408 credential established between the peer and the server, EAP methods 409 derive two types of keys: 411 [a] Keys calculated locally by the EAP method but not exported 412 by the EAP method, such as the TEKs. 413 [b] Keying material exported by the EAP method: MSK, EMSK, IV. 415 As noted in [RFC3748] Section 7.10, EAP methods generating keys are 416 required to calculate and export the MSK and EMSK, which must be at 417 least 64 octets in length. EAP methods also may export the IV; 418 however, the use of the IV is deprecated. 420 The EMSK MUST NOT be provided to an entity outside the EAP server or 421 peer, nor is it permitted to pass any quantity to an entity outside 422 the EAP server or peer from which the EMSK could be computed without 423 breaking some cryptographic assumption, such as inverting a one-way 424 function. 426 EAP methods also MAY export method-specific peer and server 427 identifiers (Peer-Id and Server-Id) and a method-specific EAP 428 conversation identifier known as the Session-Id. EAP methods MAY 429 also support the import and export of Channel Bindings. New EAP 430 method specifications MUST define the Peer-Id, Server-Id and Session- 431 Id. The combination of the Peer-Id and Server-Id uniquely specifies 432 the endpoints of the EAP method exchange when they are provided. The 433 Peer-Id, Server-Id, and Session-Id for existing EAP methods is 434 defined in Appendix A. 436 Peer-Id 438 As described in [RFC3748] Section 7.3, the identity provided in 439 the EAP-Response/Identity, may be different from the peer identity 440 authenticated by the EAP method. Where the EAP method 441 authenticates the peer identity, that identity is exported by the 442 method as the Peer-Id. A suitable EAP peer name may not always be 443 available. Where an EAP method does not define a method-specific 444 peer identity, the Peer-Id is the null string. 446 Server-Id 448 Where the EAP method authenticates the server identity, that 449 identity is exported by the method as the Server-Id. A suitable 450 EAP server name may not always be available. Where an EAP method 451 does not define a method-specific server identity, the Server-Id 452 is the null string. 454 Session-Id 456 The Session-Id uniquely identifies an EAP session between an EAP 457 peer (as identified by the Peer-Id) and server (as identified by 458 the Server-Id). Where the EAP Type Code is less than 255, the EAP 459 Session-Id consists of the concatenation of the EAP Type Code and 460 a temporally unique identifier obtained from the method. Where 461 expanded EAP Type Codes are used, the EAP Session-Id consists of 462 the Expanded Type Code (including the Type, Vendor-Id and Vendor- 463 Type fields defined in [RFC3748] Section 5.7) concatenated with a 464 temporally unique identifier obtained from the method. This 465 unique identifier is typically constructed from nonces or 466 counters used within the EAP method exchange. The inclusion of 467 the Type Code in the EAP Session-Id ensures that each EAP method 468 has a distinct Session-Id space. Since an EAP session is not 469 bound to a particular authenticator or specific ports on the peer 470 and authenticator, the authenticator port or identity are not 471 included in the Session-Id. 473 Channel Bindings 475 Channel Bindings include lower layer parameters that are verified 476 for consistency between the EAP peer and server. In order to 477 avoid introducing media dependencies, EAP methods that transport 478 Channel Binding data MUST treat this data as opaque octets. See 479 Section 5.11 for further discussion. 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 1.4.1. Key Naming 516 Each key created within the EAP key management framework has a name 517 (a unique identifier), as well as a scope (the parties to whom the 518 key is available). The scope of exported parameters is defined by 519 the EAP Peer-Id (if securely exchanged within the method) and the EAP 520 Server-Id (also only if securely exchanged). Where a peer or server 521 name is missing the null string is used. 523 MSK and EMSK Names 524 These parameters are exported by the EAP peer and EAP server, and 525 can be referred to using the EAP Session-Id and a binary or textual 526 indication of the parameter being referred to. 528 PMK Name 529 This document does not specify a naming scheme for the PMK. The 530 PMK is only identified by the key from which it is derived. 532 Note: IEEE 802.11i names the PMKID for the purposes of being able 533 to refer to it in the Secure Association protocol; this naming is 534 based on a hash of the PMK itself as well as some other parameters 535 (see Section 8.5.1.2 [IEEE-802.11i]). 537 TEK Name 538 The TEKs may or may not be named. Their naming is specified in the 539 EAP method. 541 TSK Name 542 The TSKs are typically named. Their naming is specified in the 543 lower layer so that the correct set of transient session keys can 544 be identified for processing a given packet. 546 1.5. Security Goals 548 The goal of the EAP conversation is to derive fresh session keys 549 between the EAP peer and authenticator that are known only to those 550 parties, and for both the EAP peer and authenticator to demonstrate 551 that they are authorized to perform their roles either by each other 552 or by a trusted third party (the backend authentication server). 554 Completion of an EAP method exchange (Phase 1a) supporting key 555 derivation results in the derivation of EAP keying material (MSK, 556 EMSK, TEKs) known only to the EAP peer (identified by the Peer-Id) 557 and server (identified by the Server-Id). Both the EAP peer and EAP 558 server know the exported keying material to be fresh. Key freshness 559 is discussed in Sections 3.4, 3.5 and 5.6. 561 Completion of the AAA exchange (Phase 1b) results in the transport of 562 EAP keying material from the EAP server (identified by the Server-Id) 563 to the EAP authenticator (identified by the NAS-Identifier) without 564 disclosure to any other party. Both the EAP server and EAP 565 authenticator know this keying material to be fresh. Disclosure 566 issues are discussed in Section 5.4; security properties of AAA 567 protocols are discussed in Sections 5.1-5.7, and 5.10. 569 Completion of the Secure Association Protocol (Phase 2) results in 570 the derivation or transport of Transient Session Keys (TSKs) known 571 only to the EAP peer (identified by the Peer-Id) and authenticator 572 (identified by the NAS-Identifier). Both the EAP peer and 573 authenticator know the TSKs to be fresh. Both the EAP peer and 574 authenticator demonstrate that they are authorized to perform their 575 roles. Authorization issues are discussed in Section 5.7 and 5.8; 576 security properties of Secure Association Protocols are discussed in 577 Section 3.1. 579 1.6. EAP Invariants 581 Certain basic characteristics, known as "EAP Invariants", hold true 582 for EAP implementations on all media: 584 Mode independence 585 Media independence 586 Method independence 587 Ciphersuite independence 589 1.6.1. Mode Independence 591 EAP is typically deployed to support extensible network access 592 authentication in situations where a peer desires network access via 593 one or more authenticators. Where authenticators are deployed 594 standalone, the EAP conversation occurs between the peer and 595 authenticator, and the authenticator must locally implement an EAP 596 method acceptable to the peer. However, when utilized in "pass- 597 through" mode, EAP enables deployment of new authentication methods 598 without requiring development of new code on the authenticator. 600 While the authenticator may implement some EAP methods locally and 601 use those methods to authenticate local users, it may at the same 602 time act as a pass-through for other users and methods, forwarding 603 EAP packets back and forth between the backend authentication server 604 and the peer. This is accomplished by encapsulating EAP packets 605 within the Authentication, Authorization and Accounting (AAA) 606 protocol, spoken between the authenticator and backend authentication 607 server. AAA protocols supporting EAP include RADIUS [RFC3579] and 608 Diameter [RFC4072]. 610 It is a fundamental property of EAP that at the EAP method layer, the 611 conversation between the EAP peer and server is unaffected by whether 612 the EAP authenticator is operating in "pass-through" mode. EAP 613 methods operate identically in all aspects, including key derivation 614 and parameter import/export, regardless of whether the authenticator 615 is operating as a pass-through or not. 617 The successful completion of an EAP method that supports key 618 derivation results in the export of keying material and parameters on 619 the EAP peer and server. Even though the EAP peer or server may 620 import Channel-Bindings that may include the identity of the EAP 621 authenticator, this information is treated as opaque octets. As a 622 result, within EAP the only relevant identities are the Peer-Id and 623 Server-Id. Channel Bindings are only interpreted by the lower layer. 625 Within EAP, the primary function of the AAA protocol is to maintain 626 the principle of Mode Independence, so that as far as the EAP peer is 627 concerned, its conversation with the EAP authenticator, and all 628 consequences of that conversation, are identical, regardless of the 629 authenticator mode of operation. 631 1.6.2. Media Independence 633 One of the goals of EAP is to allow EAP methods to function on any 634 lower layer meeting the criteria outlined in [RFC3748], Section 3.1. 635 For example, as described in [RFC3748], EAP authentication can be run 636 over PPP [RFC1661], IEEE 802 wired networks [IEEE-802.1X], and 637 wireless networks such as 802.11 [IEEE-802.11i] and 802.16 638 [IEEE-802.16e]. 640 In order to maintain media independence, it is necessary for EAP to 641 avoid consideration of media-specific elements. For example, EAP 642 methods cannot be assumed to have knowledge of the lower layer over 643 which they are transported, and cannot be restricted to identifiers 644 associated with a particular usage environment (e.g. MAC addresses). 646 Note that media independence may be retained within EAP methods that 647 support Channel-Bindings or method-specific identification. An EAP 648 method need not be aware of the content of an identifier in order to 649 use it. This enables an EAP method to use media-specific identifiers 650 such as MAC addresses without compromising media independence. 651 Channel-Bindings are treated as opaque octets by EAP methods, so that 652 handling them does not require media-specific knowledge. 654 1.6.3. Method Independence 656 By enabling pass-through, authenticators can support any method 657 implemented on the peer and server, not just locally implemented 658 methods. This allows the authenticator to avoid implementing code 659 for each EAP method required by peers. In fact, since a pass-through 660 authenticator is not required to implement any EAP methods at all, it 661 cannot be assumed to support any EAP method-specific code. 663 As a result, as noted in [RFC3748], authenticators must by default be 664 capable of supporting any EAP method. This is useful where there is 665 no single EAP method that is both mandatory-to-implement and offers 666 acceptable security for the media in use. For example, the [RFC3748] 667 mandatory-to-implement EAP method (MD5-Challenge) does not provide 668 dictionary attack resistance, mutual authentication or key 669 derivation, and as a result is not appropriate for use in wireless 670 LAN authentication [RFC4017]. However, despite this it is possible 671 for the peer and authenticator to interoperate as long as a suitable 672 EAP method is supported on the EAP server. 674 1.6.4. Ciphersuite Independence 676 Ciphersuite Independence is a requirement for Media Independence. 677 Since lower layer ciphersuites vary between media, media independence 678 requires that EAP keying material needs to be large enough (with 679 sufficient entropy) to handle any ciphersuite. 681 While EAP methods may negotiate the ciphersuite used in protection of 682 the EAP conversation, the ciphersuite used for the protection of the 683 data exchanged after EAP authentication has completed is negotiated 684 between the peer and authenticator within the lower layer, outside of 685 EAP. 687 For example, within PPP, the ciphersuite is negotiated within the 688 Encryption Control Protocol (ECP) defined in [RFC1968], after EAP 689 authentication is completed. Within [IEEE-802.11i], the AP 690 ciphersuites are advertised in the Beacon and Probe Responses prior 691 to EAP authentication, and are securely verified during a 4-way 692 handshake exchange. 694 Since the ciphersuites used to protect data depend on the lower 695 layer, requiring EAP methods have knowledge of lower layer 696 ciphersuites would compromise the principle of Media Independence. 697 Since ciphersuite negotiation occurs in the lower layer, there is no 698 need for lower layer ciphersuite negotiation within EAP, and EAP 699 methods generate keying material that is ciphersuite-independent. 701 In order to allow a ciphersuite to be usable within the EAP keying 702 framework, a specification MUST be provided describing how TSKs 703 suitable for use with the ciphersuite are derived from exported EAP 704 keying parameters. To maintain Method Independence, algorithms for 705 deriving TSKs MUST NOT depend on the EAP method, although algorithms 706 for TEK derivation MAY be specific to the EAP method. 708 Advantages of ciphersuite-independence include: 710 Reduced update requirements 711 If EAP methods were to specify how to derive transient session keys 712 for each ciphersuite, they would need to be updated each time a new 713 ciphersuite is developed. In addition, backend authentication 714 servers might not be usable with all EAP-capable authenticators, 715 since the backend authentication server would also need to be 716 updated each time support for a new ciphersuite is added to the 717 authenticator. 719 Reduced EAP method complexity 720 Requiring each EAP method to include ciphersuite-specific code for 721 transient session key derivation would increase method complexity 722 and result in duplicated effort. 724 Simplified configuration 725 The ciphersuite is negotiated between the peer and authenticator 726 outside of EAP. Where the authenticator operates in "pass-through" 727 mode, the EAP server is not a party to this negotiation, nor is it 728 involved in the data flow between the EAP peer and authenticator. 729 As a result, the EAP server may not have knowledge of the 730 ciphersuites and negotiation policies implemented by the peer and 731 authenticator, or be aware of the ciphersuite negotiated between 732 them. For example, since ECP negotiation occurs after 733 authentication, when run over PPP, the EAP peer and server may not 734 anticipate the negotiated ciphersuite and therefore this 735 information cannot be provided to the EAP method. 737 2. Lower Layer Operation 739 On completion of EAP authentication, keying material and material and 740 parameters exported by the EAP method are provided to the lower layer 741 and AAA layer (if present). These include the Master Session Key 742 (MSK), Extended Master Session Key (EMSK), Peer-Id, Server-Id and 743 Session-Id. The Initialization Vector (IV) is deprecated. 745 In order to preserve the security of keys derived within EAP methods, 746 lower layers MUST NOT export keys passed down by EAP methods. This 747 implies that EAP keying material passed down to a lower layer is for 748 the exclusive use of that lower layer and MUST NOT be used within 749 another lower layer. This prevents compromise of one lower layer 750 from compromising other applications using EAP keying parameters. 752 EAP keying material provided to a lower layer MUST NOT be transported 753 to another entity. For example, EAP keying material passed down to 754 the EAP peer lower layer MUST NOT leave the peer; EAP keying 755 material passed down or transported to the EAP authenticator lower 756 layer MUST NOT leave the authenticator. 758 On the EAP server, keying material and parameters requested by and 759 passed down to the AAA layer may be replicated to the AAA layer on 760 the authenticator (with the exception of the EMSK). On the 761 authenticator, the AAA layer provides the replicated keying material 762 and parameters to the lower layer over which the EAP authentication 763 conversation took place. This enables "mode independence" to be 764 maintained. 766 The EAP layer as well as the peer and authenticator layers MUST NOT 767 modify or cache keying material or parameters (including Channel 768 Bindings) passing in either direction between the EAP method layer 769 and the lower layer or AAA layer. 771 2.1. Transient Session Keys 773 Where explicitly supported by the lower layer, lower layers MAY cache 774 the exported EAP keying material and parameters and/or TSKs. The 775 structure of this key cache is defined by the lower layer. So as to 776 enable interoperability, new lower layer specifications MUST describe 777 EAP key caching behavior. Unless explicitly specified by the lower 778 layer, the EAP peer, server and authenticator MUST assume that peers 779 and authenticators do not cache exported EAP keying parameters or 780 TSKs. Existing EAP lower layers and AAA layers handle the caching of 781 EAP keying material and the generation of transient session keys in 782 different ways: 784 IEEE 802.1X-2004 785 IEEE 802.1X-2004, defined in [IEEE-802.1X] does not support caching 786 of EAP keying material or parameters. Once EAP authentication 787 completes, it is assumed that EAP keying material and parameters 788 are discarded. 790 PPP PPP, defined in [RFC1661] does not support caching of EAP keying 791 material or parameters. PPP ciphersuites derive their TSKs 792 directly from the MSK, as described in [RFC2716]. This method is 793 NOT RECOMMENDED, since if PPP were to support caching, this could 794 result in TSK reuse. As a result, once the PPP session is 795 terminated, EAP keying material and parameters MUST be discarded. 796 Since caching of EAP keying material is not permitted, within PPP 797 there is no way to handle TSK re-key without EAP re-authentication. 798 Perfect Forward Secrecy (PFS) is only possible if the negotiated 799 EAP method supports this. 801 IKEv2 802 IKEv2, defined in [RFC4306] only uses the MSK for authentication 803 purposes and not key derivation. The EMSK, IV, Peer-Id, Server-Id 804 or Session-Id are not used. As a result, the keying material 805 derived within IKEv2 is independent of the EAP keying material and 806 re-key of IPsec SAs can be handled without requiring EAP re- 807 authentication. Since generation of keying material is independent 808 of EAP, within IKEv2 it is possible to negotiate PFS, regardless of 809 the EAP method that is used. IKEv2 as specified in [RFC4306] does 810 not cache EAP keying material or parameters; once IKEv2 811 authentication completes it is assumed that EAP keying material and 812 parameters are discarded. The Session-Timeout attribute is 813 therefore interpreted as a limit on the VPN session time, rather 814 than an indication of the MSK key lifetime. 816 IEEE 802.11i 817 IEEE 802.11i enables caching of the MSK, but not the EMSK, IV, 818 Peer-Id, Server-Id, or Session-Id. More details about the 819 structure of the cache are available in [IEEE-802.11i]. In IEEE 820 802.11i, TSKs are derived from the MSK using the 4-way handshake, 821 which includes a nonce exchange. This guarantees TSK freshness 822 even if the MSK is reused. The 4-way handshake also enables TSK 823 re-key without EAP re-authentication. PFS is only possible within 824 IEEE 802.11i if caching is not enabled and the negotiated EAP 825 method supports PFS. 827 IEEE 802.16e 828 IEEE 802.16e, defined in [IEEE-802.16e] supports caching of the 829 MSK, but not the EMSK, IV, Peer-Id, Server-Id or Session-Id. In 830 IEEE 802.16e, TSKs are generated by the authenticator without any 831 contribution by the peer. The TSKs are encrypted, authenticated 832 and integrity protected using the MSK. As a result, TSK re-key is 833 possible without EAP re-authentication. PFS is not possible even 834 if the negotiated EAP method supports it. 836 AAA Existing implementations of RADIUS/EAP [RFC3579] or Diameter EAP 837 [RFC4072] do not support caching of EAP keying material or 838 parameters. In existing AAA client, proxy and server 839 implementations, exported EAP keying material (MSK, EMSK and IV) as 840 well as parameters and derived keys are not cached and MUST be 841 presumed lost after the AAA exchange completes. 843 In order to avoid key reuse, the AAA layer MUST delete transported 844 keys once they are sent. The AAA layer MUST NOT retain keys that 845 it has previously sent. For example, a AAA layer that has 846 transported the MSK MUST delete it, and keys MUST NOT be derived 847 from the MSK from that point forward. 849 2.2. Authenticator and Peer Architecture 851 This specification does not impose constraints on the architecture of 852 the EAP authenticator or peer. Any of the authenticator architectures 853 described in [RFC4118] can be used. As a result, lower layers need to 854 identify EAP peers and authenticators unambiguously, without 855 incorporating implicit assumptions about peer and authenticator 856 architectures. 858 For example, it is possible for multiple base stations and a 859 "controller" (e.g. WLAN switch) to comprise a single EAP 860 authenticator. In such a situation, the "base station identity" is 861 irrelevant to the EAP method conversation, except perhaps as an 862 opaque blob to be used in Channel Bindings. Many base stations can 863 share the same authenticator identity. It should be understood that 864 an EAP authenticator or peer: 866 [a] may contain one or more physical or logical ports; 867 [b] may advertise itself as one or more "virtual" 868 authenticators or peers; 869 [c] may utilize multiple CPUs; 870 [d] may support clustering services for load balancing or failover. 872 Both the EAP peer and authenticator may have more than one physical 873 or logical port. A peer may simultaneously access the network via 874 multiple authenticators, or via multiple physical or logical ports on 875 a given authenticator. Similarly, an authenticator may offer network 876 access to multiple peers, each via a separate physical or logical 877 port. When a single physical authenticator advertises itself as 878 multiple "virtual authenticators", it is possible for a single 879 physical port to belong to multiple "virtual authenticators". 881 An authenticator may be configured to communicate with more than one 882 EAP server, each of which is configured to communicate with a subset 883 of the authenticators. The situation is illustrated in Figure 3. 885 2.2.1. Authenticator and Peer Identification 887 The EAP method conversation is between the EAP peer and server. The 888 authenticator identity, if considered at all by the EAP method, is 889 treated as an opaque blob for the purposes of Channel Bindings (see 890 Section 5.12). However, the authenticator identity is important in 891 two other exchanges - the AAA protocol exchange and the Secure 892 Association Protocol conversation. 894 The AAA conversation is between the EAP authenticator and the backend 895 authentication server. From the point of view of the backend 896 authentication server, EAP keying material and parameters are 897 transported to the EAP authenticator identified by the NAS-Identifier 898 attribute. Since an EAP authenticator MUST NOT share EAP keying 899 material or parameters with another party, if the EAP peer or backend 900 authentication server detects use of EAP keying material and 901 parameters outside the scope defined by the NAS-Identifier, the 902 keying material MUST be considered compromised. 904 The Secure Association Protocol conversation is between the peer and 905 the authenticator. For lower layers which support key caching it is 906 particularly important for the EAP peer, authenticator and backend 907 server to have a consistent view of the usage scope of the 908 transported EAP keying material. In order to enable this, it is 909 RECOMMENDED that the Secure Association Protocol explicitly 910 communicate the usage scope of the EAP keying material passed down to 911 the lower layer, rather than implicitly assuming that this is defined 912 by the authenticator and peer endpoint addresses. 914 +-+-+-+-+ 915 | EAP | 916 | Peer | 917 +-+-+-+-+ 918 | | | Peer Ports 919 / | \ 920 / | \ 921 / | \ 922 / | \ 923 / | \ 924 / | \ 925 / | \ 926 / | \ Authenticator 927 | | | | | | | | | Ports 928 +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ 929 | | | | | | 930 | Auth1 | | Auth2 | | Auth3 | 931 | | | | | | 932 +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ 933 \ | \ | 934 \ | \ | 935 \ | \ | 936 EAP over AAA \ | \ | 937 (optional) \ | \ | 938 \ | \ | 939 \ | \ | 940 \ | \ | 941 +-+-+-+-+-+ +-+-+-+-+-+ Backend 942 | EAP | | EAP | Authentication 943 | Server1 | | Server2 | Servers 944 +-+-+-+-+-+ +-+-+-+-+-+ 946 Figure 3: Relationship between EAP peer, authenticator and server 948 Since an authenticator may have multiple ports, the scope of the 949 authenticator key cache may not be described by a single endpoint 950 address. Similarly, where a peer may have multiple ports and sharing 951 of EAP keying material and parameters between peer ports of the same 952 link type is allowed, the extent of the peer key cache cannot be 953 communicated by using a single endpoint address. Instead, it is 954 RECOMMENDED that the EAP peer and authenticator consistently identify 955 themselves utilizing explicit identifiers, rather than endpoint 956 addresses or port identifiers. 958 AAA protocols such as RADIUS [RFC3579] and Diameter [RFC4072] provide 959 a mechanism for the identification of AAA clients; since the EAP 960 authenticator and AAA client are always co-resident, this mechanism 961 is applicable to the identification of EAP authenticators. 963 RADIUS [RFC2865] requires that an Access-Request packet contain one 964 or more of the NAS-Identifier, NAS-IP-Address and NAS-IPv6-Address 965 attributes. Since a NAS may have more than one IP address, the NAS- 966 Identifier attribute is RECOMMENDED for explicit identification of 967 the authenticator, both within the AAA protocol exchange and the 968 Secure Association Protocol conversation. 970 Problems which may arise where the peer and authenticator implicitly 971 identify themselves using endpoint addresses include the following: 973 [a] It may not be obvious to the peer which authenticator ports are 974 associated with which authenticators. The EAP peer will be unable 975 to determine whether EAP keying material has been shared outside 976 its authorized scope, and needs to be considered compromised. The 977 EAP peer may also be unable to utilize the authenticator key cache 978 in an efficient way. 980 [b] It may not be obvious to the authenticator which peer ports are 981 associated with which peers. As a result, the authenticator may 982 not be able to enable a peer to communicate with it utilizing 983 multiple peer ports. 985 [c] It may not be obvious to the peer which "virtual authenticator" it 986 is communicating with. For example, multiple "virtual 987 authenticators" may share a MAC address, but utilize different NAS- 988 Identifiers. 990 [d] It may not be obvious to the authenticator which "virtual peer" it 991 is communicating with. Multiple "virtual peers" may share a MAC 992 address, but utilize different Peer-Ids. 994 [e] It may not be possible for the EAP peer and server to verify the 995 authenticator identity via channel bindings. 997 For example, problems [a], [c] and [e] occur in [IEEE-802.11i], which 998 utilizes peer and authenticator MAC addresses within the 4-way 999 handshake. Problems [b] and [d] do not occur since [IEEE-802.11i] 1000 only allows a peer to utilize a single port. 1002 The following steps enable lower layer identities to be securely 1003 verified by all parties: 1005 [f] Specifying the lower layer parameters used to identify the 1006 authenticator and peer. As noted earlier, endpoint or port 1007 identifiers are not recommended for identification of the 1008 authenticator or peer when it is possible for them to have multiple 1009 ports. 1011 [g] Communicating the lower layer identities between the peer and 1012 authenticator within phase 0. This allows the peer and 1013 authenticator to determine the key scope if a key cache is 1014 utilized. 1016 [h] Communicating the lower layer authenticator identity between the 1017 authenticator and backend server within the NAS-Identifier 1018 attribute. 1020 [i] Including the lower layer identities within Channel Bindings (if 1021 supported) in phase 1a, ensuring that they are communicated between 1022 the EAP peer and server. 1024 [j] Supporting the integrity-protected exchange of identities within 1025 phase 2a. 1027 [k] Utilizing the advertised lower layer identities to enable the peer 1028 and authenticator to verify that keys are maintained within the 1029 advertised scope. 1031 2.2.2. Virtual Authenticators 1033 When a single physical authenticator advertises itself as multiple 1034 "virtual authenticators", if the virtual authenticators do not 1035 maintain logically separate key caches, then by authenticating to 1036 one virtual authenticator, the peer can gain access to the other 1037 virtual authenticators sharing a key cache. 1039 For example, where a physical authenticator implements "Guest" and 1040 "Corporate Intranet" virtual authenticators, an attacker acting as a 1041 peer could authenticate with the "Guest" "virtual authenticator" and 1042 derive EAP keying material. If the "Guest" and "Corporate Intranet" 1043 virtual authenticators share a key cache, then the peer can utilize 1044 the EAP keying material derived for the "Guest" network to obtain 1045 access to the "Corporate Intranet" network. 1047 In order to address this vulnerability: 1049 [a] Authenticators are REQUIRED to cache associated authorizations 1050 along with EAP keying material and parameters and to apply 1051 authorizations consistently. This ensures that an attacker cannot 1052 obtain elevated privileges even where the key cache is shared 1053 between "virtual authenticators". 1055 [b] It is RECOMMENDED that physical authenticators maintain separate 1056 key caches for each "virtual authenticator". 1058 [c] It is RECOMMENDED that each "virtual authenticator" identify itself 1059 consistently to the peer and to the backend authentication server, 1060 so as to enable the peer to verify the authenticator identity via 1061 Channel Bindings (see Section 5.11). 1063 [d] It is RECOMMENDED that each "virtual authenticator" identify itself 1064 distinctly, in order to enable the peer and backend server to tell 1065 them apart. For example, this can be accomplished by utilizing a 1066 distinct NAS-Identifier attribute or BSSID. 1068 2.3. Server Identification 1070 The EAP method conversation is between the EAP peer and server, as 1071 identified by the Peer-Id and Server-Id. As shown in Figure 3, an 1072 authenticator may be configured to communicate with multiple EAP 1073 servers; the EAP server that an authenticator communicates with may 1074 vary according to configuration and network and server availability. 1075 While the EAP peer can assume that all EAP servers within a realm 1076 have access to the credentials necessary to validate an 1077 authentication attempt, it cannot assume that all EAP servers share 1078 persistent state. 1080 Authenticators may be configured with different primary or secondary 1081 EAP servers, in order to balance the load. Also, the authenticator 1082 can dynamically determine the EAP server to which requests will be 1083 sent; in event of a communication failure, the authenticator may fail 1084 over to another EAP server. For example, in Figure 3, Authenticator2 1085 may be initially configured with EAP server1 as its primary backend 1086 authentication server, and EAP server2 as the backup, but if EAP 1087 server1 becomes unavailable, EAP server2 may become the primary 1088 server. 1090 In general, the EAP peer cannot direct an authentication attempt to a 1091 particular EAP server within a realm; this decision is made solely by 1092 the authenticator. Nor can it determine which EAP server it will be 1093 communicating with, prior to the start of the EAP method 1094 conversation. The Server-Id is not included in the EAP- 1095 Request/Identity, and since the authenticator determines the EAP 1096 server dynamically, it typically is not possible for the 1097 authenticator to advertise the Server-Id during the discovery phase. 1098 EAP methods may or may not export the Server-Id, and as a result, the 1099 EAP peer may not even learn which server it was conversing with after 1100 the EAP conversation completes successfully. 1102 As a result, an EAP peer, on connecting to a new authenticator or 1103 reconnecting to the same authenticator, may find itself communicating 1104 with a different EAP server. Fast reconnect, defined in [RFC3748] 1105 Section 7.2, may fail if the EAP server that the peer communicates 1106 with is not the same one with which it initially established a 1107 security association. For example, an EAP peer attempting an EAP-TLS 1108 session resume may find that the new EAP-TLS server will not have 1109 access to the TLS Master Key identified by the TLS Session-Id, and 1110 therefore the session resumption attempt will fail, requiring 1111 completion of a full EAP-TLS exchange. 1113 EAP methods that support mutual authentication may not allow the EAP 1114 peer to verify the EAP server identity. For example, the EAP peer 1115 may only verify that the EAP server possesses a long-term secret; in 1116 this case the EAP peer will only know that an authenticator has been 1117 authorized by an EAP server, but will not confirm the identity of the 1118 EAP server. 1120 EAP methods that export the Server-Id MUST verify the server 1121 identity. As noted in Appendix A, existing EAP methods exporting the 1122 Server-Id determine this from the altSubjectName in the server 1123 certificate, and as a result, the peer determines the identity of the 1124 server (expressed as a Fully Qualified Domain Name (FQDN)) by 1125 validating the server certificate. 1127 Validating the EAP server identity may help the EAP peer to decide 1128 whether a specific EAP server is authorized, and to determine whether 1129 the EAP server is sharing keying material outside the intended scope. 1130 In some cases, such as where the certificate extensions defined in 1131 [RFC4334] are included in the server certificate, it may even be 1132 possible for the peer to verify some Channel Binding parameters from 1133 the server certificate. Where the EAP peer does not verify the EAP 1134 server identity, it is not possible for the peer to determine whether 1135 the EAP server has shared keying material outside its authorized 1136 scope. 1138 It is possible for problems to arise in situations where the EAP 1139 server identifies itself differently to the EAP peer and 1140 authenticator. For example, the Server-Id exported by EAP methods 1141 may not be identical to the Fully Qualified Domain Name (FQDN) of the 1142 backend authentication server. Where certificate-based 1143 authentication is used within RADIUS or Diameter, the altSubjectName 1144 used in the backend server certificate may not be identical to the 1145 Server-Id or backend server FQDN. 1147 Where the backend server FQDN differs from the altSubjectName in the 1148 certificate, the AAA client may not be able to successfully determine 1149 whether it is talking to the correct backend authentication server. 1151 Where the Server-Id and backend server FQDN differ, the combination 1152 of the key scope (Peer-Id, Server-Id) and EAP conversation identifier 1153 (Session-Id) may not be sufficient for the authenticator to determine 1154 where the key resides. For example, the authenticator may identify 1155 backend servers by their IP address (as occurs in RADIUS), or using a 1156 Fully Qualified Domain Name (as in Diameter). If the Server-Id does 1157 not correspond to the IP address or FQDN of a known backend 1158 authentication server, then the authenticator will not know which 1159 backend authentication server possesses the key. 1161 3. Key Management 1163 EAP as defined in [RFC3748] supports key derivation, but does not 1164 provide for the management of exported or derived keys. Missing 1165 functionality includes: 1167 [a] Re-key. EAP does not support re-key of exported keys without re- 1168 authentication, although EAP methods may support "fast reconnect" 1169 as defined in [RFC3748] Section 7.2.1. 1171 [b] Key delete/install semantics. EAP does not synchronize 1172 installation or deletion of keying material on the EAP peer and 1173 authenticator. 1175 [c] Lifetime negotiation. EAP does not support lifetime negotiation for 1176 exported keys, and existing EAP methods also do not support key 1177 lifetime negotiation. 1179 [d] Cryptographic algorithm negotiation. EAP methods only negotiate 1180 cryptographic algorithms for their own use, not for the underlying 1181 lower layers. 1183 [e] Guaranteed TSK freshness. Without a post-EAP handshake, TSKs can 1184 be reused if EAP keying material is cached. 1186 These deficiencies are typically addressed via a post-EAP handshake 1187 known as the Secure Association Protocol. 1189 3.1. Secure Association Protocol 1191 Since neither EAP nor EAP methods provide key management support, it 1192 is RECOMMENDED that key management facilities be provided within the 1193 Secure Association Protocol. This includes: 1195 [a] Entity Naming. A basic feature of a Secure Association Protocol is 1196 the explicit naming of the parties engaged in the exchange. 1197 Without explicit identification, the parties engaged in the 1198 exchange are not identified and the scope of the EAP keying 1199 parameters negotiated during the EAP exchange is undefined. 1201 [b] Mutual proof of possession of EAP keying material. During the 1202 Secure Association Protocol the EAP peer and authenticator MUST 1203 demonstrate possession of the keying material transported between 1204 the backend authentication server and authenticator (e.g. MSK), in 1205 order to demonstrate that the peer and authenticator have been 1206 authorized. Since mutual proof of possession is not the same as 1207 mutual authentication, the peer cannot verify authenticator 1208 assertions (including the authenticator identity) as a result of 1209 this exchange. Identity verification is discussed in Section 1210 2.2.1. 1212 [c] Secure capabilities negotiation. In order to protect against 1213 spoofing during the discovery phase, ensure selection of the "best" 1214 ciphersuite, and protect against forging of negotiated security 1215 parameters, the Secure Association Protocol MUST support secure 1216 capabilities negotiation. This includes the secure negotiation of 1217 usage modes, session parameters (such as security association 1218 identifiers (SAIDs) and key lifetimes), ciphersuites and required 1219 filters, including confirmation of security-relevant capabilities 1220 discovered during phase 0. The Secure Association Protocol MUST 1221 support integrity and replay protection of all capability 1222 negotiation messages. 1224 [d] Key naming and selection. Where key caching is supported, it may 1225 be possible for the EAP peer and authenticator to share more than 1226 one key of a given type. As a result, the Secure Association 1227 Protocol MUST explicitly name the keys used in the proof of 1228 possession exchange, so as to prevent confusion when more than one 1229 set of keying material could potentially be used as the basis for 1230 the exchange. Use of the key naming mechanism described in Section 1231 1.4.1 is RECOMMENDED. 1233 In order to support the correct processing of phase 2 security 1234 associations, the Secure Association (phase 2) protocol MUST 1235 support the naming of phase 2 security associations and associated 1236 transient session keys, so that the correct set of transient 1237 session keys can be identified for processing a given packet. The 1238 phase 2 Secure Association Protocol also MUST support transient 1239 session key activation and SHOULD support deletion, so that 1240 establishment and re-establishment of transient session keys can be 1241 synchronized between the parties. 1243 [e] Generation of fresh transient session keys (TSKs). Where the lower 1244 layer supports caching of exported EAP keying material, the EAP 1245 peer lower layer may initiate a new session using keying material 1246 that was derived in a previous session. Were the TSKs to be 1247 derived from a portion of the exported EAP keying material, this 1248 would result in reuse of the session keys which could expose the 1249 underlying ciphersuite to attack. 1251 In lower layers where caching of EAP keying material is supported, 1252 the Secure Association Protocol phase is REQUIRED, and MUST support 1253 the derivation of fresh unicast and multicast TSKs, even when the 1254 keying material provided by the backend authentication server is 1255 not fresh. This is typically supported via the exchange of nonces 1256 or counters, which are then mixed with the exported keying material 1257 in order to generate fresh unicast (phase 2a) and possibly 1258 multicast (phase 2b) session keys. By not using EAP keying 1259 material directly to protect data, the Secure Association Protocol 1260 protects it against compromise. 1262 [f] Key lifetime management. This includes explicit key lifetime 1263 negotiation or seamless re-key. EAP does not support re-key 1264 without re-authentication and existing EAP methods do not support 1265 key lifetime negotiation. As a result, the Secure Association 1266 Protocol may handle re-key and determination of the key lifetime. 1267 Where key caching is supported, secure negotiation of key lifetimes 1268 is RECOMMENDED. Lower layers that support re-key, but not key 1269 caching, may not require key lifetime negotiation. For example, a 1270 difference between IKEv1 [RFC2409] and IKEv2 [RFC4306] is that in 1271 IKEv1 SA lifetimes were negotiated; in IKEv2, each end of the SA is 1272 responsible for enforcing its own lifetime policy on the SA and re- 1273 keying the SA when necessary. 1275 [g] Key state resynchronization. It is possible for the peer or 1276 authenticator to reboot or reclaim resources, clearing portions or 1277 all of the key cache. Therefore, key lifetime negotiation cannot 1278 guarantee that the key cache will remain synchronized, and the peer 1279 may not be able to determine before attempting to use a key whether 1280 it exists within the authenticator cache. It is therefore 1281 RECOMMENDED for the Secure Association Protocol to provide a 1282 mechanism for key state resynchronization. Since in this situation 1283 one or more of the parties initially do not possess a key with 1284 which to protect the resynchronization exchange, securing this 1285 mechanism may be difficult. 1287 [h] Key scope synchronization. To support key scope determination, the 1288 Secure Association Protocol SHOULD provide a mechanism by which the 1289 peer can determine the scope of the key cache on each 1290 authenticator, and by which the authenticator can determine the 1291 scope of the key cache on a peer. This includes negotiation of 1292 restrictions on key usage. 1294 [i] Direct operation. Since the phase 2 Secure Association Protocol is 1295 concerned with the establishment of security associations between 1296 the EAP peer and authenticator, including the derivation of 1297 transient session keys, only those parties have "a need to know" 1298 the transient session keys. The Secure Association Protocol MUST 1299 operate directly between the peer and authenticator, and MUST NOT 1300 be passed-through to the backend authentication server, or include 1301 additional parties. 1303 [j] Bi-directional operation. While some ciphersuites only require a 1304 single set of transient session keys to protect traffic in both 1305 directions, other ciphersuites require a unique set of transient 1306 session keys in each direction. The phase 2 Secure Association 1307 Protocol SHOULD provide for the derivation of unicast and multicast 1308 keys in each direction, so as not to require two separate phase 2 1309 exchanges in order to create a bi-directional phase 2 security 1310 association. See [RFC3748] Section 2.4 for more discussion. 1312 3.2. Key Scope 1314 Absent explicit specification within the lower layer, after the 1315 completion of phase 1b, EAP keying material and parameters are bound 1316 to the EAP peer and authenticator, but are not bound to a specific 1317 peer or authenticator port. 1319 While EAP Keying Material passed down to the lower layer is not 1320 intrinsically bound to particular authenticator and peer ports, 1321 Transient Session Keys MAY be bound to particular authenticator and 1322 peer ports by the Secure Association Protocol. However, a lower 1323 layer MAY also permit TSKs to be used on multiple peer and/or 1324 authenticator ports, providing that TSK freshness is guaranteed (such 1325 as by keeping replay counter state within the authenticator). 1327 In order to further limit the key scope the following measures are 1328 suggested: 1330 [a] The lower layer MAY specify additional restrictions on key usage, 1331 such as limiting the use of EAP keying material and parameters on 1332 the EAP peer to the port over which on the EAP conversation was 1333 conducted. 1335 [b] The backend authentication server and authenticator MAY implement 1336 additional attributes in order to further restrict the scope of EAP 1337 keying material. For example, in 802.11, the backend 1338 authentication server may provide the authenticator with a list of 1339 authorized Called or Calling-Station-Ids and/or SSIDs for which EAP 1340 keying material is valid. 1342 [c] Where the backend authentication server provides attributes 1343 restricting the key scope, it is RECOMMENDED that restrictions be 1344 securely communicated by the authenticator to the peer. This can 1345 be accomplished using the Secure Association Protocol, but also 1346 can be accomplished via the EAP method or the lower layer. 1348 3.3. Parent-Child Relationships 1350 When an EAP re-authentication takes place, new keying material is 1351 derived and exported by the EAP method, which eventually results in 1352 replacement of TSKs, regardless of the way they are derived (see 1353 Section 2.1). While the maximum lifetime of TSKs or child keys can 1354 be less than or equal to that of the MSK/EMSK, it cannot be greater. 1355 This is true even where exported EAP keying material is only used for 1356 entity authentication and is not used for key derivation (such as in 1357 IKEv2), so that compromise of exported EAP keying material does not 1358 imply compromise of the TSKs or child keys. However, where child 1359 keys are derived from or are wrapped by EAP keying material, 1360 compromise of the MSK/EMSK does imply compromise of the child keys. 1362 Child keys that are used frequently (such as TSKs which are used for 1363 traffic protection) can expire sooner than the exported EAP keying 1364 material they are dependent on, so that it is advantageous to support 1365 re-key of child keys prior to EAP re-authentication. Note that 1366 deletion of the MSK/EMSK does not necessarily imply deletion of TSKs 1367 or child keys. 1369 Failure to mutually prove possession of exported EAP keying material 1370 during the Secure Association Protocol exchange need not be grounds 1371 for deletion of the keying material by both parties; rate-limiting 1372 Secure Association Protocol exchanges could be used to prevent a 1373 brute force attack. 1375 3.4. Local Key Lifetimes 1377 The Transient EAP Keys (TEKs) are session keys used to protect the 1378 EAP conversation. The TEKs are internal to the EAP method and are 1379 not exported. TEKs are typically created during an EAP conversation, 1380 used until the end of the conversation and then discarded. However, 1381 methods may re-key TEKs during an EAP conversation. 1383 When using TEKs within an EAP conversation or across conversations, 1384 it is necessary to ensure that replay protection and key separation 1385 requirements are fulfilled. For instance, if a replay counter is 1386 used, TEK re-key MUST occur prior to wrapping of the counter. 1387 Similarly, TSKs MUST remain cryptographically separate from TEKs 1388 despite TEK re-keying or caching. This prevents TEK compromise from 1389 leading directly to compromise of the TSKs and vice versa. 1391 EAP methods may cache local keying material which may persist for 1392 multiple EAP conversations when fast reconnect is used [RFC 3748]. 1393 For example, EAP methods based on TLS (such as EAP-TLS [RFC2716]) 1394 derive and cache the TLS Master Secret, typically for substantial 1395 time periods. The lifetime of other local keying material calculated 1396 within the EAP method is defined by the method. Note that in 1397 general, when using fast reconnect, there is no guarantee to that the 1398 original long-term credentials are still in the possession of the 1399 peer. For instance, a card hold holding the private key for EAP-TLS 1400 may have been removed. EAP servers SHOULD also verify that the long- 1401 term credentials are still valid, such as by checking that 1402 certificate used in the original authentication has not yet expired. 1404 3.5. Exported and Calculated Key Lifetimes 1406 All EAP methods generating keys are required to generate the MSK and 1407 EMSK, and may optionally generate the IV. However, EAP, defined in 1408 [RFC3748], does not itself support the negotiation of lifetimes for 1409 exported keying material such as the MSK, EMSK and IV. 1411 Several mechanisms exist for managing key lifetimes: 1413 [a] AAA attributes. AAA protocols such as RADIUS [RFC2865] and 1414 Diameter [RFC4072] support the Session-Timeout attribute. The 1415 Session-Timeout attribute represents the maximum lifetime of the 1416 exported keying material, and all keys depending on it, on the 1417 authenticator. Since existing backend authentication servers do 1418 not cache keys exported by EAP methods, or keys calculated from 1419 exported keys, the value of the Session-Timeout attribute has no 1420 bearing on the key lifetime within the backend authentication 1421 server. 1423 On the authenticator, where EAP is used for authentication the 1424 Session-Timeout attribute represents the maximum session time prior 1425 to re-authentication. As described in [RFC3580] Section 3.17, when 1426 sent in an Access-Accept along with a Termination-Action value of 1427 RADIUS-Request, the Session-Timeout attribute specifies the maximum 1428 number of seconds of service provided prior to re-authentication. 1430 Where EAP is used for pre-authentication, the session may not start 1431 until some future time, or may never occur. Nevertheless, the 1432 Session-Timeout value represents the maximum time after which 1433 transported EAP keying material, and all keys dependent on it, will 1434 have expired on the authenticator. If the session subsequently 1435 starts, re-authentication will be initiated once the Session-Time 1436 has expired. If the session never started, or started and ended, by 1437 default keys transported by AAA and all keys dependent on them be 1438 expired by the authenticator prior to the future time indicated by 1439 Session-Timeout; this feature is utilized by [IEEE-802.11i]. Note 1440 that in future additional attributes may be specified to control 1441 the lifetime of cached keys; these attributes may modify the 1442 meaning of the Session-Timeout attribute in specific circumstances. 1444 Since the TSK lifetime is often determined by authenticator 1445 resources, and the backend authentication server has no insight 1446 into the TSK derivation process, by the principle of ciphersuite 1447 independence, it is not appropriate for the backend authentication 1448 server to manage any aspect of the TSK derivation process, 1449 including the TSK lifetime. 1451 [b] Lower layer mechanisms. While AAA attributes can communicate the 1452 maximum exported key lifetime, this only serves to synchronize the 1453 key lifetime between the backend authentication server and the 1454 authenticator. Lower layer mechanisms such as the Secure 1455 Association Protocol can then be used to enable the lifetime of 1456 exported and calculated keys to be negotiated between the peer and 1457 authenticator. 1459 Where TSKs are established as the result of a Secure Association 1460 Protocol exchange, it is RECOMMENDED that the Secure Association 1461 Protocol include support for TSK re-key. Where the TSK is taken 1462 directly from the MSK, there is no need to manage the TSK lifetime 1463 as a separate parameter, since the TSK lifetime and MSK lifetime 1464 are identical. 1466 [c] System defaults. Where the EAP method does not support the 1467 negotiation of the lifetime of exported keys, and a key lifetime 1468 negotiation mechanism is not provided by the lower lower, there may 1469 be no way for the peer to learn the lifetime of exported keys. In 1470 this case it is RECOMMENDED that the peer assume a default value; 8 1471 hours is recommended. Similarly, the lifetime of calculated keys 1472 can also be managed as a system parameter on the authenticator. 1474 [d] Method specific negotiation within EAP. While EAP itself does not 1475 support lifetime negotiation, it would be possible to specify 1476 methods that do. However, systems that rely on such negotiation 1477 for exported keys would only function with these methods. In the 1478 interest of method independence, key management of exported or 1479 derived keys SHOULD NOT be provided within EAP methods. 1481 3.6. Key cache synchronization 1483 Issues arise when attempting to synchronize the key cache on the peer 1484 and authenticator. 1486 While the AAA protocol can enable the backend authentication server 1487 to provide guidance on the lifetime of transported EAP keying 1488 material to the authenticator, this does not address the problem of 1489 key lifetime synchronization between the peer and authenticator. 1490 Where the EAP method does not negotiate the lifetime of exported 1491 keys, the lifetime of the EAP keying material may not be defined 1492 until completion of the Secure Association Protocol, if ever. This 1493 can leave the peer uncertain how long the authenticator will maintain 1494 EAP keying material within the key cache. 1496 However, key lifetime negotiation alone cannot guarantee key cache 1497 synchronization. Even where the Secure Association Protocol is run 1498 immediately after EAP and determines the lifetime of EAP keying 1499 material, it is still possible for the authenticator to reclaim 1500 resources. 1502 The lower layer may utilize the Discovery phase 0 to improve key 1503 cache synchronization. For example, if the authenticator manages the 1504 key cache by deleting the oldest key first (LIFO), the relative 1505 creation time of the last key to be deleted could be advertised 1506 within the Discovery phase, enabling the peer to determine whether 1507 keying material had been prematurely expired from the authenticator 1508 key cache. 1510 3.7. Key Strength 1512 As noted in Section 2.1, EAP lower layers determine TSKs in different 1513 ways. Where EAP keying material is utilized in the derivation, 1514 encryption or authentication of TSKs, it is possible for EAP key 1515 generation to represent the weakest link. 1517 In order to ensure that EAP methods produce keying material of an 1518 appropriate symmetric key strength, it is RECOMMENDED that EAP 1519 methods utilizing public key cryptography choose a public key that 1520 has a cryptographic strength providing the required level of attack 1521 resistance. This is typically provided by configuring EAP methods, 1522 since there is no coordination between the lower layer and EAP method 1523 with respect to minimum required symmetric key strength. 1525 As noted in [RFC3766] Section 5, this results in the following 1526 required RSA or DH module and DSA subgroup size in bits, for a given 1527 level of attack resistance in bits: 1529 Attack Resistance RSA or DH Modulus DSA subgroup 1530 (bits) size (bits) size (bits) 1531 ----------------- ----------------- ------------ 1532 70 947 128 1533 80 1228 145 1534 90 1553 153 1535 100 1926 184 1536 150 4575 279 1537 200 8719 373 1538 250 14596 475 1540 3.8. Key Wrap 1542 The key wrap specified in [RFC2548], which is based on an MD5-based 1543 stream cipher, has known problems, as described in [RFC3579] Section 1544 4.3. RADIUS uses the shared secret for multiple purposes, including 1545 per-packet authentication and attribute hiding, considerable 1546 information is exposed about the shared secret with each packet. 1547 This exposes the shared secret to dictionary attacks. MD5 is used 1548 both to compute the RADIUS Response Authenticator and the Message- 1549 Authenticator attribute, and concerns exist relating to the security 1550 of this hash [MD5Collision]. 1552 As discussed in [RFC3579] Section 4.3, the security vulnerabilities 1553 of RADIUS are extensive, and therefore development of an alternative 1554 key wrap technique based on the RADIUS shared secret would not 1555 substantially improve security. As a result, [RFC3579] Section 4.2 1556 recommends running RADIUS over IPsec. The same approach is taken in 1557 Diameter EAP [RFC4072], which defines clear-text key attributes, to 1558 be protected by IPsec or TLS. 1560 4. Handoff Vulnerabilities 1562 With EAP, several mechanisms are available to reduce the latency in 1563 handoff between authenticators: 1565 [a] EAP pre-authentication. This utilizes EAP to pre-establish EAP 1566 keying material on an authenticator prior to arrival of the peer. 1567 Use of pre-authentication within IEEE 802.11 is described in 1568 [8021XHandoff] and [IEEE-802.11i]. 1570 [b] Key caching. This mechanism enables an EAP peer to re-attach to an 1571 authenticator without requiring EAP re-authentication. 1573 [c] Context transfer, such as is defined in [IEEE-802.11F] (now 1574 deprecated) and [RFC4067]. Use of context transfer for handoff 1575 latency improvement is described in [IEEE-02-758]. 1577 [d] Proactive key distribution, such as is described in 1578 [IEEE-02-758][IEEE-03-084] and [I-D.irtf-aaaarch-handoff]. 1580 The sections that follow discuss the security vulnerabilities 1581 introduced by the above mechanisms. 1583 4.1. EAP Pre-authentication 1585 EAP pre-authentication enables an EAP peer to pre-establish EAP 1586 keying material with an authenticator prior to attaching to it. Where 1587 there is sufficient time to pre-establish keying material prior to 1588 changing the point of attachment, this may enable the peer to remove 1589 EAP authentication from the critical path for handoff, reducing 1590 latency. 1592 EAP pre-authentication exchanges typically differ from a normal EAP 1593 conversation only with respect to the lower layer encapsulation. For 1594 example, in [IEEE-802.11i], EAP pre-authentication frames are 1595 encapsulated within a distinct Ethertype, but otherwise conform to 1596 the encapsulation described in [IEEE-802.1X]. As a result, an EAP 1597 pre-authentication conversation that eventually results in 1598 establishment of security associations differs little from the model 1599 described in Section 1.3, other than the potential introduction of a 1600 delay between Phase 1 and Phase 2. However, since a peer may complete 1601 EAP pre-authentication with an authenticator without eventually 1602 attaching to it, it is possible that Phase 2 will not occur. 1604 [RFC3580] describes only minor differences in the AAA exchange 1605 occurring as a result of EAP pre-authentication as compared with an 1606 ordinary EAP authentication exchange. For example, since in 802.11i 1607 an Association exchange does not occur prior to EAP pre- 1608 authentication, the SSID is not yet known. As a result, an Access- 1609 Request generated as the result of pre-authentication cannot include 1610 the SSID within the Called-Station-Id attribute as described in 1611 [RFC3580] Section 3.20. Since a peer may never associate with an 1612 authenticator to which it pre-authenticated, an Accounting-Request 1613 signifying the start of service may never be sent, or may only be 1614 sent with a substantial delay after the completion of authentication. 1616 Since an EAP pre-authentication exchange differs from an EAP 1617 authentication exchange only in subtle ways, the backend 1618 authentication server may not be aware of whether it is engaging in a 1619 pre-authentication exchange, resulting in operational or security 1620 problems. For example, where the authenticator does not include the 1621 SSID within the Called-Station-Id attribute in ordinary requests, 1622 pre-authentication requests may appear indistinguishable. As a 1623 result, the backend authentication server may not be able to 1624 correctly calculate the simultaneous sessions in progress, either 1625 preventing successful completion of pre-authentication or enabling 1626 the peer to engage in more simultaneous sessions than they are 1627 authorized for. 1629 In order to allow backend authentication servers to handle pre- 1630 authentication requests more reliably, it is recommended that EAP 1631 pre-authentication requests be explicitly identified within AAA 1632 protocols. Also, in order to suppress unnecessary EAP pre- 1633 authentication exchanges, it is recommended that authenticators 1634 unambiguously identify themselves as described in Section 2.2.1, 1635 allowing the peer to determine whether it has previously established 1636 EAP keying material with that authenticator. 1638 4.2. Authorization 1640 In a typical network access scenario (dial-in, wireless LAN, etc.) 1641 access control mechanisms are typically applied. These mechanisms 1642 include user authentication as well as authorization for the offered 1643 service. 1645 As a part of the authentication process, the backend authentication 1646 server determines the user's authorization profile. The user 1647 authorizations are transmitted by the backend authentication server 1648 to the EAP authenticator (also known as the Network Access Server or 1649 authenticator) along with the transported EAP keying material, in 1650 Phase 1b of the EAP conversation. Typically, the profile is 1651 determined based on the user identity, but a certificate presented by 1652 the user may also provide authorization information. 1654 The backend authentication server is responsible for making a user 1655 authorization decision, which requires answering the following 1656 questions: 1658 [a] Is this a legitimate user for this particular network? 1660 [b] Is the user allowed the type of access he or she is requesting? 1662 [c] Are there any specific parameters (mandatory tunneling, bandwidth, 1663 filters, and so on) that the access network should be aware of for 1664 this user? 1666 [d] Is the user operating within the time of day subscription rules? 1668 [e] Is the user within his limits for concurrent sessions? 1670 [f] Are there any fraud, credit limit, or other concerns that indicate 1671 that access should be denied? 1673 While the authorization decision is in principle simple, the process 1674 is complicated by the distributed nature of the decision making. 1675 Where brokering entities or proxies are involved, all of the AAA 1676 entities in the chain from the authenticator to the home backend 1677 authentication server are involved in the decision. For instance, a 1678 broker can disallow access even if the home backend authentication 1679 server would allow it, or a proxy can add authorizations (e.g., 1680 bandwidth limits). 1682 Decisions can be based on static policy definitions and profiles as 1683 well as dynamic state (e.g. time of day or limits on the number of 1684 concurrent sessions). In addition to the Accept/Reject decision made 1685 by the AAA chain, parameters or constraints can be communicated to 1686 the authenticator. 1688 The criteria for Accept/Reject decisions or the reasons for choosing 1689 particular authorizations are typically not communicated to the 1690 authenticator, only the final result. As a result, the authenticator 1691 has no way to know what the decision was based on. Was a set of 1692 authorization parameters sent because this service is always provided 1693 to the user, or was the decision based on the time/day and the 1694 capabilities of the requesting authenticator device? 1696 4.3. Correctness 1698 When the AAA exchange is bypassed via use of techniques such as key 1699 caching, it can be challenging to ensure that authorization is 1700 properly handled. Challenges include: 1702 [a] Consistent application of session time limits. Bypassing AAA 1703 should not automatically increase the available session time, 1704 allowing a user to endlessly extend their network access by 1705 changing the point of attachment. 1707 [b] Avoidance of privilege elevation. Bypassing AAA should not result 1708 in a user being granted access to services which they are not 1709 entitled to. 1711 [c] Consideration of dynamic state. In situations in which dynamic 1712 state is involved in the access decision (day/time, simultaneous 1713 session limit) it should be possible to take this state into 1714 account either before or after access is granted. Note that 1715 consideration of network-wide state such as simultaneous session 1716 limits can typically only be taken into account by the backend 1717 authentication server. 1719 [d] Encoding of restrictions. Since a authenticator may not be aware 1720 of the criteria considered by a backend authentication server when 1721 allowing access, in order to ensure consistent authorization during 1722 a fast handoff it may be necessary to explicitly encode the 1723 restrictions within the authorizations provided by the backend 1724 authentication server. 1726 [e] State validity. The introduction of fast handoff should not render 1727 the authentication server incapable of keeping track of network- 1728 wide state. 1730 A handoff mechanism capable of addressing these concerns is said to 1731 be "correct". One condition for correctness is as follows: 1733 For a handoff to be "correct" it MUST establish on the new device 1734 the same context as would have been created had the new device 1735 completed a AAA conversation with the backend authentication 1736 server. 1738 A properly designed handoff scheme will only succeed if it is 1739 "correct" in this way. If a successful handoff would establish 1740 "incorrect" state, it is preferable for it to fail, in order to avoid 1741 creation of incorrect context. 1743 Some authenticator and backend authentication server configurations 1744 are incapable of meeting this definition of "correctness". For 1745 example, if the old and new device differ in their capabilities, a 1746 handoff mechanism that bypasses AAA may find it difficult to meet 1747 this definition of correctness. Backend authentication servers often 1748 perform conditional evaluation, in which the authorizations returned 1749 in an Access-Accept message are contingent on the authenticator or on 1750 dynamic state such as the time of day or number of simultaneous 1751 sessions. For example, in a heterogeneous deployment, the backend 1752 authentication server might return different authorizations depending 1753 on the authenticator making the request, in order to make sure that 1754 the requested service is consistent with the authenticator 1755 capabilities. 1757 If differences between the new and old device would result in the 1758 backend authentication server sending a different set of messages to 1759 the new device than were sent to the old device, then if the handoff 1760 mechanism bypasses AAA, the handoff cannot be carried out correctly. 1762 For example, if some authenticators support dynamic Virtual LANs 1763 (VLANs) while others do not, then attributes present in the Access- 1764 Request (such as the NAS-IP-Address, NAS-IPv6-Address, NAS- 1765 Identifier, etc.) could be examined to determine when VLAN attributes 1766 will be returned, as described in [RFC3580]. VLAN support is 1767 defined in [IEEE-802.1Q]. If a handoff bypassing the backend 1768 authentication server were to occur between a authenticator 1769 supporting dynamic VLANs and another authenticator which does not, 1770 then a guest user with access restricted to a guest VLAN could be 1771 given unrestricted access to the network. 1773 Similarly, in a network where access is restricted based on the day 1774 and time, Service Set Identifier (SSID), Calling-Station-Id or other 1775 factors, unless the restrictions are encoded within the 1776 authorizations, or a partial AAA conversation is included, then a 1777 handoff could result in the user bypassing the restrictions. 1779 In practice, these considerations limit the situations in which fast 1780 handoff mechanisms bypassing AAA can be expected to be successful. 1781 Where the deployed devices implement the same set of services, it may 1782 be possible to do successful handoffs within such mechanisms. 1783 However, where the supported services differ between devices, the 1784 handoff may not succeed. For example, [RFC2865] section 1.1 states: 1786 "A authenticator that does not implement a given service MUST NOT 1787 implement the RADIUS attributes for that service. For example, a 1788 authenticator that is unable to offer ARAP service MUST NOT 1789 implement the RADIUS attributes for ARAP. A authenticator MUST 1790 treat a RADIUS access-accept authorizing an unavailable service as 1791 an access-reject instead." 1793 Note that this behavior only applies to attributes that are known, 1794 but not implemented. For attributes that are unknown, [RFC2865] 1795 Section 5 states: 1797 "A RADIUS server MAY ignore Attributes with an unknown Type. A 1798 RADIUS client MAY ignore Attributes with an unknown Type." 1800 In order to perform a correct handoff, if a new device is provided 1801 with RADIUS context for a known but unavailable service, then it MUST 1802 process this context the same way it would handle a RADIUS Access- 1803 Accept requesting an unavailable service. This MUST cause the 1804 handoff to fail. However, if a new device is provided with RADIUS 1805 context that indicates an unknown attribute, then this attribute MAY 1806 be ignored. 1808 Although it may seem somewhat counter-intuitive, failure is indeed 1809 the "correct" result where a known but unsupported service is 1810 requested. Presumably a correctly configured backend authentication 1811 server would not request that a device carry out a service that it 1812 does not implement. This implies that if the new device were to 1813 complete a AAA conversation that it would be likely to receive 1814 different service instructions. In such a case, failure of the 1815 handoff is the desired result. This will cause the new device to go 1816 back to the backend server in order to receive the appropriate 1817 service definition. 1819 In practice, this implies that handoff mechanisms which bypass AAA 1820 are most likely to be successful within a homogeneous device 1821 deployment within a single administrative domain. For example, it 1822 would not be advisable to carry out a fast handoff bypassing AAA 1823 between a authenticator providing confidentiality and another 1824 authenticator that does not support this service. The correct result 1825 of such a handoff would be a failure, since if the handoff were 1826 blindly carried out, then the user would be moved from a secure to an 1827 insecure channel without permission from the backend authentication 1828 server. Thus the definition of a "known but unsupported service" 1829 MUST encompass requests for unavailable security services. This 1830 includes vendor-specific attributes related to security, such as 1831 those described in [RFC2548]. 1833 5. Security Considerations 1835 The EAP threat model is described in [RFC3748] Section 7.1. The 1836 security properties of EAP methods (known as "security claims") are 1837 described in [RFC3748] Section 7.2.1. EAP method requirements for 1838 applications such as Wireless LAN authentication are described in 1839 [RFC4017]. The RADIUS threat model is described in [RFC3579] Section 1840 4.1, and responses to these threats are described in [RFC3579] 1841 Sections 4.2 and 4.3. 1843 However, in addition to threats against EAP and AAA, there are other 1844 system level threats. In developing the threat model, it is assumed 1845 that: 1847 All traffic is visible to the attacker. 1848 The attacker can alter, forge or replay messages. 1849 The attacker can reroute messages to another principal. 1850 The attacker may be a principal or an outsider. 1851 The attacker can compromise any key that is sufficiently old. 1853 Threats arising from these assumptions include: 1855 [a] An attacker may compromise or steal an EAP authenticator, in an 1856 attempt to gain access to other EAP authenticators or obtain long- 1857 term secrets. 1859 [b] An attacker may try to modify or spoof packets, including Discovery 1860 or Secure Association Protocol frames, EAP or AAA packets. 1862 [c] An attacker may attempt a downgrade attack in order to exploit 1863 known weaknesses in an authentication method or cryptographic 1864 transform. 1866 [d] An attacker may attempt to induce an EAP peer, authenticator or 1867 server to disclose keying material to an unauthorized party, or 1868 utilize keying material outside the context that it was intended 1869 for. 1871 [e] An attacker may alter, forge or replay packets. 1873 [f] An attacker may cause an EAP peer, authenticator or server to reuse 1874 an stale key. Use of stale keys may also occur unintentionally. 1875 For example, a poorly implemented backend authentication server may 1876 provide stale keying material to an authenticator, or a poorly 1877 implemented authenticator may reuse nonces. 1879 [g] An authenticated attacker may attempt to obtain elevated privilege 1880 in order to access information that it does not have rights to. 1882 [h] An attacker may attempt a man-in-the-middle attack in order to gain 1883 access to the network. 1885 [i] An attacker may launch a denial of service attack against the EAP 1886 peer, authenticator or backend authentication server. 1888 [j] An attacker may compromise an EAP authenticator in an effort to 1889 commit fraud. For example, a compromised authenticator may provide 1890 incorrect information to the EAP peer and/or server via out-of-band 1891 mechanisms (such as via a AAA or lower layer protocol). This 1892 includes impersonating another authenticator, or providing 1893 inconsistent information to the peer and EAP server. 1895 In order to address these threats, [I-D.housley-aaa-key-mgmt] 1896 provides a description of mandatory system security properties. 1897 Issues relating to system security requirements are discussed in the 1898 sections that follow. 1900 5.1. Authenticator Compromise 1902 In the event that an authenticator is compromised or stolen, an 1903 attacker may gain access to the network via that authenticator, or 1904 may obtain the credentials required for that authenticator/AAA client 1905 to communicate with one or more backend authentication servers. 1906 However, this should not allow the attacker to compromise other 1907 authenticators or the backend authentication server, or obtain long- 1908 term user credentials. 1910 The implications of this requirement are many, but some of the more 1911 important are as follows: 1913 No Key Sharing 1914 An EAP authenticator MUST NOT share any keying material with 1915 another EAP authenticator, since if one EAP authenticator were 1916 compromised, this would enable the compromise of keying material on 1917 another authenticator. In order to be able to determine whether 1918 keying material has been shared, it is necessary for the identity 1919 of the EAP authenticator to be defined and understood by all 1920 parties that communicate with it. 1922 No AAA Credential Sharing 1923 AAA credentials (such as RADIUS shared secrets, IPsec pre-shared 1924 keys or certificates) MUST NOT be shared between AAA clients, since 1925 if one AAA client were compromised, this would enable an attacker 1926 to impersonate other AAA clients to the backend authentication 1927 server, or even to impersonate a backend authentication server to 1928 other AAA clients. 1930 No Compromise of Long-Term Credentials 1931 An attacker obtaining TSKs, TEKs or EAP keying material such as the 1932 MSK MUST NOT be able to obtain long-term user credentials such as 1933 pre-shared keys, passwords or private-keys without breaking a 1934 fundamental cryptographic assumption. 1936 5.2. Spoofing 1938 The use of per-packet authentication and integrity protection 1939 provides protection against spoofing attacks. Diameter [RFC3588] 1940 provides support for per-packet authentication and integrity 1941 protection via use of IPsec or TLS. RADIUS/EAP [RFC3579] provides 1942 for per-packet authentication and integrity protection via use of the 1943 Message-Authenticator attribute. 1945 [RFC3748] Section 7.2.1 describes the "integrity protection" security 1946 claim and [RFC4017] requires use of EAP methods supporting this 1947 claim. 1949 In order to prevent forgery of Secure Association Protocol frames, 1950 per-frame authentication and integrity protection is RECOMMENDED on 1951 all messages. [IEEE-802.11i] supports per-frame integrity protection 1952 and authentication on all messages within the 4-way handshake except 1953 the first message. An attack leveraging this ommission is described 1954 in [Analysis]. 1956 5.3. Downgrade Attacks 1958 The ability to negotiate the use of a particular cryptographic 1959 algorithm provides resilience against compromise of a particular 1960 cryptographic algorithm. This is usually accomplished by including 1961 an algorithm identifier in the protocol, and by specifying the 1962 algorithm requirements in the protocol specification. In order to 1963 prevent downgrade attacks, secure confirmation of the "best" 1964 ciphersuite is required. 1966 [RFC3748] Section 7.2.1 describes the "protected ciphersuite 1967 negotiation" security claim that refers to the ability of an EAP 1968 method to negotiate the ciphersuite used to protect the EAP 1969 conversation, as well as to integrity protect the negotiation. 1970 [RFC4017] requires EAP methods satisfying this security claim. 1972 Diameter [RFC3588] provides support for cryptographic algorithm 1973 negotiation via use of IPsec or TLS. RADIUS [RFC3579] does not 1974 support the negotiation of cryptographic algorithms, and relies on 1975 MD5 for integrity protection, authentication and confidentiality, 1976 despite known weaknesses in the algorithm [MD5Collision]. This issue 1977 can be addressed via use of RADIUS over IPsec, as described in 1978 [RFC3579] Section 4.2. 1980 As a result, EAP methods and AAA protocols are capable of addressing 1981 downgrade attacks. To ensure against downgrade attacks within lower 1982 layer protocols, algorithm independence is REQUIRED with lower layers 1983 using EAP for key derivation. For interoperability, at least one 1984 suite of mandatory-to-implement algorithm MUST be selected. Lower 1985 layer protocols supporting EAP for key derivation SHOULD also support 1986 secure ciphersuite negotiation. As described in [RFC1968], PPP ECP 1987 does not provide support for secure ciphersuite negotiation. 1988 However, [IEEE-802.11i] does support secure ciphersuite negotiation. 1990 5.4. Unauthorized Disclosure 1992 While preserving algorithm independence, confidentiality of all 1993 keying material MUST be maintained. To prevent unauthorized disclose 1994 of keys, each party in the EAP conversation MUST be authenticated to 1995 the other parties with whom it communicates. Keying material MUST be 1996 bound to the appropriate context. 1998 [RFC3748] Section 7.2.1 describes the "mutual authentication" and 1999 "dictionary attack resistance" claims, and [RFC4017] requires EAP 2000 methods satisfying these claims. EAP methods complying with 2001 [RFC4017] therefore provide for mutual authentication between the EAP 2002 peer and server. Within EAP, binding of EAP keying material (MSK, 2003 EMSK) to the appropriate context is provided by the Peer-Id and 2004 Server-Id which are exported along with the keying material. 2006 Diameter [RFC3588] provides for per-packet authentication and 2007 integrity protection via IPsec or TLS, and RADIUS/EAP [RFC3579] also 2008 provides for per-packet authentication and integrity protection. 2010 Where the NAS/authenticator and backend authentication server 2011 communicate directly and credible keywrap is used (see Section 3.8), 2012 this ensures that the AAA Key Transport phase achieves its security 2013 objectives: mutually authenticating the AAA client/authenticator and 2014 backend authentication server and providing EAP keying material to 2015 the EAP authenticator and to no other party. Within the AAA 2016 protocol, the authorization attributes provide the information 2017 binding the transported keying material to the appropriate context. 2018 For example, transported keying material is destined for the EAP 2019 authenticator identified by the NAS-Identifier attribute within the 2020 request, and relates to the EAP peer identified by the Peer-Id, User- 2021 Name [RFC2865] or CUI [RFC4372] attributes. 2023 [RFC2607] Section 7 describes the security issues occurring when the 2024 authenticator and backend authentication server do not communicate 2025 directly. Where an untrusted AAA intermediary is present (such as a 2026 RADIUS proxy or a Diameter agent), and data object security is not 2027 used, transported keying material may be recovered by an attacker in 2028 control of the untrusted intermediary. As discussed in Section 2.1, 2029 unless the TSKs are derived independently from EAP keying material 2030 (as in IKEv2), possession of transported keying material enables 2031 decryption of data traffic sent between the peer and a specific 2032 authenticator. However, as long as EAP keying material or keys 2033 derived from it are only utilized by a single authenticator, 2034 compromise of the transported keying material does not enable an 2035 attacker to impersonate the peer to another authenticator. 2036 Vulnerability to an untrusted AAA intermediary can be mitigated by 2037 implementation of redirect functionality, as described in [RFC3588] 2038 and [RFC4072]. 2040 As noted in Section 3.1, the Secure Association Protocol does not by 2041 itself provide for mutual authentication between the EAP peer and 2042 authenticator, even if mutual possession of EAP keying material is 2043 proven. Where the NAS/authenticator and backend authentication 2044 server communicate directly, the backend authentication server can 2045 verify the correspondence between NAS identification attributes, the 2046 source address of packets sent by the NAS, and the AAA credentials. 2047 As long as the NAS has not shared its AAA credentials with another 2048 NAS, this allows the backend authentication server to authenticate 2049 the NAS. Using Channel Bindings, the EAP peer can then determine 2050 whether the NAS/authenticator has provided the same identifying 2051 information to the EAP peer and backend authentication server. 2053 Peer and authenticator authorization MUST be performed. 2054 Authorization is REQUIRED whenever a peer associates with a new 2055 authenticator. Authorization checking prevents an elevation of 2056 privilege attack, and ensures that an unauthorized authenticator is 2057 detected. Authorizations SHOULD be synchronized between the EAP 2058 peer, server, authenticator. Once the EAP conversation exchanges are 2059 complete, all of these parties should hold the same view of the 2060 authorizations associated the other parties. If peer authorization 2061 is restricted, then the peer SHOULD be made aware of the restriction. 2063 The AAA exchange provides the EAP authenticator with authorizations 2064 relating to the EAP peer. However, neither the EAP nor AAA exchanges 2065 provides authorizations to the EAP peer. In order to ensure that all 2066 parties hold the same view of the authorizations it is RECOMMENDED 2067 that the Secure Association Protocol enable communication of 2068 authorizations between the EAP authenticator and peer. 2070 Consistently identifying the EAP authenticator enables the EAP peer 2071 to determine whether EAP keying material has been shared between EAP 2072 authenticators as well as to confirm with the backend authentication 2073 server that an EAP authenticator proving possession of EAP keying 2074 material during the Secure Association Protocol was authorized to 2075 obtain it. Identification issues are discussed in Section 2.2 and 2076 key scope issues are discussed in Section 3.2. 2078 5.5. Replay Protection 2080 Replay protection allows a protocol message recipient to discard any 2081 message that was recorded during a previous legitimate dialogue and 2082 presented as though it belonged to the current dialogue. 2084 [RFC3748] Section 7.2.1 describes the "replay protection" security 2085 claim and [RFC4017] requires use of EAP methods supporting this 2086 claim. 2088 Diameter [RFC3588] provides support for replay protection via use of 2089 IPsec or TLS. RADIUS/EAP [RFC3579] protects against replay of keying 2090 material via the Request Authenticator. However, some RADIUS packets 2091 are not replay protected. In Accounting, Disconnect and CoA-Request 2092 packets the Request Authenticator contains a keyed MAC rather than a 2093 Nonce. The Response Authenticator in Accounting, Disconnect and CoA 2094 Response packets also contains a keyed MAC whose calculation does not 2095 depend on a Nonce in either the Request or Response packets. 2096 Therefore unless an Event-Timestamp attribute is included or IPsec is 2097 used, the recipient may not be able to determine whether these 2098 packets have been replayed. 2100 In order to prevent replay of Secure Association Protocol frames, 2101 replay protection is REQUIRED on all messages. [IEEE-802.11i] 2102 supports replay protection on all messages within the 4-way 2103 handshake. 2105 5.6. Key Freshness 2107 A session key should be considered compromised if it remains in use 2108 too long. As noted in [I-D.housley-aaa-key-mgmt]], session keys MUST 2109 be strong and fresh, while preserving algorithm independence. A 2110 fresh cryptographic key is one that is generated specifically for the 2111 intended use. Each session deserves an independent session key; 2112 disclosure of one session key MUST NOT aid the attacker in 2113 discovering any other session keys. 2115 Fresh keys are required even when a long replay counter (that is, one 2116 that "will never wrap") is used to ensure that loss of state does not 2117 cause the same counter value to be used more than once with the same 2118 session key. 2120 EAP, AAA and the lower layer each bear responsibility for ensuring 2121 the use of fresh, strong session keys: 2123 EAP EAP methods need to ensure the freshness and strength of EAP keying 2124 material provided as an input to session key derivation. [RFC3748] 2125 Section 7.10 states that "EAP methods SHOULD ensure the freshness 2126 of the MSK and EMSK, even in cases where one party may not have a 2127 high quality random number generator. A RECOMMENDED method is for 2128 each party to provide a nonce of at least 128 bits, used in the 2129 derivation of the MSK and EMSK." The contribution of nonces 2130 enables the EAP peer and server to ensure that exported EAP keying 2131 material is fresh. 2133 [RFC3748] Section 7.2.1 describes the "key strength" and "session 2134 independence" security claims, and and [RFC4017] requires use of 2135 EAP methods supporting these claims as well as being capable of 2136 providing an equivalent key strength of 128 bits or greater. 2138 AAA The AAA protocol needs to ensure that transported keying material 2139 is fresh and is not utilized outside its recommended lifetime. 2140 Replay protection is necessary for key freshness, but an attacker 2141 can deliver a stale (and therefore potentially compromised) key in 2142 a replay-protected message, so replay protection is not sufficient. 2143 As discussed in Section 3.5, the Session-Timeout attribute enables 2144 the backend authentication server to limit the exposure of 2145 transported EAP keying material. 2147 The EAP Session-Id, derived from the Expanded EAP Type and the 2148 temporally unique identifier obtained from the method, enables the 2149 EAP peer, authenticator and server to distinguish EAP 2150 conversations. However, unless the authenticator keeps track of 2151 EAP Session-Ids, the authenticator cannot use the Session-Id to 2152 guarantee the freshness of EAP keying material. 2154 Lower Layer 2155 As described in Section 3.1, the lower layer Secure Association 2156 Protocol MUST generate a fresh session key for each session, even 2157 if the keying material and parameters provided by EAP methods are 2158 cached, or either the peer or authenticator lack a high entropy 2159 random number generator. A RECOMMENDED method is for the peer and 2160 authenticator to each provide a nonce or counter used in session 2161 key derivation. If a nonce is used, it is RECOMMENDED that it be 2162 at least 128 bits. 2164 5.7. Elevation of Privilege 2166 Parties MUST NOT have access to keying material that is not needed to 2167 perform their own role. A party has access to a particular key if it 2168 has access to all of the secret information needed to derive it. If 2169 a Secure Association Protocol is used to establish session keys, it 2170 MUST specify the scope for session keys. 2172 Transported EAP keying material is permitted to be accessed by the 2173 EAP peer, authenticator and server. The EAP peer and server derive 2174 the transported keying material during the process of mutually 2175 authenticating each other using the selected EAP method. During the 2176 Secure Association Protocol, the EAP peer utilizes the transported 2177 EAP keying material to demonstrate to the authenticator that it is 2178 the same party that authenticated to the EAP server and was 2179 authorized by it. The EAP authenticator utilizes the transported EAP 2180 keying material to prove to the peer not only that the EAP 2181 conversation was transported through it (this could be demonstrated 2182 by a man-in-the-middle), but that it was uniquely authorized by the 2183 EAP server to provide the peer with access to the network. Unique 2184 authorization can only be demonstrated if the EAP authenticator does 2185 not share the transported keying material with a party other than the 2186 EAP peer and server. 2188 TSKs are permitted to be accessed only by the EAP peer and 2189 authenticator (see Section 1.5). As discussed in Section 2.1, PPP 2190 and 802.11i derive the TSKs from transported EAP keying material; 2191 802.16e utilizes transported EAP keying material for TSK keywrap; 2192 IKEv2 utilizes transported EAP keying material only to authenticate 2193 the derivation of TSKs. 2195 Where demonstration of authorization depends entirely on possession 2196 of transported EAP keying material (such as in PPP, 802.11i and 2197 802.16e), this enables the backend server to masquerade as the 2198 authenticator, and possibly to obtain the TSKs unless the backend 2199 server deletes the transported EAP keying material after sending it. 2201 5.8. Man-in-the-middle Attacks 2203 As described in [I-D.puthenkulam-eap-binding], EAP method sequences 2204 and compound authentication mechanisms may be subject to man-in-the- 2205 middle attacks. When such attacks are successfully carried out, the 2206 attacker acts as an intermediary between a victim and a legitimate 2207 authenticator. This allows the attacker to authenticate successfully 2208 to the authenticator, as well as to obtain access to the network. 2210 In order to prevent these attacks, [I-D.puthenkulam-eap-binding] 2211 recommends derivation of a compound key by which the EAP peer and 2212 server can prove that they have participated in the entire EAP 2213 exchange. Since the compound key must not be known to an attacker 2214 posing as an authenticator, and yet must be derived from quantities 2215 that are exported by EAP methods, it may be desirable to derive the 2216 compound key from a portion of the EMSK. In order to provide proper 2217 key hygiene, it is recommended that the compound key used for man-in- 2218 the-middle protection be cryptographically separate from other keys 2219 derived from the EMSK. 2221 5.9. Denial of Service Attacks 2223 Key caching may result in vulnerability to denial of service attacks. 2224 For example, EAP methods that create persistent state may be 2225 vulnerable to denial of service attacks on the EAP server by a rogue 2226 EAP peer. 2228 To address this vulnerability, EAP methods creating persistent state 2229 may wish to limit the persistent state created by an EAP peer. For 2230 example, for each peer an EAP server may choose to limit persistent 2231 state to a few EAP conversations, distinguished by the EAP Session- 2232 Id. This prevents a rogue peer from denying access to other peers. 2234 Similarly, to conserve resources an authenticator may choose to limit 2235 the persistent state corresponding to each peer. This can be 2236 accomplished by limiting each peer to persistent state corresponding 2237 to a few EAP conversations, distinguished by the EAP Session-Id. 2239 Depending on the media, creation of new TSKs may or may not imply 2240 deletion of previously derived TSKs. Where there is no implied 2241 deletion, the authenticator may choose to limit the number of TSKs 2242 and associated state that can be stored for each peer. 2244 5.10. Impersonation 2246 Both the RADIUS [RFC2865] and Diameter [RFC3588] protocols are 2247 potentially vulnerable to impersonation by a rogue authenticator. 2248 While both protocols support mutual authentication between the 2249 authenticator/AAA client and the backend authentication server, the 2250 security mechanisms vary. 2252 In RADIUS, the shared secret used for authentication is determined by 2253 the source address of the RADIUS packet. As noted in [RFC3579] 2254 Section 4.3.7, it is highly desirable that the source address be 2255 checked against one or more NAS identification attributes so as to 2256 detect and prevent impersonation attacks. 2258 When RADIUS Access-Requests are forwarded by a proxy, the NAS-IP- 2259 Address or NAS-IPv6-Address attributes may not correspond to the 2260 source address. Since the NAS-Identifier attribute need not contain 2261 an FQDN, it also may not correspond to the source address, even 2262 indirectly. [RFC2865] Section 3 states: 2264 A RADIUS server MUST use the source IP address of the RADIUS 2265 UDP packet to decide which shared secret to use, so that 2266 RADIUS requests can be proxied. 2268 This implies that it is possible for a rogue authenticator to forge 2269 NAS-IP-Address, NAS-IPv6-Address or NAS-Identifier attributes within 2270 a RADIUS Access-Request in order to impersonate another 2271 authenticator. Among other things, this can result in messages (and 2272 transported keying material) being sent to the wrong authenticator. 2273 Since the rogue authenticator is authenticated by the RADIUS proxy or 2274 server purely based on the source address, other mechanisms are 2275 required to detect the forgery. In addition, it is possible for 2276 attributes such as the Called-Station-Id and Calling-Station-Id to be 2277 forged as well. 2279 [RFC3579] Section 4.3.7 describes how an EAP pass-through 2280 authenticator acting as a AAA client can be detected if it attempts 2281 to impersonate another authenticator (such by sending incorrect 2282 Called-Station-Id [RFC2865], NAS-Identifier [RFC2865], NAS-IP-Address 2283 [RFC2865] or NAS-IPv6-Address [RFC3162] attributes via the AAA 2284 protocol). This vulnerability can be mitigated by having RADIUS 2285 proxies check NAS identification attributes against the source 2286 address. 2288 While [RFC3588] requires use of the Route-Record AVP, this utilizes 2289 Fully Qualified Domain Names (FQDNs), so that impersonation detection 2290 requires DNS A, AAAA and PTR Resource Records (RRs) to be properly 2291 configured. As a result, Diameter is as vulnerable to this attack as 2292 RADIUS, if not more so. To address this vulnerability, it is 2293 necessary to allow the backend authentication server to communicate 2294 with the authenticator directly, such as via the redirect 2295 functionality supported in [RFC3588]. 2297 5.11. Channel Binding 2299 It is possible for a compromised or poorly implemented EAP 2300 authenticator to communicate incorrect information to the EAP peer 2301 and/or server. This may enable an authenticator to impersonate 2302 another authenticator or communicate incorrect information via out- 2303 of-band mechanisms (such as via AAA or the lower layer). 2305 Where EAP is used in pass-through mode, the EAP peer does not verify 2306 the identity of the pass-through authenticator. Within the Secure 2307 Association Protocol, the EAP peer and authenticator only demonstrate 2308 mutual possession of the transported EAP keying material. This 2309 creates a potential security vulnerability, described in [RFC3748] 2310 Section 7.15. 2312 As described in the previous section, it is possible for a proxy to 2313 detect a AAA client attempting to impersonate another authenticator 2314 (such by sending incorrect Called-Station-Id [RFC2865], NAS- 2315 Identifier [RFC2865], NAS-IP-Address [RFC2865] or NAS-IPv6-Address 2316 [RFC3162] attributes via the AAA protocol). However, it is possible 2317 for a pass-through authenticator acting as a AAA client to provide 2318 correct information to the backend authentication server while 2319 communicating misleading information to the EAP peer via the lower 2320 layer. 2322 For example, a compromised authenticator can utilize another 2323 authenticator's Called-Station-Id or NAS-Identifier in communicating 2324 with the EAP peer via the lower layer. Also, a pass-through 2325 authenticator acting as a AAA client can provide an incorrect peer 2326 Calling-Station-Id [RFC2865][RFC3580] to the backend authentication 2327 server via the AAA protocol. 2329 As noted in [RFC3748] Section 7.15, this vulnerability can be 2330 addressed by EAP methods that support a protected exchange of channel 2331 properties such as endpoint identifiers, including (but not limited 2332 to): Called-Station-Id [RFC2865][RFC3580], Calling-Station-Id 2333 [RFC2865][RFC3580], NAS-Identifier [RFC2865], NAS-IP-Address 2334 [RFC2865], and NAS-IPv6-Address [RFC3162]. 2336 Using such a protected exchange, it is possible to match the channel 2337 properties provided by the authenticator via out-of-band mechanisms 2338 against those exchanged within the EAP method. Typically the EAP 2339 method imports Channel Bindings from the lower layer on the peer, and 2340 transmits them securely to the EAP server, which exports them to the 2341 lower layer or AAA layer. However, transport may occur from EAP 2342 server to peer, or may be bi-directional. On the side of the 2343 exchange (peer or server) where Channel Bindings are verified, the 2344 lower layer or AAA layer passes the result of the verification (TRUE 2345 or FALSE) up to the EAP method. While the verification can be done 2346 either by the peer or the server, typically only the server has the 2347 knowledge to determine the correctness of the values, as opposed to 2348 merely verifying their equality. For further discussion, see [I- 2349 D.arkko-eap-service-identity-auth]. 2351 It is also possible to achieve Channel Bindings without transporting 2352 data over EAP. For example, see [I-D.draft-ohba-eap-channel- 2353 binding]. In this approach the EAP method includes Channel Bindings 2354 in the calculation of exported EAP keying material, making it 2355 impossible for the peer and authenticator to complete the Secure 2356 Association Protocol if there is a mismatch in the Channel Bindings. 2357 However, this approach can only be applied where EAP methods 2358 generating key material are used along with lower layers that utilize 2359 the keying material. For example, this mechanism would not enable 2360 verification of Channel Bindings on wired IEEE 802 networks using 2361 IEEE 802.1X. 2363 6. IANA Considerations 2365 This specification does not request the creation of any new parameter 2366 registries, nor does it require any other IANA assignments. 2368 7. References 2370 7.1. Normative References 2372 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2373 Requirement Levels", BCP 14, RFC 2119, March 1997. 2375 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 2376 Lefkowetz, "Extensible Authentication Protocol (EAP)", RFC 2377 3748, June 2004. 2379 7.2. Informative References 2381 [Analysis] He, C. and J. Mitchell, "Analysis of the 802.11i 4-Way 2382 Handshake", Proceedings of the 2004 ACM Workshop on 2383 Wireless Security, pp. 43-50, ISBN: 1-58113-925-X. 2385 [GKDP] Dondeti, L., Xiang, J. and S. Rowles, "GKDP: Group Key 2386 Distribution Protocol", Internet draft (work in progress), 2387 draft-ietf-msec-gkdp-01, March 2006. 2389 [GSAKMP] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP: 2390 Group Secure Association Group Management Protocol", 2391 Internet draft (work in progress), draft-ietf-msec-gsakmp- 2392 sec-10, May 2005. 2394 [He] He, C., Sundararajan, M., Datta, A. Derek, A. and J. C. 2395 Mitchell, "A Modular Correctness Proof of TLS and IEEE 2396 802.11i", ACM Conference on Computer and Communications 2397 Security (CCS '05), November, 2005. 2399 [IEEE-802.11] 2400 Institute of Electrical and Electronics Engineers, 2401 "Information technology - Telecommunications and 2402 information exchange between systems - Local and 2403 metropolitan area networks - Specific Requirements Part 11: 2404 Wireless LAN Medium Access Control (MAC) and Physical Layer 2405 (PHY) Specifications", IEEE IEEE Standard 802.11-2003, 2406 2003. 2408 [IEEE-802.1X] 2409 Institute of Electrical and Electronics Engineers, "Local 2410 and Metropolitan Area Networks: Port-Based Network Access 2411 Control", IEEE Standard 802.1X-2004, December 2004. 2413 [IEEE-802.1Q] 2414 Institute of Electrical and Electronics Engineers, "IEEE 2415 Standards for Local and Metropolitan Area Networks: Draft 2416 Standard for Virtual Bridged Local Area Networks", IEEE 2417 Standard 802.1Q/D8, January 1998. [IEEE802.11i] Institute 2418 of Electrical and Electronics Engineers, "Supplement to 2419 Standard for Telecommunications and Information Exchange 2420 Between Systems - LAN/MAN Specific Requirements - Part 11: 2421 Wireless LAN Medium Access Control (MAC) and Physical Layer 2422 (PHY) Specifications: Specification for Enhanced Security", 2423 IEEE 802.11i, July 2004. 2425 [IEEE-802.11F] 2426 Institute of Electrical and Electronics Engineers, 2427 "Recommended Practice for Multi-Vendor Access Point 2428 Interoperability via an Inter-Access Point Protocol Across 2429 Distribution Systems Supporting IEEE 802.11 Operation", 2430 IEEE 802.11F, July 2003 (now deprecated). 2432 [IEEE-802.16e] 2433 Institute of Electrical and Electronics Engineers, "IEEE 2434 Standard for Local and Metropolitan Area Networks: Part 16: 2435 Air Interface for Fixed and Mobile Broadband Wireless 2436 Access Systems: Amendment for Physical and Medium Access 2437 Control Layers for Combined Fixed and Mobile Operations in 2438 Licensed Bands" IEEE 802.16e, August 2005. 2440 [IEEE-02-758] 2441 Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, 2442 "Proactive Caching Strategies for IAPP Latency Improvement 2443 during 802.11 Handoff", IEEE 802.11 Working Group, 2444 IEEE-02-758r1-F Draft 802.11I/D5.0, November 2002. 2446 [IEEE-03-084] 2447 Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, 2448 "Proactive Key Distribution to support fast and secure 2449 roaming", IEEE 802.11 Working Group, IEEE-03-084r1-I, 2450 http://www.ieee802.org/11/Documents/DocumentHolder/ 2451 3-084.zip, January 2003. 2453 [I-D.housley-aaa-key-mgmt] 2454 Housley, R. and B. Aboba, "AAA Key Management", draft- 2455 housley-aaa-key-mgmt-02.txt, Internet draft (work in 2456 progress), March 2006. 2458 [I-D.puthenkulam-eap-binding] 2459 Puthenkulam, J., "The Compound Authentication Binding 2460 Problem", draft-puthenkulam-eap-binding-04 (work in 2461 progress), October 2003. 2463 [I-D.arkko-eap-service-identity-auth] 2464 Arkko, J. and P. Eronen, "Authenticated Service Information 2465 for the Extensible Authentication Protocol (EAP)", draft- 2466 arkko-eap-service-identity-auth-02.txt (work in progress), 2467 May 2005. 2469 [I-D.ohba-eap-channel-binding] 2470 Ohba, Y., Parthasrathy, M. and M. Yanagiya, "Channel 2471 Binding Mechanism Based on Parameter Binding in Key 2472 Derivation", draft-ohba-eap-channel-binding-00.txt (work in 2473 progress), January 2006. 2475 [I-D.irtf-aaaarch-handoff] 2476 Arbaugh, W. and B. Aboba, "Handoff Extension to RADIUS", 2477 draft-irtf-aaaarch-handoff-04.txt (work in progress), 2478 October 2003. 2480 [MD5Collision] 2481 Klima, V., "Tunnels in Hash Functions: MD5 Collisions 2482 Within a Minute", Cryptology ePrint Archive, March 2006, 2483 http://eprint.iacr.org/2006/105.pdf 2485 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 2486 RFC 1661, July 1994. 2488 [RFC1968] Meyer, G. and K. Fox, "The PPP Encryption Control Protocol 2489 (ECP)", RFC 1968, June 1996. 2491 [RFC2230] Atkinson, R., "Key Exchange Delegation Record for the DNS", 2492 RFC 2230, November 1997. 2494 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 2495 (IKE)", RFC 2409, November 1998. 2497 [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D. 2498 and R. Wheeler, "A Method for Transmitting PPP Over 2499 Ethernet (PPPoE)", RFC 2516, February 1999. 2501 [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2502 2535, March 1999. 2504 [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", 2505 RFC 2548, March 1999. 2507 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 2508 Implementation in Roaming", RFC 2607, June 1999. 2510 [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication 2511 Protocol", RFC 2716, October 1999. 2513 [RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for 2514 specifying the location of services (DNS SRV)", RFC 2782, 2515 February 2000. 2517 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. 2518 Wellington, "Secret Key Transaction Authentication for DNS 2519 (TSIG)", RFC 2845, May 2000. 2521 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 2522 Authentication Dial In User Service (RADIUS)", RFC 2865, 2523 June 2000. 2525 [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures 2526 (SIG(0)s )", RFC 2931, September 2000. 2528 [RFC3007] Wellington, B., "Simple Secure Domain Name System (DNS) 2529 Dynamic Update", RFC 3007, November 2000. 2531 [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 2532 3162, August 2001. 2534 [RFC3547] Baugher, M., Weis, B., Hardjono, T. and H. Harney, "The 2535 Group Domain of Interpretation", RFC 3547, July 2003. 2537 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 2538 Dial In User Service) Support For Extensible Authentication 2539 Protocol (EAP)", RFC 3579, September 2003. 2541 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese, 2542 "IEEE 802.1X Remote Authentication Dial In User Service 2543 (RADIUS) Usage Guidelines", RFC 3580, September 2003. 2545 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. 2546 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 2548 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public 2549 Keys Used For Exchanging Symmetric Keys", RFC 3766, April 2550 2004. 2552 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M. and K. 2553 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 2554 August 2004. 2556 [RFC4017] Stanley, D., Walker, J. and B. Aboba, "EAP Method 2557 Requirements for Wireless LANs", RFC 4017, March 2005. 2559 [RFC4067] Loughney, J., Nakhjiri, M., Perkins, C. and R. Koodli, 2560 "Context Transfer Protocol (CXTP)", RFC 4067, July 2005. 2562 [RFC4072] Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible 2563 Authentication Protocol (EAP) Application", RFC 4072, 2564 August 2005. 2566 [RFC4118] Yang, L., Zerfos, P. and E. Sadot, "Architecture Taxonomy 2567 for Control and Provisioning of Wireless Access Points 2568 (CAPWAP)", RFC 4118, June 2005. 2570 [RFC4186] Haverinen, H. and J. Salowey, "Extensible Authentication 2571 Protocol Method for Global System for Mobile Communications 2572 (GSM) Subscriber Identity Modules (EAP-SIM)", RFC 4186, 2573 January 2006. 2575 [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication 2576 Protocol Method for 3rd Generation Authentication and Key 2577 Agreement (EAP-AKA)", RFC 4187, January 2006. 2579 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 2580 4306, December 2005. 2582 [RFC4372] Adrangi, F., Lior, A., Korhonen, J. and J. Loughney, 2583 "Chargeable User Identity", RFC 4372, January 2006. 2585 [RFC4334] Housley, R. and T. Moore, "Certificate Extensions and 2586 Attributes Suporting Authenticatoin in Point-to-Point 2587 Protocol (PPP) and Wireless Local Area Neworks (WLAN)", RFC 2588 4334, February 2006. 2590 [8021XHandoff] 2591 Pack, S. and Y. Choi, "Pre-Authenticated Fast Handoff in a 2592 Public Wireless LAN Based on IEEE 802.1X Model", School of 2593 Computer Science and Engineering, Seoul National 2594 University, Seoul, Korea, 2002. 2596 Acknowledgments 2598 Thanks to Ashwin Palekar, and Tim Moore of Microsoft, Jari Arkko of 2599 Ericsson, Dorothy Stanley of Aruba Networks, Bob Moskowitz of 2600 TruSecure, Jesse Walker of Intel, Joe Salowey of Cisco and Russ 2601 Housley of Vigil Security for useful feedback. 2603 Authors' Addresses 2605 Bernard Aboba 2606 Microsoft Corporation 2607 One Microsoft Way 2608 Redmond, WA 98052 2610 EMail: bernarda@microsoft.com 2611 Phone: +1 425 706 6605 2612 Fax: +1 425 936 7329 2614 Dan Simon 2615 Microsoft Research 2616 Microsoft Corporation 2617 One Microsoft Way 2618 Redmond, WA 98052 2620 EMail: dansimon@microsoft.com 2621 Phone: +1 425 706 6711 2622 Fax: +1 425 936 7329 2624 Pasi Eronen 2625 Nokia Research Center 2626 P.O. Box 407 2627 FIN-00045 Nokia Group 2628 Finland 2630 EMail: pasi.eronen@nokia.com 2632 Henrik Levkowetz 2633 Ericsson Research 2634 Torshamsgatan 23 2635 SE-164 80 Stockholm 2636 SWEDEN 2638 Phone: +46 7 08 32 16 08 2639 EMail: henrik@levkowetz.com 2641 Appendix A - Exported Parameters in Existing Methods 2643 This Appendix specifies Session-Id, Peer-Id, Server-Id and Key- 2644 Lifetime for EAP methods that have been published prior to this 2645 specification. Future EAP method specifications MUST include a 2646 definition of the Session-Id, Peer-Id, and Server-Id (could be the 2647 empty string). 2649 EAP-Identity 2651 The EAP-Identity method is defined in [RC3748]. It does not 2652 derive keys, and therefore does not define the Session-Id. The 2653 Peer-Id exported by the Identity method is determined by the 2654 octets included within the EAP- Response/Identity. The Server-Id 2655 is the empty string (zero length). 2657 EAP-Notification 2659 The EAP-Notification method is defined in [RFC3748]. It does not 2660 derive keys and therefore does not define the Session-Id. The 2661 Peer-Id and Server-Id are the empty string (zero length). 2663 EAP-GTC 2665 The EAP-GTC method is defined in [RFC3748]. It does not derive 2666 keys and therefore does not define the Session-Id. The Peer-Id 2667 and Server-Id are the empty string. 2669 EAP-OTP 2671 The EAP-OTP method is defined in [RFC3748]. It does not derive 2672 keys and therefore does not define the Session-Id. The Peer-Id 2673 and Server-Id are the empty string. 2675 EAP-TLS 2677 EAP-TLS is defined in [RFC2716]. The EAP-TLS Session-Id is the 2678 concatenation of the EAP Type Code (0x0D) with the peer and server 2679 nonces. The Peer-Id and Server-Id are the contents of the 2680 altSubjectName in the peer and server certificates. 2682 EAP-AKA 2684 EAP-AKA is defined in [RFC4187]. The EAP-AKA Session-Id is the 2685 concatenation of the EAP Type Code (0x17) with the contents of the 2686 RAND field from the AT_RAND attribute, followed by the contents of 2687 the AUTN field in the AT_AUTN attribute. 2689 The Peer-Id is the contents of the Identity field from the 2690 AT_IDENTITY attribute, using only the Actual Identity Length 2691 octets from the beginning, however. Note that the contents are 2692 used as they are transmitted, regardless of whether the 2693 transmitted identity was a permanent, pseudonym, or fast re- 2694 authentication identity. The Server-Id is an empty string. 2696 EAP-SIM 2698 EAP-SIM is defined in [RFC4186]. The EAP-SIM Session-Id is the 2699 concatenation of the EAP Type Code (0x12) with the contents of the 2700 RAND field from the AT_RAND attribute, followed by the contents of 2701 the NONCE_MT field in the AT_NONCE_MT attribute. 2703 The Peer-Id is the contents of the Identity field from the 2704 AT_IDENTITY attribute, using only the Actual Identity Length 2705 octets from the beginning, however. Note that the contents are 2706 used as they are transmitted, regardless of whether the 2707 transmitted identity was a permanent, pseudonym, or fast re- 2708 authentication identity. The Server-Id is an empty string. 2710 Intellectual Property Statement 2712 The IETF takes no position regarding the validity or scope of any 2713 Intellectual Property Rights or other rights that might be claimed 2714 to pertain to the implementation or use of the technology 2715 described in this document or the extent to which any license 2716 under such rights might or might not be available; nor does it 2717 represent that it has made any independent effort to identify any 2718 such rights. Information on the procedures with respect to rights 2719 in RFC documents can be found in BCP 78 and BCP 79. 2721 Copies of IPR disclosures made to the IETF Secretariat and any 2722 assurances of licenses to be made available, or the result of an 2723 attempt made to obtain a general license or permission for the use 2724 of such proprietary rights by implementers or users of this 2725 specification can be obtained from the IETF on-line IPR repository 2726 at http://www.ietf.org/ipr. 2728 The IETF invites any interested party to bring to its attention 2729 any copyrights, patents or patent applications, or other 2730 proprietary rights that may cover technology that may be required 2731 to implement this standard. Please address the information to the 2732 IETF at ietf-ipr@ietf.org. 2734 Disclaimer of Validity 2736 This document and the information contained herein are provided on 2737 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 2738 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 2739 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 2740 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 2741 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 2742 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 2743 PARTICULAR PURPOSE. 2745 Copyright Statement 2747 Copyright (C) The Internet Society (2006). This document is 2748 subject to the rights, licenses and restrictions contained in BCP 2749 78, and except as set forth therein, the authors retain all their 2750 rights. 2752 Acknowledgment 2754 Funding for the RFC Editor function is currently provided by the 2755 Internet Society. 2757 Open Issues 2759 Open issues relating to this specification are tracked on the 2760 following web site: 2762 http://www.drizzle.com/~aboba/EAP/