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