idnits 2.17.1 draft-ietf-eap-keying-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == The page length should not exceed 58 lines per page, but there was 68 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 69 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 85 instances of too long lines in the document, the longest one being 7 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 1882 has weird spacing: '...ude the key s...' == Line 3164 has weird spacing: '...>, and expir...' == 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: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IEEE-802.1X' is mentioned on line 138, but not defined -- Looks like a reference, but probably isn't: '1' on line 1798 -- Looks like a reference, but probably isn't: '2' on line 1801 -- Looks like a reference, but probably isn't: '3' on line 1807 -- Looks like a reference, but probably isn't: '4' on line 1365 -- Looks like a reference, but probably isn't: '5' on line 413 == Missing Reference: 'IEEE802.11i' is mentioned on line 1530, but not defined == Missing Reference: 'RFC3784' is mentioned on line 1781, but not defined ** Obsolete undefined reference: RFC 3784 (Obsoleted by RFC 5305) == Missing Reference: 'RFC2284bis' is mentioned on line 2144, but not defined ** Obsolete undefined reference: RFC 2284 (Obsoleted by RFC 3748) == Missing Reference: 'RFC3162' is mentioned on line 2167, but not defined == Missing Reference: 'RFC3759' is mentioned on line 2215, but not defined == Missing Reference: 'ECP' is mentioned on line 2855, but not defined == Unused Reference: 'RFC0793' is defined on line 2607, but no explicit reference was found in the text == Unused Reference: 'RFC2104' is defined on line 2617, but no explicit reference was found in the text == Unused Reference: 'RFC2401' is defined on line 2624, but no explicit reference was found in the text == Unused Reference: 'RFC3079' is defined on line 2656, but no explicit reference was found in the text == Unused Reference: 'IEEE802' is defined on line 2682, but no explicit reference was found in the text == Unused Reference: 'IEEE80211F' is defined on line 2705, but no explicit reference was found in the text == Unused Reference: 'IEEE-03-155' is defined on line 2733, but no explicit reference was found in the text == Unused Reference: 'I-D.aboba-802-context' is defined on line 2757, but no explicit reference was found in the text == Unused Reference: 'IKEv2' is defined on line 2766, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2716 (Obsoleted by RFC 5216) -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) -- Unexpected draft version: The latest known version of draft-ietf-roamops-cert is -01, but you're referring to -02. == Outdated reference: A later version (-10) exists of draft-ietf-aaa-eap-08 -- Unexpected draft version: The latest known version of draft-aboba-802-context is -02, but you're referring to -03. == Outdated reference: A later version (-16) exists of draft-arkko-pppext-eap-aka-11 == Outdated reference: A later version (-17) exists of draft-ietf-ipsec-ikev2-12 == Outdated reference: A later version (-04) exists of draft-walker-ieee802-req-02 Summary: 7 errors (**), 0 flaws (~~), 27 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 EAP Working Group Bernard Aboba 2 INTERNET-DRAFT Dan Simon 3 Category: Informational Microsoft 4 J. Arkko 5 26 June 2004 Ericsson 6 P. Eronen 7 Nokia 8 H. Levkowetz, Ed. 9 ipUnplugged 11 Extensible Authentication Protocol (EAP) Key Management Framework 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC 2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 The Extensible Authentication Protocol (EAP), defined in [RFC3748], 41 enables extensible network access authentication. This document 42 provides a framework for the generation, transport and usage of 43 keying material generated by EAP authentication algorithms, known as 44 "methods". 46 Table of Contents 48 1. Introduction .......................................... 4 49 1.1 Requirements Language ........................... 4 50 1.2 Terminology ..................................... 4 51 1.3 Overview ........................................ 5 52 1.4 EAP Invariants .................................. 11 53 2. EAP Key Hierarchy ..................................... 13 54 2.1 Key Terminology ................................. 13 55 2.2 Key Hierarchy ................................... 15 56 2.3 Key Lifetimes ................................... 17 57 2.4 AAA-Key Scope ................................... 24 58 2.5 Fast Handoff Support ............................ 26 59 3. Security associations ................................. 30 60 3.1 EAP Method SA ................................... 31 61 3.2 EAP-Key SA ...................................... 33 62 3.3 AAA SA(s) ....................................... 33 63 3.4 Service SA(s) ................................... 34 64 3.5 SA Naming ....................................... 37 65 4. Security Considerations .............................. 39 66 4.1 Security Terminology ............................ 39 67 4.2 Threat Model .................................... 39 68 4.3 Security Analysis ............................... 41 69 4.4 Man-in-the-middle Attacks ....................... 45 70 4.5 Denial of Service Attacks ....................... 45 71 4.6 Impersonation ................................... 46 72 4.7 Channel Binding ................................. 47 73 4.8 Key Strength .................................... 48 74 4.9 Key Wrap ........................................ 48 76 5. Security Requirements ................................. 49 77 5.1 EAP Method Requirements ......................... 49 78 5.2 AAA Protocol Requirements ....................... 52 79 5.3 Secure Association Protocol Requirements ........ 54 80 5.4 Ciphersuite Requirements ........................ 55 81 6. IANA Considerations ................................... 56 82 7. References ............................................ 56 83 7.1 Normative References ............................ 56 84 7.2 Informative References .......................... 57 85 Acknowledgments .............................................. 60 86 Author's Addresses ........................................... 61 87 Appendix A - Ciphersuite Keying Requirements ................. 62 88 Appendix B - Transient EAP Key (TEK) Hierarchy ............... 63 89 Appendix C - EAP Key Hierarchy ............................... 64 90 Appendix D - Transient Session Key (TSK) Derivation .......... 66 91 Appendix E - AAA-Key Derivation .............................. 67 92 Intellectual Property Statement .............................. 68 93 Full Copyright Statement ..................................... 68 95 1. Introduction 97 The Extensible Authentication Protocol (EAP), defined in [RFC3748], 98 was designed to enable extensible authentication for network access 99 in situations in which the IP protocol is not available. Originally 100 developed for use with PPP [RFC1661], it has subsequently also been 101 applied to IEEE 802 wired networks [IEEE8021X]. 103 This document provides a framework for the generation, transport and 104 usage of keying material generated by EAP authentication algorithms, 105 known as "methods". Since in EAP keying material is generated by EAP 106 methods, transported by AAA protocols, transformed into session keys 107 by Secure Association Protocols and used by lower layer ciphersuites, 108 it is necessary to describe each of these elements and provide a 109 system-level security analysis. 111 1.1. Requirements Language 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in BCP 14 [RFC2119]. 117 1.2. Terminology 119 This document frequently uses the following terms: 121 authenticator 122 The end of the link initiating EAP authentication. The term 123 Authenticator is used in [IEEE-802.1X], and authenticator has the 124 same meaning in this document. 126 peer The end of the link that responds to the authenticator. In 127 [IEEE-802.1X], this end is known as the Supplicant. 129 Supplicant 130 The end of the link that responds to the authenticator in 131 [IEEE-802.1X]. In this document, this end of the link is called 132 the peer. 134 backend authentication server 135 A backend authentication server is an entity that provides an 136 authentication service to an authenticator. When used, this server 137 typically executes EAP methods for the authenticator. This 138 terminology is also used in [IEEE-802.1X]. 140 AAA Authentication, Authorization and Accounting. AAA protocols with 141 EAP support include RADIUS [RFC3579] and Diameter [I-D.ietf-aaa- 142 eap]. In this document, the terms "AAA server" and "backend 143 authentication server" are used interchangeably. 145 EAP server 146 The entity that terminates the EAP authentication method with the 147 peer. In the case where no backend authentication server is used, 148 the EAP server is part of the authenticator. In the case where the 149 authenticator operates in pass-through mode, the EAP server is 150 located on the backend authentication server. 152 security association 153 A set of policies and key(s) used to protect information. This 154 information in the security association is stored by each party of 155 the security association and must be consistent among the parties. 156 Elements of a security association include cryptographic keys, 157 negotiated ciphersuites and other parameters, counters, sequence 158 spaces, authorization attributes, etc. 160 1.3. Overview 162 EAP is typically deployed in order to support extensible network 163 access authentication in situations where a peer desires network 164 access via one or more authenticators. The situation is illustrated 165 in Figure 1. 167 Since both the peer and authenticator may have more than one physical 168 or logical port, a given peer may simultaneously access the network 169 via multiple authenticators, or via multiple physical or logical 170 ports on a given authenticator. Similarly, an authenticator may 171 offer network access to multiple peers, each via a separate physical 172 or logical port. 174 The peer may be stationary, in which case it may establish 175 communications with one or more authenticators while remaining in one 176 location. Alternatively, the peer may be mobile, changing its point 177 of attachment from one authenticator to another, or moving between 178 points of attachment on a single authenticator. 180 Where authenticators are deployed standalone, the EAP conversation 181 occurs between the peer and authenticator, and the authenticator must 182 locally implement an EAP method acceptable to the peer. 184 However, one of the advantages of EAP is that it enables deployment 185 of new authentication methods without requiring development of new 186 code on the authenticator. While the authenticator may implement 187 some EAP methods locally and use those methods to authenticate local 188 users, it may at the same time act as a pass-through for other users 189 and methods, forwarding EAP packets back and forth between the 190 backend authentication server and the peer. 192 +-+-+-+-+ 193 | | 194 | EAP | 195 | Peer | 196 | | 197 +-+-+-+-+ 198 | | | Peer Ports 199 / | \ 200 / | \ 201 Phase 0: Discovery / | \ 202 Phase 1: Authentication / | \ 203 Phase 2: Secure / | \ 204 Association / | \ 205 / | \ 206 / | \ 207 | | | | | | | | | Authenticator Ports 208 +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ 209 | | | | | | 210 | Auth. | | Auth. | | Auth. | 211 | | | | | | 212 +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ 213 \ | / 214 \ | / 215 \ | / 216 EAP over AAA \ | / 217 (optional) \ | / 218 \ | / 219 \ | / 220 \ | / 221 +-+-+-+-+ 222 | | 223 | AAA | 224 |Server | 225 | | 226 +-+-+-+-+ 228 Figure 1: Relationship between peer, authenticator and backend server 230 This is accomplished by encapsulating EAP packets within the 231 Authentication, Authorization and Accounting (AAA) protocol, spoken 232 between the authenticator and backend authentication server. AAA 233 protocols supporting EAP include RADIUS [RFC3579] and Diameter [I- 234 D.ietf-aaa-eap]. 236 Where EAP key derivation is supported, the conversation between the 237 peer and the authenticator typically takes place in three phases: 239 Phase 0: Discovery 240 Phase 1: Authentication 241 1a: EAP authentication 242 1b: AAA-Key Transport (optional) 243 Phase 2: Secure Association Establishment 244 2a: Unicast Secure Association 245 2b: Multicast Secure Association (optional) 247 In the discovery phase (phase 0), peers locate authenticators and 248 discover their capabilities. For example, a peer may locate an 249 authenticator providing access to a particular network, or a peer may 250 locate an authenticator behind a bridge with which it desires to 251 establish a Secure Association. 253 The authentication phase (phase 1) may begin once the peer and 254 authenticator discover each other. This phase always includes EAP 255 authentication (phase 1a). Where the chosen EAP method supports key 256 derivation, in phase 1a keying material is derived on both the peer 257 and the EAP server. This keying material may be used for multiple 258 purposes, including protection of the EAP conversation and subsequent 259 data exchanges. 261 An additional step (phase 1b) is required in deployments which 262 include a backend authentication server, in order to transport keying 263 material (known as the AAA-Key) from the backend authentication 264 server to the authenticator. 266 A Secure Association exchange (phase 2) then occurs between the peer 267 and authenticator in order to manage the creation and deletion of 268 unicast (phase 2a) and multicast (phase 2b) security associations 269 between the peer and authenticator. 271 The conversation phases and relationship between the parties is shown 272 in Figure 2. 274 EAP peer Authenticator Auth. Server 275 -------- ------------- ------------ 276 |<----------------------------->| | 277 | Discovery (phase 0) | | 278 |<----------------------------->|<----------------------------->| 279 | EAP auth (phase 1a) | AAA pass-through (optional) | 280 | | | 281 | |<----------------------------->| 282 | | AAA-Key transport | 283 | | (optional; phase 1b) | 284 |<----------------------------->| | 285 | Unicast Secure association | | 286 | (phase 2a) | | 287 | | | 288 |<----------------------------->| | 289 | Multicast Secure association | | 290 | (optional; phase 2b) | | 291 | | | 293 Figure 2: Conversation Overview 295 1.3.1. Discovery Phase 297 In the discovery phase (phase 0), the EAP peer and authenticator 298 locate each other and discover each other's capabilities. Discovery 299 can occur manually or automatically, depending on the lower layer 300 over which EAP runs. Since discovery is handled outside of EAP, 301 there is no need to provide this functionality within EAP. 303 For example, where EAP runs over PPP, the EAP peer might be 304 configured with a phone book providing phone numbers of 305 authenticators and associated capabilities such as supported rates, 306 authentication protocols or ciphersuites. 308 In contrast, PPPoE [RFC2516] provides support for a Discovery Stage 309 to allow a peer to identify the Ethernet MAC address of one or more 310 authenticators and establish a PPPoE SESSION_ID. 312 IEEE 802.11 [IEEE80211] also provides integrated discovery support 313 utilizing Beacon and/or Probe Request/Response frames, allowing the 314 peer (known as the station or STA) to determine the MAC address and 315 capabilities of one or more authenticators (known as Access Point or 316 APs). 318 1.3.2. Authentication Phase 320 Once the peer and authenticator discover each other, they exchange 321 EAP packets. Typically, the peer desires access to the network, and 322 the authenticators provide that access. In such a situation, access 323 to the network can be provided by any authenticator attaching to the 324 desired network, and the EAP peer is typically willing to send data 325 traffic through any authenticator that can demonstrate that it is 326 authorized to provide access to the desired network. 328 An EAP authenticator may handle the authentication locally, or it may 329 act as a pass-through to a backend authentication server. In the 330 latter case the EAP exchange occurs between the EAP peer and a 331 backend authenticator server, with the authenticator forwarding EAP 332 packets between the two. The entity which terminates EAP 333 authentication with the peer is known as the EAP server. Where pass- 334 through is supported, the backend authentication server functions as 335 the EAP server; where authentication occurs locally, the EAP server 336 is the authenticator. Where a backend authentication server is 337 present, at the successful completion of an authentication exchange, 338 the AAA-Key is transported to the authenticator (phase 1b). 340 EAP may also be used when it is desired for two network devices (e.g. 341 two switches or routers) to authenticate each other, or where two 342 peers desire to authenticate each other and set up a secure 343 association suitable for protecting data traffic. 345 Some EAP methods exist which only support one-way authentication; 346 however, EAP methods deriving keys are required to support mutual 347 authentication. In either case, it can be assumed that the parties 348 do not utilize the link to exchange data traffic unless their 349 authentication requirements have been met. For example, a peer 350 completing mutual authentication with an EAP server will not send 351 data traffic over the link until the EAP server has authenticated 352 successfully to the peer, and a Secure Association has been 353 negotiated. 355 Since EAP is a peer-to-peer protocol, an independent and simultaneous 356 authentication may take place in the reverse direction. Both peers 357 may act as authenticators and authenticatees at the same time. 359 Successful completion of EAP authentication and key derivation by a 360 peer and EAP server does not necessarily imply that the peer is 361 committed to joining the network associated with an EAP server. 362 Rather, this commitment is implied by the creation of a security 363 association between the EAP peer and authenticator, as part of the 364 Secure Association Protocol (phase 2). As a result, EAP may be used 365 for "pre-authentication" in situations where it is necessary to pre- 366 establish EAP security associations in order to decrease handoff or 367 roaming latency. 369 1.3.3. Secure Association Phase 371 The Secure Association phase (phase 2) always occurs after the 372 completion of EAP authentication (phase 1a) and key transport (phase 373 1b), and typically supports the following features: 375 [1] Entity Naming. A basic feature of a Secure Association Protocol is 376 the naming of the parties engaged in the exchange. As illustrated 377 in Figure 1, it is possible for both the peer and NAS to have more 378 than one physical or virtual port. For the purposes of 379 identification, it is therefore not possible to identify either 380 peers or NAS devices using port identifiers. Proper identification 381 of the parties is critical to the Secure Association phase, since 382 without this the parties engaged in the exchange are not identified 383 and the scope of the transient session keys (TSKs) generated during 384 the exchange is undefined. 386 [2] Secure capabilities negotiation. This provides for the secure 387 negotiation of usage modes, session parameters (such as key 388 lifetimes), ciphersuites, and required filters, including 389 confirmation of the capabilities discovered during phase 0. By 390 securely negotiating session parameters, the secure Association 391 Protocol protects against spoofing during the discovery phase and 392 ensures that the peer and authenticator are in agreement about how 393 data is to be secured. 395 [3] Generation of fresh transient session keys (TSKs). The Secure 396 Association Protocol typically guarantees the freshness of session 397 keys by exchanging nonces between both parties and then mixing the 398 nonces with the AAA-Key in order to generate fresh unicast (phase 399 2a) and multicast (phase 2b) session keys. By not using the AAA- 400 Key directly to protect data, the secure Association Protocol 401 protects against compromise of the AAA-Key, and by guaranteeing the 402 freshness of transient session keys, assures that they are not 403 reused. 405 [4] Key activation and deletion. In order for the peer and 406 authenticator to communicate securely, it is necessary for both 407 sides to derive the same session keys, and remain in sync with 408 respect to key state going forward. One of the functions of the 409 Secure Association Protocol is to synchronize the activation and 410 deletion of keys so as to enable seamless rekey, or recovery from 411 partial or complete loss of key state by the peer or authenticator. 413 [5] Mutual proof of possession of the AAA-Key. This demonstrates that 414 both the peer and authenticator have been authenticated and 415 authorized by the backend authentication server. Since mutual 416 proof of possession is not the same as mutual authentication, the 417 peer cannot verify authenticator assertions (including the 418 authenticator identity) as a result of this exchange. 420 1.4. EAP Invariants 422 By utilizing a three phase exchange, the EAP key management framework 423 guarantees that certain basic characteristics, known as the "EAP 424 Invariants" hold true for all implementations of EAP. These include: 426 Media independence 427 Method independence 428 Ciphersuite independence 430 1.4.1. Media Independence 432 One of the goals of EAP is to allow EAP methods to function on any 433 lower layer meeting the criteria outlined in [RFC3748], Section 3.1. 434 For example, as described in [RFC3748], EAP authentication can be run 435 over PPP [RFC1661], IEEE 802 wired networks [IEEE8021X], and IEEE 436 802.11 wireless LANs [IEEE80211i]. 438 In order to maintain media independence, it is necessary for EAP to 439 avoid inclusion of media-specific elements. For example, EAP methods 440 cannot be assumed to have knowledge of the lower layer over which 441 they are transported, and cannot utilize identifiers associated with 442 a particular usage environment (e.g. MAC addresses). 444 The need for media independence has also motivated the development of 445 the three phase exchange. Since discovery is typically media- 446 specific, this function is handled outside of EAP, rather than being 447 incorporated within it. Similarly, the Secure Association Protocol 448 often contains media dependencies such as negotiation of media- 449 specific ciphersuites or session parameters, and as a result this 450 functionality also cannot be incorporated within EAP. 452 Note that media independence may be retained within EAP methods that 453 support channel binding or method-specific identification. An EAP 454 method need not be aware of the content of an identifier in order to 455 use it. This enables an EAP method to use media-specific identifiers 456 such as MAC addresses without compromising media independence. To 457 support channel binding, an EAP method can pass binding parameters to 458 the AAA server in the form of an opaque blob, and receive 459 confirmation of whether the parameters match, without requiring 460 media-specific knowledge. 462 1.4.2. Method Independence 464 By enabling pass-through, authenticators can support any method 465 implemented on the peer and server, not just locally implemented 466 methods. This allows the authenticator to avoid implementing code 467 for each EAP method required by peers. In fact, since a pass-through 468 authenticator is not required to implement any EAP methods at all, it 469 cannot be assumed to support any EAP method-specific code. 471 As a result, as noted in [RFC3748], authenticators must by default be 472 capable of supporting any EAP method. Since the Discovery and Secure 473 Association exchanges are also method independent, an authenticator 474 can carry out the three phase exchange without having an EAP method 475 in common with the peer. 477 This is useful where there is no single EAP method that is both 478 mandatory-to-implement and offers acceptable security for the media 479 in use. For example, the [RFC3748] mandatory-to-implement EAP method 480 (MD5-Challenge) does not provide dictionary attack resistance, mutual 481 authentication or key derivation, and as a result is not appropriate 482 for use in wireless LAN authentication [WLANREQ]. However, despite 483 this it is possible for the peer and authenticator to interoperate as 484 long as a suitable EAP method is supported on the EAP server. 486 1.4.3. Ciphersuite Independence 488 While EAP methods may negotiate the ciphersuite used in protection of 489 the EAP conversation, the ciphersuite used for the protection of data 490 is negotiated within the Secure Association Protocol, out-of-band of 491 EAP. 493 The backend authentication server is not a party to this negotiation 494 nor is it an intermediary in the data flow between the EAP peer and 495 authenticator. The backend authentication server may not even have 496 knowledge of the ciphersuites implemented by the peer and 497 authenticator, or be aware of the ciphersuite negotiated between 498 them, and therefore does not implement ciphersuite-specific code. 500 Since ciphersuite negotiation occurs in the Secure Association 501 protocol, not in EAP, ciphersuite-specific key generation, if 502 implemented within an EAP method, would potentially conflict with the 503 transient session key derivation occurring in the Secure Association 504 protocol. As a result, EAP methods generate keying material that is 505 ciphersuite-independent. Additional advantages of ciphersuite- 506 independence include: 508 Update requirements 509 If EAP methods were to specify how to derive transient session keys 510 for each ciphersuite, they would need to be updated each time a new 511 ciphersuite is developed. In addition, backend authentication 512 servers might not be usable with all EAP-capable authenticators, 513 since the backend authentication server would also need to be 514 updated each time support for a new ciphersuite is added to the 515 authenticator. 517 EAP method complexity 518 Requiring each EAP method to include ciphersuite-specific code for 519 transient session key derivation would increase method complexity 520 and result in duplicated effort. 522 Knowledge of capabilities 523 In practice, an EAP method may not have knowledge of the 524 ciphersuite that has been negotiated between the peer and 525 authenticator, since this negotiation typically occurs within the 526 Secure Association Protocol. 528 For example, PPP ciphersuite negotiation occurs in the Encryption 529 Control Protocol (ECP) [RFC1968]. Since ECP negotiation occurs 530 after authentication, unless an EAP method is utilized that 531 supports ciphersuite negotiation, the peer, authenticator and 532 backend authentication server may not be able to anticipate the 533 negotiated ciphersuite and therefore this information cannot be 534 provided to the EAP method. Since ciphersuite negotiation is 535 assumed to occur out-of-band, there is no need for ciphersuite 536 negotiation within EAP. 538 2. EAP Key Hierarchy 540 2.1. Key Terminology 542 The EAP Key Hierarchy makes use of the following types of keys: 544 Long Term Credential 545 EAP methods frequently make use of long term secrets in order to 546 enable authentication between the peer and server. In the case of 547 a method based on pre-shared key authentication, the long term 548 credential is the pre-shared key. In the case of a public-key 549 based method, the long term credential is the corresponding private 550 key. 552 Master Session Key (MSK) 553 Keying material that is derived between the EAP peer and server and 554 exported by the EAP method. The MSK is at least 64 octets in 555 length. 557 Extended Master Session Key (EMSK) 558 Additional keying material derived between the peer and server that 559 is exported by the EAP method. The EMSK is at least 64 octets in 560 length, and is never shared with a third party. 562 AAA-Key 563 A key derived by the peer and EAP server, used by the peer and 564 authenticator in the derivation of Transient Session Keys (TSKs). 565 Where a backend authentication server is present, the AAA-Key is 566 transported from the backend authentication server to the 567 authenticator, wrapped within the AAA-Token; it is therefore known 568 by the peer, authenticator and backend authentication server. 569 However, despite the name, the AAA-Key is computed regardless of 570 whether a backend authentication server is present. AAA-Key 571 derivation is discussed in Appendix E; in existing implementations 572 the MSK is used as the AAA-Key. 574 Application-specific Master Session Keys (AMSKs) 575 Keys derived from the EMSK which are cryptographically separate 576 from each other and may be subsequently used in the derivation of 577 Transient Session Keys (TSKs) for extended uses. AMSK derivation 578 is discussed in Appendix E. 580 AAA-Token 581 Where a backend server is present, the AAA-Key and one or more 582 attributes is transported between the backend authentication server 583 and the authenticator within a package known as the AAA-Token. The 584 format and wrapping of the AAA-Token, which is intended to be 585 accessible only to the backend authentication server and 586 authenticator, is defined by the AAA protocol. Examples include 587 RADIUS [RFC2548] and Diameter [I-D.ietf-aaa-eap]. 589 Initialization Vector (IV) 590 A quantity of at least 64 octets, suitable for use in an 591 initialization vector field, that is derived between the peer and 592 EAP server. Since the IV is a known value in methods such as EAP- 593 TLS [RFC2716], it cannot be used by itself for computation of any 594 quantity that needs to remain secret. As a result, its use has 595 been deprecated and EAP methods are not required to generate it. 596 However, when it is generated it MUST be unpredictable. 598 Pairwise Master Key (PMK) 599 The AAA-Key is divided into two halves, the "Peer to Authenticator 600 Encryption Key" (Enc-RECV-Key) and "Authenticator to Peer 601 Encryption Key" (Enc-SEND-Key) (reception is defined from the point 602 of view of the authenticator). Within [IEEE80211i] Octets 0-31 of 603 the AAA-Key (Enc-RECV-Key) are known as the Pairwise Master Key 604 (PMK). In [IEEE80211i] the TKIP and AES CCMP ciphersuites derive 605 their Transient Session Keys (TSKs) solely from the PMK, whereas 606 the WEP ciphersuite as noted in [RFC3580], derives its TSKs from 607 both halves of the AAA-Key. 609 Transient EAP Keys (TEKs) 610 Session keys which are used to establish a protected channel 611 between the EAP peer and server during the EAP authentication 612 exchange. The TEKs are appropriate for use with the ciphersuite 613 negotiated between EAP peer and server for use in protecting the 614 EAP conversation. Note that the ciphersuite used to set up the 615 protected channel between the EAP peer and server during EAP 616 authentication is unrelated to the ciphersuite used to subsequently 617 protect data sent between the EAP peer and authenticator. An 618 example TEK key hierarchy is described in Appendix C. 620 Transient Session Keys (TSKs) 621 Session keys used to protect data which are appropriate for the 622 ciphersuite negotiated between the EAP peer and authenticator. The 623 TSKs are derived from AAA-Key during the Secure Association 624 Protocol. In the case of [IEEE80211i] the Secure Association 625 Protocol consists of the 4-way handshake and group key derivation. 626 An example TSK derivation is provided in Appendix D. 628 2.2. Key Hierarchy 630 The EAP Key Hierarchy, illustrated in Figure 3, has at the root the 631 long term credential utilized by the selected EAP method. If 632 authentication is based on a pre-shared key, the parties store the 633 EAP method to be used and the pre-shared key. The EAP server also 634 stores the peer's identity and/or other information necessary to 635 decide whether access to some service should be granted. The peer 636 stores information necessary to choose which secret to use for which 637 service. 639 If authentication is based on proof of possession of the private key 640 corresponding to the public key contained within a certificate, the 641 parties store the EAP method to be used and the trust anchors used to 642 validate the certificates. The EAP server also stores the peer's 643 identity and/or other information necessary to decide whether access 644 to some service should be granted. The peer stores information 645 necessary to choose which certificate to use for which service. 647 Based on the long term credential established between the peer and 648 the server, EAP derives four types of keys: 650 [1] Keys calculated locally by the EAP method but not exported 651 by the EAP method, such as the TEKs. 652 [2] Keys exported by the EAP method: MSK, EMSK, IV 654 [3] Keys calculated from exported quantities: AAA-Key, AMSKs. 655 [4] Keys calculated by the Secure Association Protocol: TSKs. 657 In order to protect the EAP conversation, methods supporting key 658 derivation typically negotiate a ciphersuite and derive Transient EAP 659 Keys (TEKs) for use with that ciphersuite. The TEKs are stored 660 locally by the EAP method and are not exported. 662 As noted in [RFC3748] Section 7.10, EAP methods generating keys are 663 required to calculate and export the MSK and EMSK, which must be at 664 least 64 octets in length. EAP methods also may export the IV; 665 however, the use of the IV is deprecated. 667 On both the peer and EAP server, the exported MSK and EMSK are 668 utilized in order to calculate the AAA-Key, as described in Appendix 669 E. 671 Where a backend authentication server is present, the AAA-Key is 672 transported from the backend authentication server to the 673 authenticator within the AAA-Token, using the AAA protocol. 675 Once EAP authentication completes and is successful, the peer and 676 authenticator obtain the AAA-Key and the Secure Association Protocol 677 is run between the peer and authenticator in order to securely 678 negotiate the ciphersuite, derive fresh TSKs used to protect data, 679 and provide mutual proof of possession of the AAA-Key. 681 When the authenticator acts as an endpoint of the EAP conversation 682 rather than a pass-through, EAP methods are implemented on the 683 authenticator as well as the peer. If the EAP method negotiated 684 between the EAP peer and authenticator supports mutual authentication 685 and key derivation, the EAP Master Session Key (MSK) and Extended 686 Master Session Key (EMSK) are derived on the EAP peer and 687 authenticator and exported by the EAP method. In this case, the MSK 688 and EMSK are known only to the peer and authenticator and no other 689 parties. The TEKs and TSKs also reside solely on the peer and 690 authenticator. This is illustrated in Figure 4. As demonstrated in 691 [I-D.ietf-roamops-cert], in this case it is still possible to support 692 roaming between providers, using certificate-based authentication. 694 Where a backend authentication server is utilized, the situation is 695 illustrated in Figure 5. Here the authenticator acts as a pass- 696 through between the EAP peer and a backend authentication server. In 697 this model, the authenticator delegates the access control decision 698 to the backend authentication server, which acts as a Key 699 Distribution Center (KDC). In this case, the authenticator 700 encapsulates EAP packet with a AAA protocol such as RADIUS [RFC3579] 701 or Diameter [I-D.ietf-aaa-eap], and forwards packets to and from the 702 backend authentication server, which acts as the EAP server. Since 703 the authenticator acts as a pass-through, EAP methods reside only on 704 the peer and EAP server As a result, the TEKs, MSK and EMSK are 705 derived on the peer and EAP server. 707 On completion of EAP authentication, EAP methods on the peer and EAP 708 server export the Master Session Key (MSK) and Extended Master 709 Session Key (EMSK). The peer and EAP server then calculate the AAA- 710 Key from the MSK and EMSK, and the backend authentication server 711 sends an Access-Accept to the authenticator, providing the AAA-Key 712 within a protected package known as the AAA-Token. 714 The AAA-Key is then used by the peer and authenticator within the 715 Secure Association Protocol to derive Transient Session Keys (TSKs) 716 required for the negotiated ciphersuite. The TSKs are known only to 717 the peer and authenticator. 719 2.3. Key Lifetimes 721 As noted earlier, the EAP Key Management framework includes several 722 types of keys, including: 724 [1] Keys calculated locally by the EAP method but not exported 725 by the EAP method, such as the TEKs. 726 [2] Keys exported by the EAP method: MSK, EMSK, IV 727 [3] Keys calculated from exported quantities: AAA-Key, AMSKs. 728 [4] Keys calculated by the Secure Association Protocol: TSKs. 730 Key lifetime issues associated with each type of key are discussed in 731 the sections that follow. Challenges include: 733 [a] Security. Where key lifetimes cannot be assumed, it may be 734 necessary to negotiate them. While key lifetimes may be announced 735 or negotiated in the clear, a protected lifetime negotiation is 736 RECOMMENDED. 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 739 | | ^ 740 | EAP Method | | 741 | | | 742 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | | 743 | | | | | | | 744 | | EAP Method Key |<->| Long-Term | | | 745 | | Derivation | | Credential | | | 746 | | | | | | | 747 | | | +-+-+-+-+-+-+-+ | Local to | 748 | | | | EAP | 749 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Method | 750 | | | | | | 751 | | | | | | 752 | | | | | | 753 | | | | | | 754 | V | | | | 755 | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | | 756 | | TEK | | MSK | |EMSK | |IV | | | 757 | |Derivation | |Derivation | |Derivation | |Derivation | | | 758 | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | | 759 | | | | | | 760 | | | | | V 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 762 | | | ^ 763 | | | | 764 | MSK (64B) | EMSK (64B) | IV (64B) | 765 | | | Exported| 766 | | | by | 767 V V V EAP | 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ Method| 769 | AAA Key Derivation, | | Known | | 770 | Naming & Binding | |(Not Secret) | | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ V 772 | ---+ 773 | Transported | 774 | AAA-Key by AAA | 775 | Protocol | 776 V V 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 778 | | ^ 779 | TSK | Ciphersuite | 780 | Derivation | Specific | 781 | | V 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 784 Figure 3: EAP Key Hierarchy 786 +-+-+-+-+-+ +-+-+-+-+-+ 787 | | | | 788 | | | | 789 | Cipher- | | Cipher- | 790 | Suite | | Suite | 791 | | | | 792 +-+-+-+-+-+ +-+-+-+-+-+ 793 ^ ^ 794 | | 795 | | 796 | | 797 V V 798 +-+-+-+-+-+ +-+-+-+-+-+ 799 | | | | 800 | |===============| | 801 | |EAP, TEK Deriv.|Authenti-| 802 | |<------------->| cator | 803 | | | | 804 | | Secure Assoc. | | 805 | peer |<------------->| (EAP | 806 | |===============| server) | 807 | | Link layer | | 808 | | (PPP,IEEE802) | | 809 | | | | 810 |MSK,EMSK | |MSK,EMSK | 811 | AAA-Key | | AAA-Key | 812 | (TSKs) | | (TSKs) | 813 | | | | 814 +-+-+-+-+-+ +-+-+-+-+-+ 815 ^ ^ 816 | | 817 | MSK, EMSK | MSK, EMSK 818 | | 819 | | 820 +-+-+-+-+-+ +-+-+-+-+-+ 821 | | | | 822 | EAP | | EAP | 823 | Method | | Method | 824 | | | | 825 | (TEKs) | | (TEKs) | 826 | | | | 827 +-+-+-+-+-+ +-+-+-+-+-+ 829 Figure 4: Relationship between EAP peer and authenticator (acting 830 as an EAP server), where no backend authentication server is 831 present. 833 +-+-+-+-+-+ +-+-+-+-+-+ 834 | | | | 835 | | | | 836 | Cipher- | | Cipher- | 837 | Suite | | Suite | 838 | | | | 839 +-+-+-+-+-+ +-+-+-+-+-+ 840 ^ ^ 841 | | 842 | | 843 | | 844 V V 845 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 846 | |===============| |========| | 847 | |EAP, TEK Deriv.| | | | 848 | |<-------------------------------->| backend | 849 | | | | | | 850 | | Secure Assoc. | | AAA-Key| | 851 | peer |<------------->|Authenti-|<-------| auth | 852 | |===============| cator |========| server | 853 | | Link Layer | | AAA | (EAP | 854 | | (PPP,IEEE 802)| |Protocol| server) | 855 |MSK,EMSK | | | | | 856 | AAA-Key | | AAA-Key | |MSK,EMSK,| 857 | (TSKs) | | (TSKs) | | AAA-Key | 858 | | | | | | 859 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 860 ^ ^ 861 | | 862 | MSK, EMSK | MSK, EMSK 863 | | 864 | | 865 +-+-+-+-+-+ +-+-+-+-+-+ 866 | | | | 867 | EAP | | EAP | 868 | Method | | Method | 869 | | | | 870 | (TEKs) | | (TEKs) | 871 | | | | 872 +-+-+-+-+-+ +-+-+-+-+-+ 874 Figure 5: Pass-through relationship between EAP peer, authenticator 875 and backend authentication server. 877 [b] Resource reclaimation. While key lifetimes may be securely 878 negotiated, it is possible for the NAS or peer to reboot or reclaim 879 resources, and therefore not be able to cache keys for their full 880 lifetime. As a result, lifetime negotiation does not guarantee 881 that the key cache will remain sychronized. It is therefore 882 RECOMMENDED for the lower layer to provide a mechanism for key 883 state resynchronization. Note that securing this mechanism may be 884 difficult since in this situation one or more of the parties 885 initially do not possess a key with which to protect the 886 resynchronization exchange. 888 2.3.1. Local Key Lifetimes 890 The Transient EAP Keys (TEKs) are session keys used to protect the 891 EAP conversation. The TEKs are internal to the EAP method and are 892 not exported. They remain valid only for the duration of the EAP 893 conversation, and are lost once the EAP conversation completes. 895 EAP methods may also implement a cache for other local keying 896 material which may persist for multiple EAP conversations. For 897 example, EAP methods based on TLS (such as EAP-TLS [RFC2716]) derive 898 and cache the TLS Master Secret, typically for substantial time 899 periods. The lifetime of other local keying material calculated 900 within the EAP method is defined by the method. 902 2.3.2. Exported Key Lifetimes 904 All EAP methods generating keys are required to generate the MSK and 905 EMSK, and may optionally generate the IV. However, although new 906 exported keys are generated during reauthentication, the lifetime of 907 exported keys is conceptually distinct from the reauthentication 908 time, since while reauthentication causes new exported keys to be 909 derived, exported keys may be cached on the peer and server after a 910 session completes and therefore their lifetime may be greater than 911 the reauthentication time. 913 Although exported keys are generated by the EAP method, most existing 914 EAP methods do not negotiate the lifetime of the exported keys. EAP, 915 defined in [RFC3748], also does not support the negotiation of 916 lifetimes for exported keying material such as the MSK, EMSK and IV. 918 Several mechanisms exist for managing the lifetime of exported EAP 919 keys. Exported EAP keys may be cached on the EAP server as well as 920 on the peer. On the EAP server, it is RECOMMENDED that the lifetime 921 of exported keys be managed as a system parameter. Where the EAP 922 method does not support the negotiation of the exported key lifetime, 923 and where a negotiation mechanism is not provided by the lower lower, 924 it is RECOMMENDED that the peer assume a default value of the 925 exported key lifetime. A value of 8 hours is suggested. 927 Managing the lifetime of exported keys using a AAA attribute is NOT 928 RECOMMENDED. This is problematic because although this would ensure 929 transport of the exported key lifetime between the AAA server and the 930 authenticator, the goal is to synchronize the exported key lifetime 931 between the peer and EAP server. Providing the the exported key 932 lifetime on an per-session basis to the authenticator results in 933 requiring the authenticator to maintain EAP-Key SA state. As a 934 described in Section 3, EAP-Key SA state is typically only maintained 935 on the peer and server, so that this represents a substantial 936 additional burden. 938 2.3.3. Calculated Key Lifetimes 940 When keying material exported by EAP methods is replaced, new 941 calculated keys are also put in place. Similarly, when the keying 942 material exported by EAP methods expires, so do the calculated keys. 943 As a result, the lifetime of keys calculated from material exported 944 by EAP methods can be no larger than the lifetime of the keying 945 material they are calculated from. Since the lifetime of calculated 946 keys can be less than that of the exported keys they are derived 947 from, calculated key lifetimes are conceptually distinct from 948 exported key lifetimes and reauthentication times, and need to be 949 managed as a separate parameter. 951 Note that just as the reauthentication time and the exported key 952 lifetime are conceptually distinct parameters, so too are calculated 953 key lifetimes conceptually distinct from the reauthentication time. 955 Today AAA protocols such as RADIUS [RFC2865] support the Session- 956 Timeout attribute. As described in [RFC3580], this may be used to 957 determine the maximum session time prior to reauthentication. Since 958 reauthentication results in the derivation of new exported keys and 959 the transport of a new AAA-Key, while a session is in progress the 960 maximum session time prior to reauthentication places an upper bound 961 on the AAA-Key lifetime. 963 However, after the session has terminated, it is possible for the 964 AAA-Key to be cached on the authenticator. Therefore the AAA-Key 965 lifetime may be larger than the reauthentication time. As a result, 966 the AAA-Key lifetime needs to be managed as a separate parameter. 968 Since the lifetime of the AAA-Key within the authenticator key cache 969 is in part determined by authenticator resources, the AAA-Key 970 lifetime is typically managed as a system parameter on the 971 authenticator. Since the authenticator may have considerably fewer 972 resources than either the EAP peer or server, it is possible that 973 AAA-Key lifetime on the authenticator may be less than exported key 974 lifetime maintained by the server, or that the authenticator may need 975 to reclaim AAA-Key resources prior to expiration of the AAA-Key 976 lifetime. 978 As a result, the primary issue with managing the AAA-Key lifetime is 979 the determination by the peer whether a particular AAA-Key exists 980 within the key cache of a given authenticator. Transmitting the AAA- 981 Key lifetime from the AAA server to the authenticator is not helpful 982 in solving this problem in several important scenarios. 984 Where the AAA-key lifetime is negotiated between the authenticator 985 and the peer within the Secure Association Protocol, this may be used 986 by the peer to manage the lifetime of the AAA-Key once the Secure 987 Association Protocol has completed. 989 However, should a time gap may exist between the time of completion 990 of the EAP method and the initiation of the Secure Association 991 Protocol, the lifetime of the AAA-Key cannot be determined by the 992 peer during this period. As a result, unless the Secure Association 993 Protocol always follos the completion of the EAP method exchange 994 without a gap in time, it may not be possible for the peer and 995 authenticator to negotiate session-specific value of the AAA-Key 996 lifetime. For example, where EAP pre-authentication is used, the 997 AAA-Key may be derived and remain resident on the peer and 998 authenticator prior to initiation of the Secure Association Protocol. 1000 However, if the AAA-Key lifetime is managed as an authenticator 1001 system parameter, it may be possible for lower layer solutions to 1002 bridge the gap. For example, the lower layer may utilize Discovery 1003 mechanisms to ensure AAA-Key cache synchronization between the peer 1004 and authenticator. 1006 If the authenticator manages the AAA-Key cache by deleting the oldest 1007 AAA-Key first (LIFO), the relative creation time of the last AAA-Key 1008 to be deleted could be advertised with the Discovery phase, enabling 1009 the peer to determine whether a given AAA-Key had been expired from 1010 the authenticator key cache. 1012 2.3.4. TSK Key Lifetimes 1014 Since the TSKs depend on the AAA-Key, replacement of the AAA-Key 1015 implies replacement of the TSKs. However, replacement of the TSKs 1016 only implies replacement of the AAA-Key when the TSKs are taken from 1017 a portion of the AAA-Key. 1019 Therefore while the lifetime of the TSKs may be shorter than or equal 1020 to the AAA-Key lifetime, the TSK lifetime cannot exceed the AAA-Key 1021 lifetime. Where a Secure Association Protocol exists, it is possible 1022 for TSKs to be refreshed prior to reauthentication, and so the TSK 1023 Key Lifetime may also be shorter than or equal to the 1024 reauthentication timeout. It is therefore RECOMMENDED that the TSK 1025 Key lifetime be managed parameter distinct from the reauthentication 1026 timeout and the AAA-Key lifetime (except where the TSK is taken from 1027 the AAA-Key). 1029 Where TSKs are established as the result of a Secure Association 1030 Protocol exchange, it is RECOMMENDED that the Secure Association 1031 Protocol include secure negotiation of the TSK lifetime between the 1032 peer and authenticator. Where the TSK is taken from the AAA-Key, 1033 there is no need to manage the TSK lifetime as a separate parameter, 1034 since the TSK lifetime and AAA-Key lifetime are identical. 1036 As described in Section 3, TSKs are part of Service SAs which reside 1037 on the peer and authenticator and as with the AAA-Key lifetime, the 1038 TSK lifetime is often determined by authenticator resources. As a 1039 result, the AAA server has no insight into the TSK derivation 1040 process, and by the principle of ciphersuite independence, it is not 1041 appropriate for the AAA server to manage any aspect of the TSK 1042 derivation process, including the TSK lifetime. 1044 2.4. AAA-Key Scope 1046 As described in Appendix E, the AAA-Key is calculated from the EMSK 1047 and MSK by the EAP peer and server, and is used as the root of the 1048 ciphersuite-specific key hierarchy. Where a backend authentication 1049 server is present, the AAA-Key is transported from the EAP server to 1050 the authenticator; where it is not present, the AAA-Key is calculated 1051 on the authenticator. 1053 The AAA-Key is restricted to use between the EAP peer that calculates 1054 it, and the authenticator that either calculates it (where no backend 1055 authenticator is present) or receives it from the server (where a 1056 backend authenticator server is present). However, in practice 1057 difficulties arise in ensuring that the AAA-Key is used only within 1058 the defined scope. 1060 A wide variety of authenticator and peer designs need to be 1061 accomodated within the EAP key management framework. An 1062 authenticator may contain multiple physical ports; a single physical 1063 authenticator may, for the purpose of peer discovery, advertise 1064 itself as multiple "virtual authenticators"; authenticators may be 1065 compromised of multiple CPUs; authenticators may utilize clustering 1066 in order to provide load balancing or failover. Similarly, a peer 1067 may support multiple ports; may support multiple CPUs; or may support 1068 clustering. 1070 As illustrated in Figure 1, an EAP peer with multiple ports may be 1071 attached to one or more authenticators, each with multiple ports. 1072 Where an authenticator identifies itself to the peer only via use of 1073 a port identifer (such as a link layer address), it may not be 1074 obvious to the peer which authenticator ports are associated with 1075 which authenticators. 1077 Similarly, where an EAP peer identifies itself using a port 1078 identifier (such as a link layer address), it may not be obvious to 1079 the authenticator which peer ports are associated with which peers. 1080 In such situations, the peer and authenticator may not be able to 1081 determine the appropriate AAA-Key scope. 1083 Additional issues arise when a single physical authenticator 1084 advertises itself as multiple "virtual authenticators". In such a 1085 situation, the EAP peer may act as though each "virtual 1086 authenticator" represented a distinct physical authenticator, thereby 1087 restricting the AAA-Key to use with the "virtual authenticator" that 1088 it interacts with. However, depending on the architecture of the 1089 physical AP, it may or may not share AAA-Keys between "virtual 1090 authenticators". Once again, the peer and authenticator may not be 1091 in agreement on the AAA-key scope. 1093 This lack of synchronization may create security vulnerabilities. 1094 For example, where the AAA-Key is shared between "virtual 1095 authenticators" an EAP peer could authenticate with the "Guest" 1096 "virtual authenticator" and derive a AAA-Key. The peer could then 1097 use that AAA-Key within the Secure Association Protocol in order to 1098 connect to the "Corporate Intranet" "virtual authenticator" within 1099 the same physical authenticator. If the "virtual authenticators" 1100 share a AAA-Key cache, then the attempt will be successful. 1102 Several measures are recommended to address these issues: 1104 [a] Authenticators are REQUIRED to cache associated authorizations 1105 along with the AAA-Key and apply authorizations consistently. This 1106 ensures that an attacker cannot obtain elevated privileges even 1107 where the AAA-Key cache is shared between "virtual authenticators". 1109 [b] It is RECOMMENDED that Secure Association Protocols utilize peer 1110 and authenticator identities that are unambiguous and do not 1111 incorporate implicit assumptions about peer and authenticator 1112 architectures. 1114 For example, using port-specific MAC addresses as identifiers is a 1115 particularly poor choice, given that peers and authenticators may 1116 have multiple ports. 1118 [c] It is RECOMMENDED that physical authenticators maintain separate 1119 AAA-Key caches for each "virtual authenticator". 1121 [d] Where a "virtual authenticator" is implemented, the AAA client MAY 1122 also be virtualized. Where a "virtual AAA client" is implemented, 1123 each "virtual authenticator" identifies itself distinctly to the 1124 AAA server. Where the AAA client and server communicate directly, 1125 this enables the AAA server to authenticate each "virtual AAA 1126 client" distinctly. 1128 [e] The AAA server and authenticator MAY implement additional 1129 attributes in order to further restrict the AAA-Key scope. When 1130 this is done, it is RECOMMENDED that the Secure Association 1131 Protocol be extended to enable the restrictions to be communicated 1132 between the authenticator and the peer. For example, in 802.11, 1133 the AAA server may provide the authenticator with a list of 1134 authorized Called-Station-Ids and/or SSIDs for which the AAA-Key 1135 is valid, restricting the use of the AAA-Key by the peer. 1136 Similarly, the authenticator may provide the peer with a list of 1137 Calling-Station-Ids for which the AAA-Key is valid. 1139 2.5. Fast Handoff Support 1141 Within EAP, "fast handoff" is defined as a conversation in which the 1142 EAP exchange (phase 1a) and associated AAA passthrough is bypassed, 1143 so as to reduce latency. Depending on the fast handoff mechanism, 1144 AAA-Key transport (phase 1b) may also be bypassed or it may be 1145 provided in a pre-emptive manner as in [IEEE-03-084] and [I-D.irtf- 1146 aaaarch-handoff]. 1148 The introduction of fast handoff creates a new class of security 1149 vulnerabilities as well as requirements for the secure handling of 1150 authorization context. 1152 2.5.1. Authorization Issues 1154 In a typical network access scenario (dial-in, wireless LAN, etc.) 1155 access control mechanisms are typically applied. These mechanisms 1156 include user authentication as well as authorization for the offered 1157 service. 1159 As a part of the authentication process, the AAA network determines 1160 the user's authorization profile. The user authorizations are 1161 transmitted by the backend authentication server to the EAP 1162 authenticator (also known as the Network Access Server or 1163 authenticator) included with the AAA-Token, which also contains the 1164 AAA-Key, in Phase 1b of the EAP conversation. Typically, the profile 1165 is determined based on the user identity, but a certificate presented 1166 by the user may also provide authorization information. 1168 The backend authentication server is responsible for making a user 1169 authorization decision, answering the following questions: 1171 [a] Is this a legitimate user for this particular network? 1173 [b] Is this user allowed the type of access he or she is requesting? 1175 [c] Are there any specific parameters (mandatory tunneling, bandwidth, 1176 filters, and so on) that the access network should be aware of for 1177 this user? 1179 [d] Is this user within the subscription rules regarding time of day? 1181 [e] Is this user within his limits for concurrent sessions? 1183 [f] Are there any fraud, credit limit, or other concerns that indicate 1184 that access should be denied? 1186 While the authorization decision is in principle simple, the process 1187 is complicated by the distributed nature of AAA decision making. 1188 Where brokering entities or proxies are involved, all of the AAA 1189 devices in the chain from the authenticator to the home AAA server 1190 are involved in the decision. For instance, a broker can disallow 1191 access even if the home AAA server would allow it, or a proxy can add 1192 authorizations (e.g., bandwidth limits). 1194 Decisions can be based on static policy definitions and profiles as 1195 well as dynamic state (e.g. time of day or limits on the number of 1196 concurrent sessions). In addition to the Accept/Reject decision made 1197 by the AAA chain, parameters or constraints can be communicated to 1198 the authenticator. 1200 The criteria for Accept/Reject decisions or the reasons for choosing 1201 particular authorizations are typically not communicated to the 1202 authenticator, only the final result. As a result, the authenticator 1203 has no way to know what the decision was based on. Was a set of 1204 authorization parameters sent because this service is always provided 1205 to the user, or was the decision based on the time/day and the 1206 capabilities of the requesting authenticator device? 1208 2.5.2. Correctness in Fast Handoff 1210 Bypassing all or portions of the AAA conversation creates challenges 1211 in ensuring that authorization is properly handled. These include: 1213 [a] Consistent application of session time limits. A fast handoff 1214 should not automatically increase the available session time, 1215 allowing a user to endlessly extend their network access by 1216 changing the point of attachment. 1218 [b] Avoidance of privilege elevation. A fast handoff should not result 1219 in a user being granted access to services which they are not 1220 entitled to. 1222 [c] Consideration of dynamic state. In situations in which dynamic 1223 state is involved in the access decision (day/time, simultaneous 1224 session limit) it should be possible to take this state into 1225 account either before or after access is granted. Note that 1226 consideration of network-wide state such as simultaneous session 1227 limits can typically only be taken into account by the backend 1228 authentication server. 1230 [d] Encoding of restrictions. Since a authenticator may not be aware 1231 of the criteria considered by a backend authentication server when 1232 allowing access, in order to ensure consistent authorization during 1233 a fast handoff it may be necessary to explicitly encode the 1234 restrictions within the authorizations provided in the AAA-Token. 1236 [e] State validity. The introduction of fast handoff should not render 1237 the authentication server incapable of keeping track of network- 1238 wide state. 1240 A fast handoff mechanism capable of addressing these concerns is 1241 said to be "correct". One condition for correctness is as follows: 1242 For a fast handoff to be "correct" it MUST establish on the new 1243 device the same context as would have been created had the new 1244 device completed a AAA conversation with the authentication server. 1246 A properly designed fast handoff scheme will only succeed if it is 1247 "correct" in this way. If a successful fast handoff would 1248 establish "incorrect" state, it is preferable for it to fail, in 1249 order to avoid creation of incorrect context. 1251 Some backend authentication server and authenticator configurations 1252 are incapable of meeting this definition of "correctness". For 1253 example, if the old and new device differ in their capabilities, it 1254 may be difficult to meet this definition of correctness in a fast 1255 handoff mechanism that bypasses AAA. Backend authentication 1256 servers often perform conditional evaluation, in which the 1257 authorizations returned in an Access-Accept message are contingent 1258 on the authenticator or on dynamic state such as the time of day or 1259 number of simultaneous sessions. For example, in a heterogeneous 1260 deployment, the backend authentication server might return 1261 different authorizations depending on the authenticator making the 1262 request, in order to make sure that the requested service is 1263 consistent with the authenticator capabilities. 1265 If differences between the new and old device would result in the 1266 backend authentication server sending a different set of messages 1267 to the new device than were sent to the old device, then if the 1268 fast handoff mechanism bypasses AAA, then the fast handoff cannot 1269 be carried out correctly. 1271 For example, if some authenticator devices within a deployment 1272 support dynamic VLANs while others do not, then attributes present 1273 in the Access-Request (such as the authenticator-IP-Address, 1274 authenticator-Identifier, Vendor-Identifier, etc.) could be 1275 examined to determine when VLAN attributes will be returned, as 1276 described in [RFC3580]. VLAN support is defined in [IEEE8021Q]. 1277 If a fast handoff bypassing the backend authentication server were 1278 to occur between a authenticator supporting dynamic VLANs and 1279 another authenticator which does not, then a guest user with access 1280 restricted to a guest VLAN could be given unrestricted access to 1281 the network. 1283 Similarly, in a network where access is restricted based on the day 1284 and time, Service Set Identifier (SSID), Calling-Station-Id or 1285 other factors, unless the restrictions are encoded within the 1286 authorizations, or a partial AAA conversation is included, then a 1287 fast handoff could result in the user bypassing the restrictions. 1289 In practice, these considerations limit the situations in which 1290 fast handoff mechanisms bypassing AAA can be expected to be 1291 successful. Where the deployed devices implement the same set of 1292 services, it may be possible to do successful fast handoffs within 1293 such mechanisms. However, where the supported services differ 1294 between devices, the fast handoff may not succeed. For example, 1295 [RFC2865], section 1.1 states: 1297 "A authenticator that does not implement a given service MUST 1298 NOT implement the RADIUS attributes for that service. For 1299 example, a authenticator that is unable to offer ARAP service 1300 MUST NOT implement the RADIUS attributes for ARAP. A 1301 authenticator MUST treat a RADIUS access-accept authorizing an 1302 unavailable service as an access-reject instead." 1304 Note that this behavior only applies to attributes that are known, 1305 but not implemented. For attributes that are unknown, section of 5 1306 of [RFC2865] states: 1308 "A RADIUS server MAY ignore Attributes with an unknown Type. A 1309 RADIUS client MAY ignore Attributes with an unknown Type." 1311 In order to perform a correct fast handoff, if a new device is 1312 provided with RADIUS context for a known but unavailable service, 1313 then it MUST process this context the same way it would handle a 1314 RADIUS Access-Accept requesting an unavailable service. This MUST 1315 cause the fast handoff to fail. However, if a new device is 1316 provided with RADIUS context that indicates an unknown attribute, 1317 then this attribute MAY be ignored. 1319 Although it may seem somewhat counter-intuitive, failure is indeed 1320 the "correct" result where a known but unsupported service is 1321 requested. Presumably a correctly configured backend authentication 1322 server would not request that a device carry out a service that it 1323 does not implement. This implies that if the new device were to 1324 complete a AAA conversation that it would be likely to receive 1325 different service instructions. In such a case, failure of the 1326 fast handoff is the desired result. This will cause the new device 1327 to go back to the AAA server in order to receive the appropriate 1328 service definition. 1330 In practice, this implies that fast handoff mechanisms which bypass 1331 AAA are most likely to be successful within a homogeneous device 1332 deployment within a single administrative domain. For example, it 1333 would not be advisable to carry out a fast handoff bypassing AAA 1334 between a authenticator providing confidentiality and another 1335 authenticator that does not support this service. The correct 1336 result of such a fast handoff would be a failure, since if the 1337 handoff were blindly carried out, then the user would be moved from 1338 a secure to an insecure channel without permission from the backend 1339 authentication server. Thus the definition of a "known but 1340 unsupported service" MUST encompass requests for unavailable 1341 security services. This includes vendor-specific attributes 1342 related to security, such as those described in [RFC2548]. 1344 3. Security Associations 1346 During EAP authentication and subsequent exchanges, four types of 1347 security associations (SAs) are created: 1349 [1] EAP method SA. This SA is between the peer and EAP server. It 1350 stores state that can be used for "fast resume" or other 1351 functionality in some EAP methods. Not all EAP methods create such 1352 an SA. 1354 [2] EAP-Key SA. This is an SA between the peer and EAP server, which 1355 is used to store the keying material exported by the EAP method. 1356 Current EAP server implementations do not retain this SA after the 1357 EAP conversation completes, but future implementations could use 1358 this SA for purposes such as pre-emptive key distribution. 1360 [3] AAA SA(s). These SAs are between the authenticator and the backend 1361 authentication server. They permit the parties to mutually 1362 authenticate each other and protect the communications between 1363 them. 1365 [4] Service SA(s). These SAs are between the peer and authenticator, 1366 and they are created as a result of phases 1-2 of the conversation 1367 (see Section 1.3). 1369 3.1. EAP Method SA (peer - EAP server) 1371 An EAP method may store some state on the peer and EAP server even 1372 after phase 1a has completed. 1374 Typically, this is used for "fast resume": the peer and EAP server 1375 can confirm that they are still talking to the same party, perhaps 1376 using fewer roundtrips or less computational power. In this case, 1377 the EAP method SA is essentially a cache for performance 1378 optimization, and either party may remove the SA from its cache at 1379 any point. 1381 An EAP method may also keep state in order to support pseudonym-based 1382 identity protection. This is typically a cache as well (the 1383 information can be recreated if the original EAP method SA is lost), 1384 but may be stored for longer periods of time. 1386 The EAP method SA is not restricted to a particular service or 1387 authenticator and is most useful when the peer accesses many 1388 different authenticators. 1390 An EAP method is responsible for specifying how the parties select if 1391 an existing EAP method SA should be used, and if so, which one. 1392 Where multiple backend authentication servers are used, EAP method 1393 SAs are not typically synchronized between them. 1395 EAP method implementations should consider the appropriate lifetime 1396 for the EAP method SA. "Fast resume" assumes that the information 1397 required (primarily the keys in the EAP method SA) hasn't been 1398 compromised. In case the original authentication was carried out 1399 using, for instance, a smart card, it may be easier to compromise the 1400 EAP method SA (stored on the PC, for instance), so typically the EAP 1401 method SAs have a limited lifetime. 1403 Contents: 1405 o Implicitly, the EAP method this SA refers to 1406 o One or more internal (non-exported) keys 1407 o EAP method SA name 1408 o SA lifetime 1410 3.1.1. Example: EAP-TLS 1412 In EAP-TLS [RFC2716], after the EAP authentication the client (peer) 1413 and server can store the following information: 1415 o Implicitly, the EAP method this SA refers to (EAP-TLS) 1416 o Session identifier (a value selected by the server) 1417 o Certificate of the other party (server stores the clients's 1418 certificate and vice versa) 1419 o Ciphersuite and compression method 1420 o TLS Master secret (known as the EAP-TLS Master Key or MK) 1421 o SA lifetime (ensuring that the SA is not stored forever) 1422 o If the client has multiple different credentials (certificates 1423 and corresponding private keys), a pointer to those credentials 1425 When the server initiates EAP-TLS, the client can look up the EAP-TLS 1426 SA based on the credentials it was going to use (certificate and 1427 private key), and the expected credentials (certificate or name) of 1428 the server. If an EAP-TLS SA exists, and it is not too old, the 1429 client informs the server about the existence of this SA by including 1430 its Session-Id in the TLS ClientHello message. The server then looks 1431 up the correct SA based on the Session-Id (or detects that it doesn't 1432 yet have one). 1434 3.1.2. Example: EAP-AKA 1436 In EAP-AKA [I-D.arkko-pppext-eap-aka], after EAP authentication the 1437 client and server can store the following information: 1439 o Implicitly, the EAP method this SA refers to (EAP-AKA) 1440 o A re-authentication pseudonym 1441 o The client's permanent identity (IMSI) (server) 1442 o Replay protection counter 1443 o Authentication key (K_aut) 1444 o Encryption key (K_encr) 1445 o Original Master Key (MK) 1446 o SA lifetime (ensuring that the SA is not stored forever) 1448 When the server initiates EAP-AKA, the client can look up the EAP-AKA 1449 SA based on the credentials it was going to use (permanent identity). 1450 If an EAP-AKA SA exists, and it is not too old, the client informs 1451 the server about the existence of this SA by sending its re- 1452 authentication pseudonym as its identity in EAP Identity Response 1453 message, instead of its permanent identity. The server then looks up 1454 the correct SA based on this identity. 1456 3.2. EAP-key SA 1458 This is an SA between the peer and EAP server, which is used to store 1459 the keying material exported by the EAP method. Current EAP server 1460 implementations do not retain this SA after the EAP conversation 1461 completes, but future implementations could use this SA for pre- 1462 emptive key distribution. 1464 Contents: 1466 o Name/identifier for this SA 1467 o Identities of the parties 1468 o MSK and EMSK 1469 o SA lifetime 1471 3.3. AAA SA(s) (authenticator - backend authentication server) 1473 In order for the authenticator and backend authentication server to 1474 authenticate each other, they need to store some information. 1476 In case the authenticator and backend authentication server are 1477 colocated, and they communicate using local procedure calls or shared 1478 memory, this SA need not necessarily contain any information. 1480 3.3.1. Example: RADIUS 1482 In RADIUS, where shared secret authentication is used, the client and 1483 server store each other's IP address and the shared secret, which is 1484 used to calculate the Response Authenticator [RFC2865] and Message- 1485 Authenticator [RFC3579] values, and to encrypt some attributes (such 1486 as the AAA-Key [RFC2548]). 1488 Where IPsec is used to protect RADIUS [RFC3579] and IKE is used for 1489 key management, the parties store information necessary to 1490 authenticate and authorize the other party (e.g. certificates, trust 1491 anchors and names). The IKE exchange results in IKE Phase 1 and 1492 Phase 2 SAs containing information used to protect the conversation 1493 (session keys, selected ciphersuite, etc.) 1495 3.3.2. Example: Diameter with TLS 1497 When using Diameter protected by TLS, the parties store information 1498 necessary to authenticate and authorize the other party (e.g. 1499 certificates, trust anchors and names). The TLS handshake results in 1500 a short-term TLS SA that contains information used to protect the 1501 actual communications (session keys, selected TLS ciphersuite, etc.). 1503 3.4. Service SA(s) (peer - authenticator) 1505 The service SA stores information about the service being provided. 1506 This includes: 1508 o Service parameters (or at least those parameters 1509 that are still needed) 1510 o On the authenticator, service authorization 1511 information received from the backend authentication 1512 server (or necessary parts of it) 1513 o On the peer, usually locally configured service 1514 authorization information. 1515 o Transient Session Keys used to protect the communication 1516 o The AAA-Key, if it can be needed again (to refresh 1517 and/or resynchronize other keys or for another reason) 1518 o AAA-Key lifetime 1520 The information in the service SA can be grouped into several 1521 different SAs. This would make sense if, for instance, the service 1522 provided is naturally divided into several different subconversations 1523 with different parameters. 1525 How exactly the relevant service SA is chosen at each point depends 1526 on the protocol; see below for examples. 1528 3.4.1. Example: 802.11i 1530 [IEEE802.11i] Section 8.4.1.1 defines the security associations used 1531 within IEEE 802.11. A summary follows; the standard should be 1532 consulted for details. 1534 o Pairwise Master Key Security Association (PMKSA) 1536 The PMKSA is a bi-directional SA, used by both parties for sending 1537 and receiving. It is created on the peer when EAP authentication 1538 completes successfully or a pre-shared key is configured. The 1539 PMKSA is created on the authenticator when the PMK is received or 1540 created on the authenticator or a pre-shared key is configured. 1541 The PMKSA is used to create the PTKSA. PMKSAs are cached for 1542 their lifetimes. The PMKSA consists of the following elements: 1544 - PMKID (security association identifier) 1545 - Authenticator MAC address 1546 - PMK 1547 - Lifetime 1548 - Authenticated Key Management Protocol (AKMP) 1549 - Authorization parameters specified the AAA server or 1550 by local configuration. This can include 1551 parameters such as the peer's authorized SSID. 1552 On the peer, this information can be locally 1553 configured. 1554 - Key replay counters (for EAPOL-Key messages) 1555 - Reference to PTKSA (if any), needed to: 1556 o delete it (e.g. AAA server initiated disconnect) 1557 o replace it when a new four-way handshake is done 1558 - Reference to accounting context (the details of which depend 1559 on the accounting protocol used, and various implementation 1560 and administrative details. In RADIUS, this could include 1561 (e.g. packet and octet counters, and Acct-Multi-Session-Id). 1563 o Pairwise Transient Key Security Association (PTKSA) 1565 The PTKSA is a bi-directional SA created as the result of a 1566 successful four-way handshake. There may only be one PTKSA 1567 between a pair of peer and authenticator MAC addresses. PTKSAs 1568 are cached for the lifetime of the PMKSA. Since the PTKSA is tied 1569 to the PMKSA, it only has the addititional information from the 1570 4-way handshake. The PTKSA consists of the following: 1572 - Key (PTK) 1573 - Selected ciphersuite 1574 - MAC addresses of the parties 1575 - Replay counters, and ciphersuite specific state 1576 - Reference to PMKSA: This is needed when: 1577 o A new four-way handshake is needed (lifetime, TKIP 1578 countermeasures), and we need to know which PMKSA to use 1580 o Group Transient Key Security Association (GTKSA) 1582 The GTKSA is a uni-directional SA created based on the four-way 1583 handshake or the group key handshake. A GTKSA consists of the 1584 following: 1586 - Direction vector (whether the GTK is used for transmit or receive) 1587 - Group cipher suite selector 1588 - Key (GTK) 1589 - Authenticator MAC addres 1590 - Via reference to PMKSA, or copied here: 1591 o Authorization parameters 1592 o Reference to accounting context 1594 3.4.2. Example: IKEv2/IPsec 1596 Note that this example is intended to be informative, and it does not 1597 necessarily include all information stored. 1599 o IKEv2 SA 1601 - Protocol version 1602 - Identitities of the parties 1603 - IKEv2 SPIs 1604 - Selected ciphersuite 1605 - Replay protection counters (Message ID) 1606 - Keys for protecting IKEv2 messages (SK_ai/SK_ar/SK_ei/SK_er) 1607 - Key for deriving keys for IPsec SAs (SK_d) 1608 - Lifetime information 1609 - On the authenticator, service authorization information 1610 received from the backend authentication server. 1612 When processing an incoming message, the correct SA is looked up based 1613 on the SPIs. 1615 o IPsec SAs/SPD 1617 - Traffic selectors 1618 - Replay protection counters 1619 - Selected ciphersuite 1620 - IPsec SPI 1621 - Keys 1622 - Lifetime information 1623 - Protocol mode (tunnel or transport) 1625 The correct SA is looked up based on SPI (for inbound packets), or 1626 SPD traffic selectors (for outbound traffic). A separate IPsec SA 1627 exists for each direction. 1629 3.4.3. Sharing service SAs 1631 A single service may be provided by multiple logical or physical 1632 service elements. Each service is responsible for specifying how 1633 changing service elements is handled. Some approaches include: 1635 Transparent sharing 1636 If the service parameters visible to the other party (either peer 1637 or authenticator) do not change, the service can be moved without 1638 requiring cooperation from the other party. 1640 Whether such a move should be supported or used depends on 1641 implementation and administrative considerations. For instance, an 1642 administrator may decide to configure a group of IKEv2/IPsec 1643 gateways in a cluster for high-availability purposes, if the 1644 implementation used supports this. The peer does not necessarily 1645 have any way of knowing when the change occurs. 1647 No sharing 1648 If the service parameters require changing, some changes may 1649 require terminating the old service, and starting a new 1650 conversation from phase 0. This approach is used by all services 1651 for at least some parameters, and it doesn't require any protocol 1652 for transferring the service SA between the service elements. 1654 The service may support keeping the old service element active 1655 while the new conversation takes phase, to decrease the time the 1656 service is not available. 1658 Some sharing 1659 The service may allow changing some parameters by simply agreeing 1660 about the new values. This may involve a similar exchange as in 1661 phase 2, or perhaps a shorter conversation. 1663 This option usually requires some protocol for transferring the 1664 service SA between the elements. An administrator may decide not to 1665 enable this feature at all, and typically the sharing is restricted 1666 to some particular service elements (defined either by a service 1667 parameter, or simple administrative decision). If the old and new 1668 service element do not support such "context transfer", this 1669 approach falls back to the previous option (no transfer). 1671 Services supporting this feature should also consider what changes 1672 require new authorization from the backend authentication server 1673 (see Section 1.7). 1675 Note that these considerations are not limited to service 1676 parameters related to the authenticator--they apply to peer's 1677 parameters as well. 1679 3.5. SA Naming 1681 In order to support the correct processing of phase 2 security 1682 associations, the Secure Association (phase 2) protocol supports the 1683 naming of phase 2 security associations and associated transient 1684 session keys, so that the correct set of transient session keys can 1685 be identified for processing a given packet. Explicit creation and 1686 deletion operations are also typically supported so that 1687 establishment and re-establishment of transient session keys can be 1688 synchronized between the parties. 1690 In order to securely bind the AAA SA (phase 1b) to its child phase 2 1691 security associations, the phase 2 Secure Association Protocol allows 1692 the EAP peer and authenticator to mutually prove possession of the 1693 AAA-Key. In order to avoid confusion in the case where an EAP peer 1694 has more than one AAA-Key (phase 1b) applicable to establishment of a 1695 phase 2 security association, it is necessary for the secure 1696 Association Protocol (phase 2) to support key selection, so that the 1697 appropriate phase 1b keying material can be utilized by both parties 1698 in the Secure Association Protocol exchange. 1700 For example, a peer might be pre-configured with policy indicating 1701 the ciphersuite to be used in communicating with a given 1702 authenticator. Within PPP, the ciphersuite is negotiated within the 1703 Encryption Control Protocol (ECP), after EAP authentication is 1704 completed. Within [IEEE80211i], the AP ciphersuites are advertised 1705 in the Beacon and Probe Responses, and are securely verified during a 1706 4-way exchange after EAP authentication has completed. 1708 As part of the Secure Association Protocol (phase 2), it is necessary 1709 to bind the Transient Session Keys (TSKs) to the keying material 1710 provided in the AAA-Token. This ensures that the EAP peer and 1711 authenticator are both clear about what key to use to provide mutual 1712 proof of possession. 1714 Keys within the EAP key hierarchy are named as follows: 1716 EAP SA name 1717 The EAP security association is negotiated between the EAP peer and 1718 EAP server, and is uniquely named as follows . 1720 Here the EAP peer name and EAP server name are the identifiers 1721 securely exchanged within the EAP method. Since multiple EAP SAs 1722 may exist between an EAP peer and EAP server, the EAP peer nonce 1723 and EAP server nonce allow EAP SAs to be differentiated. The 1724 inclusion of the Method Type in the EAP SA name ensures that each 1725 EAP method has a distinct EAP SA space. 1727 AAA-Key Name 1728 The AAA-Key is named by the concatenation of the EAP SA name, "AAA- 1729 Key" and the authenticator name, since the AAA-Key is bound to a 1730 particular authenticator. For the purpose of identification, the 1731 NAS-Identifier attribute is recommended. In order to ensure that 1732 all parties can agree on the NAS name this requires the NAS to 1733 advertise its name (typically using a media-specific mechanism, 1734 such as the 802.11 Beacon/Probe Response)." 1736 4. Security considerations 1738 4.1. Security Terminology 1740 Cryptographic binding 1741 The demonstration of the EAP peer to the EAP server that a single 1742 entity has acted as the EAP peer for all methods executed within a 1743 tunnel method. Binding MAY also imply that the EAP server 1744 demonstrates to the peer that a single entity has acted as the EAP 1745 server for all methods executed within a tunnel method. If 1746 executed correctly, binding serves to mitigate man-in-the-middle 1747 vulnerabilities. 1749 Cryptographic separation 1750 Two keys (x and y) are "cryptographically separate" if an adversary 1751 that knows all messages exchanged in the protocol cannot compute x 1752 from y or y from x without "breaking" some cryptographic 1753 assumption. In particular, this definition allows that the 1754 adversary has the knowledge of all nonces sent in cleartext as well 1755 as all predictable counter values used in the protocol. Breaking a 1756 cryptographic assumption would typically require inverting a one- 1757 way function or predicting the outcome of a cryptographic pseudo- 1758 random number generator without knowledge of the secret state. In 1759 other words, if the keys are cryptographically separate, there is 1760 no shortcut to compute x from y or y from x, but the work an 1761 adversary must do to perform this computation is equivalent to 1762 performing exhaustive search for the secret state value. 1764 Key strength 1765 If the effective key strength is N bits, the best currently known 1766 methods to recover the key (with non-negligible probability) 1767 require on average an effort comparable to 2^(N-1) operations of a 1768 typical block cipher. 1770 Mutual authentication 1771 This refers to an EAP method in which, within an interlocked 1772 exchange, the authenticator authenticates the peer and the peer 1773 authenticates the authenticator. Two independent one-way methods, 1774 running in opposite directions do not provide mutual authentication 1775 as defined here. 1777 4.2. Threat Model 1779 The EAP threat model is described in [RFC3748], Section 7.1. In 1780 order to address these threats, EAP relies on the security properties 1781 of EAP methods (known as "security claims", described in [RFC3784], 1782 Section 7.2.1). EAP method requirements for application such as 1783 Wireless LAN authentication are described in [WLANREQ]. 1785 The RADIUS threat model is described in [RFC3579] Section 4.1, and 1786 responses to these threats are described in [RFC3579] Sections 4.2 1787 and 4.3. Among other things, [RFC3579] Section 4.2 recommends the 1788 use of IPsec ESP with non-null transform to provide per-packet 1789 authentication and confidentiality, integrity and replay protection 1790 for RADIUS/EAP. 1792 Given the existing documentation of EAP and AAA threat models and 1793 responses, there is no need to duplicate that material here. 1794 However, there are many other system-level threats no covered in 1795 these document which have not been described or analyzed elsewhere. 1796 These include: 1798 [1] An attacker may try to modify or spoof Secure Association Protocol 1799 packets. 1801 [2] An attacker compromising an authenticator may provide incorrect 1802 information to the EAP peer and/or server via out-of-band 1803 mechanisms (such as via a AAA or lower layer protocol). This 1804 includes impersonating another authenticator, or providing 1805 inconsistent information to the peer and EAP server. 1807 [3] An attacker may attempt to perform downgrading attacks on the 1808 ciphersuite negotiation within the Secure Association Protocol in 1809 order to ensure that a weaker ciphersuite is used to protect data. 1811 Depending on the lower layer, these attacks may be carried out 1812 without requiring physical proximity. 1814 In order to address these threats, [Housley56] describes the 1815 mandatory system security properties: 1817 Algorithm independence 1818 Wherever cryptographic algorithms are chosen, the algorithms must 1819 be negotiable, in order to provide resilient against compromise of 1820 a particular algorithm. Algorithm independence must be 1821 demonstrated within all aspects of the system, including within 1822 EAP, AAA and the Secure Association Protocol. However, for 1823 interoperability, at least one suite of algorithms MUST be 1824 implemented. 1826 Strong, fresh session keys 1827 Session keys must be demonstrated to be strong and fresh in all 1828 circumstances, while at the same time retaining algorithm 1829 independence. 1831 Replay protection 1832 All protocol exchanges must be replay protected. This includes 1833 exchanges within EAP, AAA, and the Secure Association Protocol. 1835 Authentication 1836 All parties need to be authenticated. The confidentiality of the 1837 authenticator must be maintained. No plaintext passwords are 1838 allowed. 1840 Authorization 1841 EAP peer and authenticator authorization must be performed. 1843 Session keys 1844 Confidentiality of session keys must be maintained. 1846 Ciphersuite negotiation 1847 The selection of the "best" ciphersuite must be securely confirmed. 1849 Unique naming 1850 Session keys must be uniquely named. 1852 Domino effect 1853 Compromise of a single authenticator cannot compromise any other 1854 part of the system, including session keys and long-term secrets. 1856 Key binding 1857 The key must be bound to the appropriate context. 1859 4.3. Security Analysis 1861 Figure 6 illustrates the relationship between the peer, authenticator 1862 and backend authentication server. 1864 EAP peer 1865 /\ 1866 / \ 1867 Protocol: EAP / \ Protocol: Secure Association 1868 Auth: Mutual / \ Auth: Mutual 1869 Unique keys: / \ Unique keys: TSKs 1870 TEKs,EMSK / \ 1871 / \ 1872 EAP server +--------------+ Authenticator 1873 Protocol: AAA 1874 Auth: Mutual 1875 Unique key: AAA session key 1877 Figure 6: Relationship between peer, authenticator and auth. server 1879 The peer and EAP server communicate using EAP [RFC3748]. The 1880 security properties of this communication are largely determined by 1881 the chosen EAP method. Method security claims are described in 1882 [RFC3748] Section 7.2. These include the key strength, protected 1883 ciphersuite negotiation, mutual authentication, integrity protection, 1884 replay protection, confidentiality, key derivation, key strength, 1885 dictionary attack resistance, fast reconnect, cryptographic binding, 1886 session independence, fragmentation and channel binding claims. At a 1887 minimum, methods claiming to support key derivation must also support 1888 mutual authentication. As noted in [RFC3748] Section 7.10: 1890 EAP Methods deriving keys MUST provide for mutual authentication 1891 between the EAP peer and the EAP Server. 1893 Ciphersuite independence is also required: 1895 Keying material exported by EAP methods MUST be independent of the 1896 ciphersuite negotiated to protect data. 1898 In terms of key strength and freshness, [RFC3748] Section 10 says: 1900 EAP methods SHOULD ensure the freshness of the MSK and EMSK even 1901 in cases where one party may not have a high quality random number 1902 generator.... In order to preserve algorithm independence, EAP 1903 methods deriving keys SHOULD support (and document) the protected 1904 negotiation of the ciphersuite used to protect the EAP 1905 conversation between the peer and server... In order to enable 1906 deployments requiring strong keys, EAP methods supporting key 1907 derivation SHOULD be capable of generating an MSK and EMSK, each 1908 with an effective key strength of at least 128 bits. 1910 The authenticator and backend authentication server communicate using 1911 a AAA protocol such as RADIUS [RFC3579] or Diameter [I-D.ietf-aaa- 1912 eap]. As noted in [RFC3588] Section 13, Diameter must be protected 1913 by either IPsec ESP with non-null transform or TLS. As a result, 1914 Diameter requires per-packet integrity and confidentiality. Replay 1915 protection must be supported. For RADIUS, [RFC3579] Section 4.2 1916 recommends that RADIUS be protected by IPsec ESP with a non-null 1917 transform, and where IPsec is implemented replay protection must be 1918 supported. 1920 The peer and authenticator communicate using the Secure Association 1921 Protocol. 1923 As noted in the figure, each party in the exchange mutually 1924 authenticates with each of the other parties, and derives a unique 1925 key. All parties in the diagram have access to the AAA-Key. 1927 The EAP peer and backend authentication server mutually authenticate 1928 via the EAP method, and derive the TEKs and EMSK which are known only 1929 to them. The TEKs are used to protect some or all of the EAP 1930 conversation between the peer and authenticator, so as to guard 1931 against modification or insertion of EAP packets by an attacker. The 1932 degree of protection afforded by the TEKs is determined by the EAP 1933 method; some methods may protect the entire EAP packet, including the 1934 EAP header, while other methods may only protect the contents of the 1935 Type-Data field, defined in [RFC3748]. 1937 Since EAP is spoken only between the EAP peer and server, if a 1938 backend authentication server is present then the EAP conversation 1939 does not provide mutual authentication between the peer and 1940 authenticator, only between the EAP peer and EAP server (backend 1941 authentication server). As a result, mutual authentication between 1942 the peer and authenticator only occurs where a Secure Association 1943 protocol is used, such the unicast and group key derivation handshake 1944 supported in [IEEE80211i]. This means that absent use of a secure 1945 Association Protocol, from the point of view of the peer, EAP mutual 1946 authentication only proves that the authenticator is trusted by the 1947 backend authentication server; the identity of the authenticator is 1948 not confirmed. 1950 Utilizing the AAA protocol, the authenticator and backend 1951 authentication server mutually authenticate and derive session keys 1952 known only to them, used to provide per-packet integrity and replay 1953 protection, authentication and confidentiality. The AAA-Key is 1954 distributed by the backend authentication server to the authenticator 1955 over this channel, bound to attributes constraining its usage, as 1956 part of the AAA-Token. The binding of attributes to the AAA-Key 1957 within a protected package is important so the authenticator 1958 receiving the AAA-Token can determine that it has not been 1959 compromised, and that the keying material has not been replayed, or 1960 mis-directed in some way. 1962 The security properties of the EAP exchange are dependent on each leg 1963 of the triangle: the selected EAP method, AAA protocol and the Secure 1964 Association Protocol. 1966 Assuming that the AAA protocol provides protection against rogue 1967 authenticators forging their identity, then the AAA-Token can be 1968 assumed to be sent to the correct authenticator, and where it is 1969 wrapped appropriately, it can be assumed to be immune to compromise 1970 by a snooping attacker. 1972 Where an untrusted AAA intermediary is present, the AAA-Token must 1973 not be provided to the intermediary so as to avoid compromise of the 1974 AAA-Token. This can be avoided by use of re-direct as defined in 1975 [RFC3588]. 1977 When EAP is used for authentication on PPP or wired IEEE 802 1978 networks, it is typically assumed that the link is physically secure, 1979 so that an attacker cannot gain access to the link, or insert a rogue 1980 device. EAP methods defined in [RFC3748] reflect this usage model. 1981 These include EAP MD5, as well as One-Time Password (OTP) and Generic 1982 Token Card. These methods support one-way authentication (from EAP 1983 peer to authenticator) but not mutual authentication or key 1984 derivation. As a result, these methods do not bind the initial 1985 authentication and subsequent data traffic, even when the the 1986 ciphersuite used to protect data supports per-packet authentication 1987 and integrity protection. As a result, EAP methods not supporting 1988 mutual authentication are vulnerable to session hijacking as well as 1989 attacks by rogue devices. 1991 On wireless networks such as IEEE 802.11 [IEEE80211], these attacks 1992 become easy to mount, since any attacker within range can access the 1993 wireless medium, or act as an access point. As a result, new 1994 ciphersuites have been proposed for use with wireless LANs 1995 [IEEE80211i] which provide per-packet authentication, integrity and 1996 replay protection. In addition, mutual authentication and key 1997 derivation, provided by methods such as EAP-TLS [RFC2716] are 1998 required [IEEE80211i], so as to address the threat of rogue devices, 1999 and provide keying material to bind the initial authentication to 2000 subsequent data traffic. 2002 If the selected EAP method does not support mutual authentication, 2003 then the peer will be vulnerable to attack by rogue authenticators 2004 and backend authentication servers. If the EAP method does not derive 2005 keys, then TSKs will not be available for use with a negotiated 2006 ciphersuite, and there will be no binding between the initial EAP 2007 authentication and subsequent data traffic, leaving the session 2008 vulnerable to hijack. 2010 If the backend authentication server does not protect against 2011 authenticator masquerade, or provide the proper binding of the AAA- 2012 Key to the session within the AAA-Token, then one or more AAA-Keys 2013 may be sent to an unauthorized party, and an attacker may be able to 2014 gain access to the network. If the AAA-Token is provided to an 2015 untrusted AAA intermediary, then that intermediary may be able to 2016 modify the AAA-Key, or the attributes associated with it, as 2017 described in [RFC2607]. 2019 If the Secure Association Protocol does not provide mutual proof of 2020 possession of the AAA-Key material, then the peer will not have 2021 assurance that it is connected to the correct authenticator, only 2022 that the authenticator and backend authentication server share a 2023 trust relationship (since AAA protocols support mutual 2024 authentication). This distinction can become important when multiple 2025 authenticators receive AAA-Keys from the backend authentication 2026 server, such as where fast handoff is supported. If the TSK 2027 derivation does not provide for protected ciphersuite and 2028 capabilities negotiation, then downgrade attacks are possible. 2030 4.4. Man-in-the-middle Attacks 2032 As described in [I-D.puthenkulam-eap-binding], EAP method sequences 2033 and compound authentication mechanisms may be subject to man-in-the- 2034 middle attacks. When such attacks are successfully carried out, the 2035 attacker acts as an intermediary between a victim and a legitimate 2036 authenticator. This allows the attacker to authenticate successfully 2037 to the authenticator, as well as to obtain access to the network. 2039 In order to prevent these attacks, [I-D.puthenkulam-eap-binding] 2040 recommends derivation of a compound key by which the EAP peer and 2041 server can prove that they have participated in the entire EAP 2042 exchange. Since the compound key must not be known to an attacker 2043 posing as an authenticator, and yet must be derived from quantities 2044 that are exported by EAP methods, it may be desirable to derive the 2045 compound key from a portion of the EMSK. In order to provide proper 2046 key hygiene, it is recommended that the compound key used for man-in- 2047 the-middle protection be cryptographically separate from other keys 2048 derived from the EMSK, such as fast handoff keys, discussed in 2049 Appendix E. 2051 4.5. Denial of Service Attacks 2053 The caching of security associations may result in vulnerability to 2054 denial of service attacks. Since an EAP peer may derive multiple EAP 2055 SAs with a given EAP server, and creation of a new EAP SA does not 2056 implicitly delete a previous EAP SA, EAP methods that result in 2057 creation of persistent state may be vulnerable to denial of service 2058 attacks by a rogue EAP peer. 2060 As a result, EAP methods creating persistent state may wish to limit 2061 the number of cached EAP SAs (Phase 1a) corresponding to an EAP peer. 2062 For example, an EAP server may choose to only retain a few EAP SAs 2063 for each peer. This prevents a rogue peer from denying access to 2064 other peers. 2066 Similarly, an authenticator may have multiple AAA-Key SAs 2067 corresponding to a given EAP peer; to conserve resources an 2068 authenticator may choose to limit the number of cached AAA-Key (Phase 2069 1 b) SAs for each peer. 2071 Depending on the media, creation of a new unicast Secure Association 2072 SA may or may not imply deletion of a previous unicast secure 2073 association SA. Where there is no implied deletion, the 2074 authenticator may choose to limit Phase 2 (unicast and multicast) 2075 Secure Association SAs for each peer. 2077 4.6. Impersonation 2079 Both the RADIUS and Diameter protocols are potentially vulnerable to 2080 impersonation by a rogue authenticator. 2082 While AAA protocols such as RADIUS [RFC2865] or Diameter [RFC3588] 2083 support mutual authentication between the authenticator (known as the 2084 AAA client) and the backend authentication server (known as the AAA 2085 server), the security mechanisms vary according to the AAA protocol. 2087 In RADIUS, the shared secret used for authentication is determined by 2088 the source address of the RADIUS packet. As noted in [RFC3579] 2089 Section 4.3.7, it is highly desirable that the source address be 2090 checked against one or more NAS identification attributes so as to 2091 detect and prevent impersonation attacks. 2093 When RADIUS requests are forwarded by a proxy, the NAS-IP-Address or 2094 NAS-IPv6-Address attributes may not correspond to the source address. 2095 Since the NAS-Identifier attribute need not contain an FQDN, it also 2096 may not correspond to the source address, even indirectly. [RFC2865] 2097 Section 3 states: 2099 A RADIUS server MUST use the source IP address of the RADIUS 2100 UDP packet to decide which shared secret to use, so that 2101 RADIUS requests can be proxied. 2103 This implies that it is possible for a rogue authenticator to forge 2104 NAS-IP-Address, NAS-IPv6-Address or NAS-Identifier attributes within 2105 a RADIUS Access-Request in order to impersonate another 2106 authenticator. Among other things, this can result in messages (and 2107 MSKs) being sent to the wrong authenticator. Since the rogue 2108 authenticator is authenticated by the RADIUS proxy or server purely 2109 based on the source address, other mechanisms are required to detect 2110 the forgery. In addition, it is possible for attributes such as the 2111 Called-Station-Id and Calling-Station-Id to be forged as well. 2113 As recommended in [RFC3579], this vulnerability can be mitigated by 2114 having RADIUS proxies check authenticator identification attributes 2115 against the source address. 2117 To allow verification of session parameters such as the Called- 2118 Station- Id and Calling-Station-Id, these can be sent by the EAP peer 2119 to the server, protected by the TEKs. The RADIUS server can then 2120 check the parameters sent by the EAP peer against those claimed by 2121 the authenticator. If a discrepancy is found, an error can be 2122 logged. 2124 While [RFC3588] requires use of the Route-Record AVP, this utilizes 2125 FQDNs, so that impersonation detection requires DNS A/AAAA and PTR 2126 RRs to be properly configured. As a result, it appears that Diameter 2127 is as vulnerable to this attack as RADIUS, if not more so. To address 2128 this vulnerability, it is necessary to allow the backend 2129 authentication server to communicate with the authenticator directly, 2130 such as via the redirect functionality supported in [RFC3588]. 2132 4.7. Channel binding 2134 It is possible for a compromised or poorly implemented EAP 2135 authenticator to communicate incorrect information to the EAP peer 2136 and/or server. This may enable an authenticator to impersonate 2137 another authenticator or communicate incorrect information via out- 2138 of-band mechanisms (such as via a AAA or lower layer protocol). 2140 Where EAP is used in pass-through mode, the EAP peer typically does 2141 not verify the identity of the pass-through authenticator, it only 2142 verifies that the pass-through authenticator is trusted by the EAP 2143 server. This creates a potential security vulnerability, described in 2144 Section 7.15 of [RFC2284bis]. 2146 Section 4.3.7 of [RFC3579] describes how an EAP pass-through 2147 authenticator acting as a AAA client can be detected if it attempts 2148 to impersonate another authenticator (such by sending incorrect NAS- 2149 Identifier [RFC2865], NAS-IP-Address [RFC2865] or NAS-IPv6-Address 2150 [RFC3162] attributes via the AAA protocol). However, it is possible 2151 for a pass-through authenticator acting as a AAA client to provide 2152 correct information to the AAA server while communicating misleading 2153 information to the EAP peer via a lower layer protocol. 2155 For example, it is possible for a compromised authenticator to 2156 utilize another authenticator's Called-Station-Id or NAS-Identifier 2157 in communicating with the EAP peer via a lower layer protocol, or for 2158 a pass-through authenticator acting as a AAA client to provide an 2159 incorrect peer Calling-Station-Id [RFC2865][RFC3580] to the AAA 2160 server via the AAA protocol. 2162 As noted in Section 7.15 of [RFC3748] this vulnerability can be 2163 addressed by use of EAP methods that support a protected exchange of 2164 channel properties such as endpoint identifiers, including (but not 2165 limited to): Called-Station-Id [RFC2865][RFC3580], Calling-Station-Id 2166 [RFC2865][RFC3580], NAS-Identifier [RFC2865], NAS-IP-Address 2167 [RFC2865], and NAS-IPv6-Address [RFC3162]. 2169 Using such a protected exchange, it is possible to match the channel 2170 properties provided by the authenticator via out-of-band mechanisms 2171 against those exchanged within the EAP method. 2173 4.8. Key Strength 2175 In order to guard against brute force attacks, EAP methods deriving 2176 keys need to be capable of generating keys with an appropriate 2177 effective symmetric key strength. In order to ensure that key 2178 generation is not the weakest link, it is necessary for EAP methods 2179 utilizing public key cryptography to choose a public key that has a 2180 cryptographic strength meeting the symmetric key strength 2181 requirement. 2183 As noted in Section 5 of [RFC3766], this results in the following 2184 required RSA or DH module and DSA subgroup size in bits, for a given 2185 level of attack resistance in bits: 2187 Attack Resistance RSA or DH Modulus DSA subgroup 2188 (bits) size (bits) size (bits) 2189 ----------------- ----------------- ------------ 2190 70 947 128 2191 80 1228 145 2192 90 1553 153 2193 100 1926 184 2194 150 4575 279 2195 200 8719 373 2196 250 14596 475 2198 4.9. Key Wrap 2200 As described in [RFC3579], Section 4.3, known problems exist in the 2201 key wrap specified in [RFC2548]. Where the same RADIUS shared secret 2202 is used by a PAP authenticator and an EAP authenticator, there is a 2203 vulnerability to known plaintext attack. Since RADIUS uses the 2204 shared secret for multiple purposes, including per-packet 2205 authentication, attribute hiding, considerable information is exposed 2206 about the shared secret with each packet. This exposes the shared 2207 secret to dictionary attacks. MD5 is used both to compute the RADIUS 2208 Response Authenticator and the Message-Authenticator attribute, and 2209 some concerns exist relating to the security of this hash 2210 [MD5Attack]. 2212 As discussed in [RFC3579], Section 4.3, the security vulnerabilities 2213 of RADIUS are extensive, and therefore development of an alternative 2214 key wrap technique based on the RADIUS shared secret would not 2215 substantially improve security. As a result, [RFC3759], Section 4.2 2216 recommends running RADIUS over IPsec. The same approach is taken in 2217 Diameter EAP [I-D.ietf-aaa-eap], which defines cleartext key 2218 attributes, to be protected by IPsec or TLS. 2220 Where an untrusted AAA intermediary is present (such as a RADIUS 2221 proxy or a Diameter agent), and data object security is not used, the 2222 AAA-Key may be recovered by an attacker in control of the untrusted 2223 intermediary. Possession of the AAA-Key enables decryption of data 2224 traffic sent between the peer and a specific authenticator; however 2225 where key separation is implemented, compromise of the AAA-Key does 2226 not enable an attacker to impersonate the peer to another 2227 authenticator, since that requires possession of the MK or EMSK, 2228 which are not transported by the AAA protocol. This vulnerability 2229 may be mitigated by implementation of redirect functionality, as 2230 provided in [RFC3588]. 2232 5. Security Requirements 2234 This section summarizes the security requirements that must be met by 2235 EAP methods, AAA protocols, Secure Association Protocols and 2236 Ciphersuites in order to address the security threats described in 2237 this document. These requirements MUST be met by specifications 2238 requesting publication as an RFC. Each requirement provides a 2239 pointer to the sections of this document describing the threat that 2240 it mitigates. 2242 5.1. EAP Method Requirements 2244 It is possible for the peer and EAP server to mutually authenticate 2245 and derive keys. In order to provide keying material for use in a 2246 subsequently negotiated ciphersuite, an EAP method supporting key 2247 derivation MUST export a Master Session Key (MSK) of at least 64 2248 octets, and an Extended Master Session Key (EMSK) of at least 64 2249 octets. EAP Methods deriving keys MUST provide for mutual 2250 authentication between the EAP peer and the EAP Server. 2252 The MSK and EMSK MUST NOT be used directly to protect data; however, 2253 they are of sufficient size to enable derivation of a AAA-Key 2254 subsequently used to derive Transient Session Keys (TSKs) for use 2255 with the selected ciphersuite. Each ciphersuite is responsible for 2256 specifying how to derive the TSKs from the AAA-Key. 2258 The AAA-Key is derived from the keying material exported by the EAP 2259 method (MSK and EMSK). This derivation occurs on the AAA server. In 2260 many existing protocols that use EAP, the AAA-Key and MSK are 2261 equivalent, but more complicated mechanisms are possible (see 2262 Appendix E for details). 2264 EAP methods SHOULD ensure the freshness of the MSK and EMSK even in 2265 cases where one party may not have a high quality random number 2266 generator. A RECOMMENDED method is for each party to provide a nonce 2267 of at least 128 bits, used in the derivation of the MSK and EMSK. 2269 EAP methods export the MSK and EMSK and not Transient Session Keys so 2270 as to allow EAP methods to be ciphersuite and media independent. 2271 Keying material exported by EAP methods MUST be independent of the 2272 ciphersuite negotiated to protect data. 2274 Depending on the lower layer, EAP methods may run before or after 2275 ciphersuite negotiation, so that the selected ciphersuite may not be 2276 known to the EAP method. By providing keying material usable with 2277 any ciphersuite, EAP methods can used with a wide range of 2278 ciphersuites and media. 2280 It is RECOMMENDED that methods providing integrity protection of EAP 2281 packets include coverage of all the EAP header fields, including the 2282 Code, Identifier, Length, Type and Type-Data fields. 2284 In order to preserve algorithm independence, EAP methods deriving 2285 keys SHOULD support (and document) the protected negotiation of the 2286 ciphersuite used to protect the EAP conversation between the peer and 2287 server. This is distinct from the ciphersuite negotiated between the 2288 peer and authenticator, used to protect data. 2290 The strength of Transient Session Keys (TSKs) used to protect data is 2291 ultimately dependent on the strength of keys generated by the EAP 2292 method. If an EAP method cannot produce keying material of 2293 sufficient strength, then the TSKs may be subject to brute force 2294 attack. In order to enable deployments requiring strong keys, EAP 2295 methods supporting key derivation SHOULD be capable of generating an 2296 MSK and EMSK, each with an effective key strength of at least 128 2297 bits. 2299 Methods supporting key derivation MUST demonstrate cryptographic 2300 separation between the MSK and EMSK branches of the EAP key 2301 hierarchy. Without violating a fundamental cryptographic assumption 2302 (such as the non-invertibility of a one-way function) an attacker 2303 recovering the MSK or EMSK MUST NOT be able to recover the other 2304 quantity with a level of effort less than brute force. 2306 Non-overlapping substrings of the MSK MUST be cryptographically 2307 separate from each other. That is, knowledge of one substring MUST 2308 NOT help in recovering some other substring without breaking some 2309 hard cryptographic assumption. This is required because some 2310 existing ciphersuites form TSKs by simply splitting the AAA-Key to 2311 pieces of appropriate length. Likewise, non-overlapping substrings 2312 of the EMSK MUST be cryptographically separate from each other, and 2313 from substrings of the MSK. 2315 The EMSK MUST remain on the EAP peer and EAP server where it is 2316 derived; it MUST NOT be transported to, or shared with, additional 2317 parties, or used to derive any other keys. 2319 Since EAP does not provide for explicit key lifetime negotiation, EAP 2320 peers, authenticators and authentication servers MUST be prepared for 2321 situations in which one of the parties discards key state which 2322 remains valid on another party. 2324 The development and validation of key derivation algorithms is 2325 difficult, and as a result EAP methods SHOULD reuse well established 2326 and analyzed mechanisms for key derivation (such as those specified 2327 in IKE [RFC2409] or TLS [RFC2246]), rather than inventing new ones. 2328 EAP methods SHOULD also utilize well established and analyzed 2329 mechanisms for MSK and EMSK derivation. 2331 5.1.1. Requirements for EAP methods 2333 In order for an EAP method to meet the guidelines for EMSK usage it 2334 must meet the following requirements: 2336 o It must specify how to derive the EMSK 2338 o The key material used for the EMSK MUST be 2339 computationally independent of the MSK and TEKs. 2341 o The EMSK MUST NOT be used for any other purpose than the key 2342 derivation described in this document. 2344 o The EMSK MUST be secret and not known to someone observing 2345 the authentication mechanism protocol exchange. 2347 o The EMSK MUST be maintained within the EAP server. 2348 Only keys (AMSKs) derived according to this specification 2349 may be exported from the EAP server. 2351 o The EMSK MUST be unique for each session. 2353 o The EAP mechanism SHOULD provide a way of naming the EMSK. 2355 Implementations of EAP frameworks on the EAP-Peer and EAP-Server 2356 SHOULD provide an interface to obtain AMSKs. The implementation MAY 2357 restrict which callers can obtain which keys. 2359 5.1.2. Requirements for EAP applications 2361 In order for an application to meet the guidelines for EMSK usage it 2362 must meet the following requirements: 2364 o The application MAY use the MSK transmitted to the NAS in any 2365 way it chooses. This is required for backward compatibility. New 2366 applications following this specification SHOULD NOT use the 2367 MSK. If more than one application uses the MSK, then the 2368 cryptographic separation is not achieved. Implementations SHOULD 2369 prevent such combinations. 2371 o The application MUST NOT use the EMSK in any other way except to 2372 derive Application Master Session Keys (AMSK) using the key 2373 derivation specified in this document. It MUST NOT 2374 use the EMSK directly for cryptographic protection of data. 2376 o Applications MUST define distinct key labels, application 2377 specific data, length of derived key material used in the key 2378 derivation described in section 2.4.3. 2380 o Applications MUST define how they use their AMSK to derive TSKs 2381 for their use. 2383 5.2. AAA Protocol Requirements 2385 AAA protocols suitable for use in transporting EAP MUST provide the 2386 following facilities: 2388 Security services 2389 AAA protocols used for transport of EAP keying material MUST 2390 implement and SHOULD use per-packet integrity and authentication, 2391 replay protection and confidentiality. These requirements are met 2392 by Diameter EAP [I-D.ietf-aaa-eap], as well as RADIUS over IPsec 2393 [RFC3579]. 2395 Session Keys 2396 AAA protocols used for transport of EAP keying material MUST 2397 implement and SHOULD use dynamic key management in order to derive 2398 fresh session keys, as in Diameter EAP [I-D.ietf-aaa-eap] and 2399 RADIUS over IPsec [RFC3579], rather than using a static key, as 2400 originally defined in RADIUS [RFC2865]. 2402 Mutual authentication 2403 AAA protocols used for transport of EAP keying material MUST 2404 provide for mutual authentication between the authenticator and 2405 backend authentication server. These requirements are met by 2406 Diameter EAP [I-D.ietf-aaa-eap] as well as by RADIUS EAP [RFC3579]. 2408 Authorization 2409 AAA protocols used for transport of EAP keying material SHOULD 2410 provide protection against rogue authenticators masquerading as 2411 other authenticators. This can be accomplished, for example, by 2412 requiring that AAA agents check the source address of packets 2413 against the origin attributes (Origin-Host AVP in Diameter, NAS-IP- 2414 Address, NAS-IPv6-Address, NAS-Identifier in RADIUS). For details, 2415 see Section 4.3.7 of [RFC3579]. 2417 Key transport 2418 Since EAP methods do not export Transient Session Keys (TSKs) in 2419 order to maintain media and ciphersuite independence, the AAA 2420 server MUST NOT transport TSKs from the backend authentication 2421 server to authenticator. 2423 Key transport specification 2424 In order to enable backend authentication servers to provide keying 2425 material to the authenticator in a well defined format, AAA 2426 protocols suitable for use with EAP MUST define the format and 2427 wrapping of the AAA-Token. 2429 EMSK transport 2430 Since the EMSK is a secret known only to the backend authentication 2431 server and peer, the AAA-Token MUST NOT transport the EMSK from the 2432 backend authentication server to the authenticator. 2434 AAA-Token protection 2435 To ensure against compromise, the AAA-Token MUST be integrity 2436 protected, authenticated, replay protected and encrypted in 2437 transit, using well-established cryptographic algorithms. 2439 Session Keys 2440 The AAA-Token SHOULD be protected with session keys as in Diameter 2441 [RFC3588] or RADIUS over IPsec [RFC3579] rather than static keys, 2442 as in [RFC2548]. 2444 Key naming 2445 In order to ensure against confusion between the appropriate keying 2446 material to be used in a given Secure Association Protocol 2447 exchange, the AAA-Token SHOULD include explicit key names and 2448 context appropriate for informing the authenticator how the keying 2449 material is to be used. 2451 Key Compromise 2452 Where untrusted intermediaries are present, the AAA-Token SHOULD 2453 NOT be provided to the intermediaries. In Diameter, handling of 2454 keys by intermediaries can be avoided using Redirect functionality 2455 [RFC3588]. 2457 5.3. Secure Association Protocol Requirements 2459 The Secure Association Protocol supports the following: 2461 Entity Naming 2462 The peer and authenticator SHOULD identify themselves in a manner 2463 that is independent of their attached ports. 2465 Mutual proof of possession 2466 The peer and authenticator MUST each demonstrate possession of the 2467 keying material transported between the backend authentication 2468 server and authenticator (AAA-Key). 2470 Key Naming 2471 The Secure Association Protocol MUST explicitly name the keys used 2472 in the proof of possession exchange, so as to prevent confusion 2473 when more than one set of keying material could potentially be used 2474 as the basis for the exchange. 2476 Creation and Deletion 2477 In order to support the correct processing of phase 2 security 2478 associations, the Secure Association (phase 2) protocol MUST 2479 support the naming of phase 2 security associations and associated 2480 transient session keys, so that the correct set of transient 2481 session keys can be identified for processing a given packet. The 2482 phase 2 Secure Association Protocol also MUST support transient 2483 session key activation and SHOULD support deletion, so that 2484 establishment and re-establishment of transient session keys can be 2485 synchronized between the parties. 2487 Integrity and Replay Protection 2488 The Secure Association Protocol MUST support integrity and replay 2489 protection of all messages. 2491 Direct operation 2492 Since the phase 2 Secure Association Protocol is concerned with the 2493 establishment of security associations between the EAP peer and 2494 authenticator, including the derivation of transient session keys, 2495 only those parties have "a need to know" the transient session 2496 keys. The Secure Association Protocol MUST operate directly between 2497 the peer and authenticator, and MUST NOT be passed-through to the 2498 backend authentication server, or include additional parties. 2500 Derivation of transient session keys 2501 The Secure Association Protocol negotiation MUST support derivation 2502 of unicast and multicast transient session keys suitable for use 2503 with the negotiated ciphersuite. 2505 TSK freshness 2506 The Secure Association (phase 2) Protocol MUST support the 2507 derivation of fresh unicast and multicast transient session keys, 2508 even when the keying material provided by the backend 2509 authentication server is not fresh. This is typically supported by 2510 including an exchange of nonces within the Secure Association 2511 Protocol. 2513 Bi-directional operation 2514 While some ciphersuites only require a single set of transient 2515 session keys to protect traffic in both directions, other 2516 ciphersuites require a unique set of transient session keys in each 2517 direction. The phase 2 Secure Association Protocol SHOULD provide 2518 for the derivation of unicast and multicast keys in each direction, 2519 so as not to require two separate phase 2 exchanges in order to 2520 create a bi-directional phase 2 security association. 2522 Secure capabilities negotiation 2523 The Secure Association Protocol MUST support secure capabilities 2524 negotiation. This includes security parameters such as the 2525 security association identifier (SAID) and ciphersuites, as well as 2526 negotiation of the lifetime of the TSKs, AAA-Key and exported EAP 2527 keys. Secure capabilities negotiation also includes confirmation 2528 of the capabilities discovered during the discovery phase (phase 2529 0), so as to ensure that the announced capabilities have not been 2530 forged. 2532 Key Scoping 2533 The Secure Association Protocol MUST ensure the synchronization of 2534 key scope between the peer and authenticator. This includes 2535 negotiation of restrictions on key usage. 2537 5.4. Ciphersuite Requirements 2539 Ciphersuites suitable for keying by EAP methods MUST provide the 2540 following facilities: 2542 TSK derivation 2543 In order to allow a ciphersuite to be usable within the EAP keying 2544 framework, a specification MUST be provided describing how 2545 transient session keys suitable for use with the ciphersuite are 2546 derived from the AAA-Key. 2548 EAP method independence 2549 Algorithms for deriving transient session keys from the AAA-Key 2550 MUST NOT depend on the EAP method. However, algorithms for 2551 deriving TEKs MAY be specific to the EAP method. 2553 Cryptographic separation 2554 The TSKs derived from the AAA-Key MUST be cryptographically 2555 separate from each other. Similarly, TEKs MUST be 2556 cryptographically separate from each other. In addition, the TSKs 2557 MUST be cryptographically separate from the TEKs. 2559 6. IANA Considerations 2561 This section provides guidance to the Internet Assigned Numbers 2562 Authority (IANA) regarding registration of values related to EAP key 2563 management, in accordance with BCP 26, [RFC2434]. 2565 The following terms are used here with the meanings defined in BCP 2566 26: "name space", "assigned value", "registration". 2568 The following policies are used here with the meanings defined in BCP 2569 26: "Private Use", "First Come First Served", "Expert Review", 2570 "Specification Required", "IETF Consensus", "Standards Action". 2572 For registration requests where a Designated Expert should be 2573 consulted, the responsible IESG area director should appoint the 2574 Designated Expert. The intention is that any allocation will be 2575 accompanied by a published RFC. But in order to allow for the 2576 allocation of values prior to the RFC being approved for publication, 2577 the Designated Expert can approve allocations once it seems clear 2578 that an RFC will be published. The Designated expert will post a 2579 request to the EAP WG mailing list (or a successor designated by the 2580 Area Director) for comment and review, including an Internet-Draft. 2581 Before a period of 30 days has passed, the Designated Expert will 2582 either approve or deny the registration request and publish a notice 2583 of the decision to the EAP WG mailing list or its successor, as well 2584 as informing IANA. A denial notice must be justified by an 2585 explanation and, in the cases where it is possible, concrete 2586 suggestions on how the request can be modified so as to become 2587 acceptable. 2589 7. References 2591 7.1. Normative References 2593 [RFC2119] 2594 Bradner, S., "Key words for use in RFCs to Indicate Requirement 2595 Levels", BCP 14, RFC 2119, March 1997. 2597 [RFC2434] 2598 Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 2599 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 2601 [RFC3748] 2602 Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. Lefkowetz, 2603 "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. 2605 7.2. Informative References 2607 [RFC0793] 2608 Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 2609 September 1981. 2611 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 2612 1661, July 1994. 2614 [RFC1968] Meyer, G. and K. Fox, "The PPP Encryption Control Protocol 2615 (ECP)", RFC 1968, June 1996. 2617 [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing 2618 for Message Authentication", RFC 2104, February 1997. 2620 [RFC2246] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. 2621 and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, 2622 January 1999. 2624 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 2625 Internet Protocol", RFC 2401, November 1998. 2627 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 2628 RFC 2409, November 1998. 2630 [RFC2419] Sklower, K. and G. Meyer, "The PPP DES Encryption Protocol, 2631 Version 2 (DESE-bis)", RFC 2419, September 1998. 2633 [RFC2420] Kummert, H., "The PPP Triple-DES Encryption Protocol (3DESE)", 2634 RFC 2420, September 1998. 2636 [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D. and 2637 R. Wheeler, "A Method for Transmitting PPP Over Ethernet 2638 (PPPoE)", RFC 2516, February 1999. 2640 [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2641 2548, March 1999. 2643 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 2644 Implementation in Roaming", RFC 2607, June 1999. 2646 [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol", 2647 RFC 2716, October 1999. 2649 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 2650 Authentication Dial In User Service (RADIUS)", RFC 2865, June 2651 2000. 2653 [RFC3078] Pall, G. and G. Zorn, "Microsoft Point-To-Point Encryption 2654 (MPPE) Protocol", RFC 3078, March 2001. 2656 [RFC3079] Zorn, G., "Deriving Keys for use with Microsoft Point-to-Point 2657 Encryption (MPPE)", RFC 3079, March 2001. 2659 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial 2660 In User Service) Support For Extensible Authentication 2661 Protocol (EAP)", RFC 3579, September 2003. 2663 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese, 2664 "IEEE 802.1X Remote Authentication Dial In User Service 2665 (RADIUS) Usage Guidelines", RFC 3580, September 2003. 2667 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. 2668 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 2670 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public 2671 Keys Used For Exchanging Symmetric Keys", RFC 3766, April 2672 2004. 2674 [FIPSDES] National Institute of Standards and Technology, "Data 2675 Encryption Standard", FIPS PUB 46, January 1977. 2677 [DESMODES] 2678 National Institute of Standards and Technology, "DES Modes of 2679 Operation", FIPS PUB 81, December 1980, . 2682 [IEEE802] Institute of Electrical and Electronics Engineers, "IEEE 2683 Standards for Local and Metropolitan Area Networks: Overview 2684 and Architecture", ANSI/IEEE Standard 802, 1990. 2686 [IEEE80211] 2687 Institute of Electrical and Electronics Engineers, 2688 "Information technology - Telecommunications and information 2689 exchange between systems - Local and metropolitan area 2690 networks - Specific Requirements Part 11: Wireless LAN Medium 2691 Access Control (MAC) and Physical Layer (PHY) Specifications", 2692 IEEE IEEE Standard 802.11-1999, 1999. 2694 [IEEE8021X] 2695 Institute of Electrical and Electronics Engineers, "Local and 2696 Metropolitan Area Networks: Port-Based Network Access 2697 Control", IEEE Standard 802.1X-2004, September 2004. 2699 [IEEE8021Q] 2700 Institute of Electrical and Electronics Engineers, "IEEE 2701 Standards for Local and Metropolitan Area Networks: Draft 2702 Standard for Virtual Bridged Local Area Networks", IEEE 2703 Standard 802.1Q/D8, January 1998. 2705 [IEEE80211F] 2706 Institute of Electrical and Electronics Engineers, 2707 "Recommended Practice for Multi-Vendor Access Point 2708 Interoperability via an Inter-Access Point Protocol Across 2709 Distribution Systems Supporting IEEE 802.11 Operation", IEEE 2710 802.11F, July 2003. 2712 [IEEE80211i] 2713 Institute of Electrical and Electronics Engineers, "Draft 2714 Supplement to STANDARD FOR Telecommunications and Information 2715 Exchange between Systems - LAN/MAN Specific Requirements - 2716 Part 11: Wireless Medium Access Control (MAC) and physical 2717 layer (PHY) specifications: Specification for Enhanced 2718 Security", IEEE Draft 802.11I/ D8, February 2004. 2720 [IEEE-02-758] 2721 Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, 2722 "Proactive Caching Strategies for IAPP Latency Improvement 2723 during 802.11 Handoff", IEEE 802.11 Working Group, 2724 IEEE-02-758r1-F Draft 802.11I/D5.0, November 2002. 2726 [IEEE-03-084] 2727 Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, 2728 "Proactive Key Distribution to support fast and secure 2729 roaming", IEEE 802.11 Working Group, IEEE-03-084r1-I, 2730 http://www.ieee802.org/11/Documents/DocumentHolder/ 3-084.zip, 2731 January 2003. 2733 [IEEE-03-155] 2734 Aboba, B., "Fast Handoff Issues", IEEE 802.11 Working Group, 2735 IEEE-03-155r0-I, http://www.ieee802.org/11/ 2736 Documents/DocumentHolder/3-155.zip, March 2003. 2738 [I-D.ietf-roamops-cert] 2739 Aboba, B., "Certificate-Based Roaming", draft-ietf-roamops- 2740 cert-02 (work in progress), April 1999. 2742 [I-D.ietf-aaa-eap] 2743 Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible 2744 Authentication Protocol (EAP) Application", draft-ietf-aaa- 2745 eap-08 (work in progress), June 2004. 2747 [I-D.irtf-aaaarch-handoff] 2748 Arbaugh, W. and B. Aboba, "Handoff Extension to RADIUS", 2749 draft-irtf-aaaarch-handoff-04 (work in progress), October 2750 2003. 2752 [I-D.puthenkulam-eap-binding] 2753 Puthenkulam, J., "The Compound Authentication Binding 2754 Problem", draft-puthenkulam-eap-binding-04 (work in progress), 2755 October 2003. 2757 [I-D.aboba-802-context] 2758 Aboba, B. and T. Moore, "A Model for Context Transfer in IEEE 2759 802", draft-aboba-802-context-03 (work in progress), October 2760 2003. 2762 [I-D.arkko-pppext-eap-aka] 2763 Arkko, J. and H. Haverinen, "EAP AKA Authentication", draft- 2764 arkko-pppext-eap-aka-11 (work in progress), October 2003. 2766 [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", draft- 2767 ietf-ipsec-ikev2-12 (work in progress), March 2004. 2769 [8021XHandoff] 2770 Pack, S. and Y. Choi, "Pre-Authenticated Fast Handoff in a 2771 Public Wireless LAN Based on IEEE 802.1X Model", School of 2772 Computer Science and Engineering, Seoul National University, 2773 Seoul, Korea, 2002. 2775 [MD5Attack] 2776 Dobbertin, H., "The Status of MD5 After a Recent Attack", 2777 CryptoBytes, Vol.2 No.2, 1996. 2779 [WLANREQ] Stanley, D., Walker, J. and B. Aboba, "EAP Method Requirements 2780 for Wireless LANs", draft-walker-ieee802-req-02.txt (work in 2781 progress), July 2004. 2783 [Housley56] 2784 Housley, R., "Key Management in AAA", Presentation to the AAA 2785 WG at IETF 56, 2786 http://www.ietf.org/proceedings/03mar/slides/aaa-5/index.html, 2787 March 2003. 2789 Acknowledgments 2791 Thanks to Arun Ayyagari, Ashwin Palekar, and Tim Moore of Microsoft, 2792 Dorothy Stanley of Agere, Bob Moskowitz of TruSecure, and Russ 2793 Housley of Vigil Security for useful feedback. 2795 Author Addresses 2797 Bernard Aboba 2798 Microsoft Corporation 2799 One Microsoft Way 2800 Redmond, WA 98052 2802 EMail: bernarda@microsoft.com 2803 Phone: +1 425 706 6605 2804 Fax: +1 425 936 7329 2806 Dan Simon 2807 Microsoft Research 2808 Microsoft Corporation 2809 One Microsoft Way 2810 Redmond, WA 98052 2812 EMail: dansimon@microsoft.com 2813 Phone: +1 425 706 6711 2814 Fax: +1 425 936 7329 2816 Jari Arkko 2817 Ericsson 2818 Jorvas 02420 2819 Finland 2821 Phone: 2822 EMail: jari.arkko@ericsson.com 2824 Pasi Eronen 2825 Nokia Research Center 2826 P.O. Box 407 2827 FIN-00045 Nokia Group 2828 Finland 2830 EMail: pasi.eronen@nokia.com 2832 Henrik Levkowetz (editor) 2833 ipUnplugged AB 2834 Arenavagen 27 2835 Stockholm S-121 28 2836 SWEDEN 2838 Phone: +46 708 32 16 08 2839 EMail: henrik@levkowetz.com 2841 Appendix A - Ciphersuite Keying Requirements 2843 To date, PPP and IEEE 802.11 ciphersuites are suitable for keying by 2844 EAP. This Appendix describes the keying requirements of common PPP 2845 and 802.11 ciphersuites. 2847 PPP ciphersuites include DESEbis [RFC2419], 3DES [RFC2420], and MPPE 2848 [RFC3078]. The DES algorithm is described in [FIPSDES], and DES 2849 modes (such as CBC, used in [RFC2419] and DES-EDE3-CBC, used in 2850 [RFC2420]) are described in [DESMODES]. For PPP DESEbis, a single 2851 56-bit encryption key is required, used in both directions. For PPP 2852 3DES, a 168-bit encryption key is needed, used in both directions. As 2853 described in [RFC2419] for DESEbis and [RFC2420] for 3DES, the IV, 2854 which is different in each direction, is "deduced from an explicit 2855 64-bit nonce, which is exchanged in the clear during the [ECP] 2856 negotiation phase." There is therefore no need for the IV to be 2857 provided by EAP. 2859 For MPPE, 40-bit, 56-bit or 128-bit encryption keys are required in 2860 each direction, as described in [RFC3078]. No initialization vector 2861 is required. 2863 While these PPP ciphersuites provide encryption, they do not provide 2864 per-packet authentication or integrity protection, so an 2865 authentication key is not required in either direction. 2867 Within [IEEE80211], Transient Session Keys (TSKs) are required both 2868 for unicast traffic as well as for multicast traffic, and therefore 2869 separate key hierarchies are required for unicast keys and multicast 2870 keys. IEEE 802.11 ciphersuites include WEP-40, described in 2871 [IEEE80211], which requires a 40-bit encryption key, the same in 2872 either direction; and WEP-128, which requires a 104-bit encryption 2873 key, the same in either direction. These ciphersuites also do not 2874 support per-packet authentication and integrity protection. In 2875 addition to these unicast keys, authentication and encryption keys 2876 are required to wrap the multicast encryption key. 2878 Recently, new ciphersuites have been proposed for use with IEEE 2879 802.11 that provide per-packet authentication and integrity 2880 protection as well as encryption [IEEE80211i]. These include TKIP, 2881 which requires a single 128-bit encryption key and a 128-bit 2882 authentication key (used in both directions); AES CCMP, which 2883 requires a single 128-bit key (used in both directions) in order to 2884 authenticate and encrypt data; and WRAP, which requires a single 2885 128-bit key (used in both directions). 2887 As with WEP, authentication and encryption keys are also required to 2888 wrap the multicast encryption (and possibly, authentication) keys. 2890 Appendix B - Transient EAP Key (TEK) Hierarchy 2892 Figure B-1 illustrates the TEK key hierarchy for EAP-TLS [RFC2716], 2893 which is based on the TLS key hierarchy described in [RFC2246]. The 2894 TLS-negotiated ciphersuite is used to set up a protected channel for 2895 use in protecting the EAP conversation, keyed by the derived TEKs. 2896 The TEK derivation proceeds as follows: 2898 master_secret = TLS-PRF-48(pre_master_secret, "master secret", 2899 client.random || server.random) 2900 TEK = TLS-PRF-X(master_secret, "key expansion", 2901 server.random || client.random) 2902 Where: 2903 TLS-PRF-X = TLS pseudo-random function defined in [RFC2246], 2904 computed to X octets. 2905 master_secret = TLS term for the MK. 2907 | | | 2908 | | pre_master_secret | 2909 server| | | client 2910 Random| V | Random 2911 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2912 | | | | 2913 | | | | 2914 +---->| master_secret |<------+ 2915 | | (MK) | | 2916 | | | | 2917 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2918 | | | 2919 | | | 2920 | | | 2921 V V V 2922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2923 | | 2924 | | 2925 | Key Block | 2926 | (TEKs) | 2927 | | 2928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2929 | | | | | | 2930 | client | server | client | server | client | server 2931 | MAC | MAC | write | write | IV | IV 2932 | | | | | | 2933 V V V V V V 2935 Figure B-1 - TLS [RFC2246] Key Hierarchy 2937 Appendix C - EAP Key Hierarchy 2939 In EAP-TLS [RFC2716], the MSK is divided into two halves, 2940 corresponding to the "Peer to Authenticator Encryption Key" (Enc- 2941 RECV-Key, 32 octets, also known as the PMK) and "Authenticator to 2942 Peer Encryption Key" (Enc-SEND-Key, 32 octets). In [RFC2548], the 2943 Enc-RECV-Key (the PMK) is transported in the MS-MPPE-Recv-Key 2944 attribute, and the Enc-SEND-Key is transported in the MS-MPPE-Send- 2945 Key attribute. 2947 The EMSK is also divided into two halves, corresponding to the "Peer 2948 to Authenticator Authentication Key" (Auth-RECV-Key, 32 octets) and 2949 "Authenticator to Peer Authentication Key" (Auth-SEND-Key, 32 2950 octets). The IV is a 64 octet quantity that is a known value; octets 2951 0-31 are known as the "Peer to Authenticator IV" or RECV-IV, and 2952 Octets 32-63 are known as the "Authenticator to Peer IV", or SEND-IV. 2954 In EAP-TLS, the MSK, EMSK and IV are derived from the MK via a one- 2955 way function. This ensures that the MK cannot be derived from the 2956 MSK, EMSK or IV unless the one-way function (TLS PRF) is broken. 2957 Since the MSK is derived from the MK, if the MK is compromised then 2958 the MSK is also compromised. 2960 As described in [RFC2716], the formula for the derivation of the MSK, 2961 EMSK and IV from the MK is as follows: 2963 MSK = TLS-PRF-64(MK, "client EAP encryption", 2964 client.random || server.random) 2965 EMSK = second 64 octets of: 2966 TLS-PRF-128(MK, "client EAP encryption", 2967 client.random || server.random) 2968 IV = TLS-PRF-64("", "client EAP encryption", 2969 client.random || server.random) 2971 AAA-Key(0,31) = Peer to Authenticator Encryption Key (Enc-RECV-Key) 2972 (MS-MPPE-Recv-Key in [RFC2548]). Also known as the 2973 PMK. 2974 AAA-Key(32,63)= Authenticator to Peer Encryption Key (Enc-SEND-Key) 2975 (MS-MPPE-Send-Key in [RFC2548]) 2976 EMSK(0,31) = Peer to Authenticator Authentication Key (Auth-RECV-Key) 2977 EMSK(32,63) = Authenticator to Peer Authentication Key (Auth-Send-Key) 2978 IV(0,31) = Peer to Authenticator Initialization Vector (RECV-IV) 2979 IV(32,63) = Authenticator to Peer Initialization vector (SEND-IV) 2981 Where: 2983 AAA-Key(W,Z) = Octets W through Z includes of the AAA-Key. 2985 IV(W,Z) = Octets W through Z inclusive of the IV. 2986 MSK(W,Z) = Octets W through Z inclusive of the MSK. 2987 EMSK(W,Z) = Octets W through Z inclusive of the EMSK. 2988 MK = TLS master_secret 2989 TLS-PRF-X = TLS PRF function defined in [RFC2246] computed to X octets 2990 client.random = Nonce generated by the TLS client. 2991 server.random = Nonce generated by the TLS server. 2993 Figure C-1 describes the process by which the MSK,EMSK,IV and 2994 ultimately the TSKs, are derived from the MK. Note that in [RFC2716], 2995 the MK is referred to as the "TLS Master Secret". 2997 ---+ 2998 | ^ 2999 | TLS Master Secret (MK) | 3000 | | 3001 V | 3002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3003 | | EAP | 3004 | Master Session Key (MSK) | Method | 3005 | Derivation | | 3006 | | V 3007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ EAP ---+ 3008 | | | API ^ 3009 | MSK | EMSK | IV | 3010 | | | | 3011 V V V v 3012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 3013 | | | 3014 | | | 3015 | backend authentication server | | 3016 | | | 3017 | | V 3018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 3019 | | ^ 3020 | AAA-Key(0,31) | AAA-Key(32,63) | 3021 | (PMK) | Transported | 3022 | | via AAA | 3023 | | | 3024 V V V 3025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 3026 | | ^ 3027 | Ciphersuite-Specific Transient Session | Auth.| 3028 | Key Derivation | | 3029 | | V 3030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 3032 Figure C-1 - EAP TLS [RFC2716] Key hierarchy 3034 Appendix D - Transient Session Key (TSK) Derivation 3036 Within IEEE 802.11 RSN, the Pairwise Transient Key (PTK), a transient 3037 session key used to protect unicast traffic, is derived from the PMK 3038 (octets 0-31 of the MSK), known in [RFC2716] as the Peer to 3039 Authenticator Encryption Key. In [IEEE80211i], the PTK is derived 3040 from the PMK via the following formula: 3042 PTK = EAPOL-PRF-X(PMK, "Pairwise key expansion", Min(AA,SA) || 3043 Max(AA, SA) || Min(ANonce,SNonce) || Max(ANonce,SNonce)) 3045 Where: 3047 PMK = AAA-Key(0,31) 3048 SA = Station MAC address (Calling-Station-Id) 3049 AA = Access Point MAC address (Called-Station-Id) 3050 ANonce = Access Point Nonce 3051 SNonce = Station Nonce 3052 EAPOL-PRF-X = Pseudo-Random Function based on HMAC-SHA1, generating 3053 a PTK of size X octets. 3055 TKIP uses X = 64, while CCMP, WRAP, and WEP use X = 48. 3057 The EAPOL-Key Confirmation Key (KCK) is used to provide data origin 3058 authenticity in the TSK derivation. It utilizes the first 128 bits 3059 (bits 0-127) of the PTK. The EAPOL-Key Encryption Key (KEK) provides 3060 confidentiality in the TSK derivation. It utilizes bits 128-255 of 3061 the PTK. Bits 256-383 of the PTK are used by Temporal Key 1, and Bits 3062 384-511 are used by Temporal Key 2. Usage of TK1 and TK2 is 3063 ciphersuite specific. Details are available in [IEEE80211i]. 3065 Appendix E - AAA-Key Derivation 3067 Where a AAA-Key is generated as the result of a successful EAP 3068 authentication, the AAA-Key is set to MSK(0,63). 3070 As discussed in [I-D.irtf-aaaarch-handoff], [IEEE-02-758], 3071 [IEEE-03-084], and [8021XHandoff], keying material may be required 3072 for use in fast handoff between authenticators. Where the backend 3073 authentication server provides keying material to multiple 3074 authenticators in order to facilitate fast handoff, it is highly 3075 desirable for the keying material used on different authenticators to 3076 be cryptographically separate, so that if one authenticator is 3077 compromised, it does not lead to the compromise of other 3078 authenticators. Where keying material is provided by the backend 3079 authentication server, a key hierarchy derived from the EMSK, can be 3080 used to provide cryptographically separate keying material for use in 3081 fast handoff: 3083 AAA-Key-A = MSK(0,63) 3084 AAA-Key-B = PRF(EMSK(0,63),"EAP AAA-Key derivation for 3085 multiple attachments", AAA-Key-A,B-Called-Station-Id, 3086 Calling-Station-Id,length) 3088 AAA-Key-E = PRF(EMSK(0,63),"EAP AAA-Key derivation for 3089 multiple attachments",AAA-Key-A,E-Called-Station-Id, 3090 Calling-Station-Id, length) 3092 Where: 3093 Calling-Station-Id = STA MAC address 3094 B-Called-Station-Id = AP B MAC address 3095 E-Called-Station-Id = AP E MAC address 3096 length = length of derived key material 3098 Here AAA-Key-A is the AAA-Key derived during the initial EAP 3099 authentication between the peer and authenticator A. Based on this 3100 initial EAP authentication, the EMSK is also derived, which can be 3101 used to derive AAA-Keys for fast authentication between the EAP peer 3102 and authenticators B and E. Since the EMSK is cryptographically 3103 separate from the MSK, each of these AAA-Keys is cryptographically 3104 separate from each other, and are guaranteed to be unique between the 3105 EAP peer (also known as the STA) and the authenticator (also known as 3106 the AP). 3108 Intellectual Property Statement 3110 The IETF takes no position regarding the validity or scope of any 3111 intellectual property or other rights that might be claimed to 3112 pertain to the implementation or use of the technology described in 3113 this document or the extent to which any license under such rights 3114 might or might not be available; neither does it represent that it 3115 has made any effort to identify any such rights. Information on the 3116 IETF's procedures with respect to rights in standards-track and 3117 standards- related documentation can be found in BCP-11. Copies of 3118 claims of rights made available for publication and any assurances of 3119 licenses to be made available, or the result of an attempt made to 3120 obtain a general license or permission for the use of such 3121 proprietary rights by implementors or users of this specification can 3122 be obtained from the IETF Secretariat. 3124 The IETF invites any interested party to bring to its attention any 3125 copyrights, patents or patent applications, or other proprietary 3126 rights which may cover technology that may be required to practice 3127 this standard. Please address the information to the IETF Executive 3128 Director. 3130 Full Copyright Statement 3132 Copyright (C) The Internet Society (2004). All Rights Reserved. 3134 This document and translations of it may be copied and furnished to 3135 others, and derivative works that comment on or otherwise explain it 3136 or assist in its implementation may be prepared, copied, published 3137 and distributed, in whole or in part, without restriction of any 3138 kind, provided that the above copyright notice and this paragraph are 3139 included on all such copies and derivative works. However, this 3140 document itself may not be modified in any way, such as by removing 3141 the copyright notice or references to the Internet Society or other 3142 Internet organizations, except as needed for the purpose of 3143 developing Internet standards in which case the procedures for 3144 copyrights defined in the Internet Standards process must be 3145 followed, or as required to translate it into languages other than 3146 English. The limited permissions granted above are perpetual and 3147 will not be revoked by the Internet Society or its successors or 3148 assigns. This document and the information contained herein is 3149 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 3150 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 3151 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 3152 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3153 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 3155 Open Issues 3157 Open issues relating to this specification are tracked on the 3158 following web site: 3160 http://www.drizzle.com/~aboba/EAP/eapissues.html 3162 Expiration Date 3164 This memo is filed as , and expires 3165 December 22, 2004.