idnits 2.17.1 draft-ietf-eap-keying-10.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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2621. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2598. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2605. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2611. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 55 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 56 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC3748]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 751 has weird spacing: '... enable inter...' == Line 753 has weird spacing: '... the lower ...' == Line 1196 has weird spacing: '...enerate fresh...' == Line 1457 has weird spacing: '...aterial may b...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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) -- Looks like a reference, but probably isn't: '1' on line 1728 -- Looks like a reference, but probably isn't: '2' on line 1732 == Missing Reference: 'RFC2230' is mentioned on line 631, but not defined == Missing Reference: 'IEEE-802.1X-2004' is mentioned on line 760, but not defined -- Looks like a reference, but probably isn't: '3' on line 1739 -- Looks like a reference, but probably isn't: '4' on line 1742 -- Looks like a reference, but probably isn't: '5' on line 1746 -- Looks like a reference, but probably isn't: '6' on line 1751 == Missing Reference: 'RFC 3748' is mentioned on line 1298, but not defined == Missing Reference: 'RFC3759' is mentioned on line 1450, but not defined == Missing Reference: 'RFC3784' is mentioned on line 1719, but not defined ** Obsolete undefined reference: RFC 3784 (Obsoleted by RFC 5305) -- Looks like a reference, but probably isn't: '7' on line 1753 -- Looks like a reference, but probably isn't: '8' on line 1759 == Missing Reference: 'RFC3162' is mentioned on line 2195, but not defined == Unused Reference: 'RFC2434' is defined on line 2230, but no explicit reference was found in the text == Unused Reference: 'DESMODES' is defined on line 2249, but no explicit reference was found in the text == Unused Reference: 'FIPSDES' is defined on line 2254, but no explicit reference was found in the text == Unused Reference: 'IEEE-802' is defined on line 2261, but no explicit reference was found in the text == Unused Reference: 'IEEE-02-758' is defined on line 2308, but no explicit reference was found in the text == Unused Reference: 'IEEE-03-084' is defined on line 2314, but no explicit reference was found in the text == Unused Reference: 'IEEE-03-155' is defined on line 2321, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roamops-cert' is defined on line 2326, but no explicit reference was found in the text == Unused Reference: 'I-D.arkko-pppext-eap-aka' is defined on line 2335, but no explicit reference was found in the text == Unused Reference: 'I-D.arkko-eap-service-identity-auth' is defined on line 2339, but no explicit reference was found in the text == Unused Reference: 'I-D.ohba-eap-aaakey-binding' is defined on line 2345, but no explicit reference was found in the text == Unused Reference: 'RFC0793' is defined on line 2353, but no explicit reference was found in the text == Unused Reference: 'RFC2104' is defined on line 2362, but no explicit reference was found in the text == Unused Reference: 'RFC2246' is defined on line 2365, but no explicit reference was found in the text == Unused Reference: 'RFC2401' is defined on line 2369, but no explicit reference was found in the text == Unused Reference: 'RFC2409' is defined on line 2372, but no explicit reference was found in the text == Unused Reference: 'RFC2419' is defined on line 2375, but no explicit reference was found in the text == Unused Reference: 'RFC2420' is defined on line 2378, but no explicit reference was found in the text == Unused Reference: 'RFC2607' is defined on line 2391, but no explicit reference was found in the text == Unused Reference: 'RFC3078' is defined on line 2415, but no explicit reference was found in the text == Unused Reference: 'RFC3079' is defined on line 2418, but no explicit reference was found in the text == Unused Reference: '8021XHandoff' is defined on line 2457, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) == Outdated reference: A later version (-09) exists of draft-housley-aaa-key-mgmt-01 -- Unexpected draft version: The latest known version of draft-ietf-roamops-cert is -01, but you're referring to -02. == Outdated reference: A later version (-16) exists of draft-arkko-pppext-eap-aka-15 == Outdated reference: A later version (-04) exists of draft-arkko-eap-service-identity-auth-02 == Outdated reference: A later version (-01) exists of draft-ohba-eap-aaakey-binding-00 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Obsolete informational reference (is this intentional?): RFC 2716 (Obsoleted by RFC 5216) -- Obsolete informational reference (is this intentional?): RFC 2845 (Obsoleted by RFC 8945) -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 4005 (Obsoleted by RFC 7155) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) Summary: 6 errors (**), 0 flaws (~~), 41 warnings (==), 26 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 J. Arkko 6 5 March 2006 Ericsson 7 P. Eronen 8 Nokia 9 H. Levkowetz, Ed. 10 ipUnplugged 12 Extensible Authentication Protocol (EAP) Key Management Framework 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 22, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society 2006. 41 Abstract 43 The Extensible Authentication Protocol (EAP), defined in [RFC3748], 44 enables extensible network access authentication. This document 45 provides a framework for the transport and usage of keying material 46 generated by EAP authentication algorithms, known as "methods". It 47 also specifies the EAP key hierarchy. 49 Table of Contents 51 1. Introduction .......................................... 3 52 1.1 Requirements Language ........................... 3 53 1.2 Terminology ..................................... 3 54 1.3 Overview ........................................ 5 55 1.4 EAP Invariants .................................. 9 56 2. Lower Layer Operation ................................. 12 57 2.1 Overview ........................................ 12 58 2.2 Layering ........................................ 14 59 2.3 Transient Session Keys .......................... 16 60 2.4 Authenticator Architecture ...................... 19 61 2.5 Key Scope ....................................... 22 62 3. Key Management ........................................ 24 63 3.1 Secure Association Protocol ..................... 24 64 3.2 Parent-Child Relationships ...................... 27 65 3.3 Local Key Lifetimes ............................. 27 66 3.4 Exported and Calculated Key Lifetimes ........... 28 67 3.5 Key Cache Synchronization ....................... 29 68 3.6 Key Strength .................................... 30 69 3.7 Key Wrap ........................................ 31 70 4. Handoff Vulnerabilities ............................... 31 71 4.1 Authorization ................................... 32 72 4.2 Correctness ..................................... 33 73 5. Security Considerations .............................. 36 74 5.1 Security Terminology ............................ 36 75 5.2 Threat Model .................................... 36 76 5.3 Authenticator Compromise ........................ 37 77 5.4 Spoofing ........................................ 38 78 5.5 Downgrade Attacks ............................... 39 79 5.6 Unauthorized Disclosure ......................... 39 80 5.7 Replay Protection ............................... 41 81 5.8 Key Freshness ................................... 42 82 5.9 Elevation of Privilege .......................... 43 83 5.10 Man-in-the-Middle Attacks ....................... 44 84 5.11 Denial of Service Attacks ....................... 44 85 5.12 Impersonation ................................... 45 86 5.13 Channel Binding ................................. 46 87 6. IANA Considerations ................................... 47 88 7. References ............................................ 47 89 7.1 Normative References ............................ 47 90 7.2 Informative References .......................... 47 91 Acknowledgments .............................................. 52 92 Author's Addresses ........................................... 53 93 Appendix A - Exported Parameters in Existing Methods ......... 54 94 Intellectual Property Statement .............................. 55 95 Disclaimer of Validity ....................................... 56 96 Copyright Statement .......................................... 56 98 1. Introduction 100 The Extensible Authentication Protocol (EAP), defined in [RFC3748], 101 was designed to enable extensible authentication for network access 102 in situations in which the IP protocol is not available. Originally 103 developed for use with PPP [RFC1661], it has subsequently also been 104 applied to IEEE 802 wired networks [IEEE-802.1X]. 106 This document provides a framework for the transport and usage of 107 keying material generated by EAP authentication algorithms, known as 108 "methods". In EAP, keying material is generated by EAP methods. 109 Part of this keying material may be used by EAP methods themselves 110 and part of this material may be exported. The exported keying 111 material may be transported by AAA protocols or used by Secure 112 Association Protocols in the generation or transport of session keys 113 which are used by lower layer ciphersuites. This document describes 114 each of these elements and provides a system-level security analysis. 115 It also specifies the EAP key hierarchy. 117 1.1. Requirements Language 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in BCP 14 [RFC2119]. 123 1.2. Terminology 125 This document frequently uses the following terms: 127 authenticator 128 The end of the link initiating EAP authentication. The term 129 Authenticator is used in [IEEE-802.1X], and authenticator has the 130 same meaning in this document. 132 peer The end of the link that responds to the authenticator. In 133 [IEEE-802.1X], this end is known as the Supplicant. 135 Supplicant 136 The end of the link that responds to the authenticator in 137 [IEEE-802.1X]. In this document, this end of the link is called 138 the peer. 140 backend authentication server 141 A backend authentication server is an entity that provides an 142 authentication service to an authenticator. When used, this server 143 typically executes EAP methods for the authenticator. This 144 terminology is also used in [IEEE-802.1X]. 146 AAA Authentication, Authorization and Accounting. AAA protocols with 147 EAP support include RADIUS [RFC3579] and Diameter [RFC4072]. In 148 this document, the terms "AAA server" and "backend authentication 149 server" are used interchangeably. 151 EAP server 152 The entity that terminates the EAP authentication method with the 153 peer. In the case where no backend authentication server is used, 154 the EAP server is part of the authenticator. In the case where the 155 authenticator operates in pass-through mode, the EAP server is 156 located on the backend authentication server. 158 security association 159 A set of policies and cryptographic state used to protect 160 information. Elements of a security association may include 161 cryptographic keys, negotiated ciphersuites and other parameters, 162 counters, sequence spaces, authorization attributes, etc. 164 Long Term Credential 165 EAP methods frequently make use of long term secrets in order to 166 enable authentication between the peer and server. In the case of 167 a method based on pre-shared key authentication, the long term 168 credential is the pre-shared key. In the case of a public-key 169 based method, the long term credential is the corresponding private 170 key. 172 Master Session Key (MSK) 173 Keying material that is derived between the EAP peer and server and 174 exported by the EAP method. The MSK is at least 64 octets in 175 length. 177 Extended Master Session Key (EMSK) 178 Additional keying material derived between the peer and server that 179 is exported by the EAP method. The EMSK is at least 64 octets in 180 length, and is never shared with a third party. 182 Initialization Vector (IV) 183 A quantity of at least 64 octets, suitable for use in an 184 initialization vector field, that is derived between the peer and 185 EAP server. Since the IV is a known value in methods such as EAP- 186 TLS [RFC2716], it cannot be used by itself for computation of any 187 quantity that needs to remain secret. As a result, its use has 188 been deprecated and EAP methods are not required to generate it. 189 However, when it is generated it MUST be unpredictable. 191 Pairwise Master Key (PMK) 192 Lower layers use MSK in lower-layer dependent manner. For 193 instance, in [IEEE-802.11i] Octets 0-31 of the MSK are known as the 194 Pairwise Master Key (PMK). In [IEEE-802.11i] the TKIP and AES CCMP 195 ciphersuites derive their Transient Session Keys (TSKs) solely from 196 the PMK, whereas the WEP ciphersuite as noted in [RFC3580], derives 197 its TSKs from both halves of the MSK. In [802.16e], the MSK is 198 truncated to 40 octets for PMK and 20 octets for PMK2. 200 Transient EAP Keys (TEKs) 201 Session keys which are used to establish a protected channel 202 between the EAP peer and server during the EAP authentication 203 exchange. The TEKs are appropriate for use with the ciphersuite 204 negotiated between EAP peer and server for use in protecting the 205 EAP conversation. The TEKs are stored locally by the EAP method 206 and are not exported. Note that the ciphersuite used to set up the 207 protected channel between the EAP peer and server during EAP 208 authentication is unrelated to the ciphersuite used to subsequently 209 protect data sent between the EAP peer and authenticator. 211 Transient Session Keys (TSKs) 212 Session keys used to protect data exchanged after EAP 213 authentication has successfully completed, using the ciphersuite 214 negotiated between the EAP peer and authenticator. 216 AAA-Key 217 The term AAA-Key is synonymous with MSK. 219 1.3. Overview 221 EAP, defined in [RFC3748], is a two-party protocol spoken between the 222 EAP peer and server. Within EAP, keying material is generated by EAP 223 methods. Part of this keying material may be used by EAP methods 224 themselves and part of this material may be exported. In addition to 225 export of keying material, EAP methods may also export associated 226 parameters, and may import and export Channel Bindings from the lower 227 layer. 229 As illustrated in Figure 1, the EAP method key derivation has at the 230 root the long term credential utilized by the selected EAP method. 231 If authentication is based on a pre-shared key, the parties store the 232 EAP method to be used and the pre-shared key. The EAP server also 233 stores the peer's identity as well as other information associated 234 with it. This information may be used to determine whether access to 235 some service should be granted. The peer stores information necessary 236 to choose which secret to use for which service. 238 If authentication is based on proof of possession of the private key 239 corresponding to the public key contained within a certificate, the 240 parties store the EAP method to be used and the trust anchors used to 241 validate the certificates. The EAP server also stores the peer's 242 identity and the peer stores information necessary to choose which 243 certificate to use for which service. 245 Based on the long term credential established between the peer and 246 the server, EAP methods derive two types of keys: 248 [1] Keys calculated locally by the EAP method but not exported 249 by the EAP method, such as the TEKs. 250 [2] Keying material exported by the EAP method: MSK, EMSK, IV. 252 As noted in [RFC3748] Section 7.10, EAP methods generating keys are 253 required to calculate and export the MSK and EMSK, which must be at 254 least 64 octets in length. EAP methods also may export the IV; 255 however, the use of the IV is deprecated. 257 EAP methods also MAY export method-specific peer and server 258 identifiers (peer-ID and server-ID), a method-specific EAP 259 conversation identifier known as the Method-ID, and the lifetime of 260 the exported keys, known as the Key-Lifetime. EAP methods MAY also 261 support the import and export of Channel Bindings. New EAP method 262 specifications MUST define the Peer-ID, Server-ID and Method-ID. The 263 combination of the Peer-ID and Server-ID uniquely specifies the 264 endpoints of the EAP method exchange when they are provided. 266 Peer-ID 268 As described in [RFC3748] Section 7.3, the identity provided in the 269 EAP-Response/Identity, may be different from the peer identity 270 authenticated by the EAP method. Where the EAP method authenticates 271 the peer identity, that identity is exported by the method as the 272 Peer-ID. A suitable EAP peer name may not always be available. 273 Where an EAP method does not define a method-specific peer identity, 274 the Peer-ID is the null string. The Peer-ID for existing EAP 275 methods is defined in Appendix A. 277 Server-ID 279 Where the EAP method authenticates the server identity, that identity 280 is exported by the method as the Server-ID. A suitable EAP server 281 name may not always be available. Where an EAP method does not 282 define a method-specific peer identity, the Server-ID is the null 283 string. The Server-ID for existing EAP methods is defined in 284 Appendix A. 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 287 | | ^ 288 | EAP Method | | 289 | | | 290 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | | 291 | | | | | | | 292 | | EAP Method Key |<->| Long-Term | | | 293 | | Derivation | | Credential | | | 294 | | | | | | | 295 | | | +-+-+-+-+-+-+-+ | Local to | 296 | | | | EAP | 297 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Method | 298 | | | | | | 299 | | | | | | 300 | | | | | | 301 | | | | | | 302 | | | | | | 303 | | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | | 304 | | | TEK | |MSK, EMSK | |IV | | | 305 | | |Derivation | |Derivation | |Derivation | | | 306 | | | | | | |(Deprecated) | | | 307 | | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | | 308 | | ^ | | | | 309 | | | | | | V 310 +-+-|-+-+-+-+-+-+-+-+-|-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+ ---+ 311 | | | | ^ 312 | Peer-ID, | | | Exported | 313 | Server-ID, | Channel | MSK (64+B) | IV (64B) by | 314 | Method-ID, | Bindings | EMSK (64+B) | (Optional) EAP | 315 | Key-Lifetime | & Result | | Method | 316 V V V V V 318 Figure 1: EAP Method Parameter Import/Export 320 Method-ID 322 EAP method specifications deriving keys MUST specify a temporally 323 unique method identifier known as the Method-ID. The EAP Method-ID 324 uniquely identifies an EAP session of a given Type between an EAP 325 peer and server. The Method-ID is typically constructed from nonces 326 or counters used within the EAP method exchange. The Method-ID for 327 existing EAP methods is defined in Appendix A. 329 Session-ID 331 The Session-ID uniquely identifies an EAP session between an EAP peer 332 (as identified by the Peer-ID) and server (as identified by the 333 Server-ID). The EAP Session-ID consists of the concatenation of the 334 Expanded EAP Type Code (including the Type, Vendor-ID and Vendor-Type 335 fields defined in [RFC3748] Section 5.7) and the Method-ID. The 336 inclusion of the Expanded Type Code in the EAP Session-Id ensures 337 that each EAP method has a distinct Session-ID space. Since an EAP 338 session is not bound to a particular authenticator or specific ports 339 on the peer and authenticator, the authenticator port or identity are 340 not included in the Session-Id. 342 Key-Lifetime 344 While EAP itself does not support key lifetime negotiation, it is 345 possible to specify methods that do. However, systems that rely on 346 such negotiation for exported keys would only function with these 347 methods. As a result, it is NOT RECOMMENDED to use this approach as 348 the sole way to determine key lifetimes. 350 Channel Bindings 352 Channel Bindings include lower layer parameters that are verified for 353 consistency between the EAP peer and server. In order to avoid 354 introducing media dependencies, EAP methods that transport Channel 355 Binding data MUST treat this data as opaque octets. Typically the 356 EAP method imports Channel Bindings from the lower layer on the peer, 357 and transmits them securely to the EAP server, which exports them to 358 the lower layer. However, transport may occur from EAP server to 359 peer, or may be bi-directional. On the side of the exchange (peer or 360 server) where Channel Bindings are verified, the lower layer passes 361 the result of the verification (TRUE or FALSE) up to the EAP method. 363 1.3.1. Key Naming 365 Each key created within the EAP key management framework has a name 366 (a unique identifier), as well as a scope (the parties to whom the 367 key is available). The scope of exported parameters is defined by 368 the EAP peer name (if securely exchanged within the method) and the 369 EAP server name (also only if securely exchanged). Where a peer or 370 server name is missing the null string is used. 372 MSK and EMSK Names 373 These parameters are exported by the EAP peer and EAP server, and 374 can be referred to using the EAP Session-ID and a binary or textual 375 indication of the parameter being referred to. 377 PMK Name 378 This document does not specify a naming scheme for the PMK. The 379 PMK is only identified by the key from which it is derived. 381 Note: IEEE 802.11i names the PMKID for the purposes of being able 382 to refer to it in the Secure Association protocol; this naming is 383 based on a hash of the PMK itself as well as some other parameters 384 (see Section 8.5.1.2 [IEEE-802.11i]). 386 TEK Name 387 The TEKs may or may not be named. Their naming is specified in the 388 EAP method. 390 TSK Name 391 The TSKs are typically named. Their naming is specified in the 392 lower layer so that the correct set of transient session keys can 393 be identified for processing a given packet. 395 1.4. EAP Invariants 397 Certain basic characteristics, known as "EAP Invariants", hold true 398 for EAP implementations on all media: 400 Mode independence 401 Media independence 402 Method independence 403 Ciphersuite independence 405 1.4.1. Mode Independence 407 EAP is typically deployed in order to support extensible network 408 access authentication in situations where a peer desires network 409 access via one or more authenticators. Where authenticators are 410 deployed standalone, the EAP conversation occurs between the peer and 411 authenticator, and the authenticator must locally implement an EAP 412 method acceptable to the peer. However, one of the advantages of EAP 413 is that it enables deployment of new authentication methods without 414 requiring development of new code on the authenticator. 416 While the authenticator may implement some EAP methods locally and 417 use those methods to authenticate local users, it may at the same 418 time act as a pass-through for other users and methods, forwarding 419 EAP packets back and forth between the backend authentication server 420 and the peer. This is accomplished by encapsulating EAP packets 421 within the Authentication, Authorization and Accounting (AAA) 422 protocol, spoken between the authenticator and backend authentication 423 server. AAA protocols supporting EAP include RADIUS [RFC3579] and 424 Diameter [RFC4072]. 426 It is a fundamental property of EAP that at the EAP method layer, the 427 conversation between the EAP peer and server is unaffected by whether 428 the EAP authenticator is operating in "pass-through" mode. EAP 429 methods operate identically in all aspects, including key derivation 430 and parameter import/export, regardless of whether the authenticator 431 is operating as a pass-through or not. 433 The successful completion of an EAP method that supports key 434 derivation results in the export of keying material on the EAP peer 435 and server. Even though the EAP peer or server may import Channel- 436 Bindings that may include the identity of the EAP authenticator, 437 this information is treated as opaque octets. As a result, within 438 EAP the only relevant identities are the Peer-ID and Server-ID. 439 Channel Bindings are only interpreted by the lower layer. 441 Within EAP, the primary function of the AAA protocol is to maintain 442 the principle of Mode Independence, so that as far as the EAP peer is 443 concerned, its conversation with the EAP authenticator, and all 444 consequences of that conversation, are identical, regardless of the 445 authenticator mode of operation. 447 1.4.2. Media Independence 449 One of the goals of EAP is to allow EAP methods to function on any 450 lower layer meeting the criteria outlined in [RFC3748], Section 3.1. 451 For example, as described in [RFC3748], EAP authentication can be run 452 over PPP [RFC1661], IEEE 802 wired networks [IEEE-802.1X], and IEEE 453 802.11 wireless LANs [IEEE-802.11i]. 455 In order to maintain media independence, it is necessary for EAP to 456 avoid consideration of media-specific elements. For example, EAP 457 methods cannot be assumed to have knowledge of the lower layer over 458 which they are transported, and cannot be restricted to identifiers 459 associated with a particular usage environment (e.g. MAC addresses). 461 Note that media independence may be retained within EAP methods that 462 support Channel-Bindings or method-specific identification. An EAP 463 method need not be aware of the content of an identifier in order to 464 use it. This enables an EAP method to use media-specific identifiers 465 such as MAC addresses without compromising media independence. 466 Channel-Bindings are treated as opaque octets by EAP methods, so that 467 handling them does not require media-specific knowledge. 469 1.4.3. Method Independence 471 By enabling pass-through, authenticators can support any method 472 implemented on the peer and server, not just locally implemented 473 methods. This allows the authenticator to avoid implementing code 474 for each EAP method required by peers. In fact, since a pass-through 475 authenticator is not required to implement any EAP methods at all, it 476 cannot be assumed to support any EAP method-specific code. 478 As a result, as noted in [RFC3748], authenticators must by default be 479 capable of supporting any EAP method. This is useful where there is 480 no single EAP method that is both mandatory-to-implement and offers 481 acceptable security for the media in use. For example, the [RFC3748] 482 mandatory-to-implement EAP method (MD5-Challenge) does not provide 483 dictionary attack resistance, mutual authentication or key 484 derivation, and as a result is not appropriate for use in wireless 485 LAN authentication [RFC4017]. However, despite this it is possible 486 for the peer and authenticator to interoperate as long as a suitable 487 EAP method is supported on the EAP server. 489 1.4.4. Ciphersuite Independence 491 Ciphersuite Independence is a requirement for Media Independence. 492 Since lower layer ciphersuites vary between media, media independence 493 requires that EAP keying material needs to be large enough (with 494 sufficient entropy) to handle any ciphersuite. 496 While EAP methods may negotiate the ciphersuite used in protection of 497 the EAP conversation, the ciphersuite used for the protection of the 498 data exchanged after EAP authentication has completed is negotiated 499 between the peer and authenticator within the lower layer, outside of 500 EAP. 502 For example, within PPP, the ciphersuite is negotiated within the 503 Encryption Control Protocol (ECP) defined in [RFC1968], after EAP 504 authentication is completed. Within [IEEE-802.11i], the AP 505 ciphersuites are advertised in the Beacon and Probe Responses prior 506 to EAP authentication, and are securely verified during a 4-way 507 handshake exchange. 509 Since the ciphersuites used to protect data depend on the lower 510 layer, requiring EAP methods have knowledge of lower layer 511 ciphersuites would compromise the principle of Media Independence. 512 Since ciphersuite negotiation occurs in the lower layer, there is no 513 need for ciphersuite negotiation within EAP, and EAP methods generate 514 keying material that is ciphersuite-independent. 516 Algorithms for deriving TSKs MUST NOT depend on the EAP method, 517 although algorithms for TEK derivation MAY be specific to the EAP 518 method. 520 In order to allow a ciphersuite to be usable within the EAP keying 521 framework, a specification MUST be provided describing how TSKs 522 suitable for use with the ciphersuite are derived from exported EAP 523 keying parameters. 525 Advantages of ciphersuite-independence include: 527 Reduced update requirements 528 If EAP methods were to specify how to derive transient session keys 529 for each ciphersuite, they would need to be updated each time a new 530 ciphersuite is developed. In addition, backend authentication 531 servers might not be usable with all EAP-capable authenticators, 532 since the backend authentication server would also need to be 533 updated each time support for a new ciphersuite is added to the 534 authenticator. 536 Reduced EAP method complexity 537 Requiring each EAP method to include ciphersuite-specific code for 538 transient session key derivation would increase method complexity 539 and result in duplicated effort. 541 Simplified configuration 542 The ciphersuite is negotiated between the peer and authenticator 543 outside of EAP. Where the authenticator operates in "pass-through" 544 mode, the EAP server is not a party to this negotiation, nor is it 545 involved in the data flow between the EAP peer and authenticator. 546 As a result, the EAP server may not have knowledge of the 547 ciphersuites and negotiation policies implemented by the peer and 548 authenticator, or be aware of the ciphersuite negotiated between 549 them. For example, since ECP negotiation occurs after 550 authentication, when run over PPP, the EAP peer and server may not 551 anticipate the negotiated ciphersuite and therefore this 552 information cannot be provided to the EAP method. 554 2. Lower Layer Operation 556 2.1. Overview 558 Where EAP key derivation is supported, the conversation typically 559 takes place in three phases: 561 Phase 0: Discovery 562 Phase 1: Authentication 563 1a: EAP authentication 564 1b: AAA Key Transport (optional) 565 Phase 2: Secure Association Establishment 566 2a: Unicast Secure Association 567 2b: Multicast Secure Association (optional) 569 Of these phases, Phase 0, 1b and Phase 2 are handled external to EAP. 570 Phases 0 and 2 are handled by the lower layer protocol and phase 1b 571 is typically handled by a AAA protocol. In the discovery phase 572 (phase 0), peers locate authenticators and discover their 573 capabilities. A peer may locate an authenticator providing access to 574 a particular network, or a peer may locate an authenticator behind a 575 bridge with which it desires to establish a Secure Association. 576 Discovery can occur manually or automatically, depending on the lower 577 layer over which EAP runs. 579 The authentication phase (phase 1) may begin once the peer and 580 authenticator discover each other. This phase, if it occurs, always 581 includes EAP authentication (phase 1a). Where the chosen EAP method 582 supports key derivation, in phase 1a EAP keying material is derived 583 on both the peer and the EAP server. 585 An additional step (phase 1b) is required in deployments which 586 include a backend authentication server, in order to transport keying 587 material from the backend authentication server to the authenticator. 588 In order to obey the principle of Mode Independence, where a backend 589 server is present, all keying material which is required by the lower 590 layer needs to be transported from the EAP server to the 591 authenticator. Since existing TSK derivation techniques depend 592 solely on the MSK, in existing implementations, this is the only 593 keying material replicated in the AAA key transport phase 1b. 595 Successful completion of EAP authentication and key derivation by a 596 peer and EAP server does not necessarily imply that the peer is 597 committed to joining the network associated with an EAP server. 598 Rather, this commitment is implied by the creation of a security 599 association between the EAP peer and authenticator, as part of the 600 Secure Association Protocol (phase 2). 602 The Secure Association exchange (phase 2) occurs between the peer and 603 authenticator in order to manage the creation and deletion of unicast 604 (phase 2a) and multicast (phase 2b) security associations between the 605 peer and authenticator. The conversation between the parties is 606 shown in Figure 2. 608 Existing EAP lower layers implement phase 0, 2a and 2b in different 609 ways: 611 PPP PPP, defined in [RFC1661] does not support discovery, nor does it 612 include a Secure Association Protocol. 614 PPPOE 615 PPPOE, defined in [RFC2516], includes support for a Discovery stage 616 (phase 0). In this step, the EAP peer sends a PPPoE Active 617 Discovery Initiation (PADI) packet to the broadcast address, 618 indicating the service it is requesting. The Access Concentrator 619 replies with a PPPOE Active Discovery Offer (PADO) packet 620 containing its name, the service name and an indication of the 621 services offered by the concentrator. The discovery phase is not 622 secured. PPPOE, like PPP, does not include a Secure Association 623 Protocol. 625 IKEv2 626 IKEv2, defined in [RFC4306], handles the derivation of unicast 627 security associations (phase 2a), while the derivation of multicast 628 security associations (phase 2b) is handled in a separate group key 629 management protocol, as described in [RFC4046]. Several mechanisms 630 have been proposed for discovery of IPsec security gateways. 631 [RFC2230] discusses the use of KX Resource Records (RRs) for IPsec 632 gateway discovery; while KX RRs are supported by many DNS server 633 implementations, they have not yet been widely deployed. 634 Alternatively, DNS SRV [RFC2782] can be used for this purpose. 635 Where DNS is used for gateway location, DNS security mechanisms 636 such as DNSSEC ([RFC2535], [RFC2931]), TSIG [RFC2845], and Simple 637 Secure Dynamic Update [RFC3007] are available. 639 IEEE 802.11i 640 IEEE 802.11, defined in [IEEE-802.11], handles discovery via the 641 Beacon and Probe Request/Response mechanisms. IEEE 802.11 access 642 points periodically announce their Service Set Identifiers (SSIDs) 643 as well as capabilities using Beacon frames. Stations can query 644 for access points by sending a Probe Request to the broadcast 645 address. Neither Beacon nor Probe Request/Response frames are 646 secured. The 4-way handshake defined in [IEEE-802.11i] enables the 647 derivation of unicast (phase 2a) and multicast/broadcast (phase 2b) 648 secure associations. Since the group key exchange transports a 649 group key from the access point to the station, two 4-way 650 handshakes may be required in order to support peer-to-peer 651 communications. 653 IEEE 802.1X-2004 654 IEEE 802.1X-2004, defined in [IEEE-802.1X-2004] does not support 655 discovery (phase 0), nor does it provide for derivation of unicast 656 or multicast secure associations. 658 2.2. Layering 660 As illustrated in Figure 3, on completion of EAP authentication, EAP 661 methods export the Master Session Key (MSK), Extended Master Session 662 Key (EMSK), Peer-ID, Server-ID, Session-ID and Key-Lifetime to the 663 EAP peer or authenticator layers. The Initialization Vector (IV) is 664 deprecated. 666 The EAP peer and authenticator layers MUST NOT modify or cache keying 667 material or parameters (including Channel Bindings) passing in either 668 direction between the EAP method layer and the EAP layer. The EAP 669 layer also MUST NOT cache keying material or parameters (including 670 Channel Bindings) passed to it, whether by the EAP peer/authenticator 671 layer, the lower layer or the AAA layer. 673 EAP peer Authenticator Auth. Server 674 -------- ------------- ------------ 675 |<----------------------------->| | 676 | Discovery (phase 0) | | 677 |<----------------------------->|<----------------------------->| 678 | EAP auth (phase 1a) | AAA pass-through (optional) | 679 | | | 680 | |<----------------------------->| 681 | | AAA Key transport | 682 | | (optional; phase 1b) | 683 |<----------------------------->| | 684 | Unicast Secure association | | 685 | (phase 2a) | | 686 | | | 687 |<----------------------------->| | 688 | Multicast Secure association | | 689 | (optional; phase 2b) | | 690 | | | 692 Figure 2: Conversation Overview 694 Based on the Method-ID exported by the EAP method, the EAP layer 695 forms the EAP Session-ID by concatenating the EAP Expanded Type with 696 the Method-ID. Together with the MSK, IV (deprecated), Peer-ID, 697 Server-ID, and Key-Lifetime, the EAP layer passes the Session-ID down 698 to the lower layer. The Method-ID is exported by EAP methods rather 699 than the Session-ID so as to prevent EAP methods from writing into 700 each other's Session- ID space. 702 The EMSK MUST NOT be provided to an entity outside the EAP server or 703 peer, nor is it permitted to pass any quantity to an entity outside 704 the EAP server or peer from which the EMSK could be computed without 705 breaking some cryptographic assumption, such as inverting a one-way 706 function. As noted in [RFC3748] Section 7.10: 708 The EMSK is reserved for future use and MUST remain on the EAP 709 peer and EAP server where it is derived; it MUST NOT be 710 transported to, or shared with, additional parties, or used to 711 derive any other keys. (This restriction will be relaxed in a 712 future document that specifies how the EMSK can be used.) 714 In order to preserve the security of keys derived within EAP methods, 715 lower layers MUST NOT export keys passed down by EAP methods. This 716 implies that EAP keying material or parameters passed down to a lower 717 layer are for the exclusive use of that lower layer and MUST NOT be 718 used within another lower layer. This prevents compromise of one 719 lower layer from compromising other applications using EAP keying 720 parameters. 722 EAP keying material and parameters provided to a lower layer MUST NOT 723 be transported to another entity. For example, EAP keying material 724 and parameters passed down to the EAP peer lower layer MUST NOT leave 725 the peer; EAP keying material and parameters passed down or 726 transported to the EAP authenticator lower layer MUST NOT leave the 727 authenticator. 729 On the EAP server, keying material requested by and passed down to 730 the AAA layer may be replicated to the AAA layer on the 731 authenticator. On the authenticator, the AAA layer may provide the 732 replicated keying material to the lower layer over which the EAP 733 authentication conversation took place. This enables "mode 734 independence" to be maintained. However, the EMSK MUST NOT be 735 transported by the AAA layer. 737 As illustrated in Figure 4, a AAA client receiving transported EAP 738 keying material and parameters passes them to the EAP authenticator 739 and EAP layers, which then provide them to the authenticator lower 740 layer using the same mechanisms that would be used if the EAP peer 741 and authenticator were conducting a stand-alone conversation. The 742 resulting key state in the lower layer is indistinguishable between 743 the standalone and pass-through cases, as required by the principle 744 of mode independence. 746 2.3. Transient Session Keys 748 Where explicitly supported by the lower layer, lower layers MAY cache 749 the exported EAP keying material and parameters and/or TSKs. The 750 structure of this key cache is defined by the lower layer. So as to 751 enable interoperability, new lower layer specifications MUST 752 describe EAP key caching behavior. Unless explicitly specified by 753 the lower layer, the EAP peer, server and authenticator MUST assume 754 that peers and authenticators do not cache exported EAP keying 755 parameters or TSKs. Existing EAP lower layers and AAA layers handle 756 the caching of EAP keying material and the generation of transient 757 session keys in different ways: 759 IEEE 802.1X-2004 760 IEEE 802.1X-2004, defined in [IEEE-802.1X-2004] does not support 761 caching of EAP keying material or parameters. Once EAP 762 authentication completes, it is assumed that EAP keying material 763 and parameters are discarded. 765 PPP PPP, defined in [RFC1661] does not support caching of EAP keying 766 material or parameters. PPP ciphersuites derive their TSKs 767 directly from the MSK, as described in [RFC2716]. This method is 768 NOT RECOMMENDED, since were PPP to support caching, this could 769 result in stale TSKs. As a result, once the PPP session is 770 terminated, EAP keying material and parameters MUST be discarded. 771 Since caching of EAP keying material is not permitted, within PPP 772 there is no way to handle TSK rekey without EAP re-authentication. 773 Perfect Forward Secrecy (PFS) is only possible within PPP if the 774 negotiated EAP method supports this. 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 | | 778 | | 779 | EAP method | 780 | | 781 | MSK, EMSK, Peer-ID, Channel | 782 | Server-ID, Method-ID Bindings | 783 | IV (deprecated), | 784 | Key-Lifetime | 785 | | 786 | V ^ ^ | 787 +-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+ 788 | ! ! ! | 789 | EAP ! Peer or Authenticator ! ! | 790 | ! layer ! ! | 791 | ! ! ! | 792 +-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+ 793 | ! ! ! | 794 | EAP ! layer ! ! | 795 | ! ! ! | 796 | ! Session-ID = ! ! | 797 | ! Expanded-Type || ! ! | 798 | ! Method-ID ! ! | 799 | ! ! ! | 800 +-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+ 801 | ! ! ! | 802 | Lower ! layer or AAA ! ! | 803 | ! ! ! | 804 | V V ^ | 805 | MSK, Peer-ID, Channel Result | 806 | Server-ID, Bindings | 807 | Session-ID, | 808 | Key-Lifetime, | 809 | IV (deprecated) | 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 Figure 3: Flow of EAP parameters 813 Peer Pass-through Authenticator Authentication 814 Server 816 +-+-+-+-+-+-+ +-+-+-+-+-+-+ 817 | | | | 818 |EAP method | |EAP method | 819 | V | | V | 820 +-+-+-!-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+ 821 | ! | |EAP | EAP | | | ! | 822 | ! | |Peer | Auth.| EAP Auth. | | ! | 823 |EAP ! peer| | | +-----------+ | |EAP !Auth.| 824 | ! | | | ! | ! | | ! | 825 +-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+ 826 | ! | | ! | ! | | ! | 827 |EAP !layer| | EAP !layer| EAP !layer | |EAP !layer| 828 | ! | | ! | ! | | ! | 829 +-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+ 830 | V | | V | ! | | ! | 831 |Lower layer| | Lower layer| AAA ! /IP | | AAA ! /IP | 832 | | | | ! | | ! | 833 +-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+ 834 ! ! 835 ! ! 836 +---------<-------+ 838 Figure 4: Flow of EAP Keying Material and Parameters 840 IKEv2 841 IKEv2, defined in [RFC4306] only uses the MSK for authentication 842 purposes and not key derivation. The EMSK, IV, Peer-ID, Server-ID 843 or Session-ID are not used. As a result, the keying material 844 derived within IKEv2 is independent of the EAP keying material and 845 rekey of IPsec SAs can be handled without requiring EAP re- 846 authentication. Since generation of keying material is independent 847 of EAP, within IKEv2 it is possible to negotiate PFS, regardless of 848 the EAP method that is used. IKEv2 does not cache EAP keying 849 material or parameters; once IKEv2 authentication completes it is 850 assumed that EAP keying material and parameters are discarded. The 851 Session-Timeout attribute is therefore interpreted as a limit on 852 the VPN session time, rather than an indication of the MSK key 853 lifetime. 855 IEEE 802.11i 856 IEEE 802.11i enables caching of the MSK, but not the EMSK, IV, 857 Peer-ID, Server-ID, or Session-ID. More details about the 858 structure of the cache are available in [IEEE-802.11i]. In IEEE 859 802.11i, TSKs are derived from the MSK using the 4-way handshake, 860 which includes a nonce exchange. This guarantees TSK freshness 861 even if the MSK is reused. The 4-way handshake also enables TSK 862 rekey without EAP re-authentication. PFS is only possible within 863 IEEE 802.11i if the negotiated EAP method supports this. 865 IEEE 802.16e 866 IEEE 802.16e, defined in [IEEE-802.16e] supports caching of the 867 MSK, but not the EMSK, IV, Peer-ID, Server-ID or Session-ID. In 868 IEEE 802.16e, TSKs are generated by the authenticator without any 869 contribution by the peer. The TSKs are encrypted, authenticated 870 and integrity protected using the MSK. As a result, TSK rekey is 871 possible without EAP re-authentication. PFS is not possible even 872 if the negotiated EAP method supports it. 874 AAA Existing implementations of RADIUS/EAP [RFC3579] or Diameter EAP 875 [RFC4072] do not support caching of EAP keying material or 876 parameters. In existing AAA client, proxy and server 877 implementations, exported EAP keying material (MSK, EMSK and IV) as 878 well as parameters and derived keys are not cached and MUST be 879 presumed lost after the AAA exchange completes. 881 In order to avoid key reuse, the AAA layer MUST delete transported 882 keys once they are sent. The AAA layer MUST NOT retain keys that 883 it has previously sent. For example, a AAA layer that has 884 transported the MSK MUST delete it, and keys MUST NOT be derived 885 from the MSK from that point forward. 887 2.4. Authenticator Architecture 889 This specification does not impose constraints on the architecture of 890 the EAP authenticator or peer. Any of the authenticator 891 architectures described in [RFC4118] can be used. For example, it is 892 possible for multiple base stations and a "controller" (e.g. WLAN 893 switch) to comprise a single EAP authenticator. In such a situation, 894 the "base station identity" is irrelevant to the EAP method 895 conversation, except perhaps as an opaque blob to be used in Channel 896 Bindings. Many base stations can share the same authenticator 897 identity. As a result, lower layers need to identify EAP peers and 898 authenticators unambiguously, without incorporating implicit 899 assumptions about peer and authenticator architectures. 901 It should be understood that an EAP authenticator or peer: 903 [a] may contain one or more physical or logical ports; 904 [b] may advertise itself as one or more "virtual" 905 authenticators or peers; 906 [c] may utilize multiple CPUs; 907 [d] may support clustering services for load balancing or failover. 909 Both the EAP peer and authenticator may have more than one physical 910 or logical port. A peer may simultaneously access the network via 911 multiple authenticators, or via multiple physical or logical ports on 912 a given authenticator. Similarly, an authenticator may offer network 913 access to multiple peers, each via a separate physical or logical 914 port. When a single physical authenticator advertises itself as 915 multiple "virtual authenticators", it is possible for a single 916 physical port to belong to multiple "virtual authenticators". The 917 situation is illustrated in Figure 5. 919 +-+-+-+-+ 920 | EAP | 921 | Peer | 922 +-+-+-+-+ 923 | | | Peer Ports 924 / | \ 925 / | \ 926 / | \ 927 / | \ 928 / | \ 929 / | \ 930 / | \ 931 / | \ 932 | | | | | | | | | Authenticator Ports 933 +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ 934 | | | | | | 935 | Auth. | | Auth. | | Auth. | 936 | | | | | | 937 +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ 938 \ | / 939 \ | / 940 \ | / 941 EAP over AAA \ | / 942 (optional) \ | / 943 \ | / 944 \ | / 945 \ | / 946 +-+-+-+-+ 947 | EAP | 948 |Server | 949 +-+-+-+-+ 951 Figure 5: Relationship between EAP peer, authenticator and server 953 2.4.1. Authenticator Identification 955 The EAP method conversation is between the EAP peer and server, as 956 identified by the Peer-ID and Server-ID. The authenticator identity, 957 if considered at all by the EAP method, is treated as an opaque blob 958 for the purposes of Channel bindings. However, the Secure 959 Association Protocol conversation is between the peer and the 960 authenticator, and therefore the authenticator and peer identities 961 are relevant to that exchange, and define the scope of use of the EAP 962 keying material passed down to the lower layer. 964 Since an authenticator may have multiple ports, the authenticator 965 identifiers used within the Secure Association Protocol exchange 966 SHOULD be distinct from any port identifier (e.g. MAC address). 967 Similarly, where a peer may have multiple ports, and sharing of EAP 968 keying material and parameters between peer ports of the same link 969 type is allowed, the peer identifier used within the Secure 970 Association Protocol exchange SHOULD also be distinct from any port 971 identifier. 973 Where the peer and authenticator identify themselves within the lower 974 layer using a port identifier such as a link layer address, this 975 creates a number of problems: 977 [1] It may not be obvious to the peer which authenticator ports are 978 associated with which authenticators. 980 [2] It may not be obvious to the authenticator which peer ports are 981 associated with which peers. 983 [3] It may not be obvious to the peer which "virtual authenticator" it 984 is communicating with. 986 [4] It may not be obvious to the authenticator which "virtual peer" it 987 is communicating with. 989 AAA protocols such as RADIUS [RFC3579] and Diameter [RFC4072] 990 provide a mechanism for the identification of AAA clients; since 991 the EAP authenticator and AAA client are always co-resident, this 992 mechanism is applicable to the identification of EAP 993 authenticators. 995 RADIUS [RFC2865] requires that an Access-Request packet contain one 996 or more of the NAS-Identifier, NAS-IP-Address and NAS-IPv6-Address 997 attributes. Since a NAS may have more than one IP address, the 998 NAS-Identifier attribute is RECOMMENDED for the unambiguous 999 identification of the EAP authenticator. 1001 From the point of view of the AAA server, EAP keying material and 1002 parameters are transported to the EAP authenticator identified by 1003 the NAS-Identifier attribute. Since an EAP authenticator MUST NOT 1004 share EAP keying material or parameters with another party, if the 1005 EAP peer or AAA server detects use of EAP keying material and 1006 parameters outside the scope defined by the NAS-Identifier, the 1007 keying material MUST be considered compromised. 1009 2.5. Key Scope 1011 Where the EAP peer and authenticator cannot unambiguously identify 1012 each other they may not be able to determine the scope of transported 1013 EAP keying material. This is particularly problematic for lower 1014 layers where key caching is supported. 1016 For example, if the EAP peer cannot identify the EAP authenticator, 1017 it will be unable to determine whether transported EAP keying 1018 material has been shared outside of its authorized scope, and 1019 therefore needs to be considered compromised. There is also a 1020 practical problem because the EAP peer will be unable to utilize the 1021 EAP authenticator key cache in an efficient way. 1023 To avoid these problems, it is recomended that lower layers: 1025 [1] Specify the lower layer parameters used to identify the 1026 authenticator and peer; 1028 [2] Communicate the lower layer identities between the peer and 1029 authenticator within phase 0; 1031 [3] Communicate the lower layer authenticator identity between the 1032 authenticator and backend server within the NAS-Identifier 1033 attribute; 1035 [4] Include the lower layer identities within channel bindings (if 1036 supported) in phase 1a, ensuring that they are communicated between 1037 the EAP peer and server; 1039 [5] Securely verify the lower layer identities within phase 2a; 1041 [6] Utilize the advertised lower layer identities to enable the peer 1042 and authenticator to verify that keys are maintained within the 1043 advertised scope; 1045 Absent explicit specification within the lower layer, after the 1046 completion of phase 1b, EAP keying material and parameters are 1047 bound to the EAP peer and authenticator, but are not bound to a 1048 specific peer or authenticator port. 1050 While EAP Keying Material passed down to the lower layer is not 1051 intrinsically bound to particular authenticator and peer ports, 1052 Transient Session Keys MAY be bound to particular authenticator and 1053 peer ports by the Secure Association Protocol. However, a lower 1054 layer MAY also permit TSKs to be used on multiple peer and/or 1055 authenticator ports, providing that TSK freshness is guaranteed 1056 (such as by keeping replay counter state within the authenticator). 1058 In order to further limit the key scope the following measures are 1059 suggested: 1061 [a] The lower layer MAY specify additional restrictions on key usage, 1062 such as limiting the use of EAP keying material and parameters on 1063 the EAP peer to the port over which on the EAP conversation was 1064 conducted. 1066 [b] The backend authentication server and authenticator MAY implement 1067 additional attributes in order to further restrict the scope of EAP 1068 keying material. For example, in 802.11, the backend 1069 authentication server may provide the authenticator with a list of 1070 authorized Called or Calling-Station-Ids and/or SSIDs for which EAP 1071 keying material is valid. 1073 [c] Where the backend authentication server provides attributes 1074 restricting the key scope, it is RECOMMENDED that restrictions be 1075 securely communicated by the authenticator to the peer. This can 1076 be accomplished using the Secure Association Protocol, but also 1077 can be accomplished via the EAP method or the lower layer. 1079 2.5.1. Virtual Authenticators 1081 When a single physical authenticator advertises itself as multiple 1082 "virtual authenticators", the EAP peer and authenticator may not be 1083 able to agree on the scope of the EAP keying material, creating a 1084 security vulnerability. For example, the peer may assume that the 1085 "virtual authenticators" are distinct and do not share a key cache, 1086 whereas, depending on the architecture of the physical authenticator, 1087 a shared key cache may or may not be implemented. 1089 Where EAP keying material is shared between "virtual authenticators" 1090 an attacker acting as a peer could authenticate with the "Guest" 1091 "virtual authenticator" and derive EAP keying material. If the 1092 virtual authenticators share a key cache, then the peer can utilize 1093 the EAP keying material derived for the "Guest" network to obtain 1094 access to the "Corporate Intranet" virtual authenticator. 1096 Several measures are recommended to address these issues: 1098 [d] Authenticators are REQUIRED to cache associated authorizations 1099 along with EAP keying material and parameters and to apply 1100 authorizations consistently. This ensures that an attacker cannot 1101 obtain elevated privileges even where the key cache is shared 1102 between "virtual authenticators". 1104 [e] It is RECOMMENDED that physical authenticators maintain separate 1105 key caches for each "virtual authenticator". 1107 [f] It is RECOMMENDED that each "virtual authenticator" identify itself 1108 distinctly to the backend authentication server, such as by 1109 utilizing a distinct NAS-Identifier attribute. This enables the 1110 backend authentication server to utilize a separate credential to 1111 authenticate each "virtual authenticator". 1113 3. Key Management 1115 EAP as defined in [RFC3748] supports key derivation, but not key 1116 management. While EAP methods may derive keying material, EAP does 1117 not provide for the management of exported or derived keys. For 1118 example, EAP does not support negotiation of the key lifetime of 1119 exported or derived keys, nor does it support re-key. Although EAP 1120 methods may support "fast reconnect" as defined in [RFC3748] Section 1121 7.2.1, re-key of exported keys cannot occur without re- 1122 authentication. In order to provide method independence, key 1123 management of exported or derived keys SHOULD NOT be provided within 1124 EAP methods. 1126 3.1. Secure Association Protocol 1128 Since neither EAP nor EAP methods provide key management support, it 1129 is RECOMMENDED that key management facilities be provided within the 1130 Secure Association Protocol. This includes: 1132 [a] Entity Naming. A basic feature of a Secure Association Protocol is 1133 the explicit naming of the parties engaged in the exchange. 1134 Without explicit identification, the parties engaged in the 1135 exchange are not identified and the scope of the EAP keying 1136 parameters negotiated during the EAP exchange is undefined. As 1137 shown in Figure 5, both the peer and authenticator may have more 1138 than one physical or virtual port, and as a result SHOULD identify 1139 themselves in a manner that is independent of their attached ports. 1141 [b] Mutual proof of possession of EAP keying material. During the 1142 Secure Association Protocol the EAP peer and authenticator MUST 1143 demonstrate possession of the keying material transported between 1144 the backend authentication server and authenticator (e.g. MSK), in 1145 order to demonstrate that the peer and authenticator have been 1146 authorized. Since mutual proof of possession is not the same as 1147 mutual authentication, the peer cannot verify authenticator 1148 assertions (including the authenticator identity) as a result of 1149 this exchange. 1151 [c] Secure capabilities negotiation. In order to protect against 1152 spoofing during the discovery phase, ensure selection of the "best" 1153 ciphersuite, and protect against forging of negotiated security 1154 parameters, the Secure Association Protocol MUST support secure 1155 capabilities negotiation. This includes the secure negotiation of 1156 usage modes, session parameters (such as security association 1157 identifiers (SAIDs) and key lifetimes), ciphersuites and required 1158 filters, including confirmation of security-relevant capabilities 1159 discovered during phase 0. As part of secure capabilities 1160 negotiation, the Secure Association Protocol MUST support integrity 1161 and replay protection of all messages. 1163 [d] Key naming and selection. Where key caching is supported, it may 1164 be possible for the EAP peer and authenticator to share more than 1165 one key of a given type. As a result, the Secure Association 1166 Protocol MUST explicitly name the keys used in the proof of 1167 possession exchange, so as to prevent confusion when more than one 1168 set of keying material could potentially be used as the basis for 1169 the exchange. Use of the key naming mechanism described in this 1170 document is RECOMMENDED. 1172 In order to support the correct processing of phase 2 security 1173 associations, the Secure Association (phase 2) protocol MUST 1174 support the naming of phase 2 security associations and associated 1175 transient session keys, so that the correct set of transient 1176 session keys can be identified for processing a given packet. The 1177 phase 2 Secure Association Protocol also MUST support transient 1178 session key activation and SHOULD support deletion, so that 1179 establishment and re-establishment of transient session keys can be 1180 synchronized between the parties. 1182 [e] Generation of fresh transient session keys (TSKs). Where the lower 1183 layer supports caching of exported EAP keying material, the EAP 1184 peer lower layer may initiate a new session using keying material 1185 that was derived in a previous session. Were the TSKs to be 1186 derived from a portion of the exported EAP keying material, this 1187 would result in reuse of the session keys which could expose the 1188 underlying ciphersuite to attack. 1190 In lower layers where caching of EAP keying material is supported, 1191 the Secure Association Protocol phase is REQUIRED, and MUST support 1192 the derivation of fresh unicast and multicast TSKs, even when the 1193 keying material provided by the backend authentication server is 1194 not fresh. This is typically supported via the exchange of nonces 1195 or counters, which are then mixed with the exported keying material 1196 in order to generate fresh unicast (phase 2a) and possibly 1197 multicast (phase 2b) session keys. By not using EAP keying 1198 material directly to protect data, the Secure Association Protocol 1199 protects it against compromise. 1201 [f] Key lifetime management. This includes explicit key lifetime 1202 negotiation or seamless re-key. EAP does not support negotiation 1203 of key lifetimes, nor does it support re-key without re- 1204 authentication. As a result, the Secure Association Protocol may 1205 handle re-key and determination of the key lifetime. Where key 1206 caching is supported, secure negotiation of key lifetimes is 1207 RECOMMENDED. Lower layers that support re-key, but not key 1208 caching, may not require key lifetime negotiation. To take an 1209 example from IKE, the difference between IKEv1 and IKEv2 is that in 1210 IKEv1 SA lifetimes were negotiated. In IKEv2, each end of the SA is 1211 responsible for enforcing its own lifetime policy on the SA and re- 1212 keying the SA when necessary. 1214 [g] Key resynchronization. It is possible for the peer or 1215 authenticator to reboot or reclaim resources, clearing portions or 1216 all of the key cache. Therefore, key lifetime negotiation cannot 1217 guarantee that the key cache will remain synchronized, and the peer 1218 may not be able to determine before attempting to use a key whether 1219 it exists within the authenticator cache. It is therefore 1220 RECOMMENDED for the Secure Association Protocol to provide a 1221 mechanism for key state resynchronization. Since in this situation 1222 one or more of the parties initially do not possess a key with 1223 which to protect the resynchronization exchange, securing this 1224 mechanism may be difficult. 1226 [h] Key scope synchronization. Since the Discovery phase is handled 1227 out-of-band, EAP does not provide a mechanism by which the peer can 1228 determine the authenticator identity. As a result, where the 1229 authenticator has multiple ports and key caching is supported, the 1230 EAP peer may not be able to determine the scope of validity of the 1231 exported EAP keying material. Similarly, where the EAP peer has 1232 multiple ports, the authenticator may not be able to determine 1233 whether a peer has authorization to use a particular key. To allow 1234 key scope determination, the Secure Association Protocol SHOULD 1235 provide a mechanism by which the peer can determine the scope of 1236 the key cache on each authenticator, and by which the authenticator 1237 can determine the scope of the key cache on a peer. This includes 1238 negotiation of restrictions on key usage. 1240 [i] Direct operation. Since the phase 2 Secure Association Protocol is 1241 concerned with the establishment of security associations between 1242 the EAP peer and authenticator, including the derivation of 1243 transient session keys, only those parties have "a need to know" 1244 the transient session keys. The Secure Association Protocol MUST 1245 operate directly between the peer and authenticator, and MUST NOT 1246 be passed-through to the backend authentication server, or include 1247 additional parties. 1249 [j] Bi-directional operation While some ciphersuites only require a 1250 single set of transient session keys to protect traffic in both 1251 directions, other ciphersuites require a unique set of transient 1252 session keys in each direction. The phase 2 Secure Association 1253 Protocol SHOULD provide for the derivation of unicast and multicast 1254 keys in each direction, so as not to require two separate phase 2 1255 exchanges in order to create a bi-directional phase 2 security 1256 association. 1258 3.2. Parent-Child Relationships 1260 When keying material exported by EAP methods expires, all keying 1261 material derived from the exported keying material expires, including 1262 the TSKs. 1264 When an EAP re-authentication takes place, new keying material is 1265 derived and exported by the EAP method, which eventually results in 1266 replacement of calculated keys, including the TSKs. 1268 As a result, while the lifetime of calculated keys can be less than 1269 or equal that of the exported keys they are derived from, it cannot 1270 be greater. For example, when EAP re-authentication occurs, TSK re- 1271 key will also occur. However, this does not prohibit TSK re-key from 1272 occurring prior to expiration of the lifetime of exported keys. For 1273 example, TSK re-key may occur prior to EAP re-authentication. 1275 Failure to mutually prove possession of keying material during the 1276 Secure Association Protocol exchange need not be grounds for deletion 1277 of the keying material by both parties; rate-limiting Secure 1278 Association Protocol exchanges could be used to prevent a brute force 1279 attack. 1281 3.3. Local Key Lifetimes 1283 The Transient EAP Keys (TEKs) are session keys used to protect the 1284 EAP conversation. The TEKs are internal to the EAP method and are 1285 not exported. TEKs are typically created during an EAP conversation, 1286 used until the end of the conversation and then discarded. However, 1287 methods may re-key TEKs during a conversation. 1289 When using TEKs within an EAP conversation or across conversations, 1290 it is necessary to ensure that replay protection and key separation 1291 requirements are fulfilled. For instance, if a replay counter is 1292 used, TEK re-key MUST occur prior to wrapping of the counter. 1293 Similarly, TSKs MUST remain cryptographically separate from TEKs 1294 despite TEK re-keying or caching. This prevents TEK compromise from 1295 leading directly to compromise of the TSKs and vice versa. 1297 EAP methods may cache local keying material which may persist for 1298 multiple EAP conversations when fast reconnect is used [RFC 3748]. 1299 For example, EAP methods based on TLS (such as EAP-TLS [RFC2716]) 1300 derive and cache the TLS Master Secret, typically for substantial 1301 time periods. The lifetime of other local keying material calculated 1302 within the EAP method is defined by the method. Note that in 1303 general, when using fast reconnect, there is no guarantee to that the 1304 original long-term credentials are still in the possession of the 1305 peer. For instance, a card hold holding the private key for EAP-TLS 1306 may have been removed. EAP servers SHOULD also verify that the long- 1307 term credentials are still valid, such as by checking that 1308 certificate used in the original authentication has not yet expired. 1310 3.4. Exported and Calculated Key Lifetimes 1312 All EAP methods generating keys are required to generate the MSK and 1313 EMSK, and may optionally generate the IV. However, EAP, defined in 1314 [RFC3748], does not support the negotiation of lifetimes for exported 1315 keying material such as the MSK, EMSK and IV. 1317 Several mechanisms exist for managing key lifetimes: 1319 [a] AAA attributes. AAA protocols such as RADIUS [RFC2865] and 1320 Diameter [RFC4072] support the Session-Timeout attribute. The 1321 Session-Timeout value represents the maximum lifetime of the 1322 exported keys, and all keys calculated from it, on the 1323 authenticator. Since existing backend authentication servers do 1324 not cache keys exported by EAP methods, or keys calculated from 1325 exported keys, the value of the Session-Timeout attribute has no 1326 bearing on the key lifetime within the backend authentication 1327 server. 1329 On the authenticator, where EAP is used for authentication, the 1330 Session-Timeout value represents the maximum session time prior to 1331 re-authentication, as described in [RFC3580]. Where EAP is used 1332 for pre-authentication, the session may not start until some future 1333 time, or may never occur. Nevertheless, the Session-Timeout value 1334 represents the time after which transported EAP keying material, 1335 and all keys calculated from it, will have expired on the 1336 authenticator. If the session subsequently starts, re- 1337 authentication will be initiated once the Session-Time has expired. 1339 If the session never started, or started and ended, by default keys 1340 transported by AAA and all keys calculated from them will be 1341 expired by the authenticator prior to the future time indicated by 1342 Session-Timeout. 1344 Since the TSK lifetime is often determined by authenticator 1345 resources, the backend authentication server has no insight into 1346 the TSK derivation process, and by the principle of ciphersuite 1347 independence, it is not appropriate for the backend authentication 1348 server to manage any aspect of the TSK derivation process, 1349 including the TSK lifetime. 1351 [b] Lower layer mechanisms. While AAA attributes can communicate the 1352 maximum exported key lifetime, this only serves to synchronize the 1353 key lifetime between the backend authentication server and the 1354 authenticator. Lower layer mechanisms such as the Secure 1355 Association Protocol can then be used to enable the lifetime of 1356 exported and calculated keys to be negotiated between the peer and 1357 authenticator. 1359 Where TSKs are established as the result of a Secure Association 1360 Protocol exchange, it is RECOMMENDED that the Secure Association 1361 Protocol include support for TSK resynchronization. Where the TSK 1362 is taken from the MSK, there is no need to manage the TSK lifetime 1363 as a separate parameter, since the TSK lifetime and MSK lifetime 1364 are identical. 1366 [c] System defaults. Where the EAP method does not support the 1367 negotiation of the exported key lifetime, and a key lifetime 1368 negotiation mechanism is not provided by the lower lower, there may 1369 be no way for the peer to learn the exported key lifetime. In this 1370 case it is RECOMMENDED that the peer assume a default value of the 1371 exported key lifetime; 8 hours is recommended. Similarly, the 1372 lifetime of calculated keys can also be managed as a system 1373 parameter on the authenticator. 1375 [d] Method specific negotiation within EAP. While EAP itself does not 1376 support lifetime negotiation, it would be possible to specify 1377 methods that do. However, systems that rely on such negotiation 1378 for exported keys would only function with these methods. As a 1379 result, it is NOT RECOMMENDED to use this approach as the sole way 1380 to determine key lifetimes. 1382 3.5. Key cache synchronization 1384 Issues arise when attempting to synchronize the key cache on the peer 1385 and authenticator. Lifetime negotiation alone cannot guarantee key 1386 cache synchronization. 1388 One problem is that the AAA protocol cannot guarantee synchronization 1389 of key lifetimes between the peer and authenticator. Where the 1390 Secure Association Protocol is not run immediately after EAP 1391 authentication, the exported and calculated key lifetimes will not be 1392 known by the peer during the hiatus. Where EAP pre-authentication 1393 occurs, this can leave the peer uncertain whether a subsequent 1394 attempt to use the exported keys will prove successful. 1396 However, even where the Secure Association Protocol is run 1397 immediately after EAP, it is still possible for the authenticator to 1398 reclaim resources if the created key state is not immediately 1399 utilized. 1401 The lower layer may utilize Discovery mechanisms to assist in this. 1402 For example, the authenticator manages the key cache by deleting the 1403 oldest key first (LIFO), the relative creation time of the last key 1404 to be deleted could be advertised with the Discovery phase, enabling 1405 the peer to determine whether a given key had been expired from the 1406 authenticator key cache prematurely. 1408 3.6. Key Strength 1410 In order to guard against brute force attacks, EAP methods deriving 1411 keys need to be capable of generating keys with an appropriate 1412 effective symmetric key strength. In order to ensure that key 1413 generation is not the weakest link, it is RECOMMENDED that EAP 1414 methods utilizing public key cryptography choose a public key that 1415 has a cryptographic strength meeting the symmetric key strength 1416 requirement. 1418 As noted in [RFC3766] Section 5, this results in the following 1419 required RSA or DH module and DSA subgroup size in bits, for a given 1420 level of attack resistance in bits: 1422 Attack Resistance RSA or DH Modulus DSA subgroup 1423 (bits) size (bits) size (bits) 1424 ----------------- ----------------- ------------ 1425 70 947 128 1426 80 1228 145 1427 90 1553 153 1428 100 1926 184 1429 150 4575 279 1430 200 8719 373 1431 250 14596 475 1433 3.7. Key Wrap 1435 As described in [RFC3579] Section 4.3, known problems exist in the 1436 key wrap specified in [RFC2548]. Where the same RADIUS shared secret 1437 is used by a PAP authenticator and an EAP authenticator, there is a 1438 vulnerability to known plaintext attack. Since RADIUS uses the 1439 shared secret for multiple purposes, including per-packet 1440 authentication, attribute hiding, considerable information is exposed 1441 about the shared secret with each packet. This exposes the shared 1442 secret to dictionary attacks. MD5 is used both to compute the RADIUS 1443 Response Authenticator and the Message-Authenticator attribute, and 1444 some concerns exist relating to the security of this hash 1445 [MD5Attack]. 1447 As discussed in [RFC3579] Section 4.3, the security vulnerabilities 1448 of RADIUS are extensive, and therefore development of an alternative 1449 key wrap technique based on the RADIUS shared secret would not 1450 substantially improve security. As a result, [RFC3759] Section 4.2 1451 recommends running RADIUS over IPsec. The same approach is taken in 1452 Diameter EAP [RFC4072], which defines cleartext key attributes, to be 1453 protected by IPsec or TLS. 1455 Where an untrusted AAA intermediary is present (such as a RADIUS 1456 proxy or a Diameter agent), and data object security is not used, 1457 transported keying material may be recovered by an attacker in 1458 control of the untrusted intermediary. Possession of transported 1459 keying material enables decryption of data traffic sent between the 1460 peer and a specific authenticator. However, as long as EAP keying 1461 material or keys derived from it is only utilized by a single 1462 authenticator, compromise of the transported keying material does not 1463 enable an attacker to impersonate the peer to another authenticator. 1464 Vulnerability to an untrusted AAA intermediary can be mitigated by 1465 implementation of redirect functionality, as described in [RFC3588] 1466 and [RFC4072]. 1468 4. Handoff Vulnerabilities 1470 With EAP, a number of mechanisms are be utilized in order to reduce 1471 the latency of handoff between authenticators. One such mechanism is 1472 EAP pre-authentication, in which EAP is utilized to pre-establish EAP 1473 keying material on an authenticator prior to arrival of the peer. 1474 Another such mechanism is key caching, in which an EAP peer can re- 1475 attach to an authenticator without having to re-authenticate using 1476 EAP. Yet another mechanism is context transfer, such as is defined 1477 in [IEEE-802.11F] (now deprecated) and [CTP]. These mechanisms 1478 introduce new security vulnerabilities, as discussed in the sections 1479 that follow. 1481 4.1. Authorization 1483 In a typical network access scenario (dial-in, wireless LAN, etc.) 1484 access control mechanisms are typically applied. These mechanisms 1485 include user authentication as well as authorization for the offered 1486 service. 1488 As a part of the authentication process, the backend authentication 1489 server determines the user's authorization profile. The user 1490 authorizations are transmitted by the backend authentication server 1491 to the EAP authenticator (also known as the Network Access Server or 1492 authenticator) and with the transported EAP keying material, in Phase 1493 1b of the EAP conversation. Typically, the profile is determined 1494 based on the user identity, but a certificate presented by the user 1495 may also provide authorization information. 1497 The backend authentication server is responsible for making a user 1498 authorization decision, answering the following questions: 1500 [a] Is this a legitimate user for this particular network? 1502 [b] Is this user allowed the type of access he or she is requesting? 1504 [c] Are there any specific parameters (mandatory tunneling, bandwidth, 1505 filters, and so on) that the access network should be aware of for 1506 this user? 1508 [d] Is this user within the subscription rules regarding time of day? 1510 [e] Is this user within his limits for concurrent sessions? 1512 [f] Are there any fraud, credit limit, or other concerns that indicate 1513 that access should be denied? 1515 While the authorization decision is in principle simple, the process 1516 is complicated by the distributed nature of the decision making. 1517 Where brokering entities or proxies are involved, all of the AAA 1518 entities in the chain from the authenticator to the home backend 1519 authentication server are involved in the decision. For instance, a 1520 broker can disallow access even if the home backend authentication 1521 server would allow it, or a proxy can add authorizations (e.g., 1522 bandwidth limits). 1524 Decisions can be based on static policy definitions and profiles as 1525 well as dynamic state (e.g. time of day or limits on the number of 1526 concurrent sessions). In addition to the Accept/Reject decision made 1527 by the AAA chain, parameters or constraints can be communicated to 1528 the authenticator. 1530 The criteria for Accept/Reject decisions or the reasons for choosing 1531 particular authorizations are typically not communicated to the 1532 authenticator, only the final result. As a result, the authenticator 1533 has no way to know what the decision was based on. Was a set of 1534 authorization parameters sent because this service is always provided 1535 to the user, or was the decision based on the time/day and the 1536 capabilities of the requesting authenticator device? 1538 4.2. Correctness 1540 When the AAA exchange is bypassed via use of techniques such as key 1541 caching, this creates challenges in ensuring that authorization is 1542 properly handled. These include: 1544 [a] Consistent application of session time limits. Bypassing AAA 1545 should not automatically increase the available session time, 1546 allowing a user to endlessly extend their network access by 1547 changing the point of attachment. 1549 [b] Avoidance of privilege elevation. Bypassing AAA should not result 1550 in a user being granted access to services which they are not 1551 entitled to. 1553 [c] Consideration of dynamic state. In situations in which dynamic 1554 state is involved in the access decision (day/time, simultaneous 1555 session limit) it should be possible to take this state into 1556 account either before or after access is granted. Note that 1557 consideration of network-wide state such as simultaneous session 1558 limits can typically only be taken into account by the backend 1559 authentication server. 1561 [d] Encoding of restrictions. Since a authenticator may not be aware 1562 of the criteria considered by a backend authentication server when 1563 allowing access, in order to ensure consistent authorization during 1564 a fast handoff it may be necessary to explicitly encode the 1565 restrictions within the authorizations provided by the backend 1566 authentication server. 1568 [e] State validity. The introduction of fast handoff should not render 1569 the authentication server incapable of keeping track of network- 1570 wide state. 1572 A handoff mechanism capable of addressing these concerns is said to 1573 be "correct". One condition for correctness is as follows: For a 1574 handoff to be "correct" it MUST establish on the new device the same 1575 context as would have been created had the new device completed a AAA 1576 conversation with the backend authentication server. 1578 A properly designed handoff scheme will only succeed if it is 1579 "correct" in this way. If a successful handoff would establish 1580 "incorrect" state, it is preferable for it to fail, in order to avoid 1581 creation of incorrect context. 1583 Some backend authentication server and authenticator configurations 1584 are incapable of meeting this definition of "correctness". For 1585 example, if the old and new device differ in their capabilities, it 1586 may be difficult to meet this definition of correctness in a handoff 1587 mechanism that bypasses AAA. Backend authentication servers often 1588 perform conditional evaluation, in which the authorizations returned 1589 in an Access-Accept message are contingent on the authenticator or on 1590 dynamic state such as the time of day or number of simultaneous 1591 sessions. For example, in a heterogeneous deployment, the backend 1592 authentication server might return different authorizations depending 1593 on the authenticator making the request, in order to make sure that 1594 the requested service is consistent with the authenticator 1595 capabilities. 1597 If differences between the new and old device would result in the 1598 backend authentication server sending a different set of messages to 1599 the new device than were sent to the old device, then if the handoff 1600 mechanism bypasses AAA, then the handoff cannot be carried out 1601 correctly. 1603 For example, if some authenticator devices within a deployment 1604 support dynamic VLANs while others do not, then attributes present in 1605 the Access-Request (such as the authenticator-IP-Address, 1606 authenticator-Identifier, Vendor-Identifier, etc.) could be examined 1607 to determine when VLAN attributes will be returned, as described in 1608 [RFC3580]. VLAN support is defined in [IEEE-802.1Q]. If a handoff 1609 bypassing the backend authentication server were to occur between a 1610 authenticator supporting dynamic VLANs and another authenticator 1611 which does not, then a guest user with access restricted to a guest 1612 VLAN could be given unrestricted access to the network. 1614 Similarly, in a network where access is restricted based on the day 1615 and time, Service Set Identifier (SSID), Calling-Station-Id or other 1616 factors, unless the restrictions are encoded within the 1617 authorizations, or a partial AAA conversation is included, then a 1618 handoff could result in the user bypassing the restrictions. 1620 In practice, these considerations limit the situations in which fast 1621 handoff mechanisms bypassing AAA can be expected to be successful. 1622 Where the deployed devices implement the same set of services, it may 1623 be possible to do successful handoffs within such mechanisms. 1624 However, where the supported services differ between devices, the 1625 handoff may not succeed. For example, [RFC2865] section 1.1 states: 1627 "A authenticator that does not implement a given service MUST NOT 1628 implement the RADIUS attributes for that service. For example, a 1629 authenticator that is unable to offer ARAP service MUST NOT 1630 implement the RADIUS attributes for ARAP. A authenticator MUST 1631 treat a RADIUS access-accept authorizing an unavailable service as 1632 an access-reject instead." 1634 Note that this behavior only applies to attributes that are known, 1635 but not implemented. For attributes that are unknown, [RFC2865] 1636 Section 5 states: 1638 "A RADIUS server MAY ignore Attributes with an unknown Type. A 1639 RADIUS client MAY ignore Attributes with an unknown Type." 1641 In order to perform a correct handoff, if a new device is provided 1642 with RADIUS context for a known but unavailable service, then it MUST 1643 process this context the same way it would handle a RADIUS Access- 1644 Accept requesting an unavailable service. This MUST cause the 1645 handoff to fail. However, if a new device is provided with RADIUS 1646 context that indicates an unknown attribute, then this attribute MAY 1647 be ignored. 1649 Although it may seem somewhat counter-intuitive, failure is indeed 1650 the "correct" result where a known but unsupported service is 1651 requested. Presumably a correctly configured backend authentication 1652 server would not request that a device carry out a service that it 1653 does not implement. This implies that if the new device were to 1654 complete a AAA conversation that it would be likely to receive 1655 different service instructions. In such a case, failure of the 1656 handoff is the desired result. This will cause the new device to go 1657 back to the AAA server in order to receive the appropriate service 1658 definition. 1660 In practice, this implies that handoff mechanisms which bypass AAA 1661 are most likely to be successful within a homogeneous device 1662 deployment within a single administrative domain. For example, it 1663 would not be advisable to carry out a fast handoff bypassing AAA 1664 between a authenticator providing confidentiality and another 1665 authenticator that does not support this service. The correct result 1666 of such a handoff would be a failure, since if the handoff were 1667 blindly carried out, then the user would be moved from a secure to an 1668 insecure channel without permission from the backend authentication 1669 server. Thus the definition of a "known but unsupported service" 1670 MUST encompass requests for unavailable security services. This 1671 includes vendor-specific attributes related to security, such as 1672 those described in [RFC2548]. 1674 5. Security Considerations 1676 In order to analyze whether the EAP conversation achieves its 1677 security goals, it is first necessary to state those goals as well as 1678 the underlying security assumptions. 1680 The overall goal of the EAP conversation is to derive fresh session 1681 keys between the EAP peer and authenticator that are known only to 1682 those parties, and for both the EAP peer and authenticator to 1683 demonstrate that they are authorized to perform their roles either by 1684 each other or by a trusted third party (the backend authentication 1685 server). 1687 The principals of the authentication phase are the EAP peer and 1688 server. Completion of an EAP method exchange supporting key 1689 derivation results in the derivation of EAP keying material (MSK, 1690 EMSK, TEKs) known only to the EAP peer (identified by the Peer-ID) 1691 and server (identified by the Server-ID). Both the EAP peer and EAP 1692 server know the exported keying material to be fresh. 1694 The principals of the AAA Key transport exchange are the EAP 1695 authenticator and the EAP server. Completion of the AAA exchange 1696 results in the transport of EAP keying material from the EAP server 1697 (identified by the Server-ID) to the EAP authenticator (identified by 1698 the NAS-Identifier) without disclosure to any other party. Both the 1699 EAP server and EAP authenticator know this keying material to be 1700 fresh. 1702 The principals of the Secure Association Protocol are the EAP peer 1703 (identified by the Peer-ID) and authenticator (identified by the NAS- 1704 Identifier). Completion of the Secure Association Protocol results 1705 in the derivation of TSKs known only to the EAP peer and 1706 authenticator. Both the EAP peer and authenticator know the TSKs to 1707 be fresh. 1709 5.1. Terminology 1711 "Cryptographic binding", "Cryptographic separation", "Key strength" 1712 and "Mutual authentication" are defined in [RFC3748] and are used 1713 with the same meaning here. 1715 5.2. Threat Model 1717 The EAP threat model is described in [RFC3748] Section 7.1. The 1718 security properties of EAP methods (known as "security claims", 1719 described in [RFC3784] Section 7.2.1), address these threats. EAP 1720 method requirements for applications such as Wireless LAN 1721 authentication are described in [RFC4017]. The RADIUS threat model 1722 is described in [RFC3579] Section 4.1, and responses to these threats 1723 are described in [RFC3579] Sections 4.2 and 4.3. 1725 However, in addition to threats against EAP and AAA, there are other 1726 system-level threats worth discussing. These include: 1728 [1] An attacker may compromise or steal an EAP authenticator, in an 1729 attempt to gain access to other EAP authenticators or obtain long- 1730 term secrets. 1732 [2] An attacker may compromise an EAP authenticator in an effort to 1733 commit fraud. For example, a compromised authenticator may provide 1734 incorrect information to the EAP peer and/or server via out-of-band 1735 mechanisms (such as via a AAA or lower layer protocol). This 1736 includes impersonating another authenticator, or providing 1737 inconsistent information to the peer and EAP server. 1739 [3] An attacker may try to modify or spoof packets, including Discovery 1740 or Secure Association Protocol frames, EAP or AAA packets. 1742 [4] An attacker may attempt a downgrade attack in order to exploit 1743 known weaknesses in an authentication method or cryptographic 1744 transform. 1746 [5] An attacker may attempt to induce an EAP peer, authenticator or 1747 server to disclose keying material to an unauthorized party, or 1748 utilize keying material outside the context that it was intended 1749 for. 1751 [6] An attacker may replay packets. 1753 [7] An attacker may cause an EAP peer, authenticator or server to reuse 1754 an stale key. Use of stale keys may also occur unintentionally. 1755 For example, a poorly implemented backend authentication server may 1756 provide stale keying material to an authenticator, or a poorly 1757 implemented authenticator may reuse nonces. 1759 [8] An authenticated attacker may attempt to obtain elevated privilege 1760 in order to access information that it does not have rights to. 1762 In order to address these threats, [Housley] provides a description 1763 of mandatory system security properties. Issues relating system 1764 security requirements are discussed in the sections that follow. 1766 5.3. Authenticator Compromise 1768 In the event that an authenticator is compromised or stolen, an 1769 attacker may gain access to the network via that authenticator, or 1770 may obtain the credentials required for that authenticator/AAA client 1771 to communicate with one or more backend authentication servers. 1772 However, this should not allow the attacker to compromise other 1773 authenticators or the backend authentication server, or obtain long- 1774 term user credentials. 1776 The implications of this requirement are many, but some of the more 1777 important are as follows: 1779 No Key Sharing 1780 An EAP authenticator MUST NOT share any keying material with 1781 another EAP authenticator, since if one EAP authenticator were 1782 compromised, this would enable the compromise of keying material on 1783 another authenticator. In order to be able to determine whether 1784 keying material has been shared, it is necessary for the identity 1785 of the EAP authenticator to be defined and understood by all 1786 parties that communicate with it. 1788 No AAA Credential Sharing 1789 AAA credentials (such as RADIUS shared secrets, IPsec pre-shared 1790 keys or certificates) MUST NOT be shared between AAA clients, since 1791 if one AAA client were compromised, this would enable an attacker 1792 to impersonate other AAA clients to the backend authentication 1793 server, or even to impersonate a backend authentication server to 1794 other AAA clients. 1796 No Compromise of Long-Term Credentials 1797 An attacker obtaining TSKs, TEKs or EAP keying material such as the 1798 MSK MUST NOT be able to obtain long-term user credentials such as 1799 pre-shared keys, passwords or private-keys without breaking a 1800 fundamental cryptographic assumption. 1802 5.4. Spoofing 1804 The use of per-packet authentication and integrity protection 1805 provides protection against spoofing attacks. Diameter [RFC3588] 1806 provides support for per-packet authentication and integrity 1807 protection via use of IPsec or TLS. RADIUS/EAP [RFC3579] provides 1808 for per-packet authentication and integrity protection via use of the 1809 Message-Authenticator attribute. 1811 [RFC3748] Section 7.2.1 describes the "integrity protection" security 1812 claim and [RFC4017] requires use of EAP methods supporting this 1813 claim. 1815 In order to prevent forgery of Secure Association Protocol frames, 1816 per-frame authentication and integrity protection is RECOMMENDED on 1817 all messages. [IEEE-802.11i] supports per-frame integrity protection 1818 and authentication on all messages within the 4-way handshake except 1819 the first message. An attack leveraging this ommission is described 1820 in [Analysis]. 1822 5.5. Downgrade Attacks 1824 The ability to negotiate the use of a particular cryptographic 1825 algorithm provides resilience against compromise of a particular 1826 cryptographic algorithm. This is usually accomplished by including 1827 an algorithm identifier in the protocol, and by specifying the 1828 algorithm requirements in the protocol specification. In order to 1829 prevent downgrade attacks, secure confirmation of the "best" 1830 ciphersuite is required. 1832 [RFC3748] Section 7.2.1 describes the "protected ciphersuite 1833 negotiation" security claim that refers to the ability of an EAP 1834 method to negotiate the ciphersuite used to protect the EAP 1835 conversation, as well as to integrity protect the negotiation. 1836 [RFC4017] requires EAP methods satisfying this security claim. 1838 Diameter [RFC3588] provides support for cryptographic algorithm 1839 negotiation via use of IPsec or TLS. RADIUS [RFC3579] does not 1840 support the negotiation of cryptographic algorithms, and relies on 1841 MD5 for integrity protection, authentication and confidentiality, 1842 despite known weaknesses in the algorithm [MD5Attack]. This issue 1843 can be addressed via use of RADIUS over IPsec, as described in 1844 [RFC3579] Section 4.2. 1846 As a result, EAP methods and AAA protocols are capable of addressing 1847 downgrade attacks. To ensure against downgrade attacks within lower 1848 layer protocols, algorithm independence is REQUIRED with lower layers 1849 using EAP for key derivation. For interoperability, at least one 1850 suite of mandatory-to-implement algorithm MUST be selected. Lower 1851 layer protocols supporting EAP for key derivation SHOULD also support 1852 secure ciphersuite negotiation. As described in [RFC1968], PPP ECP 1853 does not provide support for secure ciphersuite negotiation. 1854 However, [IEEE-802.11i] does support secure ciphersuite negotiation. 1856 5.6. Unauthorized Disclosure 1858 While preserving algorithm independence, confidentiality of all 1859 keying material MUST be maintained. To prevent unauthorized disclose 1860 of keys, each party in the EAP conversation MUST be authenticated to 1861 the other parties with whom it communicates. Keying material MUST be 1862 bound to the appropriate context. 1864 [RFC3748] Section 7.2.1 describes the "mutual authentication" and 1865 "dictionary attack resistance" claims, and [RFC4017] requires EAP 1866 methods satisfying these claims. EAP methods complying with 1867 [RFC4017] therefore provide for mutual authentication between the EAP 1868 peer and server. Binding of EAP keying material (MSK, EMSK) to the 1869 appropriate context is provided by the Peer-ID and Server-ID which 1870 are exported along with the keying material. 1872 Diameter [RFC3588] provides for per-packet authentication and 1873 integrity protection via IPsec or TLS, and RADIUS/EAP [RFC3579] also 1874 provides for per-packet authentication and integrity protection. 1875 Where the NAS/authenticator and backend authentication server 1876 communicate directly and credible keywrap is used (see Section 3.7), 1877 this ensures that the AAA Key Transport phase achieves its security 1878 objectives: mutually authenticating the AAA client/authenticator and 1879 backend authentication server and providing EAP keying material to 1880 the EAP authenticator and to no other party. 1882 As noted in Section 3.1, the Secure Association Protocol does not by 1883 itself provide for mutual authentication between the EAP peer and 1884 authenticator, even if mutual possession of EAP keying material is 1885 proven. However, where the NAS/authenticator and backend 1886 authentication server communicate directly, the backend 1887 authentication server can verify the correspondence between NAS 1888 identification attributes, the source address of packets sent by the 1889 NAS, and the AAA credentials. As long as the NAS has not shared its 1890 AAA credentials with another NAS, this allows the backend 1891 authentication server to authenticate the NAS. Using Channel 1892 Bindings, the EAP peer can then determine whether the 1893 NAS/authenticator has provided the same identifying information to 1894 the EAP peer and backend authentication server. 1896 Peer and authenticator authorization MUST be performed. 1897 Authorization is REQUIRED whenever a peer associates with a new 1898 authenticator. Authorization checking prevents an elevation of 1899 privilege attack, and ensures that an unauthorized authenticator is 1900 detected. Authorizations SHOULD be synchronized between the EAP 1901 peer, server, authenticator. Once the EAP conversation exchanges are 1902 complete, all of these parties should hold the same view of the 1903 authorizations associated the other parties. If peer authorization 1904 is restricted, then the peer SHOULD be made aware of the restriction. 1906 The AAA exchange provides the EAP authenticator with authorizations 1907 relating to the EAP peer. However, neither the EAP nor AAA exchanges 1908 provides authorizations to the EAP peer. In order to ensure that all 1909 parties hold the same view of the authorizations it is RECOMMENDED 1910 that the Secure Association Protocol enable communication of 1911 authorizations between the EAP authenticator and peer. 1913 In order to enable key binding and authorization of all parties, it 1914 is RECOMMENDED that the parties use a set of identities that are 1915 consistent between the conversation phases. RADIUS [RFC2865] and 1916 Diameter NASREQ [RFC4005] require that the NAS/EAP authenticator 1917 identify itself by including one or more identification attributes 1918 within an Access-Request packet (NAS-Identifier, NAS-IP-Address, NAS- 1919 IPv6-Address). 1921 Since the backend authentication server provides EAP keying material 1922 for use by the EAP authenticator as identified by these attributes, 1923 where an EAP authenticator may have multiple ports, it is RECOMMENDED 1924 for the EAP authenticator to identify itself using NAS identification 1925 attributes during the Secure Association Protocol exchange with the 1926 EAP peer. This enables the EAP peer to determine whether EAP keying 1927 material has been shared between EAP authenticators as well as to 1928 confirm with the backend authentication server that an EAP 1929 authenticator proving possession of EAP keying material during the 1930 Secure Association Protocol was authorized to obtain it. Typically, 1931 the NAS-Identifier attribute is most convenient for this purpose, 1932 since a NAS/authenticator may have multiple IP addresses. 1934 Similarly, the backend authentication server authorizes the EAP 1935 authenticator to provide access to the EAP peer identified by the 1936 Peer-ID, securely verified during the EAP authentication exchange. 1937 In order to determine whether EAP keying material has been shared 1938 between EAP peers, where the EAP peer has multiple ports it is 1939 RECOMMENDED for the EAP peer to identify itself using the Peer-ID 1940 during the Secure Association Protocol exchange with the EAP 1941 authenticator. 1943 5.7. Replay Protection 1945 Replay protection allows a protocol message recipient to discard any 1946 message that was recorded during a previous legitimate dialogue and 1947 presented as though it belonged to the current dialogue. 1949 [RFC3748] Section 7.2.1 describes the "replay protection" security 1950 claim and [RFC4017] requires use of EAP methods supporting this 1951 claim. 1953 Diameter [RFC3588] provides support for replay protection via use of 1954 IPsec or TLS. RADIUS/EAP [RFC3579] protects against replay of keying 1955 material via the Request Authenticator. However, some RADIUS packets 1956 are not replay protected. In Accounting, Disconnect and CoA-Request 1957 packets the Request Authenticator contains a keyed MAC rather than a 1958 Nonce. The Response Authenticator in Accounting, Disconnect and CoA 1959 Response packets also contains a keyed MAC whose calculation does not 1960 depend on a Nonce in either the Request or Response packets. 1961 Therefore unless an Event-Timestamp attribute is included or IPsec is 1962 used, the recipient may not be able to determine whether these 1963 packets have been replayed. 1965 In order to prevent replay of Secure Association Protocol frames, 1966 replay protection is REQUIRED on all messages. [IEEE-802.11i] 1967 supports replay protection on all messages within the 4-way 1968 handshake. 1970 5.8. Key Freshness 1972 A session key should be considered compromised if it remains in use 1973 too long. As noted in [Housley], session keys MUST be strong and 1974 fresh, while preserving algorithm independence. A fresh 1975 cryptographic key is one that is generated specifically for the 1976 intended use. Each session deserves an independent session key; 1977 disclosure of one session key MUST NOT aid the attacker in 1978 discovering any other session keys. 1980 Fresh keys are required even when a long replay counter (that is, one 1981 that "will never wrap") is used to ensure that loss of state does not 1982 cause the same counter value to be used more than once with the same 1983 session key. 1985 EAP, AAA and the lower layer each bear responsibility for ensuring 1986 the use of fresh, strong session keys: 1988 EAP EAP methods need to ensure the freshness and strength of EAP keying 1989 material provided as an input to session key derivation. [RFC3748] 1990 Section 7.10 states that "EAP methods SHOULD ensure the freshness 1991 of the MSK and EMSK, even in cases where one party may not have a 1992 high quality random number generator. A RECOMMENDED method is for 1993 each party to provide a nonce of at least 128 bits, used in the 1994 derivation of the MSK and EMSK." The contribution of nonces 1995 enables the EAP peer and server to ensure that exported EAP keying 1996 material is fresh. 1998 [RFC3748] Section 7.2.1 describes the "key strength" and "session 1999 independence" security claims, and and [RFC4017] requires use of 2000 EAP methods supporting these claims as well as being capable of 2001 providing an equivalent key strength of 128 bits or greater. 2003 AAA The AAA protocol needs to ensure that transported keying material 2004 is fresh and is not utilized outside its recommended lifetime. 2005 Replay protection is necessary for key freshness, but an attacker 2006 can deliver a stale (and therefore potentially compromised) key in 2007 a replay-protected message, so replay protection is not sufficient. 2009 The EAP Session-ID, derived from the EAP Type and Method-ID (based 2010 on the nonces contributed by the peer and server) enables the EAP 2011 peer, authenticator and server to distinguish EAP conversations. 2012 However, unless the authenticator keeps track of EAP Session-IDs, 2013 the authenticator cannot use the Session-ID to guarantee the 2014 freshness of EAP keying material. 2016 As described in [RFC3580] Section 3.17, When sent in an Access- 2017 Accept along with a Termination-Action value of RADIUS-Request, the 2018 Session-Timeout attribute specifies the maximum number of seconds 2019 of service provided prior to re-authentication. [IEEE-802.11i] 2020 also utilizes the Session-Timeout attribute to limit the maximum 2021 time that EAP keying material may be cache. Therefore the use of 2022 the Session-Timeout attribute enables the backend authentication 2023 server to limit the exposure of EAP keying material. 2025 Lower Layer 2026 The lower layer Secure Association Protocol MUST generate a fresh 2027 session key for each session, even if the keying material and 2028 parameters provided by EAP methods are cached, or the peer or 2029 authenticator lack a high entropy random number generator. A 2030 RECOMMENDED method is for the peer and authenticator to each 2031 provide a nonce or counter used in session key derivation. If a 2032 nonce is used, it is RECOMMENDED that it be at least 128 bits. 2034 5.9. Elevation of Privilege 2036 Parties MUST NOT have access to keying material that is not needed to 2037 perform their own role. A party has access to a particular key if it 2038 has access to all of the secret information needed to derive it. If 2039 a post-EAP handshake is used to establish session keys, the post-EAP 2040 handshake MUST specify the scope for session keys. 2042 Transported EAP keying material is permitted to be accessed by the 2043 EAP peer, authenticator and server. The EAP peer and server derive 2044 the transported keying material during the process of mutually 2045 authenticating each other using the selected EAP method. During the 2046 Secure Association Protocol, the EAP peer utilizes the transported 2047 EAP keying material to demonstrate to the authenticator that it is 2048 the same party that authenticated to the EAP server and was 2049 authorized by it. The EAP authenticator utilizes the transported EAP 2050 keying material to prove to the peer not only that the EAP 2051 conversation was transported through it (this could be demonstrated 2052 by a man-in-the-middle), but that it was uniquely authorized by the 2053 EAP server to provide the peer with access to the network. Unique 2054 authorization can only be demonstrated if the EAP authenticator does 2055 not share the transported keying material with a party other than the 2056 EAP peer and server. 2058 TSKs are permitted to be accessed only by the EAP peer and 2059 authenticator. Since the TSKs can be determined from the transported 2060 EAP keying material and the cleartext of the Secure Association 2061 Protocol exchange, the backend authentication server will have access 2062 to the TSKs unless it deletes the transported EAP keying material 2063 after sending it. 2065 5.10. Man-in-the-middle Attacks 2067 As described in [I-D.puthenkulam-eap-binding], EAP method sequences 2068 and compound authentication mechanisms may be subject to man-in-the- 2069 middle attacks. When such attacks are successfully carried out, the 2070 attacker acts as an intermediary between a victim and a legitimate 2071 authenticator. This allows the attacker to authenticate successfully 2072 to the authenticator, as well as to obtain access to the network. 2074 In order to prevent these attacks, [I-D.puthenkulam-eap-binding] 2075 recommends derivation of a compound key by which the EAP peer and 2076 server can prove that they have participated in the entire EAP 2077 exchange. Since the compound key must not be known to an attacker 2078 posing as an authenticator, and yet must be derived from quantities 2079 that are exported by EAP methods, it may be desirable to derive the 2080 compound key from a portion of the EMSK. In order to provide proper 2081 key hygiene, it is recommended that the compound key used for man-in- 2082 the-middle protection be cryptographically separate from other keys 2083 derived from the EMSK. 2085 5.11. Denial of Service Attacks 2087 Key caching may result in vulnerability to denial of service attacks. 2088 For example, EAP methods that create persistent state may be 2089 vulnerable to denial of service attacks on the EAP server by a rogue 2090 EAP peer. 2092 To address this vulnerability, EAP methods creating persistent state 2093 may wish to limit the persistent state created by an EAP peer. For 2094 example, for each peer an EAP server may choose to limit persistent 2095 state to a few EAP conversations, distinguished by the EAP Session- 2096 ID. This prevents a rogue peer from denying access to other peers. 2098 Similarly, to conserve resources an authenticator may choose to limit 2099 the persistent state corresponding to each peer. This can be 2100 accomplished by limiting each peer to persistent sttate corresponding 2101 to a few EAP converations, distinguished by the EAP Session-ID. 2103 Depending on the media, creation of new TSKs may or may not imply 2104 deletion of previously derived TSKs. Where there is no implied 2105 deletion, the authenticator may choose to limit the number of TSKs 2106 and associated state that can be stored for each peer. 2108 5.12. Impersonation 2110 Both the RADIUS and Diameter protocols are potentially vulnerable to 2111 impersonation by a rogue authenticator. 2113 While AAA protocols such as RADIUS [RFC2865] or Diameter [RFC3588] 2114 support mutual authentication between the authenticator (known as the 2115 AAA client) and the backend authentication server (known as the 2116 backend authentication server), the security mechanisms vary 2117 according to the AAA protocol. 2119 In RADIUS, the shared secret used for authentication is determined by 2120 the source address of the RADIUS packet. As noted in [RFC3579] 2121 Section 4.3.7, it is highly desirable that the source address be 2122 checked against one or more NAS identification attributes so as to 2123 detect and prevent impersonation attacks. 2125 When RADIUS requests are forwarded by a proxy, the NAS-IP-Address or 2126 NAS-IPv6-Address attributes may not correspond to the source address. 2127 Since the NAS-Identifier attribute need not contain an FQDN, it also 2128 may not correspond to the source address, even indirectly. [RFC2865] 2129 Section 3 states: 2131 A RADIUS server MUST use the source IP address of the RADIUS 2132 UDP packet to decide which shared secret to use, so that 2133 RADIUS requests can be proxied. 2135 This implies that it is possible for a rogue authenticator to forge 2136 NAS-IP-Address, NAS-IPv6-Address or NAS-Identifier attributes within 2137 a RADIUS Access-Request in order to impersonate another 2138 authenticator. Among other things, this can result in messages (and 2139 transorted keying material) being sent to the wrong authenticator. 2140 Since the rogue authenticator is authenticated by the RADIUS proxy or 2141 server purely based on the source address, other mechanisms are 2142 required to detect the forgery. In addition, it is possible for 2143 attributes such as the Called-Station-Id and Calling-Station-Id to be 2144 forged as well. 2146 As recommended in [RFC3579] Section 4.3.7, this vulnerability can be 2147 mitigated by having RADIUS proxies check NAS identification 2148 attributes against the source address. 2150 While [RFC3588] requires use of the Route-Record AVP, this utilizes 2151 FQDNs, so that impersonation detection requires DNS A/AAAA and PTR 2152 RRs to be properly configured. As a result, it appears that Diameter 2153 is as vulnerable to this attack as RADIUS, if not more so. To 2154 address this vulnerability, it is necessary to allow the backend 2155 authentication server to communicate with the authenticator directly, 2156 such as via the redirect functionality supported in [RFC3588]. 2158 5.13. Channel Binding 2160 It is possible for a compromised or poorly implemented EAP 2161 authenticator to communicate incorrect information to the EAP peer 2162 and/or server. This may enable an authenticator to impersonate 2163 another authenticator or communicate incorrect information via out- 2164 of-band mechanisms (such as via AAA or the lower layer). 2166 Where EAP is used in pass-through mode, the EAP peer does not verify 2167 the identity of the pass-through authenticator. Within the Secure 2168 Association Protocol, the EAP peer and authenticator only demonstrate 2169 mutual possession of the transported EAP keying material. This 2170 creates a potential security vulnerability, described in [RFC3748] 2171 Section 7.15. 2173 [RFC3579] Section 4.3.7 describes how an EAP pass-through 2174 authenticator acting as a AAA client can be detected if it attempts 2175 to impersonate another authenticator (such by sending incorrect 2176 Called-Station-ID [RFC2865], NAS-Identifier [RFC2865], NAS-IP-Address 2177 [RFC2865] or NAS-IPv6-Address [RFC3162] attributes via the AAA 2178 protocol). However, it is possible for a pass-through authenticator 2179 acting as a AAA client to provide correct information to the backend 2180 authentication server while communicating misleading information to 2181 the EAP peer via the lower layer. 2183 For example, a compromised authenticator can utilize another 2184 authenticator's Called-Station-Id or NAS-Identifier in communicating 2185 with the EAP peer via the lower layer, or for a pass-through 2186 authenticator acting as a AAA client to provide an incorrect peer 2187 Calling-Station-Id [RFC2865][RFC3580] to the AAA server via the AAA 2188 protocol. 2190 As noted in [RFC3748] Section 7.15, this vulnerability can be 2191 addressed by EAP methods that support a protected exchange of channel 2192 properties such as endpoint identifiers, including (but not limited 2193 to): Called-Station-Id [RFC2865][RFC3580], Calling-Station-Id 2194 [RFC2865][RFC3580], NAS-Identifier [RFC2865], NAS-IP-Address 2195 [RFC2865], and NAS-IPv6-Address [RFC3162]. 2197 Using such a protected exchange, it is possible to match the channel 2198 properties provided by the authenticator via out-of-band mechanisms 2199 against those exchanged within the EAP method. For example, see [I- 2200 D.arkko-eap-service-identity-auth]. 2202 It is also possible to achieve Channel Bindings without transporting 2203 data over EAP. For example, see [draft-ohba-eap-aaakey-binding]. In 2204 this approach the authenticator informs the backend server about the 2205 Channel Binding parameters using AAA, and the backend server 2206 calculates transported keying material based on this parameter set, 2207 making it impossible for the peer and authenticator to complete the 2208 Secure Association Protocol if there was a mismatch in the 2209 parameters. 2211 The main difference between these approaches is that Channel Binding 2212 support within an EAP method may require upgrading or changing the 2213 EAP method, impacting both the peer and the server. Where Channel 2214 Bindings are implemented in AAA, the peer, authenticator and the 2215 backend server need to be upgraded, but the EAP method need not be 2216 modified. 2218 6. IANA Considerations 2220 This document does not create any new name spaces nor does it 2221 allocate any protocol parameters. 2223 7. References 2225 7.1. Normative References 2227 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2228 Requirement Levels", BCP 14, RFC 2119, March 1997. 2230 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 2231 Considerations Section in RFCs", BCP 26, RFC 2434, October 2232 1998. 2234 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 2235 Lefkowetz, "Extensible Authentication Protocol (EAP)", RFC 2236 3748, June 2004. 2238 7.2. Informative References 2240 [Analysis] 2241 He, C. and J. Mitchell, "Analysis of the 802.11i 4-Way 2242 Handshake", Proceedings of the 2004 ACM Workshop on Wireless 2243 Security, pp. 43-50, ISBN: 1-58113-925-X. 2245 [CTP] Loughney, J., Nakhjiri, M., Perkins, C. and R. Koodli, 2246 "Context Transfer Protocol", draft-ietf-seamoby-ctp-11.txt, 2247 Internet draft (work in progress), August 2004. 2249 [DESMODES] 2250 National Institute of Standards and Technology, "DES Modes of 2251 Operation", FIPS PUB 81, December 1980, . 2254 [FIPSDES] National Institute of Standards and Technology, "Data 2255 Encryption Standard", FIPS PUB 46, January 1977. 2257 [Housley] Housley, R. and B. Aboba, "AAA Key Management", draft-housley- 2258 aaa-key-mgmt-01.txt, Internet draft (work in progress), 2259 November 2005. 2261 [IEEE-802] 2262 Institute of Electrical and Electronics Engineers, "IEEE 2263 Standards for Local and Metropolitan Area Networks: Overview 2264 and Architecture", ANSI/IEEE Standard 802, 1990. 2266 [IEEE-802.11] 2267 Institute of Electrical and Electronics Engineers, 2268 "Information technology - Telecommunications and information 2269 exchange between systems - Local and metropolitan area 2270 networks - Specific Requirements Part 11: Wireless LAN Medium 2271 Access Control (MAC) and Physical Layer (PHY) Specifications", 2272 IEEE IEEE Standard 802.11-2003, 2003. 2274 [IEEE-802.1X] 2275 Institute of Electrical and Electronics Engineers, "Local and 2276 Metropolitan Area Networks: Port-Based Network Access 2277 Control", IEEE Standard 802.1X-2004, December 2004. 2279 [IEEE-802.1Q] 2280 Institute of Electrical and Electronics Engineers, "IEEE 2281 Standards for Local and Metropolitan Area Networks: Draft 2282 Standard for Virtual Bridged Local Area Networks", IEEE 2283 Standard 802.1Q/D8, January 1998. 2285 [IEEE-802.11i] 2286 Institute of Electrical and Electronics Engineers, "Supplement 2287 to STANDARD FOR Telecommunications and Information Exchange 2288 between Systems - LAN/MAN Specific Requirements - Part 11: 2289 Wireless Medium Access Control (MAC) and physical layer (PHY) 2290 specifications: Specification for Enhanced Security", IEEE 2291 802.11i, December 2004. 2293 [IEEE-802.11F] 2294 Institute of Electrical and Electronics Engineers, 2295 "Recommended Practice for Multi-Vendor Access Point 2296 Interoperability via an Inter-Access Point Protocol Across 2297 Distribution Systems Supporting IEEE 802.11 Operation", IEEE 2298 802.11F, July 2003 (now deprecated). 2300 [IEEE-802.16e] 2301 Institute of Electrical and Electronics Engineers, "IEEE 2302 Standard for Local and Metropolitan Area Networks: Part 16: 2303 Air Interface for Fixed and Mobile Broadband Wireless Access 2304 Systems: Amendment for Physical and Medium Access Control 2305 Layers for Combined Fixed and Mobile Operations in Licensed 2306 Bands" IEEE 802.16e, August 2005. 2308 [IEEE-02-758] 2309 Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, 2310 "Proactive Caching Strategies for IAPP Latency Improvement 2311 during 802.11 Handoff", IEEE 802.11 Working Group, 2312 IEEE-02-758r1-F Draft 802.11I/D5.0, November 2002. 2314 [IEEE-03-084] 2315 Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, 2316 "Proactive Key Distribution to support fast and secure 2317 roaming", IEEE 802.11 Working Group, IEEE-03-084r1-I, 2318 http://www.ieee802.org/11/Documents/DocumentHolder/ 3-084.zip, 2319 January 2003. 2321 [IEEE-03-155] 2322 Aboba, B., "Fast Handoff Issues", IEEE 802.11 Working Group, 2323 IEEE-03-155r0-I, http://www.ieee802.org/11/ 2324 Documents/DocumentHolder/3-155.zip, March 2003. 2326 [I-D.ietf-roamops-cert] 2327 Aboba, B., "Certificate-Based Roaming", draft-ietf-roamops- 2328 cert-02 (work in progress), April 1999. 2330 [I-D.puthenkulam-eap-binding] 2331 Puthenkulam, J., "The Compound Authentication Binding 2332 Problem", draft-puthenkulam-eap-binding-04 (work in progress), 2333 October 2003. 2335 [I-D.arkko-pppext-eap-aka] 2336 Arkko, J. and H. Haverinen, "EAP AKA Authentication", draft- 2337 arkko-pppext-eap-aka-15.txt (work in progress), December 2004. 2339 [I-D.arkko-eap-service-identity-auth] 2340 Arkko, J. and P. Eronen, "Authenticated Service Information 2341 for the Extensible Authentication Protocol (EAP)", draft- 2342 arkko-eap-service-identity-auth-02.txt (work in progress), May 2343 2005. 2345 [I-D.ohba-eap-aaakey-binding] 2346 Ohba, Y., "AAA-Key Derivation with Channel Binding", draft- 2347 ohba-eap-aaakey-binding-00.txt (work in progress), May 2005. 2349 [MD5Attack] 2350 Dobbertin, H., "The Status of MD5 After a Recent Attack", 2351 CryptoBytes, Vol.2 No.2, 1996. 2353 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 2354 September 1981. 2356 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 2357 1661, July 1994. 2359 [RFC1968] Meyer, G. and K. Fox, "The PPP Encryption Control Protocol 2360 (ECP)", RFC 1968, June 1996. 2362 [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing 2363 for Message Authentication", RFC 2104, February 1997. 2365 [RFC2246] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. 2366 and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, 2367 January 1999. 2369 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 2370 Internet Protocol", RFC 2401, November 1998. 2372 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 2373 RFC 2409, November 1998. 2375 [RFC2419] Sklower, K. and G. Meyer, "The PPP DES Encryption Protocol, 2376 Version 2 (DESE-bis)", RFC 2419, September 1998. 2378 [RFC2420] Kummert, H., "The PPP Triple-DES Encryption Protocol (3DESE)", 2379 RFC 2420, September 1998. 2381 [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D. and 2382 R. Wheeler, "A Method for Transmitting PPP Over Ethernet 2383 (PPPoE)", RFC 2516, February 1999. 2385 [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2386 2535, March 1999. 2388 [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2389 2548, March 1999. 2391 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 2392 Implementation in Roaming", RFC 2607, June 1999. 2394 [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol", 2395 RFC 2716, October 1999. 2397 [RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for 2398 specifying the location of services (DNS SRV)", RFC 2782, 2399 February 2000. 2401 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, 2402 "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2403 2845, May 2000. 2405 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 2406 Authentication Dial In User Service (RADIUS)", RFC 2865, June 2407 2000. 2409 [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (SIG(0)s 2410 )", RFC 2931, September 2000. 2412 [RFC3007] Wellington, B., "Simple Secure Domain Name System (DNS) 2413 Dynamic Update", RFC 3007, November 2000. 2415 [RFC3078] Pall, G. and G. Zorn, "Microsoft Point-To-Point Encryption 2416 (MPPE) Protocol", RFC 3078, March 2001. 2418 [RFC3079] Zorn, G., "Deriving Keys for use with Microsoft Point-to-Point 2419 Encryption (MPPE)", RFC 3079, March 2001. 2421 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial 2422 In User Service) Support For Extensible Authentication 2423 Protocol (EAP)", RFC 3579, September 2003. 2425 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese, 2426 "IEEE 802.1X Remote Authentication Dial In User Service 2427 (RADIUS) Usage Guidelines", RFC 3580, September 2003. 2429 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. 2430 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 2432 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public 2433 Keys Used For Exchanging Symmetric Keys", RFC 3766, April 2434 2004. 2436 [RFC4005] Calhoun, P., Zorn, G., Spence, D. and D. Mitton, "Diameter 2437 Network Access Server Application", RFC 4005, August 2005. 2439 [RFC4017] Stanley, D., Walker, J. and B. Aboba, "EAP Method Requirements 2440 for Wireless LANs", RFC 4017, March 2005. 2442 [RFC4046] Baugher, M., Canetti, R., Dondeti, L. and F. Lindholm, 2443 "Multicast Security (MSEC) Group Key Management Architecture", 2444 RFC 4046, April 2005. 2446 [RFC4072] Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible 2447 Authentication Protocol (EAP) Application", RFC 4072, August 2448 2005. 2450 [RFC4118] Yang, L., Zerfos, P. and E. Sadot, "Architecture Taxonomy for 2451 Control and Provisioning of Wireless Access Points (CAPWAP)", 2452 RFC 4118, June 2005. 2454 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 2455 4306, December 2005. 2457 [8021XHandoff] 2458 Pack, S. and Y. Choi, "Pre-Authenticated Fast Handoff in a 2459 Public Wireless LAN Based on IEEE 802.1X Model", School of 2460 Computer Science and Engineering, Seoul National University, 2461 Seoul, Korea, 2002. 2463 Acknowledgments 2465 Thanks to Arun Ayyagari, Ashwin Palekar, and Tim Moore of Microsoft, 2466 Dorothy Stanley of Agere, Bob Moskowitz of TruSecure, Jesse Walker of 2467 Intel, Joe Salowey of Cisco and Russ Housley of Vigil Security for 2468 useful feedback. 2470 Author Addresses 2472 Bernard Aboba 2473 Microsoft Corporation 2474 One Microsoft Way 2475 Redmond, WA 98052 2477 EMail: bernarda@microsoft.com 2478 Phone: +1 425 706 6605 2479 Fax: +1 425 936 7329 2481 Dan Simon 2482 Microsoft Research 2483 Microsoft Corporation 2484 One Microsoft Way 2485 Redmond, WA 98052 2487 EMail: dansimon@microsoft.com 2488 Phone: +1 425 706 6711 2489 Fax: +1 425 936 7329 2491 Jari Arkko 2492 Ericsson 2493 Jorvas 02420 2494 Finland 2496 Phone: 2497 EMail: jari.arkko@ericsson.com 2499 Pasi Eronen 2500 Nokia Research Center 2501 P.O. Box 407 2502 FIN-00045 Nokia Group 2503 Finland 2505 EMail: pasi.eronen@nokia.com 2507 Henrik Levkowetz (editor) 2508 ipUnplugged AB 2509 Arenavagen 27 2510 Stockholm S-121 28 2511 SWEDEN 2513 Phone: +46 708 32 16 08 2514 EMail: henrik@levkowetz.com 2516 Appendix A - Exported Parameters in Existing Methods 2518 This Appendix specifies Method-ID, Peer-ID, Server-ID and Key- 2519 Lifetime for EAP methods that have been published prior to this 2520 specification. Future EAP method specifications MUST include a 2521 definition of the Method-ID, Peer-ID, and Server-ID (could be the 2522 empty string) and MAY also define the Key-Lifetime (assumed to be 2523 indeterminate if not described). 2525 EAP-Identity 2527 The EAP-Identity method does not derive keys, and therefore does 2528 not define the Key-Lifetime or Method-ID. The Peer-ID exported by 2529 the Identity method is determined by the octets included within 2530 the EAP- Response/Identity. The Server-ID is the empty string 2531 (zero length). 2533 EAP-Notification 2535 The EAP-Notification method does not derive keys and therefore 2536 does not define the Key-Lifetime and Method-ID. The Peer-ID and 2537 Server-ID are the empty string (zero length). 2539 EAP-GTC 2541 The EAP-GTC method does not derive keys and therefore does not 2542 define the Key-Lifetime and Method-ID. The Peer-ID and Server-ID 2543 are the empty string. 2545 EAP-OTP 2547 The EAP-OTP method does not derive keys and therefore does not 2548 define the Key-Lifetime and Method-ID. The Peer-ID and Server-ID 2549 are the empty string. 2551 EAP-TLS 2553 The EAP-TLS Method-Id is the concatenation of the peer and server 2554 nonces. 2556 The Peer-ID and Server-ID are the contents of the altSubjectName 2557 in the peer and server certificates. 2559 EAP-TLS does not negotiate a Key-Lifetime. 2561 EAP-AKA 2563 The EAP-AKA Method-Id is the contents of the RAND field from the 2564 AT_RAND attribute, followed by the contents of the AUTN field in 2565 the AT_AUTN attribute. 2567 The Peer-ID is the contents of the Identity field from the 2568 AT_IDENTITY attribute, using only the Actual Identity Length 2569 octets from the beginning, however. Note that the contents are 2570 used as they are transmitted, regardless of whether the 2571 transmitted identity was a permanent, pseudonym, or fast re- 2572 authentication identity. The Server-ID is an empty string. EAP- 2573 AKA does not negotiate a key lifetime. 2575 EAP-SIM 2577 The Method-Id is the contents of the RAND field from the AT_RAND 2578 attribute, followed by the contents of the NONCE_MT field in the 2579 AT_NONCE_MT attribute. 2581 The Peer-ID is the contents of the Identity field from the 2582 AT_IDENTITY attribute, using only the Actual Identity Length 2583 octets from the beginning, however. Note that the contents are 2584 used as they are transmitted, regardless of whether the 2585 transmitted identity was a permanent, pseudonym, or fast re- 2586 authentication identity. The Server-ID is an empty string. EAP- 2587 SIM does not negotiate a key lifetime. 2589 Intellectual Property Statement 2591 The IETF takes no position regarding the validity or scope of any 2592 Intellectual Property Rights or other rights that might be claimed to 2593 pertain to the implementation or use of the technology described in 2594 this document or the extent to which any license under such rights 2595 might or might not be available; nor does it represent that it has 2596 made any independent effort to identify any such rights. Information 2597 on the procedures with respect to rights in RFC documents can be 2598 found in BCP 78 and BCP 79. 2600 Copies of IPR disclosures made to the IETF Secretariat and any 2601 assurances of licenses to be made available, or the result of an 2602 attempt made to obtain a general license or permission for the use of 2603 such proprietary rights by implementers or users of this 2604 specification can be obtained from the IETF on-line IPR repository at 2605 http://www.ietf.org/ipr. 2607 The IETF invites any interested party to bring to its attention any 2608 copyrights, patents or patent applications, or other proprietary 2609 rights that may cover technology that may be required to implement 2610 this standard. Please address the information to the IETF at ietf- 2611 ipr@ietf.org. 2613 Disclaimer of Validity 2615 This document and the information contained herein are provided on an 2616 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2617 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2618 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2619 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2620 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2621 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2623 Copyright Statement 2625 Copyright (C) The Internet Society (2006). This document is subject 2626 to the rights, licenses and restrictions contained in BCP 78, and 2627 except as set forth therein, the authors retain all their rights. 2629 Acknowledgment 2631 Funding for the RFC Editor function is currently provided by the 2632 Internet Society. 2634 Open Issues 2636 Open issues relating to this specification are tracked on the 2637 following web site: 2639 http://www.drizzle.com/~aboba/EAP/eapissues.html