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