idnits 2.17.1 draft-ietf-eap-keying-09.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 2599. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2576. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2583. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2589. ** 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 : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** 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 700 has weird spacing: '... enable inter...' == Line 702 has weird spacing: '... the lower ...' == Line 1110 has weird spacing: '...enerate fresh...' == Line 1368 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 1639 -- Looks like a reference, but probably isn't: '2' on line 1643 == Missing Reference: 'IEEE-802.1X-2004' is mentioned on line 807, but not defined == Missing Reference: 'IEEE-802.16e' is mentioned on line 813, but not defined == Missing Reference: 'RFC 3748' is mentioned on line 1210, but not defined == Missing Reference: 'RFC3759' is mentioned on line 1361, but not defined == Missing Reference: 'RFC3784' is mentioned on line 1630, but not defined ** Obsolete undefined reference: RFC 3784 (Obsoleted by RFC 5305) -- Looks like a reference, but probably isn't: '3' on line 1650 -- Looks like a reference, but probably isn't: '4' on line 1653 -- Looks like a reference, but probably isn't: '5' on line 1657 -- Looks like a reference, but probably isn't: '6' on line 1662 -- Looks like a reference, but probably isn't: '7' on line 1664 -- Looks like a reference, but probably isn't: '8' on line 1670 == Missing Reference: 'RFC3162' is mentioned on line 2106, but not defined == Missing Reference: 'RFC 2716' is mentioned on line 2400, but not defined ** Obsolete undefined reference: RFC 2716 (Obsoleted by RFC 5216) == Unused Reference: 'RFC2434' is defined on line 2141, but no explicit reference was found in the text == Unused Reference: 'DESMODES' is defined on line 2160, but no explicit reference was found in the text == Unused Reference: 'FIPSDES' is defined on line 2165, but no explicit reference was found in the text == Unused Reference: 'IEEE-802' is defined on line 2172, but no explicit reference was found in the text == Unused Reference: 'IEEE-802.11' is defined on line 2177, but no explicit reference was found in the text == Unused Reference: 'IEEE-02-758' is defined on line 2211, but no explicit reference was found in the text == Unused Reference: 'IEEE-03-084' is defined on line 2217, but no explicit reference was found in the text == Unused Reference: 'IEEE-03-155' is defined on line 2224, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roamops-cert' is defined on line 2229, but no explicit reference was found in the text == Unused Reference: 'I-D.arkko-pppext-eap-aka' is defined on line 2238, but no explicit reference was found in the text == Unused Reference: 'I-D.arkko-eap-service-identity-auth' is defined on line 2242, but no explicit reference was found in the text == Unused Reference: 'I-D.ohba-eap-aaakey-binding' is defined on line 2248, but no explicit reference was found in the text == Unused Reference: 'RFC0793' is defined on line 2259, but no explicit reference was found in the text == Unused Reference: 'RFC2104' is defined on line 2268, but no explicit reference was found in the text == Unused Reference: 'RFC2401' is defined on line 2275, but no explicit reference was found in the text == Unused Reference: 'RFC2409' is defined on line 2278, but no explicit reference was found in the text == Unused Reference: 'RFC2419' is defined on line 2281, but no explicit reference was found in the text == Unused Reference: 'RFC2420' is defined on line 2284, but no explicit reference was found in the text == Unused Reference: 'RFC2516' is defined on line 2287, but no explicit reference was found in the text == Unused Reference: 'RFC2607' is defined on line 2294, but no explicit reference was found in the text == Unused Reference: 'RFC3078' is defined on line 2304, but no explicit reference was found in the text == Unused Reference: 'RFC3079' is defined on line 2307, but no explicit reference was found in the text == Unused Reference: '8021XHandoff' is defined on line 2339, 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 2716 (Obsoleted by RFC 5216) -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 4005 (Obsoleted by RFC 7155) Summary: 8 errors (**), 0 flaws (~~), 43 warnings (==), 23 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 8 January 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 ........................................ 13 59 2.3 Transient Session Keys .......................... 15 60 2.4 Key Scope ....................................... 18 61 3. Key Management ........................................ 22 62 3.1 Secure Association Protocol ..................... 22 63 3.2 Parent-Child Relationships ...................... 25 64 3.3 Local Key Lifetimes ............................. 26 65 3.4 Exported and Calculated Key Lifetimes ........... 26 66 3.5 Key Cache Synchronization ....................... 28 67 3.6 Key Strength .................................... 28 68 3.7 Key Wrap ........................................ 29 69 4. Handoff Vulnerabilities ............................... 30 70 4.1 Authorization ................................... 30 71 4.2 Correctness ..................................... 31 72 5. Security Considerations .............................. 34 73 5.1 Security Terminology ............................ 35 74 5.2 Threat Model .................................... 35 75 5.3 Authenticator Compromise ........................ 36 76 5.4 Spoofing ........................................ 37 77 5.5 Downgrade Attacks ............................... 37 78 5.6 Unauthorized Disclosure ......................... 38 79 5.7 Replay Protection ............................... 40 80 5.8 Key Freshness ................................... 40 81 5.9 Elevation of Privilege .......................... 41 82 5.10 Man-in-the-Middle Attacks ....................... 42 83 5.11 Denial of Service Attacks ....................... 43 84 5.12 Impersonation ................................... 43 85 5.13 Channel Binding ................................. 44 86 6. IANA Considerations ................................... 45 87 7. References ............................................ 45 88 7.1 Normative References ............................ 45 89 7.2 Informative References .......................... 46 90 Acknowledgments .............................................. 50 91 Author's Addresses ........................................... 50 92 Appendix A - EAP-TLS Key Hierarchy ........................... 52 93 Appendix B - Exported Parameters in Existing Methods ......... 53 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. An 210 example TEK key hierarchy is described in Appendix A. 212 Transient Session Keys (TSKs) 213 Session keys used to protect data exchanged after EAP 214 authentication has successfully completed, using the ciphersuite 215 negotiated between the EAP peer and authenticator. 217 AAA-Key 218 The term AAA-Key is synonymous with MSK. 220 1.3. Overview 222 EAP, defined in [RFC3748], is a two-party protocol spoken between the 223 EAP peer and server. Within EAP, keying material is generated by EAP 224 methods. Part of this keying material may be used by EAP methods 225 themselves and part of this material may be exported. In addition to 226 export of keying material, EAP methods may also export associated 227 parameters, and may import and export Channel Bindings from the lower 228 layer. 230 As illustrated in Figure 1, the EAP method key derivation has at the 231 root the long term credential utilized by the selected EAP method. 232 If authentication is based on a pre-shared key, the parties store the 233 EAP method to be used and the pre-shared key. The EAP server also 234 stores the peer's identity as well as other information associated 235 with it. This information may be used to determine whether access to 236 some service should be granted. The peer stores information necessary 237 to choose which secret to use for which service. 239 If authentication is based on proof of possession of the private key 240 corresponding to the public key contained within a certificate, the 241 parties store the EAP method to be used and the trust anchors used to 242 validate the certificates. The EAP server also stores the peer's 243 identity and the peer stores information necessary to choose which 244 certificate to use for which service. 246 Based on the long term credential established between the peer and 247 the server, EAP methods derive two types of keys: 249 [1] Keys calculated locally by the EAP method but not exported 250 by the EAP method, such as the TEKs. 251 [2] Keying material exported by the EAP method: MSK, EMSK, IV. 253 As noted in [RFC3748] Section 7.10, EAP methods generating keys are 254 required to calculate and export the MSK and EMSK, which must be at 255 least 64 octets in length. EAP methods also may export the IV; 256 however, the use of the IV is deprecated. 258 EAP methods also MAY export method-specific peer and server 259 identifiers (peer-ID and server-ID), a method-specific EAP 260 conversation identifier known as the Method-ID, and the lifetime of 261 the exported keys, known as the Key-Lifetime. EAP methods MAY also 262 support the import and export of Channel Bindings. New EAP method 263 specifications MUST define the Peer-ID, Server-ID and Method-ID. The 264 combination of the Peer-ID and Server-ID uniquely specifies the 265 endpoints of the EAP method exchange. 267 Peer-ID 269 As described in [RFC3748] Section 7.3, the identity provided in the 270 EAP-Response/Identity, may be different from the peer identity 271 authenticated by the EAP method. Where the EAP method authenticates 272 the peer identity, that identity is exported by the method as the 273 Peer-ID. A suitable EAP peer name may not always be available. 274 Where an EAP method does not define a method-specific peer identity, 275 the Peer-ID is the null string. The Peer-ID for existing EAP 276 methods is defined in Appendix B. 278 Server-ID 280 Where the EAP method authenticates the server identity, that identity 281 is exported by the method as the Server-ID. A suitable EAP server 282 name may not always be available. Where an EAP method does not 283 define a method-specific peer identity, the Server-ID is the null 284 string. The Server-ID for existing EAP methods is defined in 285 Appendix B. 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 288 | | ^ 289 | EAP Method | | 290 | | | 291 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | | 292 | | | | | | | 293 | | EAP Method Key |<->| Long-Term | | | 294 | | Derivation | | Credential | | | 295 | | | | | | | 296 | | | +-+-+-+-+-+-+-+ | Local to | 297 | | | | EAP | 298 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Method | 299 | | | | | | 300 | | | | | | 301 | | | | | | 302 | | | | | | 303 | | | | | | 304 | | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | | 305 | | | TEK | |MSK, EMSK | |IV | | | 306 | | |Derivation | |Derivation | |Derivation | | | 307 | | | | | | |(Deprecated) | | | 308 | | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | | 309 | | ^ | | | | 310 | | | | | | V 311 +-+-|-+-+-+-+-+-+-+-+-|-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+ ---+ 312 | | | | ^ 313 | Peer-ID, | | | Exported | 314 | Server-ID, | Channel | MSK (64+B) | IV (64B) by | 315 | Method-ID, | Bindings | EMSK (64+B) | (Optional) EAP | 316 | Key-Lifetime | & Result | | Method | 317 V V V V V 319 Figure 1: EAP Method Parameter Import/Export 321 Method-ID 323 EAP method specifications deriving keys MUST specify a temporally 324 unique method identifier known as the Method-ID. The EAP Method-ID 325 uniquely identifies an EAP session of a given Type between an EAP 326 peer and server. The Method-ID is typically constructed from nonces 327 or counters used within the EAP method exchange. The Method-ID for 328 existing EAP methods is defined in Appendix B. 330 Session-ID 332 The Session-ID uniquely identifies an EAP session between an EAP peer 333 (as identified by the Peer-ID) and server (as identified by the 334 Server-ID). The EAP Session-ID consists of the concatenation of the 335 Expanded EAP Type Code (including the Type, Vendor-ID and Vendor-Type 336 fields defined in [RFC3748] Section 5.7) and the Method-ID. The 337 inclusion of the Expanded Type Code in the EAP Session-Id ensures 338 that each EAP method has a distinct Session-ID space. Since an EAP 339 session is not bound to a particular authenticator or specific ports 340 on the peer and authenticator, the authenticator port or identity are 341 not included in the Session-Id. 343 Key-Lifetime 345 While EAP itself does not support key lifetime negotiation, it is 346 possible to specify methods that do. However, systems that rely on 347 such negotiation for exported keys would only function with these 348 methods. As a result, it is NOT RECOMMENDED to use this approach as 349 the sole way to determine key lifetimes. 351 Channel Bindings 353 Channel Bindings include lower layer parameters that are verified for 354 consistency between the EAP peer and server. In order to avoid 355 introducing media dependencies, EAP methods that transport Channel 356 Binding data MUST treat this data as opaque octets. Typically the 357 EAP method imports Channel Bindings from the lower layer on the peer, 358 and transmits them securely to the EAP server, which exports them to 359 the lower layer. However, transport may occur from EAP server to 360 peer, or may be bi-directional. On the side of the exchange (peer or 361 server) where Channel Bindings are verified, the lower layer passes 362 the result of the verification (TRUE or FALSE) up to the EAP method. 364 1.3.1. Key Naming 366 Each key created within the EAP key management framework has a name 367 (a unique identifier), as well as a scope (the parties to whom the 368 key is available). The scope of exported parameters is defined by 369 the EAP peer name (if securely exchanged within the method) and the 370 EAP server name (also only if securely exchanged). Where a peer or 371 server name is missing the null string is used. 373 MSK and EMSK Names 374 These parameters are exported by the EAP peer and EAP server, and 375 can be referred to using the EAP Session-ID and a binary or textual 376 indication of the parameter being referred to. 378 PMK Name 379 This document does not specify a naming scheme for the PMK. The 380 PMK is only identified by the key from which it is derived. 382 Note: IEEE 802.11i names the PMKID for the purposes of being able 383 to refer to it in the Secure Association protocol; this naming is 384 based on a hash of the PMK itself as well as some other parameters 385 (see Section 8.5.1.2 [IEEE-802.11i]). 387 TEK Name 388 The TEKs may or may not be named. Their naming is specified in the 389 EAP method. 391 TSK Name 392 The TSKs are typically named. Their naming is specified in the 393 lower layer so that the correct set of transient session keys can 394 be identified for processing a given packet. 396 1.4. EAP Invariants 398 Certain basic characteristics, known as "EAP Invariants", hold true 399 for EAP implementations on all media: 401 Mode independence 402 Media independence 403 Method independence 404 Ciphersuite independence 406 1.4.1. Mode Independence 408 EAP is typically deployed in order to support extensible network 409 access authentication in situations where a peer desires network 410 access via one or more authenticators. Where authenticators are 411 deployed standalone, the EAP conversation occurs between the peer and 412 authenticator, and the authenticator must locally implement an EAP 413 method acceptable to the peer. However, one of the advantages of EAP 414 is that it enables deployment of new authentication methods without 415 requiring development of new code on the authenticator. 417 While the authenticator may implement some EAP methods locally and 418 use those methods to authenticate local users, it may at the same 419 time act as a pass-through for other users and methods, forwarding 420 EAP packets back and forth between the backend authentication server 421 and the peer. This is accomplished by encapsulating EAP packets 422 within the Authentication, Authorization and Accounting (AAA) 423 protocol, spoken between the authenticator and backend authentication 424 server. AAA protocols supporting EAP include RADIUS [RFC3579] and 425 Diameter [RFC4072]. 427 It is a fundamental property of EAP that at the EAP method layer, the 428 conversation between the EAP peer and server is unaffected by whether 429 the EAP authenticator is operating in "pass-through" mode. EAP 430 methods operate identically in all aspects, including key derivation 431 and parameter import/export, regardless of whether the authenticator 432 is operating as a pass-through or not. 434 The successful completion of an EAP method that supports key 435 derivation results in the export of keying material on the EAP peer 436 and server. Even though the EAP peer or server may import Channel- 437 Bindings that may include the identity of the EAP authenticator, 438 this information is treated as opaque octets. As a result, within 439 EAP the only relevant identities are the Peer-ID and Server-ID. 440 Channel Bindings are only interpreted by the lower layer. 442 Within EAP, the primary function of the AAA protocol is to maintain 443 the principle of Mode Independence, so that as far as the EAP peer is 444 concerned, its conversation with the EAP authenticator, and all 445 consequences of that conversation, are identical, regardless of the 446 authenticator mode of operation. 448 1.4.2. Media Independence 450 One of the goals of EAP is to allow EAP methods to function on any 451 lower layer meeting the criteria outlined in [RFC3748], Section 3.1. 452 For example, as described in [RFC3748], EAP authentication can be run 453 over PPP [RFC1661], IEEE 802 wired networks [IEEE-802.1X], and IEEE 454 802.11 wireless LANs [IEEE-802.11i]. 456 In order to maintain media independence, it is necessary for EAP to 457 avoid consideration of media-specific elements. For example, EAP 458 methods cannot be assumed to have knowledge of the lower layer over 459 which they are transported, and cannot be restricted to identifiers 460 associated with a particular usage environment (e.g. MAC addresses). 462 Note that media independence may be retained within EAP methods that 463 support Channel-Bindings or method-specific identification. An EAP 464 method need not be aware of the content of an identifier in order to 465 use it. This enables an EAP method to use media-specific identifiers 466 such as MAC addresses without compromising media independence. 467 Channel-Bindings are treated as opaque octets by EAP methods, so that 468 handling them does not require media-specific knowledge. 470 1.4.3. Method Independence 472 By enabling pass-through, authenticators can support any method 473 implemented on the peer and server, not just locally implemented 474 methods. This allows the authenticator to avoid implementing code 475 for each EAP method required by peers. In fact, since a pass-through 476 authenticator is not required to implement any EAP methods at all, it 477 cannot be assumed to support any EAP method-specific code. 479 As a result, as noted in [RFC3748], authenticators must by default be 480 capable of supporting any EAP method. This is useful where there is 481 no single EAP method that is both mandatory-to-implement and offers 482 acceptable security for the media in use. For example, the [RFC3748] 483 mandatory-to-implement EAP method (MD5-Challenge) does not provide 484 dictionary attack resistance, mutual authentication or key 485 derivation, and as a result is not appropriate for use in wireless 486 LAN authentication [RFC4017]. However, despite this it is possible 487 for the peer and authenticator to interoperate as long as a suitable 488 EAP method is supported on the EAP server. 490 1.4.4. Ciphersuite Independence 492 Ciphersuite Independence is a requirement for Media Independence. 493 Since lower layer ciphersuites vary between media, media independence 494 requires that EAP keying material needs to be large enough (with 495 sufficient entropy) to handle any ciphersuite. 497 While EAP methods may negotiate the ciphersuite used in protection of 498 the EAP conversation, the ciphersuite used for the protection of the 499 data exchanged after EAP authentication has completed is negotiated 500 between the peer and authenticator within the lower layer, outside of 501 EAP. 503 For example, within PPP, the ciphersuite is negotiated within the 504 Encryption Control Protocol (ECP) defined in [RFC1968], after EAP 505 authentication is completed. Within [IEEE-802.11i], the AP 506 ciphersuites are advertised in the Beacon and Probe Responses prior 507 to EAP authentication, and are securely verified during a 4-way 508 handshake exchange. 510 Since the ciphersuites used to protect data depend on the lower 511 layer, requiring EAP methods have knowledge of lower layer 512 ciphersuites would compromise the principle of Media Independence. 513 Since ciphersuite negotiation occurs in the lower layer, there is no 514 need for ciphersuite negotiation within EAP, and EAP methods generate 515 keying material that is ciphersuite-independent. 517 Algorithms for deriving TSKs MUST NOT depend on the EAP method, 518 although algorithms for TEK derivation MAY be specific to the EAP 519 method. 521 In order to allow a ciphersuite to be usable within the EAP keying 522 framework, a specification MUST be provided describing how TSKs 523 suitable for use with the ciphersuite are derived from exported EAP 524 keying parameters. 526 Advantages of ciphersuite-independence include: 528 Reduced update requirements 529 If EAP methods were to specify how to derive transient session keys 530 for each ciphersuite, they would need to be updated each time a new 531 ciphersuite is developed. In addition, backend authentication 532 servers might not be usable with all EAP-capable authenticators, 533 since the backend authentication server would also need to be 534 updated each time support for a new ciphersuite is added to the 535 authenticator. 537 Reduced EAP method complexity 538 Requiring each EAP method to include ciphersuite-specific code for 539 transient session key derivation would increase method complexity 540 and result in duplicated effort. 542 Simplified configuration 543 The ciphersuite is negotiated between the peer and authenticator 544 outside of EAP. Where the authenticator operates in "pass-through" 545 mode, the EAP server is not a party to this negotiation, nor is it 546 involved in the data flow between the EAP peer and authenticator. 547 As a result, the EAP server may not have knowledge of the 548 ciphersuites and negotiation policies implemented by the peer and 549 authenticator, or be aware of the ciphersuite negotiated between 550 them. For example, since ECP negotiation occurs after 551 authentication, when run over PPP, the EAP peer and server may not 552 anticipate the negotiated ciphersuite and therefore this 553 information cannot be provided to the EAP method. 555 2. Lower Layer Operation 557 2.1. Overview 559 Where EAP key derivation is supported, the conversation typically 560 takes place in three phases: 562 Phase 0: Discovery 563 Phase 1: Authentication 564 1a: EAP authentication 565 1b: AAA Key Transport (optional) 566 Phase 2: Secure Association Establishment 567 2a: Unicast Secure Association 568 2b: Multicast Secure Association (optional) 570 Of these phases, Phase 0, 1b and Phase 2 are handled by a lower 571 layer. In the discovery phase (phase 0), peers locate 572 authenticators and discover their capabilities. A peer may locate an 573 authenticator providing access to a particular network, or a peer may 574 locate an authenticator behind a bridge with which it desires to 575 establish a Secure Association. Discovery can occur manually or 576 automatically, depending on the lower layer over which EAP runs. 578 The authentication phase (phase 1) may begin once the peer and 579 authenticator discover each other. This phase, if it occurs, always 580 includes EAP authentication (phase 1a). Where the chosen EAP method 581 supports key derivation, in phase 1a EAP keying material is derived 582 on both the peer and the EAP server. 584 An additional step (phase 1b) is required in deployments which 585 include a backend authentication server, in order to transport keying 586 material from the backend authentication server to the authenticator. 587 In order to obey the principle of Mode Independence, where a backend 588 server is present, all keying material which us required by the lower 589 layer needs to be transported from the EAP server to the 590 authenticator. Since existing TSK derivation techniques depend 591 solely on the MSK, in existing implementations, this is the only 592 keying material replicated in the AAA key transport phase 1b. 594 Successful completion of EAP authentication and key derivation by a 595 peer and EAP server does not necessarily imply that the peer is 596 committed to joining the network associated with an EAP server. 597 Rather, this commitment is implied by the creation of a security 598 association between the EAP peer and authenticator, as part of the 599 Secure Association Protocol (phase 2). 601 The Secure Association exchange (phase 2) occurs between the peer and 602 authenticator in order to manage the creation and deletion of unicast 603 (phase 2a) and multicast (phase 2b) security associations between the 604 peer and authenticator. The conversation between the parties is 605 shown in Figure 2. 607 2.2. Layering 609 In completion of EAP authentication, EAP methods on the peer and EAP 610 server export the Master Session Key (MSK), Extended Master Session 611 Key (EMSK), Initialization Vector (IV), Peer-ID, Server-ID, Session- 612 ID and Key-Lifetime. As illustrated in Figure 3, EAP methods export 613 keying material and parameters to the EAP peer or authenticator 614 layers. 616 The EAP peer and authenticator layers MUST NOT modify or cache keying 617 material or parameters (including Channel Bindings) passing in either 618 direction between the EAP method layer and the EAP layer. The EAP 619 layer also MUST NOT cache keying material or parameters (including 620 Channel Bindings) passed to it by the EAP peer/authenticator layer or 621 the lower layer. 623 EAP peer Authenticator Auth. Server 624 -------- ------------- ------------ 625 |<----------------------------->| | 626 | Discovery (phase 0) | | 627 |<----------------------------->|<----------------------------->| 628 | EAP auth (phase 1a) | AAA pass-through (optional) | 629 | | | 630 | |<----------------------------->| 631 | | AAA Key transport | 632 | | (optional; phase 1b) | 633 |<----------------------------->| | 634 | Unicast Secure association | | 635 | (phase 2a) | | 636 | | | 637 |<----------------------------->| | 638 | Multicast Secure association | | 639 | (optional; phase 2b) | | 640 | | | 642 Figure 2: Conversation Overview 644 Based on the Method-ID exported by the EAP method, the EAP layer 645 forms the EAP Session-ID by concatenating the EAP Expanded Type with 646 the Method-ID. Together with the MSK, IV (deprecated), Peer-ID, 647 Server-ID, and Key-Lifetime, the EAP layer passes the Session-ID down 648 to the lower layer. The Method-ID is exported by EAP methods rather 649 than the Session-ID so as to prevent EAP methods from writing into 650 each other's Session- ID space. 652 The EMSK MUST NOT be provided to the lower layer, nor is it permitted 653 to pass any quantity to the lower layer from which the EMSK could be 654 computed without breaking some cryptographic assumption, such as 655 inverting a one-way function. As noted in [RFC3748] Section 7.10: 657 The EMSK is reserved for future use and MUST remain on the EAP 658 peer and EAP server where it is derived; it MUST NOT be 659 transported to, or shared with, additional parties, or used to 660 derive any other keys. (This restriction will be relaxed in a 661 future document that specifies how the EMSK can be used.) 663 In order to preserve the security of keys derived within EAP methods, 664 lower layers other than AAA MUST NOT export keys passed down by EAP 665 methods. This implies that EAP keying material or parameters passed 666 down to a lower layer are for the exclusive use of that lower layer 667 and MUST NOT be used within another lower layer. This prevents 668 compromise of one lower layer from compromising other applications 669 using EAP keying parameters. 671 EAP keying material and parameters provided to a lower layer other 672 than AAA MUST NOT be transported to another entity. For example, EAP 673 keying material and parameters passed down to the EAP peer lower 674 layer MUST NOT leave the peer; EAP keying material and parameters 675 passed down or transported to the EAP authenticator lower layer MUST 676 NOT leave the authenticator. 678 The exception to the "no sharing" rule is the AAA layer. On EAP 679 server, keying material requested by and passed down to the AAA layer 680 may be replicated to the AAA layer on the authenticator. On the 681 authenticator, the AAA layer may provide the replicated keying 682 material to the lower layer over which the EAP authentication 683 conversation took place. This enables "mode independence" to be 684 maintained. 686 As illustrated in Figure 4, a AAA client receiving transported EAP 687 keying material and parameters passes them to the EAP authenticator 688 and EAP layers, which then provide them to the authenticator lower 689 layer using the same mechanisms that would be used if the EAP peer 690 and authenticator were conducting a stand-alone conversation. The 691 resulting key state in the lower layer is indistinguishable between 692 the standalone and pass-through cases, as required by the principle 693 of mode independence. 695 2.3. Transient Session Keys 697 Where explicitly supported by the lower layer, lower layers MAY cache 698 the exported EAP keying material and parameters and/or TSKs. The 699 structure of this key cache is defined by the lower layer. So as to 700 enable interoperability, new lower layer specifications MUST 701 describe EAP key caching behavior. Unless explicitly specified by 702 the lower layer, the EAP peer, server and authenticator MUST assume 703 that peers and authenticators do not cache exported EAP keying 704 parameters or TSKs. Existing EAP lower layers handle the caching of 705 EAP keying material and the generation of transient session keys in 706 different ways: 708 PPP PPP, defined in [RFC1661] does not support caching of EAP keying 709 material or parameters. PPP ciphersuites derive their TSKs 710 directly from the MSK, as described in [RFC2716]. This method is 711 NOT RECOMMENDED, since were PPP to support caching, this could 712 result in stale TSKs. As a result, once the PPP session is 713 terminated, EAP keying material and parameters MUST be discarded. 714 Since caching of EAP keying material is not permitted, within PPP 715 there is no way to handle TSK rekey without EAP re-authentication. 716 Perfect Forward Secrecy (PFS) is only possible within PPP if the 717 negotiated EAP method supports this. 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 | | 721 | | 722 | EAP method | 723 | | 724 | MSK, EMSK, Peer-ID, Channel | 725 | Server-ID, Method-ID Bindings | 726 | IV (deprecated), | 727 | Key-Lifetime | 728 | | 729 | V ^ ^ | 730 +-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+ 731 | ! ! ! | 732 | EAP ! Peer or Authenticator ! ! | 733 | ! layer ! ! | 734 | ! ! ! | 735 +-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+ 736 | ! ! ! | 737 | EAP ! layer ! ! | 738 | ! ! ! | 739 | ! Session-ID = ! ! | 740 | ! Expanded-Type || ! ! | 741 | ! Method-ID ! ! | 742 | ! ! ! | 743 +-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+ 744 | ! ! ! | 745 | Lower ! layer ! ! | 746 | ! ! ! | 747 | V V ^ | 748 | MSK, Peer-ID, Channel Result | 749 | Server-ID, Bindings | 750 | Session-ID, | 751 | Key-Lifetime, | 752 | IV (deprecated) | 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 Figure 3: Flow of EAP parameters 756 Peer Pass-through Authenticator Authentication 757 Server 759 +-+-+-+-+-+-+ +-+-+-+-+-+-+ 760 | | | | 761 |EAP method | |EAP method | 762 | V | | V | 763 +-+-+-!-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+ 764 | ! | |EAP | EAP | | | ! | 765 | ! | |Peer | Auth.| EAP Auth. | | ! | 766 |EAP ! peer| | | +-----------+ | |EAP !Auth.| 767 | ! | | | ! | ! | | ! | 768 +-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+ 769 | ! | | ! | ! | | ! | 770 |EAP !layer| | EAP !layer| EAP !layer | |EAP !layer| 771 | ! | | ! | ! | | ! | 772 +-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+ 773 | V | | V | ! | | ! | 774 |Lower layer| | Lower layer| AAA ! /IP | | AAA ! /IP | 775 | | | | ! | | ! | 776 +-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+ 777 ! ! 778 ! ! 779 +---------<-------+ 781 Figure 4: Flow of EAP Keying Material and Parameters 783 IKEv2 784 IKEv2, defined in [IKEv2] only uses EAP keying material for 785 authentication purposes and not key derivation. As a result, the 786 keying material derived within IKEv2 is independent of the EAP 787 keying material and rekey of IPsec SAs can be handled without 788 requiring EAP re-authentiation. Since generation of keying 789 material is independent of EAP, within IKEv2 it is possible to 790 negotiate PFS, regardless of the EAP method that is used. IKEv2 791 does not cache EAP keying material or parameters, nor does it 792 utilize the EAP Key-Lifetime parameter to determine the lifetime of 793 IPsec SAs. As a result, once IKEv2 authentication completes it is 794 assumed that EAP keying material and parameters are discarded. 796 IEEE 802.11i 797 IEEE 802.11i enables caching of the MSK, but not the EMSK, IV, 798 Peer-ID, Server-ID, or Session-ID. More details about the 799 structure of the cache are available in [IEEE-802.11i]. In IEEE 800 802.11i, TSKs are derived from the MSK using the 4-way handshake, 801 which includes a nonce exchange. This guarantees TSK freshness 802 even if the MSK is reused. The 4-way handshake also enables TSK 803 rekey without EAP re-authentication. PFS is only possible within 804 IEEE 802.11i if the negotiated EAP method supports this. 806 IEEE 802.1X-2004 807 IEEE 802.1X-2004, defined in [IEEE-802.1X-2004] does not support 808 caching of EAP keying material or parameters. Once EAP 809 authentication completes, it is assumed that EAP keying material 810 and parameters are discarded. 812 IEEE 802.16e 813 IEEE 802.16e, defined in [IEEE-802.16e] supports caching of the 814 MSK, but not the EMSK, IV, Peer-ID, Server-ID or Session-ID. In 815 IEEE 802.16e, TSKs are generated by the authenticator without any 816 contribution by the peer. The TSKs are encrypted, authenticated 817 and integrity protected using the MSK. As a result, TSK rekey is 818 possible without EAP re-authentication. PFS is not possible even 819 if the negotiated EAP method supports it. 821 AAA Existing AAA implementations supporting RADIUS/EAP [RFC3579] or 822 Diameter EAP [RFC4072] do not support caching of EAP keying 823 material or parameters. In existing AAA client, proxy and server 824 implementations, exported EAP keying material (MSK, EMSK and IV) as 825 well as parameters and derived keys are not cached and MUST be 826 presumed lost after the AAA exchange completes. 828 In order to avoid key reuse, the AAA layer MUST delete transported 829 keys once they are sent. The AAA layer MUST NOT retain keys that 830 it has previously sent. For example, a AAA layer that has 831 transported the MSK MUST delete it, and keys MUST NOT be derived 832 from the MSK from that point forward. 834 2.4. Key Scope 836 It should be understood that an EAP authenticator or peer: 838 [a] may contain one or more physical or logical ports; 839 [b] may advertise itself as one or more "virtual" 840 authenticators or peers; 841 [c] may utilize multiple CPUs; 842 [d] may support clustering services for load balancing or failover. 844 The issues that arise from this are discussed below. 846 2.4.1. Multiple Ports 848 Both the EAP peer and authenticator may have more than one physical 849 or logical port. A peer may simultaneously access the network via 850 multiple authenticators, or via multiple physical or logical ports on 851 a given authenticator. Similarly, an authenticator may offer network 852 access to multiple peers, each via a separate physical or logical 853 port. The situation is illustrated in Figure 5. 855 +-+-+-+-+ 856 | EAP | 857 | Peer | 858 +-+-+-+-+ 859 | | | Peer Ports 860 / | \ 861 / | \ 862 / | \ 863 / | \ 864 / | \ 865 / | \ 866 / | \ 867 / | \ 868 | | | | | | | | | Authenticator Ports 869 +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ 870 | | | | | | 871 | Auth. | | Auth. | | Auth. | 872 | | | | | | 873 +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ 874 \ | / 875 \ | / 876 \ | / 877 EAP over AAA \ | / 878 (optional) \ | / 879 \ | / 880 \ | / 881 \ | / 882 +-+-+-+-+ 883 | EAP | 884 |Server | 885 +-+-+-+-+ 887 Figure 5: Relationship between EAP peer, authenticator and server 889 Absent explicit specification within the lower layer, EAP keying 890 material and parameters are not bound to a specific peer or 891 authenticator port. Where the peer and authenticator identify 892 themselves within the lower layer using a port identifier such as a 893 link layer address, this creates a problem, because it may not be 894 obvious to the peer which authenticator ports are associated with 895 which authenticators. Similarly, it may not be obvious to the 896 authenticator which peer ports are associated with which peers. As a 897 result, the peer and authenticator may not be able to determine the 898 scope of the EAP keying material. This is particularly problematic 899 for lower layers where key caching is supported. 901 For example, where the EAP peer cannot identify the EAP 902 authenticator, it will be unable to determine whether EAP keying 903 material has been shared outside of its authorized scope, and 904 therefore needs to be considered compromised. There is also a 905 practical problem because the EAP peer will be unable to utilize the 906 EAP authenticator key cache in an efficient way. 908 The solution to this problem is for lower layers to identify EAP 909 peers and authenticators unambiguously, without incorporating 910 implicit assumptions about peer and authenticator architectures. Use 911 of port identifiers is NOT RECOMMENDED where peers and authenticators 912 may support multiple ports. 914 In order to further limit the key scope the following measures are 915 suggested: 917 [a] The lower layer MAY specify additional restrictions on key usage, 918 such as limiting the use of EAP keying material and parameters on 919 the EAP peer to the port over which on the EAP conversation was 920 conducted. 922 [b] The backend authentication server and authenticator MAY implement 923 additional attributes in order to further restrict the scope of EAP 924 keying material. For example, in 802.11, the backend 925 authentication server may provide the authenticator with a list of 926 authorized Called or Calling-Station-Ids and/or SSIDs for which EAP 927 keying material is valid. 929 [c] Where the backend authentication server provides attributes 930 restricting the key scope, it is RECOMMENDED that restrictions be 931 securely communicated by the authenticator to the peer. This can 932 be accomplished using the Secure Association Protocol, but also 933 can be accomplished via the EAP method or the lower layer. 935 2.4.2. Authenticator Architecture 937 The EAP method conversation is between the EAP peer and server, as 938 identified by the Peer-ID and Server-ID. The authenticator identity, 939 if considered at all by the EAP method, is treated as an opaque blob 940 for the purposes of Channel bindings. However, the Secure 941 Association Protocol conversation is between the peer and the 942 authenticator, and therefore the authenticator and peer identities 943 are relevant to that exchange, and define the scope of use of the EAP 944 keying material passed down to the lower layer. 946 Since an authenticator may have many ports, the authenticator 947 identifier used within the Secure Association Protocol exchange 948 SHOULD be distinct from any port identifier (e.g. MAC address). 950 Similarly, where a peer may have multiple ports, and sharing of EAP 951 keying material and parameters between peer ports of the same link 952 type is allowed, the peer identifier used within the Secure 953 Association Protocol exchange SHOULD also be distinct from any port 954 identifier. 956 While EAP Keying Material passed down to the lower layer is not 957 intrinsically bound to particular authenticator and peer ports, 958 Transient Session Keys MAY be bound to particular authenticator and 959 peer ports by the Secure Association Protocol. However, a lower 960 layer MAY also permit TSKs to be used on multiple peer and/or 961 authenticator ports, providing that TSK freshness is guaranteed (such 962 as by keeping replay counter state within the authenticator). 964 This specification does not impose constraints on the architecture of 965 the EAP authenticator or peer. Any of the authenticator 966 architectures described in [RFC4118] can be used. For example, it is 967 possible for multiple base stations and a "controller" (e.g. WLAN 968 switch) to comprise a single EAP authenticator. In such a situation, 969 the "base station identity" is irrelevant to the EAP method 970 conversation, except perhaps as an opaque blob to be used in Channel 971 Bindings. Many base stations can share the same authenticator 972 identity. 974 AAA protocols such as RADIUS [RFC3579] and Diameter [RFC4072] provide 975 a mechanism for the identification of AAA clients; since the EAP 976 authenticator and AAA client are always co-resident, this mechanism 977 is applicable to the identification of EAP authenticators. 979 RADIUS [RFC2865] requires that an Access-Request packet contain one 980 or more of the NAS-Identifier, NAS-IP-Address and NAS-IPv6-Address 981 attributes. Since a NAS may have more than one IP address, the NAS- 982 Identifier attribute is RECOMMENDED for the unambiguous 983 identification of the EAP authenticator. 985 From the point of view of the AAA server, EAP keying material and 986 parameters are transported to the EAP authenticator identified by the 987 NAS-Identifier attribute. Since an EAP authenticator MUST NOT share 988 EAP keying material or parameters with another party, if the EAP peer 989 or AAA server detects use of EAP keying material and parameters 990 outside the scope defined by the NAS-Identifier, the keying material 991 MUST be considered compromised. 993 2.4.3. Virtual Authenticators 995 When a single physical authenticator advertises itself as multiple 996 "virtual authenticators", the EAP peer and authenticator also may not 997 be able to agree on the scope of the EAP keying material, creating a 998 security vulnerability. For example, the peer may assume that the 999 "virtual authenticators" are distinct and do not share a key cache, 1000 whereas, depending on the architecture of the physical authenticator, 1001 a shared key cache may or may not be implemented. 1003 Where EAP keying material is shared between "virtual authenticators" 1004 an attacker acting as a peer could authenticate with the "Guest" 1005 "virtual authenticator" and derive EAP keying material. If the 1006 virtual authenticators share a key cache, then the peer can utilize 1007 the EAP keying material derived for the "Guest" network to obtain 1008 access to the "Corporate Intranet" virtual authenticator. 1010 Several measures are recommended to address these issues: 1012 [d] Authenticators are REQUIRED to cache associated authorizations 1013 along with EAP keying material and parameters and to apply 1014 authorizations consistently. This ensures that an attacker cannot 1015 obtain elevated privileges even where the key cache is shared 1016 between "virtual authenticators". 1018 [e] It is RECOMMENDED that physical authenticators maintain separate 1019 key caches for each "virtual authenticator". 1021 [f] It is RECOMMENDED that each "virtual authenticator" identify itself 1022 distinctly to the backend authentication server, such as by 1023 utilizing a distinct NAS-Identifier attribute. This enables the 1024 backend authentication server to utilize a separate credential to 1025 authenticate each "virtual authenticator". 1027 3. Key Management 1029 EAP as defined in [RFC3748] supports key derivation, but not key 1030 management. While EAP methods may derive keying material, EAP does 1031 not provide for the management of exported or derived keys. For 1032 example, EAP does not support negotiation of the key lifetime of 1033 exported or derived keys, nor does it support re-key. Although EAP 1034 methods may support "fast reconnect" as defined in [RFC3748] Section 1035 7.2.1, re-key of exported keys cannot occur without re- 1036 authentication. In order to provide method independence, key 1037 management of exported or derived keys SHOULD NOT be provided within 1038 EAP methods. 1040 3.1. Secure Association Protocol 1042 Since neither EAP nor EAP methods provide key management support, it 1043 is RECOMMENDED that key management facilities be provided within the 1044 Secure Association Protocol. This includes: 1046 [a] Entity Naming. A basic feature of a Secure Association Protocol is 1047 the explicit naming of the parties engaged in the exchange. 1048 Without explicit identification, the parties engaged in the 1049 exchange are not identified and the scope of the EAP keying 1050 parameters negotiated during the EAP exchange is undefined. As 1051 shown in Figure 5, both the peer and authenticator may have more 1052 than one physical or virtual port, and as a result SHOULD identify 1053 themselves in a manner that is independent of their attached ports. 1055 [b] Mutual proof of possession of EAP keying material. During the 1056 Secure Association Protocol the EAP peer and authenticator MUST 1057 demonstrate possession of the keying material transported between 1058 the backend authentication server and authenticator (e.g. MSK), in 1059 order to demonstrate that the peer and authenticator have been 1060 authorized. Since mutual proof of possession is not the same as 1061 mutual authentication, the peer cannot verify authenticator 1062 assertions (including the authenticator identity) as a result of 1063 this exchange. 1065 [c] Secure capabilities negotiation. In order to protect against 1066 spoofing during the discovery phase, ensure selection of the "best" 1067 ciphersuite, and protect against forging of negotiated security 1068 parameters, the Secure Association Protocol MUST support secure 1069 capabilities negotiation. This includes the secure negotiation of 1070 usage modes, session parameters (such as security association 1071 identifiers (SAIDs) and key lifetimes), ciphersuites and required 1072 filters, including confirmation of security-relevant capabilities 1073 discovered during phase 0. As part of secure capabilities 1074 negotiation, the Secure Association Protocol MUST support integrity 1075 and replay protection of all messages. 1077 [d] Key naming and selection. Where key caching is supported, it may 1078 be possible for the EAP peer and authenticator to share more than 1079 one key of a given type. As a result, the Secure Association 1080 Protocol MUST explicitly name the keys used in the proof of 1081 possession exchange, so as to prevent confusion when more than one 1082 set of keying material could potentially be used as the basis for 1083 the exchange. Use of the key naming mechanism described in this 1084 document is RECOMMENDED. 1086 In order to support the correct processing of phase 2 security 1087 associations, the Secure Association (phase 2) protocol MUST 1088 support the naming of phase 2 security associations and associated 1089 transient session keys, so that the correct set of transient 1090 session keys can be identified for processing a given packet. The 1091 phase 2 Secure Association Protocol also MUST support transient 1092 session key activation and SHOULD support deletion, so that 1093 establishment and re-establishment of transient session keys can be 1094 synchronized between the parties. 1096 [e] Generation of fresh transient session keys (TSKs). Where the lower 1097 layer supports caching of exported EAP keying material, the EAP 1098 peer lower layer may initiate a new session using keying material 1099 that was derived in a previous session. Were the TSKs to be 1100 derived from a portion of the exported EAP keying material, this 1101 would result in reuse of the session keys which could expose the 1102 underlying ciphersuite to attack. 1104 In lower layers where caching of EAP keying material is supported, 1105 the Secure Association Protocol phase is REQUIRED, and MUST support 1106 the derivation of fresh unicast and multicast TSKs, even when the 1107 keying material provided by the backend authentication server is 1108 not fresh. This is typically supported via the exchange of nonces 1109 or counters, which are then mixed with the exported keying material 1110 in order to generate fresh unicast (phase 2a) and possibly 1111 multicast (phase 2b) session keys. By not using EAP keying 1112 material directly to protect data, the Secure Association Protocol 1113 protects it against compromise. 1115 [f] Key lifetime management. This includes explicit key lifetime 1116 negotiation or seamless re-key. EAP does not support negotiation 1117 of key lifetimes, nor does it support re-key without re- 1118 authentication. As a result, the Secure Association Protocol may 1119 handle re-key and determination of the key lifetime. Where key 1120 caching is supported, secure negotiation of key lifetimes is 1121 RECOMMENDED. Lower layers that support re-key, but not key 1122 caching, may not require key lifetime negotiation. To take an 1123 example from IKE, the difference between IKEv1 and IKEv2 is that in 1124 IKEv1 SA lifetimes were negotiated. In IKEv2, each end of the SA is 1125 responsible for enforcing its own lifetime policy on the SA and re- 1126 keying the SA when necessary. 1128 [g] Key resynchronization. It is possible for the peer or 1129 authenticator to reboot or reclaim resources, clearing portions or 1130 all of the key cache. Therefore, key lifetime negotiation cannot 1131 guarantee that the key cache will remain synchronized, and the peer 1132 may not be able to determine before attempting to use a key whether 1133 it exists within the authenticator cache. It is therefore 1134 RECOMMENDED for the Secure Association Protocol to provide a 1135 mechanism for key state resynchronization. Since in this situation 1136 one or more of the parties initially do not possess a key with 1137 which to protect the resynchronization exchange, securing this 1138 mechanism may be difficult. 1140 [h] Key scope synchronization. Since the Discovery phase is handled 1141 out-of-band, EAP does not provide a mechanism by which the peer can 1142 determine the authenticator identity. As a result, where the 1143 authenticator has multiple ports and key caching is supported, the 1144 EAP peer may not be able to determine the scope of validity of the 1145 exported EAP keying material. Similarly, where the EAP peer has 1146 multiple ports, the authenticator may not be able to determine 1147 whether a peer has authorization to use a particular key. To allow 1148 key scope determination, the Secure Association Protocol SHOULD 1149 provide a mechanism by which the peer can determine the scope of 1150 the key cache on each authenticator, and by which the authenticator 1151 can determine the scope of the key cache on a peer. This includes 1152 negotiation of restrictions on key usage. 1154 [i] Direct operation. Since the phase 2 Secure Association Protocol is 1155 concerned with the establishment of security associations between 1156 the EAP peer and authenticator, including the derivation of 1157 transient session keys, only those parties have "a need to know" 1158 the transient session keys. The Secure Association Protocol MUST 1159 operate directly between the peer and authenticator, and MUST NOT 1160 be passed-through to the backend authentication server, or include 1161 additional parties. 1163 [j] Bi-directional operation While some ciphersuites only require a 1164 single set of transient session keys to protect traffic in both 1165 directions, other ciphersuites require a unique set of transient 1166 session keys in each direction. The phase 2 Secure Association 1167 Protocol SHOULD provide for the derivation of unicast and multicast 1168 keys in each direction, so as not to require two separate phase 2 1169 exchanges in order to create a bi-directional phase 2 security 1170 association. 1172 3.2. Parent-Child Relationships 1174 When keying material exported by EAP methods expires, all keying 1175 material derived from the exported keying material expires, including 1176 the TSKs. 1178 When an EAP re-authentication takes place, new keying material is 1179 derived and exported by the EAP method, which eventually results in 1180 replacement of calculated keys, including the TSKs. 1182 As a result, while the lifetime of calculated keys can be less than 1183 or equal that of the exported keys they are derived from, it cannot 1184 be greater. For example, TSK re-key may occur prior to EAP re- 1185 authentication. 1187 Failure to mutually prove possession of keying material during the 1188 Secure Association Protocol exchange need not be grounds for deletion 1189 of the keying material by both parties; rate-limiting Secure 1190 Association Protocol exchanges could be used to prevent a brute force 1191 attack. 1193 3.3. Local Key Lifetimes 1195 The Transient EAP Keys (TEKs) are session keys used to protect the 1196 EAP conversation. The TEKs are internal to the EAP method and are 1197 not exported. TEKs are typically created during an EAP conversation, 1198 used until the end of the conversation and then discarded. However, 1199 methods may re-key TEKs during a conversation. 1201 When using TEKs within an EAP conversation or across conversations, 1202 it is necessary to ensure that replay protection and key separation 1203 requirements are fulfilled. For instance, if a replay counter is 1204 used, TEK re-key MUST occur prior to wrapping of the counter. 1205 Similarly, TSKs MUST remain cryptographically separate from TEKs 1206 despite TEK re-keying or caching. This prevents TEK compromise from 1207 leading directly to compromise of the TSKs and vice versa. 1209 EAP methods may cache local keying material which may persist for 1210 multiple EAP conversations when fast reconnect is used [RFC 3748]. 1211 For example, EAP methods based on TLS (such as EAP-TLS [RFC2716]) 1212 derive and cache the TLS Master Secret, typically for substantial 1213 time periods. The lifetime of other local keying material calculated 1214 within the EAP method is defined by the method. Note that in 1215 general, when using fast reconnect, there is no guarantee to that the 1216 original long-term credentials are still in the possession of the 1217 peer. For instance, a card hold holding the private key for EAP-TLS 1218 may have been removed. EAP servers SHOULD also verify that the long- 1219 term credentials are still valid, such as by checking that 1220 certificate used in the original authentication has not yet expired. 1222 3.4. Exported and Calculated Key Lifetimes 1224 All EAP methods generating keys are required to generate the MSK and 1225 EMSK, and may optionally generate the IV. However, EAP, defined in 1226 [RFC3748], does not support the negotiation of lifetimes for exported 1227 keying material such as the MSK, EMSK and IV. 1229 Several mechanisms exist for managing key lifetimes: 1231 [a] AAA attributes. AAA protocols such as RADIUS [RFC2865] and 1232 Diameter [RFC4072] support the Session-Timeout attribute. The 1233 Session-Timeout value represents the maximum lifetime of the 1234 exported keys, and all keys calculated from it, on the 1235 authenticator. Since existing backend authentication servers do 1236 not cache keys exported by EAP methods, or keys calculated from 1237 exported keys, the value of the Session-Timeout attribute has no 1238 bearing on the key lifetime within the backend authentication 1239 server. 1241 On the authenticator, where EAP is used for authentication, the 1242 Session-Timeout value represents the maximum session time prior to 1243 re-authentication, as described in [RFC3580]. Where EAP is used 1244 for pre-authentication, the session may not start until some future 1245 time, or may never occur. Nevertheless, the Session-Timeout value 1246 represents the time after which transported EAP keying material, 1247 and all keys calculated from it, will have expired on the 1248 authenticator. If the session subsequently starts, re- 1249 authentication will be initiated once the Session-Time has expired. 1250 If the session never started, or started and ended, by default keys 1251 transported by AAA and all keys calculated from them will be 1252 expired by the authenticator prior to the future time indicated by 1253 Session-Timeout. 1255 Since the TSK lifetime is often determined by authenticator 1256 resources, the backend authentication server has no insight into 1257 the TSK derivation process, and by the principle of ciphersuite 1258 independence, it is not appropriate for the backend authentication 1259 server to manage any aspect of the TSK derivation process, 1260 including the TSK lifetime. 1262 [b] Lower layer mechanisms. While AAA attributes can communicate the 1263 maximum exported key lifetime, this only serves to synchronize the 1264 key lifetime between the backend authentication server and the 1265 authenticator. Lower layer mechanisms such as the Secure 1266 Association Protocol can then be used to enable the lifetime of 1267 exported and calculated keys to be negotiated between the peer and 1268 authenticator. 1270 Where TSKs are established as the result of a Secure Association 1271 Protocol exchange, it is RECOMMENDED that the Secure Association 1272 Protocol include support for TSK resynchronization. Where the TSK 1273 is taken from the MSK, there is no need to manage the TSK lifetime 1274 as a separate parameter, since the TSK lifetime and MSK lifetime 1275 are identical. 1277 [c] System defaults. Where the EAP method does not support the 1278 negotiation of the exported key lifetime, and a key lifetime 1279 negotiation mechanism is not provided by the lower lower, there may 1280 be no way for the peer to learn the exported key lifetime. In this 1281 case it is RECOMMENDED that the peer assume a default value of the 1282 exported key lifetime; 8 hours is recommended. Similarly, the 1283 lifetime of calculated keys can also be managed as a system 1284 parameter on the authenticator. 1286 [d] Method specific negotiation within EAP. While EAP itself does not 1287 support lifetime negotiation, it would be possible to specify 1288 methods that do. However, systems that rely on such negotiation 1289 for exported keys would only function with these methods. As a 1290 result, it is NOT RECOMMENDED to use this approach as the sole way 1291 to determine key lifetimes. 1293 3.5. Key cache synchronization 1295 Issues arise when attempting to synchronize the key cache on the peer 1296 and authenticator. Lifetime negotiation alone cannot guarantee key 1297 cache synchronization. 1299 One problem is that the AAA protocol cannot guarantee synchronization 1300 of key lifetimes between the peer and authenticator. Where the 1301 Secure Association Protocol is not run immediately after EAP 1302 authentication, the exported and calculated key lifetimes will not be 1303 known by the peer during the hiatus. Where EAP pre-authentication 1304 occurs, this can leave the peer uncertain whether a subsequent 1305 attempt to use the exported keys will prove successful. 1307 However, even where the Secure Association Protocol is run 1308 immediately after EAP, it is still possible for the authenticator to 1309 reclaim resources if the created key state is not immediately 1310 utilized. 1312 The lower layer may utilize Discovery mechanisms to assist in this. 1313 For example, the authenticator manages the key cache by deleting the 1314 oldest key first (LIFO), the relative creation time of the last key 1315 to be deleted could be advertised with the Discovery phase, enabling 1316 the peer to determine whether a given key had been expired from the 1317 authenticator key cache prematurely. 1319 3.6. Key Strength 1321 In order to guard against brute force attacks, EAP methods deriving 1322 keys need to be capable of generating keys with an appropriate 1323 effective symmetric key strength. In order to ensure that key 1324 generation is not the weakest link, it is RECOMMENDED that EAP 1325 methods utilizing public key cryptography choose a public key that 1326 has a cryptographic strength meeting the symmetric key strength 1327 requirement. 1329 As noted in [RFC3766] Section 5, this results in the following 1330 required RSA or DH module and DSA subgroup size in bits, for a given 1331 level of attack resistance in bits: 1333 Attack Resistance RSA or DH Modulus DSA subgroup 1334 (bits) size (bits) size (bits) 1335 ----------------- ----------------- ------------ 1336 70 947 128 1337 80 1228 145 1338 90 1553 153 1339 100 1926 184 1340 150 4575 279 1341 200 8719 373 1342 250 14596 475 1344 3.7. Key Wrap 1346 As described in [RFC3579] Section 4.3, known problems exist in the 1347 key wrap specified in [RFC2548]. Where the same RADIUS shared secret 1348 is used by a PAP authenticator and an EAP authenticator, there is a 1349 vulnerability to known plaintext attack. Since RADIUS uses the 1350 shared secret for multiple purposes, including per-packet 1351 authentication, attribute hiding, considerable information is exposed 1352 about the shared secret with each packet. This exposes the shared 1353 secret to dictionary attacks. MD5 is used both to compute the RADIUS 1354 Response Authenticator and the Message-Authenticator attribute, and 1355 some concerns exist relating to the security of this hash 1356 [MD5Attack]. 1358 As discussed in [RFC3579] Section 4.3, the security vulnerabilities 1359 of RADIUS are extensive, and therefore development of an alternative 1360 key wrap technique based on the RADIUS shared secret would not 1361 substantially improve security. As a result, [RFC3759] Section 4.2 1362 recommends running RADIUS over IPsec. The same approach is taken in 1363 Diameter EAP [RFC4072], which defines cleartext key attributes, to be 1364 protected by IPsec or TLS. 1366 Where an untrusted AAA intermediary is present (such as a RADIUS 1367 proxy or a Diameter agent), and data object security is not used, 1368 transported keying material may be recovered by an attacker in 1369 control of the untrusted intermediary. Possession of transported 1370 keying material enables decryption of data traffic sent between the 1371 peer and a specific authenticator. However, as long as EAP keying 1372 material or keys derived from it is only utilized by a single 1373 authenticator, compromise of the transported keying material does not 1374 enable an attacker to impersonate the peer to another authenticator. 1375 Vulnerability to an untrusted AAA intermediary can be mitigated by 1376 implementation of redirect functionality, as described in [RFC3588] 1377 and [RFC4072]. 1379 4. Handoff Vulnerabilities 1381 With EAP, a number of mechanisms are be utilized in order to reduce 1382 the latency of handoff between authenticators. One such mechanism is 1383 EAP pre-authentication, in which EAP is utilized to pre-establish EAP 1384 keying material on an authenticator prior to arrival of the peer. 1385 Another such mechanism is key caching, in which an EAP peer can re- 1386 attach to an authenticator without having to re-authenticate using 1387 EAP. Yet another mechanism is context transfer, such as is defined 1388 in [IEEE-802.11F] (now deprecated) and [CTP]. These mechanisms 1389 introduce new security vulnerabilities, as discussed in the sections 1390 that follow. 1392 4.1. Authorization 1394 In a typical network access scenario (dial-in, wireless LAN, etc.) 1395 access control mechanisms are typically applied. These mechanisms 1396 include user authentication as well as authorization for the offered 1397 service. 1399 As a part of the authentication process, the backend authentication 1400 server determines the user's authorization profile. The user 1401 authorizations are transmitted by the backend authentication server 1402 to the EAP authenticator (also known as the Network Access Server or 1403 authenticator) and with the transported EAP keying material, in Phase 1404 1b of the EAP conversation. Typically, the profile is determined 1405 based on the user identity, but a certificate presented by the user 1406 may also provide authorization information. 1408 The backend authentication server is responsible for making a user 1409 authorization decision, answering the following questions: 1411 [a] Is this a legitimate user for this particular network? 1413 [b] Is this user allowed the type of access he or she is requesting? 1415 [c] Are there any specific parameters (mandatory tunneling, bandwidth, 1416 filters, and so on) that the access network should be aware of for 1417 this user? 1419 [d] Is this user within the subscription rules regarding time of day? 1421 [e] Is this user within his limits for concurrent sessions? 1423 [f] Are there any fraud, credit limit, or other concerns that indicate 1424 that access should be denied? 1426 While the authorization decision is in principle simple, the process 1427 is complicated by the distributed nature of the decision making. 1428 Where brokering entities or proxies are involved, all of the AAA 1429 entities in the chain from the authenticator to the home backend 1430 authentication server are involved in the decision. For instance, a 1431 broker can disallow access even if the home backend authentication 1432 server would allow it, or a proxy can add authorizations (e.g., 1433 bandwidth limits). 1435 Decisions can be based on static policy definitions and profiles as 1436 well as dynamic state (e.g. time of day or limits on the number of 1437 concurrent sessions). In addition to the Accept/Reject decision made 1438 by the AAA chain, parameters or constraints can be communicated to 1439 the authenticator. 1441 The criteria for Accept/Reject decisions or the reasons for choosing 1442 particular authorizations are typically not communicated to the 1443 authenticator, only the final result. As a result, the authenticator 1444 has no way to know what the decision was based on. Was a set of 1445 authorization parameters sent because this service is always provided 1446 to the user, or was the decision based on the time/day and the 1447 capabilities of the requesting authenticator device? 1449 4.2. Correctness 1451 When the AAA exchange is bypassed via use of techniques such as key 1452 caching, this creates challenges in ensuring that authorization is 1453 properly handled. These include: 1455 [a] Consistent application of session time limits. Bypassing AAA 1456 should not automatically increase the available session time, 1457 allowing a user to endlessly extend their network access by 1458 changing the point of attachment. 1460 [b] Avoidance of privilege elevation. Bypassing AAA should not result 1461 in a user being granted access to services which they are not 1462 entitled to. 1464 [c] Consideration of dynamic state. In situations in which dynamic 1465 state is involved in the access decision (day/time, simultaneous 1466 session limit) it should be possible to take this state into 1467 account either before or after access is granted. Note that 1468 consideration of network-wide state such as simultaneous session 1469 limits can typically only be taken into account by the backend 1470 authentication server. 1472 [d] Encoding of restrictions. Since a authenticator may not be aware 1473 of the criteria considered by a backend authentication server when 1474 allowing access, in order to ensure consistent authorization during 1475 a fast handoff it may be necessary to explicitly encode the 1476 restrictions within the authorizations provided by the backend 1477 authentication server. 1479 [e] State validity. The introduction of fast handoff should not render 1480 the authentication server incapable of keeping track of network- 1481 wide state. 1483 A handoff mechanism capable of addressing these concerns is said to 1484 be "correct". One condition for correctness is as follows: For a 1485 handoff to be "correct" it MUST establish on the new device the same 1486 context as would have been created had the new device completed a AAA 1487 conversation with the backend authentication server. 1489 A properly designed handoff scheme will only succeed if it is 1490 "correct" in this way. If a successful handoff would establish 1491 "incorrect" state, it is preferable for it to fail, in order to avoid 1492 creation of incorrect context. 1494 Some backend authentication server and authenticator configurations 1495 are incapable of meeting this definition of "correctness". For 1496 example, if the old and new device differ in their capabilities, it 1497 may be difficult to meet this definition of correctness in a handoff 1498 mechanism that bypasses AAA. Backend authentication servers often 1499 perform conditional evaluation, in which the authorizations returned 1500 in an Access-Accept message are contingent on the authenticator or on 1501 dynamic state such as the time of day or number of simultaneous 1502 sessions. For example, in a heterogeneous deployment, the backend 1503 authentication server might return different authorizations depending 1504 on the authenticator making the request, in order to make sure that 1505 the requested service is consistent with the authenticator 1506 capabilities. 1508 If differences between the new and old device would result in the 1509 backend authentication server sending a different set of messages to 1510 the new device than were sent to the old device, then if the handoff 1511 mechanism bypasses AAA, then the handoff cannot be carried out 1512 correctly. 1514 For example, if some authenticator devices within a deployment 1515 support dynamic VLANs while others do not, then attributes present in 1516 the Access-Request (such as the authenticator-IP-Address, 1517 authenticator-Identifier, Vendor-Identifier, etc.) could be examined 1518 to determine when VLAN attributes will be returned, as described in 1519 [RFC3580]. VLAN support is defined in [IEEE-802.1Q]. If a handoff 1520 bypassing the backend authentication server were to occur between a 1521 authenticator supporting dynamic VLANs and another authenticator 1522 which does not, then a guest user with access restricted to a guest 1523 VLAN could be given unrestricted access to the network. 1525 Similarly, in a network where access is restricted based on the day 1526 and time, Service Set Identifier (SSID), Calling-Station-Id or other 1527 factors, unless the restrictions are encoded within the 1528 authorizations, or a partial AAA conversation is included, then a 1529 handoff could result in the user bypassing the restrictions. 1531 In practice, these considerations limit the situations in which fast 1532 handoff mechanisms bypassing AAA can be expected to be successful. 1533 Where the deployed devices implement the same set of services, it may 1534 be possible to do successful handoffs within such mechanisms. 1535 However, where the supported services differ between devices, the 1536 handoff may not succeed. For example, [RFC2865] section 1.1 states: 1538 "A authenticator that does not implement a given service MUST NOT 1539 implement the RADIUS attributes for that service. For example, a 1540 authenticator that is unable to offer ARAP service MUST NOT 1541 implement the RADIUS attributes for ARAP. A authenticator MUST 1542 treat a RADIUS access-accept authorizing an unavailable service as 1543 an access-reject instead." 1545 Note that this behavior only applies to attributes that are known, 1546 but not implemented. For attributes that are unknown, [RFC2865] 1547 Section 5 states: 1549 "A RADIUS server MAY ignore Attributes with an unknown Type. A 1550 RADIUS client MAY ignore Attributes with an unknown Type." 1552 In order to perform a correct handoff, if a new device is provided 1553 with RADIUS context for a known but unavailable service, then it MUST 1554 process this context the same way it would handle a RADIUS Access- 1555 Accept requesting an unavailable service. This MUST cause the 1556 handoff to fail. However, if a new device is provided with RADIUS 1557 context that indicates an unknown attribute, then this attribute MAY 1558 be ignored. 1560 Although it may seem somewhat counter-intuitive, failure is indeed 1561 the "correct" result where a known but unsupported service is 1562 requested. Presumably a correctly configured backend authentication 1563 server would not request that a device carry out a service that it 1564 does not implement. This implies that if the new device were to 1565 complete a AAA conversation that it would be likely to receive 1566 different service instructions. In such a case, failure of the 1567 handoff is the desired result. This will cause the new device to go 1568 back to the AAA server in order to receive the appropriate service 1569 definition. 1571 In practice, this implies that handoff mechanisms which bypass AAA 1572 are most likely to be successful within a homogeneous device 1573 deployment within a single administrative domain. For example, it 1574 would not be advisable to carry out a fast handoff bypassing AAA 1575 between a authenticator providing confidentiality and another 1576 authenticator that does not support this service. The correct result 1577 of such a handoff would be a failure, since if the handoff were 1578 blindly carried out, then the user would be moved from a secure to an 1579 insecure channel without permission from the backend authentication 1580 server. Thus the definition of a "known but unsupported service" 1581 MUST encompass requests for unavailable security services. This 1582 includes vendor-specific attributes related to security, such as 1583 those described in [RFC2548]. 1585 5. Security Considerations 1587 In order to analyze whether the EAP conversation achieves its 1588 security goals, it is first necessary to state those goals as well as 1589 the underlying security assumptions. 1591 The overall goal of the EAP conversation is to derive fresh session 1592 keys between the EAP peer and authenticator that are known only to 1593 those parties, and for both the EAP peer and authenticator to 1594 demonstrate that they are authorized to perform their roles either by 1595 each other or by a trusted third party (the backend authentication 1596 server). 1598 The principals of the authentication phase are the EAP peer and 1599 server. Completion of an EAP method exchange supporting key 1600 derivation results in the derivation of EAP keying material (MSK, 1601 EMSK, TEKs) known only to the EAP peer (identified by the Peer-ID) 1602 and server (identified by the Server-ID). Both the EAP peer and EAP 1603 server know the exported keying material to be fresh. 1605 The principals of the AAA Key transport exchange are the EAP 1606 authenticator and the EAP server. Completion of the AAA exchange 1607 results in the transport of EAP keying material from the EAP server 1608 (identified by the Server-ID) to the EAP authenticator (identified by 1609 the NAS-Identifier) without disclosure to any other party. Both the 1610 EAP server and EAP authenticator know this keying material to be 1611 fresh. 1613 The principals of the Secure Association Protocol are the EAP peer 1614 (identified by the Peer-ID) and authenticator (identified by the NAS- 1615 Identifier). Completion of the Secure Association Protocol results 1616 in the derivation of TSKs known only to the EAP peer and 1617 authenticator. Both the EAP peer and authenticator know the TSKs to 1618 be fresh. 1620 5.1. Terminology 1622 "Cryptographic binding", "Cryptographic separation", "Key strength" 1623 and "Mutual authentication" are defined in [RFC3748] and are used 1624 with the same meaning here. 1626 5.2. Threat Model 1628 The EAP threat model is described in [RFC3748] Section 7.1. The 1629 security properties of EAP methods (known as "security claims", 1630 described in [RFC3784] Section 7.2.1), address these threats. EAP 1631 method requirements for applications such as Wireless LAN 1632 authentication are described in [RFC4017]. The RADIUS threat model 1633 is described in [RFC3579] Section 4.1, and responses to these threats 1634 are described in [RFC3579] Sections 4.2 and 4.3. 1636 However, in addition to threats against EAP and AAA, there are other 1637 system-level threats worth discussing. These include: 1639 [1] An attacker may compromise or steal an EAP authenticator, in an 1640 attempt to gain access to other EAP authenticators or obtain long- 1641 term secrets. 1643 [2] An attacker may compromise an EAP authenticator in an effort to 1644 commit fraud. For example, a compromised authenticator may provide 1645 incorrect information to the EAP peer and/or server via out-of-band 1646 mechanisms (such as via a AAA or lower layer protocol). This 1647 includes impersonating another authenticator, or providing 1648 inconsistent information to the peer and EAP server. 1650 [3] An attacker may try to modify or spoof packets, including Discovery 1651 or Secure Association Protocol frames, EAP or AAA packets. 1653 [4] An attacker may attempt a downgrade attack in order to exploit 1654 known weaknesses in an authentication method or cryptographic 1655 transform. 1657 [5] An attacker may attempt to induce an EAP peer, authenticator or 1658 server to disclose keying material to an unauthorized party, or 1659 utilize keying material outside the context that it was intended 1660 for. 1662 [6] An attacker may replay packets. 1664 [7] An attacker may cause an EAP peer, authenticator or server to reuse 1665 an stale key. Use of stale keys may also occur unintentionally. 1666 For example, a poorly implemented backend authentication server may 1667 provide stale keying material to an authenticator, or a poorly 1668 implemented authenticator may reuse nonces. 1670 [8] An authenticated attacker may attempt to obtain elevated privilege 1671 in order to access information that it does not have rights to. 1673 In order to address these threats, [Housley] provides a description 1674 of mandatory system security properties. Issues relating system 1675 security requirements are discussed in the sections that follow. 1677 5.3. Authenticator Compromise 1679 In the event that an authenticator is compromised or stolen, an 1680 attacker may gain access to the network via that authenticator, or 1681 may obtain the credentials required for that authenticator/AAA client 1682 to communicate with one or more backend authentication servers. 1683 However, this should not allow the attacker to compromise other 1684 authenticators or the backend authentication server, or obtain long- 1685 term user credentials. 1687 The implications of this requirement are many, but some of the more 1688 important are as follows: 1690 No Key Sharing 1691 An EAP authenticator MUST NOT share any keying material with 1692 another EAP authenticator, since if one EAP authenticator were 1693 compromised, this would enable the compromise of keying material on 1694 another authenticator. In order to be able to determine whether 1695 keying material has been shared, it is necessary for the identity 1696 of the EAP authenticator to be defined and understood by all 1697 parties that communicate with it. 1699 No AAA Credential Sharing 1700 AAA credentials (such as RADIUS shared secrets, IPsec pre-shared 1701 keys or certificates) MUST NOT be shared between AAA clients, since 1702 if one AAA client were compromised, this would enable an attacker 1703 to impersonate other AAA clients to the backend authentication 1704 server, or even to impersonate a backend authentication server to 1705 other AAA clients. 1707 No Compromise of Long-Term Credentials 1708 An attacker obtaining TSKs, TEKs or EAP keying material such as the 1709 MSK MUST NOT be able to obtain long-term user credentials such as 1710 pre-shared keys, passwords or private-keys without breaking a 1711 fundamental cryptographic assumption. 1713 5.4. Spoofing 1715 The use of per-packet authentication and integrity protection 1716 provides protection against spoofing attacks. Diameter [RFC3588] 1717 provides support for per-packet authentication and integrity 1718 protection via use of IPsec or TLS. RADIUS/EAP [RFC3579] provides 1719 for per-packet authentication and integrity protection via use of the 1720 Message-Authenticator attribute. 1722 [RFC3748] Section 7.2.1 describes the "integrity protection" security 1723 claim and [RFC4017] requires use of EAP methods supporting this 1724 claim. 1726 In order to prevent forgery of Secure Association Protocol frames, 1727 per-frame authentication and integrity protection is RECOMMENDED on 1728 all messages. [IEEE-802.11i] supports per-frame integrity protection 1729 and authentication on all messages within the 4-way handshake except 1730 the first message. An attack leveraging this ommission is described 1731 in [Analysis]. 1733 5.5. Downgrade Attacks 1735 The ability to negotiate the use of a particular cryptographic 1736 algorithm provides resilience against compromise of a particular 1737 cryptographic algorithm. This is usually accomplished by including 1738 an algorithm identifier in the protocol, and by specifying the 1739 algorithm requirements in the protocol specification. In order to 1740 prevent downgrade attacks, secure confirmation of the "best" 1741 ciphersuite is required. 1743 [RFC3748] Section 7.2.1 describes the "protected ciphersuite 1744 negotiation" security claim that refers to the ability of an EAP 1745 method to negotiate the ciphersuite used to protect the EAP 1746 conversation, as well as to integrity protect the negotiation. 1747 [RFC4017] requires EAP methods satisfying this security claim. 1749 Diameter [RFC3588] provides support for cryptographic algorithm 1750 negotiation via use of IPsec or TLS. RADIUS [RFC3579] does not 1751 support the negotiation of cryptographic algorithms, and relies on 1752 MD5 for integrity protection, authentication and confidentiality, 1753 despite known weaknesses in the algorithm [MD5Attack]. This issue 1754 can be addressed via use of RADIUS over IPsec, as described in 1755 [RFC3579] Section 4.2. 1757 As a result, EAP methods and AAA protocols are capable of addressing 1758 downgrade attacks. To ensure against downgrade attacks within lower 1759 layer protocols, algorithm independence is REQUIRED with lower layers 1760 using EAP for key derivation. For interoperability, at least one 1761 suite of mandatory-to-implement algorithm MUST be selected. Lower 1762 layer protocols supporting EAP for key derivation SHOULD also support 1763 secure ciphersuite negotiation. As described in [RFC1968], PPP ECP 1764 does not provide support for secure ciphersuite negotiation. 1765 However, [IEEE-802.11i] does support secure ciphersuite negotiation. 1767 5.6. Unauthorized Disclosure 1769 While preserving algorithm independence, confidentiality of all 1770 keying material MUST be maintained. To prevent unauthorized disclose 1771 of keys, each party in the EAP conversation MUST be authenticated to 1772 the other parties with whom it communicates. Keying material MUST be 1773 bound to the appropriate context. 1775 [RFC3748] Section 7.2.1 describes the "mutual authentication" and 1776 "dictionary attack resistance" claims, and [RFC4017] requires EAP 1777 methods satisfying these claims. EAP methods complying with 1778 [RFC4017] therefore provide for mutual authentication between the EAP 1779 peer and server. Binding of EAP keying material (MSK, EMSK) to the 1780 appropriate context is provided by the Peer-ID and Server-ID which 1781 are exported along with the keying material. 1783 Diameter [RFC3588] provides for per-packet authentication and 1784 integrity protection via IPsec or TLS, and RADIUS/EAP [RFC3579] also 1785 provides for per-packet authentication and integrity protection. 1786 Where the NAS/authenticator and backend authentication server 1787 communicate directly and credible keywrap is used (see Section 3.7), 1788 this ensures that the AAA Key Transport phase achieves its security 1789 objectives: mutually authenticating the AAA client/authenticator and 1790 backend authentication server and providing EAP keying material to 1791 the EAP authenticator and to no other party. 1793 As noted in Section 3.1, the Secure Association Protocol does not by 1794 itself provide for mutual authentication between the EAP peer and 1795 authenticator, even if mutual possession of EAP keying material is 1796 proven. However, where the NAS/authenticator and backend 1797 authentication server communicate directly, the backend 1798 authentication server can verify the correspondence between NAS 1799 identification attributes, the source address of packets sent by the 1800 NAS, and the AAA credentials. As long as the NAS has not shared its 1801 AAA credentials with another NAS, this allows the backend 1802 authentication server to authenticate the NAS. Using Channel 1803 Bindings, the EAP peer can then determine whether the 1804 NAS/authenticator has provided the same identifying information to 1805 the EAP peer and backend authentication server. 1807 Peer and authenticator authorization MUST be performed. 1808 Authorization is REQUIRED whenever a peer associates with a new 1809 authenticator. Authorization checking prevents an elevation of 1810 privilege attack, and ensures that an unauthorized authenticator is 1811 detected. Authorizations SHOULD be synchronized between the EAP 1812 peer, server, authenticator. Once the EAP conversation exchanges are 1813 complete, all of these parties should hold the same view of the 1814 authorizations associated the other parties. If peer authorization 1815 is restricted, then the peer SHOULD be made aware of the restriction. 1817 The AAA exchange provides the EAP authenticator with authorizations 1818 relating to the EAP peer. However, neither the EAP nor AAA exchanges 1819 provides authorizations to the EAP peer. In order to ensure that all 1820 parties hold the same view of the authorizations it is RECOMMENDED 1821 that the Secure Association Protocol enable communication of 1822 authorizations between the EAP authenticator and peer. 1824 In order to enable key binding and authorization of all parties, it 1825 is RECOMMENDED that the parties use a set of identities that are 1826 consistent between the conversation phases. RADIUS [RFC2865] and 1827 Diameter NASREQ [RFC4005] require that the NAS/EAP authenticator 1828 identify itself by including one or more identification attributes 1829 within an Access-Request packet (NAS-Identifier, NAS-IP-Address, NAS- 1830 IPv6-Address). 1832 Since the backend authentication server provides EAP keying material 1833 for use by the EAP authenticator as identified by these attributes, 1834 where an EAP authenticator may have multiple ports, it is RECOMMENDED 1835 for the EAP authenticator to identify itself using NAS identification 1836 attributes during the Secure Association Protocol exchange with the 1837 EAP peer. This enables the EAP peer to determine whether EAP keying 1838 material has been shared between EAP authenticators as well as to 1839 confirm with the backend authentication server that an EAP 1840 authenticator proving possession of EAP keying material during the 1841 Secure Association Protocol was authorized to obtain it. Typically, 1842 the NAS-Identifier attribute is most convenient for this purpose, 1843 since a NAS/authenticator may have multiple IP addresses. 1845 Similarly, the backend authentication server authorizes the EAP 1846 authenticator to provide access to the EAP peer identified by the 1847 Peer-ID, securely verified during the EAP authentication exchange. 1848 In order to determine whether EAP keying material has been shared 1849 between EAP peers, where the EAP peer has multiple ports it is 1850 RECOMMENDED for the EAP peer to identify itself using the Peer-ID 1851 during the Secure Association Protocol exchange with the EAP 1852 authenticator. 1854 5.7. Replay Protection 1856 Replay protection allows a protocol message recipient to discard any 1857 message that was recorded during a previous legitimate dialogue and 1858 presented as though it belonged to the current dialogue. 1860 [RFC3748] Section 7.2.1 describes the "replay protection" security 1861 claim and [RFC4017] requires use of EAP methods supporting this 1862 claim. 1864 Diameter [RFC3588] provides support for replay protection via use of 1865 IPsec or TLS. RADIUS/EAP [RFC3579] protects against replay of keying 1866 material via the Request Authenticator. However, some RADIUS packets 1867 are not replay protected. In Accounting, Disconnect and CoA-Request 1868 packets the Request Authenticator contains a keyed MAC rather than a 1869 Nonce. The Response Authenticator in Accounting, Disconnect and CoA 1870 Response packets also contains a keyed MAC whose calculation does not 1871 depend on a Nonce in either the Request or Response packets. 1872 Therefore unless an Event-Timestamp attribute is included or IPsec is 1873 used, the recipient may not be able to determine whether these 1874 packets have been replayed. 1876 In order to prevent replay of Secure Association Protocol frames, 1877 replay protection is REQUIRED on all messages. [IEEE-802.11i] 1878 supports replay protection on all messages within the 4-way 1879 handshake. 1881 5.8. Key Freshness 1883 A session key should be considered compromised if it remains in use 1884 too long. As noted in [Housley], session keys MUST be strong and 1885 fresh, while preserving algorithm independence. A fresh 1886 cryptographic key is one that is generated specifically for the 1887 intended use. Each session deserves an independent session key; 1888 disclosure of one session key MUST NOT aid the attacker in 1889 discovering any other session keys. 1891 Fresh keys are required even when a long replay counter (that is, one 1892 that "will never wrap") is used to ensure that loss of state does not 1893 cause the same counter value to be used more than once with the same 1894 session key. 1896 EAP, AAA and the lower layer each bear responsibility for ensuring 1897 the use of fresh, strong session keys: 1899 EAP EAP methods need to ensure the freshness and strength of EAP keying 1900 material provided as an input to session key derivation. [RFC3748] 1901 Section 7.10 states that "EAP methods SHOULD ensure the freshness 1902 of the MSK and EMSK, even in cases where one party may not have a 1903 high quality random number generator. A RECOMMENDED method is for 1904 each party to provide a nonce of at least 128 bits, used in the 1905 derivation of the MSK and EMSK." The contribution of nonces 1906 enables the EAP peer and server to ensure that exported EAP keying 1907 material is fresh. 1909 [RFC3748] Section 7.2.1 describes the "key strength" and "session 1910 independence" security claims, and and [RFC4017] requires use of 1911 EAP methods supporting these claims as well as being capable of 1912 providing an equivalent key strength of 128 bits or greater. 1914 AAA The AAA protocol needs to ensure that transported keying material 1915 is fresh and is not utilized outside its recommended lifetime. 1916 Replay protection is necessary for key freshness, but an attacker 1917 can deliver a stale (and therefore potentially compromised) key in 1918 a replay-protected message, so replay protection is not sufficient. 1920 The EAP Session-ID, derived from the EAP Type and Method-ID (based 1921 on the nonces contributed by the peer and server) enables the EAP 1922 peer, authenticator and server to distinguish EAP conversations. 1923 However, unless the authenticator keeps track of EAP Session-IDs, 1924 the authenticator cannot use the Session-ID to guarantee the 1925 freshness of EAP keying material. 1927 As described in [RFC3580] Section 3.17, When sent in an Access- 1928 Accept along with a Termination-Action value of RADIUS-Request, the 1929 Session-Timeout attribute specifies the maximum number of seconds 1930 of service provided prior to re-authentication. [IEEE-802.11i] 1931 also utilizes the Session-Timeout attribute to limit the maximum 1932 time that EAP keying material may be cache. Therefore the use of 1933 the Session-Timeout attribute enables the backend authentication 1934 server to limit the exposure of EAP keying material. 1936 Lower Layer 1937 The lower layer Secure Association Protocol MUST generate a fresh 1938 session key for each session, even if the keying material and 1939 parameters provided by EAP methods are cached, or the peer or 1940 authenticator lack a high entropy random number generator. A 1941 RECOMMENDED method is for the peer and authenticator to each 1942 provide a nonce or counter used in session key derivation. If a 1943 nonce is used, it is RECOMMENDED that it be at least 128 bits. 1945 5.9. Elevation of Privilege 1947 Parties MUST NOT have access to keying material that is not needed to 1948 perform their own role. A party has access to a particular key if it 1949 has access to all of the secret information needed to derive it. If 1950 a post-EAP handshake is used to establish session keys, the post-EAP 1951 handshake MUST specify the scope for session keys. 1953 Transported EAP keying material is permitted to be accessed by the 1954 EAP peer, authenticator and server. The EAP peer and server derive 1955 the transported keying material during the process of mutually 1956 authenticating each other using the selected EAP method. During the 1957 Secure Association Protocol, the EAP peer utilizes the transported 1958 EAP keying material to demonstrate to the authenticator that it is 1959 the same party that authenticated to the EAP server and was 1960 authorized by it. The EAP authenticator utilizes the transported EAP 1961 keying material to prove to the peer not only that the EAP 1962 conversation was transported through it (this could be demonstrated 1963 by a man-in-the-middle), but that it was uniquely authorized by the 1964 EAP server to provide the peer with access to the network. Unique 1965 authorization can only be demonstrated if the EAP authenticator does 1966 not share the transported keying material with a party other than the 1967 EAP peer and server. 1969 TSKs are permitted to be accessed only by the EAP peer and 1970 authenticator. Since the TSKs can be determined from the transported 1971 EAP keying material and the cleartext of the Secure Association 1972 Protocol exchange, the backend authentication server will have access 1973 to the TSKs unless it deletes the transported EAP keying material 1974 after sending it. 1976 5.10. Man-in-the-middle Attacks 1978 As described in [I-D.puthenkulam-eap-binding], EAP method sequences 1979 and compound authentication mechanisms may be subject to man-in-the- 1980 middle attacks. When such attacks are successfully carried out, the 1981 attacker acts as an intermediary between a victim and a legitimate 1982 authenticator. This allows the attacker to authenticate successfully 1983 to the authenticator, as well as to obtain access to the network. 1985 In order to prevent these attacks, [I-D.puthenkulam-eap-binding] 1986 recommends derivation of a compound key by which the EAP peer and 1987 server can prove that they have participated in the entire EAP 1988 exchange. Since the compound key must not be known to an attacker 1989 posing as an authenticator, and yet must be derived from quantities 1990 that are exported by EAP methods, it may be desirable to derive the 1991 compound key from a portion of the EMSK. In order to provide proper 1992 key hygiene, it is recommended that the compound key used for man-in- 1993 the-middle protection be cryptographically separate from other keys 1994 derived from the EMSK. 1996 5.11. Denial of Service Attacks 1998 Key caching may result in vulnerability to denial of service attacks. 1999 For example, EAP methods that create persistent state may be 2000 vulnerable to denial of service attacks on the EAP server by a rogue 2001 EAP peer. 2003 To address this vulnerability, EAP methods creating persistent state 2004 may wish to limit the persistent state created by an EAP peer. For 2005 example, for each peer an EAP server may choose to limit persistent 2006 state to a few EAP conversations, distinguished by the EAP Session- 2007 ID. This prevents a rogue peer from denying access to other peers. 2009 Similarly, to conserve resources an authenticator may choose to limit 2010 the persistent state corresponding to each peer. This can be 2011 accomplished by limiting each peer to persistent sttate corresponding 2012 to a few EAP converations, distinguished by the EAP Session-ID. 2014 Depending on the media, creation of new TSKs may or may not imply 2015 deletion of previously derived TSKs. Where there is no implied 2016 deletion, the authenticator may choose to limit the number of TSKs 2017 and associated state that can be stored for each peer. 2019 5.12. Impersonation 2021 Both the RADIUS and Diameter protocols are potentially vulnerable to 2022 impersonation by a rogue authenticator. 2024 While AAA protocols such as RADIUS [RFC2865] or Diameter [RFC3588] 2025 support mutual authentication between the authenticator (known as the 2026 AAA client) and the backend authentication server (known as the 2027 backend authentication server), the security mechanisms vary 2028 according to the AAA protocol. 2030 In RADIUS, the shared secret used for authentication is determined by 2031 the source address of the RADIUS packet. As noted in [RFC3579] 2032 Section 4.3.7, it is highly desirable that the source address be 2033 checked against one or more NAS identification attributes so as to 2034 detect and prevent impersonation attacks. 2036 When RADIUS requests are forwarded by a proxy, the NAS-IP-Address or 2037 NAS-IPv6-Address attributes may not correspond to the source address. 2038 Since the NAS-Identifier attribute need not contain an FQDN, it also 2039 may not correspond to the source address, even indirectly. [RFC2865] 2040 Section 3 states: 2042 A RADIUS server MUST use the source IP address of the RADIUS 2043 UDP packet to decide which shared secret to use, so that 2044 RADIUS requests can be proxied. 2046 This implies that it is possible for a rogue authenticator to forge 2047 NAS-IP-Address, NAS-IPv6-Address or NAS-Identifier attributes within 2048 a RADIUS Access-Request in order to impersonate another 2049 authenticator. Among other things, this can result in messages (and 2050 transorted keying material) being sent to the wrong authenticator. 2051 Since the rogue authenticator is authenticated by the RADIUS proxy or 2052 server purely based on the source address, other mechanisms are 2053 required to detect the forgery. In addition, it is possible for 2054 attributes such as the Called-Station-Id and Calling-Station-Id to be 2055 forged as well. 2057 As recommended in [RFC3579] Section 4.3.7, this vulnerability can be 2058 mitigated by having RADIUS proxies check NAS identification 2059 attributes against the source address. 2061 While [RFC3588] requires use of the Route-Record AVP, this utilizes 2062 FQDNs, so that impersonation detection requires DNS A/AAAA and PTR 2063 RRs to be properly configured. As a result, it appears that Diameter 2064 is as vulnerable to this attack as RADIUS, if not more so. To 2065 address this vulnerability, it is necessary to allow the backend 2066 authentication server to communicate with the authenticator directly, 2067 such as via the redirect functionality supported in [RFC3588]. 2069 5.13. Channel Binding 2071 It is possible for a compromised or poorly implemented EAP 2072 authenticator to communicate incorrect information to the EAP peer 2073 and/or server. This may enable an authenticator to impersonate 2074 another authenticator or communicate incorrect information via out- 2075 of-band mechanisms (such as via AAA or the lower layer). 2077 Where EAP is used in pass-through mode, the EAP peer does not verify 2078 the identity of the pass-through authenticator. Within the Secure 2079 Association Protocol, the EAP peer and authenticator only demonstrate 2080 mutual possession of the transported EAP keying material. This 2081 creates a potential security vulnerability, described in [RFC3748] 2082 Section 7.15. 2084 [RFC3579] Section 4.3.7 describes how an EAP pass-through 2085 authenticator acting as a AAA client can be detected if it attempts 2086 to impersonate another authenticator (such by sending incorrect 2087 Called-Station-ID [RFC2865], NAS-Identifier [RFC2865], NAS-IP-Address 2088 [RFC2865] or NAS-IPv6-Address [RFC3162] attributes via the AAA 2089 protocol). However, it is possible for a pass-through authenticator 2090 acting as a AAA client to provide correct information to the backend 2091 authentication server while communicating misleading information to 2092 the EAP peer via the lower layer. 2094 For example, a compromised authenticator can utilize another 2095 authenticator's Called-Station-Id or NAS-Identifier in communicating 2096 with the EAP peer via the lower layer, or for a pass-through 2097 authenticator acting as a AAA client to provide an incorrect peer 2098 Calling-Station-Id [RFC2865][RFC3580] to the AAA server via the AAA 2099 protocol. 2101 As noted in [RFC3748] Section 7.15, this vulnerability can be 2102 addressed by EAP methods that support a protected exchange of channel 2103 properties such as endpoint identifiers, including (but not limited 2104 to): Called-Station-Id [RFC2865][RFC3580], Calling-Station-Id 2105 [RFC2865][RFC3580], NAS-Identifier [RFC2865], NAS-IP-Address 2106 [RFC2865], and NAS-IPv6-Address [RFC3162]. 2108 Using such a protected exchange, it is possible to match the channel 2109 properties provided by the authenticator via out-of-band mechanisms 2110 against those exchanged within the EAP method. For example, see [I- 2111 D.arkko-eap-service-identity-auth]. 2113 It is also possible to achieve Channel Bindings without transporting 2114 data over EAP. For example, see [draft-ohba-eap-aaakey-binding]. In 2115 this approach the authenticator informs the backend server about the 2116 Channel Binding parameters using AAA, and the backend server 2117 calculates transported keying material based on this parameter set, 2118 making it impossible for the peer and authenticator to complete the 2119 Secure Association Protocol if there was a mismatch in the 2120 parameters. 2122 The main difference between these approaches is that Channel Binding 2123 support within an EAP method may require upgrading or changing the 2124 EAP method, impacting both the peer and the server. Where Channel 2125 Bindings are implemented in AAA, the peer, authenticator and the 2126 backend server need to be upgraded, but the EAP method need not be 2127 modified. 2129 6. IANA Considerations 2131 This document does not create any new name spaces nor does it 2132 allocate any protocol parameters. 2134 7. References 2136 7.1. Normative References 2138 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2139 Requirement Levels", BCP 14, RFC 2119, March 1997. 2141 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 2142 Considerations Section in RFCs", BCP 26, RFC 2434, October 2143 1998. 2145 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 2146 Lefkowetz, "Extensible Authentication Protocol (EAP)", RFC 2147 3748, June 2004. 2149 7.2. Informative References 2151 [Analysis] 2152 He, C. and J. Mitchell, "Analysis of the 802.11i 4-Way 2153 Handshake", Proceedings of the 2004 ACM Workshop on Wireless 2154 Security, pp. 43-50, ISBN: 1-58113-925-X. 2156 [CTP] Loughney, J., Nakhjiri, M., Perkins, C. and R. Koodli, 2157 "Context Transfer Protocol", draft-ietf-seamoby-ctp-11.txt, 2158 Internet draft (work in progress), August 2004. 2160 [DESMODES] 2161 National Institute of Standards and Technology, "DES Modes of 2162 Operation", FIPS PUB 81, December 1980, . 2165 [FIPSDES] National Institute of Standards and Technology, "Data 2166 Encryption Standard", FIPS PUB 46, January 1977. 2168 [Housley] Housley, R. and B. Aboba, "AAA Key Management", draft-housley- 2169 aaa-key-mgmt-01.txt, Internet draft (work in progress), 2170 November 2005. 2172 [IEEE-802] 2173 Institute of Electrical and Electronics Engineers, "IEEE 2174 Standards for Local and Metropolitan Area Networks: Overview 2175 and Architecture", ANSI/IEEE Standard 802, 1990. 2177 [IEEE-802.11] 2178 Institute of Electrical and Electronics Engineers, 2179 "Information technology - Telecommunications and information 2180 exchange between systems - Local and metropolitan area 2181 networks - Specific Requirements Part 11: Wireless LAN Medium 2182 Access Control (MAC) and Physical Layer (PHY) Specifications", 2183 IEEE IEEE Standard 802.11-2003, 2003. 2185 [IEEE-802.1X] 2186 Institute of Electrical and Electronics Engineers, "Local and 2187 Metropolitan Area Networks: Port-Based Network Access 2188 Control", IEEE Standard 802.1X-2004, December 2004. 2190 [IEEE-802.1Q] 2191 Institute of Electrical and Electronics Engineers, "IEEE 2192 Standards for Local and Metropolitan Area Networks: Draft 2193 Standard for Virtual Bridged Local Area Networks", IEEE 2194 Standard 802.1Q/D8, January 1998. 2196 [IEEE-802.11i] 2197 Institute of Electrical and Electronics Engineers, "Supplement 2198 to STANDARD FOR Telecommunications and Information Exchange 2199 between Systems - LAN/MAN Specific Requirements - Part 11: 2200 Wireless Medium Access Control (MAC) and physical layer (PHY) 2201 specifications: Specification for Enhanced Security", IEEE 2202 802.11i, December 2004. 2204 [IEEE-802.11F] 2205 Institute of Electrical and Electronics Engineers, 2206 "Recommended Practice for Multi-Vendor Access Point 2207 Interoperability via an Inter-Access Point Protocol Across 2208 Distribution Systems Supporting IEEE 802.11 Operation", IEEE 2209 802.11F, July 2003 (now deprecated). 2211 [IEEE-02-758] 2212 Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, 2213 "Proactive Caching Strategies for IAPP Latency Improvement 2214 during 802.11 Handoff", IEEE 802.11 Working Group, 2215 IEEE-02-758r1-F Draft 802.11I/D5.0, November 2002. 2217 [IEEE-03-084] 2218 Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, 2219 "Proactive Key Distribution to support fast and secure 2220 roaming", IEEE 802.11 Working Group, IEEE-03-084r1-I, 2221 http://www.ieee802.org/11/Documents/DocumentHolder/ 3-084.zip, 2222 January 2003. 2224 [IEEE-03-155] 2225 Aboba, B., "Fast Handoff Issues", IEEE 802.11 Working Group, 2226 IEEE-03-155r0-I, http://www.ieee802.org/11/ 2227 Documents/DocumentHolder/3-155.zip, March 2003. 2229 [I-D.ietf-roamops-cert] 2230 Aboba, B., "Certificate-Based Roaming", draft-ietf-roamops- 2231 cert-02 (work in progress), April 1999. 2233 [I-D.puthenkulam-eap-binding] 2234 Puthenkulam, J., "The Compound Authentication Binding 2235 Problem", draft-puthenkulam-eap-binding-04 (work in progress), 2236 October 2003. 2238 [I-D.arkko-pppext-eap-aka] 2239 Arkko, J. and H. Haverinen, "EAP AKA Authentication", draft- 2240 arkko-pppext-eap-aka-15.txt (work in progress), December 2004. 2242 [I-D.arkko-eap-service-identity-auth] 2243 Arkko, J. and P. Eronen, "Authenticated Service Information 2244 for the Extensible Authentication Protocol (EAP)", draft- 2245 arkko-eap-service-identity-auth-02.txt (work in progress), May 2246 2005. 2248 [I-D.ohba-eap-aaakey-binding] 2249 Ohba, Y., "AAA-Key Derivation with Channel Binding", draft- 2250 ohba-eap-aaakey-binding-00.txt (work in progress), May 2005. 2252 [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", draft- 2253 ietf-ipsec-ikev2-17 (work in progress), September 2004. 2255 [MD5Attack] 2256 Dobbertin, H., "The Status of MD5 After a Recent Attack", 2257 CryptoBytes, Vol.2 No.2, 1996. 2259 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 2260 September 1981. 2262 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 2263 1661, July 1994. 2265 [RFC1968] Meyer, G. and K. Fox, "The PPP Encryption Control Protocol 2266 (ECP)", RFC 1968, June 1996. 2268 [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing 2269 for Message Authentication", RFC 2104, February 1997. 2271 [RFC2246] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. 2272 and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, 2273 January 1999. 2275 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 2276 Internet Protocol", RFC 2401, November 1998. 2278 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 2279 RFC 2409, November 1998. 2281 [RFC2419] Sklower, K. and G. Meyer, "The PPP DES Encryption Protocol, 2282 Version 2 (DESE-bis)", RFC 2419, September 1998. 2284 [RFC2420] Kummert, H., "The PPP Triple-DES Encryption Protocol (3DESE)", 2285 RFC 2420, September 1998. 2287 [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D. and 2288 R. Wheeler, "A Method for Transmitting PPP Over Ethernet 2289 (PPPoE)", RFC 2516, February 1999. 2291 [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2292 2548, March 1999. 2294 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 2295 Implementation in Roaming", RFC 2607, June 1999. 2297 [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol", 2298 RFC 2716, October 1999. 2300 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 2301 Authentication Dial In User Service (RADIUS)", RFC 2865, June 2302 2000. 2304 [RFC3078] Pall, G. and G. Zorn, "Microsoft Point-To-Point Encryption 2305 (MPPE) Protocol", RFC 3078, March 2001. 2307 [RFC3079] Zorn, G., "Deriving Keys for use with Microsoft Point-to-Point 2308 Encryption (MPPE)", RFC 3079, March 2001. 2310 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial 2311 In User Service) Support For Extensible Authentication 2312 Protocol (EAP)", RFC 3579, September 2003. 2314 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese, 2315 "IEEE 802.1X Remote Authentication Dial In User Service 2316 (RADIUS) Usage Guidelines", RFC 3580, September 2003. 2318 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. 2319 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 2321 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public 2322 Keys Used For Exchanging Symmetric Keys", RFC 3766, April 2323 2004. 2325 [RFC4005] Calhoun, P., Zorn, G., Spence, D. and D. Mitton, "Diameter 2326 Network Access Server Application", RFC 4005, August 2005. 2328 [RFC4017] Stanley, D., Walker, J. and B. Aboba, "EAP Method Requirements 2329 for Wireless LANs", RFC 4017, March 2005. 2331 [RFC4072] Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible 2332 Authentication Protocol (EAP) Application", RFC 4072, August 2333 2005. 2335 [RFC4118] Yang, L., Zerfos, P. and E. Sadot, "Architecture Taxonomy for 2336 Control and Provisioning of Wireless Access Points (CAPWAP)", 2337 RFC 4118, June 2005. 2339 [8021XHandoff] 2340 Pack, S. and Y. Choi, "Pre-Authenticated Fast Handoff in a 2341 Public Wireless LAN Based on IEEE 802.1X Model", School of 2342 Computer Science and Engineering, Seoul National University, 2343 Seoul, Korea, 2002. 2345 Acknowledgments 2347 Thanks to Arun Ayyagari, Ashwin Palekar, and Tim Moore of Microsoft, 2348 Dorothy Stanley of Agere, Bob Moskowitz of TruSecure, Jesse Walker of 2349 Intel, Joe Salowey of Cisco and Russ Housley of Vigil Security for 2350 useful feedback. 2352 Author Addresses 2354 Bernard Aboba 2355 Microsoft Corporation 2356 One Microsoft Way 2357 Redmond, WA 98052 2359 EMail: bernarda@microsoft.com 2360 Phone: +1 425 706 6605 2361 Fax: +1 425 936 7329 2363 Dan Simon 2364 Microsoft Research 2365 Microsoft Corporation 2366 One Microsoft Way 2367 Redmond, WA 98052 2369 EMail: dansimon@microsoft.com 2370 Phone: +1 425 706 6711 2371 Fax: +1 425 936 7329 2373 Jari Arkko 2374 Ericsson 2375 Jorvas 02420 2376 Finland 2378 Phone: 2379 EMail: jari.arkko@ericsson.com 2381 Pasi Eronen 2382 Nokia Research Center 2383 P.O. Box 407 2384 FIN-00045 Nokia Group 2385 Finland 2387 EMail: pasi.eronen@nokia.com 2389 Henrik Levkowetz (editor) 2390 ipUnplugged AB 2391 Arenavagen 27 2392 Stockholm S-121 28 2393 SWEDEN 2395 Phone: +46 708 32 16 08 2396 EMail: henrik@levkowetz.com 2398 Appendix A - EAP-TLS Key Hierarchy 2400 EAP-TLS [RFC 2716] was documented prior to the development of EAP key 2401 management terminology [RFC3748], and therefore does not explicitly 2402 define the MSK and EMSK. 2404 In EAP-TLS, the MSK, EMSK and IV are derived from the TLS master 2405 secret via a one-way function. This ensures that the TLS master 2406 secret cannot be derived from the MSK, EMSK or IV unless the one-way 2407 function (TLS PRF) is broken. Since the MSK is derived from the the 2408 TLS master secret, if the TLS master secret is compromised then the 2409 MSK is also compromised. 2411 [RFC2716] specifies that the MSK is divided into two halves, 2412 corresponding to the "Peer to Authenticator Encryption Key" (Enc- 2413 RECV-Key, 32 octets) and "Authenticator to Peer Encryption Key" (Enc- 2414 SEND-Key, 32 octets). In [RFC2548], the Enc-RECV-Key is transported 2415 in the MS-MPPE-Recv-Key attribute, and the Enc-SEND-Key is 2416 transported in the MS-MPPE-Send- Key attribute. 2418 The EMSK is also divided into two halves, corresponding to the "Peer 2419 to Authenticator Authentication Key" (Auth-RECV-Key, 32 octets) and 2420 "Authenticator to Peer Authentication Key" (Auth-SEND-Key, 32 2421 octets). The IV is a 64 octet quantity that is a known value; octets 2422 0-31 are known as the "Peer to Authenticator IV" or RECV-IV, and 2423 Octets 32-63 are known as the "Authenticator to Peer IV", or SEND-IV. 2425 The key derivation scheme MUST be interpreted as follows: 2427 MSK = TLS-PRF-64(TMS, "client EAP encryption", 2428 client.random || server.random) 2429 EMSK = second 64 octets of: 2430 TLS-PRF-128(TMS, "client EAP encryption", 2431 client.random || server.random) 2432 IV = TLS-PRF-64("", "client EAP encryption", 2433 client.random || server.random) 2435 MSK(0,31) = Peer to Authenticator Encryption Key (Enc-RECV-Key) 2436 (MS-MPPE-Recv-Key in [RFC2548]). Also known as the 2437 PMK. 2438 MSK(32,63) = Authenticator to Peer Encryption Key (Enc-SEND-Key) 2439 (MS-MPPE-Send-Key in [RFC2548]) 2440 EMSK(0,31) = Peer to Authenticator Authentication Key (Auth-RECV-Key) 2441 EMSK(32,63) = Authenticator to Peer Authentication Key (Auth-Send-Key) 2442 IV(0,31) = Peer to Authenticator Initialization Vector (RECV-IV) 2443 IV(32,63) = Authenticator to Peer Initialization vector (SEND-IV) 2445 Where: 2447 IV(W,Z) = Octets W through Z inclusive of the IV. 2448 MSK(W,Z) = Octets W through Z inclusive of the MSK. 2449 EMSK(W,Z) = Octets W through Z inclusive of the EMSK. 2450 TMS = TLS master_secret 2451 TLS-PRF-X = TLS PRF function defined in [RFC2246] computed to X octets 2452 client.random = Nonce generated by the TLS client. 2453 server.random = Nonce generated by the TLS server. 2455 Figure A-1 illustrates the TEK key hierarchy for EAP-TLS [RFC2716], 2456 which is based on the TLS key hierarchy described in [RFC2246]. The 2457 TLS-negotiated ciphersuite is used to set up a protected channel for 2458 use in protecting the EAP conversation, keyed by the derived TEKs. 2459 The TEK derivation proceeds as follows: 2461 master_secret = TLS-PRF-48(pre_master_secret, "master secret", 2462 client.random || server.random) 2463 TEK = TLS-PRF-X(master_secret, "key expansion", 2464 server.random || client.random) 2465 Where: 2467 TLS-PRF-X = TLS pseudo-random function defined in [RFC2246], 2468 computed to X octets. 2470 | | pre_master_secret | 2471 server| | | client 2472 Random| V | Random 2473 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2474 | | | | 2475 +---->| master_secret |<------+ 2476 | | (TMS) | | 2477 | | | | 2478 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2479 | | | 2480 V V V 2481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2482 | | 2483 | Key Block (TEKs) | 2484 | | 2485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2486 | | | | | | 2487 | client | server | client | server | client | server 2488 | MAC | MAC | write | write | IV | IV 2489 | | | | | | 2490 V V V V V V 2492 Figure A-1 - TLS [RFC2246] Key Hierarchy 2494 Appendix B - Exported Parameters in Existing Methods 2496 This Appendix specifies Method-ID, Peer-ID, Server-ID and Key- 2497 Lifetime for EAP methods that have been published prior to this 2498 specification. Future EAP method specifications MUST include a 2499 definition of the Method-ID, Peer-ID, and Server-ID (could be the 2500 empty string) and MAY also define the Key-Lifetime (assumed to be 2501 indeterminate if not described). 2503 EAP-Identity 2505 The EAP-Identity method does not derive keys, and therefore does 2506 not define the Key-Lifetime or Method-ID. The Peer-ID exported by 2507 the Identity method is determined by the octets included within 2508 the EAP- Response/Identity. The Server-ID is the empty string 2509 (zero length). 2511 EAP-Notification 2513 The EAP-Notification method does not derive keys and therefore 2514 does not define the Key-Lifetime and Method-ID. The Peer-ID and 2515 Server-ID are the empty string (zero length). 2517 EAP-GTC 2519 The EAP-GTC method does not derive keys and therefore does not 2520 define the Key-Lifetime and Method-ID. The Peer-ID and Server-ID 2521 are the empty string. 2523 EAP-OTP 2525 The EAP-OTP method does not derive keys and therefore does not 2526 define the Key-Lifetime and Method-ID. The Peer-ID and Server-ID 2527 are the empty string. 2529 EAP-TLS 2531 The EAP-TLS Method-Id is the concatenation of the peer and server 2532 nonces. 2534 The Peer-ID and Server-ID are the contents of the altSubjectName 2535 in the peer and server certificates. 2537 EAP-TLS does not negotiate a Key-Lifetime. 2539 EAP-AKA 2541 The EAP-AKA Method-Id is the contents of the RAND field from the 2542 AT_RAND attribute, followed by the contents of the AUTN field in 2543 the AT_AUTN attribute. 2545 The Peer-ID is the contents of the Identity field from the 2546 AT_IDENTITY attribute, using only the Actual Identity Length 2547 octets from the beginning, however. Note that the contents are 2548 used as they are transmitted, regardless of whether the 2549 transmitted identity was a permanent, pseudonym, or fast re- 2550 authentication identity. The Server-ID is an empty string. EAP- 2551 AKA does not negotiate a key lifetime. 2553 EAP-SIM 2555 The Method-Id is the contents of the RAND field from the AT_RAND 2556 attribute, followed by the contents of the NONCE_MT field in the 2557 AT_NONCE_MT attribute. 2559 The Peer-ID is the contents of the Identity field from the 2560 AT_IDENTITY attribute, using only the Actual Identity Length 2561 octets from the beginning, however. Note that the contents are 2562 used as they are transmitted, regardless of whether the 2563 transmitted identity was a permanent, pseudonym, or fast re- 2564 authentication identity. The Server-ID is an empty string. EAP- 2565 SIM does not negotiate a key lifetime. 2567 Intellectual Property Statement 2569 The IETF takes no position regarding the validity or scope of any 2570 Intellectual Property Rights or other rights that might be claimed to 2571 pertain to the implementation or use of the technology described in 2572 this document or the extent to which any license under such rights 2573 might or might not be available; nor does it represent that it has 2574 made any independent effort to identify any such rights. Information 2575 on the procedures with respect to rights in RFC documents can be 2576 found in BCP 78 and BCP 79. 2578 Copies of IPR disclosures made to the IETF Secretariat and any 2579 assurances of licenses to be made available, or the result of an 2580 attempt made to obtain a general license or permission for the use of 2581 such proprietary rights by implementers or users of this 2582 specification can be obtained from the IETF on-line IPR repository at 2583 http://www.ietf.org/ipr. 2585 The IETF invites any interested party to bring to its attention any 2586 copyrights, patents or patent applications, or other proprietary 2587 rights that may cover technology that may be required to implement 2588 this standard. Please address the information to the IETF at ietf- 2589 ipr@ietf.org. 2591 Disclaimer of Validity 2593 This document and the information contained herein are provided on an 2594 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2595 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2596 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2597 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2598 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2599 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2601 Copyright Statement 2603 Copyright (C) The Internet Society (2006). This document is subject 2604 to the rights, licenses and restrictions contained in BCP 78, and 2605 except as set forth therein, the authors retain all their rights. 2607 Acknowledgment 2609 Funding for the RFC Editor function is currently provided by the 2610 Internet Society. 2612 Open Issues 2614 Open issues relating to this specification are tracked on the 2615 following web site: 2617 http://www.drizzle.com/~aboba/EAP/eapissues.html