idnits 2.17.1 draft-ietf-eap-keying-03.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 72 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 73 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 88 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 1987 has weird spacing: '...ude the key s...' == Line 3338 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 141, but not defined -- Looks like a reference, but probably isn't: '1' on line 1903 -- Looks like a reference, but probably isn't: '2' on line 1906 -- Looks like a reference, but probably isn't: '3' on line 1912 -- Looks like a reference, but probably isn't: '4' on line 1160 -- Looks like a reference, but probably isn't: '5' on line 416 == Missing Reference: 'IEEE802.11i' is mentioned on line 1374, but not defined == Missing Reference: 'RFC3784' is mentioned on line 1886, but not defined ** Obsolete undefined reference: RFC 3784 (Obsoleted by RFC 5305) == Missing Reference: 'RFC3162' is mentioned on line 2272, but not defined == Missing Reference: 'RFC3759' is mentioned on line 2320, but not defined == Missing Reference: 'ECP' is mentioned on line 2971, but not defined == Missing Reference: 'SHA1' is mentioned on line 3255, but not defined == Missing Reference: 'TLS' is mentioned on line 3273, but not defined == Missing Reference: 'SIGMA' is mentioned on line 3274, but not defined == Unused Reference: 'RFC0793' is defined on line 2724, but no explicit reference was found in the text == Unused Reference: 'RFC2401' is defined on line 2741, but no explicit reference was found in the text == Unused Reference: 'RFC3079' is defined on line 2773, but no explicit reference was found in the text == Unused Reference: 'IEEE802' is defined on line 2799, but no explicit reference was found in the text == Unused Reference: 'IEEE80211F' is defined on line 2822, but no explicit reference was found in the text == Unused Reference: 'IEEE-03-155' is defined on line 2850, but no explicit reference was found in the text == Unused Reference: 'I-D.aboba-802-context' is defined on line 2874, 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-14 == Outdated reference: A later version (-04) exists of draft-walker-ieee802-req-02 Summary: 6 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 18 July 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 Key Naming ...................................... 24 58 3. Security associations ................................. 26 59 3.1 EAP Method SA ................................... 26 60 3.2 EAP-Key SA ...................................... 28 61 3.3 AAA SA(s) ....................................... 28 62 3.4 Service SA(s) ................................... 29 63 4. Handoff Support ....................................... 34 64 4.1 Key Scope Issues ................................ 35 65 4.2 Authorization Issues ............................ 36 66 4.3 Correctness Issues .............................. 38 67 5. Security Considerations .............................. 40 68 5.1 Security Terminology ............................ 40 69 5.2 Threat Model .................................... 41 70 5.3 Security Analysis ............................... 43 71 5.4 Man-in-the-middle Attacks ....................... 47 72 5.5 Denial of Service Attacks ....................... 47 73 5.6 Impersonation ................................... 48 74 5.7 Channel Binding ................................. 49 75 5.8 Key Strength .................................... 50 76 5.9 Key Wrap ........................................ 50 78 6. Security Requirements ................................. 51 79 6.1 EAP Method Requirements ......................... 51 80 6.2 AAA Protocol Requirements ....................... 54 81 6.3 Secure Association Protocol Requirements ........ 55 82 6.4 Ciphersuite Requirements ........................ 57 83 7. IANA Considerations ................................... 58 84 8. References ............................................ 59 85 8.1 Normative References ............................ 59 86 8.2 Informative References .......................... 59 87 Acknowledgments .............................................. 63 88 Author's Addresses ........................................... 63 89 Appendix A - Ciphersuite Keying Requirements ................. 65 90 Appendix B - Transient EAP Key (TEK) Hierarchy ............... 66 91 Appendix C - EAP Key Hierarchy ............................... 67 92 Appendix D - Transient Session Key (TSK) Derivation .......... 69 93 Appendix E - AAA-Key Derivation .............................. 70 94 Appendix F - AMSK Derivation ................................. 71 95 Intellectual Property Statement .............................. 72 96 Full Copyright Statement ..................................... 72 98 1. Introduction 100 The Extensible Authentication Protocol (EAP), defined in [RFC3748], 101 was designed to enable extensible authentication for network access 102 in situations in which the IP protocol is not available. Originally 103 developed for use with PPP [RFC1661], it has subsequently also been 104 applied to IEEE 802 wired networks [IEEE8021X]. 106 This document provides a framework for the generation, transport and 107 usage of keying material generated by EAP authentication algorithms, 108 known as "methods". Since in EAP keying material is generated by EAP 109 methods, transported by AAA protocols, transformed into session keys 110 by Secure Association Protocols and used by lower layer ciphersuites, 111 it is necessary to describe each of these elements and provide a 112 system-level security analysis. 114 1.1. Requirements Language 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in BCP 14 [RFC2119]. 120 1.2. Terminology 122 This document frequently uses the following terms: 124 authenticator 125 The end of the link initiating EAP authentication. The term 126 Authenticator is used in [IEEE-802.1X], and authenticator has the 127 same meaning in this document. 129 peer The end of the link that responds to the authenticator. In 130 [IEEE-802.1X], this end is known as the Supplicant. 132 Supplicant 133 The end of the link that responds to the authenticator in 134 [IEEE-802.1X]. In this document, this end of the link is called 135 the peer. 137 backend authentication server 138 A backend authentication server is an entity that provides an 139 authentication service to an authenticator. When used, this server 140 typically executes EAP methods for the authenticator. This 141 terminology is also used in [IEEE-802.1X]. 143 AAA Authentication, Authorization and Accounting. AAA protocols with 144 EAP support include RADIUS [RFC3579] and Diameter [I-D.ietf-aaa- 145 eap]. In this document, the terms "AAA server" and "backend 146 authentication server" are used interchangeably. 148 EAP server 149 The entity that terminates the EAP authentication method with the 150 peer. In the case where no backend authentication server is used, 151 the EAP server is part of the authenticator. In the case where the 152 authenticator operates in pass-through mode, the EAP server is 153 located on the backend authentication server. 155 security association 156 A set of policies and key(s) used to protect information. This 157 information in the security association is stored by each party of 158 the security association and must be consistent among the parties. 159 Elements of a security association include cryptographic keys, 160 negotiated ciphersuites and other parameters, counters, sequence 161 spaces, authorization attributes, etc. 163 1.3. Overview 165 EAP is typically deployed in order to support extensible network 166 access authentication in situations where a peer desires network 167 access via one or more authenticators. The situation is illustrated 168 in Figure 1. 170 Since both the peer and authenticator may have more than one physical 171 or logical port, a given peer may simultaneously access the network 172 via multiple authenticators, or via multiple physical or logical 173 ports on a given authenticator. Similarly, an authenticator may 174 offer network access to multiple peers, each via a separate physical 175 or logical port. 177 The peer may be stationary, in which case it may establish 178 communications with one or more authenticators while remaining in one 179 location. Alternatively, the peer may be mobile, changing its point 180 of attachment from one authenticator to another, or moving between 181 points of attachment on a single authenticator. 183 Where authenticators are deployed standalone, the EAP conversation 184 occurs between the peer and authenticator, and the authenticator must 185 locally implement an EAP method acceptable to the peer. 187 However, one of the advantages of EAP is that it enables deployment 188 of new authentication methods without requiring development of new 189 code on the authenticator. While the authenticator may implement 190 some EAP methods locally and use those methods to authenticate local 191 users, it may at the same time act as a pass-through for other users 192 and methods, forwarding EAP packets back and forth between the 193 backend authentication server and the peer. 195 +-+-+-+-+ 196 | | 197 | EAP | 198 | Peer | 199 | | 200 +-+-+-+-+ 201 | | | Peer Ports 202 / | \ 203 / | \ 204 Phase 0: Discovery / | \ 205 Phase 1: Authentication / | \ 206 Phase 2: Secure / | \ 207 Association / | \ 208 / | \ 209 / | \ 210 | | | | | | | | | Authenticator Ports 211 +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ 212 | | | | | | 213 | Auth. | | Auth. | | Auth. | 214 | | | | | | 215 +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ 216 \ | / 217 \ | / 218 \ | / 219 EAP over AAA \ | / 220 (optional) \ | / 221 \ | / 222 \ | / 223 \ | / 224 +-+-+-+-+ 225 | | 226 | AAA | 227 |Server | 228 | | 229 +-+-+-+-+ 231 Figure 1: Relationship between peer, authenticator and backend server 233 This is accomplished by encapsulating EAP packets within the 234 Authentication, Authorization and Accounting (AAA) protocol, spoken 235 between the authenticator and backend authentication server. AAA 236 protocols supporting EAP include RADIUS [RFC3579] and Diameter [I- 237 D.ietf-aaa-eap]. 239 Where EAP key derivation is supported, the conversation between the 240 peer and the authenticator typically takes place in three phases: 242 Phase 0: Discovery 243 Phase 1: Authentication 244 1a: EAP authentication 245 1b: AAA-Key Transport (optional) 246 Phase 2: Secure Association Establishment 247 2a: Unicast Secure Association 248 2b: Multicast Secure Association (optional) 250 In the discovery phase (phase 0), peers locate authenticators and 251 discover their capabilities. For example, a peer may locate an 252 authenticator providing access to a particular network, or a peer may 253 locate an authenticator behind a bridge with which it desires to 254 establish a Secure Association. 256 The authentication phase (phase 1) may begin once the peer and 257 authenticator discover each other. This phase always includes EAP 258 authentication (phase 1a). Where the chosen EAP method supports key 259 derivation, in phase 1a keying material is derived on both the peer 260 and the EAP server. This keying material may be used for multiple 261 purposes, including protection of the EAP conversation and subsequent 262 data exchanges. 264 An additional step (phase 1b) is required in deployments which 265 include a backend authentication server, in order to transport keying 266 material (known as the AAA-Key) from the backend authentication 267 server to the authenticator. 269 A Secure Association exchange (phase 2) then occurs between the peer 270 and authenticator in order to manage the creation and deletion of 271 unicast (phase 2a) and multicast (phase 2b) security associations 272 between the peer and authenticator. 274 The conversation phases and relationship between the parties is shown 275 in Figure 2. 277 EAP peer Authenticator Auth. Server 278 -------- ------------- ------------ 279 |<----------------------------->| | 280 | Discovery (phase 0) | | 281 |<----------------------------->|<----------------------------->| 282 | EAP auth (phase 1a) | AAA pass-through (optional) | 283 | | | 284 | |<----------------------------->| 285 | | AAA-Key transport | 286 | | (optional; phase 1b) | 287 |<----------------------------->| | 288 | Unicast Secure association | | 289 | (phase 2a) | | 290 | | | 291 |<----------------------------->| | 292 | Multicast Secure association | | 293 | (optional; phase 2b) | | 294 | | | 296 Figure 2: Conversation Overview 298 1.3.1. Discovery Phase 300 In the discovery phase (phase 0), the EAP peer and authenticator 301 locate each other and discover each other's capabilities. Discovery 302 can occur manually or automatically, depending on the lower layer 303 over which EAP runs. Since discovery is handled outside of EAP, 304 there is no need to provide this functionality within EAP. 306 For example, where EAP runs over PPP, the EAP peer might be 307 configured with a phone book providing phone numbers of 308 authenticators and associated capabilities such as supported rates, 309 authentication protocols or ciphersuites. 311 In contrast, PPPoE [RFC2516] provides support for a Discovery Stage 312 to allow a peer to identify the Ethernet MAC address of one or more 313 authenticators and establish a PPPoE SESSION_ID. 315 IEEE 802.11 [IEEE80211] also provides integrated discovery support 316 utilizing Beacon and/or Probe Request/Response frames, allowing the 317 peer (known as the station or STA) to determine the MAC address and 318 capabilities of one or more authenticators (known as Access Point or 319 APs). 321 1.3.2. Authentication Phase 323 Once the peer and authenticator discover each other, they exchange 324 EAP packets. Typically, the peer desires access to the network, and 325 the authenticators provide that access. In such a situation, access 326 to the network can be provided by any authenticator attaching to the 327 desired network, and the EAP peer is typically willing to send data 328 traffic through any authenticator that can demonstrate that it is 329 authorized to provide access to the desired network. 331 An EAP authenticator may handle the authentication locally, or it may 332 act as a pass-through to a backend authentication server. In the 333 latter case the EAP exchange occurs between the EAP peer and a 334 backend authenticator server, with the authenticator forwarding EAP 335 packets between the two. The entity which terminates EAP 336 authentication with the peer is known as the EAP server. Where pass- 337 through is supported, the backend authentication server functions as 338 the EAP server; where authentication occurs locally, the EAP server 339 is the authenticator. Where a backend authentication server is 340 present, at the successful completion of an authentication exchange, 341 the AAA-Key is transported to the authenticator (phase 1b). 343 EAP may also be used when it is desired for two network devices (e.g. 344 two switches or routers) to authenticate each other, or where two 345 peers desire to authenticate each other and set up a secure 346 association suitable for protecting data traffic. 348 Some EAP methods exist which only support one-way authentication; 349 however, EAP methods deriving keys are required to support mutual 350 authentication. In either case, it can be assumed that the parties 351 do not utilize the link to exchange data traffic unless their 352 authentication requirements have been met. For example, a peer 353 completing mutual authentication with an EAP server will not send 354 data traffic over the link until the EAP server has authenticated 355 successfully to the peer, and a Secure Association has been 356 negotiated. 358 Since EAP is a peer-to-peer protocol, an independent and simultaneous 359 authentication may take place in the reverse direction. Both peers 360 may act as authenticators and authenticatees at the same time. 362 Successful completion of EAP authentication and key derivation by a 363 peer and EAP server does not necessarily imply that the peer is 364 committed to joining the network associated with an EAP server. 365 Rather, this commitment is implied by the creation of a security 366 association between the EAP peer and authenticator, as part of the 367 Secure Association Protocol (phase 2). As a result, EAP may be used 368 for "pre-authentication" in situations where it is necessary to pre- 369 establish EAP security associations in order to decrease handoff or 370 roaming latency. 372 1.3.3. Secure Association Phase 374 The Secure Association phase (phase 2) always occurs after the 375 completion of EAP authentication (phase 1a) and key transport (phase 376 1b), and typically supports the following features: 378 [1] Entity Naming. A basic feature of a Secure Association Protocol is 379 the naming of the parties engaged in the exchange. As illustrated 380 in Figure 1, it is possible for both the peer and NAS to have more 381 than one physical or virtual port. For the purposes of 382 identification, it is therefore not possible to identify either 383 peers or NAS devices using port identifiers. Proper identification 384 of the parties is critical to the Secure Association phase, since 385 without this the parties engaged in the exchange are not identified 386 and the scope of the transient session keys (TSKs) generated during 387 the exchange is undefined. 389 [2] Secure capabilities negotiation. This provides for the secure 390 negotiation of usage modes, session parameters (such as key 391 lifetimes), ciphersuites, and required filters, including 392 confirmation of the capabilities discovered during phase 0. By 393 securely negotiating session parameters, the secure Association 394 Protocol protects against spoofing during the discovery phase and 395 ensures that the peer and authenticator are in agreement about how 396 data is to be secured. 398 [3] Generation of fresh transient session keys (TSKs). The Secure 399 Association Protocol typically guarantees the freshness of session 400 keys by exchanging nonces between both parties and then mixing the 401 nonces with the AAA-Key in order to generate fresh unicast (phase 402 2a) and multicast (phase 2b) session keys. By not using the AAA- 403 Key directly to protect data, the secure Association Protocol 404 protects against compromise of the AAA-Key, and by guaranteeing the 405 freshness of transient session keys, assures that they are not 406 reused. 408 [4] Key activation and deletion. In order for the peer and 409 authenticator to communicate securely, it is necessary for both 410 sides to derive the same session keys, and remain in sync with 411 respect to key state going forward. One of the functions of the 412 Secure Association Protocol is to synchronize the activation and 413 deletion of keys so as to enable seamless rekey, or recovery from 414 partial or complete loss of key state by the peer or authenticator. 416 [5] Mutual proof of possession of the AAA-Key. This demonstrates that 417 both the peer and authenticator have been authenticated and 418 authorized by the backend authentication server. Since mutual 419 proof of possession is not the same as mutual authentication, the 420 peer cannot verify authenticator assertions (including the 421 authenticator identity) as a result of this exchange. 423 1.4. EAP Invariants 425 By utilizing a three phase exchange, the EAP key management framework 426 guarantees that certain basic characteristics, known as the "EAP 427 Invariants" hold true for all implementations of EAP. These include: 429 Media independence 430 Method independence 431 Ciphersuite independence 433 1.4.1. Media Independence 435 One of the goals of EAP is to allow EAP methods to function on any 436 lower layer meeting the criteria outlined in [RFC3748], Section 3.1. 437 For example, as described in [RFC3748], EAP authentication can be run 438 over PPP [RFC1661], IEEE 802 wired networks [IEEE8021X], and IEEE 439 802.11 wireless LANs [IEEE80211i]. 441 In order to maintain media independence, it is necessary for EAP to 442 avoid inclusion of media-specific elements. For example, EAP methods 443 cannot be assumed to have knowledge of the lower layer over which 444 they are transported, and cannot utilize identifiers associated with 445 a particular usage environment (e.g. MAC addresses). 447 The need for media independence has also motivated the development of 448 the three phase exchange. Since discovery is typically media- 449 specific, this function is handled outside of EAP, rather than being 450 incorporated within it. Similarly, the Secure Association Protocol 451 often contains media dependencies such as negotiation of media- 452 specific ciphersuites or session parameters, and as a result this 453 functionality also cannot be incorporated within EAP. 455 Note that media independence may be retained within EAP methods that 456 support channel binding or method-specific identification. An EAP 457 method need not be aware of the content of an identifier in order to 458 use it. This enables an EAP method to use media-specific identifiers 459 such as MAC addresses without compromising media independence. To 460 support channel binding, an EAP method can pass binding parameters to 461 the AAA server in the form of an opaque blob, and receive 462 confirmation of whether the parameters match, without requiring 463 media-specific knowledge. 465 1.4.2. Method Independence 467 By enabling pass-through, authenticators can support any method 468 implemented on the peer and server, not just locally implemented 469 methods. This allows the authenticator to avoid implementing code 470 for each EAP method required by peers. In fact, since a pass-through 471 authenticator is not required to implement any EAP methods at all, it 472 cannot be assumed to support any EAP method-specific code. 474 As a result, as noted in [RFC3748], authenticators must by default be 475 capable of supporting any EAP method. Since the Discovery and Secure 476 Association exchanges are also method independent, an authenticator 477 can carry out the three phase exchange without having an EAP method 478 in common with the peer. 480 This is useful where there is no single EAP method that is both 481 mandatory-to-implement and offers acceptable security for the media 482 in use. For example, the [RFC3748] mandatory-to-implement EAP method 483 (MD5-Challenge) does not provide dictionary attack resistance, mutual 484 authentication or key derivation, and as a result is not appropriate 485 for use in wireless LAN authentication [WLANREQ]. However, despite 486 this it is possible for the peer and authenticator to interoperate as 487 long as a suitable EAP method is supported on the EAP server. 489 1.4.3. Ciphersuite Independence 491 While EAP methods may negotiate the ciphersuite used in protection of 492 the EAP conversation, the ciphersuite used for the protection of data 493 is negotiated within the Secure Association Protocol, out-of-band of 494 EAP. 496 The backend authentication server is not a party to this negotiation 497 nor is it an intermediary in the data flow between the EAP peer and 498 authenticator. The backend authentication server may not even have 499 knowledge of the ciphersuites implemented by the peer and 500 authenticator, or be aware of the ciphersuite negotiated between 501 them, and therefore does not implement ciphersuite-specific code. 503 Since ciphersuite negotiation occurs in the Secure Association 504 protocol, not in EAP, ciphersuite-specific key generation, if 505 implemented within an EAP method, would potentially conflict with the 506 transient session key derivation occurring in the Secure Association 507 protocol. As a result, EAP methods generate keying material that is 508 ciphersuite-independent. Additional advantages of ciphersuite- 509 independence include: 511 Update requirements 512 If EAP methods were to specify how to derive transient session keys 513 for each ciphersuite, they would need to be updated each time a new 514 ciphersuite is developed. In addition, backend authentication 515 servers might not be usable with all EAP-capable authenticators, 516 since the backend authentication server would also need to be 517 updated each time support for a new ciphersuite is added to the 518 authenticator. 520 EAP method complexity 521 Requiring each EAP method to include ciphersuite-specific code for 522 transient session key derivation would increase method complexity 523 and result in duplicated effort. 525 Knowledge of capabilities 526 In practice, an EAP method may not have knowledge of the 527 ciphersuite that has been negotiated between the peer and 528 authenticator, since this negotiation typically occurs within the 529 Secure Association Protocol. 531 For example, PPP ciphersuite negotiation occurs in the Encryption 532 Control Protocol (ECP) [RFC1968]. Since ECP negotiation occurs 533 after authentication, unless an EAP method is utilized that 534 supports ciphersuite negotiation, the peer, authenticator and 535 backend authentication server may not be able to anticipate the 536 negotiated ciphersuite and therefore this information cannot be 537 provided to the EAP method. Since ciphersuite negotiation is 538 assumed to occur out-of-band, there is no need for ciphersuite 539 negotiation within EAP. 541 For example, a peer might be pre-configured with policy indicating 542 the ciphersuite to be used in communicating with a given 543 authenticator. Within PPP, the ciphersuite is negotiated within 544 the Encryption Control Protocol (ECP), after EAP authentication is 545 completed. Within [IEEE80211i], the AP ciphersuites are advertised 546 in the Beacon and Probe Responses, and are securely verified during 547 a 4-way handshake exchange after EAP authentication has completed. 549 2. EAP Key Hierarchy 551 2.1. Key Terminology 553 The EAP Key Hierarchy makes use of the following types of keys: 555 Long Term Credential 556 EAP methods frequently make use of long term secrets in order to 557 enable authentication between the peer and server. In the case of 558 a method based on pre-shared key authentication, the long term 559 credential is the pre-shared key. In the case of a public-key 560 based method, the long term credential is the corresponding private 561 key. 563 Master Session Key (MSK) 564 Keying material that is derived between the EAP peer and server and 565 exported by the EAP method. The MSK is at least 64 octets in 566 length. 568 Extended Master Session Key (EMSK) 569 Additional keying material derived between the peer and server that 570 is exported by the EAP method. The EMSK is at least 64 octets in 571 length, and is never shared with a third party. 573 AAA-Key 574 A key derived by the peer and EAP server, used by the peer and 575 authenticator in the derivation of Transient Session Keys (TSKs). 576 Where a backend authentication server is present, the AAA-Key is 577 transported from the backend authentication server to the 578 authenticator, wrapped within the AAA-Token; it is therefore known 579 by the peer, authenticator and backend authentication server. 580 Despite the name, the AAA-Key is computed regardless of whether a 581 backend authentication server is present. AAA-Key derivation is 582 discussed in Appendix E; in existing implementations the MSK is 583 used as the AAA-Key. 585 Application-specific Master Session Keys (AMSKs) 586 Keys derived from the EMSK which are cryptographically separate 587 from each other and may be subsequently used in the derivation of 588 Transient Session Keys (TSKs) for extended uses. AMSK derivation 589 is discussed in Appendix F. 591 AAA-Token 592 Where a backend server is present, the AAA-Key and one or more 593 attributes is transported between the backend authentication server 594 and the authenticator within a package known as the AAA-Token. The 595 format and wrapping of the AAA-Token, which is intended to be 596 accessible only to the backend authentication server and 597 authenticator, is defined by the AAA protocol. Examples include 598 RADIUS [RFC2548] and Diameter [I-D.ietf-aaa-eap]. 600 Initialization Vector (IV) 601 A quantity of at least 64 octets, suitable for use in an 602 initialization vector field, that is derived between the peer and 603 EAP server. Since the IV is a known value in methods such as EAP- 604 TLS [RFC2716], it cannot be used by itself for computation of any 605 quantity that needs to remain secret. As a result, its use has 606 been deprecated and EAP methods are not required to generate it. 607 However, when it is generated it MUST be unpredictable. 609 Pairwise Master Key (PMK) 610 The AAA-Key is divided into two halves, the "Peer to Authenticator 611 Encryption Key" (Enc-RECV-Key) and "Authenticator to Peer 612 Encryption Key" (Enc-SEND-Key) (reception is defined from the point 613 of view of the authenticator). Within [IEEE80211i] Octets 0-31 of 614 the AAA-Key (Enc-RECV-Key) are known as the Pairwise Master Key 615 (PMK). In [IEEE80211i] the TKIP and AES CCMP ciphersuites derive 616 their Transient Session Keys (TSKs) solely from the PMK, whereas 617 the WEP ciphersuite as noted in [RFC3580], derives its TSKs from 618 both halves of the AAA-Key. 620 Transient EAP Keys (TEKs) 621 Session keys which are used to establish a protected channel 622 between the EAP peer and server during the EAP authentication 623 exchange. The TEKs are appropriate for use with the ciphersuite 624 negotiated between EAP peer and server for use in protecting the 625 EAP conversation. Note that the ciphersuite used to set up the 626 protected channel between the EAP peer and server during EAP 627 authentication is unrelated to the ciphersuite used to subsequently 628 protect data sent between the EAP peer and authenticator. An 629 example TEK key hierarchy is described in Appendix C. 631 Transient Session Keys (TSKs) 632 Session keys used to protect data which are appropriate for the 633 ciphersuite negotiated between the EAP peer and authenticator. The 634 TSKs are derived from AAA-Key during the Secure Association 635 Protocol. In the case of [IEEE80211i] the Secure Association 636 Protocol consists of the 4-way handshake and group key derivation. 637 An example TSK derivation is provided in Appendix D. 639 2.2. Key Hierarchy 641 The EAP Key Hierarchy, illustrated in Figure 3, has at the root the 642 long term credential utilized by the selected EAP method. If 643 authentication is based on a pre-shared key, the parties store the 644 EAP method to be used and the pre-shared key. The EAP server also 645 stores the peer's identity and/or other information necessary to 646 decide whether access to some service should be granted. The peer 647 stores information necessary to choose which secret to use for which 648 service. 650 If authentication is based on proof of possession of the private key 651 corresponding to the public key contained within a certificate, the 652 parties store the EAP method to be used and the trust anchors used to 653 validate the certificates. The EAP server also stores the peer's 654 identity and/or other information necessary to decide whether access 655 to some service should be granted. The peer stores information 656 necessary to choose which certificate to use for which service. 658 Based on the long term credential established between the peer and 659 the server, EAP derives four types of keys: 661 [1] Keys calculated locally by the EAP method but not exported 662 by the EAP method, such as the TEKs. 663 [2] Keys exported by the EAP method: MSK, EMSK, IV 664 [3] Keys calculated from exported quantities: AAA-Key, AMSKs. 665 [4] Keys calculated by the Secure Association Protocol: TSKs. 667 In order to protect the EAP conversation, methods supporting key 668 derivation typically negotiate a ciphersuite and derive Transient EAP 669 Keys (TEKs) for use with that ciphersuite. The TEKs are stored 670 locally by the EAP method and are not exported. 672 As noted in [RFC3748] Section 7.10, EAP methods generating keys are 673 required to calculate and export the MSK and EMSK, which must be at 674 least 64 octets in length. EAP methods also may export the IV; 675 however, the use of the IV is deprecated. 677 On both the peer and EAP server, the exported MSK and EMSK are 678 utilized in order to calculate the AAA-Key, as described in Appendix 679 E. 681 Where a backend authentication server is present, the AAA-Key is 682 transported from the backend authentication server to the 683 authenticator within the AAA-Token, using the AAA protocol. 685 Once EAP authentication completes and is successful, the peer and 686 authenticator obtain the AAA-Key and the Secure Association Protocol 687 is run between the peer and authenticator in order to securely 688 negotiate the ciphersuite, derive fresh TSKs used to protect data, 689 and provide mutual proof of possession of the AAA-Key. 691 When the authenticator acts as an endpoint of the EAP conversation 692 rather than a pass-through, EAP methods are implemented on the 693 authenticator as well as the peer. If the EAP method negotiated 694 between the EAP peer and authenticator supports mutual authentication 695 and key derivation, the EAP Master Session Key (MSK) and Extended 696 Master Session Key (EMSK) are derived on the EAP peer and 697 authenticator and exported by the EAP method. In this case, the MSK 698 and EMSK are known only to the peer and authenticator and no other 699 parties. The TEKs and TSKs also reside solely on the peer and 700 authenticator. This is illustrated in Figure 4. As demonstrated in 701 [I-D.ietf-roamops-cert], in this case it is still possible to support 702 roaming between providers, using certificate-based authentication. 704 Where a backend authentication server is utilized, the situation is 705 illustrated in Figure 5. Here the authenticator acts as a pass- 706 through between the EAP peer and a backend authentication server. In 707 this model, the authenticator delegates the access control decision 708 to the backend authentication server, which acts as a Key 709 Distribution Center (KDC). In this case, the authenticator 710 encapsulates EAP packet with a AAA protocol such as RADIUS [RFC3579] 711 or Diameter [I-D.ietf-aaa-eap], and forwards packets to and from the 712 backend authentication server, which acts as the EAP server. Since 713 the authenticator acts as a pass-through, EAP methods reside only on 714 the peer and EAP server As a result, the TEKs, MSK and EMSK are 715 derived on the peer and EAP server. 717 On completion of EAP authentication, EAP methods on the peer and EAP 718 server export the Master Session Key (MSK) and Extended Master 719 Session Key (EMSK). The peer and EAP server then calculate the AAA- 720 Key from the MSK and EMSK, and the backend authentication server 721 sends an Access-Accept to the authenticator, providing the AAA-Key 722 within a protected package known as the AAA-Token. 724 The AAA-Key is then used by the peer and authenticator within the 725 Secure Association Protocol to derive Transient Session Keys (TSKs) 726 required for the negotiated ciphersuite. The TSKs are known only to 727 the peer and authenticator. 729 2.3. Key Lifetimes 731 As noted earlier, the EAP Key Management framework includes several 732 types of keys. Key lifetime issues associated with each type of key 733 are discussed in the sections that follow. Challenges include: 735 [a] Security. Where key lifetimes cannot be assumed, it may be 736 necessary to negotiate them. While key lifetimes may be announced 737 or negotiated in the clear, a protected lifetime negotiation is 738 RECOMMENDED. 740 [b] Resource reclamation. While key lifetimes may be securely 741 negotiated, it is possible for the NAS or peer to reboot or reclaim 742 resources, and therefore not be able to cache keys for their full 743 lifetime. As a result, lifetime negotiation does not guarantee 744 that the key cache will remain synchronized. It is therefore 745 RECOMMENDED for the lower layer to provide a mechanism for key 746 state resynchronization. Note that securing this mechanism may be 747 difficult since in this situation one or more of the parties 748 initially do not possess a key with which to protect the 749 resynchronization exchange. 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 752 | | ^ 753 | EAP Method | | 754 | | | 755 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | | 756 | | | | | | | 757 | | EAP Method Key |<->| Long-Term | | | 758 | | Derivation | | Credential | | | 759 | | | | | | | 760 | | | +-+-+-+-+-+-+-+ | Local to | 761 | | | | EAP | 762 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Method | 763 | | | | | | 764 | | | | | | 765 | | | | | | 766 | | | | | | 767 | V | | | | 768 | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | | 769 | | TEK | | MSK | |EMSK | |IV | | | 770 | |Derivation | |Derivation | |Derivation | |Derivation | | | 771 | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | | 772 | | | | | | 773 | | | | | V 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 775 | | | ^ 776 | | | | 777 | MSK (64B) | EMSK (64B) | IV (64B) | 778 | | | Exported| 779 | | | by | 780 V V V EAP | 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ Method| 782 | AAA Key Derivation, | | Known | | 783 | Naming & Binding | |(Not Secret) | | 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ V 785 | ---+ 786 | Transported | 787 | AAA-Key by AAA | 788 | Protocol | 789 V V 790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 791 | | ^ 792 | TSK | Ciphersuite | 793 | Derivation | Specific | 794 | | V 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 797 Figure 3: EAP Key Hierarchy 799 +-+-+-+-+-+ +-+-+-+-+-+ 800 | | | | 801 | | | | 802 | Cipher- | | Cipher- | 803 | Suite | | Suite | 804 | | | | 805 +-+-+-+-+-+ +-+-+-+-+-+ 806 ^ ^ 807 | | 808 | | 809 | | 810 V V 811 +-+-+-+-+-+ +-+-+-+-+-+ 812 | | | | 813 | |===============| | 814 | |EAP, TEK Deriv.|Authenti-| 815 | |<------------->| cator | 816 | | | | 817 | | Secure Assoc. | | 818 | peer |<------------->| (EAP | 819 | |===============| server) | 820 | | Link layer | | 821 | | (PPP,IEEE802) | | 822 | | | | 823 |MSK,EMSK | |MSK,EMSK | 824 | AAA-Key | | AAA-Key | 825 | (TSKs) | | (TSKs) | 826 | | | | 827 +-+-+-+-+-+ +-+-+-+-+-+ 828 ^ ^ 829 | | 830 | MSK, EMSK | MSK, EMSK 831 | | 832 | | 833 +-+-+-+-+-+ +-+-+-+-+-+ 834 | | | | 835 | EAP | | EAP | 836 | Method | | Method | 837 | | | | 838 | (TEKs) | | (TEKs) | 839 | | | | 840 +-+-+-+-+-+ +-+-+-+-+-+ 842 Figure 4: Relationship between EAP peer and authenticator 843 (acting as an EAP server), where no backend authentication 844 server is present. 846 +-+-+-+-+-+ +-+-+-+-+-+ 847 | | | | 848 | | | | 849 | Cipher- | | Cipher- | 850 | Suite | | Suite | 851 | | | | 852 +-+-+-+-+-+ +-+-+-+-+-+ 853 ^ ^ 854 | | 855 | | 856 | | 857 V V 858 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 859 | |===============| |========| | 860 | |EAP, TEK Deriv.| | | | 861 | |<-------------------------------->| backend | 862 | | | | | | 863 | | Secure Assoc. | | AAA-Key| | 864 | peer |<------------->|Authenti-|<-------| auth | 865 | |===============| cator |========| server | 866 | | Link Layer | | AAA | (EAP | 867 | | (PPP,IEEE 802)| |Protocol| server) | 868 |MSK,EMSK | | | | | 869 | AAA-Key | | AAA-Key | |MSK,EMSK,| 870 | (TSKs) | | (TSKs) | | AAA-Key | 871 | | | | | | 872 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 873 ^ ^ 874 | | 875 | MSK, EMSK | MSK, EMSK 876 | | 877 | | 878 +-+-+-+-+-+ +-+-+-+-+-+ 879 | | | | 880 | EAP | | EAP | 881 | Method | | Method | 882 | | | | 883 | (TEKs) | | (TEKs) | 884 | | | | 885 +-+-+-+-+-+ +-+-+-+-+-+ 887 Figure 5: Pass-through relationship between EAP peer, 888 authenticator and backend authentication server. 890 2.3.1. Local Key Lifetimes 892 The Transient EAP Keys (TEKs) are session keys used to protect the 893 EAP conversation. The TEKs are internal to the EAP method and are 894 not exported. They remain valid only for the duration of the EAP 895 conversation, and are lost once the EAP conversation completes. 897 EAP methods may also implement a cache for other local keying 898 material which may persist for multiple EAP conversations. For 899 example, EAP methods based on TLS (such as EAP-TLS [RFC2716]) derive 900 and cache the TLS Master Secret, typically for substantial time 901 periods. The lifetime of other local keying material calculated 902 within the EAP method is defined by the method. 904 2.3.2. Exported Key Lifetimes 906 All EAP methods generating keys are required to generate the MSK and 907 EMSK, and may optionally generate the IV. However, although new 908 exported keys are generated during re-authentication, the lifetime of 909 exported keys is conceptually distinct from the re-authentication 910 time, since while re-authentication causes new exported keys to be 911 derived, exported keys may be cached on the peer and server after a 912 session completes and therefore their lifetime may be greater than 913 the re-authentication time. 915 Although exported keys are generated by the EAP method, most existing 916 EAP methods do not negotiate the lifetime of the exported keys. EAP, 917 defined in [RFC3748], also does not support the negotiation of 918 lifetimes for exported keying material such as the MSK, EMSK and IV. 920 Several mechanisms exist for managing the lifetime of exported EAP 921 keys. Exported EAP keys may be cached on the EAP server as well as 922 on the peer. On the EAP server, it is RECOMMENDED that the lifetime 923 of exported keys be managed as a system parameter. Where the EAP 924 method does not support the negotiation of the exported key lifetime, 925 and where a negotiation mechanism is not provided by the lower lower, 926 it is RECOMMENDED that the peer assume a default value of the 927 exported key lifetime. A value of 8 hours is suggested. 929 Attempting to manage the lifetime of the EAP-Key SA using AAA 930 attributes is NOT RECOMMENDED, since this requires the authenticator 931 to maintain EAP-Key SA state. As described in Section 3, EAP-Key SA 932 state is typically only maintained on the peer and server, so 933 requiring EAP-Key SA state to be maintained on the authenticator 934 represents an unnecessary additional burden. 936 2.3.3. Calculated Key Lifetimes 938 When keying material exported by EAP methods is replaced, new 939 calculated keys are also put in place. Similarly, when the keying 940 material exported by EAP methods expires, so do the calculated keys. 941 As a result, the lifetime of keys calculated from key material 942 exported by EAP methods can be no larger than the lifetime of the 943 exported keying material. 945 However, since the lifetime of calculated keys can be less than that 946 of the exported keys they are derived from, calculated key lifetimes 947 are conceptually distinct from exported key lifetimes and re- 948 authentication times, and need to be managed as a separate parameter. 950 Note that just as the re-authentication time and the exported key 951 lifetime are conceptually distinct parameters, so too are calculated 952 key lifetimes conceptually distinct from the re-authentication time. 954 AAA protocols such as RADIUS [RFC2865] support the Session-Timeout 955 attribute. As described in [RFC3580], this may be used to determine 956 the maximum session time prior to re-authentication. Since re- 957 authentication results in the derivation of new exported keys and the 958 transport of a new AAA-Key, while a session is in progress the 959 maximum session time prior to re-authentication places an upper bound 960 on the AAA-Key lifetime. 962 However, after the session has terminated, it is possible for the 963 AAA-Key to be cached on the authenticator. Therefore the AAA-Key 964 lifetime may be larger than the re-authentication time. As a result, 965 the AAA-Key lifetime needs to be managed as a separate parameter. 967 Since the lifetime of the AAA-Key within the authenticator key cache 968 is in part determined by authenticator resources, the AAA-Key 969 lifetime is often managed as a system parameter on the authenticator. 970 Since the authenticator may have fewer resources than either the EAP 971 peer or server, it is possible that AAA-Key lifetime on the 972 authenticator may be less than exported key lifetime maintained by 973 the server, or that the authenticator may need to reclaim AAA-Key 974 resources prior to expiration of the AAA-Key lifetime. As a result, 975 knowledge of the AAA-Key lifetime may not be sufficient for the peer 976 to determine whether a particular AAA-Key exists within the key cache 977 of a given authenticator. 979 Issues arise when attempting to manage synchronization of calculated 980 key lifetimes between the AAA server and the authenticator using AAA 981 attributes. 983 Failure to mutually prove possession of the AAA-Key during the Secure 984 Association Protocol exchange need not be grounds for deletion of the 985 AAA-Key by both parties; rate-limiting Secure Association Protocol 986 exchanges could be used to prevent a brute force attack. 988 One problem is that the AAA protocol cannot guarantee synchronization 989 of the peer and authenticator with respect to calculated key 990 lifetimes. While this synchronization could be provided by the 991 Secure Association Protocol, in situations in which this protocol is 992 not run immediately after EAP authentication, the calculated key 993 lifetime will be undefined during the hiatus between the two 994 protocols. This can lead to problems with respect to key cache 995 management. 997 For example, where the AAA-key lifetime is negotiated between the 998 authenticator and the peer within the Secure Association Protocol, 999 this may be used by the peer to manage the lifetime of the AAA-Key 1000 once the Secure Association Protocol has completed. However, where 1001 EAP pre-authentication is used, a hiatus may exist between the 1002 completion of the EAP method and the initiation of the Secure 1003 Association Protocol, during which peer cannot determine the lifetime 1004 of the AAA-Key. 1006 As a result, unless the AAA-Key lifetime is negotiated within the EAP 1007 method or the lower layer, the peer will not be able to determine a 1008 session-specific AAA-Key lifetime until it attempts to negotiate the 1009 Secure Association Protocol, which could fail due to AAA-Key lifetime 1010 expiration. 1012 One solution is to simplify management of the AAA-Key lifetime by 1013 treating it as a system parameter of the peer, authenticator and 1014 server. This enables a wider range of solutions. For example, the 1015 lower layer may utilize Discovery mechanisms to ensure AAA-Key cache 1016 synchronization between the peer and authenticator. 1018 If the authenticator manages the AAA-Key cache by deleting the oldest 1019 AAA-Key first (LIFO), the relative creation time of the last AAA-Key 1020 to be deleted could be advertised with the Discovery phase, enabling 1021 the peer to determine whether a given AAA-Key had been expired from 1022 the authenticator key cache. 1024 2.3.4. TSK Key Lifetimes 1026 Since the TSKs depend on the AAA-Key, replacement of the AAA-Key 1027 typically results in replacement of the TSKs. However, deletion of 1028 the AAA-Key does not necessarily imply deletion of the corresponding 1029 TSKs. Replacement or deletion of TSKs only implies replacement of 1030 the AAA-Key when the TSKs are taken from a portion of the AAA-Key. 1032 While the lifetime of the TSKs may be shorter than or equal to the 1033 AAA-Key lifetime, the TSK lifetime cannot exceed the AAA-Key 1034 lifetime. Where a Secure Association Protocol exists, it is possible 1035 for TSKs to be refreshed prior to re-authentication, and so the TSK 1036 Key Lifetime may also be shorter than or equal to the re- 1037 authentication timeout. It is RECOMMENDED that the TSK Key lifetime 1038 be managed as a parameter distinct from the re-authentication timeout 1039 and the AAA-Key lifetime (except where the TSK is taken from the AAA- 1040 Key). 1042 Where TSKs are established as the result of a Secure Association 1043 Protocol exchange, it is RECOMMENDED that the Secure Association 1044 Protocol include secure negotiation of the TSK lifetime between the 1045 peer and authenticator. Where the TSK is taken from the AAA-Key, 1046 there is no need to manage the TSK lifetime as a separate parameter, 1047 since the TSK lifetime and AAA-Key lifetime are identical. 1049 As described in Section 3, TSKs are part of Service SAs which reside 1050 on the peer and authenticator and as with the AAA-Key lifetime, the 1051 TSK lifetime is often determined by authenticator resources. As a 1052 result, the AAA server has no insight into the TSK derivation 1053 process, and by the principle of ciphersuite independence, it is not 1054 appropriate for the AAA server to manage any aspect of the TSK 1055 derivation process, including the TSK lifetime. 1057 2.4. Key Naming 1059 MSK Name 1061 This key is created between the EAP peer and EAP server, and is 1062 uniquely named by the concatenation of the string "MSK", EAP 1063 Method Type, EAP peer name, EAP server name, EAP peer nonce, and 1064 the EAP server nonce. Here the EAP peer name and EAP server name 1065 are the identifiers securely exchanged within the EAP method. 1066 Since multiple MSKs may exist between an EAP peer and EAP server, 1067 the EAP peer nonce and EAP server nonce allow MSKs to be 1068 differentiated; at least one of these nonces is necessary. The 1069 inclusion of the Method Type in the name ensures that each EAP 1070 method has a distinct name space. 1072 Note that the components of the MSK Name are only known by the EAP 1073 method. As a result, the MSK Name is exported from the method, and 1074 no detailed format of the MSK Name can be specified without a 1075 reference to a particular method. 1077 EMSK Name 1079 The EMSK is named similarly to the above. Its name is the 1080 concatenation of the string "EMSK", the EAP Method Type, EAP peer 1081 name, EAP server name, EAP peer nonce, and the EAP server nonce. 1083 Note that neither the MSK nor EMSK names include the authenticator 1084 identity or the peer or authenticator port over which the EAP 1085 conversation took place. This is because the MSK and EMSK are not 1086 bound to an authenticator, or to specific ports on the peer or 1087 authenticator. 1089 AMSK Name 1091 AMSKs, if any, may be named by the concatenation of the string 1092 "AMSK", key label, application data (see Appendix F), and EMSK 1093 Name. 1095 AAA-Key Name 1097 The AAA-Key is named by the concatenation of the string "AAA-Key", 1098 the authenticator name (since the AAA-Key is bound to a particular 1099 authenticator), and the name of the key from which the AAA-Key is 1100 derived (MSK or AMSK Name). For the purpose of identifying the 1101 authenticator, the contents of the NAS-Identifier attribute is 1102 recommended. In order to ensure that all parties can agree on the 1103 authenticator name this requires the authenticator to advertise 1104 its name (typically using a lower layer mechanism, such as the 1105 802.11 Beacon/Probe Response). 1107 Note that the AAA-Key name does not include the peer or 1108 authenticator port over which the EAP conversation took place. 1109 This is because the AAA-Key is not bound to a specific peer or 1110 authenticator port. 1112 PMK Name 1114 The PMK has no name of its own, and is only identified by the AAA- 1115 Key from which it is derived. 1117 TEKs 1119 The TEKs may or may not be named. Their naming is specified in the 1120 EAP method. 1122 TSKs 1124 The TSKs are typically named. Their naming is specified in the 1125 Secure Association (phase 2) protocol, so that the correct set of 1126 transient session keys can be identified for processing a given 1127 packet. Explicit creation and deletion operations are also 1128 typically supported so that establishment and re-establishment of 1129 transient session keys can be synchronized between the parties. 1131 In order to avoid confusion in the case where an EAP peer has more 1132 than one AAA-Key (phase 1b) applicable to establishment of a phase 1133 2 security association, the secure Association protocol needs to 1134 name the AAA-Key so that the appropriate phase 1b keying material 1135 can be identified for use in the Secure Association Protocol 1136 exchange. 1138 3. Security Associations 1140 During EAP authentication and subsequent exchanges, four types of 1141 security associations (SAs) are created: 1143 [1] EAP method SA. This SA is between the peer and EAP server. It 1144 stores state that can be used for "fast resume" or other 1145 functionality in some EAP methods. Not all EAP methods create such 1146 an SA. 1148 [2] EAP-Key SA. This is an SA between the peer and EAP server, which 1149 is used to store the keying material exported by the EAP method. 1150 Current EAP server implementations do not retain this SA after the 1151 EAP conversation completes, but proposals such as [IEEE-03-084] and 1152 [I-D.irtf-aaaarch-handoff] use this SA for purposes such as pre- 1153 emptive key distribution. 1155 [3] AAA SA(s). These SAs are between the authenticator and the backend 1156 authentication server. They permit the parties to mutually 1157 authenticate each other and protect the communications between 1158 them. 1160 [4] Service SA(s). These SAs are between the peer and authenticator, 1161 and they are created as a result of phases 1-2 of the conversation 1162 (see Section 1.3). 1164 3.1. EAP Method SA (peer - EAP server) 1166 An EAP method may store some state on the peer and EAP server even 1167 after phase 1a has completed. 1169 Typically, this is used for "fast resume": the peer and EAP server 1170 can confirm that they are still talking to the same party, perhaps 1171 using fewer round-trips or less computational power. In this case, 1172 the EAP method SA is essentially a cache for performance 1173 optimization, and either party may remove the SA from its cache at 1174 any point. 1176 An EAP method may also keep state in order to support pseudonym-based 1177 identity protection. This is typically a cache as well (the 1178 information can be recreated if the original EAP method SA is lost), 1179 but may be stored for longer periods of time. 1181 The EAP method SA is not restricted to a particular service or 1182 authenticator and is most useful when the peer accesses many 1183 different authenticators. An EAP method is responsible for 1184 specifying how the parties select if an existing EAP method SA should 1185 be used, and if so, which one. Where multiple backend authentication 1186 servers are used, EAP method SAs are not typically synchronized 1187 between them. 1189 EAP method implementations should consider the appropriate lifetime 1190 for the EAP method SA. "Fast resume" assumes that the information 1191 required (primarily the keys in the EAP method SA) hasn't been 1192 compromised. In case the original authentication was carried out 1193 using, for instance, a smart card, it may be easier to compromise the 1194 EAP method SA (stored on the PC, for instance), so typically the EAP 1195 method SAs have a limited lifetime. 1197 Contents: 1199 o Implicitly, the EAP method this SA refers to 1200 o One or more internal (non-exported) keys 1201 o EAP method SA name 1202 o SA lifetime 1204 3.1.1. Example: EAP-TLS 1206 In EAP-TLS [RFC2716], after the EAP authentication the client (peer) 1207 and server can store the following information: 1209 o Implicitly, the EAP method this SA refers to (EAP-TLS) 1210 o Session identifier (a value selected by the server) 1211 o Certificate of the other party (server stores the client's 1212 certificate and vice versa) 1213 o Ciphersuite and compression method 1214 o TLS Master secret (known as the EAP-TLS Master Key or MK) 1215 o SA lifetime (ensuring that the SA is not stored forever) 1216 o If the client has multiple different credentials (certificates 1217 and corresponding private keys), a pointer to those credentials 1219 When the server initiates EAP-TLS, the client can look up the EAP-TLS 1220 SA based on the credentials it was going to use (certificate and 1221 private key), and the expected credentials (certificate or name) of 1222 the server. If an EAP-TLS SA exists, and it is not too old, the 1223 client informs the server about the existence of this SA by including 1224 its Session-Id in the TLS ClientHello message. The server then looks 1225 up the correct SA based on the Session-Id (or detects that it doesn't 1226 yet have one). 1228 3.1.2. Example: EAP-AKA 1230 In EAP-AKA [I-D.arkko-pppext-eap-aka], after EAP authentication the 1231 client and server can store the following information: 1233 o Implicitly, the EAP method this SA refers to (EAP-AKA) 1234 o A re-authentication pseudonym 1235 o The client's permanent identity (IMSI) 1236 o Replay protection counter 1237 o Authentication key (K_aut) 1238 o Encryption key (K_encr) 1239 o Original Master Key (MK) 1240 o SA lifetime (ensuring that the SA is not stored forever) 1242 When the server initiates EAP-AKA, the client can look up the EAP-AKA 1243 SA based on the credentials it was going to use (permanent identity). 1244 If an EAP-AKA SA exists, and it is not too old, the client informs 1245 the server about the existence of this SA by sending its re- 1246 authentication pseudonym as its identity in EAP Identity Response 1247 message, instead of its permanent identity. The server then looks up 1248 the correct SA based on this identity. 1250 3.2. EAP-Key SA 1252 This is an SA between the peer and EAP server, which is used to store 1253 the keying material exported by the EAP method. Current EAP server 1254 implementations do not retain this SA after the EAP conversation 1255 completes, but future implementations could use this SA for pre- 1256 emptive key distribution. 1258 Contents: 1260 o MSK and EMSK names 1261 o MSK and EMSK 1262 o SA lifetime 1264 3.3. AAA SA(s) (authenticator - backend authentication server) 1266 In order for the authenticator and backend authentication server to 1267 authenticate each other, they need to store some information. 1269 In case the authenticator and backend authentication server are 1270 colocated, and they communicate using local procedure calls or shared 1271 memory, this SA need not necessarily contain any information. 1273 3.3.1. Example: RADIUS 1275 In RADIUS, where shared secret authentication is used, the client and 1276 server store each other's IP address and the shared secret, which is 1277 used to calculate the Response Authenticator [RFC2865] and Message- 1278 Authenticator [RFC3579] values, and to encrypt some attributes (such 1279 as the AAA-Key [RFC2548]). 1281 Where IPsec is used to protect RADIUS [RFC3579] and IKE is used for 1282 key management, the parties store information necessary to 1283 authenticate and authorize the other party (e.g. certificates, trust 1284 anchors and names). The IKE exchange results in IKE Phase 1 and Phase 1285 2 SAs containing information used to protect the conversation 1286 (session keys, selected ciphersuite, etc.) 1288 3.3.2. Example: Diameter with TLS 1290 When using Diameter protected by TLS, the parties store information 1291 necessary to authenticate and authorize the other party (e.g. 1292 certificates, trust anchors and names). The TLS handshake results in 1293 a short-term TLS SA that contains information used to protect the 1294 actual communications (session keys, selected TLS ciphersuite, etc.). 1296 3.4. Service SA(s) (peer - authenticator) 1298 The service SAs store information about the service being provided. 1299 These include the Root service SA and derived unicast and multicast 1300 service SAs. 1302 The Root service SA is established as the result of the completion of 1303 EAP authentication (phase 1a) and AAA-Key derivation or transport 1304 (phase 1b). It includes: 1306 o Service parameters (or at least those parameters 1307 that are still needed) 1308 o On the authenticator, service authorization 1309 information received from the backend authentication 1310 server (or necessary parts of it) 1311 o On the peer, usually locally configured service 1312 authorization information. 1313 o The AAA-Key, if it can be needed again (to refresh 1314 and/or resynchronize other keys or for another reason) 1315 o AAA-Key lifetime 1317 Unicast and (optionally) multicast service SAs are derived from the 1318 Root service SA, via the Secure Association Protocol. In order for 1319 unicast and multicast service SAs and associated TSKs to be 1320 established, it is not necessary for EAP authentication (phase 1a) to 1321 be rerun each time. Instead, the Secure Association Protocol can be 1322 used to mutually prove possession of the AAA-Key and create 1323 associated unicast (phase 2a) and multicast (phase 2b) service SAs 1324 and TSKs, enabling the EAP exchange to be bypassed. Unicast and 1325 multicast service SAs include: 1327 o Service parameters negotiated by the Secure Association Protocol. 1328 o Endpoint identifiers. 1329 o Transient Session Keys used to protect the communication. 1330 o Transient Session Key lifetime. 1332 One function of the Secure Association Protocol is to bind the the 1333 unicast and multicast service SAs and TSKs to endpoint identifiers. 1334 For example, within [IEEE802.11i], the 4-way handshake binds the TSKs 1335 to the MAC addresses of the endpoints; in IKE [RFC2409], the TSKs are 1336 bound to the IP addresses of the endpoints and the negotiated SPI. 1338 It is possible for more than one unicast or multicast service SA to 1339 be derived from a single Root service SA. However, a unicast or 1340 multicast service SA is always descended from only one Root service 1341 SA. Unicast or multicast service SAs descended from the same Root 1342 service SA may utilize the same security parameters (e.g. mode, 1343 ciphersuite, etc.) or they may utilize different parameters. 1345 An EAP peer may be able to negotiate multiple service SAs with a 1346 given authenticator, or may be able to maintain one or more service 1347 SAs with multiple authenticators, depending on the properties of the 1348 media. 1350 Except where explicitly specified by the Secure Association Protocol, 1351 it should not be assumed that the installation of new service SAs 1352 implies deletion of old service SAs. It is possible for multicast 1353 Root service SAs to between the same EAP peer and authenticator; 1354 during a re-key of a unicast or multicast service SA it is possible 1355 for two service SAs to exist during the period between when the new 1356 service SA and corresponding TSKs are calculated and when they are 1357 installed. 1359 Similarly, deletion or creation of a unicast or multicast service SA 1360 does not necessarily imply deletion or creation of related unicast or 1361 multicast service SAs, unless specified by the Secure Association 1362 protocol. For example, a unicast service SA may be rekeyed without 1363 implying a rekey of the multicast service SA. 1365 The deletion of the Root service SA does not necessarily imply the 1366 deletion of the derived unicast and multicast service SAs and 1367 associated TSKs. Failure to mutually prove possession of the AAA-Key 1368 during the Secure Association Protocol exchange need not be grounds 1369 for deletion of the AAA-Key by both parties; the action to be taken 1370 is defined by the Secure Association Protocol. 1372 3.4.1. Example: 802.11i 1374 [IEEE802.11i] Section 8.4.1.1 defines the security associations used 1375 within IEEE 802.11. A summary follows; the standard should be 1376 consulted for details. 1378 o Pairwise Master Key Security Association (PMKSA) 1380 The PMKSA is a bi-directional SA, used by both parties for sending 1381 and receiving. It is created on the peer when EAP authentication 1382 completes successfully or a pre-shared key is configured. The 1383 PMKSA is created on the authenticator when the PMK is received or 1384 created on the authenticator or a pre-shared key is configured. 1385 The PMKSA is used to create the PTKSA. PMKSAs are cached for 1386 their lifetimes. The PMKSA consists of the following elements: 1388 - PMKID (security association identifier) 1389 - Authenticator MAC address 1390 - PMK 1391 - Lifetime 1392 - Authenticated Key Management Protocol (AKMP) 1393 - Authorization parameters specified by the AAA server or 1394 by local configuration. This can include 1395 parameters such as the peer's authorized SSID. 1396 On the peer, this information can be locally 1397 configured. 1398 - Key replay counters (for EAPOL-Key messages) 1399 - Reference to PTKSA (if any), needed to: 1400 o delete it (e.g. AAA server-initiated disconnect) 1401 o replace it when a new four-way handshake is done 1402 - Reference to accounting context, the details of which depend 1403 on the accounting protocol used, the implementation 1404 and administrative details. In RADIUS, this could include 1405 (e.g. packet and octet counters, and Acct-Multi-Session-Id). 1407 o Pairwise Transient Key Security Association (PTKSA) 1409 The PTKSA is a bi-directional SA created as the result of a 1410 successful four-way handshake. There may only be one PTKSA 1411 between a pair of peer and authenticator MAC addresses. PTKSAs 1412 are cached for the lifetime of the PMKSA. Since the PTKSA is tied 1413 to the PMKSA, it only has the additional information from the 1414 4-way handshake. The PTKSA consists of the following: 1416 - Key (PTK) 1417 - Selected ciphersuite 1418 - MAC addresses of the parties 1419 - Replay counters, and ciphersuite specific state 1420 - Reference to PMKSA: This is needed when: 1421 o A new four-way handshake is needed (lifetime, TKIP 1422 countermeasures), and we need to know which PMKSA to use 1424 o Group Transient Key Security Association (GTKSA) 1426 The GTKSA is a uni-directional SA created based on the four-way 1427 handshake or the group key handshake. A GTKSA consists of the 1428 following: 1430 - Direction vector (whether the GTK is used for transmit or receive) 1431 - Group cipher suite selector 1432 - Key (GTK) 1433 - Authenticator MAC address 1434 - Via reference to PMKSA, or copied here: 1435 o Authorization parameters 1436 o Reference to accounting context 1438 3.4.2. Example: IKEv2/IPsec 1440 Note that this example is intended to be informative, and it does not 1441 necessarily include all information stored. 1443 o IKEv2 SA 1445 - Protocol version 1446 - Identities of the parties 1447 - IKEv2 SPIs 1448 - Selected ciphersuite 1449 - Replay protection counters (Message ID) 1450 - Keys for protecting IKEv2 messages (SK_ai/SK_ar/SK_ei/SK_er) 1451 - Key for deriving keys for IPsec SAs (SK_d) 1452 - Lifetime information 1453 - On the authenticator, service authorization information 1454 received from the backend authentication server. 1456 When processing an incoming message, the correct SA is looked up based 1457 on the SPIs. 1459 o IPsec SAs/SPD 1461 - Traffic selectors 1462 - Replay protection counters 1463 - Selected ciphersuite 1464 - IPsec SPI 1465 - Keys 1466 - Lifetime information 1467 - Protocol mode (tunnel or transport) 1469 The correct SA is looked up based on SPI (for inbound packets), or 1470 SPD traffic selectors (for outbound traffic). A separate IPsec SA 1471 exists for each direction. 1473 3.4.3. Sharing service SAs 1475 A single service may be provided by multiple logical or physical 1476 service elements. Each service is responsible for specifying how 1477 changing service elements is handled. Some approaches include: 1479 Transparent sharing 1480 If the service parameters visible to the other party (either peer 1481 or authenticator) do not change, the service can be moved without 1482 requiring cooperation from the other party. 1484 Whether such a move should be supported or used depends on 1485 implementation and administrative considerations. For instance, an 1486 administrator may decide to configure a group of IKEv2/IPsec 1487 gateways in a cluster for high-availability purposes, if the 1488 implementation used supports this. The peer does not necessarily 1489 have any way of knowing when the change occurs. 1491 No sharing 1492 If the service parameters require changing, some changes may 1493 require terminating the old service, and starting a new 1494 conversation from phase 0. This approach is used by all services 1495 for at least some parameters, and it doesn't require any protocol 1496 for transferring the service SA between the service elements. 1498 The service may support keeping the old service element active 1499 while the new conversation takes phase, to decrease the time the 1500 service is not available. 1502 Some sharing 1503 The service may allow changing some parameters by simply agreeing 1504 about the new values. This may involve a similar exchange as in 1505 phase 2, or perhaps a shorter conversation. 1507 This option usually requires some protocol for transferring the 1508 service SA between the elements. An administrator may decide not to 1509 enable this feature at all, and typically the sharing is restricted 1510 to some particular service elements (defined either by a service 1511 parameter, or simple administrative decision). If the old and new 1512 service element do not support such "context transfer", this 1513 approach falls back to the previous option (no transfer). 1515 Services supporting this feature should also consider what changes 1516 require new authorization from the backend authentication server 1517 (see Section 4.2). 1519 Note that these considerations are not limited to service 1520 parameters related to the authenticator--they apply to peer's 1521 parameters as well. 1523 4. Handoff Support 1525 Within EAP, a number of mechanisms may be utilized in order to reduce 1526 the latency of handoff between authenticators. One such mechanism is 1527 EAP pre-authentication, in which EAP is utilized to pre-establish a 1528 AAA-Key on an authenticator prior to arrival of the peer. 1530 "Fast Handoff" is defined as a conversation in which EAP exchange 1531 (phase 1a) and associated AAA pass-through is bypassed, so as to 1532 reduce latency. Unlike EAP pre-authentication, "Fast Handoff" 1533 mechanisms do not result in additional AAA server load. Fast handoff 1534 mechanisms include: 1536 [a] Pre-emptive handoff. In this technique, the AAA server pre- 1537 establishes key state on the authenticator prior to arrival of the 1538 peer, without completion of EAP authentication. As described in 1539 [IEEE-03-084] and [I.D.irtf-aaaarch-handoff], this technique 1540 includes conventional AAA-Key transport, but without an EAP 1541 authentication. 1543 [b] Context transfer. In this technique, the old authenticator 1544 transfers the session text to the new authenticator, either prior 1545 to, or after the arrival of the peer. As a result, AAA-Key 1546 transport (phase 1b) is bypassed. 1548 Regardless of how the AAA-Key is provisioned on a given 1549 authenticator, AAA-Key caching may be utilized in order to enable a 1550 peer to quickly re-establish a session with an authenticator. 1552 Where key caching is supported, once the AAA-Key is derived and/or 1553 transported to the authenticator, it may remain cached on the peer 1554 and authenticator, even after a subsequent session terminates. To 1555 initiate a subsequent session with the same authenticator, the peer 1556 may utilize the Secure Association Protocol to confirm mutual 1557 possession of the AAA-Key by the peer and authenticator, thereby re- 1558 activating the AAA-Key for use in a subsequent session. 1560 The introduction of handoff support introduces new security 1561 vulnerabilities as well as requirements for the secure handling of 1562 authorization context. These issues are discussed in the sections 1563 that follow. 1565 4.1. Key Scope Issues 1567 As described in Appendix E, the AAA-Key is calculated from the EMSK 1568 and MSK by the EAP peer and server, and is used as the root of the 1569 ciphersuite-specific key hierarchy. Where a backend authentication 1570 server is present, the AAA-Key is transported from the EAP server to 1571 the authenticator; where it is not present, the AAA-Key is calculated 1572 on the authenticator. 1574 Regardless of how many sessions are initiated using it, the AAA-Key 1575 is restricted to use between the EAP peer that calculates it, and the 1576 authenticator that either calculates it (where no backend 1577 authenticator is present) or receives it from the server (where a 1578 backend authenticator server is present). In the process of defining 1579 the scope of the AAA-Key, it should be understood that an 1580 authenticator or peer: 1582 [a] may contain multiple physical ports; 1584 [b] may advertise itself as multiple "virtual" authenticators or peers; 1586 [c] may utilize multiple CPUs; 1588 [d] may support clustering services for load balancing or failover. 1590 As illustrated in Figure 1, an EAP peer with multiple ports may be 1591 attached to one or more authenticators, each with multiple ports. 1592 Where the peer and authenticator identify themselves using a port 1593 identifier such as a link layer address, it may not be obvious to the 1594 peer which authenticator ports are associated with which 1595 authenticators. Similarly, it may not be obvious to the 1596 authenticator which peer ports are associated with which peers. As a 1597 result, the peer and authenticator may not be able to determine the 1598 scope of the AAA-Key. 1600 When a single physical authenticator advertises itself as multiple 1601 "virtual authenticators", the EAP peer and authenticator also may not 1602 be able to agree on the scope of the AAA-Key, creating a security 1603 vulnerability. For example, the peer may assume that the "virtual 1604 authenticators" are distinct and do not share a key cache, whereas, 1605 depending on the architecture of the physical AP, a shared key cache 1606 may or may not be implemented. 1608 Where the AAA-Key is shared between "virtual authenticators" an 1609 attacker acting as a peer could authenticate with the "Guest" 1610 "virtual authenticator" and derive a AAA-Key. If the virtual 1611 authenticators share a key cache, then the peer can utilize the AAA- 1612 Key derived for the "Guest" network to obtain access to the 1613 "Corporate Intranet" virtual authenticator. 1615 Several measures are recommended to address these issues: peers and 1616 authenticators may have multiple ports. 1618 [a] Authenticators are REQUIRED to cache associated authorizations 1619 along with the AAA-Key and apply authorizations consistently. This 1620 ensures that an attacker cannot obtain elevated privileges even 1621 where the AAA-Key cache is shared between "virtual authenticators". 1623 [b] It is RECOMMENDED that physical authenticators maintain separate 1624 AAA-Key caches for each "virtual authenticator". 1626 [c] It is RECOMMENDED that each "virtual authenticator" identify itself 1627 distinctly to the AAA server, such as by utilizing a distinct NAS- 1628 identifier attribute. This enables the AAA server to utilize a 1629 separate credential to authenticate each "virtual authenticator". 1631 [d] It is RECOMMENDED that Secure Association Protocols identify peers 1632 and authenticators unambiguously, without incorporating implicit 1633 assumptions about peer and authenticator architectures. Using 1634 port-specific MAC addresses as identifiers is NOT RECOMMENDED where 1635 peers and authenticators may support multiple ports. 1637 [e] The AAA server and authenticator MAY implement additional 1638 attributes in order to further restrict the AAA-Key scope. For 1639 example, in 802.11, the AAA server may provide the authenticator 1640 with a list of authorized Called or Calling-Station-Ids and/or 1641 SSIDs for which the AAA-Key is valid. 1643 [f] Where the AAA server provides attributes restricting the key scope, 1644 it is RECOMMENDED that restrictions be securely communicated by the 1645 authenticator to the peer. This is typically accomplished using 1646 the Secure Association Protocol, but also can be accomplished via 1647 the EAP method or the lower layer. 1649 4.2. Authorization Issues 1651 In a typical network access scenario (dial-in, wireless LAN, etc.) 1652 access control mechanisms are typically applied. These mechanisms 1653 include user authentication as well as authorization for the offered 1654 service. 1656 As a part of the authentication process, the AAA network determines 1657 the user's authorization profile. The user authorizations are 1658 transmitted by the backend authentication server to the EAP 1659 authenticator (also known as the Network Access Server or 1660 authenticator) included with the AAA-Token, which also contains the 1661 AAA-Key, in Phase 1b of the EAP conversation. Typically, the profile 1662 is determined based on the user identity, but a certificate presented 1663 by the user may also provide authorization information. 1665 The backend authentication server is responsible for making a user 1666 authorization decision, answering the following questions: 1668 [a] Is this a legitimate user for this particular network? 1670 [b] Is this user allowed the type of access he or she is requesting? 1672 [c] Are there any specific parameters (mandatory tunneling, bandwidth, 1673 filters, and so on) that the access network should be aware of for 1674 this user? 1676 [d] Is this user within the subscription rules regarding time of day? 1678 [e] Is this user within his limits for concurrent sessions? 1680 [f] Are there any fraud, credit limit, or other concerns that indicate 1681 that access should be denied? 1683 While the authorization decision is in principle simple, the process 1684 is complicated by the distributed nature of AAA decision making. 1685 Where brokering entities or proxies are involved, all of the AAA 1686 devices in the chain from the authenticator to the home AAA server 1687 are involved in the decision. For instance, a broker can disallow 1688 access even if the home AAA server would allow it, or a proxy can add 1689 authorizations (e.g., bandwidth limits). 1691 Decisions can be based on static policy definitions and profiles as 1692 well as dynamic state (e.g. time of day or limits on the number of 1693 concurrent sessions). In addition to the Accept/Reject decision made 1694 by the AAA chain, parameters or constraints can be communicated to 1695 the authenticator. 1697 The criteria for Accept/Reject decisions or the reasons for choosing 1698 particular authorizations are typically not communicated to the 1699 authenticator, only the final result. As a result, the authenticator 1700 has no way to know what the decision was based on. Was a set of 1701 authorization parameters sent because this service is always provided 1702 to the user, or was the decision based on the time/day and the 1703 capabilities of the requesting authenticator device? 1705 4.3. Correctness Issues 1707 Bypassing all or portions of the AAA conversation creates challenges 1708 in ensuring that authorization is properly handled. These include: 1710 [a] Consistent application of session time limits. A fast handoff 1711 should not automatically increase the available session time, 1712 allowing a user to endlessly extend their network access by 1713 changing the point of attachment. 1715 [b] Avoidance of privilege elevation. A fast handoff should not result 1716 in a user being granted access to services which they are not 1717 entitled to. 1719 [c] Consideration of dynamic state. In situations in which dynamic 1720 state is involved in the access decision (day/time, simultaneous 1721 session limit) it should be possible to take this state into 1722 account either before or after access is granted. Note that 1723 consideration of network-wide state such as simultaneous session 1724 limits can typically only be taken into account by the backend 1725 authentication server. 1727 [d] Encoding of restrictions. Since a authenticator may not be aware 1728 of the criteria considered by a backend authentication server when 1729 allowing access, in order to ensure consistent authorization during 1730 a fast handoff it may be necessary to explicitly encode the 1731 restrictions within the authorizations provided in the AAA-Token. 1733 [e] State validity. The introduction of fast handoff should not render 1734 the authentication server incapable of keeping track of network- 1735 wide state. 1737 A fast handoff mechanism capable of addressing these concerns is said 1738 to be "correct". One condition for correctness is as follows: For a 1739 fast handoff to be "correct" it MUST establish on the new device the 1740 same context as would have been created had the new device completed 1741 a AAA conversation with the authentication server. 1743 A properly designed fast handoff scheme will only succeed if it is 1744 "correct" in this way. If a successful fast handoff would establish 1745 "incorrect" state, it is preferable for it to fail, in order to avoid 1746 creation of incorrect context. 1748 Some backend authentication server and authenticator configurations 1749 are incapable of meeting this definition of "correctness". For 1750 example, if the old and new device differ in their capabilities, it 1751 may be difficult to meet this definition of correctness in a fast 1752 handoff mechanism that bypasses AAA. Backend authentication servers 1753 often perform conditional evaluation, in which the authorizations 1754 returned in an Access-Accept message are contingent on the 1755 authenticator or on dynamic state such as the time of day or number 1756 of simultaneous sessions. For example, in a heterogeneous 1757 deployment, the backend authentication server might return different 1758 authorizations depending on the authenticator making the request, in 1759 order to make sure that the requested service is consistent with the 1760 authenticator capabilities. 1762 If differences between the new and old device would result in the 1763 backend authentication server sending a different set of messages to 1764 the new device than were sent to the old device, then if the fast 1765 handoff mechanism bypasses AAA, then the fast handoff cannot be 1766 carried out correctly. 1768 For example, if some authenticator devices within a deployment 1769 support dynamic VLANs while others do not, then attributes present in 1770 the Access-Request (such as the authenticator-IP-Address, 1771 authenticator-Identifier, Vendor-Identifier, etc.) could be examined 1772 to determine when VLAN attributes will be returned, as described in 1773 [RFC3580]. VLAN support is defined in [IEEE8021Q]. If a fast 1774 handoff bypassing the backend authentication server were to occur 1775 between a authenticator supporting dynamic VLANs and another 1776 authenticator which does not, then a guest user with access 1777 restricted to a guest VLAN could be given unrestricted access to the 1778 network. 1780 Similarly, in a network where access is restricted based on the day 1781 and time, Service Set Identifier (SSID), Calling-Station-Id or other 1782 factors, unless the restrictions are encoded within the 1783 authorizations, or a partial AAA conversation is included, then a 1784 fast handoff could result in the user bypassing the restrictions. 1786 In practice, these considerations limit the situations in which fast 1787 handoff mechanisms bypassing AAA can be expected to be successful. 1788 Where the deployed devices implement the same set of services, it may 1789 be possible to do successful fast handoffs within such mechanisms. 1790 However, where the supported services differ between devices, the 1791 fast handoff may not succeed. For example, [RFC2865] section 1.1 1792 states: 1794 "A authenticator that does not implement a given service MUST NOT 1795 implement the RADIUS attributes for that service. For example, a 1796 authenticator that is unable to offer ARAP service MUST NOT 1797 implement the RADIUS attributes for ARAP. A authenticator MUST 1798 treat a RADIUS access-accept authorizing an unavailable service as 1799 an access-reject instead." 1801 Note that this behavior only applies to attributes that are known, 1802 but not implemented. For attributes that are unknown, [RFC2865] 1803 Section 5 states: 1805 "A RADIUS server MAY ignore Attributes with an unknown Type. A 1806 RADIUS client MAY ignore Attributes with an unknown Type." 1808 In order to perform a correct fast handoff, if a new device is 1809 provided with RADIUS context for a known but unavailable service, 1810 then it MUST process this context the same way it would handle a 1811 RADIUS Access-Accept requesting an unavailable service. This MUST 1812 cause the fast handoff to fail. However, if a new device is provided 1813 with RADIUS context that indicates an unknown attribute, then this 1814 attribute MAY be ignored. 1816 Although it may seem somewhat counter-intuitive, failure is indeed 1817 the "correct" result where a known but unsupported service is 1818 requested. Presumably a correctly configured backend authentication 1819 server would not request that a device carry out a service that it 1820 does not implement. This implies that if the new device were to 1821 complete a AAA conversation that it would be likely to receive 1822 different service instructions. In such a case, failure of the fast 1823 handoff is the desired result. This will cause the new device to go 1824 back to the AAA server in order to receive the appropriate service 1825 definition. 1827 In practice, this implies that fast handoff mechanisms which bypass 1828 AAA are most likely to be successful within a homogeneous device 1829 deployment within a single administrative domain. For example, it 1830 would not be advisable to carry out a fast handoff bypassing AAA 1831 between a authenticator providing confidentiality and another 1832 authenticator that does not support this service. The correct result 1833 of such a fast handoff would be a failure, since if the handoff were 1834 blindly carried out, then the user would be moved from a secure to an 1835 insecure channel without permission from the backend authentication 1836 server. Thus the definition of a "known but unsupported service" 1837 MUST encompass requests for unavailable security services. This 1838 includes vendor-specific attributes related to security, such as 1839 those described in [RFC2548]. 1841 5. Security Considerations 1843 5.1. Security Terminology 1845 Cryptographic binding 1846 The demonstration of the EAP peer to the EAP server that a single 1847 entity has acted as the EAP peer for all methods executed within a 1848 tunnel method. Binding MAY also imply that the EAP server 1849 demonstrates to the peer that a single entity has acted as the EAP 1850 server for all methods executed within a tunnel method. If 1851 executed correctly, binding serves to mitigate man-in-the-middle 1852 vulnerabilities. 1854 Cryptographic separation 1855 Two keys (x and y) are "cryptographically separate" if an adversary 1856 that knows all messages exchanged in the protocol cannot compute x 1857 from y or y from x without "breaking" some cryptographic 1858 assumption. In particular, this definition allows that the 1859 adversary has the knowledge of all nonces sent in cleartext as well 1860 as all predictable counter values used in the protocol. Breaking a 1861 cryptographic assumption would typically require inverting a one- 1862 way function or predicting the outcome of a cryptographic pseudo- 1863 random number generator without knowledge of the secret state. In 1864 other words, if the keys are cryptographically separate, there is 1865 no shortcut to compute x from y or y from x, but the work an 1866 adversary must do to perform this computation is equivalent to 1867 performing exhaustive search for the secret state value. 1869 Key strength 1870 If the effective key strength is N bits, the best currently known 1871 methods to recover the key (with non-negligible probability) 1872 require on average an effort comparable to 2^(N-1) operations of a 1873 typical block cipher. 1875 Mutual authentication 1876 This refers to an EAP method in which, within an interlocked 1877 exchange, the authenticator authenticates the peer and the peer 1878 authenticates the authenticator. Two independent one-way methods, 1879 running in opposite directions do not provide mutual authentication 1880 as defined here. 1882 5.2. Threat Model 1884 The EAP threat model is described in [RFC3748] Section 7.1. In order 1885 to address these threats, EAP relies on the security properties of 1886 EAP methods (known as "security claims", described in [RFC3784] 1887 Section 7.2.1). EAP method requirements for application such as 1888 Wireless LAN authentication are described in [WLANREQ]. 1890 The RADIUS threat model is described in [RFC3579] Section 4.1, and 1891 responses to these threats are described in [RFC3579] Sections 4.2 1892 and 4.3. Among other things, [RFC3579] Section 4.2 recommends the 1893 use of IPsec ESP with non-null transform to provide per-packet 1894 authentication and confidentiality, integrity and replay protection 1895 for RADIUS/EAP. 1897 Given the existing documentation of EAP and AAA threat models and 1898 responses, there is no need to duplicate that material here. 1899 However, there are many other system-level threats no covered in 1900 these document which have not been described or analyzed elsewhere. 1901 These include: 1903 [1] An attacker may try to modify or spoof Secure Association Protocol 1904 packets. 1906 [2] An attacker compromising an authenticator may provide incorrect 1907 information to the EAP peer and/or server via out-of-band 1908 mechanisms (such as via a AAA or lower layer protocol). This 1909 includes impersonating another authenticator, or providing 1910 inconsistent information to the peer and EAP server. 1912 [3] An attacker may attempt to perform downgrading attacks on the 1913 ciphersuite negotiation within the Secure Association Protocol in 1914 order to ensure that a weaker ciphersuite is used to protect data. 1916 Depending on the lower layer, these attacks may be carried out 1917 without requiring physical proximity. 1919 In order to address these threats, [Housley56] describes the 1920 mandatory system security properties: 1922 Algorithm independence 1923 Wherever cryptographic algorithms are chosen, the algorithms must 1924 be negotiable, in order to provide resilient against compromise of 1925 a particular algorithm. Algorithm independence must be 1926 demonstrated within all aspects of the system, including within 1927 EAP, AAA and the Secure Association Protocol. However, for 1928 interoperability, at least one suite of algorithms MUST be 1929 implemented. 1931 Strong, fresh session keys 1932 Session keys must be demonstrated to be strong and fresh in all 1933 circumstances, while at the same time retaining algorithm 1934 independence. 1936 Replay protection 1937 All protocol exchanges must be replay protected. This includes 1938 exchanges within EAP, AAA, and the Secure Association Protocol. 1940 Authentication 1941 All parties need to be authenticated. The confidentiality of the 1942 authenticator must be maintained. No plaintext passwords are 1943 allowed. 1945 Authorization 1946 EAP peer and authenticator authorization must be performed. 1948 Session keys 1949 Confidentiality of session keys must be maintained. 1951 Ciphersuite negotiation 1952 The selection of the "best" ciphersuite must be securely confirmed. 1954 Unique naming 1955 Session keys must be uniquely named. 1957 Domino effect 1958 Compromise of a single authenticator cannot compromise any other 1959 part of the system, including session keys and long-term secrets. 1961 Key binding 1962 The key must be bound to the appropriate context. 1964 5.3. Security Analysis 1966 Figure 6 illustrates the relationship between the peer, authenticator 1967 and backend authentication server. 1969 EAP peer 1970 /\ 1971 / \ 1972 Protocol: EAP / \ Protocol: Secure Association 1973 Auth: Mutual / \ Auth: Mutual 1974 Unique keys: / \ Unique keys: TSKs 1975 TEKs,EMSK / \ 1976 / \ 1977 EAP server +--------------+ Authenticator 1978 Protocol: AAA 1979 Auth: Mutual 1980 Unique key: AAA session key 1982 Figure 6: Relationship between peer, authenticator and auth. server 1984 The peer and EAP server communicate using EAP [RFC3748]. The 1985 security properties of this communication are largely determined by 1986 the chosen EAP method. Method security claims are described in 1987 [RFC3748] Section 7.2. These include the key strength, protected 1988 ciphersuite negotiation, mutual authentication, integrity protection, 1989 replay protection, confidentiality, key derivation, key strength, 1990 dictionary attack resistance, fast reconnect, cryptographic binding, 1991 session independence, fragmentation and channel binding claims. At a 1992 minimum, methods claiming to support key derivation must also support 1993 mutual authentication. As noted in [RFC3748] Section 7.10: 1995 EAP Methods deriving keys MUST provide for mutual authentication 1996 between the EAP peer and the EAP Server. 1998 Ciphersuite independence is also required: 2000 Keying material exported by EAP methods MUST be independent of the 2001 ciphersuite negotiated to protect data. 2003 In terms of key strength and freshness, [RFC3748] Section 10 says: 2005 EAP methods SHOULD ensure the freshness of the MSK and EMSK even 2006 in cases where one party may not have a high quality random number 2007 generator.... In order to preserve algorithm independence, EAP 2008 methods deriving keys SHOULD support (and document) the protected 2009 negotiation of the ciphersuite used to protect the EAP 2010 conversation between the peer and server... In order to enable 2011 deployments requiring strong keys, EAP methods supporting key 2012 derivation SHOULD be capable of generating an MSK and EMSK, each 2013 with an effective key strength of at least 128 bits. 2015 The authenticator and backend authentication server communicate using 2016 a AAA protocol such as RADIUS [RFC3579] or Diameter [I-D.ietf-aaa- 2017 eap]. As noted in [RFC3588] Section 13, Diameter must be protected 2018 by either IPsec ESP with non-null transform or TLS. As a result, 2019 Diameter requires per-packet integrity and confidentiality. Replay 2020 protection must be supported. For RADIUS, [RFC3579] Section 4.2 2021 recommends that RADIUS be protected by IPsec ESP with a non-null 2022 transform, and where IPsec is implemented replay protection must be 2023 supported. 2025 The peer and authenticator communicate using the Secure Association 2026 Protocol. 2028 As noted in the figure, each party in the exchange mutually 2029 authenticates with each of the other parties, and derives a unique 2030 key. All parties in the diagram have access to the AAA-Key. 2032 The EAP peer and backend authentication server mutually authenticate 2033 via the EAP method, and derive the TEKs and EMSK which are known only 2034 to them. The TEKs are used to protect some or all of the EAP 2035 conversation between the peer and authenticator, so as to guard 2036 against modification or insertion of EAP packets by an attacker. The 2037 degree of protection afforded by the TEKs is determined by the EAP 2038 method; some methods may protect the entire EAP packet, including the 2039 EAP header, while other methods may only protect the contents of the 2040 Type-Data field, defined in [RFC3748]. 2042 Since EAP is spoken only between the EAP peer and server, if a 2043 backend authentication server is present then the EAP conversation 2044 does not provide mutual authentication between the peer and 2045 authenticator, only between the EAP peer and EAP server (backend 2046 authentication server). As a result, mutual authentication between 2047 the peer and authenticator only occurs where a Secure Association 2048 protocol is used, such the unicast and group key derivation handshake 2049 supported in [IEEE80211i]. This means that absent use of a secure 2050 Association Protocol, from the point of view of the peer, EAP mutual 2051 authentication only proves that the authenticator is trusted by the 2052 backend authentication server; the identity of the authenticator is 2053 not confirmed. 2055 Utilizing the AAA protocol, the authenticator and backend 2056 authentication server mutually authenticate and derive session keys 2057 known only to them, used to provide per-packet integrity and replay 2058 protection, authentication and confidentiality. The AAA-Key is 2059 distributed by the backend authentication server to the authenticator 2060 over this channel, bound to attributes constraining its usage, as 2061 part of the AAA-Token. The binding of attributes to the AAA-Key 2062 within a protected package is important so the authenticator 2063 receiving the AAA-Token can determine that it has not been 2064 compromised, and that the keying material has not been replayed, or 2065 mis-directed in some way. 2067 The security properties of the EAP exchange are dependent on each leg 2068 of the triangle: the selected EAP method, AAA protocol and the Secure 2069 Association Protocol. 2071 Assuming that the AAA protocol provides protection against rogue 2072 authenticators forging their identity, then the AAA-Token can be 2073 assumed to be sent to the correct authenticator, and where it is 2074 wrapped appropriately, it can be assumed to be immune to compromise 2075 by a snooping attacker. 2077 Where an untrusted AAA intermediary is present, the AAA-Token must 2078 not be provided to the intermediary so as to avoid compromise of the 2079 AAA-Token. This can be avoided by use of re-direct as defined in 2080 [RFC3588]. 2082 When EAP is used for authentication on PPP or wired IEEE 802 2083 networks, it is typically assumed that the link is physically secure, 2084 so that an attacker cannot gain access to the link, or insert a rogue 2085 device. EAP methods defined in [RFC3748] reflect this usage model. 2086 These include EAP MD5, as well as One-Time Password (OTP) and Generic 2087 Token Card. These methods support one-way authentication (from EAP 2088 peer to authenticator) but not mutual authentication or key 2089 derivation. As a result, these methods do not bind the initial 2090 authentication and subsequent data traffic, even when the the 2091 ciphersuite used to protect data supports per-packet authentication 2092 and integrity protection. As a result, EAP methods not supporting 2093 mutual authentication are vulnerable to session hijacking as well as 2094 attacks by rogue devices. 2096 On wireless networks such as IEEE 802.11 [IEEE80211], these attacks 2097 become easy to mount, since any attacker within range can access the 2098 wireless medium, or act as an access point. As a result, new 2099 ciphersuites have been proposed for use with wireless LANs 2100 [IEEE80211i] which provide per-packet authentication, integrity and 2101 replay protection. In addition, mutual authentication and key 2102 derivation, provided by methods such as EAP-TLS [RFC2716] are 2103 required [IEEE80211i], so as to address the threat of rogue devices, 2104 and provide keying material to bind the initial authentication to 2105 subsequent data traffic. 2107 If the selected EAP method does not support mutual authentication, 2108 then the peer will be vulnerable to attack by rogue authenticators 2109 and backend authentication servers. If the EAP method does not derive 2110 keys, then TSKs will not be available for use with a negotiated 2111 ciphersuite, and there will be no binding between the initial EAP 2112 authentication and subsequent data traffic, leaving the session 2113 vulnerable to hijack. 2115 If the backend authentication server does not protect against 2116 authenticator masquerade, or provide the proper binding of the AAA- 2117 Key to the session within the AAA-Token, then one or more AAA-Keys 2118 may be sent to an unauthorized party, and an attacker may be able to 2119 gain access to the network. If the AAA-Token is provided to an 2120 untrusted AAA intermediary, then that intermediary may be able to 2121 modify the AAA-Key, or the attributes associated with it, as 2122 described in [RFC2607]. 2124 If the Secure Association Protocol does not provide mutual proof of 2125 possession of the AAA-Key material, then the peer will not have 2126 assurance that it is connected to the correct authenticator, only 2127 that the authenticator and backend authentication server share a 2128 trust relationship (since AAA protocols support mutual 2129 authentication). This distinction can become important when multiple 2130 authenticators receive AAA-Keys from the backend authentication 2131 server, such as where fast handoff is supported. If the TSK 2132 derivation does not provide for protected ciphersuite and 2133 capabilities negotiation, then downgrade attacks are possible. 2135 5.4. Man-in-the-middle Attacks 2137 As described in [I-D.puthenkulam-eap-binding], EAP method sequences 2138 and compound authentication mechanisms may be subject to man-in-the- 2139 middle attacks. When such attacks are successfully carried out, the 2140 attacker acts as an intermediary between a victim and a legitimate 2141 authenticator. This allows the attacker to authenticate successfully 2142 to the authenticator, as well as to obtain access to the network. 2144 In order to prevent these attacks, [I-D.puthenkulam-eap-binding] 2145 recommends derivation of a compound key by which the EAP peer and 2146 server can prove that they have participated in the entire EAP 2147 exchange. Since the compound key must not be known to an attacker 2148 posing as an authenticator, and yet must be derived from quantities 2149 that are exported by EAP methods, it may be desirable to derive the 2150 compound key from a portion of the EMSK. In order to provide proper 2151 key hygiene, it is recommended that the compound key used for man-in- 2152 the-middle protection be cryptographically separate from other keys 2153 derived from the EMSK, such as fast handoff keys, discussed in 2154 Appendix E. 2156 5.5. Denial of Service Attacks 2158 The caching of security associations may result in vulnerability to 2159 denial of service attacks. Since an EAP peer may derive multiple EAP 2160 SAs with a given EAP server, and creation of a new EAP SA does not 2161 implicitly delete a previous EAP SA, EAP methods that result in 2162 creation of persistent state may be vulnerable to denial of service 2163 attacks by a rogue EAP peer. 2165 As a result, EAP methods creating persistent state may wish to limit 2166 the number of cached EAP SAs (Phase 1a) corresponding to an EAP peer. 2167 For example, an EAP server may choose to only retain a few EAP SAs 2168 for each peer. This prevents a rogue peer from denying access to 2169 other peers. 2171 Similarly, an authenticator may have multiple AAA-Key SAs 2172 corresponding to a given EAP peer; to conserve resources an 2173 authenticator may choose to limit the number of cached AAA-Key (Phase 2174 1 b) SAs for each peer. 2176 Depending on the media, creation of a new unicast Secure Association 2177 SA may or may not imply deletion of a previous unicast secure 2178 association SA. Where there is no implied deletion, the 2179 authenticator may choose to limit Phase 2 (unicast and multicast) 2180 Secure Association SAs for each peer. 2182 5.6. Impersonation 2184 Both the RADIUS and Diameter protocols are potentially vulnerable to 2185 impersonation by a rogue authenticator. 2187 While AAA protocols such as RADIUS [RFC2865] or Diameter [RFC3588] 2188 support mutual authentication between the authenticator (known as the 2189 AAA client) and the backend authentication server (known as the AAA 2190 server), the security mechanisms vary according to the AAA protocol. 2192 In RADIUS, the shared secret used for authentication is determined by 2193 the source address of the RADIUS packet. As noted in [RFC3579] 2194 Section 4.3.7, it is highly desirable that the source address be 2195 checked against one or more NAS identification attributes so as to 2196 detect and prevent impersonation attacks. 2198 When RADIUS requests are forwarded by a proxy, the NAS-IP-Address or 2199 NAS-IPv6-Address attributes may not correspond to the source address. 2200 Since the NAS-Identifier attribute need not contain an FQDN, it also 2201 may not correspond to the source address, even indirectly. [RFC2865] 2202 Section 3 states: 2204 A RADIUS server MUST use the source IP address of the RADIUS 2205 UDP packet to decide which shared secret to use, so that 2206 RADIUS requests can be proxied. 2208 This implies that it is possible for a rogue authenticator to forge 2209 NAS-IP-Address, NAS-IPv6-Address or NAS-Identifier attributes within 2210 a RADIUS Access-Request in order to impersonate another 2211 authenticator. Among other things, this can result in messages (and 2212 MSKs) being sent to the wrong authenticator. Since the rogue 2213 authenticator is authenticated by the RADIUS proxy or server purely 2214 based on the source address, other mechanisms are required to detect 2215 the forgery. In addition, it is possible for attributes such as the 2216 Called-Station-Id and Calling-Station-Id to be forged as well. 2218 As recommended in [RFC3579], this vulnerability can be mitigated by 2219 having RADIUS proxies check authenticator identification attributes 2220 against the source address. 2222 To allow verification of session parameters such as the Called- 2223 Station- Id and Calling-Station-Id, these can be sent by the EAP peer 2224 to the server, protected by the TEKs. The RADIUS server can then 2225 check the parameters sent by the EAP peer against those claimed by 2226 the authenticator. If a discrepancy is found, an error can be 2227 logged. 2229 While [RFC3588] requires use of the Route-Record AVP, this utilizes 2230 FQDNs, so that impersonation detection requires DNS A/AAAA and PTR 2231 RRs to be properly configured. As a result, it appears that Diameter 2232 is as vulnerable to this attack as RADIUS, if not more so. To address 2233 this vulnerability, it is necessary to allow the backend 2234 authentication server to communicate with the authenticator directly, 2235 such as via the redirect functionality supported in [RFC3588]. 2237 5.7. Channel binding 2239 It is possible for a compromised or poorly implemented EAP 2240 authenticator to communicate incorrect information to the EAP peer 2241 and/or server. This may enable an authenticator to impersonate 2242 another authenticator or communicate incorrect information via out- 2243 of-band mechanisms (such as via a AAA or lower layer protocol). 2245 Where EAP is used in pass-through mode, the EAP peer typically does 2246 not verify the identity of the pass-through authenticator, it only 2247 verifies that the pass-through authenticator is trusted by the EAP 2248 server. This creates a potential security vulnerability, described in 2249 [RFC3748] Section 7.15. 2251 [RFC3579] Section 4.3.7 describes how an EAP pass-through 2252 authenticator acting as a AAA client can be detected if it attempts 2253 to impersonate another authenticator (such by sending incorrect NAS- 2254 Identifier [RFC2865], NAS-IP-Address [RFC2865] or NAS-IPv6-Address 2255 [RFC3162] attributes via the AAA protocol). However, it is possible 2256 for a pass-through authenticator acting as a AAA client to provide 2257 correct information to the AAA server while communicating misleading 2258 information to the EAP peer via a lower layer protocol. 2260 For example, it is possible for a compromised authenticator to 2261 utilize another authenticator's Called-Station-Id or NAS-Identifier 2262 in communicating with the EAP peer via a lower layer protocol, or for 2263 a pass-through authenticator acting as a AAA client to provide an 2264 incorrect peer Calling-Station-Id [RFC2865][RFC3580] to the AAA 2265 server via the AAA protocol. 2267 As noted in [RFC3748] Section 7.15, this vulnerability can be 2268 addressed by use of EAP methods that support a protected exchange of 2269 channel properties such as endpoint identifiers, including (but not 2270 limited to): Called-Station-Id [RFC2865][RFC3580], Calling-Station-Id 2271 [RFC2865][RFC3580], NAS-Identifier [RFC2865], NAS-IP-Address 2272 [RFC2865], and NAS-IPv6-Address [RFC3162]. 2274 Using such a protected exchange, it is possible to match the channel 2275 properties provided by the authenticator via out-of-band mechanisms 2276 against those exchanged within the EAP method. 2278 5.8. Key Strength 2280 In order to guard against brute force attacks, EAP methods deriving 2281 keys need to be capable of generating keys with an appropriate 2282 effective symmetric key strength. In order to ensure that key 2283 generation is not the weakest link, it is necessary for EAP methods 2284 utilizing public key cryptography to choose a public key that has a 2285 cryptographic strength meeting the symmetric key strength 2286 requirement. 2288 As noted in [RFC3766] Section 5, this results in the following 2289 required RSA or DH module and DSA subgroup size in bits, for a given 2290 level of attack resistance in bits: 2292 Attack Resistance RSA or DH Modulus DSA subgroup 2293 (bits) size (bits) size (bits) 2294 ----------------- ----------------- ------------ 2295 70 947 128 2296 80 1228 145 2297 90 1553 153 2298 100 1926 184 2299 150 4575 279 2300 200 8719 373 2301 250 14596 475 2303 5.9. Key Wrap 2305 As described in [RFC3579] Section 4.3, known problems exist in the 2306 key wrap specified in [RFC2548]. Where the same RADIUS shared secret 2307 is used by a PAP authenticator and an EAP authenticator, there is a 2308 vulnerability to known plaintext attack. Since RADIUS uses the 2309 shared secret for multiple purposes, including per-packet 2310 authentication, attribute hiding, considerable information is exposed 2311 about the shared secret with each packet. This exposes the shared 2312 secret to dictionary attacks. MD5 is used both to compute the RADIUS 2313 Response Authenticator and the Message-Authenticator attribute, and 2314 some concerns exist relating to the security of this hash 2315 [MD5Attack]. 2317 As discussed in [RFC3579] Section 4.3, the security vulnerabilities 2318 of RADIUS are extensive, and therefore development of an alternative 2319 key wrap technique based on the RADIUS shared secret would not 2320 substantially improve security. As a result, [RFC3759] Section 4.2 2321 recommends running RADIUS over IPsec. The same approach is taken in 2322 Diameter EAP [I-D.ietf-aaa-eap], which defines cleartext key 2323 attributes, to be protected by IPsec or TLS. 2325 Where an untrusted AAA intermediary is present (such as a RADIUS 2326 proxy or a Diameter agent), and data object security is not used, the 2327 AAA-Key may be recovered by an attacker in control of the untrusted 2328 intermediary. Possession of the AAA-Key enables decryption of data 2329 traffic sent between the peer and a specific authenticator; however 2330 where key separation is implemented, compromise of the AAA-Key does 2331 not enable an attacker to impersonate the peer to another 2332 authenticator, since that requires possession of the MK or EMSK, 2333 which are not transported by the AAA protocol. This vulnerability 2334 may be mitigated by implementation of redirect functionality, as 2335 provided in [RFC3588]. 2337 6. Security Requirements 2339 This section summarizes the security requirements that must be met by 2340 EAP methods, AAA protocols, Secure Association Protocols and 2341 Ciphersuites in order to address the security threats described in 2342 this document. These requirements MUST be met by specifications 2343 requesting publication as an RFC. Each requirement provides a 2344 pointer to the sections of this document describing the threat that 2345 it mitigates. 2347 6.1. EAP Method Requirements 2349 It is possible for the peer and EAP server to mutually authenticate 2350 and derive keys. In order to provide keying material for use in a 2351 subsequently negotiated ciphersuite, an EAP method supporting key 2352 derivation MUST export a Master Session Key (MSK) of at least 64 2353 octets, and an Extended Master Session Key (EMSK) of at least 64 2354 octets. EAP Methods deriving keys MUST provide for mutual 2355 authentication between the EAP peer and the EAP Server. 2357 The MSK and EMSK MUST NOT be used directly to protect data; however, 2358 they are of sufficient size to enable derivation of a AAA-Key 2359 subsequently used to derive Transient Session Keys (TSKs) for use 2360 with the selected ciphersuite. Each ciphersuite is responsible for 2361 specifying how to derive the TSKs from the AAA-Key. 2363 The AAA-Key is derived from the keying material exported by the EAP 2364 method (MSK and EMSK). This derivation occurs on the AAA server. In 2365 many existing protocols that use EAP, the AAA-Key and MSK are 2366 equivalent, but more complicated mechanisms are possible (see 2367 Appendix E for details). 2369 EAP methods SHOULD ensure the freshness of the MSK and EMSK even in 2370 cases where one party may not have a high quality random number 2371 generator. A RECOMMENDED method is for each party to provide a nonce 2372 of at least 128 bits, used in the derivation of the MSK and EMSK. 2374 EAP methods export the MSK and EMSK and not Transient Session Keys so 2375 as to allow EAP methods to be ciphersuite and media independent. 2376 Keying material exported by EAP methods MUST be independent of the 2377 ciphersuite negotiated to protect data. 2379 Depending on the lower layer, EAP methods may run before or after 2380 ciphersuite negotiation, so that the selected ciphersuite may not be 2381 known to the EAP method. By providing keying material usable with 2382 any ciphersuite, EAP methods can used with a wide range of 2383 ciphersuites and media. 2385 It is RECOMMENDED that methods providing integrity protection of EAP 2386 packets include coverage of all the EAP header fields, including the 2387 Code, Identifier, Length, Type and Type-Data fields. 2389 In order to preserve algorithm independence, EAP methods deriving 2390 keys SHOULD support (and document) the protected negotiation of the 2391 ciphersuite used to protect the EAP conversation between the peer and 2392 server. This is distinct from the ciphersuite negotiated between the 2393 peer and authenticator, used to protect data. 2395 The strength of Transient Session Keys (TSKs) used to protect data is 2396 ultimately dependent on the strength of keys generated by the EAP 2397 method. If an EAP method cannot produce keying material of 2398 sufficient strength, then the TSKs may be subject to brute force 2399 attack. In order to enable deployments requiring strong keys, EAP 2400 methods supporting key derivation SHOULD be capable of generating an 2401 MSK and EMSK, each with an effective key strength of at least 128 2402 bits. 2404 Methods supporting key derivation MUST demonstrate cryptographic 2405 separation between the MSK and EMSK branches of the EAP key 2406 hierarchy. Without violating a fundamental cryptographic assumption 2407 (such as the non-invertibility of a one-way function) an attacker 2408 recovering the MSK or EMSK MUST NOT be able to recover the other 2409 quantity with a level of effort less than brute force. 2411 Non-overlapping substrings of the MSK MUST be cryptographically 2412 separate from each other. That is, knowledge of one substring MUST 2413 NOT help in recovering some other substring without breaking some 2414 hard cryptographic assumption. This is required because some 2415 existing ciphersuites form TSKs by simply splitting the AAA-Key to 2416 pieces of appropriate length. Likewise, non-overlapping substrings 2417 of the EMSK MUST be cryptographically separate from each other, and 2418 from substrings of the MSK. 2420 The EMSK MUST remain on the EAP peer and EAP server where it is 2421 derived; it MUST NOT be transported to, or shared with, additional 2422 parties, or used to derive any other keys. 2424 Since EAP does not provide for explicit key lifetime negotiation, EAP 2425 peers, authenticators and authentication servers MUST be prepared for 2426 situations in which one of the parties discards key state which 2427 remains valid on another party. 2429 The development and validation of key derivation algorithms is 2430 difficult, and as a result EAP methods SHOULD reuse well established 2431 and analyzed mechanisms for key derivation (such as those specified 2432 in IKE [RFC2409] or TLS [RFC2246]), rather than inventing new ones. 2433 EAP methods SHOULD also utilize well established and analyzed 2434 mechanisms for MSK and EMSK derivation. 2436 6.1.1. Requirements for EAP methods 2438 In order for an EAP method to meet the guidelines for EMSK usage it 2439 must meet the following requirements: 2441 o It must specify how to derive the EMSK 2443 o The key material used for the EMSK MUST be 2444 computationally independent of the MSK and TEKs. 2446 o The EMSK MUST NOT be used for any other purpose than the key 2447 derivation described in this document. 2449 o The EMSK MUST be secret and not known to someone observing 2450 the authentication mechanism protocol exchange. 2452 o The EMSK MUST be maintained within the EAP server. 2453 Only keys (AMSKs) derived according to this specification 2454 may be exported from the EAP server. 2456 o The EMSK MUST be unique for each session. 2458 o The EAP mechanism SHOULD provide a way of naming the EMSK. 2460 Implementations of EAP frameworks on the EAP-Peer and EAP-Server 2461 SHOULD provide an interface to obtain AMSKs. The implementation MAY 2462 restrict which callers can obtain which keys. 2464 6.1.2. Requirements for EAP applications 2466 In order for an application to meet the guidelines for EMSK usage it 2467 must meet the following requirements: 2469 o New applications following this specification SHOULD NOT use the 2470 MSK. If more than one application uses the MSK, then the 2471 cryptographic separation is not achieved. Implementations SHOULD 2472 prevent such combinations. 2474 o A peer MUST NOT use the EMSK in any other way except to 2475 derive Application Master Session Keys (AMSKs) using the 2476 key derivation specified in Appendix F. It MUST NOT 2477 use the EMSK directly for cryptographic protection of data, 2478 and SHOULD provide only the AMSKs to applications. 2480 o Applications MUST define distinct key labels, application 2481 specific data, and the length of derived key material used in the key 2482 derivation described in Appendix F. 2484 o Applications MUST define how they use their AMSK to derive TSKs 2485 for their use. 2487 6.2. AAA Protocol Requirements 2489 AAA protocols suitable for use in transporting EAP MUST provide the 2490 following facilities: 2492 Security services 2493 AAA protocols used for transport of EAP keying material MUST 2494 implement and SHOULD use per-packet integrity and authentication, 2495 replay protection and confidentiality. These requirements are met 2496 by Diameter EAP [I-D.ietf-aaa-eap], as well as RADIUS over IPsec 2497 [RFC3579]. 2499 Session Keys 2500 AAA protocols used for transport of EAP keying material MUST 2501 implement and SHOULD use dynamic key management in order to derive 2502 fresh session keys, as in Diameter EAP [I-D.ietf-aaa-eap] and 2503 RADIUS over IPsec [RFC3579], rather than using a static key, as 2504 originally defined in RADIUS [RFC2865]. 2506 Mutual authentication 2507 AAA protocols used for transport of EAP keying material MUST 2508 provide for mutual authentication between the authenticator and 2509 backend authentication server. These requirements are met by 2510 Diameter EAP [I-D.ietf-aaa-eap] as well as by RADIUS EAP [RFC3579]. 2512 Authorization 2513 AAA protocols used for transport of EAP keying material SHOULD 2514 provide protection against rogue authenticators masquerading as 2515 other authenticators. This can be accomplished, for example, by 2516 requiring that AAA agents check the source address of packets 2517 against the origin attributes (Origin-Host AVP in Diameter, NAS-IP- 2518 Address, NAS-IPv6-Address, NAS-Identifier in RADIUS). For details, 2519 see [RFC3579] Section 4.3.7. 2521 Key transport 2522 Since EAP methods do not export Transient Session Keys (TSKs) in 2523 order to maintain media and ciphersuite independence, the AAA 2524 server MUST NOT transport TSKs from the backend authentication 2525 server to authenticator. 2527 Key transport specification 2528 In order to enable backend authentication servers to provide keying 2529 material to the authenticator in a well defined format, AAA 2530 protocols suitable for use with EAP MUST define the format and 2531 wrapping of the AAA-Token. 2533 EMSK transport 2534 Since the EMSK is a secret known only to the backend authentication 2535 server and peer, the AAA-Token MUST NOT transport the EMSK from the 2536 backend authentication server to the authenticator. 2538 AAA-Token protection 2539 To ensure against compromise, the AAA-Token MUST be integrity 2540 protected, authenticated, replay protected and encrypted in 2541 transit, using well-established cryptographic algorithms. 2543 Session Keys 2544 The AAA-Token SHOULD be protected with session keys as in Diameter 2545 [RFC3588] or RADIUS over IPsec [RFC3579] rather than static keys, 2546 as in [RFC2548]. 2548 Key naming 2549 In order to ensure against confusion between the appropriate keying 2550 material to be used in a given Secure Association Protocol 2551 exchange, the AAA-Token SHOULD include explicit key names and 2552 context appropriate for informing the authenticator how the keying 2553 material is to be used. 2555 Key Compromise 2556 Where untrusted intermediaries are present, the AAA-Token SHOULD 2557 NOT be provided to the intermediaries. In Diameter, handling of 2558 keys by intermediaries can be avoided using Redirect functionality 2559 [RFC3588]. 2561 6.3. Secure Association Protocol Requirements 2563 The Secure Association Protocol supports the following: 2565 Entity Naming 2566 The peer and authenticator SHOULD identify themselves in a manner 2567 that is independent of their attached ports. 2569 Mutual proof of possession 2570 The peer and authenticator MUST each demonstrate possession of the 2571 keying material transported between the backend authentication 2572 server and authenticator (AAA-Key). 2574 Key Naming 2575 The Secure Association Protocol MUST explicitly name the keys used 2576 in the proof of possession exchange, so as to prevent confusion 2577 when more than one set of keying material could potentially be used 2578 as the basis for the exchange. 2580 Creation and Deletion 2581 In order to support the correct processing of phase 2 security 2582 associations, the Secure Association (phase 2) protocol MUST 2583 support the naming of phase 2 security associations and associated 2584 transient session keys, so that the correct set of transient 2585 session keys can be identified for processing a given packet. The 2586 phase 2 Secure Association Protocol also MUST support transient 2587 session key activation and SHOULD support deletion, so that 2588 establishment and re-establishment of transient session keys can be 2589 synchronized between the parties. 2591 Integrity and Replay Protection 2592 The Secure Association Protocol MUST support integrity and replay 2593 protection of all messages. 2595 Direct operation 2596 Since the phase 2 Secure Association Protocol is concerned with the 2597 establishment of security associations between the EAP peer and 2598 authenticator, including the derivation of transient session keys, 2599 only those parties have "a need to know" the transient session 2600 keys. The Secure Association Protocol MUST operate directly between 2601 the peer and authenticator, and MUST NOT be passed-through to the 2602 backend authentication server, or include additional parties. 2604 Derivation of transient session keys 2605 The Secure Association Protocol negotiation MUST support derivation 2606 of unicast and multicast transient session keys suitable for use 2607 with the negotiated ciphersuite. 2609 TSK freshness 2610 The Secure Association (phase 2) Protocol MUST support the 2611 derivation of fresh unicast and multicast transient session keys, 2612 even when the keying material provided by the backend 2613 authentication server is not fresh. This is typically supported by 2614 including an exchange of nonces within the Secure Association 2615 Protocol. 2617 Bi-directional operation 2618 While some ciphersuites only require a single set of transient 2619 session keys to protect traffic in both directions, other 2620 ciphersuites require a unique set of transient session keys in each 2621 direction. The phase 2 Secure Association Protocol SHOULD provide 2622 for the derivation of unicast and multicast keys in each direction, 2623 so as not to require two separate phase 2 exchanges in order to 2624 create a bi-directional phase 2 security association. 2626 Secure capabilities negotiation 2627 The Secure Association Protocol MUST support secure capabilities 2628 negotiation. This includes security parameters such as the 2629 security association identifier (SAID) and ciphersuites, as well as 2630 negotiation of the lifetime of the TSKs, AAA-Key and exported EAP 2631 keys. Secure capabilities negotiation also includes confirmation 2632 of the capabilities discovered during the discovery phase (phase 2633 0), so as to ensure that the announced capabilities have not been 2634 forged. 2636 Key Scoping 2637 The Secure Association Protocol MUST ensure the synchronization of 2638 key scope between the peer and authenticator. This includes 2639 negotiation of restrictions on key usage. 2641 6.4. Ciphersuite Requirements 2643 Ciphersuites suitable for keying by EAP methods MUST provide the 2644 following facilities: 2646 TSK derivation 2647 In order to allow a ciphersuite to be usable within the EAP keying 2648 framework, a specification MUST be provided describing how 2649 transient session keys suitable for use with the ciphersuite are 2650 derived from the AAA-Key. 2652 EAP method independence 2653 Algorithms for deriving transient session keys from the AAA-Key 2654 MUST NOT depend on the EAP method. However, algorithms for 2655 deriving TEKs MAY be specific to the EAP method. 2657 Cryptographic separation 2658 The TSKs derived from the AAA-Key MUST be cryptographically 2659 separate from each other. Similarly, TEKs MUST be 2660 cryptographically separate from each other. In addition, the TSKs 2661 MUST be cryptographically separate from the TEKs. 2663 7. IANA Considerations 2665 This section provides guidance to the Internet Assigned Numbers 2666 Authority (IANA) regarding registration of values related to EAP key 2667 management, in accordance with BCP 26, [RFC2434]. 2669 The following terms are used here with the meanings defined in BCP 2670 26: "name space", "assigned value", "registration". 2672 The following policies are used here with the meanings defined in BCP 2673 26: "Private Use", "First Come First Served", "Expert Review", 2674 "Specification Required", "IETF Consensus", "Standards Action". 2676 For registration requests where a Designated Expert should be 2677 consulted, the responsible IESG area director should appoint the 2678 Designated Expert. The intention is that any allocation will be 2679 accompanied by a published RFC. But in order to allow for the 2680 allocation of values prior to the RFC being approved for publication, 2681 the Designated Expert can approve allocations once it seems clear 2682 that an RFC will be published. The Designated expert will post a 2683 request to the EAP WG mailing list (or a successor designated by the 2684 Area Director) for comment and review, including an Internet-Draft. 2685 Before a period of 30 days has passed, the Designated Expert will 2686 either approve or deny the registration request and publish a notice 2687 of the decision to the EAP WG mailing list or its successor, as well 2688 as informing IANA. A denial notice must be justified by an 2689 explanation and, in the cases where it is possible, concrete 2690 suggestions on how the request can be modified so as to become 2691 acceptable. 2693 This document introduces a new name space for "key labels". Key 2694 labels are ASCII strings and are assigned via IETF Consensus. It is 2695 expected that key label specifications will include the following 2696 information: 2698 o A description of the application 2699 o The key label to be used 2700 o How TSKs will be derived from the AMSK and how they will be used 2701 o If application specific data is used, what it is and how it is 2702 maintained 2703 o Where the AMSKs or TSKs will be used and how they are 2704 communicated if necessary. 2706 8. References 2708 8.1. Normative References 2710 [RFC2119] 2711 Bradner, S., "Key words for use in RFCs to Indicate Requirement 2712 Levels", BCP 14, RFC 2119, March 1997. 2714 [RFC2434] 2715 Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 2716 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 2718 [RFC3748] 2719 Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. Lefkowetz, 2720 "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. 2722 8.2. Informative References 2724 [RFC0793] 2725 Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 2726 September 1981. 2728 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 2729 1661, July 1994. 2731 [RFC1968] Meyer, G. and K. Fox, "The PPP Encryption Control Protocol 2732 (ECP)", RFC 1968, June 1996. 2734 [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing 2735 for Message Authentication", RFC 2104, February 1997. 2737 [RFC2246] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. 2738 and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, 2739 January 1999. 2741 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 2742 Internet Protocol", RFC 2401, November 1998. 2744 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 2745 RFC 2409, November 1998. 2747 [RFC2419] Sklower, K. and G. Meyer, "The PPP DES Encryption Protocol, 2748 Version 2 (DESE-bis)", RFC 2419, September 1998. 2750 [RFC2420] Kummert, H., "The PPP Triple-DES Encryption Protocol (3DESE)", 2751 RFC 2420, September 1998. 2753 [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D. and 2754 R. Wheeler, "A Method for Transmitting PPP Over Ethernet 2755 (PPPoE)", RFC 2516, February 1999. 2757 [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2758 2548, March 1999. 2760 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 2761 Implementation in Roaming", RFC 2607, June 1999. 2763 [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol", 2764 RFC 2716, October 1999. 2766 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 2767 Authentication Dial In User Service (RADIUS)", RFC 2865, June 2768 2000. 2770 [RFC3078] Pall, G. and G. Zorn, "Microsoft Point-To-Point Encryption 2771 (MPPE) Protocol", RFC 3078, March 2001. 2773 [RFC3079] Zorn, G., "Deriving Keys for use with Microsoft Point-to-Point 2774 Encryption (MPPE)", RFC 3079, March 2001. 2776 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial 2777 In User Service) Support For Extensible Authentication 2778 Protocol (EAP)", RFC 3579, September 2003. 2780 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese, 2781 "IEEE 802.1X Remote Authentication Dial In User Service 2782 (RADIUS) Usage Guidelines", RFC 3580, September 2003. 2784 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. 2785 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 2787 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public 2788 Keys Used For Exchanging Symmetric Keys", RFC 3766, April 2789 2004. 2791 [FIPSDES] National Institute of Standards and Technology, "Data 2792 Encryption Standard", FIPS PUB 46, January 1977. 2794 [DESMODES] 2795 National Institute of Standards and Technology, "DES Modes of 2796 Operation", FIPS PUB 81, December 1980, . 2799 [IEEE802] Institute of Electrical and Electronics Engineers, "IEEE 2800 Standards for Local and Metropolitan Area Networks: Overview 2801 and Architecture", ANSI/IEEE Standard 802, 1990. 2803 [IEEE80211] 2804 Institute of Electrical and Electronics Engineers, 2805 "Information technology - Telecommunications and information 2806 exchange between systems - Local and metropolitan area 2807 networks - Specific Requirements Part 11: Wireless LAN Medium 2808 Access Control (MAC) and Physical Layer (PHY) Specifications", 2809 IEEE IEEE Standard 802.11-1999, 1999. 2811 [IEEE8021X] 2812 Institute of Electrical and Electronics Engineers, "Local and 2813 Metropolitan Area Networks: Port-Based Network Access 2814 Control", IEEE Standard 802.1X-2004, September 2004. 2816 [IEEE8021Q] 2817 Institute of Electrical and Electronics Engineers, "IEEE 2818 Standards for Local and Metropolitan Area Networks: Draft 2819 Standard for Virtual Bridged Local Area Networks", IEEE 2820 Standard 802.1Q/D8, January 1998. 2822 [IEEE80211F] 2823 Institute of Electrical and Electronics Engineers, 2824 "Recommended Practice for Multi-Vendor Access Point 2825 Interoperability via an Inter-Access Point Protocol Across 2826 Distribution Systems Supporting IEEE 802.11 Operation", IEEE 2827 802.11F, July 2003. 2829 [IEEE80211i] 2830 Institute of Electrical and Electronics Engineers, "Draft 2831 Supplement to STANDARD FOR Telecommunications and Information 2832 Exchange between Systems - LAN/MAN Specific Requirements - 2833 Part 11: Wireless Medium Access Control (MAC) and physical 2834 layer (PHY) specifications: Specification for Enhanced 2835 Security", IEEE Draft 802.11I/ D8, February 2004. 2837 [IEEE-02-758] 2838 Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, 2839 "Proactive Caching Strategies for IAPP Latency Improvement 2840 during 802.11 Handoff", IEEE 802.11 Working Group, 2841 IEEE-02-758r1-F Draft 802.11I/D5.0, November 2002. 2843 [IEEE-03-084] 2844 Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, 2845 "Proactive Key Distribution to support fast and secure 2846 roaming", IEEE 802.11 Working Group, IEEE-03-084r1-I, 2847 http://www.ieee802.org/11/Documents/DocumentHolder/ 3-084.zip, 2848 January 2003. 2850 [IEEE-03-155] 2851 Aboba, B., "Fast Handoff Issues", IEEE 802.11 Working Group, 2852 IEEE-03-155r0-I, http://www.ieee802.org/11/ 2853 Documents/DocumentHolder/3-155.zip, March 2003. 2855 [I-D.ietf-roamops-cert] 2856 Aboba, B., "Certificate-Based Roaming", draft-ietf-roamops- 2857 cert-02 (work in progress), April 1999. 2859 [I-D.ietf-aaa-eap] 2860 Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible 2861 Authentication Protocol (EAP) Application", draft-ietf-aaa- 2862 eap-08 (work in progress), June 2004. 2864 [I-D.irtf-aaaarch-handoff] 2865 Arbaugh, W. and B. Aboba, "Handoff Extension to RADIUS", 2866 draft-irtf-aaaarch-handoff-04 (work in progress), October 2867 2003. 2869 [I-D.puthenkulam-eap-binding] 2870 Puthenkulam, J., "The Compound Authentication Binding 2871 Problem", draft-puthenkulam-eap-binding-04 (work in progress), 2872 October 2003. 2874 [I-D.aboba-802-context] 2875 Aboba, B. and T. Moore, "A Model for Context Transfer in IEEE 2876 802", draft-aboba-802-context-03 (work in progress), October 2877 2003. 2879 [I-D.arkko-pppext-eap-aka] 2880 Arkko, J. and H. Haverinen, "EAP AKA Authentication", draft- 2881 arkko-pppext-eap-aka-11 (work in progress), October 2003. 2883 [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", draft- 2884 ietf-ipsec-ikev2-14 (work in progress), June 2004. 2886 [8021XHandoff] 2887 Pack, S. and Y. Choi, "Pre-Authenticated Fast Handoff in a 2888 Public Wireless LAN Based on IEEE 802.1X Model", School of 2889 Computer Science and Engineering, Seoul National University, 2890 Seoul, Korea, 2002. 2892 [MD5Attack] 2893 Dobbertin, H., "The Status of MD5 After a Recent Attack", 2894 CryptoBytes, Vol.2 No.2, 1996. 2896 [WLANREQ] Stanley, D., Walker, J. and B. Aboba, "EAP Method Requirements 2897 for Wireless LANs", draft-walker-ieee802-req-02.txt (work in 2898 progress), July 2004. 2900 [Housley56] 2901 Housley, R., "Key Management in AAA", Presentation to the AAA 2902 WG at IETF 56, 2903 http://www.ietf.org/proceedings/03mar/slides/aaa-5/index.html, 2904 March 2003. 2906 Acknowledgments 2908 Thanks to Arun Ayyagari, Ashwin Palekar, and Tim Moore of Microsoft, 2909 Dorothy Stanley of Agere, Bob Moskowitz of TruSecure, and Russ 2910 Housley of Vigil Security for useful feedback. 2912 Author Addresses 2914 Bernard Aboba 2915 Microsoft Corporation 2916 One Microsoft Way 2917 Redmond, WA 98052 2919 EMail: bernarda@microsoft.com 2920 Phone: +1 425 706 6605 2921 Fax: +1 425 936 7329 2923 Dan Simon 2924 Microsoft Research 2925 Microsoft Corporation 2926 One Microsoft Way 2927 Redmond, WA 98052 2929 EMail: dansimon@microsoft.com 2930 Phone: +1 425 706 6711 2931 Fax: +1 425 936 7329 2933 Jari Arkko 2934 Ericsson 2935 Jorvas 02420 2936 Finland 2938 Phone: 2939 EMail: jari.arkko@ericsson.com 2941 Pasi Eronen 2942 Nokia Research Center 2943 P.O. Box 407 2944 FIN-00045 Nokia Group 2945 Finland 2946 EMail: pasi.eronen@nokia.com 2948 Henrik Levkowetz (editor) 2949 ipUnplugged AB 2950 Arenavagen 27 2951 Stockholm S-121 28 2952 SWEDEN 2954 Phone: +46 708 32 16 08 2955 EMail: henrik@levkowetz.com 2957 Appendix A - Ciphersuite Keying Requirements 2959 To date, PPP and IEEE 802.11 ciphersuites are suitable for keying by 2960 EAP. This Appendix describes the keying requirements of common PPP 2961 and 802.11 ciphersuites. 2963 PPP ciphersuites include DESEbis [RFC2419], 3DES [RFC2420], and MPPE 2964 [RFC3078]. The DES algorithm is described in [FIPSDES], and DES 2965 modes (such as CBC, used in [RFC2419] and DES-EDE3-CBC, used in 2966 [RFC2420]) are described in [DESMODES]. For PPP DESEbis, a single 2967 56-bit encryption key is required, used in both directions. For PPP 2968 3DES, a 168-bit encryption key is needed, used in both directions. As 2969 described in [RFC2419] for DESEbis and [RFC2420] for 3DES, the IV, 2970 which is different in each direction, is "deduced from an explicit 2971 64-bit nonce, which is exchanged in the clear during the [ECP] 2972 negotiation phase." There is therefore no need for the IV to be 2973 provided by EAP. 2975 For MPPE, 40-bit, 56-bit or 128-bit encryption keys are required in 2976 each direction, as described in [RFC3078]. No initialization vector 2977 is required. 2979 While these PPP ciphersuites provide encryption, they do not provide 2980 per-packet authentication or integrity protection, so an 2981 authentication key is not required in either direction. 2983 Within [IEEE80211], Transient Session Keys (TSKs) are required both 2984 for unicast traffic as well as for multicast traffic, and therefore 2985 separate key hierarchies are required for unicast keys and multicast 2986 keys. IEEE 802.11 ciphersuites include WEP-40, described in 2987 [IEEE80211], which requires a 40-bit encryption key, the same in 2988 either direction; and WEP-128, which requires a 104-bit encryption 2989 key, the same in either direction. These ciphersuites also do not 2990 support per-packet authentication and integrity protection. In 2991 addition to these unicast keys, authentication and encryption keys 2992 are required to wrap the multicast encryption key. 2994 Recently, new ciphersuites have been proposed for use with IEEE 2995 802.11 that provide per-packet authentication and integrity 2996 protection as well as encryption [IEEE80211i]. These include TKIP, 2997 which requires a single 128-bit encryption key and a 128-bit 2998 authentication key (used in both directions); AES CCMP, which 2999 requires a single 128-bit key (used in both directions) in order to 3000 authenticate and encrypt data; and WRAP, which requires a single 3001 128-bit key (used in both directions). 3003 As with WEP, authentication and encryption keys are also required to 3004 wrap the multicast encryption (and possibly, authentication) keys. 3006 Appendix B - Transient EAP Key (TEK) Hierarchy 3008 Figure B-1 illustrates the TEK key hierarchy for EAP-TLS [RFC2716], 3009 which is based on the TLS key hierarchy described in [RFC2246]. The 3010 TLS-negotiated ciphersuite is used to set up a protected channel for 3011 use in protecting the EAP conversation, keyed by the derived TEKs. 3012 The TEK derivation proceeds as follows: 3014 master_secret = TLS-PRF-48(pre_master_secret, "master secret", 3015 client.random || server.random) 3016 TEK = TLS-PRF-X(master_secret, "key expansion", 3017 server.random || client.random) 3018 Where: 3019 TLS-PRF-X = TLS pseudo-random function defined in [RFC2246], 3020 computed to X octets. 3021 master_secret = TLS term for the MK. 3023 | | | 3024 | | pre_master_secret | 3025 server| | | client 3026 Random| V | Random 3027 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3028 | | | | 3029 | | | | 3030 +---->| master_secret |<------+ 3031 | | (MK) | | 3032 | | | | 3033 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3034 | | | 3035 | | | 3036 | | | 3037 V V V 3038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3039 | | 3040 | | 3041 | Key Block | 3042 | (TEKs) | 3043 | | 3044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3045 | | | | | | 3046 | client | server | client | server | client | server 3047 | MAC | MAC | write | write | IV | IV 3048 | | | | | | 3049 V V V V V V 3051 Figure B-1 - TLS [RFC2246] Key Hierarchy 3053 Appendix C - EAP Key Hierarchy 3055 In EAP-TLS [RFC2716], the MSK is divided into two halves, 3056 corresponding to the "Peer to Authenticator Encryption Key" (Enc- 3057 RECV-Key, 32 octets, also known as the PMK) and "Authenticator to 3058 Peer Encryption Key" (Enc-SEND-Key, 32 octets). In [RFC2548], the 3059 Enc-RECV-Key (the PMK) is transported in the MS-MPPE-Recv-Key 3060 attribute, and the Enc-SEND-Key is transported in the MS-MPPE-Send- 3061 Key attribute. 3063 The EMSK is also divided into two halves, corresponding to the "Peer 3064 to Authenticator Authentication Key" (Auth-RECV-Key, 32 octets) and 3065 "Authenticator to Peer Authentication Key" (Auth-SEND-Key, 32 3066 octets). The IV is a 64 octet quantity that is a known value; octets 3067 0-31 are known as the "Peer to Authenticator IV" or RECV-IV, and 3068 Octets 32-63 are known as the "Authenticator to Peer IV", or SEND-IV. 3070 In EAP-TLS, the MSK, EMSK and IV are derived from the MK via a one- 3071 way function. This ensures that the MK cannot be derived from the 3072 MSK, EMSK or IV unless the one-way function (TLS PRF) is broken. 3073 Since the MSK is derived from the MK, if the MK is compromised then 3074 the MSK is also compromised. 3076 As described in [RFC2716], the formula for the derivation of the MSK, 3077 EMSK and IV from the MK is as follows: 3079 MSK = TLS-PRF-64(MK, "client EAP encryption", 3080 client.random || server.random) 3081 EMSK = second 64 octets of: 3082 TLS-PRF-128(MK, "client EAP encryption", 3083 client.random || server.random) 3084 IV = TLS-PRF-64("", "client EAP encryption", 3085 client.random || server.random) 3087 AAA-Key(0,31) = Peer to Authenticator Encryption Key (Enc-RECV-Key) 3088 (MS-MPPE-Recv-Key in [RFC2548]). Also known as the 3089 PMK. 3090 AAA-Key(32,63)= Authenticator to Peer Encryption Key (Enc-SEND-Key) 3091 (MS-MPPE-Send-Key in [RFC2548]) 3092 EMSK(0,31) = Peer to Authenticator Authentication Key (Auth-RECV-Key) 3093 EMSK(32,63) = Authenticator to Peer Authentication Key (Auth-Send-Key) 3094 IV(0,31) = Peer to Authenticator Initialization Vector (RECV-IV) 3095 IV(32,63) = Authenticator to Peer Initialization vector (SEND-IV) 3097 Where: 3099 AAA-Key(W,Z) = Octets W through Z includes of the AAA-Key. 3101 IV(W,Z) = Octets W through Z inclusive of the IV. 3102 MSK(W,Z) = Octets W through Z inclusive of the MSK. 3103 EMSK(W,Z) = Octets W through Z inclusive of the EMSK. 3104 MK = TLS master_secret 3105 TLS-PRF-X = TLS PRF function defined in [RFC2246] computed to X octets 3106 client.random = Nonce generated by the TLS client. 3107 server.random = Nonce generated by the TLS server. 3109 Figure C-1 describes the process by which the MSK,EMSK,IV and 3110 ultimately the TSKs, are derived from the MK. Note that in [RFC2716], 3111 the MK is referred to as the "TLS Master Secret". 3113 ---+ 3114 | ^ 3115 | TLS Master Secret (MK) | 3116 | | 3117 V | 3118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3119 | | EAP | 3120 | Master Session Key (MSK) | Method | 3121 | Derivation | | 3122 | | V 3123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ EAP ---+ 3124 | | | API ^ 3125 | MSK | EMSK | IV | 3126 | | | | 3127 V V V v 3128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 3129 | | | 3130 | | | 3131 | backend authentication server | | 3132 | | | 3133 | | V 3134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 3135 | | ^ 3136 | AAA-Key(0,31) | AAA-Key(32,63) | 3137 | (PMK) | Transported | 3138 | | via AAA | 3139 | | | 3140 V V V 3141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 3142 | | ^ 3143 | Ciphersuite-Specific Transient Session | Auth.| 3144 | Key Derivation | | 3145 | | V 3146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 3148 Figure C-1 - EAP TLS [RFC2716] Key hierarchy 3150 Appendix D - Transient Session Key (TSK) Derivation 3152 Within IEEE 802.11 RSN, the Pairwise Transient Key (PTK), a transient 3153 session key used to protect unicast traffic, is derived from the PMK 3154 (octets 0-31 of the MSK), known in [RFC2716] as the Peer to 3155 Authenticator Encryption Key. In [IEEE80211i], the PTK is derived 3156 from the PMK via the following formula: 3158 PTK = EAPOL-PRF-X(PMK, "Pairwise key expansion", Min(AA,SA) || 3159 Max(AA, SA) || Min(ANonce,SNonce) || Max(ANonce,SNonce)) 3161 Where: 3163 PMK = AAA-Key(0,31) 3164 SA = Station MAC address (Calling-Station-Id) 3165 AA = Access Point MAC address (Called-Station-Id) 3166 ANonce = Access Point Nonce 3167 SNonce = Station Nonce 3168 EAPOL-PRF-X = Pseudo-Random Function based on HMAC-SHA1, generating 3169 a PTK of size X octets. 3171 TKIP uses X = 64, while CCMP, WRAP, and WEP use X = 48. 3173 The EAPOL-Key Confirmation Key (KCK) is used to provide data origin 3174 authenticity in the TSK derivation. It utilizes the first 128 bits 3175 (bits 0-127) of the PTK. The EAPOL-Key Encryption Key (KEK) provides 3176 confidentiality in the TSK derivation. It utilizes bits 128-255 of 3177 the PTK. Bits 256-383 of the PTK are used by Temporal Key 1, and Bits 3178 384-511 are used by Temporal Key 2. Usage of TK1 and TK2 is 3179 ciphersuite specific. Details are available in [IEEE80211i]. 3181 Appendix E - AAA-Key Derivation 3183 Where a AAA-Key is generated as the result of a successful EAP 3184 authentication, the AAA-Key is set to MSK(0,63). 3186 As discussed in [I-D.irtf-aaaarch-handoff], [IEEE-02-758], 3187 [IEEE-03-084], and [8021XHandoff], keying material may be required 3188 for use in fast handoff between authenticators. Where the backend 3189 authentication server provides keying material to multiple 3190 authenticators in order to facilitate fast handoff, it is highly 3191 desirable for the keying material used on different authenticators to 3192 be cryptographically separate, so that if one authenticator is 3193 compromised, it does not lead to the compromise of other 3194 authenticators. Where keying material is provided by the backend 3195 authentication server, a key hierarchy derived from the EMSK, can be 3196 used to provide cryptographically separate keying material for use in 3197 fast handoff: 3199 AAA-Key-A = MSK(0,63) 3200 AAA-Key-B = PRF(EMSK(0,63),"EAP AAA-Key derivation for 3201 multiple attachments", AAA-Key-A,B-Called-Station-Id, 3202 Calling-Station-Id,length) 3204 AAA-Key-E = PRF(EMSK(0,63),"EAP AAA-Key derivation for 3205 multiple attachments",AAA-Key-A,E-Called-Station-Id, 3206 Calling-Station-Id, length) 3208 Where: 3209 Calling-Station-Id = STA MAC address 3210 B-Called-Station-Id = AP B MAC address 3211 E-Called-Station-Id = AP E MAC address 3212 PRF = Some suitable pseudo-random function 3213 length = length of derived key material 3215 Here AAA-Key-A is the AAA-Key derived during the initial EAP 3216 authentication between the peer and authenticator A. Based on this 3217 initial EAP authentication, the EMSK is also derived, which can be 3218 used to derive AAA-Keys for fast authentication between the EAP peer 3219 and authenticators B and E. Since the EMSK is cryptographically 3220 separate from the MSK, each of these AAA-Keys is cryptographically 3221 separate from each other, and are guaranteed to be unique between the 3222 EAP peer (also known as the STA) and the authenticator (also known as 3223 the AP). 3225 Appendix F - AMSK Key Derivation 3227 The EAP AMSK key derivation function (KDF) derives an AMSK from the 3228 Extended Master Session Key (EMSK), an application key label, 3229 optional application data, and output length. 3231 AMSK = KDF(EMSK, key label, optional application data, length) 3233 The key labels are printable ASCII strings unique for each 3234 application (see Section 7 for IANA Considerations). 3236 Additional ciphering keys (TSKs) can be derived from the AMSK using 3237 an application specific key derivation mechanism. In many cases, this 3238 AMSK->TSK derivation can simply split the AMSK to pieces of correct 3239 length. In particular, it is not necessary to use a cryptographic 3240 one-way function. Note that the length of the AMSK must be specified 3241 by the application. 3243 F.1 The EAP AMSK Key Derivation Function 3245 The EAP key derivation function is taken from the PRF+ key expansion 3246 PRF from [IKEv2]. This KDF takes 4 parameters as input: secret, 3247 label, application data, and output length. It is only defined for 3248 255 iterations so it may produce up to 5100 bytes of key material. 3250 For the purposes of this specification the secret is taken as the 3251 EMSK, the label is the key label described above concatenated with a 3252 NUL byte, the application data is also described above and the output 3253 length is two bytes. The application data is optional and may not be 3254 used by some applications. The KDF is based on HMAC-SHA1 [RFC2104] 3255 [SHA1]. For this specification we have: 3257 KDF (K,L,D,O) = T1 | T2 | T3 | T4 | ... 3259 where: 3260 T1 = prf (K, S | 0x01) 3261 T2 = prf (K, T1 | S | 0x02) 3262 T3 = prf (K, T2 | S | 0x03) 3263 T4 = prf (K, T3 | S | 0x04) 3265 prf = HMAC-SHA1 3266 K = EMSK 3267 L = key label 3268 D = application data 3269 O = OutputLength (2 bytes) 3270 S = L | " " | D | O 3272 The prf+ construction was chosen because of its simplicity and 3273 efficiency over other PRFs such as those used in [TLS]. The 3274 motivation for the design of this PRF is described in [SIGMA]. 3276 The NUL byte after the key label is used to avoid collisions if one 3277 key label is a prefix of another label (e.g. "foobar" and 3278 "foobarExtendedV2"). This is considered a simpler solution than 3279 requiring a key label assignment policy that prevents prefixes from 3280 occurring. 3282 Intellectual Property Statement 3284 The IETF takes no position regarding the validity or scope of any 3285 intellectual property or other rights that might be claimed to 3286 pertain to the implementation or use of the technology described in 3287 this document or the extent to which any license under such rights 3288 might or might not be available; neither does it represent that it 3289 has made any effort to identify any such rights. Information on the 3290 IETF's procedures with respect to rights in standards-track and 3291 standards- related documentation can be found in BCP-11. Copies of 3292 claims of rights made available for publication and any assurances of 3293 licenses to be made available, or the result of an attempt made to 3294 obtain a general license or permission for the use of such 3295 proprietary rights by implementors or users of this specification can 3296 be obtained from the IETF Secretariat. 3298 The IETF invites any interested party to bring to its attention any 3299 copyrights, patents or patent applications, or other proprietary 3300 rights which may cover technology that may be required to practice 3301 this standard. Please address the information to the IETF Executive 3302 Director. 3304 Full Copyright Statement 3306 Copyright (C) The Internet Society (2004). All Rights Reserved. 3308 This document and translations of it may be copied and furnished to 3309 others, and derivative works that comment on or otherwise explain it 3310 or assist in its implementation may be prepared, copied, published 3311 and distributed, in whole or in part, without restriction of any 3312 kind, provided that the above copyright notice and this paragraph are 3313 included on all such copies and derivative works. However, this 3314 document itself may not be modified in any way, such as by removing 3315 the copyright notice or references to the Internet Society or other 3316 Internet organizations, except as needed for the purpose of 3317 developing Internet standards in which case the procedures for 3318 copyrights defined in the Internet Standards process must be 3319 followed, or as required to translate it into languages other than 3320 English. The limited permissions granted above are perpetual and 3321 will not be revoked by the Internet Society or its successors or 3322 assigns. This document and the information contained herein is 3323 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 3324 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 3325 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 3326 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3327 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3329 Open Issues 3331 Open issues relating to this specification are tracked on the 3332 following web site: 3334 http://www.drizzle.com/~aboba/EAP/eapissues.html 3336 Expiration Date 3338 This memo is filed as , and expires 3339 January 5, 2005.