idnits 2.17.00 (12 Aug 2021) /tmp/idnits21094/draft-ietf-eap-keying-07.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 3376. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3353. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3360. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3366. ** 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 73 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 74 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 73 instances of too long lines in the document, the longest one being 10 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 843 has weird spacing: '...enerate fresh...' == Line 2031 has weird spacing: '...ude the key s...' == 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 1947 -- Looks like a reference, but probably isn't: '2' on line 1950 -- Looks like a reference, but probably isn't: '3' on line 1956 -- Looks like a reference, but probably isn't: '4' on line 1157 -- Looks like a reference, but probably isn't: '5' on line 888 == Missing Reference: 'IEEE802.11i' is mentioned on line 3242, but not defined == Missing Reference: 'RFC 3748' is mentioned on line 1469, but not defined == Missing Reference: 'RFC3759' is mentioned on line 1698, but not defined == Missing Reference: 'RFC3784' is mentioned on line 1930, but not defined ** Obsolete undefined reference: RFC 3784 (Obsoleted by RFC 5305) == Missing Reference: 'RFC3162' is mentioned on line 2316, but not defined == Missing Reference: 'ServiceIdent' is mentioned on line 2321, but not defined == Missing Reference: 'IEEE-802' is mentioned on line 2664, but not defined == Missing Reference: 'ECP' is mentioned on line 2888, but not defined == Unused Reference: 'RFC2434' is defined on line 2640, but no explicit reference was found in the text == Unused Reference: 'IEEE-02-758' is defined on line 2703, but no explicit reference was found in the text == Unused Reference: 'IEEE-03-084' is defined on line 2709, but no explicit reference was found in the text == Unused Reference: 'IEEE-03-155' is defined on line 2716, but no explicit reference was found in the text == Unused Reference: 'RFC0793' is defined on line 2746, but no explicit reference was found in the text == Unused Reference: 'RFC2104' is defined on line 2755, but no explicit reference was found in the text == Unused Reference: 'RFC2401' is defined on line 2762, but no explicit reference was found in the text == Unused Reference: 'RFC3079' is defined on line 2794, but no explicit reference was found in the text == Unused Reference: '8021XHandoff' is defined on line 2815, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) == Outdated reference: draft-ietf-seamoby-ctp has been published as RFC 4067 == Outdated reference: draft-housley-aaa-key-mgmt has been published as RFC 4962 -- Unexpected draft version: The latest known version of draft-ietf-roamops-cert is -01, but you're referring to -02. == Outdated reference: draft-ietf-aaa-eap has been published as RFC 4072 == Outdated reference: draft-arkko-pppext-eap-aka has been published as RFC 4187 == Outdated reference: draft-ietf-ipsec-ikev2 has been published as RFC 4306 -- 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) Summary: 7 errors (**), 0 flaws (~~), 29 warnings (==), 18 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 17 July 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 January 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 .......................................... 4 52 1.1 Requirements Language ........................... 4 53 1.2 Terminology ..................................... 4 54 1.3 Overview ........................................ 7 55 1.4 EAP Invariants .................................. 14 56 2. Lower Layer Operation ................................. 16 57 2.1 Discovery Phase ................................. 18 58 2.2 Authentication Phase ............................ 18 59 2.3 Secure Association Phase ........................ 19 60 2.4 Lower Layer Key Hierarchy ....................... 21 61 2.5 AAA-Key Derivation and Naming ................... 24 62 3. Security associations ................................. 26 63 3.1 EAP Method SA ................................... 26 64 3.2 EAP-Key SA ...................................... 27 65 3.3 AAA SA(s) ....................................... 27 66 3.4 Service SA(s) ................................... 27 67 4. Key Management ........................................ 30 68 4.1 Key Caching ..................................... 31 69 4.2 Parent-Child Relationships ...................... 32 70 4.3 Local Key Lifetimes ............................. 32 71 4.4 Exported and Calculated Key Lifetimes ........... 33 72 4.5 Key Cache Synchronization ....................... 34 73 4.6 Key Scope ....................................... 35 74 4.7 Key Strength .................................... 36 75 4.8 Key Wrap ........................................ 37 76 5. Handoff Vulnerabilities ............................... 38 77 5.1 Authorization ................................... 38 78 5.2 Correctness ..................................... 39 79 6. Security Considerations .............................. 42 80 6.1 Security Terminology ............................ 42 81 6.2 Threat Model .................................... 42 82 6.3 Security Analysis ............................... 44 83 6.4 Man-in-the-middle Attacks ....................... 47 84 6.5 Denial of Service Attacks ....................... 48 85 6.6 Impersonation ................................... 48 86 6.7 Channel Binding ................................. 50 88 7. Security Requirements ................................. 50 89 7.1 EAP Method Requirements ......................... 51 90 7.2 AAA Protocol Requirements ....................... 53 91 7.3 Secure Association Protocol Requirements ........ 55 92 7.4 Ciphersuite Requirements ........................ 56 93 8. IANA Considerations ................................... 57 94 9. References ............................................ 57 95 9.1 Normative References ............................ 57 96 9.2 Informative References .......................... 57 97 Acknowledgments .............................................. 61 98 Author's Addresses ........................................... 61 99 Appendix A - Ciphersuite Keying Requirements ................. 63 100 Appendix B - Example Transient EAP Key (TEK) Hierarchy ....... 64 101 Appendix C - EAP-TLS Key Hierarchy ........................... 65 102 Appendix D - Example Transient Session Key (TSK) Derivation .. 67 103 Appendix E - Exported Parameters in Existing Methods ......... 68 104 Appendix F - Security Association Examples ................... 70 105 Intellectual Property Statement .............................. 73 106 Disclaimer of Validity ....................................... 74 107 Copyright Statement .......................................... 74 109 1. Introduction 111 The Extensible Authentication Protocol (EAP), defined in [RFC3748], 112 was designed to enable extensible authentication for network access 113 in situations in which the IP protocol is not available. Originally 114 developed for use with PPP [RFC1661], it has subsequently also been 115 applied to IEEE 802 wired networks [IEEE-802.1X]. 117 This document provides a framework for the generation, transport and 118 usage of keying material generated by EAP authentication algorithms, 119 known as "methods". In EAP keying material is generated by EAP 120 methods. Part of this keying material may be used by EAP methods 121 themselves and part of this material may be exported. The exported 122 keying material may be transported by AAA protocols or transformed by 123 Secure Association Protocols into session keys which are used by 124 lower layer ciphersuites. This document describes each of these 125 elements and provides a system-level security analysis. It also 126 specifies the EAP key hierarchy. 128 1.1. Requirements Language 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in BCP 14 [RFC2119]. 134 1.2. Terminology 136 This document frequently uses the following terms: 138 authenticator 139 The end of the link initiating EAP authentication. The term 140 Authenticator is used in [IEEE-802.1X], and authenticator has the 141 same meaning in this document. 143 peer The end of the link that responds to the authenticator. In 144 [IEEE-802.1X], this end is known as the Supplicant. 146 Supplicant 147 The end of the link that responds to the authenticator in 148 [IEEE-802.1X]. In this document, this end of the link is called 149 the peer. 151 backend authentication server 152 A backend authentication server is an entity that provides an 153 authentication service to an authenticator. When used, this server 154 typically executes EAP methods for the authenticator. This 155 terminology is also used in [IEEE-802.1X]. 157 AAA Authentication, Authorization and Accounting. AAA protocols with 158 EAP support include RADIUS [RFC3579] and Diameter [I-D.ietf-aaa- 159 eap]. In this document, the terms "AAA server" and "backend 160 authentication server" are used interchangeably. 162 EAP server 163 The entity that terminates the EAP authentication method with the 164 peer. In the case where no backend authentication server is used, 165 the EAP server is part of the authenticator. In the case where the 166 authenticator operates in pass-through mode, the EAP server is 167 located on the backend authentication server. 169 security association 170 A set of policies and cryptographic state used to protect 171 information. Elements of a security association may include 172 cryptographic keys, negotiated ciphersuites and other parameters, 173 counters, sequence spaces, authorization attributes, etc. 175 Long Term Credential 176 EAP methods frequently make use of long term secrets in order to 177 enable authentication between the peer and server. In the case of 178 a method based on pre-shared key authentication, the long term 179 credential is the pre-shared key. In the case of a public-key 180 based method, the long term credential is the corresponding private 181 key. 183 Master Session Key (MSK) 184 Keying material that is derived between the EAP peer and server and 185 exported by the EAP method. The MSK is at least 64 octets in 186 length. 188 Extended Master Session Key (EMSK) 189 Additional keying material derived between the peer and server that 190 is exported by the EAP method. The EMSK is at least 64 octets in 191 length, and is never shared with a third party. 193 Initialization Vector (IV) 194 A quantity of at least 64 octets, suitable for use in an 195 initialization vector field, that is derived between the peer and 196 EAP server. Since the IV is a known value in methods such as EAP- 197 TLS [RFC2716], it cannot be used by itself for computation of any 198 quantity that needs to remain secret. As a result, its use has 199 been deprecated and EAP methods are not required to generate it. 200 However, when it is generated it MUST be unpredictable. 202 Pairwise Master Key (PMK) 203 The AAA-Key is divided into two halves, the "Peer to Authenticator 204 Encryption Key" (Enc-RECV-Key) and "Authenticator to Peer 205 Encryption Key" (Enc-SEND-Key) (reception is defined from the point 206 of view of the authenticator). Within [IEEE-802.11i] Octets 0-31 207 of the AAA-Key (Enc-RECV-Key) are known as the Pairwise Master Key 208 (PMK). In [IEEE-802.11i] the TKIP and AES CCMP ciphersuites derive 209 their Transient Session Keys (TSKs) solely from the PMK, whereas 210 the WEP ciphersuite as noted in [RFC3580], derives its TSKs from 211 both halves of the AAA-Key. 213 Transient EAP Keys (TEKs) 214 Session keys which are used to establish a protected channel 215 between the EAP peer and server during the EAP authentication 216 exchange. The TEKs are appropriate for use with the ciphersuite 217 negotiated between EAP peer and server for use in protecting the 218 EAP conversation. Note that the ciphersuite used to set up the 219 protected channel between the EAP peer and server during EAP 220 authentication is unrelated to the ciphersuite used to subsequently 221 protect data sent between the EAP peer and authenticator. An 222 example TEK key hierarchy is described in Appendix C. 224 Transient Session Keys (TSKs) 225 Session keys used to protect data exchanged between a port of the 226 peer and a port of the authenticator after the EAP authentication 227 has successfully completed. TSKs are appropriate for the lower 228 layer ciphersuite negotiated between the ports of the EAP peer and 229 authenticator. Examples of TSK derivation are provided in Appendix 230 D. 232 AAA-Key 233 A key derived by the peer and EAP server, used by the peer and 234 authenticator in the derivation of Transient Session Keys (TSKs). 235 Where a backend authentication server is present, the AAA-Key is 236 transported from the backend authentication server to the 237 authenticator, wrapped within the AAA-Token; it is therefore known 238 by the peer, authenticator and backend authentication server. 239 Despite the name, the AAA-Key is computed regardless of whether a 240 backend authentication server is present. AAA-Key derivation is 241 discussed in Section 2.5; in existing implementations the MSK is 242 used as the AAA-Key. 244 AAA-Token 245 Where a backend server is present, the AAA-Key and one or more 246 attributes is transported between the backend authentication server 247 and the authenticator within a package known as the AAA-Token. The 248 format and wrapping of the AAA-Token, which is intended to be 249 accessible only to the backend authentication server and 250 authenticator, is defined by the AAA protocol. Examples include 251 RADIUS [RFC2548] and Diameter [I-D.ietf-aaa-eap]. 253 1.3. Overview 255 EAP, defined in [RFC3748] is a two-party protocol spoken between the 256 EAP peer and server. Within EAP, keying material is generated by EAP 257 methods. Part of this keying material may be used by EAP methods 258 themselves and part of this material may be exported. In addition to 259 export of keying material, EAP methods may also export associated 260 parameters, and may import and export Channel Bindings from the lower 261 layer. 263 As illustrated in Figure 1, the EAP method key derivation has at the 264 root the long term credential utilized by the selected EAP method. 265 If authentication is based on a pre-shared key, the parties store the 266 EAP method to be used and the pre-shared key. The EAP server also 267 stores the peer's identity and/or other information necessary to 268 decide whether access to some service should be granted. The peer 269 stores information necessary to choose which secret to use for which 270 service. 272 If authentication is based on proof of possession of the private key 273 corresponding to the public key contained within a certificate, the 274 parties store the EAP method to be used and the trust anchors used to 275 validate the certificates. The EAP server also stores the peer's 276 identity and/or other information necessary to decide whether access 277 to some service should be granted. The peer stores information 278 necessary to choose which certificate to use for which service. 280 Based on the long term credential established between the peer and 281 the server, EAP methods derive two types of keys: 283 [1] Keys calculated locally by the EAP method but not exported 284 by the EAP method, such as the TEKs. 285 [2] Keying material exported by the EAP method: MSK, EMSK, IV. 287 As noted in [RFC3748] Section 7.10, EAP methods generating keys are 288 required to calculate and export the MSK and EMSK, which must be at 289 least 64 octets in length. EAP methods also may export the IV; 290 however, the use of the IV is deprecated. 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 293 | | ^ 294 | EAP Method | | 295 | | | 296 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | | 297 | | | | | | | 298 | | EAP Method Key |<->| Long-Term | | | 299 | | Derivation | | Credential | | | 300 | | | | | | | 301 | | | +-+-+-+-+-+-+-+ | Local to | 302 | | | | EAP | 303 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Method | 304 | | | | | | 305 | | | | | | 306 | | | | | | 307 | | | | | | 308 | | | | | | 309 | | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | | 310 | | | TEK | |MSK, EMSK | |IV | | | 311 | | |Derivation | |Derivation | |Derivation | | | 312 | | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | | 313 | | | | | | 314 | | ^ | | | V 315 +-+-|-+-+-+-+-+-+-+-+-|-+-+-+-+-+-|-+-+-+-+-+-+-+-+-|-+-+-+ ---+ 316 | | | | ^ 317 | Peer-ID, | | | Exported| 318 | Server-ID, | Channel | MSK (64+B) | IV (64B) by | 319 | Method-ID, | Bindings | EMSK (64+B) | EAP | 320 | Key-Lifetime | & Result | | Method | 321 V V V V V 323 Figure 1: EAP Parameter Import/Export 325 EAP methods also MAY export method-specific peer and server 326 identifiers (peer-ID and server-ID), a method-specific EAP 327 conversation identifier known as the Method-ID, and the lifetime of 328 the exported keys, known the Key-Lifetime. EAP methods MAY also 329 support the import and export of Channel Bindings. New EAP method 330 specifications MUST define the Peer-ID, Server-ID and Method-ID. The 331 combination of the Peer-ID and Server-ID uniquely specifies the 332 endpoints of the EAP method exchange. 334 Peer-ID 336 As described in [RFC3748] Section 7.3, the identity provided in 337 the EAP-Response/Identity, may be different from the peer identity 338 authenticated by the EAP method. Where the EAP method 339 authenticates the peer identity, that identity is exported by the 340 method as the Peer-ID. A suitable EAP peer name may not always be 341 available. Where an EAP method does not define a method-specific 342 peer identity, the Peer-ID is the null string. The Peer-ID for 343 existing EAP methods is defined in Appendix E. 345 Server-ID 347 Where the EAP method authenticates the server identity, that 348 identity is exported by the method as the Server-ID. A suitable 349 EAP server name may not always be available. Where an EAP method 350 does not define a method-specific peer identity, the Server-ID is 351 the null string. The Server-ID for existing EAP methods is 352 defined in Appendix E. 354 Method-ID 356 EAP method specifications deriving keys MUST specify a temporally 357 unique method identifier known as the Method-ID. The EAP Method- 358 ID uniquely identifies an EAP session of a given Type between an 359 EAP peer and server. The Method-ID is typically constructed from 360 nonces or counters used within the EAP method exchange. The 361 Method-ID for existing EAP methods is defined in Appendix E. 363 Session-ID 365 The Session-ID uniquely identifies an EAP session between an EAP 366 peer (as identified by the Peer-ID) and server (as identified by 367 the Server-ID). The EAP Session-ID consists of the concatenation 368 of the Expanded EAP Type Code (including the Type, Vendor-ID and 369 Vendor-Type fields defined in [RFC3748] Section 5.7) and the 370 Method-ID. The inclusion of the Expanded Type Code in the EAP 371 Session-Id ensures that each EAP method has a distinct Session-ID 372 space. Since an EAP session is not bound to a particular 373 authenticator or specific ports on the peer and authenticator, the 374 authenticator port or identity are not included in the Session-Id. 376 Key-Lifetime 378 While EAP itself does not support key lifetime negotiation, it is 379 possible to specify methods that do. However, systems that rely 380 on such negotiation for exported keys would only function with 381 these methods. As a result, it is NOT RECOMMENDED to use this 382 approach as the sole way to determine key lifetimes. 384 Channel Bindings 386 Channel Bindings include lower layer parameters that are verified 387 for consistency between the EAP peer and server. In order to 388 avoid introducing media dependencies, EAP methods MUST treat 389 Channel Bindings as opaque octets. Typically the EAP method 390 imports Channel Bindings from the lower layer on the peer, and 391 transmits them securely to the EAP server, which exports them to 392 the lower layer. However, transport may occur from EAP server to 393 peer, or may be bi-directional. On the side of the exchange (peer 394 or server) where Channel Bindings are verified, the lower layer 395 passes the result of the verification (TRUE or FALSE) up to the 396 EAP method. 398 1.3.1. Layering 400 As illustrated in Figure 2, keying material and parameters exported 401 by EAP methods are passed down to the EAP peer or authenticator 402 layers, which passes them to the EAP layer. Keying material and 403 related parameters (including Channel Bindings) MUST NOT be cached by 404 the EAP peer or authenticator layers, or the EAP layer. 406 Based on the Method-ID exported by the EAP method, the EAP layer 407 forms the EAP Session-ID by concatenating the EAP Expanded Type with 408 the Method-ID. Together with the MSK, EMSK, IV, Peer-ID, Server-ID, 409 and Key-Lifetime, the EAP layer passes the Session-ID down to the 410 lower layer. 412 The Method-ID is exported by EAP methods rather than the Session-ID 413 so as to prevent EAP methods from writing into each other's Session- 414 ID space. Lower layers MAY cache keying material and related 415 parameters, including Channel Bindings. Lower Layer behavior is 416 discussed in more detail in Section 2. 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | | 420 | | 421 | EAP method | 422 | | 423 | MSK, EMSK, IV, Channel | 424 | Peer-ID, Server-ID, Bindings | 425 | Method-ID, | 426 | Key-Lifetime | 427 | | 428 | V ^ ^ | 429 +-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+ 430 | ! ! ! | 431 | EAP ! Peer or Authenticator ! ! | 432 | ! layer ! ! | 433 | ! ! ! | 434 +-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+ 435 | ! ! ! | 436 | EAP ! layer ! ! | 437 | ! ! ! | 438 | ! Session-ID = ! ! | 439 | ! Expanded-Type || ! ! | 440 | ! Method-ID ! ! | 441 | ! ! ! | 442 +-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+ 443 | ! ! ! | 444 | Lower ! layer ! ! | 445 | ! ! ! | 446 | V V ^ | 447 | MSK, EMSK, IV, Channel Result | 448 | Peer-ID, Server-ID, Bindings | 449 | Session-ID, | 450 | Key-Lifetime | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 Figure 2: Flow of EAP parameters 455 1.3.2. Key Naming 457 Each key created within the EAP key management framework has a name 458 (the identifier by which the key can be identified), as well as a 459 scope (the parties to whom the key is available). The scope of 460 exported parameters is defined by the EAP peer name (if securely 461 exchanged within the method) and the EAP server name (also only if 462 securely exchanged). Where a peer or server name is missing the null 463 string is used. 465 MSK Name 466 This key is created between the EAP peer and EAP server, and can be 467 referred to using the string "MSK:", concatenated with the EAP 468 Session-ID. 470 EMSK Name 471 The EMSK can be referred to using the string "EMSK:", concatenated 472 with the EAP Session-ID. 474 IV Name 475 Use of the IV is deprecated. However, if necessary the IV can be 476 referred to using the string "IV:" concatenated with the EAP 477 Session-ID. 479 PMK Name 480 This document does not specify a naming scheme for the PMK. The 481 PMK is only identified by the key from which it is derived. 483 Note: IEEE 802.11i names the PMKID for the purposes of being able 484 to refer to it in the Secure Association protocol; this naming is 485 based on a hash of the PMK itself as well as some other parameters 486 (see Section 8.5.1.2 [IEEE-802.11i]). 488 TEK Name 489 The TEKs may or may not be named. Their naming is specified in the 490 EAP method. 492 1.3.3. EAP and AAA 494 EAP is typically deployed in order to support extensible network 495 access authentication in situations where a peer desires network 496 access via one or more authenticators. Since both the peer and 497 authenticator may have more than one physical or logical port, a 498 given peer may simultaneously access the network via multiple 499 authenticators, or via multiple physical or logical ports on a given 500 authenticator. Similarly, an authenticator may offer network access 501 to multiple peers, each via a separate physical or logical port. The 502 situation is illustrated in Figure 3. 504 Where authenticators are deployed standalone, the EAP conversation 505 occurs between the peer and authenticator, and the authenticator must 506 locally implement an EAP method acceptable to the peer. However, one 507 of the advantages of EAP is that it enables deployment of new 508 authentication methods without requiring development of new code on 509 the authenticator. While the authenticator may implement some EAP 510 methods locally and use those methods to authenticate local users, it 511 may at the same time act as a pass-through for other users and 512 methods, forwarding EAP packets back and forth between the backend 513 authentication server and the peer. 515 This is accomplished by encapsulating EAP packets within the 516 Authentication, Authorization and Accounting (AAA) protocol, spoken 517 between the authenticator and backend authentication server. AAA 518 protocols supporting EAP include RADIUS [RFC3579] and Diameter [I- 519 D.ietf-aaa-eap]. 521 +-+-+-+-+ 522 | | 523 | EAP | 524 | Peer | 525 | | 526 +-+-+-+-+ 527 | | | Peer Ports 528 / | \ 529 / | \ 530 / | \ 531 / | \ 532 / | \ 533 / | \ 534 / | \ 535 / | \ 536 | | | | | | | | | Authenticator Ports 537 +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ 538 | | | | | | 539 | Auth. | | Auth. | | Auth. | 540 | | | | | | 541 +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ 542 \ | / 543 \ | / 544 \ | / 545 EAP over AAA \ | / 546 (optional) \ | / 547 \ | / 548 \ | / 549 \ | / 550 +-+-+-+-+ 551 | | 552 | AAA | 553 |Server | 554 | | 555 +-+-+-+-+ 557 Figure 3: Relationship between peer, authenticator and backend server 558 1.4. EAP Invariants 560 Certain basic characteristics, known as "EAP Invariants", hold true 561 for EAP implementations on all media: 563 Mode independence 564 Media independence 565 Method independence 566 Ciphersuite independence 568 1.4.1. Mode Independence 570 EAP as defined in [RFC3748] is a two party protocol spoken between 571 the EAP peer and server. A fundamental property of EAP is that at 572 the EAP method layer, the conversation between the EAP peer and 573 server is unaffected by whether the EAP authenticator is operating in 574 "pass-through" mode. 576 EAP methods operate identically in all aspects, including key 577 derivation and parameter import/export, regardless of whether the 578 authenticator is operating as a pass-through or not. 580 The successful completion of an EAP method that supports key 581 derivation results in the export of keying material on the EAP peer 582 and server. Even though the EAP peer or server may import Channel- 583 Bindings that may include the identity of the EAP authenticator, 584 this information is treated as opaque octets. As a result, within 585 EAP the only relevant identities are the Peer-ID and Server-ID. 586 Channel Bindings are only interpreted by the lower layer. 588 Within EAP, the primary function of the AAA protocol is to maintain 589 the principle of Mode Independence, so that as far as the EAP peer is 590 concerned, its conversation with the EAP authenticator, and all 591 consequences of that conversation, are identical, regardless of the 592 authenticator mode of operation. 594 1.4.2. Media Independence 596 One of the goals of EAP is to allow EAP methods to function on any 597 lower layer meeting the criteria outlined in [RFC3748], Section 3.1. 598 For example, as described in [RFC3748], EAP authentication can be run 599 over PPP [RFC1661], IEEE 802 wired networks [IEEE-802.1X], and IEEE 600 802.11 wireless LANs [IEEE-802.11i]. 602 In order to maintain media independence, it is necessary for EAP to 603 avoid consideration of media-specific elements. For example, EAP 604 methods cannot be assumed to have knowledge of the lower layer over 605 which they are transported, and cannot be restricted to identifiers 606 associated with a particular usage environment (e.g. MAC addresses). 608 Note that media independence may be retained within EAP methods that 609 support Channel-Bindings or method-specific identification. An EAP 610 method need not be aware of the content of an identifier in order to 611 use it. This enables an EAP method to use media-specific identifiers 612 such as MAC addresses without compromising media independence. 613 Channel-Bindings are treated as opaque octets by EAP methods, so that 614 handling them does not require media-specific knowledge. 616 1.4.3. Method Independence 618 By enabling pass-through, authenticators can support any method 619 implemented on the peer and server, not just locally implemented 620 methods. This allows the authenticator to avoid implementing code 621 for each EAP method required by peers. In fact, since a pass-through 622 authenticator is not required to implement any EAP methods at all, it 623 cannot be assumed to support any EAP method-specific code. 625 As a result, as noted in [RFC3748], authenticators must by default be 626 capable of supporting any EAP method. This is useful where there is 627 no single EAP method that is both mandatory-to-implement and offers 628 acceptable security for the media in use. For example, the [RFC3748] 629 mandatory-to-implement EAP method (MD5-Challenge) does not provide 630 dictionary attack resistance, mutual authentication or key 631 derivation, and as a result is not appropriate for use in wireless 632 LAN authentication [RFC4017]. However, despite this it is possible 633 for the peer and authenticator to interoperate as long as a suitable 634 EAP method is supported on the EAP server. 636 1.4.4. Ciphersuite Independence 638 Ciphersuite Independence is a consequence of the principles of Mode 639 Independence and Media Independence. 641 While EAP methods may negotiate the ciphersuite used in protection of 642 the EAP conversation, the ciphersuite used for the protection of the 643 data exchanged after EAP authentication has completed is negotiated 644 between the peer and authenticator within the lower layer, outside of 645 EAP. Since the ciphersuites used to protect data depend on the lower 646 layer, requiring EAP methods have knowledge of lower layer 647 ciphersuites would compromise the principle of Media Indepence. 649 Since ciphersuite negotiation occurs in the lower layer, there is no 650 need for ciphersuite negotiation within EAP, and EAP methods generate 651 keying material that is ciphersuite-independent. 653 For example, within PPP, the ciphersuite is negotiated within the 654 Encryption Control Protocol (ECP) defined in [RFC1968], after EAP 655 authentication is completed. Within [IEEE-802.11i], the AP 656 ciphersuites are advertised in the Beacon and Probe Responses prior 657 to EAP authentication, and are securely verified during a 4-way 658 handshake exchange. 660 Advantages of ciphersuite-independence include: 662 Reduced update requirements 663 If EAP methods were to specify how to derive transient session keys 664 for each ciphersuite, they would need to be updated each time a new 665 ciphersuite is developed. In addition, backend authentication 666 servers might not be usable with all EAP-capable authenticators, 667 since the backend authentication server would also need to be 668 updated each time support for a new ciphersuite is added to the 669 authenticator. 671 Reduced EAP method complexity 672 Requiring each EAP method to include ciphersuite-specific code for 673 transient session key derivation would increase method complexity 674 and result in duplicated effort. 676 Simplified configuration 677 The ciphersuite is negotiated between the peer and authenticator 678 outside of EAP. Where the authenticator operates in "pass-through" 679 mode, the EAP server is not a party to this negotiation, nor is it 680 involved in the data flow between the EAP peer and authenticator. 681 As a result, the EAP server may not have knowledge of the 682 ciphersuites and negotiation policies implemented by the peer and 683 authenticator, or be aware of the ciphersuite negotiated between 684 them. For example, since ECP negotiation occurs after 685 authentication, when run over PPP, the EAP peer and server may not 686 anticipate the negotiated ciphersuite and therefore this 687 information cannot be provided to the EAP method. 689 2. Lower Layer Operation 691 Where EAP key derivation is supported, the conversation typically 692 takes place in three phases: 694 Phase 0: Discovery 695 Phase 1: Authentication 696 1a: EAP authentication 697 1b: AAA-Key Transport (optional) 698 Phase 2: Secure Association Establishment 699 2a: Unicast Secure Association 700 2b: Multicast Secure Association (optional) 702 Of these phases, Phase 0, 1b and Phase 2 are handled by a lower 703 layer. In the discovery phase (phase 0), peers locate 704 authenticators and discover their capabilities. For example, a peer 705 may locate an authenticator providing access to a particular network, 706 or a peer may locate an authenticator behind a bridge with which it 707 desires to establish a Secure Association. 709 The authentication phase (phase 1) may begin once the peer and 710 authenticator discover each other. This phase always includes EAP 711 authentication (phase 1a). Where the chosen EAP method supports key 712 derivation, in phase 1a keying material is derived on both the peer 713 and the EAP server. This keying material may be used for multiple 714 purposes, including protection of the EAP conversation and subsequent 715 data exchanges. 717 An additional step (phase 1b) is required in deployments which 718 include a backend authentication server, in order to transport keying 719 material (known as the AAA-Key) from the backend authentication 720 server to the authenticator. 722 A Secure Association exchange (phase 2) then occurs between the peer 723 and authenticator in order to manage the creation and deletion of 724 unicast (phase 2a) and multicast (phase 2b) security associations 725 between the peer and authenticator. 727 The conversation phases and relationship between the parties is shown 728 in Figure 4. 730 EAP peer Authenticator Auth. Server 731 -------- ------------- ------------ 732 |<----------------------------->| | 733 | Discovery (phase 0) | | 734 |<----------------------------->|<----------------------------->| 735 | EAP auth (phase 1a) | AAA pass-through (optional) | 736 | | | 737 | |<----------------------------->| 738 | | AAA-Key transport | 739 | | (optional; phase 1b) | 740 |<----------------------------->| | 741 | Unicast Secure association | | 742 | (phase 2a) | | 743 | | | 744 |<----------------------------->| | 745 | Multicast Secure association | | 746 | (optional; phase 2b) | | 747 | | | 749 Figure 4: Conversation Overview 751 2.1. Discovery Phase 753 In the discovery phase (phase 0), the EAP peer and authenticator 754 locate each other and discover each other's capabilities. Discovery 755 can occur manually or automatically, depending on the lower layer 756 over which EAP runs. Since authenticator discovery is handled 757 outside of EAP, there is no need to provide this functionality within 758 EAP. 760 For example, where EAP runs over PPP, the EAP peer might be 761 configured with a phone book providing phone numbers of 762 authenticators and associated capabilities such as supported rates, 763 authentication protocols or ciphersuites. In contrast, PPPoE 764 [RFC2516] provides support for a Discovery Stage to allow a peer to 765 identify the Ethernet MAC address of one or more authenticators and 766 establish a PPPoE SESSION_ID. 768 IEEE 802.11 [IEEE-802.11] also provides integrated discovery support 769 utilizing Beacon and/or Probe Request/Response frames, allowing the 770 peer (known as the station or STA) to determine the MAC address and 771 capabilities of one or more authenticators (known as Access Point or 772 APs). 774 2.2. Authentication Phase 776 Once the peer and authenticator discover each other, they exchange 777 EAP packets. Typically, the peer desires access to the network, and 778 the authenticators provide that access. In such a situation, access 779 to the network can be provided by any authenticator attaching to the 780 desired network, and the EAP peer is typically willing to send data 781 traffic through any authenticator that can demonstrate that it is 782 authorized to provide access to the desired network. 784 An EAP authenticator may handle the authentication locally, or it may 785 act as a pass-through to a backend authentication server. In the 786 latter case the EAP exchange occurs between the EAP peer and a 787 backend authenticator server, with the authenticator forwarding EAP 788 packets between the two. The entity which terminates EAP 789 authentication with the peer is known as the EAP server. Where pass- 790 through is supported, the backend authentication server functions as 791 the EAP server; where authentication occurs locally, the EAP server 792 is the authenticator. Where a backend authentication server is 793 present, at the successful completion of an authentication exchange, 794 the AAA-Key is transported to the authenticator (phase 1b). 796 EAP may also be used when it is desired for two network devices (e.g. 797 two switches or routers) to authenticate each other, or where two 798 peers desire to authenticate each other and set up a secure 799 association suitable for protecting data traffic. 801 Some EAP methods exist which only support one-way authentication; 802 however, EAP methods deriving keys are required to support mutual 803 authentication. In either case, it can be assumed that the parties 804 do not utilize the link to exchange data traffic unless their 805 authentication requirements have been met. For example, a peer 806 completing mutual authentication with an EAP server will not send 807 data traffic over the link until the EAP server has authenticated 808 successfully to the peer, and a Secure Association has been 809 negotiated. 811 Since EAP is a peer-to-peer protocol, an independent and simultaneous 812 authentication may take place in the reverse direction. Both peers 813 may act as authenticators and authenticatees at the same time. 815 Successful completion of EAP authentication and key derivation by a 816 peer and EAP server does not necessarily imply that the peer is 817 committed to joining the network associated with an EAP server. 818 Rather, this commitment is implied by the creation of a security 819 association between the EAP peer and authenticator, as part of the 820 Secure Association Protocol (phase 2). As a result, EAP may be used 821 for "pre-authentication" in situations where it is necessary to pre- 822 establish EAP security associations in order to decrease handoff or 823 roaming latency. 825 2.3. Secure Association Phase 827 The Secure Association phase (phase 2), if it occurs, begins after 828 the completion of EAP authentication (phase 1a) and key transport 829 (phase 1b). A Secure Association Protocol used with EAP typically 830 supports the following features: 832 [1] Generation of fresh transient session keys (TSKs). Where AAA-Key 833 caching is supported, the EAP peer may initiate a new session using 834 a AAA-Key that was used in a previous session. Were the TSKs to be 835 derived from a portion of the AAA-Key, this would result in reuse 836 of the session keys which could expose the underlying ciphersuite 837 to attack. 839 As a result, where AAA-Key caching is supported, the Secure 840 Association Protocol phase is REQUIRED, and MUST provide for 841 freshness of the TSKs. This is typically handled via the exchange 842 of nonces or counters, which are then mixed with the AAA-Key in 843 order to generate fresh unicast (phase 2a) and possibly multicast 844 (phase 2b) session keys. By not using the AAA-Key directly to 845 protect data, the Secure Association Protocol protects against 846 compromise of the AAA-Key. 848 [2] Entity Naming. A basic feature of a Secure Association Protocol is 849 the explicit naming of the parties engaged in the exchange. 850 Explicit identification of the parties is critical, since without 851 this the parties engaged in the exchange are not identified and the 852 scope of the transient session keys (TSKs) generated during the 853 exchange is undefined. As illustrated in Figure 3, both the peer 854 and NAS may have more than one physical or virtual port, so that 855 port identifiers are NOT RECOMMENDED as a naming mechanism. 857 [3] Secure capabilities negotiation. This includes the secure 858 negotiation of usage modes, session parameters (such as key 859 lifetimes), ciphersuites and required filters, including 860 confirmation of the capabilities discovered during phase 0. It is 861 RECOMMENDED that the Secure Association Protocol support secure 862 capabilities negotiation, in order to protect against spoofing 863 during the discovery phase, and to ensure agreement between the 864 peer and authenticator about how data is to be secured. 866 [4] Key management. EAP as defined in [RFC3748] supports key 867 derivation, but not key management. While EAP methods may derive 868 keying material, EAP does provide for the management of exported or 869 derived keys. For example, EAP does not support negotiation of the 870 key lifetime of exported or derived keys, nor does it support 871 rekey. Although EAP methods may support "fast reconnect" as 872 defined in [RFC3748] Section 7.2.1, rekey of exported keys cannot 873 occur without reauthentication. In order to provide method 874 independence, key management of exported or derived keys SHOULD NOT 875 be provided within EAP methods. 877 Since neither EAP nor EAP methods provide key management support, 878 it is RECOMMENDED that key management facilities be provided within 879 the Secure Association Protocol. This includes key lifetime 880 management (such as via explicit key lifetime negotiation, or 881 seamless rekey), as well synchronization of the installation and 882 deletion of keys so as to enable recovery from partial or complete 883 loss of key state by the peer or authenticator. Since key 884 management requires a key naming scheme, Secure Association 885 Protocols supporting key management support MUST also support key 886 naming. 888 [5] Mutual proof of possession of the AAA-Key. The Secure Association 889 Protocol MUST demonstrate mutual proof of posession of the AAA-Key, 890 in order to show that both the peer and authenticator have been 891 authenticated and authorized by the backend authentication server. 892 Since mutual proof of possession is not the same as mutual 893 authentication, the peer cannot verify authenticator assertions 894 (including the authenticator identity) as a result of this 895 exchange. 897 2.4. Lower Layer Key Hierarchy 899 From the keys exported by the EAP method, two other types of keys may 900 be derived: 902 [3] Keys calculated from exported quantities: AAA-Key. 903 [4] Keys calculated by the Secure Association Protocol from the 904 AAA-Key: TSKs. 906 In order to protect the EAP conversation, methods supporting key 907 derivation typically negotiate a ciphersuite and derive Transient EAP 908 Keys (TEKs) for use with that ciphersuite. The TEKs are stored 909 locally by the EAP method and are not exported. 911 As noted in [RFC3748] Section 7.10, EAP methods generating keys are 912 required to calculate and export the MSK and EMSK, which must be at 913 least 64 octets in length. EAP methods also may export the IV; 914 however, the use of the IV is deprecated. On both the peer and EAP 915 server, the exported MSK is utilized in order to calculate the AAA- 916 Key. Where a backend authentication server is present, the AAA-Key 917 is transported from the backend authentication server to the 918 authenticator within the AAA-Token, using the AAA protocol. 920 Once EAP authentication completes and is successful, the peer and 921 authenticator obtain the AAA-Key and the Secure Association Protocol 922 is run between the peer and authenticator in order to securely 923 negotiate the ciphersuite, derive fresh TSKs used to protect data, 924 and provide mutual proof of possession of the AAA-Key. 926 When the authenticator acts as an endpoint of the EAP conversation 927 rather than a pass-through, EAP methods are implemented on the 928 authenticator as well as the peer. If the EAP method negotiated 929 between the EAP peer and authenticator supports mutual authentication 930 and key derivation, the EAP Master Session Key (MSK) and Extended 931 Master Session Key (EMSK) are derived on the EAP peer and 932 authenticator and exported by the EAP method. In this case, the MSK 933 and EMSK are known only to the peer and authenticator and no other 934 parties. The TEKs and TSKs also reside solely on the peer and 935 authenticator. This is illustrated in Figure 6. As demonstrated in 936 [I-D.ietf-roamops-cert], in this case it is still possible to support 937 roaming between providers, using certificate-based authentication. 939 Where a backend authentication server is utilized, the situation is 940 illustrated in Figure 7. Here the authenticator acts as a pass- 941 through between the EAP peer and a backend authentication server. In 942 this model, the authenticator delegates the access control decision 943 to the backend authentication server, which acts as a Key 944 Distribution Center (KDC). In this case, the authenticator 945 encapsulates EAP packet with a AAA protocol such as RADIUS [RFC3579] 946 or Diameter [I-D.ietf-aaa-eap], and forwards packets to and from the 947 backend authentication server, which acts as the EAP server. Since 948 the authenticator acts as a pass-through, EAP methods reside only on 949 the peer and EAP server As a result, the TEKs, MSK and EMSK are 950 derived on the peer and EAP server. 952 On completion of EAP authentication, EAP methods on the peer and EAP 953 server export the Master Session Key (MSK) and Extended Master 954 Session Key (EMSK). The peer and EAP server then calculate the AAA- 955 Key from the MSK and EMSK, and the backend authentication server 956 sends an Access-Accept to the authenticator, providing the AAA-Key 957 within a protected package known as the AAA-Token. 959 The AAA-Key is then used by the peer and authenticator within the 960 Secure Association Protocol to derive Transient Session Keys (TSKs) 961 required for the negotiated ciphersuite. The TSKs are known only to 962 the peer and authenticator. 964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 965 | | ^ 966 | EAP Method | Local to | 967 | | EAP | 968 | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | | 969 | | TEK | | MSK | |EMSK | |IV | | | 970 | |Derivation | |Derivation | |Derivation | |Derivation | | | 971 | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | | 972 | | | | | V 973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 974 | | | ^ 975 | MSK (64B) | EMSK (64B) | IV (64B) Exported| 976 | | | by | 977 | | | EAP | 978 | V V v 979 | ---+ 980 | AAA-Key Transported | 981 | by AAA | 982 | Protocol | 983 V V 984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 985 | | ^ 986 | TSK Derivation | Lower layer | 987 | [AAA-Key Cache] | Specific | 988 | | V 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 991 Figure 5: Complete Key Hierarchy 993 +-+-+-+-+-+ +-+-+-+-+-+ 994 | | | | 995 | | | | 996 | Cipher- | | Cipher- | 997 | Suite | | Suite | 998 | | | | 999 +-+-+-+-+-+ +-+-+-+-+-+ 1000 ^ ^ 1001 | | 1002 | | 1003 | | 1004 V V 1005 +-+-+-+-+-+ +-+-+-+-+-+ 1006 | | | | 1007 | |===============| | 1008 | |EAP, TEK Deriv.|Authenti-| 1009 | |<------------->| cator | 1010 | | | | 1011 | | Secure Assoc. | | 1012 | peer |<------------->| (EAP | 1013 | |===============| server) | 1014 | | Link layer | | 1015 | | (PPP,IEEE802) | | 1016 | | | | 1017 |MSK,EMSK | |MSK,EMSK | 1018 | (TSKs) | | (TSKs) | 1019 +-+-+-+-+-+ +-+-+-+-+-+ 1020 ^ ^ 1021 | | 1022 | MSK, EMSK | MSK, EMSK 1023 | | 1024 | | 1025 +-+-+-+-+-+ +-+-+-+-+-+ 1026 | | | | 1027 | EAP | | EAP | 1028 | Method | | Method | 1029 | | | | 1030 | (TEKs) | | (TEKs) | 1031 | | | | 1032 +-+-+-+-+-+ +-+-+-+-+-+ 1034 Figure 6: Relationship between EAP peer and authenticator (acting as 1035 an EAP server), where no backend authentication server is present. 1037 +-+-+-+-+-+ +-+-+-+-+-+ 1038 | | | | 1039 | | | | 1040 | Cipher- | | Cipher- | 1041 | Suite | | Suite | 1042 | | | | 1043 +-+-+-+-+-+ +-+-+-+-+-+ 1044 ^ ^ 1045 | | 1046 | | 1047 | | 1048 V V 1049 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 1050 | |===============| |========| | 1051 | |EAP, TEK Deriv.| | | | 1052 | |<-------------------------------->| backend | 1053 | | | |AAA-Key/| | 1054 | | Secure Assoc. | | Name | | 1055 | peer |<------------->|Authenti-|<-------| auth | 1056 | |===============| cator |========| server | 1057 | | Link Layer | | AAA | (EAP | 1058 | | (PPP,IEEE 802)| |Protocol| server) | 1059 | | | | | | 1060 |MSK,EMSK | | MSK | |MSK,EMSK | 1061 | (TSKs) | | (TSKs) | | | 1062 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 1063 ^ ^ 1064 | | 1065 | MSK, EMSK | MSK, EMSK 1066 | | 1067 | | 1068 +-+-+-+-+-+ +-+-+-+-+-+ 1069 | | | | 1070 | EAP | | EAP | 1071 | Method | | Method | 1072 | | | | 1073 | (TEKs) | | (TEKs) | 1074 | | | | 1075 +-+-+-+-+-+ +-+-+-+-+-+ 1077 Figure 7: Pass-through relationship between EAP peer, authenticator 1078 and backend authentication server. 1080 2.5. AAA-Key Derivation and Naming 1082 In existing usage, where a AAA-Key is generated as the result of a 1083 successful EAP authentication with the authenticator, the AAA-Key is 1084 based on the MSK: AAA-Key = MSK(0,63). 1086 In existing usage, the AAA-Key is always derived from the MSK so can 1087 be referred to using the MSK name. 1089 The AAA-Key scope is provided by the concatenation of the EAP peer 1090 name (if securely provided to the authenticator), and the 1091 authenticator name (if securely provided to the peer). 1093 For the purpose of identifying the authenticator to the peer, the 1094 value of the NAS-Identifier attribute is recommended. The 1095 authenticator may include the NAS-Identifier attribute to the AAA 1096 server in an Access-Request, and the authenticator may provide the 1097 NAS-Identifier to the EAP peer. Mechanisms for this include use of 1098 the EAP-Request/Identity (unsecured) or a lower layer mechanism (such 1099 as the 802.11 Beacon/Probe Response). Where the NAS-Identifier is 1100 provided by the authenticator to the peer a secure mechanism is 1101 RECOMMENDED. 1103 For the purpose of identifying the peer to the authenticator, the EAP 1104 peer identifier provided within the EAP method is recommended. It 1105 cannot be assumed that the authenticator is aware of the EAP peer 1106 name used within the method. Therefore alternatives mechanisms need 1107 to be used to provide the EAP peer name to the authenticator. For 1108 example, the AAA server may include the EAP peer name in the User- 1109 Name attribute of the Access-Accept or the peer may provide the 1110 authenticator with its name via a lower layer mechanism. 1112 Absent an explicit binding step within the Secure Association 1113 Protocol, the AAA-Key is not bound to a specific peer or 1114 authenticator port. As a result, the peer or authenticator port over 1115 which the EAP conversation takes place is not included in the AAA-Key 1116 scope. 1118 2.5.1. TSKs 1120 The TSKs are typically named. Their naming is specified in the Secure 1121 Association (phase 2) protocol, so that the correct set of transient 1122 session keys can be identified for processing a given packet. The 1123 scope of the TSKs is negotiated within the Secure Association 1124 Protocol. 1126 TSK creation and deletion operations are typically supported so that 1127 establishment and re-establishment of TSKs can be synchronized 1128 between the parties. 1130 In order to avoid confusion in the case where an EAP peer has more 1131 than one AAA-Key (phase 1b) applicable to establishment of a phase 2 1132 security association, the secure Association protocol needs to 1133 utilize the AAA-Key name so that the appropriate phase 1b keying 1134 material can be identified for use in the Secure Association Protocol 1135 exchange. 1137 3. Security Associations 1139 During EAP authentication and subsequent exchanges, four types of 1140 security associations (SAs) are created: 1142 [1] EAP method SA. This SA is between the peer and EAP server. It 1143 stores state that can be used for "fast reconnect" or other 1144 functionality in some EAP methods. Not all EAP methods create such 1145 an SA. 1147 [2] EAP-Key SA. This is an SA between the peer and EAP server, which 1148 is used to store the keying material exported by the EAP method. 1149 Current EAP server implementations do not retain this SA after the 1150 EAP conversation completes. 1152 [3] AAA SA(s). These SAs are between the authenticator and the backend 1153 authentication server. They permit the parties to mutually 1154 authenticate each other and protect the communications between 1155 them. 1157 [4] Service SA(s). These SAs are between the peer and authenticator, 1158 and they are created as a result of phases 1-2 of the conversation 1159 (see Section 2). 1161 Examples of security associations are provided in Appendix F. 1163 3.1. EAP Method SA (peer - EAP server) 1165 An EAP method may store some state on the peer and EAP server even 1166 after phase 1a has completed. 1168 Typically, this is used for "fast reconnect": the peer and EAP server 1169 can confirm that they are still talking to the same party, perhaps 1170 using fewer round-trips or less computational power. In this case, 1171 the EAP method SA is essentially a cache for performance 1172 optimization, and either party may remove the SA from its cache at 1173 any point. 1175 An EAP method may also keep state in order to support pseudonym-based 1176 identity protection. This is typically a cache as well (the 1177 information can be recreated if the original EAP method SA is lost), 1178 but may be stored for longer periods of time. 1180 The EAP method SA is not restricted to a particular service or 1181 authenticator and is most useful when the peer accesses many 1182 different authenticators. An EAP method is responsible for 1183 specifying how the parties select if an existing EAP method SA should 1184 be used, and if so, which one. Where multiple backend authentication 1185 servers are used, EAP method SAs are not typically synchronized 1186 between them. 1188 EAP method implementations should consider the appropriate lifetime 1189 for the EAP method SA. "Fast reconnect" assumes that the information 1190 required (primarily the keys in the EAP method SA) hasn't been 1191 compromised. In case the original authentication was carried out 1192 using, for instance, a smart card, it may be easier to compromise the 1193 EAP method SA (stored on the PC, for instance), so typically the EAP 1194 method SAs have a limited lifetime. 1196 Contents: 1198 o Implicitly, the EAP method this SA refers to 1199 o Internal (non-exported) cryptographic state 1200 o EAP method SA name 1201 o SA lifetime 1203 3.2. EAP-Key SA 1205 This is an SA between the peer and EAP server, which is used to store 1206 the keying material exported by the EAP method. Current EAP server 1207 implementations do not retain this SA after the EAP conversation 1208 completes. As a result, all keys exported by the EAP method 1209 (including the MSK, EMSK and IV) on the AAA server are discarded and 1210 are not cached. Calculated keys (such as the AAA-Key) are also 1211 discarded and not cached. 1213 3.3. AAA SA(s) (authenticator - backend authentication server) 1215 In order for the authenticator and backend authentication server to 1216 authenticate each other, they need to store some information. 1218 In case the authenticator and backend authentication server are 1219 colocated, and they communicate using local procedure calls or shared 1220 memory, this SA need not necessarily contain any information. 1222 3.4. Service SA(s) (peer - authenticator) 1224 The service SAs store information about the service being provided. 1225 These include the Root service SA and derived unicast and multicast 1226 service SAs. 1228 The Root service SA is established as the result of the completion of 1229 EAP authentication (phase 1a) and AAA-Key derivation or transport 1230 (phase 1b). It includes: 1232 o Service parameters (or at least those parameters 1233 that are still needed) 1234 o On the authenticator, service authorization 1235 information received from the backend authentication 1236 server (or necessary parts of it) 1237 o On the peer, usually locally configured service 1238 authorization information. 1239 o The AAA-Key, if it can be needed again (to refresh 1240 and/or resynchronize other keys or for another reason) 1241 o AAA-Key lifetime 1243 Unicast and (optionally) multicast service SAs are derived from the 1244 Root service SA, via the Secure Association Protocol. In order for 1245 unicast and multicast service SAs and associated TSKs to be 1246 established, it is not necessary for EAP authentication (phase 1a) to 1247 be rerun each time. Instead, the Secure Association Protocol can be 1248 used to mutually prove possession of the AAA-Key and create 1249 associated unicast (phase 2a) and multicast (phase 2b) service SAs 1250 and TSKs, enabling the EAP exchange to be bypassed. Unicast and 1251 multicast service SAs include: 1253 o Service parameters negotiated by the Secure Association Protocol. 1254 o Endpoint identifiers. 1255 o Transient Session Keys used to protect the communication. 1256 o Transient Session Key lifetime. 1258 One function of the Secure Association Protocol is to bind the the 1259 unicast and multicast service SAs and TSKs to endpoint identifiers. 1260 For example, within [IEEE802.11i], the 4-way handshake binds the TSKs 1261 to the MAC addresses of the endpoints; in [IKEv2], the TSKs are bound 1262 to the IP addresses of the endpoints and the negotiated SPI. 1264 It is possible for more than one unicast or multicast service SA to 1265 be derived from a single Root service SA. However, a unicast or 1266 multicast service SA is always descended from only one Root service 1267 SA. Unicast or multicast service SAs descended from the same Root 1268 service SA may utilize the same security parameters (e.g. mode, 1269 ciphersuite, etc.) or they may utilize different parameters. 1271 An EAP peer may be able to negotiate multiple service SAs with a 1272 given authenticator, or may be able to maintain one or more service 1273 SAs with multiple authenticators, depending on the properties of the 1274 media. 1276 Except where explicitly specified by the Secure Association Protocol, 1277 it should not be assumed that the installation of new service SAs 1278 implies deletion of old service SAs. It is possible for multicast 1279 Root service SAs to between the same EAP peer and authenticator; 1280 during a re-key of a unicast or multicast service SA it is possible 1281 for two service SAs to exist during the period between when the new 1282 service SA and corresponding TSKs are calculated and when they are 1283 installed. 1285 Similarly, deletion or creation of a unicast or multicast service SA 1286 does not necessarily imply deletion or creation of related unicast or 1287 multicast service SAs, unless specified by the Secure Association 1288 protocol. For example, a unicast service SA may be rekeyed without 1289 implying a rekey of the multicast service SA. 1291 The deletion of the Root service SA does not necessarily imply the 1292 deletion of the derived unicast and multicast service SAs and 1293 associated TSKs. Failure to mutually prove possession of the AAA-Key 1294 during the Secure Association Protocol exchange need not be grounds 1295 for deletion of the AAA-Key by both parties; the action to be taken 1296 is defined by the Secure Association Protocol. 1298 3.4.1. Sharing service SAs 1300 A single service may be provided by multiple logical or physical 1301 service elements. Each service is responsible for specifying how 1302 changing service elements is handled. Some approaches include: 1304 Transparent sharing 1305 If the service parameters visible to the other party (either peer 1306 or authenticator) do not change, the service can be moved without 1307 requiring cooperation from the other party. 1309 Whether such a move should be supported or used depends on 1310 implementation and administrative considerations. For instance, an 1311 administrator may decide to configure a group of IKEv2/IPsec 1312 gateways in a cluster for high-availability purposes, if the 1313 implementation used supports this. The peer does not necessarily 1314 have any way of knowing when the change occurs. 1316 No sharing 1317 If the service parameters require changing, some changes may 1318 require terminating the old service, and starting a new 1319 conversation from phase 0. This approach is used by all services 1320 for at least some parameters, and it doesn't require any protocol 1321 for transferring the service SA between the service elements. 1323 The service may support keeping the old service element active 1324 while the new conversation takes phase, to decrease the time the 1325 service is not available. 1327 Some sharing 1328 The service may allow changing some parameters by simply agreeing 1329 about the new values. This may involve a similar exchange as in 1330 phase 2, or perhaps a shorter conversation. 1332 This option usually requires some protocol for transferring the 1333 service SA between the elements. An administrator may decide not to 1334 enable this feature at all, and typically the sharing is restricted 1335 to some particular service elements (defined either by a service 1336 parameter, or simple administrative decision). If the old and new 1337 service element do not support such "context transfer", this 1338 approach falls back to the previous option (no transfer). 1340 Services supporting this feature should also consider what changes 1341 require new authorization from the backend authentication server 1342 (see Section 5.2). 1344 Note that these considerations are not limited to service 1345 parameters related to the authenticator--they apply to peer 1346 parameters as well. 1348 4. Key Management 1350 EAP supports key derivation, but not key management. As a result, 1351 key management functionality needs to be provided by the Secure 1352 Association Protocol. This includes: 1354 [a] Generation of fresh transient session keys (TSKs). Where AAA-Key 1355 caching is supported, the EAP peer may initiate a new session using 1356 a AAA-Key that was used in a previous session. Were the TSKs to be 1357 derived from a portion of the AAA-Key, this would result in reuse 1358 of the session keys which could expose the underlying ciphersuite 1359 to attack. As a result, where AAA-Key caching is supported, the 1360 Secure Association Protocol phase is REQUIRED, and MUST provide for 1361 freshness of the TSKs. 1363 [b] Key lifetime determination. EAP does not support negotiation of 1364 key lifetimes, nor does it support rekey without reauthentication. 1365 As a result, the Secure Association Protocol may handle rekey and 1366 determination of the key lifetime. Where key caching is supported, 1367 secure negotiation of key lifetimes is RECOMMENDED. Lower layers 1368 that support rekey, but not key caching, may not require key 1369 lifetime negotiation. To take an example from IKE, the difference 1370 between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes were 1371 negotiated. In IKEv2, each end of the SA is responsible for 1372 enforcing its own lifetime policy on the SA and rekeying the SA 1373 when necessary. 1375 [c] Key resynchronization. It is possible for the peer or 1376 authenticator to reboot or reclaim resources, clearing portions or 1377 all of the key cache. Therefore, key lifetime negotiation cannot 1378 guarantee that the key cache will remain synchronized, and the peer 1379 may not be able to determine before attempting to use a AAA-Key 1380 whether it exists within the authenticator cache. It is therefore 1381 RECOMMENDED for the Secure Association Protocol to provide a 1382 mechanism for key state resynchronization. Since in this situation 1383 one or more of the parties initially do not possess a key with 1384 which to protect the resynchronization exchange, securing this 1385 mechanism may be difficult. 1387 [d] Key selection. Where key caching is supported, it may be possible 1388 for the EAP peer and authenticator to share more than one key of a 1389 given type. As a result, the Secure Association Protocol needs to 1390 support key selection, using the EAP Key Naming scheme described in 1391 this document. 1393 [e] Key scope determination. Since the Discovery phase is handled out- 1394 of-band, EAP does not provide a mechanism by which the peer can 1395 determine the authenticator identity. As a result, where the 1396 authenticator has multiple ports and AAA-Key caching is supported, 1397 the EAP peer may not be able to determine the scope of validity of 1398 a AAA-Key. Similarly, where the EAP peer has multiple ports, the 1399 authenticator may not be able to determine whether a peer has 1400 authorization to use a particular AAA-Key. To allow key scope 1401 determination, the lower layer SHOULD provide a mechanism by which 1402 the peer can determine the scope of the AAA-Key cache on each 1403 authenticator, and by which the authenticator can determine the 1404 scope of the AAA-Key cache on a peer. 1406 4.1. Key Caching 1408 In existing implementations, key caching may be supported on the EAP 1409 peer and authenticator but not on the backend server. Where 1410 explicitly supported by the lower layer, the EAP peer and 1411 authenticator MAY cache the AAA-Key and/or TSKs. The structure of 1412 the key cache on the peer and authenticator is defined by the lower 1413 layer. Unless specified by the lower layer, the EAP peer and 1414 authenticator MUST assume that peers and authenticators do not cache 1415 the AAA-Key or TSKs. 1417 In existing AAA server implementations, all keys exported by EAP 1418 methods (including the MSK, EMSK and IV) and calculated keys (e.g. 1419 AAA-Key) are not cached and are lost after EAP authentication 1420 completes: 1422 [1] In order to avoid key reuse, on the EAP server, transported keys 1423 are deleted once they are sent. An EAP server MUST NOT retain keys 1424 that it has previously sent to the authenticator. For example, an 1425 EAP server that has transported a AAA-Key based on the MSK MUST 1426 delete the MSK, and no keys may be derived from the MSK from that 1427 point forward by the server. 1429 [2] Keys which are not transported, such as the EMSK, are also deleted 1430 by existing implementations. 1432 4.2. Parent-Child Relationships 1434 When keying material exported by EAP methods expires, all keying 1435 material derived from the exported keying material expires, including 1436 the AAA-Key and TSKs. 1438 When an EAP reauthentication takes place, new keying material is 1439 derived and exported by the EAP method, which eventually results in 1440 replacement of calculated keys, including the AAA-Key and TSKs. 1442 As a result, while the lifetime of calculated keys can be less than 1443 or equal that of the exported keys they are derived from, it cannot 1444 be greater. For example, TSK rekey may occur prior to EAP 1445 reauthentication. 1447 Failure to mutually prove possession of the AAA-Key during the Secure 1448 Association Protocol exchange need not be grounds for deletion of the 1449 AAA-Key by both parties; rate-limiting Secure Association Protocol 1450 exchanges could be used to prevent a brute force attack. 1452 4.3. Local Key Lifetimes 1454 The Transient EAP Keys (TEKs) are session keys used to protect the 1455 EAP conversation. The TEKs are internal to the EAP method and are 1456 not exported. TEKs are typically created during an EAP conversation, 1457 used until the end of the conversation and then discarded. However, 1458 methods may rekey TEKs during a conversation. 1460 When using TEKs within an EAP conversation or across conversations, 1461 it is necessary to ensure that replay protection and key separation 1462 requirements are fulfilled. For instance, if a replay counter is 1463 used, TEK rekey MUST occur prior to wrapping of the counter. 1464 Similarly, TSKs MUST remain cryptographically separate from TEKs 1465 despite TEK rekeying or caching. This prevents TEK compromise from 1466 leading directly to compromise of the TSKs and vice versa. 1468 EAP methods may cache local keying material which may persist for 1469 multiple EAP conversations when fast reconnect is used [RFC 3748]. 1470 For example, EAP methods based on TLS (such as EAP-TLS [RFC2716]) 1471 derive and cache the TLS Master Secret, typically for substantial 1472 time periods. The lifetime of other local keying material calculated 1473 within the EAP method is defined by the method. Note that in 1474 general, when using fast reconnect, there is no guarantee to that the 1475 original long-term credentials are still in the possession of the 1476 peer. For instance, a card hold holding the private key for EAP-TLS 1477 may have been removed. EAP servers SHOULD also verify that the long- 1478 term credentials are still valid, such as by checking that 1479 certificate used in the original authentication has not yet expired. 1481 4.4. Exported and Calculated Key Lifetimes 1483 All EAP methods generating keys are required to generate the MSK and 1484 EMSK, and may optionally generate the IV. However, EAP, defined in 1485 [RFC3748], does not support the negotiation of lifetimes for exported 1486 keying material such as the MSK, EMSK and IV. 1488 Several mechanisms exist for managing key lifetimes: 1490 [a] AAA attributes. AAA protocols such as RADIUS [RFC2865] and 1491 Diameter [I-D.ietf-aaa-eap] support the Session-Timeout attribute. 1492 The Session-Timeout value represents the maximum lifetime of the 1493 exported keys, and all keys calculated from it, on the 1494 authenticator. Since existing AAA servers do not cache keys 1495 exported by EAP methods, or keys calculated from exported keys, the 1496 value of the Session-Timeout attribute has no bearing on the key 1497 lifetime within the AAA server. 1499 On the authenticator, where EAP is used for authentication, the 1500 Session-Timeout value represents the maximum session time prior to 1501 re-authentication, as described in [RFC3580]. Where EAP is used 1502 for pre-authentication, the session may not start until some future 1503 time, or may never occur. Nevertheless, the Session-Timeout value 1504 represents the time after which the AAA-Key, and all keys 1505 calculated from it, will have expired on the authenticator. If the 1506 session subsequently starts, re-authentication will be initiated 1507 once the Session-Time has expired. If the session never started, 1508 or started and ended, the AAA-Key and all keys calculated from it 1509 will be expired by the authenticator prior to the future time 1510 indicated by Session-Timeout. 1512 Since the TSK lifetime is often determined by authenticator 1513 resources, the AAA server has no insight into the TSK derivation 1514 process, and by the principle of ciphersuite independence, it is 1515 not appropriate for the AAA server to manage any aspect of the TSK 1516 derivation process, including the TSK lifetime. 1518 [b] Lower layer mechanisms. While AAA attributes can communicate the 1519 maximum exported key lifetime, this only serves to synchronize the 1520 key lifetime between the backend authentication server and the 1521 authenticator. Lower layer mechanisms such as the Secure 1522 Association Protocol can then be used to enable the lifetime of 1523 exported and calculated keys to be negotiated between the peer and 1524 authenticator. 1526 Where TSKs are established as the result of a Secure Association 1527 Protocol exchange, it is RECOMMENDED that the Secure Association 1528 Protocol include support for TSK resynchronization. Where the TSK 1529 is taken from the AAA-Key, there is no need to manage the TSK 1530 lifetime as a separate parameter, since the TSK lifetime and AAA- 1531 Key lifetime are identical. 1533 [c] System defaults. Where the EAP method does not support the 1534 negotiation of the exported key lifetime, and a key lifetime 1535 negotiation mechanism is not provided by the lower lower, there may 1536 be no way for the peer to learn the exported key lifetime. In this 1537 case it is RECOMMENDED that the peer assume a default value of the 1538 exported key lifetime; 8 hours is recommended. Similarly, the 1539 lifetime of calculated keys can also be managed as a system 1540 parameter on the authenticator. 1542 [d] Method specific negotiation within EAP. While EAP itself does not 1543 support lifetime negotiation, it would be possible to specify 1544 methods that do. However, systems that rely on such negotiation 1545 for exported keys would only function with these methods. As a 1546 result, it is NOT RECOMMENDED to use this approach as the sole way 1547 to determine key lifetimes. 1549 4.5. Key cache synchronization 1551 Issues arise when attempting to synchronize the key cache on the peer 1552 and authenticator. Lifetime negotiation alone cannot guarantee key 1553 cache synchronization. 1555 One problem is that the AAA protocol cannot guarantee synchronization 1556 of key lifetimes between the peer and authenticator. Where the 1557 Secure Association Protocol is not run immediately after EAP 1558 authentication, the exported and calculated key lifetimes will not be 1559 known by the peer during the hiatus. Where EAP pre-authentication 1560 occurs, this can leave the peer uncertain whether a subsequent 1561 attempt to use the exported keys will prove successful. 1563 However, even where the Secure Association Protocol is run 1564 immediately after EAP, it is still possible for the authenticator to 1565 reclaim resources if the created key state is not immediately 1566 utilized. 1568 The lower layer may utilize Discovery mechanisms to assist in this. 1569 For example, the authenticator manages the AAA-Key cache by deleting 1570 the oldest AAA-Key first (LIFO), the relative creation time of the 1571 last AAA-Key to be deleted could be advertised with the Discovery 1572 phase, enabling the peer to determine whether a given AAA-Key had 1573 been expired from the authenticator key cache prematurely. 1575 4.6. Key Scope 1577 As described in Section 2.5, in existing applications the AAA-Key is 1578 derived from the MSK by the EAP peer and server, and is used as the 1579 root of the ciphersuite-specific key hierarchy. Where a backend 1580 authentication server is present, the AAA-Key is transported from the 1581 EAP server to the authenticator; where it is not present, the AAA-Key 1582 is calculated on the authenticator. 1584 Regardless of how many sessions are initiated using it, the AAA-Key 1585 scope is between the EAP peer that calculates it, and the 1586 authenticator that either calculates it (where no backend 1587 authenticator is present) or receives it from the server (where a 1588 backend authenticator server is present). 1590 It should be understood that an authenticator or peer: 1592 [a] may contain multiple physical ports; 1593 [b] may advertise itself as multiple "virtual" authenticators 1594 or peers; 1595 [c] may utilize multiple CPUs; 1596 [d] may support clustering services for load balancing or failover. 1598 As illustrated in Figure 1, an EAP peer with multiple ports may be 1599 attached to one or more authenticators, each with multiple ports. 1600 Where the peer and authenticator identify themselves using a port 1601 identifier such as a link layer address, it may not be obvious to the 1602 peer which authenticator ports are associated with which 1603 authenticators. Similarly, it may not be obvious to the 1604 authenticator which peer ports are associated with which peers. As a 1605 result, the peer and authenticator may not be able to determine the 1606 scope of the AAA-Key. 1608 When a single physical authenticator advertises itself as multiple 1609 "virtual authenticators", the EAP peer and authenticator also may not 1610 be able to agree on the scope of the AAA-Key, creating a security 1611 vulnerability. For example, the peer may assume that the "virtual 1612 authenticators" are distinct and do not share a key cache, whereas, 1613 depending on the architecture of the physical AP, a shared key cache 1614 may or may not be implemented. 1616 Where the AAA-Key is shared between "virtual authenticators" an 1617 attacker acting as a peer could authenticate with the "Guest" 1618 "virtual authenticator" and derive a AAA-Key. If the virtual 1619 authenticators share a key cache, then the peer can utilize the AAA- 1620 Key derived for the "Guest" network to obtain access to the 1621 "Corporate Intranet" virtual authenticator. 1623 Several measures are recommended to address these issues: 1625 [a] Authenticators are REQUIRED to cache associated authorizations 1626 along with the AAA-Key and apply authorizations consistently. This 1627 ensures that an attacker cannot obtain elevated privileges even 1628 where the AAA-Key cache is shared between "virtual authenticators". 1630 [b] It is RECOMMENDED that physical authenticators maintain separate 1631 AAA-Key caches for each "virtual authenticator". 1633 [c] It is RECOMMENDED that each "virtual authenticator" identify itself 1634 distinctly to the AAA server, such as by utilizing a distinct NAS- 1635 identifier attribute. This enables the AAA server to utilize a 1636 separate credential to authenticate each "virtual authenticator". 1638 [d] It is RECOMMENDED that Secure Association Protocols identify peers 1639 and authenticators unambiguously, without incorporating implicit 1640 assumptions about peer and authenticator architectures. Using 1641 port-specific MAC addresses as identifiers is NOT RECOMMENDED where 1642 peers and authenticators may support multiple ports. 1644 [e] The AAA server and authenticator MAY implement additional 1645 attributes in order to further restrict the AAA-Key scope. For 1646 example, in 802.11, the AAA server may provide the authenticator 1647 with a list of authorized Called or Calling-Station-Ids and/or 1648 SSIDs for which the AAA-Key is valid. 1650 [f] Where the AAA server provides attributes restricting the key scope, 1651 it is RECOMMENDED that restrictions be securely communicated by the 1652 authenticator to the peer. This can be accomplished using the 1653 Secure Association Protocol, but also can be accomplished via the 1654 EAP method or the lower layer. 1656 4.7. Key Strength 1658 In order to guard against brute force attacks, EAP methods deriving 1659 keys need to be capable of generating keys with an appropriate 1660 effective symmetric key strength. In order to ensure that key 1661 generation is not the weakest link, it is RECOMMENDED that EAP 1662 methods utilizing public key cryptography choose a public key that 1663 has a cryptographic strength meeting the symmetric key strength 1664 requirement. 1666 As noted in [RFC3766] Section 5, this results in the following 1667 required RSA or DH module and DSA subgroup size in bits, for a given 1668 level of attack resistance in bits: 1670 Attack Resistance RSA or DH Modulus DSA subgroup 1671 (bits) size (bits) size (bits) 1672 ----------------- ----------------- ------------ 1673 70 947 128 1674 80 1228 145 1675 90 1553 153 1676 100 1926 184 1677 150 4575 279 1678 200 8719 373 1679 250 14596 475 1681 4.8. Key Wrap 1683 As described in [RFC3579] Section 4.3, known problems exist in the 1684 key wrap specified in [RFC2548]. Where the same RADIUS shared secret 1685 is used by a PAP authenticator and an EAP authenticator, there is a 1686 vulnerability to known plaintext attack. Since RADIUS uses the 1687 shared secret for multiple purposes, including per-packet 1688 authentication, attribute hiding, considerable information is exposed 1689 about the shared secret with each packet. This exposes the shared 1690 secret to dictionary attacks. MD5 is used both to compute the RADIUS 1691 Response Authenticator and the Message-Authenticator attribute, and 1692 some concerns exist relating to the security of this hash 1693 [MD5Attack]. 1695 As discussed in [RFC3579] Section 4.3, the security vulnerabilities 1696 of RADIUS are extensive, and therefore development of an alternative 1697 key wrap technique based on the RADIUS shared secret would not 1698 substantially improve security. As a result, [RFC3759] Section 4.2 1699 recommends running RADIUS over IPsec. The same approach is taken in 1700 Diameter EAP [I-D.ietf-aaa-eap], which defines cleartext key 1701 attributes, to be protected by IPsec or TLS. 1703 Where an untrusted AAA intermediary is present (such as a RADIUS 1704 proxy or a Diameter agent), and data object security is not used, the 1705 AAA-Key may be recovered by an attacker in control of the untrusted 1706 intermediary. Possession of the AAA-Key enables decryption of data 1707 traffic sent between the peer and a specific authenticator. However, 1708 as long as a AAA-Key or keys derived from it is only utilized by a 1709 single authenticator, compromise of the AAA-Key does not enable an 1710 attacker to impersonate the peer to another authenticator. 1711 Vulnerability to an untrusted AAA intermediary can be mitigated by 1712 implementation of redirect functionality, as described in [RFC3588] 1713 and [I-D.ietf-aaa-eap]. 1715 5. Handoff Vulnerabilities 1717 With EAP, a number of mechanisms are be utilized in order to reduce 1718 the latency of handoff between authenticators. One such mechanism is 1719 EAP pre-authentication, in which EAP is utilized to pre-establish a 1720 AAA-Key on an authenticator prior to arrival of the peer. Another 1721 such mechanism is AAA-Key caching, in which an EAP peer can re-attach 1722 to an authenticator without having to re-authenticate using EAP. Yet 1723 another mechanism is context transfer, such as is defined in 1724 [IEEE-802.11F] and [CTP]. These mechanisms introduce new security 1725 vulnerabilities, as discussed in the sections that follow. 1727 5.1. Authorization 1729 In a typical network access scenario (dial-in, wireless LAN, etc.) 1730 access control mechanisms are typically applied. These mechanisms 1731 include user authentication as well as authorization for the offered 1732 service. 1734 As a part of the authentication process, the AAA network determines 1735 the user's authorization profile. The user authorizations are 1736 transmitted by the backend authentication server to the EAP 1737 authenticator (also known as the Network Access Server or 1738 authenticator) included with the AAA-Token, which also contains the 1739 AAA-Key, in Phase 1b of the EAP conversation. Typically, the profile 1740 is determined based on the user identity, but a certificate presented 1741 by the user may also provide authorization information. 1743 The backend authentication server is responsible for making a user 1744 authorization decision, answering the following questions: 1746 [a] Is this a legitimate user for this particular network? 1748 [b] Is this user allowed the type of access he or she is requesting? 1750 [c] Are there any specific parameters (mandatory tunneling, bandwidth, 1751 filters, and so on) that the access network should be aware of for 1752 this user? 1754 [d] Is this user within the subscription rules regarding time of day? 1755 [e] Is this user within his limits for concurrent sessions? 1757 [f] Are there any fraud, credit limit, or other concerns that indicate 1758 that access should be denied? 1760 While the authorization decision is in principle simple, the process 1761 is complicated by the distributed nature of AAA decision making. 1762 Where brokering entities or proxies are involved, all of the AAA 1763 devices in the chain from the authenticator to the home AAA server 1764 are involved in the decision. For instance, a broker can disallow 1765 access even if the home AAA server would allow it, or a proxy can add 1766 authorizations (e.g., bandwidth limits). 1768 Decisions can be based on static policy definitions and profiles as 1769 well as dynamic state (e.g. time of day or limits on the number of 1770 concurrent sessions). In addition to the Accept/Reject decision made 1771 by the AAA chain, parameters or constraints can be communicated to 1772 the authenticator. 1774 The criteria for Accept/Reject decisions or the reasons for choosing 1775 particular authorizations are typically not communicated to the 1776 authenticator, only the final result. As a result, the authenticator 1777 has no way to know what the decision was based on. Was a set of 1778 authorization parameters sent because this service is always provided 1779 to the user, or was the decision based on the time/day and the 1780 capabilities of the requesting authenticator device? 1782 5.2. Correctness 1784 When the AAA exchange is bypassed via use of techniques such as AAA- 1785 Key caching, this creates challenges in ensuring that authorization 1786 is properly handled. These include: 1788 [a] Consistent application of session time limits. Bypassing AAA 1789 should not automatically increase the available session time, 1790 allowing a user to endlessly extend their network access by 1791 changing the point of attachment. 1793 [b] Avoidance of privilege elevation. Bypassing AAA should not result 1794 in a user being granted access to services which they are not 1795 entitled to. 1797 [c] Consideration of dynamic state. In situations in which dynamic 1798 state is involved in the access decision (day/time, simultaneous 1799 session limit) it should be possible to take this state into 1800 account either before or after access is granted. Note that 1801 consideration of network-wide state such as simultaneous session 1802 limits can typically only be taken into account by the backend 1803 authentication server. 1805 [d] Encoding of restrictions. Since a authenticator may not be aware 1806 of the criteria considered by a backend authentication server when 1807 allowing access, in order to ensure consistent authorization during 1808 a fast handoff it may be necessary to explicitly encode the 1809 restrictions within the authorizations provided in the AAA-Token. 1811 [e] State validity. The introduction of fast handoff should not render 1812 the authentication server incapable of keeping track of network- 1813 wide state. 1815 A handoff mechanism capable of addressing these concerns is said to 1816 be "correct". One condition for correctness is as follows: For a 1817 handoff to be "correct" it MUST establish on the new device the same 1818 context as would have been created had the new device completed a AAA 1819 conversation with the authentication server. 1821 A properly designed handoff scheme will only succeed if it is 1822 "correct" in this way. If a successful handoff would establish 1823 "incorrect" state, it is preferable for it to fail, in order to avoid 1824 creation of incorrect context. 1826 Some backend authentication server and authenticator configurations 1827 are incapable of meeting this definition of "correctness". For 1828 example, if the old and new device differ in their capabilities, it 1829 may be difficult to meet this definition of correctness in a handoff 1830 mechanism that bypasses AAA. Backend authentication servers often 1831 perform conditional evaluation, in which the authorizations returned 1832 in an Access-Accept message are contingent on the authenticator or on 1833 dynamic state such as the time of day or number of simultaneous 1834 sessions. For example, in a heterogeneous deployment, the backend 1835 authentication server might return different authorizations depending 1836 on the authenticator making the request, in order to make sure that 1837 the requested service is consistent with the authenticator 1838 capabilities. 1840 If differences between the new and old device would result in the 1841 backend authentication server sending a different set of messages to 1842 the new device than were sent to the old device, then if the handoff 1843 mechanism bypasses AAA, then the handoff cannot be carried out 1844 correctly. 1846 For example, if some authenticator devices within a deployment 1847 support dynamic VLANs while others do not, then attributes present in 1848 the Access-Request (such as the authenticator-IP-Address, 1849 authenticator-Identifier, Vendor-Identifier, etc.) could be examined 1850 to determine when VLAN attributes will be returned, as described in 1852 [RFC3580]. VLAN support is defined in [IEEE-802.1Q]. If a handoff 1853 bypassing the backend authentication server were to occur between a 1854 authenticator supporting dynamic VLANs and another authenticator 1855 which does not, then a guest user with access restricted to a guest 1856 VLAN could be given unrestricted access to the network. 1858 Similarly, in a network where access is restricted based on the day 1859 and time, Service Set Identifier (SSID), Calling-Station-Id or other 1860 factors, unless the restrictions are encoded within the 1861 authorizations, or a partial AAA conversation is included, then a 1862 handoff could result in the user bypassing the restrictions. 1864 In practice, these considerations limit the situations in which fast 1865 handoff mechanisms bypassing AAA can be expected to be successful. 1866 Where the deployed devices implement the same set of services, it may 1867 be possible to do successful handoffs within such mechanisms. 1868 However, where the supported services differ between devices, the 1869 handoff may not succeed. For example, [RFC2865] section 1.1 states: 1871 "A authenticator that does not implement a given service MUST NOT 1872 implement the RADIUS attributes for that service. For example, a 1873 authenticator that is unable to offer ARAP service MUST NOT 1874 implement the RADIUS attributes for ARAP. A authenticator MUST 1875 treat a RADIUS access-accept authorizing an unavailable service as 1876 an access-reject instead." 1878 Note that this behavior only applies to attributes that are known, 1879 but not implemented. For attributes that are unknown, [RFC2865] 1880 Section 5 states: 1882 "A RADIUS server MAY ignore Attributes with an unknown Type. A 1883 RADIUS client MAY ignore Attributes with an unknown Type." 1885 In order to perform a correct handoff, if a new device is provided 1886 with RADIUS context for a known but unavailable service, then it MUST 1887 process this context the same way it would handle a RADIUS Access- 1888 Accept requesting an unavailable service. This MUST cause the 1889 handoff to fail. However, if a new device is provided with RADIUS 1890 context that indicates an unknown attribute, then this attribute MAY 1891 be ignored. 1893 Although it may seem somewhat counter-intuitive, failure is indeed 1894 the "correct" result where a known but unsupported service is 1895 requested. Presumably a correctly configured backend authentication 1896 server would not request that a device carry out a service that it 1897 does not implement. This implies that if the new device were to 1898 complete a AAA conversation that it would be likely to receive 1899 different service instructions. In such a case, failure of the 1900 handoff is the desired result. This will cause the new device to go 1901 back to the AAA server in order to receive the appropriate service 1902 definition. 1904 In practice, this implies that handoff mechanisms which bypass AAA 1905 are most likely to be successful within a homogeneous device 1906 deployment within a single administrative domain. For example, it 1907 would not be advisable to carry out a fast handoff bypassing AAA 1908 between a authenticator providing confidentiality and another 1909 authenticator that does not support this service. The correct result 1910 of such a handoff would be a failure, since if the handoff were 1911 blindly carried out, then the user would be moved from a secure to an 1912 insecure channel without permission from the backend authentication 1913 server. Thus the definition of a "known but unsupported service" 1914 MUST encompass requests for unavailable security services. This 1915 includes vendor-specific attributes related to security, such as 1916 those described in [RFC2548]. 1918 6. Security Considerations 1920 6.1. Security Terminology 1922 "Cryptographic binding", "Cryptographic separation", "Key strength" 1923 and "Mutual authentication" are defined in [RFC3748] and are used 1924 with the same meaning here. 1926 6.2. Threat Model 1928 The EAP threat model is described in [RFC3748] Section 7.1. In order 1929 to address these threats, EAP relies on the security properties of 1930 EAP methods (known as "security claims", described in [RFC3784] 1931 Section 7.2.1). EAP method requirements for application such as 1932 Wireless LAN authentication are described in [RFC4017]. 1934 The RADIUS threat model is described in [RFC3579] Section 4.1, and 1935 responses to these threats are described in [RFC3579] Sections 4.2 1936 and 4.3. Among other things, [RFC3579] Section 4.2 recommends the 1937 use of IPsec ESP with non-null transform to provide per-packet 1938 authentication and confidentiality, integrity and replay protection 1939 for RADIUS/EAP. 1941 Given the existing documentation of EAP and AAA threat models and 1942 responses, there is no need to duplicate that material here. 1943 However, there are many other system-level threats no covered in 1944 these document which have not been described or analyzed elsewhere. 1945 These include: 1947 [1] An attacker may try to modify or spoof Secure Association Protocol 1948 packets. 1950 [2] An attacker compromising an authenticator may provide incorrect 1951 information to the EAP peer and/or server via out-of-band 1952 mechanisms (such as via a AAA or lower layer protocol). This 1953 includes impersonating another authenticator, or providing 1954 inconsistent information to the peer and EAP server. 1956 [3] An attacker may attempt to perform downgrading attacks on the 1957 ciphersuite negotiation within the Secure Association Protocol in 1958 order to ensure that a weaker ciphersuite is used to protect data. 1960 Depending on the lower layer, these attacks may be carried out 1961 without requiring physical proximity. 1963 In order to address these threats, [Housley] describes the mandatory 1964 system security properties: 1966 Algorithm independence 1967 Wherever cryptographic algorithms are chosen, the algorithms must 1968 be negotiable, in order to provide resilient against compromise of 1969 a particular algorithm. Algorithm independence must be 1970 demonstrated within all aspects of the system, including within 1971 EAP, AAA and the Secure Association Protocol. However, for 1972 interoperability, at least one suite of algorithms MUST be 1973 implemented. 1975 Strong, fresh session keys 1976 Session keys must be demonstrated to be strong and fresh in all 1977 circumstances, while at the same time retaining algorithm 1978 independence. 1980 Replay protection 1981 All protocol exchanges must be replay protected. This includes 1982 exchanges within EAP, AAA, and the Secure Association Protocol. 1984 Authentication 1985 All parties need to be authenticated. The confidentiality of the 1986 authenticator must be maintained. No plaintext passwords are 1987 allowed. 1989 Authorization 1990 EAP peer and authenticator authorization must be performed. 1992 Session keys 1993 Confidentiality of session keys must be maintained. 1995 Ciphersuite negotiation 1996 The selection of the "best" ciphersuite must be securely confirmed. 1998 Unique naming 1999 Session keys must be uniquely named. 2001 Domino effect 2002 Compromise of a single authenticator cannot compromise any other 2003 part of the system, including session keys and long-term secrets. 2005 Key binding 2006 The key must be bound to the appropriate context. 2008 6.3. Security Analysis 2010 Figure 8 illustrates the relationship between the peer, authenticator 2011 and backend authentication server. 2013 EAP peer 2014 /\ 2015 / \ 2016 Protocol: EAP / \ Protocol: Secure Association 2017 Auth: Mutual / \ Auth: Mutual 2018 Unique keys: / \ Unique keys: TSKs 2019 TEKs,EMSK / \ 2020 / \ 2021 EAP server +--------------+ Authenticator 2022 Protocol: AAA 2023 Auth: Mutual 2024 Unique key: AAA session key 2026 Figure 8: Relationship between peer, authenticator and auth. server 2028 The peer and EAP server communicate using EAP [RFC3748]. The 2029 security properties of this communication are largely determined by 2030 the chosen EAP method. Method security claims are described in 2031 [RFC3748] Section 7.2. These include the key strength, protected 2032 ciphersuite negotiation, mutual authentication, integrity protection, 2033 replay protection, confidentiality, key derivation, key strength, 2034 dictionary attack resistance, fast reconnect, cryptographic binding, 2035 session independence, fragmentation and channel binding claims. At a 2036 minimum, methods claiming to support key derivation must also support 2037 mutual authentication. As noted in [RFC3748] Section 7.10: 2039 EAP Methods deriving keys MUST provide for mutual authentication 2040 between the EAP peer and the EAP Server. 2042 Ciphersuite independence is also required: 2044 Keying material exported by EAP methods MUST be independent of the 2045 ciphersuite negotiated to protect data. 2047 In terms of key strength and freshness, [RFC3748] Section 10 says: 2049 EAP methods SHOULD ensure the freshness of the MSK and EMSK even 2050 in cases where one party may not have a high quality random number 2051 generator.... In order to preserve algorithm independence, EAP 2052 methods deriving keys SHOULD support (and document) the protected 2053 negotiation of the ciphersuite used to protect the EAP 2054 conversation between the peer and server... In order to enable 2055 deployments requiring strong keys, EAP methods supporting key 2056 derivation SHOULD be capable of generating an MSK and EMSK, each 2057 with an effective key strength of at least 128 bits. 2059 The authenticator and backend authentication server communicate using 2060 a AAA protocol such as RADIUS [RFC3579] or Diameter [I-D.ietf-aaa- 2061 eap]. As noted in [RFC3588] Section 13, Diameter must be protected 2062 by either IPsec ESP with non-null transform or TLS. As a result, 2063 Diameter requires per-packet integrity and confidentiality. Replay 2064 protection must be supported. For RADIUS, [RFC3579] Section 4.2 2065 recommends that RADIUS be protected by IPsec ESP with a non-null 2066 transform, and where IPsec is implemented replay protection must be 2067 supported. 2069 The peer and authenticator communicate using the Secure Association 2070 Protocol. 2072 As noted in the figure, each party in the exchange mutually 2073 authenticates with each of the other parties, and derives a unique 2074 key. All parties in the diagram have access to the AAA-Key. 2076 The EAP peer and backend authentication server mutually authenticate 2077 via the EAP method, and derive the TEKs and EMSK which are known only 2078 to them. The TEKs are used to protect some or all of the EAP 2079 conversation between the peer and authenticator, so as to guard 2080 against modification or insertion of EAP packets by an attacker. The 2081 degree of protection afforded by the TEKs is determined by the EAP 2082 method; some methods may protect the entire EAP packet, including the 2083 EAP header, while other methods may only protect the contents of the 2084 Type-Data field, defined in [RFC3748]. 2086 Since EAP is spoken only between the EAP peer and server, if a 2087 backend authentication server is present then the EAP conversation 2088 does not provide mutual authentication between the peer and 2089 authenticator, only between the EAP peer and EAP server (backend 2090 authentication server). As a result, mutual authentication between 2091 the peer and authenticator only occurs where a Secure Association 2092 protocol is used, such the unicast and group key derivation handshake 2093 supported in [IEEE-802.11i]. This means that absent use of a secure 2094 Association Protocol, from the point of view of the peer, EAP mutual 2095 authentication only proves that the authenticator is trusted by the 2096 backend authentication server; the identity of the authenticator is 2097 not confirmed. 2099 Utilizing the AAA protocol, the authenticator and backend 2100 authentication server mutually authenticate and derive session keys 2101 known only to them, used to provide per-packet integrity and replay 2102 protection, authentication and confidentiality. The AAA-Key is 2103 distributed by the backend authentication server to the authenticator 2104 over this channel, bound to attributes constraining its usage, as 2105 part of the AAA-Token. The binding of attributes to the AAA-Key 2106 within a protected package is important so the authenticator 2107 receiving the AAA-Token can determine that it has not been 2108 compromised, and that the keying material has not been replayed, or 2109 mis-directed in some way. 2111 The security properties of the EAP exchange are dependent on each leg 2112 of the triangle: the selected EAP method, AAA protocol and the Secure 2113 Association Protocol. 2115 Assuming that the AAA protocol provides protection against rogue 2116 authenticators forging their identity, then the AAA-Token can be 2117 assumed to be sent to the correct authenticator, and where it is 2118 wrapped appropriately, it can be assumed to be immune to compromise 2119 by a snooping attacker. 2121 Where an untrusted AAA intermediary is present, the AAA-Token must 2122 not be provided to the intermediary so as to avoid compromise of the 2123 AAA-Token. This can be avoided by use of re-direct as defined in 2124 [RFC3588]. 2126 When EAP is used for authentication on PPP or wired IEEE 802 2127 networks, it is typically assumed that the link is physically secure, 2128 so that an attacker cannot gain access to the link, or insert a rogue 2129 device. EAP methods defined in [RFC3748] reflect this usage model. 2130 These include EAP MD5, as well as One-Time Password (OTP) and Generic 2131 Token Card. These methods support one-way authentication (from EAP 2132 peer to authenticator) but not mutual authentication or key 2133 derivation. As a result, these methods do not bind the initial 2134 authentication and subsequent data traffic, even when the the 2135 ciphersuite used to protect data supports per-packet authentication 2136 and integrity protection. As a result, EAP methods not supporting 2137 mutual authentication are vulnerable to session hijacking as well as 2138 attacks by rogue devices. 2140 On wireless networks such as IEEE 802.11 [IEEE-802.11], these attacks 2141 become easy to mount, since any attacker within range can access the 2142 wireless medium, or act as an access point. As a result, new 2143 ciphersuites have been proposed for use with wireless LANs 2144 [IEEE-802.11i] which provide per-packet authentication, integrity and 2145 replay protection. In addition, mutual authentication and key 2146 derivation, provided by methods such as EAP-TLS [RFC2716] are 2147 required [IEEE-802.11i], so as to address the threat of rogue 2148 devices, and provide keying material to bind the initial 2149 authentication to subsequent data traffic. 2151 If the selected EAP method does not support mutual authentication, 2152 then the peer will be vulnerable to attack by rogue authenticators 2153 and backend authentication servers. If the EAP method does not derive 2154 keys, then TSKs will not be available for use with a negotiated 2155 ciphersuite, and there will be no binding between the initial EAP 2156 authentication and subsequent data traffic, leaving the session 2157 vulnerable to hijack. 2159 If the backend authentication server does not protect against 2160 authenticator masquerade, or provide the proper binding of the AAA- 2161 Key to the session within the AAA-Token, then one or more AAA-Keys 2162 may be sent to an unauthorized party, and an attacker may be able to 2163 gain access to the network. If the AAA-Token is provided to an 2164 untrusted AAA intermediary, then that intermediary may be able to 2165 modify the AAA-Key, or the attributes associated with it, as 2166 described in [RFC2607]. 2168 If the Secure Association Protocol does not provide mutual proof of 2169 possession of the AAA-Key material, then the peer will not have 2170 assurance that it is connected to the correct authenticator, only 2171 that the authenticator and backend authentication server share a 2172 trust relationship (since AAA protocols support mutual 2173 authentication). This distinction can become important when multiple 2174 authenticators receive AAA-Keys from the backend authentication 2175 server, such as where fast handoff is supported. If the TSK 2176 derivation does not provide for protected ciphersuite and 2177 capabilities negotiation, then downgrade attacks are possible. 2179 6.4. Man-in-the-middle Attacks 2181 As described in [I-D.puthenkulam-eap-binding], EAP method sequences 2182 and compound authentication mechanisms may be subject to man-in-the- 2183 middle attacks. When such attacks are successfully carried out, the 2184 attacker acts as an intermediary between a victim and a legitimate 2185 authenticator. This allows the attacker to authenticate successfully 2186 to the authenticator, as well as to obtain access to the network. 2188 In order to prevent these attacks, [I-D.puthenkulam-eap-binding] 2189 recommends derivation of a compound key by which the EAP peer and 2190 server can prove that they have participated in the entire EAP 2191 exchange. Since the compound key must not be known to an attacker 2192 posing as an authenticator, and yet must be derived from quantities 2193 that are exported by EAP methods, it may be desirable to derive the 2194 compound key from a portion of the EMSK. In order to provide proper 2195 key hygiene, it is recommended that the compound key used for man-in- 2196 the-middle protection be cryptographically separate from other keys 2197 derived from the EMSK, such as fast handoff keys, discussed in 2198 Section 2.3. 2200 6.5. Denial of Service Attacks 2202 The caching of security associations may result in vulnerability to 2203 denial of service attacks. Since an EAP peer may derive multiple EAP 2204 SAs with a given EAP server, and creation of a new EAP SA does not 2205 implicitly delete a previous EAP SA, EAP methods that result in 2206 creation of persistent state may be vulnerable to denial of service 2207 attacks by a rogue EAP peer. 2209 As a result, EAP methods creating persistent state may wish to limit 2210 the number of cached EAP SAs (Phase 1a) corresponding to an EAP peer. 2211 For example, an EAP server may choose to only retain a few EAP SAs 2212 for each peer. This prevents a rogue peer from denying access to 2213 other peers. 2215 Similarly, an authenticator may have multiple AAA-Key SAs 2216 corresponding to a given EAP peer; to conserve resources an 2217 authenticator may choose to limit the number of cached AAA-Key (Phase 2218 1 b) SAs for each peer. 2220 Depending on the media, creation of a new unicast Secure Association 2221 SA may or may not imply deletion of a previous unicast secure 2222 association SA. Where there is no implied deletion, the 2223 authenticator may choose to limit Phase 2 (unicast and multicast) 2224 Secure Association SAs for each peer. 2226 6.6. Impersonation 2228 Both the RADIUS and Diameter protocols are potentially vulnerable to 2229 impersonation by a rogue authenticator. 2231 While AAA protocols such as RADIUS [RFC2865] or Diameter [RFC3588] 2232 support mutual authentication between the authenticator (known as the 2233 AAA client) and the backend authentication server (known as the AAA 2234 server), the security mechanisms vary according to the AAA protocol. 2236 In RADIUS, the shared secret used for authentication is determined by 2237 the source address of the RADIUS packet. As noted in [RFC3579] 2238 Section 4.3.7, it is highly desirable that the source address be 2239 checked against one or more NAS identification attributes so as to 2240 detect and prevent impersonation attacks. 2242 When RADIUS requests are forwarded by a proxy, the NAS-IP-Address or 2243 NAS-IPv6-Address attributes may not correspond to the source address. 2244 Since the NAS-Identifier attribute need not contain an FQDN, it also 2245 may not correspond to the source address, even indirectly. [RFC2865] 2246 Section 3 states: 2248 A RADIUS server MUST use the source IP address of the RADIUS 2249 UDP packet to decide which shared secret to use, so that 2250 RADIUS requests can be proxied. 2252 This implies that it is possible for a rogue authenticator to forge 2253 NAS-IP-Address, NAS-IPv6-Address or NAS-Identifier attributes within 2254 a RADIUS Access-Request in order to impersonate another 2255 authenticator. Among other things, this can result in messages (and 2256 MSKs) being sent to the wrong authenticator. Since the rogue 2257 authenticator is authenticated by the RADIUS proxy or server purely 2258 based on the source address, other mechanisms are required to detect 2259 the forgery. In addition, it is possible for attributes such as the 2260 Called-Station-Id and Calling-Station-Id to be forged as well. 2262 As recommended in [RFC3579], this vulnerability can be mitigated by 2263 having RADIUS proxies check authenticator identification attributes 2264 against the source address. 2266 To allow verification of session parameters such as the Called- 2267 Station- Id and Calling-Station-Id, these can be sent by the EAP peer 2268 to the server, protected by the TEKs. The RADIUS server can then 2269 check the parameters sent by the EAP peer against those claimed by 2270 the authenticator. If a discrepancy is found, an error can be 2271 logged. 2273 While [RFC3588] requires use of the Route-Record AVP, this utilizes 2274 FQDNs, so that impersonation detection requires DNS A/AAAA and PTR 2275 RRs to be properly configured. As a result, it appears that Diameter 2276 is as vulnerable to this attack as RADIUS, if not more so. To address 2277 this vulnerability, it is necessary to allow the backend 2278 authentication server to communicate with the authenticator directly, 2279 such as via the redirect functionality supported in [RFC3588]. 2281 6.7. Channel binding 2283 It is possible for a compromised or poorly implemented EAP 2284 authenticator to communicate incorrect information to the EAP peer 2285 and/or server. This may enable an authenticator to impersonate 2286 another authenticator or communicate incorrect information via out- 2287 of-band mechanisms (such as via AAA or the lower layer protocol). 2289 Where EAP is used in pass-through mode, the EAP peer typically does 2290 not verify the identity of the pass-through authenticator, it only 2291 verifies that the pass-through authenticator is trusted by the EAP 2292 server. This creates a potential security vulnerability, described in 2293 [RFC3748] Section 7.15. 2295 [RFC3579] Section 4.3.7 describes how an EAP pass-through 2296 authenticator acting as a AAA client can be detected if it attempts 2297 to impersonate another authenticator (such by sending incorrect NAS- 2298 Identifier [RFC2865], NAS-IP-Address [RFC2865] or NAS-IPv6-Address 2299 [RFC3162] attributes via the AAA protocol). However, it is possible 2300 for a pass-through authenticator acting as a AAA client to provide 2301 correct information to the AAA server while communicating misleading 2302 information to the EAP peer via a lower layer protocol. 2304 For example, it is possible for a compromised authenticator to 2305 utilize another authenticator's Called-Station-Id or NAS-Identifier 2306 in communicating with the EAP peer via a lower layer protocol, or for 2307 a pass-through authenticator acting as a AAA client to provide an 2308 incorrect peer Calling-Station-Id [RFC2865][RFC3580] to the AAA 2309 server via the AAA protocol. 2311 As noted in [RFC3748] Section 7.15, this vulnerability can be 2312 addressed by use of EAP methods that support a protected exchange of 2313 channel properties such as endpoint identifiers, including (but not 2314 limited to): Called-Station-Id [RFC2865][RFC3580], Calling-Station-Id 2315 [RFC2865][RFC3580], NAS-Identifier [RFC2865], NAS-IP-Address 2316 [RFC2865], and NAS-IPv6-Address [RFC3162]. 2318 Using such a protected exchange, it is possible to match the channel 2319 properties provided by the authenticator via out-of-band mechanisms 2320 against those exchanged within the EAP method. For example, see 2321 [ServiceIdent]. 2323 7. Security Requirements 2325 This section summarizes the security requirements that must be met by 2326 EAP methods, AAA protocols, Secure Association Protocols and 2327 Ciphersuites in order to address the security threats described in 2328 this document. These requirements MUST be met by specifications 2329 requesting publication as an RFC. Each requirement provides a 2330 pointer to the sections of this document describing the threat that 2331 it mitigates. 2333 7.1. EAP Method Requirements 2335 It is possible for the peer and EAP server to mutually authenticate 2336 and derive keys. In order to provide keying material for use in a 2337 subsequently negotiated ciphersuite, an EAP method supporting key 2338 derivation MUST export a Master Session Key (MSK) of at least 64 2339 octets, and an Extended Master Session Key (EMSK) of at least 64 2340 octets. EAP Methods deriving keys MUST provide for mutual 2341 authentication between the EAP peer and the EAP Server. 2343 The MSK and EMSK MUST NOT be used directly to protect data; however, 2344 they are of sufficient size to enable derivation of a AAA-Key 2345 subsequently used to derive Transient Session Keys (TSKs) for use 2346 with the selected ciphersuite. Each ciphersuite is responsible for 2347 specifying how to derive the TSKs from the AAA-Key. 2349 The AAA-Key is derived from the keying material exported by the EAP 2350 method (MSK and EMSK). This derivation occurs on the AAA server. In 2351 many existing protocols that use EAP, the AAA-Key and MSK are 2352 equivalent, but more complicated mechanisms are possible. 2354 EAP methods SHOULD ensure the freshness of the MSK and EMSK even in 2355 cases where one party may not have a high quality random number 2356 generator. A RECOMMENDED method is for each party to provide a nonce 2357 of at least 128 bits, used in the derivation of the MSK and EMSK. 2359 EAP methods export the MSK and EMSK and not Transient Session Keys so 2360 as to allow EAP methods to be ciphersuite and media independent. 2361 Keying material exported by EAP methods MUST be independent of the 2362 ciphersuite negotiated to protect data. 2364 Depending on the lower layer, EAP methods may run before or after 2365 ciphersuite negotiation, so that the selected ciphersuite may not be 2366 known to the EAP method. By providing keying material usable with 2367 any ciphersuite, EAP methods can used with a wide range of 2368 ciphersuites and media. 2370 It is RECOMMENDED that methods providing integrity protection of EAP 2371 packets include coverage of all the EAP header fields, including the 2372 Code, Identifier, Length, Type and Type-Data fields. 2374 In order to preserve algorithm independence, EAP methods deriving 2375 keys SHOULD support (and document) the protected negotiation of the 2376 ciphersuite used to protect the EAP conversation between the peer and 2377 server. This is distinct from the ciphersuite negotiated between the 2378 peer and authenticator, used to protect data. 2380 The strength of Transient Session Keys (TSKs) used to protect data is 2381 ultimately dependent on the strength of keys generated by the EAP 2382 method. If an EAP method cannot produce keying material of 2383 sufficient strength, then the TSKs may be subject to brute force 2384 attack. In order to enable deployments requiring strong keys, EAP 2385 methods supporting key derivation SHOULD be capable of generating an 2386 MSK and EMSK, each with an effective key strength of at least 128 2387 bits. 2389 Methods supporting key derivation MUST demonstrate cryptographic 2390 separation between the MSK and EMSK branches of the EAP key 2391 hierarchy. Without violating a fundamental cryptographic assumption 2392 (such as the non-invertibility of a one-way function) an attacker 2393 recovering the MSK or EMSK MUST NOT be able to recover the other 2394 quantity with a level of effort less than brute force. 2396 Non-overlapping substrings of the MSK MUST be cryptographically 2397 separate from each other. That is, knowledge of one substring MUST 2398 NOT help in recovering some other non-overlapping substring without 2399 breaking some hard cryptographic assumption. This is required 2400 because some existing ciphersuites form TSKs by simply splitting the 2401 AAA-Key to pieces of appropriate length. Likewise, non-overlapping 2402 substrings of the EMSK MUST be cryptographically separate from each 2403 other, and from substrings of the MSK. The EMSK MUST NOT be 2404 transported to, or shared with, additional parties. 2406 Since EAP does not provide for explicit key lifetime negotiation, EAP 2407 peers, authenticators and authentication servers MUST be prepared for 2408 situations in which one of the parties discards key state which 2409 remains valid on another party. 2411 The development and validation of key derivation algorithms is 2412 difficult, and as a result EAP methods SHOULD reuse well established 2413 and analyzed mechanisms for MSK and EMSK key derivation (such as 2414 those specified in IKE [RFC2409] or TLS [RFC2246]), rather than 2415 inventing new ones. 2417 7.1.1. Requirements for EAP methods 2419 In order for an EAP method to meet the guidelines for EMSK usage it 2420 must meet the following requirements: 2422 o It MUST specify how to derive the EMSK 2424 o The key material used for the EMSK MUST be 2425 computationally independent of the MSK and TEKs. 2427 o The EMSK MUST NOT be used for any other purpose than the key 2428 derivation described in this document. 2430 o The EMSK MUST be secret and not known to someone observing 2431 the authentication mechanism protocol exchange. 2433 o The EMSK MUST NOT be exported from the EAP server. 2435 o The EMSK MUST be unique for each session. 2437 o The EAP mechanism SHOULD a unique identifier suitable for naming the EMSK. 2439 7.1.2. Requirements for EAP applications 2441 In order for an application to meet the guidelines for EMSK usage it 2442 must meet the following requirements: 2444 o New applications following this specification SHOULD NOT use the 2445 MSK. If more than one application uses the MSK, then the 2446 cryptographic separation is not achieved. Implementations SHOULD 2447 prevent such combinations. 2449 o A peer MUST NOT use the EMSK directly for cryptographic 2450 protection of data. 2452 7.2. AAA Protocol Requirements 2454 AAA protocols suitable for use in transporting EAP MUST provide the 2455 following facilities: 2457 Security services 2458 AAA protocols used for transport of EAP keying material MUST 2459 implement and SHOULD use per-packet integrity and authentication, 2460 replay protection and confidentiality. These requirements are met 2461 by Diameter EAP [I-D.ietf-aaa-eap], as well as RADIUS over IPsec 2462 [RFC3579]. 2464 Session Keys 2465 AAA protocols used for transport of EAP keying material MUST 2466 implement and SHOULD use dynamic key management in order to derive 2467 fresh session keys, as in Diameter EAP [I-D.ietf-aaa-eap] and 2468 RADIUS over IPsec [RFC3579], rather than using a static key, as 2469 originally defined in RADIUS [RFC2865]. 2471 Mutual authentication 2472 AAA protocols used for transport of EAP keying material MUST 2473 provide for mutual authentication between the authenticator and 2474 backend authentication server. These requirements are met by 2475 Diameter EAP [I-D.ietf-aaa-eap] as well as by RADIUS EAP [RFC3579]. 2477 Authorization 2478 AAA protocols used for transport of EAP keying material SHOULD 2479 provide protection against rogue authenticators masquerading as 2480 other authenticators. This can be accomplished, for example, by 2481 requiring that AAA agents check the source address of packets 2482 against the origin attributes (Origin-Host AVP in Diameter, NAS-IP- 2483 Address, NAS-IPv6-Address, NAS-Identifier in RADIUS). For details, 2484 see [RFC3579] Section 4.3.7. 2486 Key transport 2487 Since EAP methods do not export Transient Session Keys (TSKs) in 2488 order to maintain media and ciphersuite independence, the AAA 2489 server MUST NOT transport TSKs from the backend authentication 2490 server to authenticator. 2492 Key transport specification 2493 In order to enable backend authentication servers to provide keying 2494 material to the authenticator in a well defined format, AAA 2495 protocols suitable for use with EAP MUST define the format and 2496 wrapping of the AAA-Token. 2498 EMSK transport 2499 Since the EMSK is a secret known only to the backend authentication 2500 server and peer, the AAA-Token MUST NOT transport the EMSK from the 2501 backend authentication server to the authenticator. 2503 AAA-Token protection 2504 To ensure against compromise, the AAA-Token MUST be integrity 2505 protected, authenticated, replay protected and encrypted in 2506 transit, using well-established cryptographic algorithms. 2508 Session Keys 2509 The AAA-Token SHOULD be protected with session keys as in Diameter 2510 [RFC3588] or RADIUS over IPsec [RFC3579] rather than static keys, 2511 as in [RFC2548]. 2513 Key naming 2514 In order to ensure against confusion between the appropriate keying 2515 material to be used in a given Secure Association Protocol 2516 exchange, the AAA-Token SHOULD include explicit key names and 2517 context appropriate for informing the authenticator how the keying 2518 material is to be used. 2520 Key Compromise 2521 Where untrusted intermediaries are present, the AAA-Token SHOULD 2522 NOT be provided to the intermediaries. In Diameter, handling of 2523 keys by intermediaries can be avoided using Redirect functionality 2524 [RFC3588]. 2526 7.3. Secure Association Protocol Requirements 2528 The Secure Association Protocol supports the following: 2530 Entity Naming 2531 The peer and authenticator SHOULD identify themselves in a manner 2532 that is independent of their attached ports. 2534 Mutual proof of possession 2535 The peer and authenticator MUST each demonstrate possession of the 2536 keying material transported between the backend authentication 2537 server and authenticator (AAA-Key). 2539 Key Naming 2540 The Secure Association Protocol MUST explicitly name the keys used 2541 in the proof of possession exchange, so as to prevent confusion 2542 when more than one set of keying material could potentially be used 2543 as the basis for the exchange. 2545 Creation and Deletion 2546 In order to support the correct processing of phase 2 security 2547 associations, the Secure Association (phase 2) protocol MUST 2548 support the naming of phase 2 security associations and associated 2549 transient session keys, so that the correct set of transient 2550 session keys can be identified for processing a given packet. The 2551 phase 2 Secure Association Protocol also MUST support transient 2552 session key activation and SHOULD support deletion, so that 2553 establishment and re-establishment of transient session keys can be 2554 synchronized between the parties. 2556 Integrity and Replay Protection 2557 The Secure Association Protocol MUST support integrity and replay 2558 protection of all messages. 2560 Direct operation 2561 Since the phase 2 Secure Association Protocol is concerned with the 2562 establishment of security associations between the EAP peer and 2563 authenticator, including the derivation of transient session keys, 2564 only those parties have "a need to know" the transient session 2565 keys. The Secure Association Protocol MUST operate directly between 2566 the peer and authenticator, and MUST NOT be passed-through to the 2567 backend authentication server, or include additional parties. 2569 Derivation of transient session keys 2570 The Secure Association Protocol negotiation MUST support derivation 2571 of unicast and multicast transient session keys suitable for use 2572 with the negotiated ciphersuite. 2574 TSK freshness 2575 The Secure Association (phase 2) Protocol MUST support the 2576 derivation of fresh unicast and multicast transient session keys, 2577 even when the keying material provided by the backend 2578 authentication server is not fresh. This is typically supported by 2579 including an exchange of nonces within the Secure Association 2580 Protocol. 2582 Bi-directional operation 2583 While some ciphersuites only require a single set of transient 2584 session keys to protect traffic in both directions, other 2585 ciphersuites require a unique set of transient session keys in each 2586 direction. The phase 2 Secure Association Protocol SHOULD provide 2587 for the derivation of unicast and multicast keys in each direction, 2588 so as not to require two separate phase 2 exchanges in order to 2589 create a bi-directional phase 2 security association. 2591 Secure capabilities negotiation 2592 The Secure Association Protocol MUST support secure capabilities 2593 negotiation. This includes security parameters such as the 2594 security association identifier (SAID) and ciphersuites, as well as 2595 negotiation of the lifetime of the TSKs, AAA-Key and exported EAP 2596 keys. Secure capabilities negotiation also includes confirmation 2597 of the capabilities discovered during the discovery phase (phase 2598 0), so as to ensure that the announced capabilities have not been 2599 forged. 2601 Key Scoping 2602 The Secure Association Protocol MUST ensure the synchronization of 2603 key scope between the peer and authenticator. This includes 2604 negotiation of restrictions on key usage. 2606 7.4. Ciphersuite Requirements 2608 Ciphersuites suitable for keying by EAP methods MUST provide the 2609 following facilities: 2611 TSK derivation 2612 In order to allow a ciphersuite to be usable within the EAP keying 2613 framework, a specification MUST be provided describing how 2614 transient session keys suitable for use with the ciphersuite are 2615 derived from the AAA-Key. 2617 EAP method independence 2618 Algorithms for deriving transient session keys from the AAA-Key 2619 MUST NOT depend on the EAP method. However, algorithms for 2620 deriving TEKs MAY be specific to the EAP method. 2622 Cryptographic separation 2623 The TSKs derived from the AAA-Key MUST be cryptographically 2624 separate from each other. Similarly, TEKs MUST be 2625 cryptographically separate from each other. In addition, the TSKs 2626 MUST be cryptographically separate from the TEKs. 2628 8. IANA Considerations 2630 This document does not create any new name spaces nor does it 2631 allocate any protocol parameters. 2633 9. References 2635 9.1. Normative References 2637 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2638 Requirement Levels", BCP 14, RFC 2119, March 1997. 2640 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 2641 Considerations Section in RFCs", BCP 26, RFC 2434, October 2642 1998. 2644 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 2645 Lefkowetz, "Extensible Authentication Protocol (EAP)", RFC 2646 3748, June 2004. 2648 9.2. Informative References 2650 [CTP] Loughney, J., Nakhjiri, M., Perkins, C. and R. Koodli, 2651 "Context Transfer Protocol", draft-ietf-seamoby-ctp-11.txt, 2652 Internet draft (work in progress), August 2004. 2654 [DESMODES] 2655 National Institute of Standards and Technology, "DES Modes of 2656 Operation", FIPS PUB 81, December 1980, . 2659 [FIPSDES] National Institute of Standards and Technology, "Data 2660 Encryption Standard", FIPS PUB 46, January 1977. 2662 [Housley] Housley, R. and B. Aboba, "AAA Key Management", draft-housley- 2663 aaa-key-mgmt-00.txt, Internet draft (work in progress), June 2664 2005..IP [IEEE-802] Institute of Electrical and Electronics 2665 Engineers, "IEEE Standards for Local and Metropolitan Area 2666 Networks: Overview and Architecture", ANSI/IEEE Standard 802, 2667 1990. 2669 [IEEE-802.11] 2670 Institute of Electrical and Electronics Engineers, 2671 "Information technology - Telecommunications and information 2672 exchange between systems - Local and metropolitan area 2673 networks - Specific Requirements Part 11: Wireless LAN Medium 2674 Access Control (MAC) and Physical Layer (PHY) Specifications", 2675 IEEE IEEE Standard 802.11-2003, 2003. 2677 [IEEE-802.1X] 2678 Institute of Electrical and Electronics Engineers, "Local and 2679 Metropolitan Area Networks: Port-Based Network Access 2680 Control", IEEE Standard 802.1X-2004, December 2004. 2682 [IEEE-802.1Q] 2683 Institute of Electrical and Electronics Engineers, "IEEE 2684 Standards for Local and Metropolitan Area Networks: Draft 2685 Standard for Virtual Bridged Local Area Networks", IEEE 2686 Standard 802.1Q/D8, January 1998. 2688 [IEEE-802.11i] 2689 Institute of Electrical and Electronics Engineers, "Supplement 2690 to STANDARD FOR Telecommunications and Information Exchange 2691 between Systems - LAN/MAN Specific Requirements - Part 11: 2692 Wireless Medium Access Control (MAC) and physical layer (PHY) 2693 specifications: Specification for Enhanced Security", IEEE 2694 802.11i, December 2004. 2696 [IEEE-802.11F] 2697 Institute of Electrical and Electronics Engineers, 2698 "Recommended Practice for Multi-Vendor Access Point 2699 Interoperability via an Inter-Access Point Protocol Across 2700 Distribution Systems Supporting IEEE 802.11 Operation", IEEE 2701 802.11F, July 2003. 2703 [IEEE-02-758] 2704 Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, 2705 "Proactive Caching Strategies for IAPP Latency Improvement 2706 during 802.11 Handoff", IEEE 802.11 Working Group, 2707 IEEE-02-758r1-F Draft 802.11I/D5.0, November 2002. 2709 [IEEE-03-084] 2710 Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, 2711 "Proactive Key Distribution to support fast and secure 2712 roaming", IEEE 802.11 Working Group, IEEE-03-084r1-I, 2713 http://www.ieee802.org/11/Documents/DocumentHolder/ 3-084.zip, 2714 January 2003. 2716 [IEEE-03-155] 2717 Aboba, B., "Fast Handoff Issues", IEEE 802.11 Working Group, 2718 IEEE-03-155r0-I, http://www.ieee802.org/11/ 2719 Documents/DocumentHolder/3-155.zip, March 2003. 2721 [I-D.ietf-roamops-cert] 2722 Aboba, B., "Certificate-Based Roaming", draft-ietf-roamops- 2723 cert-02 (work in progress), April 1999. 2725 [I-D.ietf-aaa-eap] 2726 Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible 2727 Authentication Protocol (EAP) Application", draft-ietf-aaa- 2728 eap-10 (work in progress), November 2004. 2730 [I-D.puthenkulam-eap-binding] 2731 Puthenkulam, J., "The Compound Authentication Binding 2732 Problem", draft-puthenkulam-eap-binding-04 (work in progress), 2733 October 2003. 2735 [I-D.arkko-pppext-eap-aka] 2736 Arkko, J. and H. Haverinen, "EAP AKA Authentication", draft- 2737 arkko-pppext-eap-aka-15.txt (work in progress), December 2004. 2739 [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", draft- 2740 ietf-ipsec-ikev2-17 (work in progress), September 2004. 2742 [MD5Attack] 2743 Dobbertin, H., "The Status of MD5 After a Recent Attack", 2744 CryptoBytes, Vol.2 No.2, 1996. 2746 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 2747 September 1981. 2749 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 2750 1661, July 1994. 2752 [RFC1968] Meyer, G. and K. Fox, "The PPP Encryption Control Protocol 2753 (ECP)", RFC 1968, June 1996. 2755 [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing 2756 for Message Authentication", RFC 2104, February 1997. 2758 [RFC2246] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. 2759 and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, 2760 January 1999. 2762 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 2763 Internet Protocol", RFC 2401, November 1998. 2765 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 2766 RFC 2409, November 1998. 2768 [RFC2419] Sklower, K. and G. Meyer, "The PPP DES Encryption Protocol, 2769 Version 2 (DESE-bis)", RFC 2419, September 1998. 2771 [RFC2420] Kummert, H., "The PPP Triple-DES Encryption Protocol (3DESE)", 2772 RFC 2420, September 1998. 2774 [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D. and 2775 R. Wheeler, "A Method for Transmitting PPP Over Ethernet 2776 (PPPoE)", RFC 2516, February 1999. 2778 [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2779 2548, March 1999. 2781 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 2782 Implementation in Roaming", RFC 2607, June 1999. 2784 [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol", 2785 RFC 2716, October 1999. 2787 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 2788 Authentication Dial In User Service (RADIUS)", RFC 2865, June 2789 2000. 2791 [RFC3078] Pall, G. and G. Zorn, "Microsoft Point-To-Point Encryption 2792 (MPPE) Protocol", RFC 3078, March 2001. 2794 [RFC3079] Zorn, G., "Deriving Keys for use with Microsoft Point-to-Point 2795 Encryption (MPPE)", RFC 3079, March 2001. 2797 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial 2798 In User Service) Support For Extensible Authentication 2799 Protocol (EAP)", RFC 3579, September 2003. 2801 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese, 2802 "IEEE 802.1X Remote Authentication Dial In User Service 2803 (RADIUS) Usage Guidelines", RFC 3580, September 2003. 2805 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. 2806 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 2808 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public 2809 Keys Used For Exchanging Symmetric Keys", RFC 3766, April 2810 2004. 2812 [RFC4017] Stanley, D., Walker, J. and B. Aboba, "EAP Method Requirements 2813 for Wireless LANs", RFC 4017, March 2005. 2815 [8021XHandoff] 2816 Pack, S. and Y. Choi, "Pre-Authenticated Fast Handoff in a 2817 Public Wireless LAN Based on IEEE 802.1X Model", School of 2818 Computer Science and Engineering, Seoul National University, 2819 Seoul, Korea, 2002. 2821 Acknowledgments 2823 Thanks to Arun Ayyagari, Ashwin Palekar, and Tim Moore of Microsoft, 2824 Dorothy Stanley of Agere, Bob Moskowitz of TruSecure, Jesse Walker of 2825 Intel, Joe Salowey of Cisco and Russ Housley of Vigil Security for 2826 useful feedback. 2828 Author Addresses 2830 Bernard Aboba 2831 Microsoft Corporation 2832 One Microsoft Way 2833 Redmond, WA 98052 2835 EMail: bernarda@microsoft.com 2836 Phone: +1 425 706 6605 2837 Fax: +1 425 936 7329 2839 Dan Simon 2840 Microsoft Research 2841 Microsoft Corporation 2842 One Microsoft Way 2843 Redmond, WA 98052 2845 EMail: dansimon@microsoft.com 2846 Phone: +1 425 706 6711 2847 Fax: +1 425 936 7329 2849 Jari Arkko 2850 Ericsson 2851 Jorvas 02420 2852 Finland 2854 Phone: 2855 EMail: jari.arkko@ericsson.com 2857 Pasi Eronen 2858 Nokia Research Center 2859 P.O. Box 407 2860 FIN-00045 Nokia Group 2861 Finland 2863 EMail: pasi.eronen@nokia.com 2865 Henrik Levkowetz (editor) 2866 ipUnplugged AB 2867 Arenavagen 27 2868 Stockholm S-121 28 2869 SWEDEN 2871 Phone: +46 708 32 16 08 2872 EMail: henrik@levkowetz.com 2874 Appendix A - Ciphersuite Keying Requirements 2876 To date, PPP and IEEE 802.11 ciphersuites are suitable for keying by 2877 EAP. This Appendix describes the keying requirements of common PPP 2878 and 802.11 ciphersuites. 2880 PPP ciphersuites include DESEbis [RFC2419], 3DES [RFC2420], and MPPE 2881 [RFC3078]. The DES algorithm is described in [FIPSDES], and DES 2882 modes (such as CBC, used in [RFC2419] and DES-EDE3-CBC, used in 2883 [RFC2420]) are described in [DESMODES]. For PPP DESEbis, a single 2884 56-bit encryption key is required, used in both directions. For PPP 2885 3DES, a 168-bit encryption key is needed, used in both directions. As 2886 described in [RFC2419] for DESEbis and [RFC2420] for 3DES, the IV, 2887 which is different in each direction, is "deduced from an explicit 2888 64-bit nonce, which is exchanged in the clear during the [ECP] 2889 negotiation phase." There is therefore no need for the IV to be 2890 provided by EAP. 2892 For MPPE, 40-bit, 56-bit or 128-bit encryption keys are required in 2893 each direction, as described in [RFC3078]. No initialization vector 2894 is required. 2896 While these PPP ciphersuites provide encryption, they do not provide 2897 per-packet authentication or integrity protection, so an 2898 authentication key is not required in either direction. 2900 Within [IEEE-802.11], Transient Session Keys (TSKs) are required both 2901 for unicast traffic as well as for multicast traffic, and therefore 2902 separate key hierarchies are required for unicast keys and multicast 2903 keys. IEEE 802.11 ciphersuites include WEP-40, described in 2904 [IEEE-802.11], which requires a 40-bit encryption key, the same in 2905 either direction; and WEP-128, which requires a 104-bit encryption 2906 key, the same in either direction. These ciphersuites also do not 2907 support per-packet authentication and integrity protection. In 2908 addition to these unicast keys, authentication and encryption keys 2909 are required to wrap the multicast encryption key. 2911 Recently, new ciphersuites have been proposed for use with IEEE 2912 802.11 that provide per-packet authentication and integrity 2913 protection as well as encryption [IEEE-802.11i]. These include TKIP, 2914 which requires a single 128-bit encryption key and two 64-bit 2915 authentication keys (one for each direction); and AES CCMP, which 2916 requires a single 128-bit key (used in both directions) in order to 2917 authenticate and encrypt data. 2919 As with WEP, authentication and encryption keys are also required to 2920 wrap the multicast encryption (and possibly, authentication) keys. 2922 Appendix B - Transient EAP Key (TEK) Hierarchy 2924 Figure B-1 illustrates the TEK key hierarchy for EAP-TLS [RFC2716], 2925 which is based on the TLS key hierarchy described in [RFC2246]. The 2926 TLS-negotiated ciphersuite is used to set up a protected channel for 2927 use in protecting the EAP conversation, keyed by the derived TEKs. 2928 The TEK derivation proceeds as follows: 2930 master_secret = TLS-PRF-48(pre_master_secret, "master secret", 2931 client.random || server.random) 2932 TEK = TLS-PRF-X(master_secret, "key expansion", 2933 server.random || client.random) 2934 Where: 2935 TLS-PRF-X = TLS pseudo-random function defined in [RFC2246], 2936 computed to X octets. 2938 | | | 2939 | | pre_master_secret | 2940 server| | | client 2941 Random| V | Random 2942 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2943 | | | | 2944 | | | | 2945 +---->| master_secret |<------+ 2946 | | (TMS) | | 2947 | | | | 2948 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2949 | | | 2950 | | | 2951 | | | 2952 V V V 2953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2954 | | 2955 | | 2956 | Key Block | 2957 | (TEKs) | 2958 | | 2959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2960 | | | | | | 2961 | client | server | client | server | client | server 2962 | MAC | MAC | write | write | IV | IV 2963 | | | | | | 2964 V V V V V V 2966 Figure B-1 - TLS [RFC2246] Key Hierarchy 2968 Appendix C - EAP-TLS Key Hierarchy 2970 In EAP-TLS [RFC2716], the MSK is divided into two halves, 2971 corresponding to the "Peer to Authenticator Encryption Key" (Enc- 2972 RECV-Key, 32 octets, also known as the PMK) and "Authenticator to 2973 Peer Encryption Key" (Enc-SEND-Key, 32 octets). In [RFC2548], the 2974 Enc-RECV-Key (the PMK) is transported in the MS-MPPE-Recv-Key 2975 attribute, and the Enc-SEND-Key is transported in the MS-MPPE-Send- 2976 Key attribute. 2978 The EMSK is also divided into two halves, corresponding to the "Peer 2979 to Authenticator Authentication Key" (Auth-RECV-Key, 32 octets) and 2980 "Authenticator to Peer Authentication Key" (Auth-SEND-Key, 32 2981 octets). The IV is a 64 octet quantity that is a known value; octets 2982 0-31 are known as the "Peer to Authenticator IV" or RECV-IV, and 2983 Octets 32-63 are known as the "Authenticator to Peer IV", or SEND-IV. 2985 In EAP-TLS, the MSK, EMSK and IV are derived from the TLS master 2986 secret via a one-way function. This ensures that the TLS master 2987 secret cannot be derived from the MSK, EMSK or IV unless the one-way 2988 function (TLS PRF) is broken. Since the MSK is derived from the the 2989 TLS master secret, if the TLS master secret is compromised then the 2990 MSK is also compromised. 2992 The key derivation scheme specified in RFC 2716 that was specified 2993 prior to the introduction of the terminology MSK and EMSK MUST be 2994 interpreted as follows: 2996 MSK = TLS-PRF-64(TMS, "client EAP encryption", 2997 client.random || server.random) 2998 EMSK = second 64 octets of: 2999 TLS-PRF-128(TMS, "client EAP encryption", 3000 client.random || server.random) 3001 IV = TLS-PRF-64("", "client EAP encryption", 3002 client.random || server.random) 3004 AAA-Key(0,31) = Peer to Authenticator Encryption Key (Enc-RECV-Key) 3005 (MS-MPPE-Recv-Key in [RFC2548]). Also known as the 3006 PMK. 3007 AAA-Key(32,63)= Authenticator to Peer Encryption Key (Enc-SEND-Key) 3008 (MS-MPPE-Send-Key in [RFC2548]) 3009 EMSK(0,31) = Peer to Authenticator Authentication Key (Auth-RECV-Key) 3010 EMSK(32,63) = Authenticator to Peer Authentication Key (Auth-Send-Key) 3011 IV(0,31) = Peer to Authenticator Initialization Vector (RECV-IV) 3012 IV(32,63) = Authenticator to Peer Initialization vector (SEND-IV) 3014 Where: 3016 AAA-Key(W,Z) = Octets W through Z includes of the AAA-Key. 3017 IV(W,Z) = Octets W through Z inclusive of the IV. 3018 MSK(W,Z) = Octets W through Z inclusive of the MSK. 3019 EMSK(W,Z) = Octets W through Z inclusive of the EMSK. 3020 TMS = TLS master_secret 3021 TLS-PRF-X = TLS PRF function defined in [RFC2246] computed to X octets 3022 client.random = Nonce generated by the TLS client. 3023 server.random = Nonce generated by the TLS server. 3025 Figure C-1 describes the process by which the MSK,EMSK,IV and 3026 ultimately the TSKs, are derived from the TLS Master Secret. 3028 ---+ 3029 | ^ 3030 | TLS Master Secret (TMS) | 3031 | | 3032 V | 3033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3034 | | EAP | 3035 | Master Session Key (MSK) | Method | 3036 | Derivation | | 3037 | | V 3038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ EAP ---+ 3039 | | | API ^ 3040 | MSK | EMSK | IV | 3041 | | | | 3042 V V V v 3043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 3044 | | | 3045 | | | 3046 | backend authentication server | | 3047 | | | 3048 | | V 3049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 3050 | | ^ 3051 | AAA-Key(0,31) | AAA-Key(32,63) | 3052 | (PMK) | Transported | 3053 | | via AAA | 3054 | | | 3055 V V V 3056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 3057 | | ^ 3058 | Ciphersuite-Specific Transient Session | Auth.| 3059 | Key Derivation | | 3060 | | V 3061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 3063 Figure C-1 - EAP TLS [RFC2716] Key hierarchy 3065 Appendix D - Example Transient Session Key (TSK) Derivation 3067 Within IEEE 802.11 RSN, the Pairwise Transient Key (PTK), a transient 3068 session key used to protect unicast traffic, is derived from the PMK 3069 (octets 0-31 of the MSK), known in [RFC2716] as the Peer to 3070 Authenticator Encryption Key. In [IEEE-802.11i], the PTK is derived 3071 from the PMK via the following formula: 3073 PTK = EAPOL-PRF-X(PMK, "Pairwise key expansion", Min(AA,SA) || 3074 Max(AA, SA) || Min(ANonce,SNonce) || Max(ANonce,SNonce)) 3076 Where: 3078 PMK = AAA-Key(0,31) 3079 SA = Station MAC address (Calling-Station-Id) 3080 AA = Access Point MAC address (Called-Station-Id) 3081 ANonce = Access Point Nonce 3082 SNonce = Station Nonce 3083 EAPOL-PRF-X = Pseudo-Random Function based on HMAC-SHA1, generating 3084 a PTK of size X octets. 3086 TKIP uses X = 64, while CCMP, WRAP, and WEP use X = 48. 3088 The EAPOL-Key Confirmation Key (KCK) is used to provide data origin 3089 authenticity in the TSK derivation. It utilizes the first 128 bits 3090 (bits 0-127) of the PTK. The EAPOL-Key Encryption Key (KEK) provides 3091 confidentiality in the TSK derivation. It utilizes bits 128-255 of 3092 the PTK. Bits 256-383 of the PTK are used by Temporal Key 1, and Bits 3093 384-511 are used by Temporal Key 2. Usage of TK1 and TK2 is 3094 ciphersuite specific. Details are available in [IEEE-802.11i]. 3096 Appendix E - Exported Parameters in Existing Methods 3098 This Appendix specifies Method-ID, Peer-ID, Server-ID and Key- 3099 Lifetime for EAP methods that have been published prior to this 3100 specification. Future EAP method specifications MUST include a 3101 definition of the Method-ID, Peer-ID, and Server-ID (could be the 3102 empty string) and MAY also define the Key-Lifetime (assumed to be 3103 indeterminate if not described). 3105 EAP-Identity 3107 The EAP-Identity method does not derive keys, and therefore does 3108 not define the Key-Lifetime or Method-ID. The Peer-ID exported by 3109 the Identity method is determined by the octets included within 3110 the EAP- Response/Identity. The Server-ID is the empty string 3111 (zero length). 3113 EAP-Notification 3115 The EAP-Notification method does not derive keys and therefore 3116 does not define the Key-Lifetime and Method-ID. The Peer-ID and 3117 Server-ID are the empty string (zero length). 3119 EAP-GTC 3121 The EAP-GTC method does not derive keys and therefore does not 3122 define the Key-Lifetime and Method-ID. The Peer-ID and Server-ID 3123 are the empty string. 3125 EAP-OTP 3127 The EAP-OTP method does not derive keys and therefore does not 3128 define the Key-Lifetime and Method-ID. The Peer-ID and Server-ID 3129 are the empty string. 3131 EAP-TLS 3133 The EAP-TLS Method-Id is the concatenation of the peer and server 3134 nonces. 3136 The Peer-ID and Server-ID are the contents of the altSubjectName 3137 in the peer and server certificates. 3139 EAP-TLS does not negotiate a Key-Lifetime. 3141 EAP-AKA 3143 The EAP-AKA Method-Id is the contents of the RAND field from the 3144 AT_RAND attribute, followed by the contents of the AUTN field in 3145 the AT_AUTN attribute. 3147 The Peer-ID is the contents of the Identity field from the 3148 AT_IDENTITY attribute, using only the Actual Identity Length 3149 octets from the beginning, however. Note that the contents are 3150 used as they are transmitted, regardless of whether the 3151 transmitted identity was a permanent, pseudonym, or fast 3152 reauthentication identity. The Server- ID is an empty string. 3153 EAP-AKA does not negotiate a key lifetime. 3155 EAP-SIM 3157 The Method-Id is the contents of the RAND field from the AT_RAND 3158 attribute, followed by the contents of the NONCE_MT field in the 3159 AT_NONCE_MT attribute. 3161 The Peer-ID is the contents of the Identity field from the 3162 AT_IDENTITY attribute, using only the Actual Identity Length 3163 octets from the beginning, however. Note that the contents are 3164 used as they are transmitted, regardless of whether the 3165 transmitted identity was a permanent, pseudonym, or fast 3166 reauthentication identity. The Server- ID is an empty string. 3167 EAP-SIM does not negotiate a key lifetime. 3169 Appendix F - Security Association Examples 3171 EAP Method SA Example: EAP-TLS 3173 In EAP-TLS [RFC2716], after the EAP authentication the client (peer) 3174 and server can store the following information: 3176 o Implicitly, the EAP method this SA refers to (EAP-TLS) 3177 o Session identifier (a value selected by the server) 3178 o Certificate of the other party (server stores the client's 3179 certificate and vice versa) 3180 o Ciphersuite and compression method 3181 o TLS Master secret (known as the EAP-TLS Master Key) 3182 o SA lifetime (ensuring that the SA is not stored forever) 3183 o If the client has multiple different credentials (certificates 3184 and corresponding private keys), a pointer to those credentials 3186 When the server initiates EAP-TLS, the client can look up the EAP-TLS 3187 SA based on the credentials it was going to use (certificate and 3188 private key), and the expected credentials (certificate or name) of 3189 the server. If an EAP-TLS SA exists, and it is not too old, the 3190 client informs the server about the existence of this SA by including 3191 its Session-Id in the TLS ClientHello message. The server then looks 3192 up the correct SA based on the Session-Id (or detects that it doesn't 3193 yet have one). 3195 EAP Method SA Example: EAP-AKA 3197 In EAP-AKA [I-D.arkko-pppext-eap-aka], after EAP authentication the 3198 client and server can store the following information: 3200 o Implicitly, the EAP method this SA refers to (EAP-AKA) 3201 o A re-authentication pseudonym 3202 o The client's permanent identity (IMSI) 3203 o Replay protection counter 3204 o Authentication key (K_aut) 3205 o Encryption key (K_encr) 3206 o Original Master Key (MK) 3207 o SA lifetime (ensuring that the SA is not stored forever) 3209 When the server initiates EAP-AKA, the client can look up the EAP-AKA 3210 SA based on the credentials it was going to use (permanent identity). 3211 If an EAP-AKA SA exists, and it is not too old, the client informs 3212 the server about the existence of this SA by sending its re- 3213 authentication pseudonym as its identity in EAP Identity Response 3214 message, instead of its permanent identity. The server then looks up 3215 the correct SA based on this identity. 3217 AAA SA Example: RADIUS 3219 In RADIUS, where shared secret authentication is used, the client and 3220 server store each other's IP address and the shared secret, which is 3221 used to calculate the Response Authenticator [RFC2865] and Message- 3222 Authenticator [RFC3579] values, and to encrypt some attributes (such 3223 as the AAA-Key, see [RFC3580] Section 3.16). 3225 Where IPsec is used to protect RADIUS [RFC3579] and IKE is used for 3226 key management, the parties store information necessary to 3227 authenticate and authorize the other party (e.g. certificates, trust 3228 anchors and names). The IKE exchange results in IKE Phase 1 and Phase 3229 2 SAs containing information used to protect the conversation 3230 (session keys, selected ciphersuite, etc.) 3232 AAA SA Example: Diameter with TLS 3234 When using Diameter protected by TLS, the parties store information 3235 necessary to authenticate and authorize the other party (e.g. 3236 certificates, trust anchors and names). The TLS handshake results in 3237 a short-term TLS SA that contains information used to protect the 3238 actual communications (session keys, selected TLS ciphersuite, etc.). 3240 Service SA Example: 802.11i 3242 [IEEE802.11i] Section 8.4.1.1 defines the security associations used 3243 within IEEE 802.11. A summary follows; the standard should be 3244 consulted for details. 3246 o Pairwise Master Key Security Association (PMKSA) 3248 The PMKSA is a bi-directional SA, used by both parties for sending 3249 and receiving. The PMKSA is the Root Service SA. It is created 3250 on the peer when EAP authentication completes successfully or a 3251 pre-shared key is configured. The PMKSA is created on the 3252 authenticator when the PMK is received or created on the 3253 authenticator or a pre-shared key is configured. The PMKSA is 3254 used to create the PTKSA. PMKSAs are cached for their lifetimes. 3255 The PMKSA consists of the following elements: 3257 - PMKID (security association identifier) 3258 - Authenticator MAC address 3259 - PMK 3260 - Lifetime 3261 - Authenticated Key Management Protocol (AKMP) 3262 - Authorization parameters specified by the AAA server or 3263 by local configuration. This can include 3264 parameters such as the peer's authorized SSID. 3266 On the peer, this information can be locally 3267 configured. 3268 - Key replay counters (for EAPOL-Key messages) 3269 - Reference to PTKSA (if any), needed to: 3270 o delete it (e.g. AAA server-initiated disconnect) 3271 o replace it when a new four-way handshake is done 3272 - Reference to accounting context, the details of which depend 3273 on the accounting protocol used, the implementation 3274 and administrative details. In RADIUS, this could include 3275 (e.g. packet and octet counters, and Acct-Multi-Session-Id). 3277 o Pairwise Transient Key Security Association (PTKSA) 3279 The PTKSA is a bi-directional SA created as the result of a 3280 successful four-way handshake. The PTKSA is a unicast service SA. 3281 There may only be one PTKSA between a pair of peer and 3282 authenticator MAC addresses. PTKSAs are cached for the lifetime 3283 of the PMKSA. Since the PTKSA is tied to the PMKSA, it only has 3284 the additional information from the 4-way handshake. The PTKSA 3285 consists of the following: 3287 - Key (PTK) 3288 - Selected ciphersuite 3289 - MAC addresses of the parties 3290 - Replay counters, and ciphersuite specific state 3291 - Reference to PMKSA: This is needed when: 3292 o A new four-way handshake is needed (lifetime, TKIP 3293 countermeasures), and we need to know which PMKSA to use 3295 o Group Transient Key Security Association (GTKSA) 3297 The GTKSA is a uni-directional SA created based on the four-way 3298 handshake or the group key handshake. The GTKSA is a multicast 3299 service SA. A GTKSA consists of the following: 3301 - Direction vector (whether the GTK is used for transmit or receive) 3302 - Group cipher suite selector 3303 - Key (GTK) 3304 - Authenticator MAC address 3305 - Via reference to PMKSA, or copied here: 3306 o Authorization parameters 3307 o Reference to accounting context 3309 Service SA Example: IKEv2/IPsec 3311 Note that this example is intended to be informative, and it does 3312 not necessarily include all information stored. 3314 o IKEv2 SA 3316 - Protocol version 3317 - Identities of the parties 3318 - IKEv2 SPIs 3319 - Selected ciphersuite 3320 - Replay protection counters (Message ID) 3321 - Keys for protecting IKEv2 messages (SK_ai/SK_ar/SK_ei/SK_er) 3322 - Key for deriving keys for IPsec SAs (SK_d) 3323 - Lifetime information 3324 - On the authenticator, service authorization information 3325 received from the backend authentication server. 3327 When processing an incoming message, the correct SA is looked up 3328 based on the SPIs. 3330 o IPsec SAs/SPD 3332 - Traffic selectors 3333 - Replay protection counters 3334 - Selected ciphersuite 3335 - IPsec SPI 3336 - Keys 3337 - Lifetime information 3338 - Protocol mode (tunnel or transport) 3340 The correct SA is looked up based on SPI (for inbound packets), or 3341 SPD traffic selectors (for outbound traffic). A separate IPsec SA 3342 exists for each direction. 3344 Intellectual Property Statement 3346 The IETF takes no position regarding the validity or scope of any 3347 Intellectual Property Rights or other rights that might be claimed to 3348 pertain to the implementation or use of the technology described in 3349 this document or the extent to which any license under such rights 3350 might or might not be available; nor does it represent that it has 3351 made any independent effort to identify any such rights. Information 3352 on the procedures with respect to rights in RFC documents can be 3353 found in BCP 78 and BCP 79. 3355 Copies of IPR disclosures made to the IETF Secretariat and any 3356 assurances of licenses to be made available, or the result of an 3357 attempt made to obtain a general license or permission for the use of 3358 such proprietary rights by implementers or users of this 3359 specification can be obtained from the IETF on-line IPR repository at 3360 http://www.ietf.org/ipr. 3362 The IETF invites any interested party to bring to its attention any 3363 copyrights, patents or patent applications, or other proprietary 3364 rights that may cover technology that may be required to implement 3365 this standard. Please address the information to the IETF at ietf- 3366 ipr@ietf.org. 3368 Disclaimer of Validity 3370 This document and the information contained herein are provided on an 3371 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3372 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 3373 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 3374 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 3375 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3376 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3378 Copyright Statement 3380 Copyright (C) The Internet Society (2005). This document is subject 3381 to the rights, licenses and restrictions contained in BCP 78, and 3382 except as set forth therein, the authors retain all their rights. 3384 Acknowledgment 3386 Funding for the RFC Editor function is currently provided by the 3387 Internet Society. 3389 Open Issues 3391 Open issues relating to this specification are tracked on the 3392 following web site: 3394 http://www.drizzle.com/~aboba/EAP/eapissues.html