idnits 2.17.1 draft-ietf-eap-keying-16.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2836. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2813. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2820. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2826. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 60 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 61 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC3748]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'IEEE-802.11i' is mentioned on line 2162, but not defined == Missing Reference: 'IEEE802.11i' is mentioned on line 2477, but not defined == Unused Reference: 'I-D.arkko-eap-service-identity-auth' is defined on line 2523, but no explicit reference was found in the text == Unused Reference: 'I-D.ohba-eap-channel-binding' is defined on line 2529, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-housley-aaa-key-mgmt-06 == Outdated reference: A later version (-04) exists of draft-arkko-eap-service-identity-auth-02 == Outdated reference: A later version (-02) exists of draft-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 4005 (Obsoleted by RFC 7155) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) Summary: 2 errors (**), 0 flaws (~~), 11 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 EAP Working Group Bernard Aboba 3 INTERNET-DRAFT Dan Simon 4 Category: Standards Track Microsoft 5 P. Eronen 6 2 January 2007 Nokia 7 H. Levkowetz 8 Ericsson Research 10 Extensible Authentication Protocol (EAP) Key Management Framework 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on July 10, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). All rights reserved. 39 Abstract 41 The Extensible Authentication Protocol (EAP), defined in [RFC3748], 42 enables extensible network access authentication. This document 43 provides a framework for the transport and usage of keying material 44 generated by EAP authentication algorithms, known as "methods". It 45 also specifies the EAP key hierarchy. 47 Table of Contents 49 1. Introduction .......................................... 3 50 1.1 Requirements Language ........................... 3 51 1.2 Terminology ..................................... 3 52 1.3 Overview ........................................ 6 53 1.4 EAP Key Hierarchy ............................... 9 54 1.5 Security Goals .................................. 13 55 1.6 EAP Invariants .................................. 14 56 2. Lower Layer Operation ................................. 17 57 2.1 Transient Session Keys .......................... 18 58 2.2 Authenticator and Peer Architecture ............. 19 59 2.3 Server Identification ........................... 24 60 3. Key Management ........................................ 26 61 3.1 Secure Association Protocol ..................... 26 62 3.2 Key Scope ....................................... 29 63 3.3 Parent-Child Relationships ...................... 30 64 3.4 Local Key Lifetimes ............................. 30 65 3.5 Exported and Calculated Key Lifetimes ........... 31 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 ............................... 43 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 ................................... 49 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 .............................. 60 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], [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 (known as 525 the Method-Id). Where expanded EAP Type Codes are used, the EAP 526 Session-Id consists of the Expanded Type Code (including the Type, 527 Vendor-Id and Vendor-Type fields defined in [RFC3748] Section 5.7) 528 concatenated with a temporally unique identifier obtained from the 529 method (Method-Id). This unique identifier is typically 530 constructed from nonces or counters used within the EAP method 531 exchange. The inclusion of the Type Code in the EAP Session-Id 532 ensures that each EAP method has a distinct Session-Id space. 533 Since an EAP session is not bound to a particular authenticator or 534 specific ports on the peer and authenticator, the authenticator 535 port or identity are not 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 The backend authentication server is trusted to only transport EAP 601 keying material to the authenticator that was established with the 602 peer, and it is trusted to transport that EAP keying material to no 603 other parties. In many systems, EAP keying material established by 604 the EAP peer and EAP server are combined with publicly available data 605 to derive other keys. The backend authentication server is trusted 606 to refrain from deriving these same keys or acting as a man-in-the- 607 middle even though it has access to the EAP keying material that is 608 needed to do so. The authenticator is also a trusted party. It is 609 trusted not to provide EAP keying material it obtains from the 610 backend authentication server to any other parties. 612 Completion of the Secure Association Protocol (Phase 2) results in 613 the derivation or transport of Transient Session Keys (TSKs) known 614 only to the EAP peer (identified by the Peer-Id) and authenticator 615 (identified by the NAS-Identifier). Both the EAP peer and 616 authenticator know the TSKs to be fresh. Both the EAP peer and 617 authenticator demonstrate that they are authorized to perform their 618 roles. Authorization issues are discussed in Section 5.7 and 5.8; 619 security properties of Secure Association Protocols are discussed in 620 Section 3.1. 622 1.6. EAP Invariants 624 Certain basic characteristics, known as "EAP Invariants", hold true 625 for EAP implementations on all media: 627 Mode independence 628 Media independence 629 Method independence 630 Ciphersuite independence 632 1.6.1. Mode Independence 634 EAP is typically deployed to support extensible network access 635 authentication in situations where a peer desires network access via 636 one or more authenticators. Where authenticators are deployed 637 standalone, the EAP conversation occurs between the peer and 638 authenticator, and the authenticator must locally implement an EAP 639 method acceptable to the peer. However, when utilized in "pass- 640 through" mode, EAP enables deployment of new authentication methods 641 without requiring development of new code on the authenticator. 643 While the authenticator may implement some EAP methods locally and 644 use those methods to authenticate local users, it may at the same 645 time act as a pass-through for other users and methods, forwarding 646 EAP packets back and forth between the backend authentication server 647 and the peer. This is accomplished by encapsulating EAP packets 648 within the Authentication, Authorization and Accounting (AAA) 649 protocol, spoken between the authenticator and backend authentication 650 server. AAA protocols supporting EAP include RADIUS [RFC3579] and 651 Diameter [RFC4072]. 653 It is a fundamental property of EAP that at the EAP method layer, the 654 conversation between the EAP peer and server is unaffected by whether 655 the EAP authenticator is operating in "pass-through" mode. EAP 656 methods operate identically in all aspects, including key derivation 657 and parameter import/export, regardless of whether the authenticator 658 is operating as a pass-through or not. 660 The successful completion of an EAP method that supports key 661 derivation results in the export of keying material and parameters on 662 the EAP peer and server. Even though the EAP peer or server may 663 import Channel Bindings that may include the identity of the EAP 664 authenticator, this information is treated as opaque octets. As a 665 result, within EAP the only relevant identities are the Peer-Id and 666 Server-Id. Channel Bindings are only interpreted by the lower layer. 668 Within EAP, the primary function of the AAA protocol is to maintain 669 the principle of Mode Independence, so that as far as the EAP peer is 670 concerned, its conversation with the EAP authenticator, and all 671 consequences of that conversation, are identical, regardless of the 672 authenticator mode of operation. 674 1.6.2. Media Independence 676 One of the goals of EAP is to allow EAP methods to function on any 677 lower layer meeting the criteria outlined in [RFC3748], Section 3.1. 678 For example, as described in [RFC3748], EAP authentication can be run 679 over PPP [RFC1661], IEEE 802 wired networks [IEEE-802.1X], and 680 wireless networks such as 802.11 [IEEE-802.11i] and 802.16 681 [IEEE-802.16e]. 683 In order to maintain media independence, it is necessary for EAP to 684 avoid consideration of media-specific elements. For example, EAP 685 methods cannot be assumed to have knowledge of the lower layer over 686 which they are transported, and cannot be restricted to identifiers 687 associated with a particular usage environment (e.g. MAC addresses). 689 Note that media independence may be retained within EAP methods that 690 support Channel Bindings or method-specific identification. An EAP 691 method need not be aware of the content of an identifier in order to 692 use it. This enables an EAP method to use media-specific identifiers 693 such as MAC addresses without compromising media independence. 694 Channel Bindings are treated as opaque octets by EAP methods, so that 695 handling them does not require media-specific knowledge. 697 1.6.3. Method Independence 699 By enabling pass-through, authenticators can support any method 700 implemented on the peer and server, not just locally implemented 701 methods. This allows the authenticator to avoid implementing code 702 for each EAP method required by peers. In fact, since a pass-through 703 authenticator is not required to implement any EAP methods at all, it 704 cannot be assumed to support any EAP method-specific code. 706 As a result, as noted in [RFC3748], authenticators must by default be 707 capable of supporting any EAP method. This is useful where there is 708 no single EAP method that is both mandatory-to-implement and offers 709 acceptable security for the media in use. For example, the [RFC3748] 710 mandatory-to-implement EAP method (MD5-Challenge) does not provide 711 dictionary attack resistance, mutual authentication or key 712 derivation, and as a result is not appropriate for use in wireless 713 LAN authentication [RFC4017]. However, despite this it is possible 714 for the peer and authenticator to interoperate as long as a suitable 715 EAP method is supported on the EAP server. 717 1.6.4. Ciphersuite Independence 719 Ciphersuite Independence is a requirement for Media Independence. 720 Since lower layer ciphersuites vary between media, media independence 721 requires that EAP keying material needs to be large enough (with 722 sufficient entropy) to handle any ciphersuite. 724 While EAP methods may negotiate the ciphersuite used in protection of 725 the EAP conversation, the ciphersuite used for the protection of the 726 data exchanged after EAP authentication has completed is negotiated 727 between the peer and authenticator within the lower layer, outside of 728 EAP. 730 For example, within PPP, the ciphersuite is negotiated within the 731 Encryption Control Protocol (ECP) defined in [RFC1968], after EAP 732 authentication is completed. Within [IEEE-802.11i], the AP 733 ciphersuites are advertised in the Beacon and Probe Responses prior 734 to EAP authentication, and are securely verified during a 4-way 735 handshake exchange. 737 Since the ciphersuites used to protect data depend on the lower 738 layer, requiring EAP methods have knowledge of lower layer 739 ciphersuites would compromise the principle of Media Independence. 740 Since ciphersuite negotiation occurs in the lower layer, there is no 741 need for lower layer ciphersuite negotiation within EAP, and EAP 742 methods generate keying material that is ciphersuite-independent. 744 In order to allow a ciphersuite to be usable within the EAP keying 745 framework, a specification MUST be provided describing how TSKs 746 suitable for use with the ciphersuite are derived from exported EAP 747 keying parameters. To maintain Method Independence, algorithms for 748 deriving TSKs MUST NOT depend on the EAP method, although algorithms 749 for TEK derivation MAY be specific to the EAP method. 751 Advantages of ciphersuite-independence include: 753 Reduced update requirements 754 If EAP methods were to specify how to derive transient session keys 755 for each ciphersuite, they would need to be updated each time a new 756 ciphersuite is developed. In addition, backend authentication 757 servers might not be usable with all EAP-capable authenticators, 758 since the backend authentication server would also need to be 759 updated each time support for a new ciphersuite is added to the 760 authenticator. 762 Reduced EAP method complexity 763 Requiring each EAP method to include ciphersuite-specific code for 764 transient session key derivation would increase method complexity 765 and result in duplicated effort. 767 Simplified configuration 768 The ciphersuite is negotiated between the peer and authenticator 769 outside of EAP. Where the authenticator operates in "pass-through" 770 mode, the EAP server is not a party to this negotiation, nor is it 771 involved in the data flow between the EAP peer and authenticator. 772 As a result, the EAP server may not have knowledge of the 773 ciphersuites and negotiation policies implemented by the peer and 774 authenticator, or be aware of the ciphersuite negotiated between 775 them. For example, since ECP negotiation occurs after 776 authentication, when run over PPP, the EAP peer and server may not 777 anticipate the negotiated ciphersuite and therefore this 778 information cannot be provided to the EAP method. 780 2. Lower Layer Operation 782 On completion of EAP authentication, keying material and material and 783 parameters exported by the EAP method are provided to the lower layer 784 and AAA layer (if present). These include the Master Session Key 785 (MSK), Extended Master Session Key (EMSK), Peer-Id, Server-Id and 786 Session-Id. The Initialization Vector (IV) is deprecated. 788 In order to preserve the security of keys derived within EAP methods, 789 lower layers MUST NOT export keys passed down by EAP methods. This 790 implies that EAP keying material passed down to a lower layer is for 791 the exclusive use of that lower layer and MUST NOT be used within 792 another lower layer. This prevents compromise of one lower layer 793 from compromising other applications using EAP keying parameters. 795 EAP keying material provided to a lower layer MUST NOT be transported 796 to another entity. For example, EAP keying material passed down to 797 the EAP peer lower layer MUST NOT leave the peer; EAP keying 798 material passed down or transported to the EAP authenticator lower 799 layer MUST NOT leave the authenticator. 801 On the EAP server, keying material and parameters requested by and 802 passed down to the AAA layer may be replicated to the AAA layer on 803 the authenticator (with the exception of the EMSK). On the 804 authenticator, the AAA layer provides the replicated keying material 805 and parameters to the lower layer over which the EAP authentication 806 conversation took place. This enables "mode independence" to be 807 maintained. 809 The EAP layer as well as the peer and authenticator layers MUST NOT 810 modify or cache keying material or parameters (including Channel 811 Bindings) passing in either direction between the EAP method layer 812 and the lower layer or AAA layer. 814 2.1. Transient Session Keys 816 Where explicitly supported by the lower layer, lower layers MAY cache 817 the exported EAP keying material and parameters and/or TSKs. The 818 structure of this key cache is defined by the lower layer. So as to 819 enable interoperability, new lower layer specifications MUST describe 820 EAP key caching behavior. Unless explicitly specified by the lower 821 layer, the EAP peer, server and authenticator MUST assume that peers 822 and authenticators do not cache exported EAP keying parameters or 823 TSKs. Existing EAP lower layers and AAA layers handle the caching of 824 EAP keying material and the generation of transient session keys in 825 different ways: 827 IEEE 802.1X-2004 828 IEEE 802.1X-2004, defined in [IEEE-802.1X] does not support caching 829 of EAP keying material or parameters. Once EAP authentication 830 completes, it is assumed that EAP keying material and parameters 831 are discarded. 833 PPP PPP, defined in [RFC1661] does not support caching of EAP keying 834 material or parameters. PPP ciphersuites derive their TSKs 835 directly from the MSK, as described in [RFC2716]. This method is 836 NOT RECOMMENDED, since if PPP were to support caching, this could 837 result in TSK reuse. As a result, once the PPP session is 838 terminated, EAP keying material and parameters MUST be discarded. 839 Since caching of EAP keying material is not permitted, within PPP 840 there is no way to handle TSK re-key without EAP re-authentication. 841 Perfect Forward Secrecy (PFS) is only possible if the negotiated 842 EAP method supports this. 844 IKEv2 845 IKEv2, defined in [RFC4306] only uses the MSK for authentication 846 purposes and not key derivation. The EMSK, IV, Peer-Id, Server-Id 847 or Session-Id are not used. As a result, the keying material 848 derived within IKEv2 is independent of the EAP keying material and 849 re-key of IPsec SAs can be handled without requiring EAP re- 850 authentication. Since generation of keying material is independent 851 of EAP, within IKEv2 it is possible to negotiate PFS, regardless of 852 the EAP method that is used. IKEv2 as specified in [RFC4306] does 853 not cache EAP keying material or parameters; once IKEv2 854 authentication completes it is assumed that EAP keying material and 855 parameters are discarded. The Session-Timeout attribute is 856 therefore interpreted as a limit on the VPN session time, rather 857 than an indication of the MSK key lifetime. 859 IEEE 802.11i 860 IEEE 802.11i enables caching of the MSK, but not the EMSK, IV, 861 Peer-Id, Server-Id, or Session-Id. More details about the 862 structure of the cache are available in [IEEE-802.11i]. In IEEE 863 802.11i, TSKs are derived from the MSK using the 4-way handshake, 864 which includes a nonce exchange. This guarantees TSK freshness 865 even if the MSK is reused. The 4-way handshake also enables TSK 866 re-key without EAP re-authentication. PFS is only possible within 867 IEEE 802.11i if caching is not enabled and the negotiated EAP 868 method supports PFS. 870 IEEE 802.16e 871 IEEE 802.16e, defined in [IEEE-802.16e] supports caching of the 872 MSK, but not the EMSK, IV, Peer-Id, Server-Id or Session-Id. In 873 IEEE 802.16e, TSKs are generated by the authenticator without any 874 contribution by the peer. The TSKs are encrypted, authenticated 875 and integrity protected using the MSK. As a result, TSK re-key is 876 possible without EAP re-authentication. PFS is not possible even 877 if the negotiated EAP method supports it. 879 AAA Existing implementations of RADIUS/EAP [RFC3579] or Diameter EAP 880 [RFC4072] do not support caching of EAP keying material or 881 parameters. In existing AAA client, proxy and server 882 implementations, exported EAP keying material (MSK, EMSK and IV) as 883 well as parameters and derived keys are not cached and MUST be 884 presumed lost after the AAA exchange completes. 886 In order to avoid key reuse, the AAA layer MUST delete transported 887 keys once they are sent. The AAA layer MUST NOT retain keys that 888 it has previously sent. For example, a AAA layer that has 889 transported the MSK MUST delete it, and keys MUST NOT be derived 890 from the MSK from that point forward. 892 2.2. Authenticator and Peer Architecture 894 This specification does not impose constraints on the architecture of 895 the EAP authenticator or peer. Any of the authenticator architectures 896 described in [RFC4118] can be used. As a result, lower layers need to 897 identify EAP peers and authenticators unambiguously, without 898 incorporating implicit assumptions about peer and authenticator 899 architectures. 901 For example, it is possible for multiple base stations and a 902 "controller" (e.g. WLAN switch) to comprise a single EAP 903 authenticator. In such a situation, the "base station identity" is 904 irrelevant to the EAP method conversation, except perhaps as an 905 opaque blob to be used in Channel Bindings. Many base stations can 906 share the same authenticator identity. It should be understood that 907 an EAP authenticator or peer: 909 [a] may contain one or more physical or logical ports; 911 [b] may advertise itself as one or more "virtual" 912 authenticators or peers; 913 [c] may utilize multiple CPUs; 914 [d] may support clustering services for load balancing or failover. 916 Both the EAP peer and authenticator may have more than one physical 917 or logical port. A peer may simultaneously access the network via 918 multiple authenticators, or via multiple physical or logical ports on 919 a given authenticator. Similarly, an authenticator may offer network 920 access to multiple peers, each via a separate physical or logical 921 port. When a single physical authenticator advertises itself as 922 multiple "virtual authenticators", it is possible for a single 923 physical port to belong to multiple "virtual authenticators". 925 An authenticator may be configured to communicate with more than one 926 EAP server, each of which is configured to communicate with a subset 927 of the authenticators. The situation is illustrated in Figure 3. 929 2.2.1. Authenticator and Peer Identification 931 The EAP method conversation is between the EAP peer and server. The 932 authenticator identity, if considered at all by the EAP method, is 933 treated as an opaque blob for the purposes of Channel Bindings (see 934 Section 5.12). However, the authenticator identity is important in 935 two other exchanges - the AAA protocol exchange and the Secure 936 Association Protocol conversation. 938 The AAA conversation is between the EAP authenticator and the backend 939 authentication server. From the point of view of the backend 940 authentication server, EAP keying material and parameters are 941 transported to the EAP authenticator identified by the NAS-Identifier 942 attribute. Since an EAP authenticator MUST NOT share EAP keying 943 material or parameters with another party, if the EAP peer or backend 944 authentication server detects use of EAP keying material and 945 parameters outside the scope defined by the NAS-Identifier, the 946 keying material MUST be considered compromised. 948 The Secure Association Protocol conversation is between the peer and 949 the authenticator. For lower layers which support key caching it is 950 particularly important for the EAP peer, authenticator and backend 951 server to have a consistent view of the usage scope of the 952 transported EAP keying material. In order to enable this, it is 953 RECOMMENDED that the Secure Association Protocol explicitly 954 communicate the usage scope of the EAP keying material passed down to 955 the lower layer, rather than implicitly assuming that this is defined 956 by the authenticator and peer endpoint addresses. 958 Since an authenticator may have multiple ports, the scope of the 959 authenticator key cache may not be described by a single endpoint 960 address. Similarly, where a peer may have multiple ports and sharing 961 of EAP keying material and parameters between peer ports of the same 962 link type is allowed, the extent of the peer key cache cannot be 963 communicated by using a single endpoint address. Instead, it is 964 RECOMMENDED that the EAP peer and authenticator consistently identify 965 themselves utilizing explicit identifiers, rather than endpoint 966 addresses or port identifiers. 968 AAA protocols such as RADIUS [RFC3579] and Diameter [RFC4072] provide 969 a mechanism for the identification of AAA clients; since the EAP 970 authenticator and AAA client are always co-resident, this mechanism 971 is applicable to the identification of EAP authenticators. 973 +-+-+-+-+ 974 | EAP | 975 | Peer | 976 +-+-+-+-+ 977 | | | Peer Ports 978 / | \ 979 / | \ 980 / | \ 981 / | \ 982 / | \ 983 / | \ 984 / | \ 985 / | \ Authenticator 986 | | | | | | | | | Ports 987 +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ 988 | | | | | | 989 | Auth1 | | Auth2 | | Auth3 | 990 | | | | | | 991 +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ 992 \ | \ | 993 \ | \ | 994 \ | \ | 995 EAP over AAA \ | \ | 996 (optional) \ | \ | 997 \ | \ | 998 \ | \ | 999 \ | \ | 1000 +-+-+-+-+-+ +-+-+-+-+-+ Backend 1001 | EAP | | EAP | Authentication 1002 | Server1 | | Server2 | Servers 1003 +-+-+-+-+-+ +-+-+-+-+-+ 1005 Figure 3: Relationship between EAP peer, authenticator and server 1006 RADIUS [RFC2865] requires that an Access-Request packet contain one 1007 or more of the NAS-Identifier, NAS-IP-Address and NAS-IPv6-Address 1008 attributes. Since a NAS may have more than one IP address, the NAS- 1009 Identifier attribute is RECOMMENDED for explicit identification of 1010 the authenticator, both within the AAA protocol exchange and the 1011 Secure Association Protocol conversation. 1013 Problems which may arise where the peer and authenticator implicitly 1014 identify themselves using endpoint addresses include the following: 1016 [a] It may not be obvious to the peer which authenticator ports are 1017 associated with which authenticators. The EAP peer will be unable 1018 to determine whether EAP keying material has been shared outside 1019 its authorized scope, and needs to be considered compromised. The 1020 EAP peer may also be unable to utilize the authenticator key cache 1021 in an efficient way. 1023 [b] It may not be obvious to the authenticator which peer ports are 1024 associated with which peers. As a result, the authenticator may 1025 not be able to enable a peer to communicate with it utilizing 1026 multiple peer ports. 1028 [c] It may not be obvious to the peer which "virtual authenticator" it 1029 is communicating with. For example, multiple "virtual 1030 authenticators" may share a MAC address, but utilize different NAS- 1031 Identifiers. 1033 [d] It may not be obvious to the authenticator which "virtual peer" it 1034 is communicating with. Multiple "virtual peers" may share a MAC 1035 address, but utilize different Peer-Ids. 1037 [e] It may not be possible for the EAP peer and server to verify the 1038 authenticator identity via channel bindings. 1040 For example, problems [a], [c] and [e] occur in [IEEE-802.11i], which 1041 utilizes peer and authenticator MAC addresses within the 4-way 1042 handshake. Problems [b] and [d] do not occur since [IEEE-802.11i] 1043 only allows a peer to utilize a single port. 1045 The following steps enable lower layer identities to be securely 1046 verified by all parties: 1048 [f] Specifying the lower layer parameters used to identify the 1049 authenticator and peer. As noted earlier, endpoint or port 1050 identifiers are not recommended for identification of the 1051 authenticator or peer when it is possible for them to have multiple 1052 ports. 1054 [g] Communicating the lower layer identities between the peer and 1055 authenticator within phase 0. This allows the peer and 1056 authenticator to determine the key scope if a key cache is 1057 utilized. 1059 [h] Communicating the lower layer authenticator identity between the 1060 authenticator and backend server within the NAS-Identifier 1061 attribute. 1063 [i] Including the lower layer identities within Channel Bindings (if 1064 supported) in phase 1a, ensuring that they are communicated between 1065 the EAP peer and server. 1067 [j] Supporting the integrity-protected exchange of identities within 1068 phase 2a. 1070 [k] Utilizing the advertised lower layer identities to enable the peer 1071 and authenticator to verify that keys are maintained within the 1072 advertised scope. 1074 2.2.2. Virtual Authenticators 1076 When a single physical authenticator advertises itself as multiple 1077 "virtual authenticators", if the virtual authenticators do not 1078 maintain logically separate key caches, then by authenticating to one 1079 virtual authenticator, the peer can gain access to the other virtual 1080 authenticators sharing a key cache. 1082 For example, where a physical authenticator implements "Guest" and 1083 "Corporate Intranet" virtual authenticators, an attacker acting as a 1084 peer could authenticate with the "Guest" "virtual authenticator" and 1085 derive EAP keying material. If the "Guest" and "Corporate Intranet" 1086 virtual authenticators share a key cache, then the peer can utilize 1087 the EAP keying material derived for the "Guest" network to obtain 1088 access to the "Corporate Intranet" network. 1090 In order to address this vulnerability: 1092 [a] Authenticators are REQUIRED to cache associated authorizations 1093 along with EAP keying material and parameters and to apply 1094 authorizations consistently. This ensures that an attacker cannot 1095 obtain elevated privileges even where the key cache is shared 1096 between "virtual authenticators". 1098 [b] It is RECOMMENDED that physical authenticators maintain separate 1099 key caches for each "virtual authenticator". 1101 [c] It is RECOMMENDED that each "virtual authenticator" identify itself 1102 consistently to the peer and to the backend authentication server, 1103 so as to enable the peer to verify the authenticator identity via 1104 Channel Bindings (see Section 5.11). 1106 [d] It is RECOMMENDED that each "virtual authenticator" identify itself 1107 distinctly, in order to enable the peer and backend server to tell 1108 them apart. For example, this can be accomplished by utilizing a 1109 distinct NAS-Identifier attribute or BSSID. 1111 2.3. Server Identification 1113 The EAP method conversation is between the EAP peer and server, as 1114 identified by the Peer-Id and Server-Id. As shown in Figure 3, an 1115 authenticator may be configured to communicate with multiple EAP 1116 servers; the EAP server that an authenticator communicates with may 1117 vary according to configuration and network and server availability. 1118 While the EAP peer can assume that all EAP servers within a realm 1119 have access to the credentials necessary to validate an 1120 authentication attempt, it cannot assume that all EAP servers share 1121 persistent state. 1123 Authenticators may be configured with different primary or secondary 1124 EAP servers, in order to balance the load. Also, the authenticator 1125 can dynamically determine the EAP server to which requests will be 1126 sent; in event of a communication failure, the authenticator may fail 1127 over to another EAP server. For example, in Figure 3, Authenticator2 1128 may be initially configured with EAP server1 as its primary backend 1129 authentication server, and EAP server2 as the backup, but if EAP 1130 server1 becomes unavailable, EAP server2 may become the primary 1131 server. 1133 In general, the EAP peer cannot direct an authentication attempt to a 1134 particular EAP server within a realm; this decision is made solely by 1135 the authenticator. Nor can it determine which EAP server it will be 1136 communicating with, prior to the start of the EAP method 1137 conversation. The Server-Id is not included in the EAP- 1138 Request/Identity, and since the authenticator determines the EAP 1139 server dynamically, it typically is not possible for the 1140 authenticator to advertise the Server-Id during the discovery phase. 1141 EAP methods may or may not export the Server-Id, and as a result, the 1142 EAP peer may not even learn which server it was conversing with after 1143 the EAP conversation completes successfully. 1145 As a result, an EAP peer, on connecting to a new authenticator or 1146 reconnecting to the same authenticator, may find itself communicating 1147 with a different EAP server. Fast reconnect, defined in [RFC3748] 1148 Section 7.2, may fail if the EAP server that the peer communicates 1149 with is not the same one with which it initially established a 1150 security association. For example, an EAP peer attempting an EAP-TLS 1151 session resume may find that the new EAP-TLS server will not have 1152 access to the TLS Master Key identified by the TLS Session-Id, and 1153 therefore the session resumption attempt will fail, requiring 1154 completion of a full EAP-TLS exchange. 1156 EAP methods that support mutual authentication may not allow the EAP 1157 peer to verify the EAP server identity. For example, the EAP peer 1158 may only verify that the EAP server possesses a long-term secret; in 1159 this case the EAP peer will only know that an authenticator has been 1160 authorized by an EAP server, but will not confirm the identity of the 1161 EAP server. 1163 EAP methods that export the Server-Id MUST verify the server 1164 identity. As noted in Appendix A, existing EAP methods exporting the 1165 Server-Id determine this from the altSubjectName in the server 1166 certificate, and as a result, the peer determines the identity of the 1167 server (expressed as a Fully Qualified Domain Name (FQDN)) by 1168 validating the server certificate. 1170 Validating the EAP server identity may help the EAP peer to decide 1171 whether a specific EAP server is authorized, and to determine whether 1172 the EAP server is sharing keying material outside the intended scope. 1173 In some cases, such as where the certificate extensions defined in 1174 [RFC4334] are included in the server certificate, it may even be 1175 possible for the peer to verify some Channel Binding parameters from 1176 the server certificate. Where the EAP peer does not verify the EAP 1177 server identity, it is not possible for the peer to determine whether 1178 the EAP server has shared keying material outside its authorized 1179 scope. 1181 It is possible for problems to arise in situations where the EAP 1182 server identifies itself differently to the EAP peer and 1183 authenticator. For example, the Server-Id exported by EAP methods 1184 may not be identical to the Fully Qualified Domain Name (FQDN) of the 1185 backend authentication server. Where certificate-based 1186 authentication is used within RADIUS or Diameter, the altSubjectName 1187 used in the backend server certificate may not be identical to the 1188 Server-Id or backend server FQDN. 1190 Where the backend server FQDN differs from the altSubjectName in the 1191 certificate, the AAA client may not be able to successfully determine 1192 whether it is talking to the correct backend authentication server. 1193 Where the Server-Id and backend server FQDN differ, the combination 1194 of the key scope (Peer-Id, Server-Id) and EAP conversation identifier 1195 (Session-Id) may not be sufficient for the authenticator to determine 1196 where the key resides. For example, the authenticator may identify 1197 backend servers by their IP address (as occurs in RADIUS), or using a 1198 Fully Qualified Domain Name (as in Diameter). If the Server-Id does 1199 not correspond to the IP address or FQDN of a known backend 1200 authentication server, then the authenticator will not know which 1201 backend authentication server possesses the key. 1203 3. Key Management 1205 EAP as defined in [RFC3748] supports key derivation, but does not 1206 provide for the management of exported or derived keys. Missing 1207 functionality includes: 1209 [a] Re-key. EAP does not support re-key of exported keys without EAP 1210 re-authentication, although EAP methods may support "fast 1211 reconnect" as defined in [RFC3748] Section 7.2.1. 1213 [b] Key delete/install semantics. EAP does not synchronize 1214 installation or deletion of keying material on the EAP peer and 1215 authenticator. 1217 [c] Lifetime negotiation. EAP does not support lifetime negotiation 1218 for exported keys, and existing EAP methods also do not support key 1219 lifetime negotiation. 1221 [d] Cryptographic algorithm negotiation. EAP methods only negotiate 1222 cryptographic algorithms for their own use, not for the underlying 1223 lower layers. 1225 [e] Guaranteed TSK freshness. Without a post-EAP handshake, TSKs can 1226 be reused if EAP keying material is cached. 1228 These deficiencies are typically addressed via a post-EAP handshake 1229 known as the Secure Association Protocol. 1231 3.1. Secure Association Protocol 1233 Since neither EAP nor EAP methods provide key management support, it 1234 is RECOMMENDED that key management facilities be provided within the 1235 Secure Association Protocol. This includes: 1237 [a] Entity Naming. A basic feature of a Secure Association Protocol is 1238 the explicit naming of the parties engaged in the exchange. 1239 Without explicit identification, the parties engaged in the 1240 exchange are not identified and the scope of the EAP keying 1241 parameters negotiated during the EAP exchange is undefined. 1243 [b] Mutual proof of possession of EAP keying material. During the 1244 Secure Association Protocol the EAP peer and authenticator MUST 1245 demonstrate possession of the keying material transported between 1246 the backend authentication server and authenticator (e.g. MSK), in 1247 order to demonstrate that the peer and authenticator have been 1248 authorized. Since mutual proof of possession is not the same as 1249 mutual authentication, the peer cannot verify authenticator 1250 assertions (including the authenticator identity) as a result of 1251 this exchange. Identity verification is discussed in Section 1252 2.2.1. 1254 [c] Secure capabilities negotiation. In order to protect against 1255 spoofing during the discovery phase, ensure selection of the "best" 1256 ciphersuite, and protect against forging of negotiated security 1257 parameters, the Secure Association Protocol MUST support secure 1258 capabilities negotiation. This includes the secure negotiation of 1259 usage modes, session parameters (such as security association 1260 identifiers (SAIDs) and key lifetimes), ciphersuites and required 1261 filters, including confirmation of security-relevant capabilities 1262 discovered during phase 0. The Secure Association Protocol MUST 1263 support integrity and replay protection of all capability 1264 negotiation messages. 1266 [d] Key naming and selection. Where key caching is supported, it may 1267 be possible for the EAP peer and authenticator to share more than 1268 one key of a given type. As a result, the Secure Association 1269 Protocol MUST explicitly name the keys used in the proof of 1270 possession exchange, so as to prevent confusion when more than one 1271 set of keying material could potentially be used as the basis for 1272 the exchange. Use of the key naming mechanism described in Section 1273 1.4.1 is RECOMMENDED. 1275 In order to support the correct processing of phase 2 security 1276 associations, the Secure Association (phase 2) protocol MUST 1277 support the naming of phase 2 security associations and associated 1278 transient session keys, so that the correct set of transient 1279 session keys can be identified for processing a given packet. The 1280 phase 2 Secure Association Protocol also MUST support transient 1281 session key activation and SHOULD support deletion, so that 1282 establishment and re-establishment of transient session keys can be 1283 synchronized between the parties. 1285 [e] Generation of fresh transient session keys (TSKs). Where the lower 1286 layer supports caching of exported EAP keying material, the EAP 1287 peer lower layer may initiate a new session using keying material 1288 that was derived in a previous session. Were the TSKs to be 1289 derived from a portion of the exported EAP keying material, this 1290 would result in reuse of the session keys which could expose the 1291 underlying ciphersuite to attack. 1293 In lower layers where caching of EAP keying material is supported, 1294 the Secure Association Protocol phase is REQUIRED, and MUST support 1295 the derivation of fresh unicast and multicast TSKs, even when the 1296 keying material provided by the backend authentication server is 1297 not fresh. This is typically supported via the exchange of nonces 1298 or counters, which are then mixed with the exported keying material 1299 in order to generate fresh unicast (phase 2a) and possibly 1300 multicast (phase 2b) session keys. By not using EAP keying 1301 material directly to protect data, the Secure Association Protocol 1302 protects it against compromise. 1304 [f] Key lifetime management. This includes explicit key lifetime 1305 negotiation or seamless re-key. EAP does not support re-key 1306 without re-authentication and existing EAP methods do not support 1307 key lifetime negotiation. As a result, the Secure Association 1308 Protocol may handle re-key and determination of the key lifetime. 1309 Where key caching is supported, secure negotiation of key lifetimes 1310 is RECOMMENDED. Lower layers that support re-key, but not key 1311 caching, may not require key lifetime negotiation. For example, a 1312 difference between IKEv1 [RFC2409] and IKEv2 [RFC4306] is that in 1313 IKEv1 SA lifetimes were negotiated; in IKEv2, each end of the SA is 1314 responsible for enforcing its own lifetime policy on the SA and re- 1315 keying the SA when necessary. 1317 [g] Key state resynchronization. It is possible for the peer or 1318 authenticator to reboot or reclaim resources, clearing portions or 1319 all of the key cache. Therefore, key lifetime negotiation cannot 1320 guarantee that the key cache will remain synchronized, and the peer 1321 may not be able to determine before attempting to use a key whether 1322 it exists within the authenticator cache. It is therefore 1323 RECOMMENDED for the Secure Association Protocol to provide a 1324 mechanism for key state resynchronization. Since in this situation 1325 one or more of the parties initially do not possess a key with 1326 which to protect the resynchronization exchange, securing this 1327 mechanism may be difficult. 1329 [h] Key scope synchronization. To support key scope determination, the 1330 Secure Association Protocol SHOULD provide a mechanism by which the 1331 peer can determine the scope of the key cache on each 1332 authenticator, and by which the authenticator can determine the 1333 scope of the key cache on a peer. This includes negotiation of 1334 restrictions on key usage. 1336 [i] Direct operation. Since the phase 2 Secure Association Protocol is 1337 concerned with the establishment of security associations between 1338 the EAP peer and authenticator, including the derivation of 1339 transient session keys, only those parties have "a need to know" 1340 the transient session keys. The Secure Association Protocol MUST 1341 operate directly between the peer and authenticator, and MUST NOT 1342 be passed-through to the backend authentication server, or include 1343 additional parties. 1345 [j] Bi-directional operation. While some ciphersuites only require a 1346 single set of transient session keys to protect traffic in both 1347 directions, other ciphersuites require a unique set of transient 1348 session keys in each direction. The phase 2 Secure Association 1349 Protocol SHOULD provide for the derivation of unicast and multicast 1350 keys in each direction, so as not to require two separate phase 2 1351 exchanges in order to create a bi-directional phase 2 security 1352 association. See [RFC3748] Section 2.4 for more discussion. 1354 3.2. Key Scope 1356 Absent explicit specification within the lower layer, after the 1357 completion of phase 1b, EAP keying material and parameters are bound 1358 to the EAP peer and authenticator, but are not bound to a specific 1359 peer or authenticator port. 1361 While EAP Keying Material passed down to the lower layer is not 1362 intrinsically bound to particular authenticator and peer ports, 1363 Transient Session Keys MAY be bound to particular authenticator and 1364 peer ports by the Secure Association Protocol. However, a lower 1365 layer MAY also permit TSKs to be used on multiple peer and/or 1366 authenticator ports, providing that TSK freshness is guaranteed (such 1367 as by keeping replay counter state within the authenticator). 1369 In order to further limit the key scope the following measures are 1370 suggested: 1372 [a] The lower layer MAY specify additional restrictions on key usage, 1373 such as limiting the use of EAP keying material and parameters on 1374 the EAP peer to the port over which on the EAP conversation was 1375 conducted. 1377 [b] The backend authentication server and authenticator MAY implement 1378 additional attributes in order to further restrict the scope of EAP 1379 keying material. For example, in 802.11, the backend 1380 authentication server may provide the authenticator with a list of 1381 authorized Called or Calling-Station-Ids and/or SSIDs for which EAP 1382 keying material is valid. 1384 [c] Where the backend authentication server provides attributes 1385 restricting the key scope, it is RECOMMENDED that restrictions be 1386 securely communicated by the authenticator to the peer. This can 1387 be accomplished using the Secure Association Protocol, but also 1388 can be accomplished via the EAP method or the lower layer. 1390 3.3. Parent-Child Relationships 1392 When an EAP re-authentication takes place, new keying material is 1393 derived and exported by the EAP method, which eventually results in 1394 replacement of TSKs, regardless of the way they are derived (see 1395 Section 2.1). While the maximum lifetime of TSKs or child keys can 1396 be less than or equal to that of the MSK/EMSK, it cannot be greater. 1397 This is true even where exported EAP keying material is only used for 1398 entity authentication and is not used for key derivation (such as in 1399 IKEv2), so that compromise of exported EAP keying material does not 1400 imply compromise of the TSKs or child keys. However, where child 1401 keys are derived from or are wrapped by EAP keying material, 1402 compromise of the MSK/EMSK does imply compromise of the child keys. 1404 Child keys that are used frequently (such as TSKs which are used for 1405 traffic protection) can expire sooner than the exported EAP keying 1406 material they are dependent on, so that it is advantageous to support 1407 re-key of child keys prior to EAP re-authentication. Note that 1408 deletion of the MSK/EMSK does not necessarily imply deletion of TSKs 1409 or child keys. 1411 Failure to mutually prove possession of exported EAP keying material 1412 during the Secure Association Protocol exchange need not be grounds 1413 for deletion of the keying material by both parties; rate-limiting 1414 Secure Association Protocol exchanges could be used to prevent a 1415 brute force attack. 1417 3.4. Local Key Lifetimes 1419 The Transient EAP Keys (TEKs) are session keys used to protect the 1420 EAP conversation. The TEKs are internal to the EAP method and are 1421 not exported. TEKs are typically created during an EAP conversation, 1422 used until the end of the conversation and then discarded. However, 1423 methods may re-key TEKs during an EAP conversation. 1425 When using TEKs within an EAP conversation or across conversations, 1426 it is necessary to ensure that replay protection and key separation 1427 requirements are fulfilled. For instance, if a replay counter is 1428 used, TEK re-key MUST occur prior to wrapping of the counter. 1429 Similarly, TSKs MUST remain cryptographically separate from TEKs 1430 despite TEK re-keying or caching. This prevents TEK compromise from 1431 leading directly to compromise of the TSKs and vice versa. 1433 EAP methods may cache local keying material which may persist for 1434 multiple EAP conversations when fast reconnect is used [RFC3748]. 1435 For example, EAP methods based on TLS (such as EAP-TLS [RFC2716]) 1436 derive and cache the TLS Master Secret, typically for substantial 1437 time periods. The lifetime of other local keying material calculated 1438 within the EAP method is defined by the method. Note that in 1439 general, when using fast reconnect, there is no guarantee to that the 1440 original long-term credentials are still in the possession of the 1441 peer. For instance, a card hold holding the private key for EAP-TLS 1442 may have been removed. EAP servers SHOULD also verify that the long- 1443 term credentials are still valid, such as by checking that 1444 certificate used in the original authentication has not yet expired. 1446 3.5. Exported and Calculated Key Lifetimes 1448 The following mechanisms are available for communicating the lifetime 1449 of exported and calculated keying material between the EAP peer, 1450 server and authenticator: 1452 AAA protocols (backend server and authenticator) 1453 Lower layer mechanisms (authenticator and peer) 1454 EAP method-specific negotiation (peer and server) 1456 Where the EAP method does not support the negotiation of the lifetime 1457 of exported keys, and a key lifetime negotiation mechanism is not 1458 provided by the lower layer, there may be no way for the peer to 1459 learn the lifetime of exported and calculated keys. This can leave 1460 the peer uncertain how long the authenticator will maintain EAP 1461 keying material within the key cache. In this case the lifetime of 1462 exported keys can be managed as a system parameter on the peer and 1463 authenticator; a default lifetime of 8 hours is RECOMMENDED. 1465 3.5.1. AAA Protocols 1467 AAA protocols such as RADIUS [RFC2865] and Diameter [RFC4072] can be 1468 used to communicate the maximum exported key lifetime from the 1469 backend authentication server to the authenticator. 1471 The Session-Timeout attribute is defined for RADIUS in [RFC2865] and 1472 for Diameter in [RFC4005]. Where EAP is used for authentication, 1473 [RFC3580] Section 3.17 indicates that a Session-Timeout attribute 1474 sent in an Access-Accept along with a Termination-Action value of 1475 RADIUS-Request specifies the maximum number of seconds of service 1476 provided prior to EAP re-authentication. 1478 However, there is also a need to be able to specify the maximum 1479 lifetime of cached keying material. Where EAP pre-authentication is 1480 supported, cached keys can be pre-established on the authenticator 1481 prior to session start, and will remain there until they expire. EAP 1482 lower layers supporting caching of exported keying material may also 1483 persist that material after the end of a session, enabling the peer 1484 to subsequently resume communication utilizing the cached keying 1485 material. In these situations it may be desirable for the backend 1486 authentication server to specify the maximum lifetime of cached 1487 keying material. 1489 To accomplish this, [IEEE-802.11i] overloaded the Session-Timeout 1490 attribute, assuming that it represents the maximum time after which 1491 transported EAP keying material will expire on the authenticator, 1492 regardless of whether transported keying material is cached. 1494 An IEEE 802.11 authenticator receiving keying material is expected to 1495 initialize a timer to the Session-Timeout value, and once the timer 1496 expires, the exported keying material expires. Whether this results 1497 in session termination or EAP re-authentication is controlled by the 1498 value of the Termination-Action attribute. Where EAP re- 1499 authentication occurs the exported keying material is replaced, and 1500 with it, new calculated keys are put in place. Where session 1501 termination occurs, exported and calculated keying material is 1502 deleted. 1504 Overloading the Session-Timeout attribute is problematic in 1505 situations where it is necessary to control the maximum session time 1506 and key lifetime independently. For example, it might be desirable 1507 to limit the lifetime of cached keys to 5 minutes while permitting a 1508 user once authenticated to remain connected for up to an hour without 1509 re-authenticating. As a result, in the future additional attributes 1510 may be specified to control the lifetime of cached keys; these 1511 attributes may modify the meaning of the Session-Timeout attribute in 1512 specific circumstances. 1514 Since the TSK lifetime is often determined by authenticator 1515 resources, and the backend authentication server has no insight into 1516 the TSK derivation process, by the principle of ciphersuite 1517 independence, it is not appropriate for the backend authentication 1518 server to manage any aspect of the TSK derivation process, including 1519 the TSK lifetime. 1521 3.5.2. Lower Layer Mechanisms 1523 Lower layer mechanisms can be used to enable the lifetime of exported 1524 and calculated keys to be negotiated between the peer and 1525 authenticator. This can be accomplished either using the Secure 1526 Association Protocol or within the lower layer transport. 1528 Where TSKs are established as the result of a Secure Association 1529 Protocol exchange, it is RECOMMENDED that the Secure Association 1530 Protocol include support for TSK re-key. Where the TSK is taken 1531 directly from the MSK, there is no need to manage the TSK lifetime as 1532 a separate parameter, since the TSK lifetime and MSK lifetime are 1533 identical. 1535 3.5.3. EAP Method-Specific Negotiation 1537 All EAP methods generating keys are required to generate the MSK and 1538 EMSK, and may optionally generate the IV. However, EAP, defined in 1539 [RFC3748], does not itself support the negotiation of lifetimes for 1540 exported keying material such as the MSK, EMSK and IV. 1542 While EAP itself does not support lifetime negotiation, it would be 1543 possible to specify methods that do. However, systems that rely on 1544 such negotiation for exported keys would only function with these 1545 methods. Also, there is no guarantee that the lifetime negotiated 1546 within the EAP method would be compatible with backend authentication 1547 server policy. In the interest of method independence and 1548 compatibility with backend server implementations, key management of 1549 exported or derived keys SHOULD NOT be provided within EAP methods. 1551 3.6. Key Cache Synchronization 1553 Key lifetime negotiation alone cannot guarantee key cache 1554 synchronization. Even where a lower layer exchange is run 1555 immediately after EAP in order to determine the lifetime of EAP 1556 keying material, it is still possible for the authenticator to purge 1557 all or part of the key cache prematurely (e.g. due to reboot or need 1558 to reclaim memory). 1560 The lower layer may utilize the Discovery phase 0 to improve key 1561 cache synchronization. For example, if the authenticator manages the 1562 key cache by deleting the oldest key first, the relative creation 1563 time of the last key to be deleted could be advertised within the 1564 Discovery phase, enabling the peer to determine whether keying 1565 material had been prematurely expired from the authenticator key 1566 cache. 1568 3.7. Key Strength 1570 As noted in Section 2.1, EAP lower layers determine TSKs in different 1571 ways. Where EAP keying material is utilized in the derivation, 1572 encryption or authentication of TSKs, it is possible for EAP key 1573 generation to represent the weakest link. 1575 In order to ensure that EAP methods produce keying material of an 1576 appropriate symmetric key strength, it is RECOMMENDED that EAP 1577 methods utilizing public key cryptography choose a public key that 1578 has a cryptographic strength providing the required level of attack 1579 resistance. This is typically provided by configuring EAP methods, 1580 since there is no coordination between the lower layer and EAP method 1581 with respect to minimum required symmetric key strength. 1583 BCP 86 [RFC3766] offers advice on appropriate key sizes. The 1584 National Institute for Standards and Technology (NIST) also offers 1585 advice on appropriate key sizes in [SP800-57]. 1587 [RFC3766] Section 5 advises use of the following required RSA or DH 1588 module and DSA subgroup size in bits, for a given level of attack 1589 resistance in bits: 1591 Attack Resistance RSA or DH Modulus DSA subgroup 1592 (bits) size (bits) size (bits) 1593 ----------------- ----------------- ------------ 1594 70 947 129 1595 80 1228 148 1596 90 1553 167 1597 100 1926 186 1598 150 4575 284 1599 200 8719 383 1600 250 14596 482 1602 3.8. Key Wrap 1604 The key wrap specified in [RFC2548], which is based on an MD5-based 1605 stream cipher, has known problems, as described in [RFC3579] Section 1606 4.3. RADIUS uses the shared secret for multiple purposes, including 1607 per-packet authentication and attribute hiding, considerable 1608 information is exposed about the shared secret with each packet. 1609 This exposes the shared secret to dictionary attacks. MD5 is used 1610 both to compute the RADIUS Response Authenticator and the Message- 1611 Authenticator attribute, and concerns exist relating to the security 1612 of this hash [MD5Collision]. 1614 As discussed in [RFC3579] Section 4.3, the security vulnerabilities 1615 of RADIUS are extensive, and therefore development of an alternative 1616 key wrap technique based on the RADIUS shared secret would not 1617 substantially improve security. As a result, [RFC3579] Section 4.2 1618 recommends running RADIUS over IPsec. The same approach is taken in 1619 Diameter EAP [RFC4072], which defines clear-text key attributes, to 1620 be protected by IPsec or TLS. 1622 4. Handoff Vulnerabilities 1624 With EAP, several mechanisms are available to reduce the latency in 1625 handoff between authenticators: 1627 [a] EAP pre-authentication. This utilizes EAP to pre-establish EAP 1628 keying material on an authenticator prior to arrival of the peer. 1629 Use of EAP pre-authentication within IEEE 802.11 is described in 1630 [8021XHandoff] and [IEEE-802.11i]. 1632 [b] Key caching. This mechanism enables an EAP peer to re-attach to an 1633 authenticator without requiring EAP re-authentication. 1635 [c] Context transfer, such as is defined in [IEEE-802.11F] (now 1636 deprecated) and [RFC4067]. Use of context transfer for handoff 1637 latency improvement is described in [IEEE-02-758]. 1639 [d] Proactive key distribution, such as is described in 1640 [IEEE-02-758][IEEE-03-084] and [I-D.irtf-aaaarch-handoff]. 1642 The sections that follow discuss the security vulnerabilities 1643 introduced by the above mechanisms. 1645 4.1. EAP Pre-authentication 1647 EAP pre-authentication enables an EAP peer to pre-establish EAP 1648 keying material with an authenticator prior to attaching to it. Where 1649 there is sufficient time to pre-establish keying material prior to 1650 changing the point of attachment, this may enable the peer to remove 1651 EAP authentication from the critical path for handoff, reducing 1652 latency. 1654 EAP pre-authentication exchanges typically differ from a normal EAP 1655 conversation only with respect to the lower layer encapsulation. For 1656 example, in [IEEE-802.11i], EAP pre-authentication frames are 1657 encapsulated within a distinct Ethertype, but otherwise conform to 1658 the encapsulation described in [IEEE-802.1X]. As a result, an EAP 1659 pre-authentication conversation that eventually results in 1660 establishment of security associations differs little from the model 1661 described in Section 1.3, other than the potential introduction of a 1662 delay between Phase 1 and Phase 2. However, since a peer may complete 1663 EAP pre-authentication with an authenticator without eventually 1664 attaching to it, it is possible that Phase 2 will not occur. 1666 [RFC3580] describes only minor differences in the AAA exchange 1667 occurring as a result of EAP pre-authentication as compared with an 1668 ordinary EAP authentication exchange. For example, since in 802.11i 1669 an Association exchange does not occur prior to EAP pre- 1670 authentication, the SSID is not yet known. As a result, an Access- 1671 Request generated as the result of EAP pre-authentication cannot 1672 include the SSID within the Called-Station-Id attribute as described 1673 in [RFC3580] Section 3.20. Since a peer may never associate with an 1674 authenticator to which it pre-authenticated, an Accounting-Request 1675 signifying the start of service may never be sent, or may only be 1676 sent with a substantial delay after the completion of authentication. 1678 Since an EAP pre-authentication exchange differs from an EAP 1679 authentication exchange only in subtle ways, the backend 1680 authentication server may not be aware of whether it is engaging in 1681 an EAP pre-authentication exchange, resulting in operational or 1682 security problems. For example, where the authenticator does not 1683 include the SSID within the Called-Station-Id attribute in ordinary 1684 requests, EAP pre-authentication requests may appear 1685 indistinguishable. As a result, the backend authentication server may 1686 not be able to correctly calculate the simultaneous sessions in 1687 progress, either preventing successful completion of EAP pre- 1688 authentication or enabling the peer to engage in more simultaneous 1689 sessions than they are authorized for. 1691 In order to allow backend authentication servers to handle EAP pre- 1692 authentication requests more reliably, it is recommended that EAP 1693 pre-authentication requests be explicitly identified within AAA 1694 protocols. Also, in order to suppress unnecessary EAP pre- 1695 authentication exchanges, it is recommended that authenticators 1696 unambiguously identify themselves as described in Section 2.2.1, 1697 allowing the peer to determine whether it has previously established 1698 EAP keying material with that authenticator. 1700 4.2. Authorization 1702 In a typical network access scenario (dial-in, wireless LAN, etc.) 1703 access control mechanisms are typically applied. These mechanisms 1704 include user authentication as well as authorization for the offered 1705 service. 1707 As a part of the authentication process, the backend authentication 1708 server determines the user's authorization profile. The user 1709 authorizations are transmitted by the backend authentication server 1710 to the EAP authenticator (also known as the Network Access Server or 1711 authenticator) along with the transported EAP keying material, in 1712 Phase 1b of the EAP conversation. Typically, the profile is 1713 determined based on the user identity, but a certificate presented by 1714 the user may also provide authorization information. 1716 The backend authentication server is responsible for making a user 1717 authorization decision, which requires answering the following 1718 questions: 1720 [a] Is this a legitimate user for this particular network? 1722 [b] Is the user allowed the type of access he or she is requesting? 1724 [c] Are there any specific parameters (mandatory tunneling, bandwidth, 1725 filters, and so on) that the access network should be aware of for 1726 this user? 1728 [d] Is the user operating within the time of day subscription rules? 1730 [e] Is the user within his limits for concurrent sessions? 1732 [f] Are there any fraud, credit limit, or other concerns that indicate 1733 that access should be denied? 1735 While the authorization decision is in principle simple, the process 1736 is complicated by the distributed nature of the decision making. 1737 Where brokering entities or proxies are involved, all of the AAA 1738 entities in the chain from the authenticator to the home backend 1739 authentication server are involved in the decision. For instance, a 1740 broker can disallow access even if the home backend authentication 1741 server would allow it, or a proxy can add authorizations (e.g., 1742 bandwidth limits). 1744 Decisions can be based on static policy definitions and profiles as 1745 well as dynamic state (e.g. time of day or limits on the number of 1746 concurrent sessions). In addition to the Accept/Reject decision made 1747 by the AAA chain, parameters or constraints can be communicated to 1748 the authenticator. 1750 The criteria for Accept/Reject decisions or the reasons for choosing 1751 particular authorizations are typically not communicated to the 1752 authenticator, only the final result. As a result, the authenticator 1753 has no way to know what the decision was based on. Was a set of 1754 authorization parameters sent because this service is always provided 1755 to the user, or was the decision based on the time/day and the 1756 capabilities of the requesting authenticator device? 1758 4.3. Correctness 1760 When the AAA exchange is bypassed via use of techniques such as key 1761 caching, it can be challenging to ensure that authorization is 1762 properly handled. Challenges include: 1764 [a] Consistent application of session time limits. Bypassing AAA 1765 should not automatically increase the available session time, 1766 allowing a user to endlessly extend their network access by 1767 changing the point of attachment. 1769 [b] Avoidance of privilege elevation. Bypassing AAA should not result 1770 in a user being granted access to services which they are not 1771 entitled to. 1773 [c] Consideration of dynamic state. In situations in which dynamic 1774 state is involved in the access decision (day/time, simultaneous 1775 session limit) it should be possible to take this state into 1776 account either before or after access is granted. Note that 1777 consideration of network-wide state such as simultaneous session 1778 limits can typically only be taken into account by the backend 1779 authentication server. 1781 [d] Encoding of restrictions. Since a authenticator may not be aware 1782 of the criteria considered by a backend authentication server when 1783 allowing access, in order to ensure consistent authorization during 1784 a fast handoff it may be necessary to explicitly encode the 1785 restrictions within the authorizations provided by the backend 1786 authentication server. 1788 [e] State validity. The introduction of fast handoff should not render 1789 the authentication server incapable of keeping track of network- 1790 wide state. 1792 A handoff mechanism capable of addressing these concerns is said to 1793 be "correct". One condition for correctness is as follows: 1795 For a handoff to be "correct" it MUST establish on the new device 1796 the same context as would have been created had the new device 1797 completed a AAA conversation with the backend authentication 1798 server. 1800 A properly designed handoff scheme will only succeed if it is 1801 "correct" in this way. If a successful handoff would establish 1802 "incorrect" state, it is preferable for it to fail, in order to avoid 1803 creation of incorrect context. 1805 Some authenticator and backend authentication server configurations 1806 are incapable of meeting this definition of "correctness". For 1807 example, if the old and new device differ in their capabilities, a 1808 handoff mechanism that bypasses AAA may find it difficult to meet 1809 this definition of correctness. Backend authentication servers often 1810 perform conditional evaluation, in which the authorizations returned 1811 in an Access-Accept message are contingent on the authenticator or on 1812 dynamic state such as the time of day or number of simultaneous 1813 sessions. For example, in a heterogeneous deployment, the backend 1814 authentication server might return different authorizations depending 1815 on the authenticator making the request, in order to make sure that 1816 the requested service is consistent with the authenticator 1817 capabilities. 1819 If differences between the new and old device would result in the 1820 backend authentication server sending a different set of messages to 1821 the new device than were sent to the old device, then if the handoff 1822 mechanism bypasses AAA, the handoff cannot be carried out correctly. 1824 For example, if some authenticators support dynamic Virtual LANs 1825 (VLANs) while others do not, then attributes present in the Access- 1826 Request (such as the NAS-IP-Address, NAS-IPv6-Address, NAS- 1827 Identifier, etc.) could be examined to determine when VLAN attributes 1828 will be returned, as described in [RFC3580]. VLAN support is 1829 defined in [IEEE-802.1Q]. If a handoff bypassing the backend 1830 authentication server were to occur between a authenticator 1831 supporting dynamic VLANs and another authenticator which does not, 1832 then a guest user with access restricted to a guest VLAN could be 1833 given unrestricted access to the network. 1835 Similarly, in a network where access is restricted based on the day 1836 and time, Service Set Identifier (SSID), Calling-Station-Id or other 1837 factors, unless the restrictions are encoded within the 1838 authorizations, or a partial AAA conversation is included, then a 1839 handoff could result in the user bypassing the restrictions. 1841 In practice, these considerations limit the situations in which fast 1842 handoff mechanisms bypassing AAA can be expected to be successful. 1843 Where the deployed devices implement the same set of services, it may 1844 be possible to do successful handoffs within such mechanisms. 1845 However, where the supported services differ between devices, the 1846 handoff may not succeed. For example, [RFC2865] section 1.1 states: 1848 "A authenticator that does not implement a given service MUST NOT 1849 implement the RADIUS attributes for that service. For example, a 1850 authenticator that is unable to offer ARAP service MUST NOT 1851 implement the RADIUS attributes for ARAP. A authenticator MUST 1852 treat a RADIUS access-accept authorizing an unavailable service as 1853 an access-reject instead." 1855 Note that this behavior only applies to attributes that are known, 1856 but not implemented. For attributes that are unknown, [RFC2865] 1857 Section 5 states: 1859 "A RADIUS server MAY ignore Attributes with an unknown Type. A 1860 RADIUS client MAY ignore Attributes with an unknown Type." 1862 In order to perform a correct handoff, if a new device is provided 1863 with RADIUS context for a known but unavailable service, then it MUST 1864 process this context the same way it would handle a RADIUS Access- 1865 Accept requesting an unavailable service. This MUST cause the 1866 handoff to fail. However, if a new device is provided with RADIUS 1867 context that indicates an unknown attribute, then this attribute MAY 1868 be ignored. 1870 Although it may seem somewhat counter-intuitive, failure is indeed 1871 the "correct" result where a known but unsupported service is 1872 requested. Presumably a correctly configured backend authentication 1873 server would not request that a device carry out a service that it 1874 does not implement. This implies that if the new device were to 1875 complete a AAA conversation that it would be likely to receive 1876 different service instructions. In such a case, failure of the 1877 handoff is the desired result. This will cause the new device to go 1878 back to the backend server in order to receive the appropriate 1879 service definition. 1881 In practice, this implies that handoff mechanisms which bypass AAA 1882 are most likely to be successful within a homogeneous device 1883 deployment within a single administrative domain. For example, it 1884 would not be advisable to carry out a fast handoff bypassing AAA 1885 between a authenticator providing confidentiality and another 1886 authenticator that does not support this service. The correct result 1887 of such a handoff would be a failure, since if the handoff were 1888 blindly carried out, then the user would be moved from a secure to an 1889 insecure channel without permission from the backend authentication 1890 server. Thus the definition of a "known but unsupported service" 1891 MUST encompass requests for unavailable security services. This 1892 includes vendor-specific attributes related to security, such as 1893 those described in [RFC2548]. 1895 5. Security Considerations 1897 The EAP threat model is described in [RFC3748] Section 7.1. The 1898 security properties of EAP methods (known as "security claims") are 1899 described in [RFC3748] Section 7.2.1. EAP method requirements for 1900 applications such as Wireless LAN authentication are described in 1901 [RFC4017]. The RADIUS threat model is described in [RFC3579] Section 1902 4.1, and responses to these threats are described in [RFC3579] 1903 Sections 4.2 and 4.3. 1905 However, in addition to threats against EAP and AAA, there are other 1906 system level threats. In developing the threat model, it is assumed 1907 that: 1909 All traffic is visible to the attacker. 1910 The attacker can alter, forge or replay messages. 1911 The attacker can reroute messages to another principal. 1912 The attacker may be a principal or an outsider. 1913 The attacker can compromise any key that is sufficiently old. 1915 Threats arising from these assumptions include: 1917 [a] An attacker may compromise or steal an EAP authenticator, in an 1918 attempt to gain access to other EAP authenticators or obtain long- 1919 term secrets. 1921 [b] An attacker may try to modify or spoof packets, including Discovery 1922 or Secure Association Protocol frames, EAP or AAA packets. 1924 [c] An attacker may attempt a downgrade attack in order to exploit 1925 known weaknesses in an authentication method or cryptographic 1926 transform. 1928 [d] An attacker may attempt to induce an EAP peer, authenticator or 1929 server to disclose keying material to an unauthorized party, or 1930 utilize keying material outside the context that it was intended 1931 for. 1933 [e] An attacker may alter, forge or replay packets. 1935 [f] An attacker may cause an EAP peer, authenticator or server to reuse 1936 an stale key. Use of stale keys may also occur unintentionally. 1937 For example, a poorly implemented backend authentication server may 1938 provide stale keying material to an authenticator, or a poorly 1939 implemented authenticator may reuse nonces. 1941 [g] An authenticated attacker may attempt to obtain elevated privilege 1942 in order to access information that it does not have rights to. 1944 [h] An attacker may attempt a man-in-the-middle attack in order to gain 1945 access to the network. 1947 [i] An attacker may launch a denial of service attack against the EAP 1948 peer, authenticator or backend authentication server. 1950 [j] An attacker may compromise an EAP authenticator in an effort to 1951 commit fraud. For example, a compromised authenticator may provide 1952 incorrect information to the EAP peer and/or server via out-of-band 1953 mechanisms (such as via a AAA or lower layer protocol). This 1954 includes impersonating another authenticator, or providing 1955 inconsistent information to the peer and EAP server. 1957 In order to address these threats, [I-D.housley-aaa-key-mgmt] 1958 provides a description of mandatory system security properties. 1959 Issues relating to system security requirements are discussed in the 1960 sections that follow. 1962 5.1. Authenticator Compromise 1964 In the event that an authenticator is compromised or stolen, an 1965 attacker may gain access to the network via that authenticator, or 1966 may obtain the credentials required for that authenticator/AAA client 1967 to communicate with one or more backend authentication servers. 1968 However, this should not allow the attacker to compromise other 1969 authenticators or the backend authentication server, or obtain long- 1970 term user credentials. 1972 The implications of this requirement are many, but some of the more 1973 important are as follows: 1975 No Key Sharing 1976 An EAP authenticator MUST NOT share any keying material with 1977 another EAP authenticator, since if one EAP authenticator were 1978 compromised, this would enable the compromise of keying material on 1979 another authenticator. In order to be able to determine whether 1980 keying material has been shared, it is necessary for the identity 1981 of the EAP authenticator to be defined and understood by all 1982 parties that communicate with it. 1984 No AAA Credential Sharing 1985 AAA credentials (such as RADIUS shared secrets, IPsec pre-shared 1986 keys or certificates) MUST NOT be shared between AAA clients, since 1987 if one AAA client were compromised, this would enable an attacker 1988 to impersonate other AAA clients to the backend authentication 1989 server, or even to impersonate a backend authentication server to 1990 other AAA clients. 1992 No Compromise of Long-Term Credentials 1993 An attacker obtaining TSKs, TEKs or EAP keying material such as the 1994 MSK MUST NOT be able to obtain long-term user credentials such as 1995 pre-shared keys, passwords or private-keys without breaking a 1996 fundamental cryptographic assumption. 1998 5.2. Spoofing 2000 The use of per-packet authentication and integrity protection 2001 provides protection against spoofing attacks. Diameter [RFC3588] 2002 provides support for per-packet authentication and integrity 2003 protection via use of IPsec or TLS. RADIUS/EAP [RFC3579] provides 2004 for per-packet authentication and integrity protection via use of the 2005 Message-Authenticator attribute. 2007 [RFC3748] Section 7.2.1 describes the "integrity protection" security 2008 claim and [RFC4017] requires use of EAP methods supporting this 2009 claim. 2011 In order to prevent forgery of Secure Association Protocol frames, 2012 per-frame authentication and integrity protection is RECOMMENDED on 2013 all messages. [IEEE-802.11i] supports per-frame integrity protection 2014 and authentication on all messages within the 4-way handshake except 2015 the first message. An attack leveraging this ommission is described 2016 in [Analysis]. 2018 5.3. Downgrade Attacks 2020 The ability to negotiate the use of a particular cryptographic 2021 algorithm provides resilience against compromise of a particular 2022 cryptographic algorithm. This is usually accomplished by including 2023 an algorithm identifier in the protocol, and by specifying the 2024 algorithm requirements in the protocol specification. In order to 2025 prevent downgrade attacks, secure confirmation of the "best" 2026 ciphersuite is required. 2028 [RFC3748] Section 7.2.1 describes the "protected ciphersuite 2029 negotiation" security claim that refers to the ability of an EAP 2030 method to negotiate the ciphersuite used to protect the EAP 2031 conversation, as well as to integrity protect the negotiation. 2032 [RFC4017] requires EAP methods satisfying this security claim. 2034 Diameter [RFC3588] provides support for cryptographic algorithm 2035 negotiation via use of IPsec or TLS. RADIUS [RFC3579] does not 2036 support the negotiation of cryptographic algorithms, and relies on 2037 MD5 for integrity protection, authentication and confidentiality, 2038 despite known weaknesses in the algorithm [MD5Collision]. This issue 2039 can be addressed via use of RADIUS over IPsec, as described in 2040 [RFC3579] Section 4.2. 2042 As a result, EAP methods and AAA protocols are capable of addressing 2043 downgrade attacks. To ensure against downgrade attacks within lower 2044 layer protocols, algorithm independence is REQUIRED with lower layers 2045 using EAP for key derivation. For interoperability, at least one 2046 suite of mandatory-to-implement algorithm MUST be selected. Lower 2047 layer protocols supporting EAP for key derivation SHOULD also support 2048 secure ciphersuite negotiation. As described in [RFC1968], PPP ECP 2049 does not provide support for secure ciphersuite negotiation. 2050 However, [IEEE-802.11i] does support secure ciphersuite negotiation. 2052 5.4. Unauthorized Disclosure 2054 While preserving algorithm independence, confidentiality of all 2055 keying material MUST be maintained. To prevent unauthorized disclose 2056 of keys, each party in the EAP conversation MUST be authenticated to 2057 the other parties with whom it communicates. Keying material MUST be 2058 bound to the appropriate context. 2060 [RFC3748] Section 7.2.1 describes the "mutual authentication" and 2061 "dictionary attack resistance" claims, and [RFC4017] requires EAP 2062 methods satisfying these claims. EAP methods complying with 2063 [RFC4017] therefore provide for mutual authentication between the EAP 2064 peer and server. Within EAP, binding of EAP keying material (MSK, 2065 EMSK) to the appropriate context is provided by the Peer-Id and 2066 Server-Id which are exported along with the keying material. 2068 Diameter [RFC3588] provides for per-packet authentication and 2069 integrity protection via IPsec or TLS, and RADIUS/EAP [RFC3579] also 2070 provides for per-packet authentication and integrity protection. 2071 Where the NAS/authenticator and backend authentication server 2072 communicate directly and credible keywrap is used (see Section 3.8), 2073 this ensures that the AAA Key Transport phase achieves its security 2074 objectives: mutually authenticating the AAA client/authenticator and 2075 backend authentication server and providing EAP keying material to 2076 the EAP authenticator and to no other party. Within the AAA 2077 protocol, the authorization attributes provide the information 2078 binding the transported keying material to the appropriate context. 2079 For example, transported keying material is destined for the EAP 2080 authenticator identified by the NAS-Identifier attribute within the 2081 request, and relates to the EAP peer identified by the Peer-Id, User- 2082 Name [RFC2865] or CUI [RFC4372] attributes. 2084 [RFC2607] Section 7 describes the security issues occurring when the 2085 authenticator and backend authentication server do not communicate 2086 directly. Where an untrusted AAA intermediary is present (such as a 2087 RADIUS proxy or a Diameter agent), and data object security is not 2088 used, transported keying material may be recovered by an attacker in 2089 control of the untrusted intermediary. As discussed in Section 2.1, 2090 unless the TSKs are derived independently from EAP keying material 2091 (as in IKEv2), possession of transported keying material enables 2092 decryption of data traffic sent between the peer and a specific 2093 authenticator. However, as long as EAP keying material or keys 2094 derived from it are only utilized by a single authenticator, 2095 compromise of the transported keying material does not enable an 2096 attacker to impersonate the peer to another authenticator. 2097 Vulnerability to an untrusted AAA intermediary can be mitigated by 2098 implementation of redirect functionality, as described in [RFC3588] 2099 and [RFC4072]. 2101 As noted in Section 3.1, the Secure Association Protocol does not by 2102 itself provide for mutual authentication between the EAP peer and 2103 authenticator, even if mutual possession of EAP keying material is 2104 proven. Where the NAS/authenticator and backend authentication 2105 server communicate directly, the backend authentication server can 2106 verify the correspondence between NAS identification attributes, the 2107 source address of packets sent by the NAS, and the AAA credentials. 2108 As long as the NAS has not shared its AAA credentials with another 2109 NAS, this allows the backend authentication server to authenticate 2110 the NAS. Using Channel Bindings, the EAP peer can then determine 2111 whether the NAS/authenticator has provided the same identifying 2112 information to the EAP peer and backend authentication server. 2114 Peer and authenticator authorization MUST be performed. 2115 Authorization is REQUIRED whenever a peer associates with a new 2116 authenticator. Authorization checking prevents an elevation of 2117 privilege attack, and ensures that an unauthorized authenticator is 2118 detected. Authorizations SHOULD be synchronized between the EAP 2119 peer, server, authenticator. Once the EAP conversation exchanges are 2120 complete, all of these parties should hold the same view of the 2121 authorizations associated the other parties. If peer authorization 2122 is restricted, then the peer SHOULD be made aware of the restriction. 2124 The AAA exchange provides the EAP authenticator with authorizations 2125 relating to the EAP peer. However, neither the EAP nor AAA exchanges 2126 provides authorizations to the EAP peer. In order to ensure that all 2127 parties hold the same view of the authorizations it is RECOMMENDED 2128 that the Secure Association Protocol enable communication of 2129 authorizations between the EAP authenticator and peer. 2131 Consistently identifying the EAP authenticator enables the EAP peer 2132 to determine whether EAP keying material has been shared between EAP 2133 authenticators as well as to confirm with the backend authentication 2134 server that an EAP authenticator proving possession of EAP keying 2135 material during the Secure Association Protocol was authorized to 2136 obtain it. Identification issues are discussed in Section 2.2 and 2137 key scope issues are discussed in Section 3.2. 2139 5.5. Replay Protection 2141 Replay protection allows a protocol message recipient to discard any 2142 message that was recorded during a previous legitimate dialogue and 2143 presented as though it belonged to the current dialogue. 2145 [RFC3748] Section 7.2.1 describes the "replay protection" security 2146 claim and [RFC4017] requires use of EAP methods supporting this 2147 claim. 2149 Diameter [RFC3588] provides support for replay protection via use of 2150 IPsec or TLS. RADIUS/EAP [RFC3579] protects against replay of keying 2151 material via the Request Authenticator. However, some RADIUS packets 2152 are not replay protected. In Accounting, Disconnect and CoA-Request 2153 packets the Request Authenticator contains a keyed MAC rather than a 2154 Nonce. The Response Authenticator in Accounting, Disconnect and CoA 2155 Response packets also contains a keyed MAC whose calculation does not 2156 depend on a Nonce in either the Request or Response packets. 2157 Therefore unless an Event-Timestamp attribute is included or IPsec is 2158 used, the recipient may not be able to determine whether these 2159 packets have been replayed. 2161 In order to prevent replay of Secure Association Protocol frames, 2162 replay protection is REQUIRED on all messages. [IEEE-802.11i] 2163 supports replay protection on all messages within the 4-way 2164 handshake. 2166 5.6. Key Freshness 2168 A session key should be considered compromised if it remains in use 2169 too long. As noted in [I-D.housley-aaa-key-mgmt]], session keys MUST 2170 be strong and fresh, while preserving algorithm independence. A 2171 fresh cryptographic key is one that is generated specifically for the 2172 intended use. Each session deserves an independent session key; 2173 disclosure of one session key MUST NOT aid the attacker in 2174 discovering any other session keys. 2176 Fresh keys are required even when a long replay counter (that is, one 2177 that "will never wrap") is used to ensure that loss of state does not 2178 cause the same counter value to be used more than once with the same 2179 session key. 2181 EAP, AAA and the lower layer each bear responsibility for ensuring 2182 the use of fresh, strong session keys: 2184 EAP EAP methods need to ensure the freshness and strength of EAP keying 2185 material provided as an input to session key derivation. [RFC3748] 2186 Section 7.10 states that "EAP methods SHOULD ensure the freshness 2187 of the MSK and EMSK, even in cases where one party may not have a 2188 high quality random number generator. A RECOMMENDED method is for 2189 each party to provide a nonce of at least 128 bits, used in the 2190 derivation of the MSK and EMSK." The contribution of nonces 2191 enables the EAP peer and server to ensure that exported EAP keying 2192 material is fresh. 2194 [RFC3748] Section 7.2.1 describes the "key strength" and "session 2195 independence" security claims, and and [RFC4017] requires use of 2196 EAP methods supporting these claims as well as being capable of 2197 providing an equivalent key strength of 128 bits or greater. 2199 AAA The AAA protocol needs to ensure that transported keying material 2200 is fresh and is not utilized outside its recommended lifetime. 2201 Replay protection is necessary for key freshness, but an attacker 2202 can deliver a stale (and therefore potentially compromised) key in 2203 a replay-protected message, so replay protection is not sufficient. 2204 As discussed in Section 3.5, the Session-Timeout attribute enables 2205 the backend authentication server to limit the exposure of 2206 transported EAP keying material. 2208 The EAP Session-Id, derived as described in Section 1.4, enables 2209 the EAP peer, authenticator and server to distinguish EAP 2210 conversations. However, unless the authenticator keeps track of 2211 EAP Session-Ids, the authenticator cannot use the Session-Id to 2212 guarantee the freshness of EAP keying material. 2214 Lower Layer 2215 As described in Section 3.1, the lower layer Secure Association 2216 Protocol MUST generate a fresh session key for each session, even 2217 if the keying material and parameters provided by EAP methods are 2218 cached, or either the peer or authenticator lack a high entropy 2219 random number generator. A RECOMMENDED method is for the peer and 2220 authenticator to each provide a nonce or counter used in session 2221 key derivation. If a nonce is used, it is RECOMMENDED that it be 2222 at least 128 bits. 2224 5.7. Elevation of Privilege 2226 Parties MUST NOT have access to keying material that is not needed to 2227 perform their own role. A party has access to a particular key if it 2228 has access to all of the secret information needed to derive it. If 2229 a Secure Association Protocol is used to establish session keys, it 2230 MUST specify the scope for session keys. 2232 Transported EAP keying material is permitted to be accessed by the 2233 EAP peer, authenticator and server. The EAP peer and server derive 2234 the transported keying material during the process of mutually 2235 authenticating each other using the selected EAP method. During the 2236 Secure Association Protocol, the EAP peer utilizes the transported 2237 EAP keying material to demonstrate to the authenticator that it is 2238 the same party that authenticated to the EAP server and was 2239 authorized by it. The EAP authenticator utilizes the transported EAP 2240 keying material to prove to the peer not only that the EAP 2241 conversation was transported through it (this could be demonstrated 2242 by a man-in-the-middle), but that it was uniquely authorized by the 2243 EAP server to provide the peer with access to the network. Unique 2244 authorization can only be demonstrated if the EAP authenticator does 2245 not share the transported keying material with a party other than the 2246 EAP peer and server. 2248 TSKs are permitted to be accessed only by the EAP peer and 2249 authenticator (see Section 1.5). As discussed in Section 2.1, PPP 2250 and 802.11i derive the TSKs from transported EAP keying material; 2251 802.16e utilizes transported EAP keying material for TSK keywrap; 2252 IKEv2 utilizes transported EAP keying material only to authenticate 2253 the derivation of TSKs. 2255 Where demonstration of authorization depends entirely on possession 2256 of transported EAP keying material (such as in PPP, 802.11i and 2257 802.16e), this enables the backend server to masquerade as the 2258 authenticator, and possibly to obtain the TSKs unless the backend 2259 server deletes the transported EAP keying material after sending it. 2261 5.8. Man-in-the-middle Attacks 2263 As described in [I-D.puthenkulam-eap-binding], EAP method sequences 2264 and compound authentication mechanisms may be subject to man-in-the- 2265 middle attacks. When such attacks are successfully carried out, the 2266 attacker acts as an intermediary between a victim and a legitimate 2267 authenticator. This allows the attacker to authenticate successfully 2268 to the authenticator, as well as to obtain access to the network. 2270 In order to prevent these attacks, [I-D.puthenkulam-eap-binding] 2271 recommends derivation of a compound key by which the EAP peer and 2272 server can prove that they have participated in the entire EAP 2273 exchange. Since the compound key must not be known to an attacker 2274 posing as an authenticator, and yet must be derived from quantities 2275 that are exported by EAP methods, it may be desirable to derive the 2276 compound key from a portion of the EMSK. In order to provide proper 2277 key hygiene, it is recommended that the compound key used for man-in- 2278 the-middle protection be cryptographically separate from other keys 2279 derived from the EMSK. 2281 5.9. Denial of Service Attacks 2283 Key caching may result in vulnerability to denial of service attacks. 2284 For example, EAP methods that create persistent state may be 2285 vulnerable to denial of service attacks on the EAP server by a rogue 2286 EAP peer. 2288 To address this vulnerability, EAP methods creating persistent state 2289 may wish to limit the persistent state created by an EAP peer. For 2290 example, for each peer an EAP server may choose to limit persistent 2291 state to a few EAP conversations, distinguished by the EAP Session- 2292 Id. This prevents a rogue peer from denying access to other peers. 2294 Similarly, to conserve resources an authenticator may choose to limit 2295 the persistent state corresponding to each peer. This can be 2296 accomplished by limiting each peer to persistent state corresponding 2297 to a few EAP conversations, distinguished by the EAP Session-Id. 2299 Depending on the media, creation of new TSKs may or may not imply 2300 deletion of previously derived TSKs. Where there is no implied 2301 deletion, the authenticator may choose to limit the number of TSKs 2302 and associated state that can be stored for each peer. 2304 5.10. Impersonation 2306 Both the RADIUS [RFC2865] and Diameter [RFC3588] protocols are 2307 potentially vulnerable to impersonation by a rogue authenticator. 2308 While both protocols support mutual authentication between the 2309 authenticator/AAA client and the backend authentication server, the 2310 security mechanisms vary. 2312 In RADIUS, the shared secret used for authentication is determined by 2313 the source address of the RADIUS packet. As noted in [RFC3579] 2314 Section 4.3.7, it is highly desirable that the source address be 2315 checked against one or more NAS identification attributes so as to 2316 detect and prevent impersonation attacks. 2318 When RADIUS Access-Requests are forwarded by a proxy, the NAS-IP- 2319 Address or NAS-IPv6-Address attributes may not correspond to the 2320 source address. Since the NAS-Identifier attribute need not contain 2321 an FQDN, it also may not correspond to the source address, even 2322 indirectly. [RFC2865] Section 3 states: 2324 A RADIUS server MUST use the source IP address of the RADIUS 2325 UDP packet to decide which shared secret to use, so that 2326 RADIUS requests can be proxied. 2328 This implies that it is possible for a rogue authenticator to forge 2329 NAS-IP-Address, NAS-IPv6-Address or NAS-Identifier attributes within 2330 a RADIUS Access-Request in order to impersonate another 2331 authenticator. Among other things, this can result in messages (and 2332 transported keying material) being sent to the wrong authenticator. 2333 Since the rogue authenticator is authenticated by the RADIUS proxy or 2334 server purely based on the source address, other mechanisms are 2335 required to detect the forgery. In addition, it is possible for 2336 attributes such as the Called-Station-Id and Calling-Station-Id to be 2337 forged as well. 2339 [RFC3579] Section 4.3.7 describes how an EAP pass-through 2340 authenticator acting as a AAA client can be detected if it attempts 2341 to impersonate another authenticator (such by sending incorrect 2342 Called-Station-Id [RFC2865], NAS-Identifier [RFC2865], NAS-IP-Address 2343 [RFC2865] or NAS-IPv6-Address [RFC3162] attributes via the AAA 2344 protocol). This vulnerability can be mitigated by having RADIUS 2345 proxies check NAS identification attributes against the source 2346 address. 2348 While [RFC3588] requires use of the Route-Record AVP, this utilizes 2349 Fully Qualified Domain Names (FQDNs), so that impersonation detection 2350 requires DNS A, AAAA and PTR Resource Records (RRs) to be properly 2351 configured. As a result, Diameter is as vulnerable to this attack as 2352 RADIUS, if not more so. To address this vulnerability, it is 2353 necessary to allow the backend authentication server to communicate 2354 with the authenticator directly, such as via the redirect 2355 functionality supported in [RFC3588]. 2357 5.11. Channel Binding 2359 It is possible for a compromised or poorly implemented EAP 2360 authenticator to communicate incorrect information to the EAP peer 2361 and/or server. This may enable an authenticator to impersonate 2362 another authenticator or communicate incorrect information via out- 2363 of-band mechanisms (such as via AAA or the lower layer). 2365 Where EAP is used in pass-through mode, the EAP peer does not verify 2366 the identity of the pass-through authenticator. Within the Secure 2367 Association Protocol, the EAP peer and authenticator only demonstrate 2368 mutual possession of the transported EAP keying material. This 2369 creates a potential security vulnerability, described in [RFC3748] 2370 Section 7.15. 2372 As described in the previous section, it is possible for a proxy to 2373 detect a AAA client attempting to impersonate another authenticator 2374 (such by sending incorrect Called-Station-Id [RFC2865], NAS- 2375 Identifier [RFC2865], NAS-IP-Address [RFC2865] or NAS-IPv6-Address 2376 [RFC3162] attributes via the AAA protocol). However, it is possible 2377 for a pass-through authenticator acting as a AAA client to provide 2378 correct information to the backend authentication server while 2379 communicating misleading information to the EAP peer via the lower 2380 layer. 2382 For example, a compromised authenticator can utilize another 2383 authenticator's Called-Station-Id or NAS-Identifier in communicating 2384 with the EAP peer via the lower layer. Also, a pass-through 2385 authenticator acting as a AAA client can provide an incorrect peer 2386 Calling-Station-Id [RFC2865][RFC3580] to the backend authentication 2387 server via the AAA protocol. 2389 As noted in [RFC3748] Section 7.15, this vulnerability can be 2390 addressed by EAP methods that support a protected exchange of channel 2391 properties such as endpoint identifiers, including (but not limited 2392 to): Called-Station-Id [RFC2865][RFC3580], Calling-Station-Id 2393 [RFC2865][RFC3580], NAS-Identifier [RFC2865], NAS-IP-Address 2394 [RFC2865], and NAS-IPv6-Address [RFC3162]. 2396 Using such a protected exchange, it is possible to match the channel 2397 properties provided by the authenticator via out-of-band mechanisms 2398 against those exchanged within the EAP method. Typically the EAP 2399 method imports Channel Bindings from the lower layer on the peer, and 2400 transmits them securely to the EAP server, which exports them to the 2401 lower layer or AAA layer. However, transport may occur from EAP 2402 server to peer, or may be bi-directional. On the side of the 2403 exchange (peer or server) where Channel Bindings are verified, the 2404 lower layer or AAA layer passes the result of the verification (TRUE 2405 or FALSE) up to the EAP method. While the verification can be done 2406 either by the peer or the server, typically only the server has the 2407 knowledge to determine the correctness of the values, as opposed to 2408 merely verifying their equality. For further discussion, see [I- 2409 D.arkko-eap-service-identity-auth]. 2411 It is also possible to achieve Channel Bindings without transporting 2412 data over EAP. For example, see [I-D.draft-ohba-eap-channel- 2413 binding]. In this approach the EAP method includes Channel Bindings 2414 in the calculation of exported EAP keying material, making it 2415 impossible for the peer and authenticator to complete the Secure 2416 Association Protocol if there is a mismatch in the Channel Bindings. 2417 However, this approach can only be applied where EAP methods 2418 generating key material are used along with lower layers that utilize 2419 the keying material. For example, this mechanism would not enable 2420 verification of Channel Bindings on wired IEEE 802 networks using 2421 IEEE 802.1X. 2423 6. IANA Considerations 2425 This specification does not request the creation of any new parameter 2426 registries, nor does it require any other IANA assignments. 2428 7. References 2430 7.1. Normative References 2432 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2433 Requirement Levels", BCP 14, RFC 2119, March 1997. 2435 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 2436 Lefkowetz, "Extensible Authentication Protocol (EAP)", RFC 2437 3748, June 2004. 2439 7.2. Informative References 2441 [Analysis] He, C. and J. Mitchell, "Analysis of the 802.11i 4-Way 2442 Handshake", Proceedings of the 2004 ACM Workshop on 2443 Wireless Security, pp. 43-50, ISBN: 1-58113-925-X. 2445 [GKDP] Dondeti, L., Xiang, J. and S. Rowles, "GKDP: Group Key 2446 Distribution Protocol", Internet draft (work in progress), 2447 draft-ietf-msec-gkdp-01, March 2006. 2449 [GSAKMP] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP: 2450 Group Secure Association Group Management Protocol", 2451 Internet draft (work in progress), draft-ietf-msec-gsakmp- 2452 sec-10, May 2005. 2454 [He] He, C., Sundararajan, M., Datta, A. Derek, A. and J. C. 2455 Mitchell, "A Modular Correctness Proof of TLS and IEEE 2456 802.11i", ACM Conference on Computer and Communications 2457 Security (CCS '05), November, 2005. 2459 [IEEE-802.11] 2460 Institute of Electrical and Electronics Engineers, 2461 "Information technology - Telecommunications and 2462 information exchange between systems - Local and 2463 metropolitan area networks - Specific Requirements Part 11: 2464 Wireless LAN Medium Access Control (MAC) and Physical Layer 2465 (PHY) Specifications", IEEE IEEE Standard 802.11-2003, 2466 2003. 2468 [IEEE-802.1X] 2469 Institute of Electrical and Electronics Engineers, "Local 2470 and Metropolitan Area Networks: Port-Based Network Access 2471 Control", IEEE Standard 802.1X-2004, December 2004. 2473 [IEEE-802.1Q] 2474 Institute of Electrical and Electronics Engineers, "IEEE 2475 Standards for Local and Metropolitan Area Networks: Draft 2476 Standard for Virtual Bridged Local Area Networks", IEEE 2477 Standard 802.1Q/D8, January 1998. [IEEE802.11i] Institute 2478 of Electrical and Electronics Engineers, "Supplement to 2479 Standard for Telecommunications and Information Exchange 2480 Between Systems - LAN/MAN Specific Requirements - Part 11: 2481 Wireless LAN Medium Access Control (MAC) and Physical Layer 2482 (PHY) Specifications: Specification for Enhanced Security", 2483 IEEE 802.11i, July 2004. 2485 [IEEE-802.11F] 2486 Institute of Electrical and Electronics Engineers, 2487 "Recommended Practice for Multi-Vendor Access Point 2488 Interoperability via an Inter-Access Point Protocol Across 2489 Distribution Systems Supporting IEEE 802.11 Operation", 2490 IEEE 802.11F, July 2003 (now deprecated). 2492 [IEEE-802.16e] 2493 Institute of Electrical and Electronics Engineers, "IEEE 2494 Standard for Local and Metropolitan Area Networks: Part 16: 2495 Air Interface for Fixed and Mobile Broadband Wireless 2496 Access Systems: Amendment for Physical and Medium Access 2497 Control Layers for Combined Fixed and Mobile Operations in 2498 Licensed Bands" IEEE 802.16e, August 2005. 2500 [IEEE-02-758] 2501 Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, 2502 "Proactive Caching Strategies for IAPP Latency Improvement 2503 during 802.11 Handoff", IEEE 802.11 Working Group, 2504 IEEE-02-758r1-F Draft 802.11I/D5.0, November 2002. 2506 [IEEE-03-084] 2507 Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, 2508 "Proactive Key Distribution to support fast and secure 2509 roaming", IEEE 802.11 Working Group, IEEE-03-084r1-I, 2510 http://www.ieee802.org/11/Documents/DocumentHolder/ 2511 3-084.zip, January 2003. 2513 [I-D.housley-aaa-key-mgmt] 2514 Housley, R. and B. Aboba, "Guidance for AAA Key 2515 Management", draft-housley-aaa-key-mgmt-06.txt, Internet 2516 draft (work in progress), November 2006. 2518 [I-D.puthenkulam-eap-binding] 2519 Puthenkulam, J., "The Compound Authentication Binding 2520 Problem", draft-puthenkulam-eap-binding-04, Internet draft 2521 (work in progress), October 2003. 2523 [I-D.arkko-eap-service-identity-auth] 2524 Arkko, J. and P. Eronen, "Authenticated Service Information 2525 for the Extensible Authentication Protocol (EAP)", draft- 2526 arkko-eap-service-identity-auth-02.txt Internet draft (work 2527 in progress), May 2005. 2529 [I-D.ohba-eap-channel-binding] 2530 Ohba, Y., Parthasrathy, M. and M. Yanagiya, "Channel 2531 Binding Mechanism Based on Parameter Binding in Key 2532 Derivation", draft-ohba-eap-channel-binding-00.txt, 2533 Internet draft (work in progress), January 2006. 2535 [I-D.irtf-aaaarch-handoff] 2536 Arbaugh, W. and B. Aboba, "Handoff Extension to RADIUS", 2537 draft-irtf-aaaarch-handoff-04.txt, Internet draft (work in 2538 progress), October 2003. 2540 [MD5Collision] 2541 Klima, V., "Tunnels in Hash Functions: MD5 Collisions 2542 Within a Minute", Cryptology ePrint Archive, March 2006, 2543 http://eprint.iacr.org/2006/105.pdf 2545 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 2546 RFC 1661, July 1994. 2548 [RFC1968] Meyer, G. and K. Fox, "The PPP Encryption Control Protocol 2549 (ECP)", RFC 1968, June 1996. 2551 [RFC2230] Atkinson, R., "Key Exchange Delegation Record for the DNS", 2552 RFC 2230, November 1997. 2554 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 2555 (IKE)", RFC 2409, November 1998. 2557 [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D. 2558 and R. Wheeler, "A Method for Transmitting PPP Over 2559 Ethernet (PPPoE)", RFC 2516, February 1999. 2561 [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2562 2535, March 1999. 2564 [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", 2565 RFC 2548, March 1999. 2567 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 2568 Implementation in Roaming", RFC 2607, June 1999. 2570 [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication 2571 Protocol", RFC 2716, October 1999. 2573 [RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for 2574 specifying the location of services (DNS SRV)", RFC 2782, 2575 February 2000. 2577 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. 2578 Wellington, "Secret Key Transaction Authentication for DNS 2579 (TSIG)", RFC 2845, May 2000. 2581 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 2582 Authentication Dial In User Service (RADIUS)", RFC 2865, 2583 June 2000. 2585 [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures 2586 (SIG(0)s )", RFC 2931, September 2000. 2588 [RFC3007] Wellington, B., "Simple Secure Domain Name System (DNS) 2589 Dynamic Update", RFC 3007, November 2000. 2591 [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 2592 3162, August 2001. 2594 [RFC3547] Baugher, M., Weis, B., Hardjono, T. and H. Harney, "The 2595 Group Domain of Interpretation", RFC 3547, July 2003. 2597 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 2598 Dial In User Service) Support For Extensible Authentication 2599 Protocol (EAP)", RFC 3579, September 2003. 2601 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese, 2602 "IEEE 802.1X Remote Authentication Dial In User Service 2603 (RADIUS) Usage Guidelines", RFC 3580, September 2003. 2605 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. 2606 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 2608 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public 2609 Keys Used For Exchanging Symmetric Keys", RFC 3766, April 2610 2004. 2612 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M. and K. 2613 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 2614 August 2004. 2616 [RFC4005] Calhoun, P., Zorn, G., Spence, D. and D. Mitton, "Diameter 2617 Network Access Server Application", RFC 4005, August 2005 2619 [RFC4017] Stanley, D., Walker, J. and B. Aboba, "EAP Method 2620 Requirements for Wireless LANs", RFC 4017, March 2005. 2622 [RFC4067] Loughney, J., Nakhjiri, M., Perkins, C. and R. Koodli, 2623 "Context Transfer Protocol (CXTP)", RFC 4067, July 2005. 2625 [RFC4072] Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible 2626 Authentication Protocol (EAP) Application", RFC 4072, 2627 August 2005. 2629 [RFC4118] Yang, L., Zerfos, P. and E. Sadot, "Architecture Taxonomy 2630 for Control and Provisioning of Wireless Access Points 2631 (CAPWAP)", RFC 4118, June 2005. 2633 [RFC4186] Haverinen, H. and J. Salowey, "Extensible Authentication 2634 Protocol Method for Global System for Mobile Communications 2635 (GSM) Subscriber Identity Modules (EAP-SIM)", RFC 4186, 2636 January 2006. 2638 [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication 2639 Protocol Method for 3rd Generation Authentication and Key 2640 Agreement (EAP-AKA)", RFC 4187, January 2006. 2642 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 2643 4306, December 2005. 2645 [RFC4372] Adrangi, F., Lior, A., Korhonen, J. and J. Loughney, 2646 "Chargeable User Identity", RFC 4372, January 2006. 2648 [RFC4334] Housley, R. and T. Moore, "Certificate Extensions and 2649 Attributes Suporting Authentication in Point-to-Point 2650 Protocol (PPP) and Wireless Local Area Neworks (WLAN)", RFC 2651 4334, February 2006. 2653 [RFC4763] Vanderveen, M. and H. Soliman, "Extensible Authentication 2654 Protocol Method for Shared-secret Authentication and Key 2655 Establishment (EAP-SAKE)", RFC 4763, November 2006. 2657 [RFCPSK] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: a 2658 Pre-Shared Key EAP Method", Internet draft (work in 2659 progress), draft-bersani-eap-psk-11.txt, June 2006. 2661 [SP800-57] National Institute of Standards and Technology, 2662 "Recommendation for Key Management", Special Publication 2663 800-57, May 2006. 2665 [8021XHandoff] 2666 Pack, S. and Y. Choi, "Pre-Authenticated Fast Handoff in a 2667 Public Wireless LAN Based on IEEE 802.1X Model", School of 2668 Computer Science and Engineering, Seoul National 2669 University, Seoul, Korea, 2002. 2671 Acknowledgments 2673 Thanks to Ashwin Palekar, and Tim Moore of Microsoft, Jari Arkko of 2674 Ericsson, Dorothy Stanley of Aruba Networks, Bob Moskowitz of 2675 TruSecure, Jesse Walker of Intel, Joe Salowey of Cisco and Russ 2676 Housley of Vigil Security for useful feedback. 2678 Authors' Addresses 2680 Bernard Aboba 2681 Microsoft Corporation 2682 One Microsoft Way 2683 Redmond, WA 98052 2685 EMail: bernarda@microsoft.com 2686 Phone: +1 425 706 6605 2687 Fax: +1 425 936 7329 2689 Dan Simon 2690 Microsoft Research 2691 Microsoft Corporation 2692 One Microsoft Way 2693 Redmond, WA 98052 2695 EMail: dansimon@microsoft.com 2696 Phone: +1 425 706 6711 2697 Fax: +1 425 936 7329 2699 Pasi Eronen 2700 Nokia Research Center 2701 P.O. Box 407 2702 FIN-00045 Nokia Group 2703 Finland 2705 EMail: pasi.eronen@nokia.com 2707 Henrik Levkowetz 2708 Ericsson Research 2709 Torshamsgatan 23 2710 SE-164 80 Stockholm 2711 SWEDEN 2713 Phone: +46 7 08 32 16 08 2714 EMail: henrik@levkowetz.com 2716 Appendix A - Exported Parameters in Existing Methods 2718 This Appendix specifies Session-Id, Peer-Id, Server-Id and Key- 2719 Lifetime for EAP methods that have been published prior to this 2720 specification. Future EAP method specifications MUST include a 2721 definition of the Session-Id, Peer-Id, and Server-Id (could be the 2722 empty string). 2724 EAP-Identity 2726 The EAP-Identity method is defined in [RFC3748]. It does not derive 2727 keys, and therefore does not define the Session-Id. The Peer-Id 2728 exported by the Identity method is determined by the octets included 2729 within the EAP- Response/Identity. The Server-Id is the empty string 2730 (zero length). 2732 EAP-Notification 2734 The EAP-Notification method is defined in [RFC3748]. It does not 2735 derive keys and therefore does not define the Session-Id. The Peer- 2736 Id and Server-Id are the empty string (zero length). 2738 EAP-GTC 2740 The EAP-GTC method is defined in [RFC3748]. It does not derive keys 2741 and therefore does not define the Session-Id. The Peer-Id and 2742 Server-Id are the empty string. 2744 EAP-OTP 2746 The EAP-OTP method is defined in [RFC3748]. It does not derive keys 2747 and therefore does not define the Session-Id. The Peer-Id and 2748 Server-Id are the empty string. 2750 EAP-TLS 2752 EAP-TLS is defined in [RFC2716]. The EAP-TLS Session-Id is the 2753 concatenation of the EAP Type Code (0x0D) with the peer and server 2754 nonces. The Peer-Id and Server-Id are the contents of the 2755 altSubjectName in the peer and server certificates. 2757 EAP-AKA 2759 EAP-AKA is defined in [RFC4187]. The EAP-AKA Session-Id is the 2760 concatenation of the EAP Type Code (0x17) with the contents of the 2761 RAND field from the AT_RAND attribute, followed by the contents of 2762 the AUTN field in the AT_AUTN attribute. 2764 The Peer-Id is the contents of the Identity field from the 2765 AT_IDENTITY attribute, using only the Actual Identity Length octets 2766 from the beginning, however. Note that the contents are used as they 2767 are transmitted, regardless of whether the transmitted identity was a 2768 permanent, pseudonym, or fast EAP re-authentication identity. The 2769 Server-Id is an empty string. 2771 EAP-SIM 2773 EAP-SIM is defined in [RFC4186]. The EAP-SIM Session-Id is the 2774 concatenation of the EAP Type Code (0x12) with the contents of the 2775 RAND field from the AT_RAND attribute, followed by the contents of 2776 the NONCE_MT field in the AT_NONCE_MT attribute. 2778 The Peer-Id is the contents of the Identity field from the 2779 AT_IDENTITY attribute, using only the Actual Identity Length octets 2780 from the beginning, however. Note that the contents are used as they 2781 are transmitted, regardless of whether the transmitted identity was a 2782 permanent, pseudonym, or fast EAP re-authentication identity. The 2783 Server-Id is an empty string. 2785 EAP-PSK 2787 EAP-PSK is defined in [RFCPSK]. The EAP-PSK Session-Id is the 2788 concatenation of the EAP Type Code (0x2F) with the peer (RAND_P) and 2789 server (RAND_S) nonces. The Peer-Id is the contents of the ID_P 2790 field and the Server-Id is the contents of the ID_S field. 2792 EAP-SAKE 2794 EAP-SAKE is defined in [RFC4763]. The EAP-SAKE Session-Id is the 2795 concatenation of the EAP Type Code (0x30) with the contents of the 2796 RAND_S field from the AT_RAND_S attribute, followed by the contents 2797 of the RAND_P field in the AT_RAND_P attribute. Note that the EAP- 2798 SAKE Session-Id is not the same as the "Session ID" parameter chosen 2799 by the Server, which is sent in the first message, and replicated in 2800 subsequent messages. The Peer-Id is contained within the value field 2801 of the AT_PEERID attibute and the Server-Id, if available, is 2802 contained in the value field of the AT_SERVERID attribute. 2804 Intellectual Property Statement 2806 The IETF takes no position regarding the validity or scope of any 2807 Intellectual Property Rights or other rights that might be claimed to 2808 pertain to the implementation or use of the technology described in 2809 this document or the extent to which any license under such rights 2810 might or might not be available; nor does it represent that it has 2811 made any independent effort to identify any such rights. Information 2812 on the procedures with respect to rights in RFC documents can be 2813 found in BCP 78 and BCP 79. 2815 Copies of IPR disclosures made to the IETF Secretariat and any 2816 assurances of licenses to be made available, or the result of an 2817 attempt made to obtain a general license or permission for the use of 2818 such proprietary rights by implementers or users of this 2819 specification can be obtained from the IETF on-line IPR repository at 2820 http://www.ietf.org/ipr. 2822 The IETF invites any interested party to bring to its attention any 2823 copyrights, patents or patent applications, or other proprietary 2824 rights that may cover technology that may be required to implement 2825 this standard. Please address the information to the IETF at ietf- 2826 ipr@ietf.org. 2828 Disclaimer of Validity 2830 This document and the information contained herein are provided on an 2831 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2832 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2833 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2834 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2835 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2836 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2838 Copyright Statement 2840 Copyright (C) The IETF Trust (2007). This document is subject to the 2841 rights, licenses and restrictions contained in BCP 78, and except as 2842 set forth therein, the authors retain all their rights. 2844 Acknowledgment 2846 Funding for the RFC Editor function is currently provided by the 2847 Internet Society. 2849 Open Issues 2851 Open issues relating to this specification are tracked on the 2852 following web site: 2854 http://www.drizzle.com/~aboba/EAP/