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