idnits 2.17.1 draft-ietf-eap-keying-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 3220. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 3226), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 39. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(A) Disclaimer.) ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(B) IPR Disclosure Invitation.) ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 69 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 70 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 43 instances of too long lines in the document, the longest one being 10 characters in excess of 72. ** The abstract seems to contain references ([RFC3748]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 392 has weird spacing: '...enerate fresh...' == Line 1899 has weird spacing: '...ude the key s...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 1815 -- Looks like a reference, but probably isn't: '2' on line 1818 -- Looks like a reference, but probably isn't: '3' on line 1824 -- Looks like a reference, but probably isn't: '4' on line 1024 -- Looks like a reference, but probably isn't: '5' on line 437 == Missing Reference: 'IEEE802.11i' is mentioned on line 3088, but not defined == Missing Reference: 'RFC 3748' is mentioned on line 1336, but not defined == Missing Reference: 'RFC3759' is mentioned on line 1565, but not defined == Missing Reference: 'RFC3784' is mentioned on line 1798, but not defined ** Obsolete undefined reference: RFC 3784 (Obsoleted by RFC 5305) == Missing Reference: 'RFC3162' is mentioned on line 2185, but not defined == Missing Reference: 'ServiceIdent' is mentioned on line 2190, but not defined == Missing Reference: 'ECP' is mentioned on line 2761, but not defined == Unused Reference: 'RFC2434' is defined on line 2510, but no explicit reference was found in the text == Unused Reference: 'RFC0793' is defined on line 2520, but no explicit reference was found in the text == Unused Reference: 'RFC2104' is defined on line 2529, but no explicit reference was found in the text == Unused Reference: 'RFC2401' is defined on line 2536, but no explicit reference was found in the text == Unused Reference: 'RFC3079' is defined on line 2568, but no explicit reference was found in the text == Unused Reference: 'IEEE-802' is defined on line 2601, but no explicit reference was found in the text == Unused Reference: 'IEEE-02-758' is defined on line 2640, but no explicit reference was found in the text == Unused Reference: 'IEEE-03-084' is defined on line 2646, but no explicit reference was found in the text == Unused Reference: 'IEEE-03-155' is defined on line 2653, but no explicit reference was found in the text == Unused Reference: '8021XHandoff' is defined on line 2679, 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 (-16) exists of draft-arkko-pppext-eap-aka-15 Summary: 13 errors (**), 0 flaws (~~), 25 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 EAP Working Group Bernard Aboba 3 INTERNET-DRAFT Dan Simon 4 Category: Standards Track Microsoft 5 J. Arkko 6 1 April 2005 Ericsson 7 P. Eronen 8 Nokia 9 H. Levkowetz, Ed. 10 ipUnplugged 12 Extensible Authentication Protocol (EAP) Key Management Framework 14 By submitting this Internet-Draft, I certify that any applicable 15 patent or other IPR claims of which I am aware have been disclosed, 16 and any of which I become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on November 22, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). All Rights Reserved. 41 Abstract 43 The Extensible Authentication Protocol (EAP), defined in [RFC3748], 44 enables extensible network access authentication. This document 45 provides a framework for the generation, transport and usage of 46 keying material generated by EAP authentication algorithms, known as 47 "methods". It also specifies the EAP key hierarchy. 49 Table of Contents 51 1. Introduction .......................................... 4 52 1.1 Requirements Language ........................... 4 53 1.2 Terminology ..................................... 4 54 1.3 Overview ........................................ 5 55 1.4 EAP Invariants .................................. 11 56 2. Key Derivation ........................................ 13 57 2.1 Key Terminology ................................. 13 58 2.2 Key Hierarchy ................................... 15 59 2.3 AAA-Key Derivation .............................. 19 60 2.4 Key Naming ...................................... 20 61 3. Security associations ................................. 22 62 3.1 EAP Method SA ................................... 23 63 3.2 EAP-Key SA ...................................... 24 64 3.3 AAA SA(s) ....................................... 24 65 3.4 Service SA(s) ................................... 24 66 4. Key Management ........................................ 27 67 4.1 Key Caching ..................................... 28 68 4.2 Parent-Child Relationships ...................... 29 69 4.3 Local Key Lifetimes ............................. 29 70 4.4 Exported and Calculated Key Lifetimes ........... 30 71 4.5 Key Cache Synchronization ....................... 31 72 4.6 Key Scope ....................................... 32 73 4.7 Key Strength .................................... 33 74 4.8 Key Wrap ........................................ 34 75 5. Handoff Vulnerabilities ............................... 35 76 5.1 Authorization ................................... 35 77 5.2 Correctness ..................................... 36 78 6. Security Considerations .............................. 39 79 6.1 Security Terminology ............................ 39 80 6.2 Threat Model .................................... 39 81 6.3 Security Analysis ............................... 41 82 6.4 Man-in-the-middle Attacks ....................... 44 83 6.5 Denial of Service Attacks ....................... 45 84 6.6 Impersonation ................................... 45 85 6.7 Channel Binding ................................. 46 87 7. Security Requirements ................................. 47 88 7.1 EAP Method Requirements ......................... 47 89 7.2 AAA Protocol Requirements ....................... 50 90 7.3 Secure Association Protocol Requirements ........ 51 91 7.4 Ciphersuite Requirements ........................ 53 92 8. IANA Considerations ................................... 54 93 9. References ............................................ 54 94 9.1 Normative References ............................ 54 95 9.2 Informative References .......................... 54 96 Acknowledgments .............................................. 58 97 Author's Addresses ........................................... 58 98 Appendix A - Ciphersuite Keying Requirements ................. 60 99 Appendix B - Example Transient EAP Key (TEK) Hierarchy ....... 61 100 Appendix C - EAP-TLS Key Hierarchy ........................... 62 101 Appendix D - Example Transient Session Key (TSK) Derivation .. 64 102 Appendix E - Key Names and Scope in Existing Methods ......... 65 103 Appendix F - Security Association Examples ................... 66 104 Intellectual Property Statement .............................. 69 105 Disclaimer of Validity ....................................... 70 106 Copyright Statement .......................................... 70 108 1. Introduction 110 The Extensible Authentication Protocol (EAP), defined in [RFC3748], 111 was designed to enable extensible authentication for network access 112 in situations in which the IP protocol is not available. Originally 113 developed for use with PPP [RFC1661], it has subsequently also been 114 applied to IEEE 802 wired networks [IEEE-802.1X]. 116 This document provides a framework for the generation, transport and 117 usage of keying material generated by EAP authentication algorithms, 118 known as "methods". In EAP keying material is generated by EAP 119 methods. Part of this keying material may be used by EAP methods 120 themselves and part of this material may be exported. The exported 121 keying material may be transported by AAA protocols or transformed by 122 Secure Association Protocols into session keys which are used by 123 lower layer ciphersuites. This document describes each of these 124 elements and provides a system-level security analysis. It also 125 specifies the EAP key hierarchy. 127 1.1. Requirements Language 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in BCP 14 [RFC2119]. 133 1.2. Terminology 135 This document frequently uses the following terms: 137 authenticator 138 The end of the link initiating EAP authentication. The term 139 Authenticator is used in [IEEE-802.1X], and authenticator has the 140 same meaning in this document. 142 peer The end of the link that responds to the authenticator. In 143 [IEEE-802.1X], this end is known as the Supplicant. 145 Supplicant 146 The end of the link that responds to the authenticator in 147 [IEEE-802.1X]. In this document, this end of the link is called 148 the peer. 150 backend authentication server 151 A backend authentication server is an entity that provides an 152 authentication service to an authenticator. When used, this server 153 typically executes EAP methods for the authenticator. This 154 terminology is also used in [IEEE-802.1X]. 156 AAA Authentication, Authorization and Accounting. AAA protocols with 157 EAP support include RADIUS [RFC3579] and Diameter [I-D.ietf-aaa- 158 eap]. In this document, the terms "AAA server" and "backend 159 authentication server" are used interchangeably. 161 EAP server 162 The entity that terminates the EAP authentication method with the 163 peer. In the case where no backend authentication server is used, 164 the EAP server is part of the authenticator. In the case where the 165 authenticator operates in pass-through mode, the EAP server is 166 located on the backend authentication server. 168 security association 169 A set of policies and cryptographic state used to protect 170 information. Elements of a security association may include 171 cryptographic keys, negotiated ciphersuites and other parameters, 172 counters, sequence spaces, authorization attributes, etc. 174 1.3. Overview 176 EAP is typically deployed in order to support extensible network 177 access authentication in situations where a peer desires network 178 access via one or more authenticators. Since both the peer and 179 authenticator may have more than one physical or logical port, a 180 given peer may simultaneously access the network via multiple 181 authenticators, or via multiple physical or logical ports on a given 182 authenticator. Similarly, an authenticator may offer network access 183 to multiple peers, each via a separate physical or logical port. The 184 situation is illustrated in Figure 1. 186 Where authenticators are deployed standalone, the EAP conversation 187 occurs between the peer and authenticator, and the authenticator must 188 locally implement an EAP method acceptable to the peer. However, one 189 of the advantages of EAP is that it enables deployment of new 190 authentication methods without requiring development of new code on 191 the authenticator. While the authenticator may implement some EAP 192 methods locally and use those methods to authenticate local users, it 193 may at the same time act as a pass-through for other users and 194 methods, forwarding EAP packets back and forth between the backend 195 authentication server and the peer. 197 This is accomplished by encapsulating EAP packets within the 198 Authentication, Authorization and Accounting (AAA) protocol, spoken 199 between the authenticator and backend authentication server. AAA 200 protocols supporting EAP include RADIUS [RFC3579] and Diameter [I- 201 D.ietf-aaa-eap]. 203 +-+-+-+-+ 204 | | 205 | EAP | 206 | Peer | 207 | | 208 +-+-+-+-+ 209 | | | Peer Ports 210 / | \ 211 / | \ 212 / | \ 213 / | \ 214 / | \ 215 / | \ 216 / | \ 217 / | \ 218 | | | | | | | | | Authenticator Ports 219 +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ 220 | | | | | | 221 | Auth. | | Auth. | | Auth. | 222 | | | | | | 223 +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ 224 \ | / 225 \ | / 226 \ | / 227 EAP over AAA \ | / 228 (optional) \ | / 229 \ | / 230 \ | / 231 \ | / 232 +-+-+-+-+ 233 | | 234 | AAA | 235 |Server | 236 | | 237 +-+-+-+-+ 239 Figure 1: Relationship between peer, authenticator and backend server 241 Where EAP key derivation is supported, the conversation between the 242 peer and the authenticator typically takes place in three phases: 244 Phase 0: Discovery 245 Phase 1: Authentication 246 1a: EAP authentication 247 1b: AAA-Key Transport (optional) 248 Phase 2: Secure Association Establishment 249 2a: Unicast Secure Association 250 2b: Multicast Secure Association (optional) 252 In the discovery phase (phase 0), peers locate authenticators and 253 discover their capabilities. For example, a peer may locate an 254 authenticator providing access to a particular network, or a peer may 255 locate an authenticator behind a bridge with which it desires to 256 establish a Secure Association. 258 The authentication phase (phase 1) may begin once the peer and 259 authenticator discover each other. This phase always includes EAP 260 authentication (phase 1a). Where the chosen EAP method supports key 261 derivation, in phase 1a keying material is derived on both the peer 262 and the EAP server. This keying material may be used for multiple 263 purposes, including protection of the EAP conversation and subsequent 264 data exchanges. 266 An additional step (phase 1b) is required in deployments which 267 include a backend authentication server, in order to transport keying 268 material (known as the AAA-Key) from the backend authentication 269 server to the authenticator. 271 A Secure Association exchange (phase 2) then occurs between the peer 272 and authenticator in order to manage the creation and deletion of 273 unicast (phase 2a) and multicast (phase 2b) security associations 274 between the peer and authenticator. 276 The conversation phases and relationship between the parties is shown 277 in Figure 2. 279 EAP peer Authenticator Auth. Server 280 -------- ------------- ------------ 281 |<----------------------------->| | 282 | Discovery (phase 0) | | 283 |<----------------------------->|<----------------------------->| 284 | EAP auth (phase 1a) | AAA pass-through (optional) | 285 | | | 286 | |<----------------------------->| 287 | | AAA-Key transport | 288 | | (optional; phase 1b) | 289 |<----------------------------->| | 290 | Unicast Secure association | | 291 | (phase 2a) | | 292 | | | 293 |<----------------------------->| | 294 | Multicast Secure association | | 295 | (optional; phase 2b) | | 296 | | | 298 Figure 2: Conversation Overview 300 1.3.1. Discovery Phase 302 In the discovery phase (phase 0), the EAP peer and authenticator 303 locate each other and discover each other's capabilities. Discovery 304 can occur manually or automatically, depending on the lower layer 305 over which EAP runs. Since authenticator discovery is handled 306 outside of EAP, there is no need to provide this functionality within 307 EAP. 309 For example, where EAP runs over PPP, the EAP peer might be 310 configured with a phone book providing phone numbers of 311 authenticators and associated capabilities such as supported rates, 312 authentication protocols or ciphersuites. In contrast, PPPoE 313 [RFC2516] provides support for a Discovery Stage to allow a peer to 314 identify the Ethernet MAC address of one or more authenticators and 315 establish a PPPoE SESSION_ID. 317 IEEE 802.11 [IEEE-802.11] also provides integrated discovery support 318 utilizing Beacon and/or Probe Request/Response frames, allowing the 319 peer (known as the station or STA) to determine the MAC address and 320 capabilities of one or more authenticators (known as Access Point or 321 APs). 323 1.3.2. Authentication Phase 325 Once the peer and authenticator discover each other, they exchange 326 EAP packets. Typically, the peer desires access to the network, and 327 the authenticators provide that access. In such a situation, access 328 to the network can be provided by any authenticator attaching to the 329 desired network, and the EAP peer is typically willing to send data 330 traffic through any authenticator that can demonstrate that it is 331 authorized to provide access to the desired network. 333 An EAP authenticator may handle the authentication locally, or it may 334 act as a pass-through to a backend authentication server. In the 335 latter case the EAP exchange occurs between the EAP peer and a 336 backend authenticator server, with the authenticator forwarding EAP 337 packets between the two. The entity which terminates EAP 338 authentication with the peer is known as the EAP server. Where pass- 339 through is supported, the backend authentication server functions as 340 the EAP server; where authentication occurs locally, the EAP server 341 is the authenticator. Where a backend authentication server is 342 present, at the successful completion of an authentication exchange, 343 the AAA-Key is transported to the authenticator (phase 1b). 345 EAP may also be used when it is desired for two network devices (e.g. 346 two switches or routers) to authenticate each other, or where two 347 peers desire to authenticate each other and set up a secure 348 association suitable for protecting data traffic. 350 Some EAP methods exist which only support one-way authentication; 351 however, EAP methods deriving keys are required to support mutual 352 authentication. In either case, it can be assumed that the parties 353 do not utilize the link to exchange data traffic unless their 354 authentication requirements have been met. For example, a peer 355 completing mutual authentication with an EAP server will not send 356 data traffic over the link until the EAP server has authenticated 357 successfully to the peer, and a Secure Association has been 358 negotiated. 360 Since EAP is a peer-to-peer protocol, an independent and simultaneous 361 authentication may take place in the reverse direction. Both peers 362 may act as authenticators and authenticatees at the same time. 364 Successful completion of EAP authentication and key derivation by a 365 peer and EAP server does not necessarily imply that the peer is 366 committed to joining the network associated with an EAP server. 367 Rather, this commitment is implied by the creation of a security 368 association between the EAP peer and authenticator, as part of the 369 Secure Association Protocol (phase 2). As a result, EAP may be used 370 for "pre-authentication" in situations where it is necessary to pre- 371 establish EAP security associations in order to decrease handoff or 372 roaming latency. 374 1.3.3. Secure Association Phase 376 The Secure Association phase (phase 2), if it occurs, begins after 377 the completion of EAP authentication (phase 1a) and key transport 378 (phase 1b). A Secure Association Protocol used with EAP typically 379 supports the following features: 381 [1] Generation of fresh transient session keys (TSKs). Where AAA-Key 382 caching is supported, the EAP peer may initiate a new session using 383 a AAA-Key that was used in a previous session. Were the TSKs to be 384 derived from a portion of the AAA-Key, this would result in reuse 385 of the session keys which could expose the underlying ciphersuite 386 to attack. 388 As a result, where AAA-Key caching is supported, the Secure 389 Association Protocol phase is REQUIRED, and MUST provide for 390 freshness of the TSKs. This is typically handled via the exchange 391 of nonces or counters, which are then mixed with the AAA-Key in 392 order to generate fresh unicast (phase 2a) and possibly multicast 393 (phase 2b) session keys. By not using the AAA-Key directly to 394 protect data, the Secure Association Protocol protects against 395 compromise of the AAA-Key. 397 [2] Entity Naming. A basic feature of a Secure Association Protocol is 398 the explicit naming of the parties engaged in the exchange. 399 Explicit identification of the parties is critical, since without 400 this the parties engaged in the exchange are not identified and the 401 scope of the transient session keys (TSKs) generated during the 402 exchange is undefined. As illustrated in Figure 1, both the peer 403 and NAS may have more than one physical or virtual port, so that 404 port identifiers are NOT RECOMMENDED as a naming mechanism. 406 [3] Secure capabilities negotiation. This includes the secure 407 negotiation of usage modes, session parameters (such as key 408 lifetimes), ciphersuites and required filters, including 409 confirmation of the capabilities discovered during phase 0. It is 410 RECOMMENDED that the Secure Association Protocol support secure 411 capabilities negotiation, in order to protect against spoofing 412 during the discovery phase, and to ensure agreement between the 413 peer and authenticator about how data is to be secured. 415 [4] Key management. EAP as defined in [RFC3748] supports key 416 derivation, but not key management. While EAP methods may derive 417 keying material, EAP does provide for the management of exported or 418 derived keys. For example, EAP does not support negotiation of the 419 key lifetime of exported or derived keys, nor does it support 420 rekey. Although EAP methods may support "fast reconnect" as 421 defined in [RFC3748] Section 7.2.1, rekey of exported keys cannot 422 occur without reauthentication. In order to provide method 423 independence, key management of exported or derived keys SHOULD NOT 424 be provided within EAP methods. 426 Since neither EAP nor EAP methods provide key management support, 427 it is RECOMMENDED that key management facilities be provided within 428 the Secure Association Protocol. This includes key lifetime 429 management (such as via explicit key lifetime negotiation, or 430 seamless rekey), as well synchronization of the installation and 431 deletion of keys so as to enable recovery from partial or complete 432 loss of key state by the peer or authenticator. Since key 433 management requires a key naming scheme, Secure Association 434 Protocols supporting key management support MUST also support key 435 naming. 437 [5] Mutual proof of possession of the AAA-Key. The Secure Association 438 Protocol MUST demonstrate mutual proof of posession of the AAA-Key, 439 in order to show that both the peer and authenticator have been 440 authenticated and authorized by the backend authentication server. 441 Since mutual proof of possession is not the same as mutual 442 authentication, the peer cannot verify authenticator assertions 443 (including the authenticator identity) as a result of this 444 exchange. 446 1.4. EAP Invariants 448 Certain basic characteristics, known as the "EAP Invariants" hold 449 true for EAP implementations on all media: 451 Media independence 452 Method independence 453 Ciphersuite independence 455 1.4.1. Media Independence 457 One of the goals of EAP is to allow EAP methods to function on any 458 lower layer meeting the criteria outlined in [RFC3748], Section 3.1. 459 For example, as described in [RFC3748], EAP authentication can be run 460 over PPP [RFC1661], IEEE 802 wired networks [IEEE-802.1X], and IEEE 461 802.11 wireless LANs [IEEE-802.11i]. 463 In order to maintain media independence, it is necessary for EAP to 464 avoid inclusion of media-specific elements. For example, EAP methods 465 cannot be assumed to have knowledge of the lower layer over which 466 they are transported, and cannot utilize identifiers associated with 467 a particular usage environment (e.g. MAC addresses). 469 The need for media independence has also motivated the development of 470 the three phase exchange. Since discovery is typically media- 471 specific, this function is handled outside of EAP, rather than being 472 incorporated within it. Similarly, the Secure Association Protocol 473 often contains media dependencies such as negotiation of media- 474 specific ciphersuites or session parameters, and as a result this 475 functionality also cannot be incorporated within EAP. 477 Note that media independence may be retained within EAP methods that 478 support channel binding or method-specific identification. An EAP 479 method need not be aware of the content of an identifier in order to 480 use it. This enables an EAP method to use media-specific identifiers 481 such as MAC addresses without compromising media independence. To 482 support channel binding, an EAP method can pass binding parameters to 483 the AAA server in the form of an opaque blob, and receive 484 confirmation of whether the parameters match, without requiring 485 media-specific knowledge. 487 1.4.2. Method Independence 489 By enabling pass-through, authenticators can support any method 490 implemented on the peer and server, not just locally implemented 491 methods. This allows the authenticator to avoid implementing code 492 for each EAP method required by peers. In fact, since a pass-through 493 authenticator is not required to implement any EAP methods at all, it 494 cannot be assumed to support any EAP method-specific code. 496 As a result, as noted in [RFC3748], authenticators must by default be 497 capable of supporting any EAP method. Since the Discovery and Secure 498 Association exchanges are also method independent, an authenticator 499 can carry out the three phase exchange without having an EAP method 500 in common with the peer. 502 This is useful where there is no single EAP method that is both 503 mandatory-to-implement and offers acceptable security for the media 504 in use. For example, the [RFC3748] mandatory-to-implement EAP method 505 (MD5-Challenge) does not provide dictionary attack resistance, mutual 506 authentication or key derivation, and as a result is not appropriate 507 for use in wireless LAN authentication [RFC4017]. However, despite 508 this it is possible for the peer and authenticator to interoperate as 509 long as a suitable EAP method is supported on the EAP server. 511 1.4.3. Ciphersuite Independence 513 While EAP methods may negotiate the ciphersuite used in protection of 514 the EAP conversation, the ciphersuite used for the protection of the 515 data exchanged after EAP authentication has completed is negotiated 516 between the peer and authenticator out-of-band of EAP. Since 517 ciphersuite negotiation is assumed to occur out-of-band, there is no 518 need for ciphersuite negotiation within EAP. Since ciphersuite 519 negotiation occurs outside of EAP, EAP methods generate keying 520 material that is ciphersuite-independent. 522 For example, within PPP, the ciphersuite is negotiated within the 523 Encryption Control Protocol (ECP) defined in [RFC1968], after EAP 524 authentication is completed. Within [IEEE-802.11i], the AP 525 ciphersuites are advertised in the Beacon and Probe Responses prior 526 to EAP authentication, and are securely verified during a 4-way 527 handshake exchange after EAP authentication has completed. 529 Advantages of ciphersuite-independence include: 531 Reduced update requirements 532 If EAP methods were to specify how to derive transient session keys 533 for each ciphersuite, they would need to be updated each time a new 534 ciphersuite is developed. In addition, backend authentication 535 servers might not be usable with all EAP-capable authenticators, 536 since the backend authentication server would also need to be 537 updated each time support for a new ciphersuite is added to the 538 authenticator. 540 Reduced EAP method complexity 541 Requiring each EAP method to include ciphersuite-specific code for 542 transient session key derivation would increase method complexity 543 and result in duplicated effort. 545 Simplified configuration 546 The ciphersuite is negotiated between the peer and authenticator 547 out-of-band of EAP. The backend authentication server is neither a 548 party to this negotiation, nor is it an intermediary in the data 549 flow between the EAP peer and authenticator. The backend 550 authentication server may not have knowledge of the ciphersuites 551 and negotiation policies implemented by the peer and authenticator, 552 or be aware of the ciphersuite negotiated between them. This 553 simplifies the configuration of the backend authentication server. 554 For example, since ECP negotiation occurs after authentication, 555 when run over PPP, the EAP peer, authenticator and backend 556 authentication server may not anticipate the negotiated ciphersuite 557 and therefore this information cannot be provided to the EAP 558 method. 560 2. Key Derivation 562 2.1. Key Terminology 564 The EAP Key Hierarchy makes use of the following types of keys: 566 Long Term Credential 567 EAP methods frequently make use of long term secrets in order to 568 enable authentication between the peer and server. In the case of 569 a method based on pre-shared key authentication, the long term 570 credential is the pre-shared key. In the case of a public-key 571 based method, the long term credential is the corresponding private 572 key. 574 Master Session Key (MSK) 575 Keying material that is derived between the EAP peer and server and 576 exported by the EAP method. The MSK is at least 64 octets in 577 length. 579 Extended Master Session Key (EMSK) 580 Additional keying material derived between the peer and server that 581 is exported by the EAP method. The EMSK is at least 64 octets in 582 length, and is never shared with a third party. 584 AAA-Key 585 A key derived by the peer and EAP server, used by the peer and 586 authenticator in the derivation of Transient Session Keys (TSKs). 587 Where a backend authentication server is present, the AAA-Key is 588 transported from the backend authentication server to the 589 authenticator, wrapped within the AAA-Token; it is therefore known 590 by the peer, authenticator and backend authentication server. 591 Despite the name, the AAA-Key is computed regardless of whether a 592 backend authentication server is present. AAA-Key derivation is 593 discussed in Section 2.3; in existing implementations the MSK is 594 used as the AAA-Key. 596 AAA-Token 597 Where a backend server is present, the AAA-Key and one or more 598 attributes is transported between the backend authentication server 599 and the authenticator within a package known as the AAA-Token. The 600 format and wrapping of the AAA-Token, which is intended to be 601 accessible only to the backend authentication server and 602 authenticator, is defined by the AAA protocol. Examples include 603 RADIUS [RFC2548] and Diameter [I-D.ietf-aaa-eap]. 605 Initialization Vector (IV) 606 A quantity of at least 64 octets, suitable for use in an 607 initialization vector field, that is derived between the peer and 608 EAP server. Since the IV is a known value in methods such as EAP- 609 TLS [RFC2716], it cannot be used by itself for computation of any 610 quantity that needs to remain secret. As a result, its use has 611 been deprecated and EAP methods are not required to generate it. 612 However, when it is generated it MUST be unpredictable. 614 Pairwise Master Key (PMK) 615 The AAA-Key is divided into two halves, the "Peer to Authenticator 616 Encryption Key" (Enc-RECV-Key) and "Authenticator to Peer 617 Encryption Key" (Enc-SEND-Key) (reception is defined from the point 618 of view of the authenticator). Within [IEEE-802.11i] Octets 0-31 619 of the AAA-Key (Enc-RECV-Key) are known as the Pairwise Master Key 620 (PMK). In [IEEE-802.11i] the TKIP and AES CCMP ciphersuites derive 621 their Transient Session Keys (TSKs) solely from the PMK, whereas 622 the WEP ciphersuite as noted in [RFC3580], derives its TSKs from 623 both halves of the AAA-Key. 625 Transient EAP Keys (TEKs) 626 Session keys which are used to establish a protected channel 627 between the EAP peer and server during the EAP authentication 628 exchange. The TEKs are appropriate for use with the ciphersuite 629 negotiated between EAP peer and server for use in protecting the 630 EAP conversation. Note that the ciphersuite used to set up the 631 protected channel between the EAP peer and server during EAP 632 authentication is unrelated to the ciphersuite used to subsequently 633 protect data sent between the EAP peer and authenticator. An 634 example TEK key hierarchy is described in Appendix C. 636 Transient Session Keys (TSKs) 637 Session keys used to protect data exchanged between the peer and 638 the authenticator after the EAP authentication has successfully 639 completed. TSKs are appropriate for the lower layer ciphersuite 640 negotiated between the EAP peer and authenticator. Examples of TSK 641 derivation are provided in Appendix D. 643 2.2. Key Hierarchy 645 The EAP Key Hierarchy, illustrated in Figure 3, has at the root the 646 long term credential utilized by the selected EAP method. If 647 authentication is based on a pre-shared key, the parties store the 648 EAP method to be used and the pre-shared key. The EAP server also 649 stores the peer's identity and/or other information necessary to 650 decide whether access to some service should be granted. The peer 651 stores information necessary to choose which secret to use for which 652 service. 654 If authentication is based on proof of possession of the private key 655 corresponding to the public key contained within a certificate, the 656 parties store the EAP method to be used and the trust anchors used to 657 validate the certificates. The EAP server also stores the peer's 658 identity and/or other information necessary to decide whether access 659 to some service should be granted. The peer stores information 660 necessary to choose which certificate to use for which service. 662 Based on the long term credential established between the peer and 663 the server, EAP derives two types of keys: 665 [1] Keys calculated locally by the EAP method but not exported 666 by the EAP method, such as the TEKs. 667 [2] Keys exported by the EAP method: MSK, EMSK, IV 669 From the keys exported by the EAP method, two other types of keys may 670 be derived: 672 [3] Keys calculated from exported quantities: AAA-Key. 673 [4] Keys calculated by the Secure Association Protocol from the 674 AAA-Key: TSKs. 676 In order to protect the EAP conversation, methods supporting key 677 derivation typically negotiate a ciphersuite and derive Transient EAP 678 Keys (TEKs) for use with that ciphersuite. The TEKs are stored 679 locally by the EAP method and are not exported. 681 As noted in [RFC3748] Section 7.10, EAP methods generating keys are 682 required to calculate and export the MSK and EMSK, which must be at 683 least 64 octets in length. EAP methods also may export the IV; 684 however, the use of the IV is deprecated. On both the peer and EAP 685 server, the exported MSK is utilized in order to calculate the AAA- 686 Key, as described in Section 2.3. Where a backend authentication 687 server is present, the AAA-Key is transported from the backend 688 authentication server to the authenticator within the AAA-Token, 689 using the AAA protocol. 691 Once EAP authentication completes and is successful, the peer and 692 authenticator obtain the AAA-Key and the Secure Association Protocol 693 is run between the peer and authenticator in order to securely 694 negotiate the ciphersuite, derive fresh TSKs used to protect data, 695 and provide mutual proof of possession of the AAA-Key. 697 When the authenticator acts as an endpoint of the EAP conversation 698 rather than a pass-through, EAP methods are implemented on the 699 authenticator as well as the peer. If the EAP method negotiated 700 between the EAP peer and authenticator supports mutual authentication 701 and key derivation, the EAP Master Session Key (MSK) and Extended 702 Master Session Key (EMSK) are derived on the EAP peer and 703 authenticator and exported by the EAP method. In this case, the MSK 704 and EMSK are known only to the peer and authenticator and no other 705 parties. The TEKs and TSKs also reside solely on the peer and 706 authenticator. This is illustrated in Figure 4. As demonstrated in 707 [I-D.ietf-roamops-cert], in this case it is still possible to support 708 roaming between providers, using certificate-based authentication. 710 Where a backend authentication server is utilized, the situation is 711 illustrated in Figure 5. Here the authenticator acts as a pass- 712 through between the EAP peer and a backend authentication server. In 713 this model, the authenticator delegates the access control decision 714 to the backend authentication server, which acts as a Key 715 Distribution Center (KDC). In this case, the authenticator 716 encapsulates EAP packet with a AAA protocol such as RADIUS [RFC3579] 717 or Diameter [I-D.ietf-aaa-eap], and forwards packets to and from the 718 backend authentication server, which acts as the EAP server. Since 719 the authenticator acts as a pass-through, EAP methods reside only on 720 the peer and EAP server As a result, the TEKs, MSK and EMSK are 721 derived on the peer and EAP server. 723 On completion of EAP authentication, EAP methods on the peer and EAP 724 server export the Master Session Key (MSK) and Extended Master 725 Session Key (EMSK). The peer and EAP server then calculate the AAA- 726 Key from the MSK and EMSK, and the backend authentication server 727 sends an Access-Accept to the authenticator, providing the AAA-Key 728 within a protected package known as the AAA-Token. 730 The AAA-Key is then used by the peer and authenticator within the 731 Secure Association Protocol to derive Transient Session Keys (TSKs) 732 required for the negotiated ciphersuite. The TSKs are known only to 733 the peer and authenticator. 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 736 | | ^ 737 | EAP Method | | 738 | | | 739 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | | 740 | | | | | | | 741 | | EAP Method Key |<->| Long-Term | | | 742 | | Derivation | | Credential | | | 743 | | | | | | | 744 | | | +-+-+-+-+-+-+-+ | Local to | 745 | | | | EAP | 746 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Method | 747 | | | | | | 748 | | | | | | 749 | | | | | | 750 | | | | | | 751 | V | | | | 752 | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | | 753 | | TEK | | MSK | |EMSK | |IV | | | 754 | |Derivation | |Derivation | |Derivation | |Derivation | | | 755 | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | | 756 | | | | | | 757 | | | | | V 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 759 | | | ^ 760 | | | | 761 | MSK (64B) | EMSK (64B) | IV (64B) | 762 | | | Exported| 763 | | | by | 764 | V V EAP v 765 | ---+ 766 | AAA-Key Transported | 767 | by AAA | 768 | Protocol | 769 V V 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 771 | | ^ 772 | TSK Derivation | Lower layer | 773 | [AAA-Key Cache] | Specific | 774 | | V 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 777 Figure 3: EAP Key Hierarchy 779 +-+-+-+-+-+ +-+-+-+-+-+ 780 | | | | 781 | | | | 782 | Cipher- | | Cipher- | 783 | Suite | | Suite | 784 | | | | 785 +-+-+-+-+-+ +-+-+-+-+-+ 786 ^ ^ 787 | | 788 | | 789 | | 790 V V 791 +-+-+-+-+-+ +-+-+-+-+-+ 792 | | | | 793 | |===============| | 794 | |EAP, TEK Deriv.|Authenti-| 795 | |<------------->| cator | 796 | | | | 797 | | Secure Assoc. | | 798 | peer |<------------->| (EAP | 799 | |===============| server) | 800 | | Link layer | | 801 | | (PPP,IEEE802) | | 802 | | | | 803 |MSK,EMSK | |MSK,EMSK | 804 | (TSKs) | | (TSKs) | 805 +-+-+-+-+-+ +-+-+-+-+-+ 806 ^ ^ 807 | | 808 | MSK, EMSK | MSK, EMSK 809 | | 810 | | 811 +-+-+-+-+-+ +-+-+-+-+-+ 812 | | | | 813 | EAP | | EAP | 814 | Method | | Method | 815 | | | | 816 | (TEKs) | | (TEKs) | 817 | | | | 818 +-+-+-+-+-+ +-+-+-+-+-+ 820 Figure 4: Relationship between EAP peer and authenticator (acting as 821 an EAP server), where no backend authentication server is present. 823 +-+-+-+-+-+ +-+-+-+-+-+ 824 | | | | 825 | | | | 826 | Cipher- | | Cipher- | 827 | Suite | | Suite | 828 | | | | 829 +-+-+-+-+-+ +-+-+-+-+-+ 830 ^ ^ 831 | | 832 | | 833 | | 834 V V 835 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 836 | |===============| |========| | 837 | |EAP, TEK Deriv.| | | | 838 | |<-------------------------------->| backend | 839 | | | |AAA-Key/| | 840 | | Secure Assoc. | | Name | | 841 | peer |<------------->|Authenti-|<-------| auth | 842 | |===============| cator |========| server | 843 | | Link Layer | | AAA | (EAP | 844 | | (PPP,IEEE 802)| |Protocol| server) | 845 | | | | | | 846 |MSK,EMSK | | MSK | |MSK,EMSK | 847 | (TSKs) | | (TSKs) | | | 848 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 849 ^ ^ 850 | | 851 | MSK, EMSK | MSK, EMSK 852 | | 853 | | 854 +-+-+-+-+-+ +-+-+-+-+-+ 855 | | | | 856 | EAP | | EAP | 857 | Method | | Method | 858 | | | | 859 | (TEKs) | | (TEKs) | 860 | | | | 861 +-+-+-+-+-+ +-+-+-+-+-+ 863 Figure 5: Pass-through relationship between EAP peer, authenticator 864 and backend authentication server. 866 2.3. AAA-Key Derivation 868 In existing usage, where a AAA-Key is generated as the result of a 869 successful EAP authentication with the authenticator, the AAA-Key is 870 based on the MSK: AAA-Key = MSK(0,63). 872 2.4. Key Naming 874 Each key created within the EAP key management framework has a name 875 (the identifier by which the key can be identified), as well as a 876 scope (the parties to whom the key is available). This section 877 describes how keys are named, and the scope within which that name 878 applies. 880 Session-Id 882 EAP methods supporting key naming MUST specify a temporally unique 883 method identifier known as the EAP Method-Id, which is typically 884 constructed from nonces or counters used within the exchange. Since 885 multiple EAP sessions may exist between an EAP peer and EAP server, 886 the Method-Id allows MSKs to be differentiated. 888 The concatenation of the EAP Type (expressed in ASCII text), ":" and 889 the Method-Id (also expressed in ASCII text) is known as the EAP 890 Session-Id. The inclusion of the Type in the EAP Session-Id ensures 891 that each EAP method has a distinct name space. 893 The EAP Session-Id uniquely identifies the EAP session to the EAP 894 peer and server terminating the EAP conversation. However, suitable 895 EAP peer and server names may not always be available. As described 896 in [RFC3748] Section 7.3, the identity provided in the EAP- 897 Response/Identity, may be different from the identity authenticated 898 by the EAP method, and as a result the EAP-Response/Identity is 899 unsuitable for determination of the peer identity. As a result, the 900 Session-Id scope is defined by the EAP peer name (if securely 901 exchanged within the method) concatenated with the EAP server name 902 (also only if securely exchanged). Where a peer or server name is 903 missing the null string is used. Since an EAP session is not bound 904 to a particular authentication or specific ports on the peer and 905 authenticator, the authenticator port or identity are not included in 906 the Session-Id scope. 908 The EAP Session-Id is exported by the EAP method along with the 909 Session-Id scope, if available, and is used to construct names for 910 other EAP keys. Note that the EAP Session-Id and scope are only 911 known by the EAP method. As a result, the format of the EAP Session- 912 Id and the definition of the Session-Id scope needs to be specified 913 within the method. Appendix E defines the EAP Session-Id and scope 914 provided by existing methods. 916 MSK Name 917 This key is created between the EAP peer and EAP server, and can be 918 referred to using the string "MSK:", concatenated with the EAP 919 Session-Id. As with the EAP Session-Id, the MSK scope is defined by 920 the EAP peer name (if securely exchanged within the method) and the 921 EAP server name (also only if securely exchanged). Where a peer or 922 server name is missing the null string is used. 924 EMSK Name 926 The EMSK can be referred to using the string "EMSK:", concatenated 927 with the EAP Session-Id. 929 As with the EAP Session-Id, the EMSK scope is defined by the EAP peer 930 name (if securely exchanged within the method) and the EAP server 931 name (also only if securely exchanged). Where a peer or server name 932 is missing the null string is used. 934 AAA-Key Name 936 In existing usage, the AAA-Key is always derived from the MSK so can 937 be referred to using the MSK name. 939 The AAA-Key scope is provided by the concatenation of the EAP peer 940 name (if securely provided to the authenticator), and the 941 authenticator name (if securely provided to the peer). 943 For the purpose of identifying the authenticator to the peer, the 944 value of the NAS-Identifier attribute is recommended. The 945 authenticator may include the NAS-Identifier attribute to the AAA 946 server in an Access-Request, and the authenticator may provide the 947 NAS-Identifier to the EAP peer. Mechanisms for this include use of 948 the EAP-Request/Identity (unsecured) or a lower layer mechanism (such 949 as the 802.11 Beacon/Probe Response). Where the NAS-Identifier is 950 provided by the authenticator to the peer a secure mechanism is 951 RECOMMENDED. 953 For the purpose of identifying the peer to the authenticator, the EAP 954 peer identifier provided within the EAP method is recommended. It 955 cannot be assumed that the authenticator is aware of the EAP peer 956 name used within the method. Therefore alternatives mechanisms need 957 to be used to provide the EAP peer name to the authenticator. For 958 example, the AAA server may include the EAP peer name in the User- 959 Name attribute of the Access-Accept or the peer may provide the 960 authenticator with its name via a lower layer mechanism. 962 Absent an explicit binding step within the Secure Association 963 Protocol, the AAA-Key is not bound to a specific peer or 964 authenticator port. As a result, the peer or authenticator port over 965 which the EAP conversation takes place is not included in the AAA-Key 966 scope. 968 PMK Name 970 This document does not specify a naming scheme for the PMK. The PMK 971 is only identified by the AAA-Key from which it is derived. 972 Similarly, the PMK scope is the same as the AAA-Key scope. 974 Note: IEEE 802.11i names the PMKID for the purposes of being able to 975 refer to it in the Secure Association protocol; this naming is based 976 on a hash of the PMK itself as well as some other parameters (see 977 Section 8.5.1.2 [IEEE-802.11i]). 979 TEKs 981 The TEKs may or may not be named. Their naming is specified in the 982 EAP method. Since the TEKs are only known by the EAP peer and 983 server, the TEK scope is the same as the Session-Id scope. 985 TSKs 987 The TSKs are typically named. Their naming is specified in the Secure 988 Association (phase 2) protocol, so that the correct set of transient 989 session keys can be identified for processing a given packet. The 990 scope of the TSKs is negotiated within the Secure Association 991 Protocol. 993 TSK creation and deletion operations are typically supported so that 994 establishment and re-establishment of TSKs can be synchronized 995 between the parties. 997 In order to avoid confusion in the case where an EAP peer has more 998 than one AAA-Key (phase 1b) applicable to establishment of a phase 2 999 security association, the secure Association protocol needs to 1000 utilize the AAA-Key name so that the appropriate phase 1b keying 1001 material can be identified for use in the Secure Association Protocol 1002 exchange. 1004 3. Security Associations 1006 During EAP authentication and subsequent exchanges, four types of 1007 security associations (SAs) are created: 1009 [1] EAP method SA. This SA is between the peer and EAP server. It 1010 stores state that can be used for "fast reconnect" or other 1011 functionality in some EAP methods. Not all EAP methods create such 1012 an SA. 1014 [2] EAP-Key SA. This is an SA between the peer and EAP server, which 1015 is used to store the keying material exported by the EAP method. 1016 Current EAP server implementations do not retain this SA after the 1017 EAP conversation completes. 1019 [3] AAA SA(s). These SAs are between the authenticator and the backend 1020 authentication server. They permit the parties to mutually 1021 authenticate each other and protect the communications between 1022 them. 1024 [4] Service SA(s). These SAs are between the peer and authenticator, 1025 and they are created as a result of phases 1-2 of the conversation 1026 (see Section 1.3). 1028 Examples of security associations are provided in Appendix F. 1030 3.1. EAP Method SA (peer - EAP server) 1032 An EAP method may store some state on the peer and EAP server even 1033 after phase 1a has completed. 1035 Typically, this is used for "fast reconnect": the peer and EAP server 1036 can confirm that they are still talking to the same party, perhaps 1037 using fewer round-trips or less computational power. In this case, 1038 the EAP method SA is essentially a cache for performance 1039 optimization, and either party may remove the SA from its cache at 1040 any point. 1042 An EAP method may also keep state in order to support pseudonym-based 1043 identity protection. This is typically a cache as well (the 1044 information can be recreated if the original EAP method SA is lost), 1045 but may be stored for longer periods of time. 1047 The EAP method SA is not restricted to a particular service or 1048 authenticator and is most useful when the peer accesses many 1049 different authenticators. An EAP method is responsible for 1050 specifying how the parties select if an existing EAP method SA should 1051 be used, and if so, which one. Where multiple backend authentication 1052 servers are used, EAP method SAs are not typically synchronized 1053 between them. 1055 EAP method implementations should consider the appropriate lifetime 1056 for the EAP method SA. "Fast reconnect" assumes that the information 1057 required (primarily the keys in the EAP method SA) hasn't been 1058 compromised. In case the original authentication was carried out 1059 using, for instance, a smart card, it may be easier to compromise the 1060 EAP method SA (stored on the PC, for instance), so typically the EAP 1061 method SAs have a limited lifetime. 1063 Contents: 1065 o Implicitly, the EAP method this SA refers to 1066 o Internal (non-exported) cryptographic state 1067 o EAP method SA name 1068 o SA lifetime 1070 3.2. EAP-Key SA 1072 This is an SA between the peer and EAP server, which is used to store 1073 the keying material exported by the EAP method. Current EAP server 1074 implementations do not retain this SA after the EAP conversation 1075 completes. As a result, all keys exported by the EAP method 1076 (including the MSK, EMSK and IV) on the AAA server are discarded and 1077 are not cached. Calculated keys (such as the AAA-Key) are also 1078 discarded and not cached. 1080 3.3. AAA SA(s) (authenticator - backend authentication server) 1082 In order for the authenticator and backend authentication server to 1083 authenticate each other, they need to store some information. 1085 In case the authenticator and backend authentication server are 1086 colocated, and they communicate using local procedure calls or shared 1087 memory, this SA need not necessarily contain any information. 1089 3.4. Service SA(s) (peer - authenticator) 1091 The service SAs store information about the service being provided. 1092 These include the Root service SA and derived unicast and multicast 1093 service SAs. 1095 The Root service SA is established as the result of the completion of 1096 EAP authentication (phase 1a) and AAA-Key derivation or transport 1097 (phase 1b). It includes: 1099 o Service parameters (or at least those parameters 1100 that are still needed) 1101 o On the authenticator, service authorization 1102 information received from the backend authentication 1103 server (or necessary parts of it) 1104 o On the peer, usually locally configured service 1105 authorization information. 1106 o The AAA-Key, if it can be needed again (to refresh 1107 and/or resynchronize other keys or for another reason) 1108 o AAA-Key lifetime 1110 Unicast and (optionally) multicast service SAs are derived from the 1111 Root service SA, via the Secure Association Protocol. In order for 1112 unicast and multicast service SAs and associated TSKs to be 1113 established, it is not necessary for EAP authentication (phase 1a) to 1114 be rerun each time. Instead, the Secure Association Protocol can be 1115 used to mutually prove possession of the AAA-Key and create 1116 associated unicast (phase 2a) and multicast (phase 2b) service SAs 1117 and TSKs, enabling the EAP exchange to be bypassed. Unicast and 1118 multicast service SAs include: 1120 o Service parameters negotiated by the Secure Association Protocol. 1121 o Endpoint identifiers. 1122 o Transient Session Keys used to protect the communication. 1123 o Transient Session Key lifetime. 1125 One function of the Secure Association Protocol is to bind the the 1126 unicast and multicast service SAs and TSKs to endpoint identifiers. 1127 For example, within [IEEE802.11i], the 4-way handshake binds the TSKs 1128 to the MAC addresses of the endpoints; in [IKEv2], the TSKs are bound 1129 to the IP addresses of the endpoints and the negotiated SPI. 1131 It is possible for more than one unicast or multicast service SA to 1132 be derived from a single Root service SA. However, a unicast or 1133 multicast service SA is always descended from only one Root service 1134 SA. Unicast or multicast service SAs descended from the same Root 1135 service SA may utilize the same security parameters (e.g. mode, 1136 ciphersuite, etc.) or they may utilize different parameters. 1138 An EAP peer may be able to negotiate multiple service SAs with a 1139 given authenticator, or may be able to maintain one or more service 1140 SAs with multiple authenticators, depending on the properties of the 1141 media. 1143 Except where explicitly specified by the Secure Association Protocol, 1144 it should not be assumed that the installation of new service SAs 1145 implies deletion of old service SAs. It is possible for multicast 1146 Root service SAs to between the same EAP peer and authenticator; 1147 during a re-key of a unicast or multicast service SA it is possible 1148 for two service SAs to exist during the period between when the new 1149 service SA and corresponding TSKs are calculated and when they are 1150 installed. 1152 Similarly, deletion or creation of a unicast or multicast service SA 1153 does not necessarily imply deletion or creation of related unicast or 1154 multicast service SAs, unless specified by the Secure Association 1155 protocol. For example, a unicast service SA may be rekeyed without 1156 implying a rekey of the multicast service SA. 1158 The deletion of the Root service SA does not necessarily imply the 1159 deletion of the derived unicast and multicast service SAs and 1160 associated TSKs. Failure to mutually prove possession of the AAA-Key 1161 during the Secure Association Protocol exchange need not be grounds 1162 for deletion of the AAA-Key by both parties; the action to be taken 1163 is defined by the Secure Association Protocol. 1165 3.4.1. Sharing service SAs 1167 A single service may be provided by multiple logical or physical 1168 service elements. Each service is responsible for specifying how 1169 changing service elements is handled. Some approaches include: 1171 Transparent sharing 1172 If the service parameters visible to the other party (either peer 1173 or authenticator) do not change, the service can be moved without 1174 requiring cooperation from the other party. 1176 Whether such a move should be supported or used depends on 1177 implementation and administrative considerations. For instance, an 1178 administrator may decide to configure a group of IKEv2/IPsec 1179 gateways in a cluster for high-availability purposes, if the 1180 implementation used supports this. The peer does not necessarily 1181 have any way of knowing when the change occurs. 1183 No sharing 1184 If the service parameters require changing, some changes may 1185 require terminating the old service, and starting a new 1186 conversation from phase 0. This approach is used by all services 1187 for at least some parameters, and it doesn't require any protocol 1188 for transferring the service SA between the service elements. 1190 The service may support keeping the old service element active 1191 while the new conversation takes phase, to decrease the time the 1192 service is not available. 1194 Some sharing 1195 The service may allow changing some parameters by simply agreeing 1196 about the new values. This may involve a similar exchange as in 1197 phase 2, or perhaps a shorter conversation. 1199 This option usually requires some protocol for transferring the 1200 service SA between the elements. An administrator may decide not to 1201 enable this feature at all, and typically the sharing is restricted 1202 to some particular service elements (defined either by a service 1203 parameter, or simple administrative decision). If the old and new 1204 service element do not support such "context transfer", this 1205 approach falls back to the previous option (no transfer). 1207 Services supporting this feature should also consider what changes 1208 require new authorization from the backend authentication server 1209 (see Section 4.2). 1211 Note that these considerations are not limited to service 1212 parameters related to the authenticator--they apply to peer 1213 parameters as well. 1215 4. Key Management 1217 EAP supports key derivation, but not key management. As a result, 1218 key management functionality needs to be provided by the Secure 1219 Association Protocol. This includes: 1221 [a] Generation of fresh transient session keys (TSKs). Where AAA-Key 1222 caching is supported, the EAP peer may initiate a new session using 1223 a AAA-Key that was used in a previous session. Were the TSKs to be 1224 derived from a portion of the AAA-Key, this would result in reuse 1225 of the session keys which could expose the underlying ciphersuite 1226 to attack. As a result, where AAA-Key caching is supported, the 1227 Secure Association Protocol phase is REQUIRED, and MUST provide for 1228 freshness of the TSKs. 1230 [b] Key lifetime determination. EAP does not support negotiation of 1231 key lifetimes, nor does it support rekey without reauthentication. 1232 As a result, the Secure Association Protocol may handle rekey and 1233 determination of the key lifetime. Where key caching is supported, 1234 secure negotiation of key lifetimes is RECOMMENDED. Lower layers 1235 that support rekey, but not key caching, may not require key 1236 lifetime negotiation. To take an example from IKE, the difference 1237 between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes were 1238 negotiated. In IKEv2, each end of the SA is responsible for 1239 enforcing its own lifetime policy on the SA and rekeying the SA 1240 when necessary. 1242 [c] Key resynchronization. It is possible for the peer or 1243 authenticator to reboot or reclaim resources, clearing portions or 1244 all of the key cache. Therefore, key lifetime negotiation cannot 1245 guarantee that the key cache will remain synchronized, and the peer 1246 may not be able to determine before attempting to use a AAA-Key 1247 whether it exists within the authenticator cache. It is therefore 1248 RECOMMENDED for the Secure Association Protocol to provide a 1249 mechanism for key state resynchronization. Since in this situation 1250 one or more of the parties initially do not possess a key with 1251 which to protect the resynchronization exchange, securing this 1252 mechanism may be difficult. 1254 [d] Key selection. Where key caching is supported, it may be possible 1255 for the EAP peer and authenticator to share more than one key of a 1256 given type. As a result, the Secure Association Protocol needs to 1257 support key selection, using the EAP Key Naming scheme described in 1258 this document. 1260 [e] Key scope determination. Since the Discovery phase is handled out- 1261 of-band, EAP does not provide a mechanism by which the peer can 1262 determine the authenticator identity. As a result, where the 1263 authenticator has multiple ports and AAA-Key caching is supported, 1264 the EAP peer may not be able to determine the scope of validity of 1265 a AAA-Key. Similarly, where the EAP peer has multiple ports, the 1266 authenticator may not be able to determine whether a peer has 1267 authorization to use a particular AAA-Key. To allow key scope 1268 determination, the lower layer SHOULD provide a mechanism by which 1269 the peer can determine the scope of the AAA-Key cache on each 1270 authenticator, and by which the authenticator can determine the 1271 scope of the AAA-Key cache on a peer. 1273 4.1. Key Caching 1275 In existing implementations, key caching may be supported on the EAP 1276 peer and authenticator but not on the backend server. Where 1277 explicitly supported by the lower layer, the EAP peer and 1278 authenticator MAY cache the AAA-Key and/or TSKs. The structure of 1279 the key cache on the peer and authenticator is defined by the lower 1280 layer. Unless specified by the lower layer, the EAP peer and 1281 authenticator MUST assume that peers and authenticators do not cache 1282 the AAA-Key or TSKs. 1284 In existing AAA server implementations, all keys exported by EAP 1285 methods (including the MSK, EMSK and IV) and calculated keys (e.g. 1286 AAA-Key) are not cached and are lost after EAP authentication 1287 completes: 1289 [1] In order to avoid key reuse, on the EAP server, transported keys 1290 are deleted once they are sent. An EAP server MUST NOT retain keys 1291 that it has previously sent to the authenticator. For example, an 1292 EAP server that has transported a AAA-Key based on the MSK MUST 1293 delete the MSK, and no keys may be derived from the MSK from that 1294 point forward by the server. 1296 [2] Keys which are not transported, such as the EMSK, are also deleted 1297 by existing implementations. 1299 4.2. Parent-Child Relationships 1301 When keying material exported by EAP methods expires, all keying 1302 material derived from the exported keying material expires, including 1303 the AAA-Key and TSKs. 1305 When an EAP reauthentication takes place, new keying material is 1306 derived and exported by the EAP method, which eventually results in 1307 replacement of calculated keys, including the AAA-Key and TSKs. 1309 As a result, while the lifetime of calculated keys can be less than 1310 or equal that of the exported keys they are derived from, it cannot 1311 be greater. For example, TSK rekey may occur prior to EAP 1312 reauthentication. 1314 Failure to mutually prove possession of the AAA-Key during the Secure 1315 Association Protocol exchange need not be grounds for deletion of the 1316 AAA-Key by both parties; rate-limiting Secure Association Protocol 1317 exchanges could be used to prevent a brute force attack. 1319 4.3. Local Key Lifetimes 1321 The Transient EAP Keys (TEKs) are session keys used to protect the 1322 EAP conversation. The TEKs are internal to the EAP method and are 1323 not exported. TEKs are typically created during an EAP conversation, 1324 used until the end of the conversation and then discarded. However, 1325 methods may rekey TEKs during a conversation. 1327 When using TEKs within an EAP conversation or across conversations, 1328 it is necessary to ensure that replay protection and key separation 1329 requirements are fulfilled. For instance, if a replay counter is 1330 used, TEK rekey MUST occur prior to wrapping of the counter. 1331 Similarly, TSKs MUST remain cryptographically separate from TEKs 1332 despite TEK rekeying or caching. This prevents TEK compromise from 1333 leading directly to compromise of the TSKs and vice versa. 1335 EAP methods may cache local keying material which may persist for 1336 multiple EAP conversations when fast reconnect is used [RFC 3748]. 1337 For example, EAP methods based on TLS (such as EAP-TLS [RFC2716]) 1338 derive and cache the TLS Master Secret, typically for substantial 1339 time periods. The lifetime of other local keying material calculated 1340 within the EAP method is defined by the method. Note that in 1341 general, when using fast reconnect, there is no guarantee to that the 1342 original long-term credentials are still in the possession of the 1343 peer. For instance, a card hold holding the private key for EAP-TLS 1344 may have been removed. EAP servers SHOULD also verify that the long- 1345 term credentials are still valid, such as by checking that 1346 certificate used in the original authentication has not yet expired. 1348 4.4. Exported and Calculated Key Lifetimes 1350 All EAP methods generating keys are required to generate the MSK and 1351 EMSK, and may optionally generate the IV. However, EAP, defined in 1352 [RFC3748], does not support the negotiation of lifetimes for exported 1353 keying material such as the MSK, EMSK and IV. 1355 Several mechanisms exist for managing key lifetimes: 1357 [a] AAA attributes. AAA protocols such as RADIUS [RFC2865] and 1358 Diameter [I-D.ietf-aaa-eap] support the Session-Timeout attribute. 1359 The Session-Timeout value represents the maximum lifetime of the 1360 exported keys, and all keys calculated from it, on the 1361 authenticator. Since existing AAA servers do not cache keys 1362 exported by EAP methods, or keys calculated from exported keys, the 1363 value of the Session-Timeout attribute has no bearing on the key 1364 lifetime within the AAA server. 1366 On the authenticator, where EAP is used for authentication, the 1367 Session-Timeout value represents the maximum session time prior to 1368 re-authentication, as described in [RFC3580]. Where EAP is used 1369 for pre-authentication, the session may not start until some future 1370 time, or may never occur. Nevertheless, the Session-Timeout value 1371 represents the time after which the AAA-Key, and all keys 1372 calculated from it, will have expired on the authenticator. If the 1373 session subsequently starts, re-authentication will be initiated 1374 once the Session-Time has expired. If the session never started, 1375 or started and ended, the AAA-Key and all keys calculated from it 1376 will be expired by the authenticator prior to the future time 1377 indicated by Session-Timeout. 1379 Since the TSK lifetime is often determined by authenticator 1380 resources, the AAA server has no insight into the TSK derivation 1381 process, and by the principle of ciphersuite independence, it is 1382 not appropriate for the AAA server to manage any aspect of the TSK 1383 derivation process, including the TSK lifetime. 1385 [b] Lower layer mechanisms. While AAA attributes can communicate the 1386 maximum exported key lifetime, this only serves to synchronize the 1387 key lifetime between the backend authentication server and the 1388 authenticator. Lower layer mechanisms such as the Secure 1389 Association Protocol can then be used to enable the lifetime of 1390 exported and calculated keys to be negotiated between the peer and 1391 authenticator. 1393 Where TSKs are established as the result of a Secure Association 1394 Protocol exchange, it is RECOMMENDED that the Secure Association 1395 Protocol include support for TSK resynchronization. Where the TSK 1396 is taken from the AAA-Key, there is no need to manage the TSK 1397 lifetime as a separate parameter, since the TSK lifetime and AAA- 1398 Key lifetime are identical. 1400 [c] System defaults. Where the EAP method does not support the 1401 negotiation of the exported key lifetime, and a key lifetime 1402 negotiation mechanism is not provided by the lower lower, there may 1403 be no way for the peer to learn the exported key lifetime. In this 1404 case it is RECOMMENDED that the peer assume a default value of the 1405 exported key lifetime; 8 hours is recommended. Similarly, the 1406 lifetime of calculated keys can also be managed as a system 1407 parameter on the authenticator. 1409 [d] Method specific negotiation within EAP. While EAP itself does not 1410 support lifetime negotiation, it would be possible to specify 1411 methods that do. However, systems that rely on such negotiation 1412 for exported keys would only function with these methods. As a 1413 result, it is NOT RECOMMENDED to use this approach as the sole way 1414 to determine key lifetimes. 1416 4.5. Key cache synchronization 1418 Issues arise when attempting to synchronize the key cache on the peer 1419 and authenticator. Lifetime negotiation alone cannot guarantee key 1420 cache synchronization. 1422 One problem is that the AAA protocol cannot guarantee synchronization 1423 of key lifetimes between the peer and authenticator. Where the 1424 Secure Association Protocol is not run immediately after EAP 1425 authentication, the exported and calculated key lifetimes will not be 1426 known by the peer during the hiatus. Where EAP pre-authentication 1427 occurs, this can leave the peer uncertain whether a subsequent 1428 attempt to use the exported keys will prove successful. 1430 However, even where the Secure Association Protocol is run 1431 immediately after EAP, it is still possible for the authenticator to 1432 reclaim resources if the created key state is not immediately 1433 utilized. 1435 The lower layer may utilize Discovery mechanisms to assist in this. 1436 For example, the authenticator manages the AAA-Key cache by deleting 1437 the oldest AAA-Key first (LIFO), the relative creation time of the 1438 last AAA-Key to be deleted could be advertised with the Discovery 1439 phase, enabling the peer to determine whether a given AAA-Key had 1440 been expired from the authenticator key cache prematurely. 1442 4.6. Key Scope 1444 As described in Section 2.3, in existing applications the AAA-Key is 1445 derived from the MSK by the EAP peer and server, and is used as the 1446 root of the ciphersuite-specific key hierarchy. Where a backend 1447 authentication server is present, the AAA-Key is transported from the 1448 EAP server to the authenticator; where it is not present, the AAA-Key 1449 is calculated on the authenticator. 1451 Regardless of how many sessions are initiated using it, the AAA-Key 1452 scope is between the EAP peer that calculates it, and the 1453 authenticator that either calculates it (where no backend 1454 authenticator is present) or receives it from the server (where a 1455 backend authenticator server is present). 1457 It should be understood that an authenticator or peer: 1459 [a] may contain multiple physical ports; 1460 [b] may advertise itself as multiple "virtual" authenticators 1461 or peers; 1462 [c] may utilize multiple CPUs; 1463 [d] may support clustering services for load balancing or failover. 1465 As illustrated in Figure 1, an EAP peer with multiple ports may be 1466 attached to one or more authenticators, each with multiple ports. 1467 Where the peer and authenticator identify themselves using a port 1468 identifier such as a link layer address, it may not be obvious to the 1469 peer which authenticator ports are associated with which 1470 authenticators. Similarly, it may not be obvious to the 1471 authenticator which peer ports are associated with which peers. As a 1472 result, the peer and authenticator may not be able to determine the 1473 scope of the AAA-Key. 1475 When a single physical authenticator advertises itself as multiple 1476 "virtual authenticators", the EAP peer and authenticator also may not 1477 be able to agree on the scope of the AAA-Key, creating a security 1478 vulnerability. For example, the peer may assume that the "virtual 1479 authenticators" are distinct and do not share a key cache, whereas, 1480 depending on the architecture of the physical AP, a shared key cache 1481 may or may not be implemented. 1483 Where the AAA-Key is shared between "virtual authenticators" an 1484 attacker acting as a peer could authenticate with the "Guest" 1485 "virtual authenticator" and derive a AAA-Key. If the virtual 1486 authenticators share a key cache, then the peer can utilize the AAA- 1487 Key derived for the "Guest" network to obtain access to the 1488 "Corporate Intranet" virtual authenticator. 1490 Several measures are recommended to address these issues: 1492 [a] Authenticators are REQUIRED to cache associated authorizations 1493 along with the AAA-Key and apply authorizations consistently. This 1494 ensures that an attacker cannot obtain elevated privileges even 1495 where the AAA-Key cache is shared between "virtual authenticators". 1497 [b] It is RECOMMENDED that physical authenticators maintain separate 1498 AAA-Key caches for each "virtual authenticator". 1500 [c] It is RECOMMENDED that each "virtual authenticator" identify itself 1501 distinctly to the AAA server, such as by utilizing a distinct NAS- 1502 identifier attribute. This enables the AAA server to utilize a 1503 separate credential to authenticate each "virtual authenticator". 1505 [d] It is RECOMMENDED that Secure Association Protocols identify peers 1506 and authenticators unambiguously, without incorporating implicit 1507 assumptions about peer and authenticator architectures. Using 1508 port-specific MAC addresses as identifiers is NOT RECOMMENDED where 1509 peers and authenticators may support multiple ports. 1511 [e] The AAA server and authenticator MAY implement additional 1512 attributes in order to further restrict the AAA-Key scope. For 1513 example, in 802.11, the AAA server may provide the authenticator 1514 with a list of authorized Called or Calling-Station-Ids and/or 1515 SSIDs for which the AAA-Key is valid. 1517 [f] Where the AAA server provides attributes restricting the key scope, 1518 it is RECOMMENDED that restrictions be securely communicated by the 1519 authenticator to the peer. This can be accomplished using the 1520 Secure Association Protocol, but also can be accomplished via the 1521 EAP method or the lower layer. 1523 4.7. Key Strength 1525 In order to guard against brute force attacks, EAP methods deriving 1526 keys need to be capable of generating keys with an appropriate 1527 effective symmetric key strength. In order to ensure that key 1528 generation is not the weakest link, it is RECOMMENDED that EAP 1529 methods utilizing public key cryptography choose a public key that 1530 has a cryptographic strength meeting the symmetric key strength 1531 requirement. 1533 As noted in [RFC3766] Section 5, this results in the following 1534 required RSA or DH module and DSA subgroup size in bits, for a given 1535 level of attack resistance in bits: 1537 Attack Resistance RSA or DH Modulus DSA subgroup 1538 (bits) size (bits) size (bits) 1539 ----------------- ----------------- ------------ 1540 70 947 128 1541 80 1228 145 1542 90 1553 153 1543 100 1926 184 1544 150 4575 279 1545 200 8719 373 1546 250 14596 475 1548 4.8. Key Wrap 1550 As described in [RFC3579] Section 4.3, known problems exist in the 1551 key wrap specified in [RFC2548]. Where the same RADIUS shared secret 1552 is used by a PAP authenticator and an EAP authenticator, there is a 1553 vulnerability to known plaintext attack. Since RADIUS uses the 1554 shared secret for multiple purposes, including per-packet 1555 authentication, attribute hiding, considerable information is exposed 1556 about the shared secret with each packet. This exposes the shared 1557 secret to dictionary attacks. MD5 is used both to compute the RADIUS 1558 Response Authenticator and the Message-Authenticator attribute, and 1559 some concerns exist relating to the security of this hash 1560 [MD5Attack]. 1562 As discussed in [RFC3579] Section 4.3, the security vulnerabilities 1563 of RADIUS are extensive, and therefore development of an alternative 1564 key wrap technique based on the RADIUS shared secret would not 1565 substantially improve security. As a result, [RFC3759] Section 4.2 1566 recommends running RADIUS over IPsec. The same approach is taken in 1567 Diameter EAP [I-D.ietf-aaa-eap], which defines cleartext key 1568 attributes, to be protected by IPsec or TLS. 1570 Where an untrusted AAA intermediary is present (such as a RADIUS 1571 proxy or a Diameter agent), and data object security is not used, the 1572 AAA-Key may be recovered by an attacker in control of the untrusted 1573 intermediary. Possession of the AAA-Key enables decryption of data 1574 traffic sent between the peer and a specific authenticator. However, 1575 as long as a AAA-Key or keys derived from it is only utilized by a 1576 single authenticator, compromise of the AAA-Key does not enable an 1577 attacker to impersonate the peer to another authenticator. 1578 Vulnerability to an untrusted AAA intermediary can be mitigated by 1579 implementation of redirect functionality, as described in [RFC3588] 1580 and [I-D.ietf-aaa-eap]. 1582 5. Handoff Vulnerabilities 1584 With EAP, a number of mechanisms are be utilized in order to reduce 1585 the latency of handoff between authenticators. One such mechanism is 1586 EAP pre-authentication, in which EAP is utilized to pre-establish a 1587 AAA-Key on an authenticator prior to arrival of the peer. Another 1588 such mechanism is AAA-Key caching, in which an EAP peer can re-attach 1589 to an authenticator without having to re-authenticate using EAP. Yet 1590 another mechanism is context transfer, such as is defined in 1591 [IEEE-802.11F] and [CTP]. These mechanisms introduce new security 1592 vulnerabilities, as discussed in the sections that follow. 1594 5.1. Authorization 1596 In a typical network access scenario (dial-in, wireless LAN, etc.) 1597 access control mechanisms are typically applied. These mechanisms 1598 include user authentication as well as authorization for the offered 1599 service. 1601 As a part of the authentication process, the AAA network determines 1602 the user's authorization profile. The user authorizations are 1603 transmitted by the backend authentication server to the EAP 1604 authenticator (also known as the Network Access Server or 1605 authenticator) included with the AAA-Token, which also contains the 1606 AAA-Key, in Phase 1b of the EAP conversation. Typically, the profile 1607 is determined based on the user identity, but a certificate presented 1608 by the user may also provide authorization information. 1610 The backend authentication server is responsible for making a user 1611 authorization decision, answering the following questions: 1613 [a] Is this a legitimate user for this particular network? 1615 [b] Is this user allowed the type of access he or she is requesting? 1617 [c] Are there any specific parameters (mandatory tunneling, bandwidth, 1618 filters, and so on) that the access network should be aware of for 1619 this user? 1621 [d] Is this user within the subscription rules regarding time of day? 1623 [e] Is this user within his limits for concurrent sessions? 1625 [f] Are there any fraud, credit limit, or other concerns that indicate 1626 that access should be denied? 1628 While the authorization decision is in principle simple, the process 1629 is complicated by the distributed nature of AAA decision making. 1631 Where brokering entities or proxies are involved, all of the AAA 1632 devices in the chain from the authenticator to the home AAA server 1633 are involved in the decision. For instance, a broker can disallow 1634 access even if the home AAA server would allow it, or a proxy can add 1635 authorizations (e.g., bandwidth limits). 1637 Decisions can be based on static policy definitions and profiles as 1638 well as dynamic state (e.g. time of day or limits on the number of 1639 concurrent sessions). In addition to the Accept/Reject decision made 1640 by the AAA chain, parameters or constraints can be communicated to 1641 the authenticator. 1643 The criteria for Accept/Reject decisions or the reasons for choosing 1644 particular authorizations are typically not communicated to the 1645 authenticator, only the final result. As a result, the authenticator 1646 has no way to know what the decision was based on. Was a set of 1647 authorization parameters sent because this service is always provided 1648 to the user, or was the decision based on the time/day and the 1649 capabilities of the requesting authenticator device? 1651 5.2. Correctness 1653 When the AAA exchange is bypassed via use of techniques such as AAA- 1654 Key caching, this creates challenges in ensuring that authorization 1655 is properly handled. These include: 1657 [a] Consistent application of session time limits. Bypassing AAA 1658 should not automatically increase the available session time, 1659 allowing a user to endlessly extend their network access by 1660 changing the point of attachment. 1662 [b] Avoidance of privilege elevation. Bypassing AAA should not result 1663 in a user being granted access to services which they are not 1664 entitled to. 1666 [c] Consideration of dynamic state. In situations in which dynamic 1667 state is involved in the access decision (day/time, simultaneous 1668 session limit) it should be possible to take this state into 1669 account either before or after access is granted. Note that 1670 consideration of network-wide state such as simultaneous session 1671 limits can typically only be taken into account by the backend 1672 authentication server. 1674 [d] Encoding of restrictions. Since a authenticator may not be aware 1675 of the criteria considered by a backend authentication server when 1676 allowing access, in order to ensure consistent authorization during 1677 a fast handoff it may be necessary to explicitly encode the 1678 restrictions within the authorizations provided in the AAA-Token. 1680 [e] State validity. The introduction of fast handoff should not render 1681 the authentication server incapable of keeping track of network- 1682 wide state. 1684 A handoff mechanism capable of addressing these concerns is said to 1685 be "correct". One condition for correctness is as follows: For a 1686 handoff to be "correct" it MUST establish on the new device the same 1687 context as would have been created had the new device completed a AAA 1688 conversation with the authentication server. 1690 A properly designed handoff scheme will only succeed if it is 1691 "correct" in this way. If a successful handoff would establish 1692 "incorrect" state, it is preferable for it to fail, in order to avoid 1693 creation of incorrect context. 1695 Some backend authentication server and authenticator configurations 1696 are incapable of meeting this definition of "correctness". For 1697 example, if the old and new device differ in their capabilities, it 1698 may be difficult to meet this definition of correctness in a handoff 1699 mechanism that bypasses AAA. Backend authentication servers often 1700 perform conditional evaluation, in which the authorizations returned 1701 in an Access-Accept message are contingent on the authenticator or on 1702 dynamic state such as the time of day or number of simultaneous 1703 sessions. For example, in a heterogeneous deployment, the backend 1704 authentication server might return different authorizations depending 1705 on the authenticator making the request, in order to make sure that 1706 the requested service is consistent with the authenticator 1707 capabilities. 1709 If differences between the new and old device would result in the 1710 backend authentication server sending a different set of messages to 1711 the new device than were sent to the old device, then if the handoff 1712 mechanism bypasses AAA, then the handoff cannot be carried out 1713 correctly. 1715 For example, if some authenticator devices within a deployment 1716 support dynamic VLANs while others do not, then attributes present in 1717 the Access-Request (such as the authenticator-IP-Address, 1718 authenticator-Identifier, Vendor-Identifier, etc.) could be examined 1719 to determine when VLAN attributes will be returned, as described in 1720 [RFC3580]. VLAN support is defined in [IEEE-802.1Q]. If a handoff 1721 bypassing the backend authentication server were to occur between a 1722 authenticator supporting dynamic VLANs and another authenticator 1723 which does not, then a guest user with access restricted to a guest 1724 VLAN could be given unrestricted access to the network. 1726 Similarly, in a network where access is restricted based on the day 1727 and time, Service Set Identifier (SSID), Calling-Station-Id or other 1728 factors, unless the restrictions are encoded within the 1729 authorizations, or a partial AAA conversation is included, then a 1730 handoff could result in the user bypassing the restrictions. 1732 In practice, these considerations limit the situations in which fast 1733 handoff mechanisms bypassing AAA can be expected to be successful. 1734 Where the deployed devices implement the same set of services, it may 1735 be possible to do successful handoffs within such mechanisms. 1736 However, where the supported services differ between devices, the 1737 handoff may not succeed. For example, [RFC2865] section 1.1 states: 1739 "A authenticator that does not implement a given service MUST NOT 1740 implement the RADIUS attributes for that service. For example, a 1741 authenticator that is unable to offer ARAP service MUST NOT 1742 implement the RADIUS attributes for ARAP. A authenticator MUST 1743 treat a RADIUS access-accept authorizing an unavailable service as 1744 an access-reject instead." 1746 Note that this behavior only applies to attributes that are known, 1747 but not implemented. For attributes that are unknown, [RFC2865] 1748 Section 5 states: 1750 "A RADIUS server MAY ignore Attributes with an unknown Type. A 1751 RADIUS client MAY ignore Attributes with an unknown Type." 1753 In order to perform a correct handoff, if a new device is provided 1754 with RADIUS context for a known but unavailable service, then it MUST 1755 process this context the same way it would handle a RADIUS Access- 1756 Accept requesting an unavailable service. This MUST cause the 1757 handoff to fail. However, if a new device is provided with RADIUS 1758 context that indicates an unknown attribute, then this attribute MAY 1759 be ignored. 1761 Although it may seem somewhat counter-intuitive, failure is indeed 1762 the "correct" result where a known but unsupported service is 1763 requested. Presumably a correctly configured backend authentication 1764 server would not request that a device carry out a service that it 1765 does not implement. This implies that if the new device were to 1766 complete a AAA conversation that it would be likely to receive 1767 different service instructions. In such a case, failure of the 1768 handoff is the desired result. This will cause the new device to go 1769 back to the AAA server in order to receive the appropriate service 1770 definition. 1772 In practice, this implies that handoff mechanisms which bypass AAA 1773 are most likely to be successful within a homogeneous device 1774 deployment within a single administrative domain. For example, it 1775 would not be advisable to carry out a fast handoff bypassing AAA 1776 between a authenticator providing confidentiality and another 1777 authenticator that does not support this service. The correct result 1778 of such a handoff would be a failure, since if the handoff were 1779 blindly carried out, then the user would be moved from a secure to an 1780 insecure channel without permission from the backend authentication 1781 server. Thus the definition of a "known but unsupported service" 1782 MUST encompass requests for unavailable security services. This 1783 includes vendor-specific attributes related to security, such as 1784 those described in [RFC2548]. 1786 6. Security Considerations 1788 6.1. Security Terminology 1790 "Cryptographic binding", "Cryptographic separation", "Key strength" 1791 and "Mutual authentication" are defined in [RFC3748] and are used 1792 with the same meaning here. 1794 6.2. Threat Model 1796 The EAP threat model is described in [RFC3748] Section 7.1. In order 1797 to address these threats, EAP relies on the security properties of 1798 EAP methods (known as "security claims", described in [RFC3784] 1799 Section 7.2.1). EAP method requirements for application such as 1800 Wireless LAN authentication are described in [RFC4017]. 1802 The RADIUS threat model is described in [RFC3579] Section 4.1, and 1803 responses to these threats are described in [RFC3579] Sections 4.2 1804 and 4.3. Among other things, [RFC3579] Section 4.2 recommends the 1805 use of IPsec ESP with non-null transform to provide per-packet 1806 authentication and confidentiality, integrity and replay protection 1807 for RADIUS/EAP. 1809 Given the existing documentation of EAP and AAA threat models and 1810 responses, there is no need to duplicate that material here. 1811 However, there are many other system-level threats no covered in 1812 these document which have not been described or analyzed elsewhere. 1813 These include: 1815 [1] An attacker may try to modify or spoof Secure Association Protocol 1816 packets. 1818 [2] An attacker compromising an authenticator may provide incorrect 1819 information to the EAP peer and/or server via out-of-band 1820 mechanisms (such as via a AAA or lower layer protocol). This 1821 includes impersonating another authenticator, or providing 1822 inconsistent information to the peer and EAP server. 1824 [3] An attacker may attempt to perform downgrading attacks on the 1825 ciphersuite negotiation within the Secure Association Protocol in 1826 order to ensure that a weaker ciphersuite is used to protect data. 1828 Depending on the lower layer, these attacks may be carried out 1829 without requiring physical proximity. 1831 In order to address these threats, [Housley56] describes the 1832 mandatory system security properties: 1834 Algorithm independence 1835 Wherever cryptographic algorithms are chosen, the algorithms must 1836 be negotiable, in order to provide resilient against compromise of 1837 a particular algorithm. Algorithm independence must be 1838 demonstrated within all aspects of the system, including within 1839 EAP, AAA and the Secure Association Protocol. However, for 1840 interoperability, at least one suite of algorithms MUST be 1841 implemented. 1843 Strong, fresh session keys 1844 Session keys must be demonstrated to be strong and fresh in all 1845 circumstances, while at the same time retaining algorithm 1846 independence. 1848 Replay protection 1849 All protocol exchanges must be replay protected. This includes 1850 exchanges within EAP, AAA, and the Secure Association Protocol. 1852 Authentication 1853 All parties need to be authenticated. The confidentiality of the 1854 authenticator must be maintained. No plaintext passwords are 1855 allowed. 1857 Authorization 1858 EAP peer and authenticator authorization must be performed. 1860 Session keys 1861 Confidentiality of session keys must be maintained. 1863 Ciphersuite negotiation 1864 The selection of the "best" ciphersuite must be securely confirmed. 1866 Unique naming 1867 Session keys must be uniquely named. 1869 Domino effect 1870 Compromise of a single authenticator cannot compromise any other 1871 part of the system, including session keys and long-term secrets. 1873 Key binding 1874 The key must be bound to the appropriate context. 1876 6.3. Security Analysis 1878 Figure 6 illustrates the relationship between the peer, authenticator 1879 and backend authentication server. 1881 EAP peer 1882 /\ 1883 / \ 1884 Protocol: EAP / \ Protocol: Secure Association 1885 Auth: Mutual / \ Auth: Mutual 1886 Unique keys: / \ Unique keys: TSKs 1887 TEKs,EMSK / \ 1888 / \ 1889 EAP server +--------------+ Authenticator 1890 Protocol: AAA 1891 Auth: Mutual 1892 Unique key: AAA session key 1894 Figure 6: Relationship between peer, authenticator and auth. server 1896 The peer and EAP server communicate using EAP [RFC3748]. The 1897 security properties of this communication are largely determined by 1898 the chosen EAP method. Method security claims are described in 1899 [RFC3748] Section 7.2. These include the key strength, protected 1900 ciphersuite negotiation, mutual authentication, integrity protection, 1901 replay protection, confidentiality, key derivation, key strength, 1902 dictionary attack resistance, fast reconnect, cryptographic binding, 1903 session independence, fragmentation and channel binding claims. At a 1904 minimum, methods claiming to support key derivation must also support 1905 mutual authentication. As noted in [RFC3748] Section 7.10: 1907 EAP Methods deriving keys MUST provide for mutual authentication 1908 between the EAP peer and the EAP Server. 1910 Ciphersuite independence is also required: 1912 Keying material exported by EAP methods MUST be independent of the 1913 ciphersuite negotiated to protect data. 1915 In terms of key strength and freshness, [RFC3748] Section 10 says: 1917 EAP methods SHOULD ensure the freshness of the MSK and EMSK even 1918 in cases where one party may not have a high quality random number 1919 generator.... In order to preserve algorithm independence, EAP 1920 methods deriving keys SHOULD support (and document) the protected 1921 negotiation of the ciphersuite used to protect the EAP 1922 conversation between the peer and server... In order to enable 1923 deployments requiring strong keys, EAP methods supporting key 1924 derivation SHOULD be capable of generating an MSK and EMSK, each 1925 with an effective key strength of at least 128 bits. 1927 The authenticator and backend authentication server communicate using 1928 a AAA protocol such as RADIUS [RFC3579] or Diameter [I-D.ietf-aaa- 1929 eap]. As noted in [RFC3588] Section 13, Diameter must be protected 1930 by either IPsec ESP with non-null transform or TLS. As a result, 1931 Diameter requires per-packet integrity and confidentiality. Replay 1932 protection must be supported. For RADIUS, [RFC3579] Section 4.2 1933 recommends that RADIUS be protected by IPsec ESP with a non-null 1934 transform, and where IPsec is implemented replay protection must be 1935 supported. 1937 The peer and authenticator communicate using the Secure Association 1938 Protocol. 1940 As noted in the figure, each party in the exchange mutually 1941 authenticates with each of the other parties, and derives a unique 1942 key. All parties in the diagram have access to the AAA-Key. 1944 The EAP peer and backend authentication server mutually authenticate 1945 via the EAP method, and derive the TEKs and EMSK which are known only 1946 to them. The TEKs are used to protect some or all of the EAP 1947 conversation between the peer and authenticator, so as to guard 1948 against modification or insertion of EAP packets by an attacker. The 1949 degree of protection afforded by the TEKs is determined by the EAP 1950 method; some methods may protect the entire EAP packet, including the 1951 EAP header, while other methods may only protect the contents of the 1952 Type-Data field, defined in [RFC3748]. 1954 Since EAP is spoken only between the EAP peer and server, if a 1955 backend authentication server is present then the EAP conversation 1956 does not provide mutual authentication between the peer and 1957 authenticator, only between the EAP peer and EAP server (backend 1958 authentication server). As a result, mutual authentication between 1959 the peer and authenticator only occurs where a Secure Association 1960 protocol is used, such the unicast and group key derivation handshake 1961 supported in [IEEE-802.11i]. This means that absent use of a secure 1962 Association Protocol, from the point of view of the peer, EAP mutual 1963 authentication only proves that the authenticator is trusted by the 1964 backend authentication server; the identity of the authenticator is 1965 not confirmed. 1967 Utilizing the AAA protocol, the authenticator and backend 1968 authentication server mutually authenticate and derive session keys 1969 known only to them, used to provide per-packet integrity and replay 1970 protection, authentication and confidentiality. The AAA-Key is 1971 distributed by the backend authentication server to the authenticator 1972 over this channel, bound to attributes constraining its usage, as 1973 part of the AAA-Token. The binding of attributes to the AAA-Key 1974 within a protected package is important so the authenticator 1975 receiving the AAA-Token can determine that it has not been 1976 compromised, and that the keying material has not been replayed, or 1977 mis-directed in some way. 1979 The security properties of the EAP exchange are dependent on each leg 1980 of the triangle: the selected EAP method, AAA protocol and the Secure 1981 Association Protocol. 1983 Assuming that the AAA protocol provides protection against rogue 1984 authenticators forging their identity, then the AAA-Token can be 1985 assumed to be sent to the correct authenticator, and where it is 1986 wrapped appropriately, it can be assumed to be immune to compromise 1987 by a snooping attacker. 1989 Where an untrusted AAA intermediary is present, the AAA-Token must 1990 not be provided to the intermediary so as to avoid compromise of the 1991 AAA-Token. This can be avoided by use of re-direct as defined in 1992 [RFC3588]. 1994 When EAP is used for authentication on PPP or wired IEEE 802 1995 networks, it is typically assumed that the link is physically secure, 1996 so that an attacker cannot gain access to the link, or insert a rogue 1997 device. EAP methods defined in [RFC3748] reflect this usage model. 1998 These include EAP MD5, as well as One-Time Password (OTP) and Generic 1999 Token Card. These methods support one-way authentication (from EAP 2000 peer to authenticator) but not mutual authentication or key 2001 derivation. As a result, these methods do not bind the initial 2002 authentication and subsequent data traffic, even when the the 2003 ciphersuite used to protect data supports per-packet authentication 2004 and integrity protection. As a result, EAP methods not supporting 2005 mutual authentication are vulnerable to session hijacking as well as 2006 attacks by rogue devices. 2008 On wireless networks such as IEEE 802.11 [IEEE-802.11], these attacks 2009 become easy to mount, since any attacker within range can access the 2010 wireless medium, or act as an access point. As a result, new 2011 ciphersuites have been proposed for use with wireless LANs 2012 [IEEE-802.11i] which provide per-packet authentication, integrity and 2013 replay protection. In addition, mutual authentication and key 2014 derivation, provided by methods such as EAP-TLS [RFC2716] are 2015 required [IEEE-802.11i], so as to address the threat of rogue 2016 devices, and provide keying material to bind the initial 2017 authentication to subsequent data traffic. 2019 If the selected EAP method does not support mutual authentication, 2020 then the peer will be vulnerable to attack by rogue authenticators 2021 and backend authentication servers. If the EAP method does not derive 2022 keys, then TSKs will not be available for use with a negotiated 2023 ciphersuite, and there will be no binding between the initial EAP 2024 authentication and subsequent data traffic, leaving the session 2025 vulnerable to hijack. 2027 If the backend authentication server does not protect against 2028 authenticator masquerade, or provide the proper binding of the AAA- 2029 Key to the session within the AAA-Token, then one or more AAA-Keys 2030 may be sent to an unauthorized party, and an attacker may be able to 2031 gain access to the network. If the AAA-Token is provided to an 2032 untrusted AAA intermediary, then that intermediary may be able to 2033 modify the AAA-Key, or the attributes associated with it, as 2034 described in [RFC2607]. 2036 If the Secure Association Protocol does not provide mutual proof of 2037 possession of the AAA-Key material, then the peer will not have 2038 assurance that it is connected to the correct authenticator, only 2039 that the authenticator and backend authentication server share a 2040 trust relationship (since AAA protocols support mutual 2041 authentication). This distinction can become important when multiple 2042 authenticators receive AAA-Keys from the backend authentication 2043 server, such as where fast handoff is supported. If the TSK 2044 derivation does not provide for protected ciphersuite and 2045 capabilities negotiation, then downgrade attacks are possible. 2047 6.4. Man-in-the-middle Attacks 2049 As described in [I-D.puthenkulam-eap-binding], EAP method sequences 2050 and compound authentication mechanisms may be subject to man-in-the- 2051 middle attacks. When such attacks are successfully carried out, the 2052 attacker acts as an intermediary between a victim and a legitimate 2053 authenticator. This allows the attacker to authenticate successfully 2054 to the authenticator, as well as to obtain access to the network. 2056 In order to prevent these attacks, [I-D.puthenkulam-eap-binding] 2057 recommends derivation of a compound key by which the EAP peer and 2058 server can prove that they have participated in the entire EAP 2059 exchange. Since the compound key must not be known to an attacker 2060 posing as an authenticator, and yet must be derived from quantities 2061 that are exported by EAP methods, it may be desirable to derive the 2062 compound key from a portion of the EMSK. In order to provide proper 2063 key hygiene, it is recommended that the compound key used for man-in- 2064 the-middle protection be cryptographically separate from other keys 2065 derived from the EMSK, such as fast handoff keys, discussed in 2066 Section 2.3. 2068 6.5. Denial of Service Attacks 2070 The caching of security associations may result in vulnerability to 2071 denial of service attacks. Since an EAP peer may derive multiple EAP 2072 SAs with a given EAP server, and creation of a new EAP SA does not 2073 implicitly delete a previous EAP SA, EAP methods that result in 2074 creation of persistent state may be vulnerable to denial of service 2075 attacks by a rogue EAP peer. 2077 As a result, EAP methods creating persistent state may wish to limit 2078 the number of cached EAP SAs (Phase 1a) corresponding to an EAP peer. 2079 For example, an EAP server may choose to only retain a few EAP SAs 2080 for each peer. This prevents a rogue peer from denying access to 2081 other peers. 2083 Similarly, an authenticator may have multiple AAA-Key SAs 2084 corresponding to a given EAP peer; to conserve resources an 2085 authenticator may choose to limit the number of cached AAA-Key (Phase 2086 1 b) SAs for each peer. 2088 Depending on the media, creation of a new unicast Secure Association 2089 SA may or may not imply deletion of a previous unicast secure 2090 association SA. Where there is no implied deletion, the 2091 authenticator may choose to limit Phase 2 (unicast and multicast) 2092 Secure Association SAs for each peer. 2094 6.6. Impersonation 2096 Both the RADIUS and Diameter protocols are potentially vulnerable to 2097 impersonation by a rogue authenticator. 2099 While AAA protocols such as RADIUS [RFC2865] or Diameter [RFC3588] 2100 support mutual authentication between the authenticator (known as the 2101 AAA client) and the backend authentication server (known as the AAA 2102 server), the security mechanisms vary according to the AAA protocol. 2104 In RADIUS, the shared secret used for authentication is determined by 2105 the source address of the RADIUS packet. As noted in [RFC3579] 2106 Section 4.3.7, it is highly desirable that the source address be 2107 checked against one or more NAS identification attributes so as to 2108 detect and prevent impersonation attacks. 2110 When RADIUS requests are forwarded by a proxy, the NAS-IP-Address or 2111 NAS-IPv6-Address attributes may not correspond to the source address. 2112 Since the NAS-Identifier attribute need not contain an FQDN, it also 2113 may not correspond to the source address, even indirectly. [RFC2865] 2114 Section 3 states: 2116 A RADIUS server MUST use the source IP address of the RADIUS 2117 UDP packet to decide which shared secret to use, so that 2118 RADIUS requests can be proxied. 2120 This implies that it is possible for a rogue authenticator to forge 2121 NAS-IP-Address, NAS-IPv6-Address or NAS-Identifier attributes within 2122 a RADIUS Access-Request in order to impersonate another 2123 authenticator. Among other things, this can result in messages (and 2124 MSKs) being sent to the wrong authenticator. Since the rogue 2125 authenticator is authenticated by the RADIUS proxy or server purely 2126 based on the source address, other mechanisms are required to detect 2127 the forgery. In addition, it is possible for attributes such as the 2128 Called-Station-Id and Calling-Station-Id to be forged as well. 2130 As recommended in [RFC3579], this vulnerability can be mitigated by 2131 having RADIUS proxies check authenticator identification attributes 2132 against the source address. 2134 To allow verification of session parameters such as the Called- 2135 Station- Id and Calling-Station-Id, these can be sent by the EAP peer 2136 to the server, protected by the TEKs. The RADIUS server can then 2137 check the parameters sent by the EAP peer against those claimed by 2138 the authenticator. If a discrepancy is found, an error can be 2139 logged. 2141 While [RFC3588] requires use of the Route-Record AVP, this utilizes 2142 FQDNs, so that impersonation detection requires DNS A/AAAA and PTR 2143 RRs to be properly configured. As a result, it appears that Diameter 2144 is as vulnerable to this attack as RADIUS, if not more so. To address 2145 this vulnerability, it is necessary to allow the backend 2146 authentication server to communicate with the authenticator directly, 2147 such as via the redirect functionality supported in [RFC3588]. 2149 6.7. Channel binding 2151 It is possible for a compromised or poorly implemented EAP 2152 authenticator to communicate incorrect information to the EAP peer 2153 and/or server. This may enable an authenticator to impersonate 2154 another authenticator or communicate incorrect information via out- 2155 of-band mechanisms (such as via AAA or the lower layer protocol). 2157 Where EAP is used in pass-through mode, the EAP peer typically does 2158 not verify the identity of the pass-through authenticator, it only 2159 verifies that the pass-through authenticator is trusted by the EAP 2160 server. This creates a potential security vulnerability, described in 2162 [RFC3748] Section 7.15. 2164 [RFC3579] Section 4.3.7 describes how an EAP pass-through 2165 authenticator acting as a AAA client can be detected if it attempts 2166 to impersonate another authenticator (such by sending incorrect NAS- 2167 Identifier [RFC2865], NAS-IP-Address [RFC2865] or NAS-IPv6-Address 2168 [RFC3162] attributes via the AAA protocol). However, it is possible 2169 for a pass-through authenticator acting as a AAA client to provide 2170 correct information to the AAA server while communicating misleading 2171 information to the EAP peer via a lower layer protocol. 2173 For example, it is possible for a compromised authenticator to 2174 utilize another authenticator's Called-Station-Id or NAS-Identifier 2175 in communicating with the EAP peer via a lower layer protocol, or for 2176 a pass-through authenticator acting as a AAA client to provide an 2177 incorrect peer Calling-Station-Id [RFC2865][RFC3580] to the AAA 2178 server via the AAA protocol. 2180 As noted in [RFC3748] Section 7.15, this vulnerability can be 2181 addressed by use of EAP methods that support a protected exchange of 2182 channel properties such as endpoint identifiers, including (but not 2183 limited to): Called-Station-Id [RFC2865][RFC3580], Calling-Station-Id 2184 [RFC2865][RFC3580], NAS-Identifier [RFC2865], NAS-IP-Address 2185 [RFC2865], and NAS-IPv6-Address [RFC3162]. 2187 Using such a protected exchange, it is possible to match the channel 2188 properties provided by the authenticator via out-of-band mechanisms 2189 against those exchanged within the EAP method. For example, see 2190 [ServiceIdent]. 2192 7. Security Requirements 2194 This section summarizes the security requirements that must be met by 2195 EAP methods, AAA protocols, Secure Association Protocols and 2196 Ciphersuites in order to address the security threats described in 2197 this document. These requirements MUST be met by specifications 2198 requesting publication as an RFC. Each requirement provides a 2199 pointer to the sections of this document describing the threat that 2200 it mitigates. 2202 7.1. EAP Method Requirements 2204 It is possible for the peer and EAP server to mutually authenticate 2205 and derive keys. In order to provide keying material for use in a 2206 subsequently negotiated ciphersuite, an EAP method supporting key 2207 derivation MUST export a Master Session Key (MSK) of at least 64 2208 octets, and an Extended Master Session Key (EMSK) of at least 64 2209 octets. EAP Methods deriving keys MUST provide for mutual 2210 authentication between the EAP peer and the EAP Server. 2212 The MSK and EMSK MUST NOT be used directly to protect data; however, 2213 they are of sufficient size to enable derivation of a AAA-Key 2214 subsequently used to derive Transient Session Keys (TSKs) for use 2215 with the selected ciphersuite. Each ciphersuite is responsible for 2216 specifying how to derive the TSKs from the AAA-Key. 2218 The AAA-Key is derived from the keying material exported by the EAP 2219 method (MSK and EMSK). This derivation occurs on the AAA server. In 2220 many existing protocols that use EAP, the AAA-Key and MSK are 2221 equivalent, but more complicated mechanisms are possible (see Section 2222 2.3 for details). 2224 EAP methods SHOULD ensure the freshness of the MSK and EMSK even in 2225 cases where one party may not have a high quality random number 2226 generator. A RECOMMENDED method is for each party to provide a nonce 2227 of at least 128 bits, used in the derivation of the MSK and EMSK. 2229 EAP methods export the MSK and EMSK and not Transient Session Keys so 2230 as to allow EAP methods to be ciphersuite and media independent. 2231 Keying material exported by EAP methods MUST be independent of the 2232 ciphersuite negotiated to protect data. 2234 Depending on the lower layer, EAP methods may run before or after 2235 ciphersuite negotiation, so that the selected ciphersuite may not be 2236 known to the EAP method. By providing keying material usable with 2237 any ciphersuite, EAP methods can used with a wide range of 2238 ciphersuites and media. 2240 It is RECOMMENDED that methods providing integrity protection of EAP 2241 packets include coverage of all the EAP header fields, including the 2242 Code, Identifier, Length, Type and Type-Data fields. 2244 In order to preserve algorithm independence, EAP methods deriving 2245 keys SHOULD support (and document) the protected negotiation of the 2246 ciphersuite used to protect the EAP conversation between the peer and 2247 server. This is distinct from the ciphersuite negotiated between the 2248 peer and authenticator, used to protect data. 2250 The strength of Transient Session Keys (TSKs) used to protect data is 2251 ultimately dependent on the strength of keys generated by the EAP 2252 method. If an EAP method cannot produce keying material of 2253 sufficient strength, then the TSKs may be subject to brute force 2254 attack. In order to enable deployments requiring strong keys, EAP 2255 methods supporting key derivation SHOULD be capable of generating an 2256 MSK and EMSK, each with an effective key strength of at least 128 2257 bits. 2259 Methods supporting key derivation MUST demonstrate cryptographic 2260 separation between the MSK and EMSK branches of the EAP key 2261 hierarchy. Without violating a fundamental cryptographic assumption 2262 (such as the non-invertibility of a one-way function) an attacker 2263 recovering the MSK or EMSK MUST NOT be able to recover the other 2264 quantity with a level of effort less than brute force. 2266 Non-overlapping substrings of the MSK MUST be cryptographically 2267 separate from each other. That is, knowledge of one substring MUST 2268 NOT help in recovering some other non-overlapping substring without 2269 breaking some hard cryptographic assumption. This is required 2270 because some existing ciphersuites form TSKs by simply splitting the 2271 AAA-Key to pieces of appropriate length. Likewise, non-overlapping 2272 substrings of the EMSK MUST be cryptographically separate from each 2273 other, and from substrings of the MSK. The EMSK MUST NOT be 2274 transported to, or shared with, additional parties. 2276 Since EAP does not provide for explicit key lifetime negotiation, EAP 2277 peers, authenticators and authentication servers MUST be prepared for 2278 situations in which one of the parties discards key state which 2279 remains valid on another party. 2281 The development and validation of key derivation algorithms is 2282 difficult, and as a result EAP methods SHOULD reuse well established 2283 and analyzed mechanisms for MSK and EMSK key derivation (such as 2284 those specified in IKE [RFC2409] or TLS [RFC2246]), rather than 2285 inventing new ones. 2287 7.1.1. Requirements for EAP methods 2289 In order for an EAP method to meet the guidelines for EMSK usage it 2290 must meet the following requirements: 2292 o It MUST specify how to derive the EMSK 2294 o The key material used for the EMSK MUST be 2295 computationally independent of the MSK and TEKs. 2297 o The EMSK MUST NOT be used for any other purpose than the key 2298 derivation described in this document. 2300 o The EMSK MUST be secret and not known to someone observing 2301 the authentication mechanism protocol exchange. 2303 o The EMSK MUST NOT be exported from the EAP server. 2305 o The EMSK MUST be unique for each session. 2307 o The EAP mechanism SHOULD a unique identifier suitable for naming the EMSK. 2309 7.1.2. Requirements for EAP applications 2311 In order for an application to meet the guidelines for EMSK usage it 2312 must meet the following requirements: 2314 o New applications following this specification SHOULD NOT use the 2315 MSK. If more than one application uses the MSK, then the 2316 cryptographic separation is not achieved. Implementations SHOULD 2317 prevent such combinations. 2319 o A peer MUST NOT use the EMSK directly for cryptographic 2320 protection of data. 2322 7.2. AAA Protocol Requirements 2324 AAA protocols suitable for use in transporting EAP MUST provide the 2325 following facilities: 2327 Security services 2328 AAA protocols used for transport of EAP keying material MUST 2329 implement and SHOULD use per-packet integrity and authentication, 2330 replay protection and confidentiality. These requirements are met 2331 by Diameter EAP [I-D.ietf-aaa-eap], as well as RADIUS over IPsec 2332 [RFC3579]. 2334 Session Keys 2335 AAA protocols used for transport of EAP keying material MUST 2336 implement and SHOULD use dynamic key management in order to derive 2337 fresh session keys, as in Diameter EAP [I-D.ietf-aaa-eap] and 2338 RADIUS over IPsec [RFC3579], rather than using a static key, as 2339 originally defined in RADIUS [RFC2865]. 2341 Mutual authentication 2342 AAA protocols used for transport of EAP keying material MUST 2343 provide for mutual authentication between the authenticator and 2344 backend authentication server. These requirements are met by 2345 Diameter EAP [I-D.ietf-aaa-eap] as well as by RADIUS EAP [RFC3579]. 2347 Authorization 2348 AAA protocols used for transport of EAP keying material SHOULD 2349 provide protection against rogue authenticators masquerading as 2350 other authenticators. This can be accomplished, for example, by 2351 requiring that AAA agents check the source address of packets 2352 against the origin attributes (Origin-Host AVP in Diameter, NAS-IP- 2353 Address, NAS-IPv6-Address, NAS-Identifier in RADIUS). For details, 2354 see [RFC3579] Section 4.3.7. 2356 Key transport 2357 Since EAP methods do not export Transient Session Keys (TSKs) in 2358 order to maintain media and ciphersuite independence, the AAA 2359 server MUST NOT transport TSKs from the backend authentication 2360 server to authenticator. 2362 Key transport specification 2363 In order to enable backend authentication servers to provide keying 2364 material to the authenticator in a well defined format, AAA 2365 protocols suitable for use with EAP MUST define the format and 2366 wrapping of the AAA-Token. 2368 EMSK transport 2369 Since the EMSK is a secret known only to the backend authentication 2370 server and peer, the AAA-Token MUST NOT transport the EMSK from the 2371 backend authentication server to the authenticator. 2373 AAA-Token protection 2374 To ensure against compromise, the AAA-Token MUST be integrity 2375 protected, authenticated, replay protected and encrypted in 2376 transit, using well-established cryptographic algorithms. 2378 Session Keys 2379 The AAA-Token SHOULD be protected with session keys as in Diameter 2380 [RFC3588] or RADIUS over IPsec [RFC3579] rather than static keys, 2381 as in [RFC2548]. 2383 Key naming 2384 In order to ensure against confusion between the appropriate keying 2385 material to be used in a given Secure Association Protocol 2386 exchange, the AAA-Token SHOULD include explicit key names and 2387 context appropriate for informing the authenticator how the keying 2388 material is to be used. 2390 Key Compromise 2391 Where untrusted intermediaries are present, the AAA-Token SHOULD 2392 NOT be provided to the intermediaries. In Diameter, handling of 2393 keys by intermediaries can be avoided using Redirect functionality 2394 [RFC3588]. 2396 7.3. Secure Association Protocol Requirements 2398 The Secure Association Protocol supports the following: 2400 Entity Naming 2401 The peer and authenticator SHOULD identify themselves in a manner 2402 that is independent of their attached ports. 2404 Mutual proof of possession 2405 The peer and authenticator MUST each demonstrate possession of the 2406 keying material transported between the backend authentication 2407 server and authenticator (AAA-Key). 2409 Key Naming 2410 The Secure Association Protocol MUST explicitly name the keys used 2411 in the proof of possession exchange, so as to prevent confusion 2412 when more than one set of keying material could potentially be used 2413 as the basis for the exchange. 2415 Creation and Deletion 2416 In order to support the correct processing of phase 2 security 2417 associations, the Secure Association (phase 2) protocol MUST 2418 support the naming of phase 2 security associations and associated 2419 transient session keys, so that the correct set of transient 2420 session keys can be identified for processing a given packet. The 2421 phase 2 Secure Association Protocol also MUST support transient 2422 session key activation and SHOULD support deletion, so that 2423 establishment and re-establishment of transient session keys can be 2424 synchronized between the parties. 2426 Integrity and Replay Protection 2427 The Secure Association Protocol MUST support integrity and replay 2428 protection of all messages. 2430 Direct operation 2431 Since the phase 2 Secure Association Protocol is concerned with the 2432 establishment of security associations between the EAP peer and 2433 authenticator, including the derivation of transient session keys, 2434 only those parties have "a need to know" the transient session 2435 keys. The Secure Association Protocol MUST operate directly between 2436 the peer and authenticator, and MUST NOT be passed-through to the 2437 backend authentication server, or include additional parties. 2439 Derivation of transient session keys 2440 The Secure Association Protocol negotiation MUST support derivation 2441 of unicast and multicast transient session keys suitable for use 2442 with the negotiated ciphersuite. 2444 TSK freshness 2445 The Secure Association (phase 2) Protocol MUST support the 2446 derivation of fresh unicast and multicast transient session keys, 2447 even when the keying material provided by the backend 2448 authentication server is not fresh. This is typically supported by 2449 including an exchange of nonces within the Secure Association 2450 Protocol. 2452 Bi-directional operation 2453 While some ciphersuites only require a single set of transient 2454 session keys to protect traffic in both directions, other 2455 ciphersuites require a unique set of transient session keys in each 2456 direction. The phase 2 Secure Association Protocol SHOULD provide 2457 for the derivation of unicast and multicast keys in each direction, 2458 so as not to require two separate phase 2 exchanges in order to 2459 create a bi-directional phase 2 security association. 2461 Secure capabilities negotiation 2462 The Secure Association Protocol MUST support secure capabilities 2463 negotiation. This includes security parameters such as the 2464 security association identifier (SAID) and ciphersuites, as well as 2465 negotiation of the lifetime of the TSKs, AAA-Key and exported EAP 2466 keys. Secure capabilities negotiation also includes confirmation 2467 of the capabilities discovered during the discovery phase (phase 2468 0), so as to ensure that the announced capabilities have not been 2469 forged. 2471 Key Scoping 2472 The Secure Association Protocol MUST ensure the synchronization of 2473 key scope between the peer and authenticator. This includes 2474 negotiation of restrictions on key usage. 2476 7.4. Ciphersuite Requirements 2478 Ciphersuites suitable for keying by EAP methods MUST provide the 2479 following facilities: 2481 TSK derivation 2482 In order to allow a ciphersuite to be usable within the EAP keying 2483 framework, a specification MUST be provided describing how 2484 transient session keys suitable for use with the ciphersuite are 2485 derived from the AAA-Key. 2487 EAP method independence 2488 Algorithms for deriving transient session keys from the AAA-Key 2489 MUST NOT depend on the EAP method. However, algorithms for 2490 deriving TEKs MAY be specific to the EAP method. 2492 Cryptographic separation 2493 The TSKs derived from the AAA-Key MUST be cryptographically 2494 separate from each other. Similarly, TEKs MUST be 2495 cryptographically separate from each other. In addition, the TSKs 2496 MUST be cryptographically separate from the TEKs. 2498 8. IANA Considerations 2500 This document does not create any new name spaces nor does it 2501 allocate any protocol parameters. 2503 9. References 2505 9.1. Normative References 2507 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2508 Requirement Levels", BCP 14, RFC 2119, March 1997. 2510 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 2511 Considerations Section in RFCs", BCP 26, RFC 2434, October 2512 1998. 2514 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 2515 Lefkowetz, "Extensible Authentication Protocol (EAP)", RFC 2516 3748, June 2004. 2518 9.2. Informative References 2520 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 2521 September 1981. 2523 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 2524 1661, July 1994. 2526 [RFC1968] Meyer, G. and K. Fox, "The PPP Encryption Control Protocol 2527 (ECP)", RFC 1968, June 1996. 2529 [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing 2530 for Message Authentication", RFC 2104, February 1997. 2532 [RFC2246] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. 2533 and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, 2534 January 1999. 2536 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 2537 Internet Protocol", RFC 2401, November 1998. 2539 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 2540 RFC 2409, November 1998. 2542 [RFC2419] Sklower, K. and G. Meyer, "The PPP DES Encryption Protocol, 2543 Version 2 (DESE-bis)", RFC 2419, September 1998. 2545 [RFC2420] Kummert, H., "The PPP Triple-DES Encryption Protocol (3DESE)", 2546 RFC 2420, September 1998. 2548 [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D. and 2549 R. Wheeler, "A Method for Transmitting PPP Over Ethernet 2550 (PPPoE)", RFC 2516, February 1999. 2552 [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2553 2548, March 1999. 2555 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 2556 Implementation in Roaming", RFC 2607, June 1999. 2558 [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol", 2559 RFC 2716, October 1999. 2561 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 2562 Authentication Dial In User Service (RADIUS)", RFC 2865, June 2563 2000. 2565 [RFC3078] Pall, G. and G. Zorn, "Microsoft Point-To-Point Encryption 2566 (MPPE) Protocol", RFC 3078, March 2001. 2568 [RFC3079] Zorn, G., "Deriving Keys for use with Microsoft Point-to-Point 2569 Encryption (MPPE)", RFC 3079, March 2001. 2571 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial 2572 In User Service) Support For Extensible Authentication 2573 Protocol (EAP)", RFC 3579, September 2003. 2575 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese, 2576 "IEEE 802.1X Remote Authentication Dial In User Service 2577 (RADIUS) Usage Guidelines", RFC 3580, September 2003. 2579 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. 2580 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 2582 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public 2583 Keys Used For Exchanging Symmetric Keys", RFC 3766, April 2584 2004. 2586 [RFC4017] Stanley, D., Walker, J. and B. Aboba, "EAP Method Requirements 2587 for Wireless LANs", RFC 4017, March 2005. 2589 [CTP] Loughney, J., Nakhjiri, M., Perkins, C. and R. Koodli, 2590 "Context Transfer Protocol", draft-ietf-seamoby-ctp-11.txt, 2591 Internet draft (work in progress), August 2004. 2593 [DESMODES] 2594 National Institute of Standards and Technology, "DES Modes of 2595 Operation", FIPS PUB 81, December 1980, . 2598 [FIPSDES] National Institute of Standards and Technology, "Data 2599 Encryption Standard", FIPS PUB 46, January 1977. 2601 [IEEE-802] 2602 Institute of Electrical and Electronics Engineers, "IEEE 2603 Standards for Local and Metropolitan Area Networks: Overview 2604 and Architecture", ANSI/IEEE Standard 802, 1990. 2606 [IEEE-802.11] 2607 Institute of Electrical and Electronics Engineers, 2608 "Information technology - Telecommunications and information 2609 exchange between systems - Local and metropolitan area 2610 networks - Specific Requirements Part 11: Wireless LAN Medium 2611 Access Control (MAC) and Physical Layer (PHY) Specifications", 2612 IEEE IEEE Standard 802.11-2003, 2003. 2614 [IEEE-802.1X] 2615 Institute of Electrical and Electronics Engineers, "Local and 2616 Metropolitan Area Networks: Port-Based Network Access 2617 Control", IEEE Standard 802.1X-2004, December 2004. 2619 [IEEE-802.1Q] 2620 Institute of Electrical and Electronics Engineers, "IEEE 2621 Standards for Local and Metropolitan Area Networks: Draft 2622 Standard for Virtual Bridged Local Area Networks", IEEE 2623 Standard 802.1Q/D8, January 1998. 2625 [IEEE-802.11i] 2626 Institute of Electrical and Electronics Engineers, "Supplement 2627 to STANDARD FOR Telecommunications and Information Exchange 2628 between Systems - LAN/MAN Specific Requirements - Part 11: 2629 Wireless Medium Access Control (MAC) and physical layer (PHY) 2630 specifications: Specification for Enhanced Security", IEEE 2631 802.11i, December 2004. 2633 [IEEE-802.11F] 2634 Institute of Electrical and Electronics Engineers, 2635 "Recommended Practice for Multi-Vendor Access Point 2636 Interoperability via an Inter-Access Point Protocol Across 2637 Distribution Systems Supporting IEEE 802.11 Operation", IEEE 2638 802.11F, July 2003. 2640 [IEEE-02-758] 2641 Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, 2642 "Proactive Caching Strategies for IAPP Latency Improvement 2643 during 802.11 Handoff", IEEE 802.11 Working Group, 2644 IEEE-02-758r1-F Draft 802.11I/D5.0, November 2002. 2646 [IEEE-03-084] 2647 Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, 2648 "Proactive Key Distribution to support fast and secure 2649 roaming", IEEE 802.11 Working Group, IEEE-03-084r1-I, 2650 http://www.ieee802.org/11/Documents/DocumentHolder/ 3-084.zip, 2651 January 2003. 2653 [IEEE-03-155] 2654 Aboba, B., "Fast Handoff Issues", IEEE 802.11 Working Group, 2655 IEEE-03-155r0-I, http://www.ieee802.org/11/ 2656 Documents/DocumentHolder/3-155.zip, March 2003. 2658 [I-D.ietf-roamops-cert] 2659 Aboba, B., "Certificate-Based Roaming", draft-ietf-roamops- 2660 cert-02 (work in progress), April 1999. 2662 [I-D.ietf-aaa-eap] 2663 Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible 2664 Authentication Protocol (EAP) Application", draft-ietf-aaa- 2665 eap-10 (work in progress), November 2004. 2667 [I-D.puthenkulam-eap-binding] 2668 Puthenkulam, J., "The Compound Authentication Binding 2669 Problem", draft-puthenkulam-eap-binding-04 (work in progress), 2670 October 2003. 2672 [I-D.arkko-pppext-eap-aka] 2673 Arkko, J. and H. Haverinen, "EAP AKA Authentication", draft- 2674 arkko-pppext-eap-aka-15.txt (work in progress), December 2004. 2676 [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", draft- 2677 ietf-ipsec-ikev2-17 (work in progress), September 2004. 2679 [8021XHandoff] 2680 Pack, S. and Y. Choi, "Pre-Authenticated Fast Handoff in a 2681 Public Wireless LAN Based on IEEE 802.1X Model", School of 2682 Computer Science and Engineering, Seoul National University, 2683 Seoul, Korea, 2002. 2685 [MD5Attack] 2686 Dobbertin, H., "The Status of MD5 After a Recent Attack", 2687 CryptoBytes, Vol.2 No.2, 1996. 2689 [Housley56] 2690 Housley, R., "Key Management in AAA", Presentation to the AAA 2691 WG at IETF 56, 2692 http://www.ietf.org/proceedings/03mar/slides/aaa-5/index.html, 2693 March 2003. 2695 Acknowledgments 2697 Thanks to Arun Ayyagari, Ashwin Palekar, and Tim Moore of Microsoft, 2698 Dorothy Stanley of Agere, Bob Moskowitz of TruSecure, Jesse Walker of 2699 Intel, Joe Salowey of Cisco and Russ Housley of Vigil Security for 2700 useful feedback. 2702 Author Addresses 2704 Bernard Aboba 2705 Microsoft Corporation 2706 One Microsoft Way 2707 Redmond, WA 98052 2709 EMail: bernarda@microsoft.com 2710 Phone: +1 425 706 6605 2711 Fax: +1 425 936 7329 2713 Dan Simon 2714 Microsoft Research 2715 Microsoft Corporation 2716 One Microsoft Way 2717 Redmond, WA 98052 2719 EMail: dansimon@microsoft.com 2720 Phone: +1 425 706 6711 2721 Fax: +1 425 936 7329 2723 Jari Arkko 2724 Ericsson 2725 Jorvas 02420 2726 Finland 2728 Phone: 2729 EMail: jari.arkko@ericsson.com 2731 Pasi Eronen 2732 Nokia Research Center 2733 P.O. Box 407 2734 FIN-00045 Nokia Group 2735 Finland 2736 EMail: pasi.eronen@nokia.com 2738 Henrik Levkowetz (editor) 2739 ipUnplugged AB 2740 Arenavagen 27 2741 Stockholm S-121 28 2742 SWEDEN 2744 Phone: +46 708 32 16 08 2745 EMail: henrik@levkowetz.com 2747 Appendix A - Ciphersuite Keying Requirements 2749 To date, PPP and IEEE 802.11 ciphersuites are suitable for keying by 2750 EAP. This Appendix describes the keying requirements of common PPP 2751 and 802.11 ciphersuites. 2753 PPP ciphersuites include DESEbis [RFC2419], 3DES [RFC2420], and MPPE 2754 [RFC3078]. The DES algorithm is described in [FIPSDES], and DES 2755 modes (such as CBC, used in [RFC2419] and DES-EDE3-CBC, used in 2756 [RFC2420]) are described in [DESMODES]. For PPP DESEbis, a single 2757 56-bit encryption key is required, used in both directions. For PPP 2758 3DES, a 168-bit encryption key is needed, used in both directions. As 2759 described in [RFC2419] for DESEbis and [RFC2420] for 3DES, the IV, 2760 which is different in each direction, is "deduced from an explicit 2761 64-bit nonce, which is exchanged in the clear during the [ECP] 2762 negotiation phase." There is therefore no need for the IV to be 2763 provided by EAP. 2765 For MPPE, 40-bit, 56-bit or 128-bit encryption keys are required in 2766 each direction, as described in [RFC3078]. No initialization vector 2767 is required. 2769 While these PPP ciphersuites provide encryption, they do not provide 2770 per-packet authentication or integrity protection, so an 2771 authentication key is not required in either direction. 2773 Within [IEEE-802.11], Transient Session Keys (TSKs) are required both 2774 for unicast traffic as well as for multicast traffic, and therefore 2775 separate key hierarchies are required for unicast keys and multicast 2776 keys. IEEE 802.11 ciphersuites include WEP-40, described in 2777 [IEEE-802.11], which requires a 40-bit encryption key, the same in 2778 either direction; and WEP-128, which requires a 104-bit encryption 2779 key, the same in either direction. These ciphersuites also do not 2780 support per-packet authentication and integrity protection. In 2781 addition to these unicast keys, authentication and encryption keys 2782 are required to wrap the multicast encryption key. 2784 Recently, new ciphersuites have been proposed for use with IEEE 2785 802.11 that provide per-packet authentication and integrity 2786 protection as well as encryption [IEEE-802.11i]. These include TKIP, 2787 which requires a single 128-bit encryption key and two 64-bit 2788 authentication keys (one for each direction); and AES CCMP, which 2789 requires a single 128-bit key (used in both directions) in order to 2790 authenticate and encrypt data. 2792 As with WEP, authentication and encryption keys are also required to 2793 wrap the multicast encryption (and possibly, authentication) keys. 2795 Appendix B - Transient EAP Key (TEK) Hierarchy 2797 Figure B-1 illustrates the TEK key hierarchy for EAP-TLS [RFC2716], 2798 which is based on the TLS key hierarchy described in [RFC2246]. The 2799 TLS-negotiated ciphersuite is used to set up a protected channel for 2800 use in protecting the EAP conversation, keyed by the derived TEKs. 2801 The TEK derivation proceeds as follows: 2803 master_secret = TLS-PRF-48(pre_master_secret, "master secret", 2804 client.random || server.random) 2805 TEK = TLS-PRF-X(master_secret, "key expansion", 2806 server.random || client.random) 2807 Where: 2808 TLS-PRF-X = TLS pseudo-random function defined in [RFC2246], 2809 computed to X octets. 2811 | | | 2812 | | pre_master_secret | 2813 server| | | client 2814 Random| V | Random 2815 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2816 | | | | 2817 | | | | 2818 +---->| master_secret |<------+ 2819 | | (TMS) | | 2820 | | | | 2821 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2822 | | | 2823 | | | 2824 | | | 2825 V V V 2826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2827 | | 2828 | | 2829 | Key Block | 2830 | (TEKs) | 2831 | | 2832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2833 | | | | | | 2834 | client | server | client | server | client | server 2835 | MAC | MAC | write | write | IV | IV 2836 | | | | | | 2837 V V V V V V 2839 Figure B-1 - TLS [RFC2246] Key Hierarchy 2841 Appendix C - EAP-TLS Key Hierarchy 2843 In EAP-TLS [RFC2716], the MSK is divided into two halves, 2844 corresponding to the "Peer to Authenticator Encryption Key" (Enc- 2845 RECV-Key, 32 octets, also known as the PMK) and "Authenticator to 2846 Peer Encryption Key" (Enc-SEND-Key, 32 octets). In [RFC2548], the 2847 Enc-RECV-Key (the PMK) is transported in the MS-MPPE-Recv-Key 2848 attribute, and the Enc-SEND-Key is transported in the MS-MPPE-Send- 2849 Key attribute. 2851 The EMSK is also divided into two halves, corresponding to the "Peer 2852 to Authenticator Authentication Key" (Auth-RECV-Key, 32 octets) and 2853 "Authenticator to Peer Authentication Key" (Auth-SEND-Key, 32 2854 octets). The IV is a 64 octet quantity that is a known value; octets 2855 0-31 are known as the "Peer to Authenticator IV" or RECV-IV, and 2856 Octets 32-63 are known as the "Authenticator to Peer IV", or SEND-IV. 2858 In EAP-TLS, the MSK, EMSK and IV are derived from the TLS master 2859 secret via a one-way function. This ensures that the TLS master 2860 secret cannot be derived from the MSK, EMSK or IV unless the one-way 2861 function (TLS PRF) is broken. Since the MSK is derived from the the 2862 TLS master secret, if the TLS master secret is compromised then the 2863 MSK is also compromised. 2865 The key derivation scheme specified in RFC 2716 that was specified 2866 prior to the introduction of the terminology MSK and EMSK MUST be 2867 interpreted as follows: 2869 MSK = TLS-PRF-64(TMS, "client EAP encryption", 2870 client.random || server.random) 2871 EMSK = second 64 octets of: 2872 TLS-PRF-128(TMS, "client EAP encryption", 2873 client.random || server.random) 2874 IV = TLS-PRF-64("", "client EAP encryption", 2875 client.random || server.random) 2877 AAA-Key(0,31) = Peer to Authenticator Encryption Key (Enc-RECV-Key) 2878 (MS-MPPE-Recv-Key in [RFC2548]). Also known as the 2879 PMK. 2880 AAA-Key(32,63)= Authenticator to Peer Encryption Key (Enc-SEND-Key) 2881 (MS-MPPE-Send-Key in [RFC2548]) 2882 EMSK(0,31) = Peer to Authenticator Authentication Key (Auth-RECV-Key) 2883 EMSK(32,63) = Authenticator to Peer Authentication Key (Auth-Send-Key) 2884 IV(0,31) = Peer to Authenticator Initialization Vector (RECV-IV) 2885 IV(32,63) = Authenticator to Peer Initialization vector (SEND-IV) 2887 Where: 2889 AAA-Key(W,Z) = Octets W through Z includes of the AAA-Key. 2890 IV(W,Z) = Octets W through Z inclusive of the IV. 2891 MSK(W,Z) = Octets W through Z inclusive of the MSK. 2892 EMSK(W,Z) = Octets W through Z inclusive of the EMSK. 2893 TMS = TLS master_secret 2894 TLS-PRF-X = TLS PRF function defined in [RFC2246] computed to X octets 2895 client.random = Nonce generated by the TLS client. 2896 server.random = Nonce generated by the TLS server. 2898 Figure C-1 describes the process by which the MSK,EMSK,IV and 2899 ultimately the TSKs, are derived from the TLS Master Secret. 2901 ---+ 2902 | ^ 2903 | TLS Master Secret (TMS) | 2904 | | 2905 V | 2906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2907 | | EAP | 2908 | Master Session Key (MSK) | Method | 2909 | Derivation | | 2910 | | V 2911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ EAP ---+ 2912 | | | API ^ 2913 | MSK | EMSK | IV | 2914 | | | | 2915 V V V v 2916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 2917 | | | 2918 | | | 2919 | backend authentication server | | 2920 | | | 2921 | | V 2922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 2923 | | ^ 2924 | AAA-Key(0,31) | AAA-Key(32,63) | 2925 | (PMK) | Transported | 2926 | | via AAA | 2927 | | | 2928 V V V 2929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 2930 | | ^ 2931 | Ciphersuite-Specific Transient Session | Auth.| 2932 | Key Derivation | | 2933 | | V 2934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 2936 Figure C-1 - EAP TLS [RFC2716] Key hierarchy 2938 Appendix D - Example Transient Session Key (TSK) Derivation 2940 Within IEEE 802.11 RSN, the Pairwise Transient Key (PTK), a transient 2941 session key used to protect unicast traffic, is derived from the PMK 2942 (octets 0-31 of the MSK), known in [RFC2716] as the Peer to 2943 Authenticator Encryption Key. In [IEEE-802.11i], the PTK is derived 2944 from the PMK via the following formula: 2946 PTK = EAPOL-PRF-X(PMK, "Pairwise key expansion", Min(AA,SA) || 2947 Max(AA, SA) || Min(ANonce,SNonce) || Max(ANonce,SNonce)) 2949 Where: 2951 PMK = AAA-Key(0,31) 2952 SA = Station MAC address (Calling-Station-Id) 2953 AA = Access Point MAC address (Called-Station-Id) 2954 ANonce = Access Point Nonce 2955 SNonce = Station Nonce 2956 EAPOL-PRF-X = Pseudo-Random Function based on HMAC-SHA1, generating 2957 a PTK of size X octets. 2959 TKIP uses X = 64, while CCMP, WRAP, and WEP use X = 48. 2961 The EAPOL-Key Confirmation Key (KCK) is used to provide data origin 2962 authenticity in the TSK derivation. It utilizes the first 128 bits 2963 (bits 0-127) of the PTK. The EAPOL-Key Encryption Key (KEK) provides 2964 confidentiality in the TSK derivation. It utilizes bits 128-255 of 2965 the PTK. Bits 256-383 of the PTK are used by Temporal Key 1, and Bits 2966 384-511 are used by Temporal Key 2. Usage of TK1 and TK2 is 2967 ciphersuite specific. Details are available in [IEEE-802.11i]. 2969 Appendix E - Key Names and Scope in Existing Methods 2971 This appendix specifies the key names and scope in methods that have 2972 been published prior to the publication of this RFC. What is needed 2973 in addition to the rules in Section 2.4 is the definition of what EAP 2974 peer and server names are used, what Method-Id is used, and how these 2975 are encoded. 2977 EAP-TLS 2979 The EAP-TLS Method-Id is provided by the concatenation of the peer 2980 and server nonces. 2982 Where certificates are used, the Session-Id scope is determined via 2983 the EAP peer and server names, deduced from the altSubjectName in the 2984 peer and server certificates. 2986 Issue: What happens if a pre-shaked key ciphersuite is negotiated? 2987 How are the EAP peer and server names determined? 2989 EAP-AKA 2991 The EAP-AKA Method-Id is the contents of the RAND field from the 2992 AT_RAND attribute, followed by the contents of the AUTN field in the 2993 AT_AUTN attribute. 2995 The EAP peer name is the contents of the Identity field from the 2996 AT_IDENTITY attribute, using only the Actual Identity Length octets 2997 from the beginning, however. Note that the contents are used as they 2998 are transmitted, regardless of whether the transmitted identity was a 2999 permanent, pseudonym, or fast reauthentication identity. The EAP 3000 server name is an empty string. 3002 EAP-SIM 3004 The Method-Id is the contents of the RAND field from the AT_RAND 3005 attribute, followed by the contents of the NONCE_MT field in the 3006 AT_NONCE_MT attribute. 3008 The EAP peer name is the contents of the Identity field from the 3009 AT_IDENTITY attribute, using only the Actual Identity Length octets 3010 from the beginning, however. Note that the contents are used as they 3011 are transmitted, regardless of whether the transmitted identity was a 3012 permanent, pseudonym, or fast reauthentication identity. The EAP 3013 server name is an empty string. 3015 Appendix F - Security Association Examples 3017 EAP Method SA Example: EAP-TLS 3019 In EAP-TLS [RFC2716], after the EAP authentication the client (peer) 3020 and server can store the following information: 3022 o Implicitly, the EAP method this SA refers to (EAP-TLS) 3023 o Session identifier (a value selected by the server) 3024 o Certificate of the other party (server stores the client's 3025 certificate and vice versa) 3026 o Ciphersuite and compression method 3027 o TLS Master secret (known as the EAP-TLS Master Key) 3028 o SA lifetime (ensuring that the SA is not stored forever) 3029 o If the client has multiple different credentials (certificates 3030 and corresponding private keys), a pointer to those credentials 3032 When the server initiates EAP-TLS, the client can look up the EAP-TLS 3033 SA based on the credentials it was going to use (certificate and 3034 private key), and the expected credentials (certificate or name) of 3035 the server. If an EAP-TLS SA exists, and it is not too old, the 3036 client informs the server about the existence of this SA by including 3037 its Session-Id in the TLS ClientHello message. The server then looks 3038 up the correct SA based on the Session-Id (or detects that it doesn't 3039 yet have one). 3041 EAP Method SA Example: EAP-AKA 3043 In EAP-AKA [I-D.arkko-pppext-eap-aka], after EAP authentication the 3044 client and server can store the following information: 3046 o Implicitly, the EAP method this SA refers to (EAP-AKA) 3047 o A re-authentication pseudonym 3048 o The client's permanent identity (IMSI) 3049 o Replay protection counter 3050 o Authentication key (K_aut) 3051 o Encryption key (K_encr) 3052 o Original Master Key (MK) 3053 o SA lifetime (ensuring that the SA is not stored forever) 3055 When the server initiates EAP-AKA, the client can look up the EAP-AKA 3056 SA based on the credentials it was going to use (permanent identity). 3057 If an EAP-AKA SA exists, and it is not too old, the client informs 3058 the server about the existence of this SA by sending its re- 3059 authentication pseudonym as its identity in EAP Identity Response 3060 message, instead of its permanent identity. The server then looks up 3061 the correct SA based on this identity. 3063 AAA SA Example: RADIUS 3065 In RADIUS, where shared secret authentication is used, the client and 3066 server store each other's IP address and the shared secret, which is 3067 used to calculate the Response Authenticator [RFC2865] and Message- 3068 Authenticator [RFC3579] values, and to encrypt some attributes (such 3069 as the AAA-Key, see [RFC3580] Section 3.16). 3071 Where IPsec is used to protect RADIUS [RFC3579] and IKE is used for 3072 key management, the parties store information necessary to 3073 authenticate and authorize the other party (e.g. certificates, trust 3074 anchors and names). The IKE exchange results in IKE Phase 1 and Phase 3075 2 SAs containing information used to protect the conversation 3076 (session keys, selected ciphersuite, etc.) 3078 AAA SA Example: Diameter with TLS 3080 When using Diameter protected by TLS, the parties store information 3081 necessary to authenticate and authorize the other party (e.g. 3082 certificates, trust anchors and names). The TLS handshake results in 3083 a short-term TLS SA that contains information used to protect the 3084 actual communications (session keys, selected TLS ciphersuite, etc.). 3086 Service SA Example: 802.11i 3088 [IEEE802.11i] Section 8.4.1.1 defines the security associations used 3089 within IEEE 802.11. A summary follows; the standard should be 3090 consulted for details. 3092 o Pairwise Master Key Security Association (PMKSA) 3094 The PMKSA is a bi-directional SA, used by both parties for sending 3095 and receiving. The PMKSA is the Root Service SA. It is created 3096 on the peer when EAP authentication completes successfully or a 3097 pre-shared key is configured. The PMKSA is created on the 3098 authenticator when the PMK is received or created on the 3099 authenticator or a pre-shared key is configured. The PMKSA is 3100 used to create the PTKSA. PMKSAs are cached for their lifetimes. 3101 The PMKSA consists of the following elements: 3103 - PMKID (security association identifier) 3104 - Authenticator MAC address 3105 - PMK 3106 - Lifetime 3107 - Authenticated Key Management Protocol (AKMP) 3108 - Authorization parameters specified by the AAA server or 3109 by local configuration. This can include 3110 parameters such as the peer's authorized SSID. 3112 On the peer, this information can be locally 3113 configured. 3114 - Key replay counters (for EAPOL-Key messages) 3115 - Reference to PTKSA (if any), needed to: 3116 o delete it (e.g. AAA server-initiated disconnect) 3117 o replace it when a new four-way handshake is done 3118 - Reference to accounting context, the details of which depend 3119 on the accounting protocol used, the implementation 3120 and administrative details. In RADIUS, this could include 3121 (e.g. packet and octet counters, and Acct-Multi-Session-Id). 3123 o Pairwise Transient Key Security Association (PTKSA) 3125 The PTKSA is a bi-directional SA created as the result of a 3126 successful four-way handshake. The PTKSA is a unicast service SA. 3127 There may only be one PTKSA between a pair of peer and 3128 authenticator MAC addresses. PTKSAs are cached for the lifetime 3129 of the PMKSA. Since the PTKSA is tied to the PMKSA, it only has 3130 the additional information from the 4-way handshake. The PTKSA 3131 consists of the following: 3133 - Key (PTK) 3134 - Selected ciphersuite 3135 - MAC addresses of the parties 3136 - Replay counters, and ciphersuite specific state 3137 - Reference to PMKSA: This is needed when: 3138 o A new four-way handshake is needed (lifetime, TKIP 3139 countermeasures), and we need to know which PMKSA to use 3141 o Group Transient Key Security Association (GTKSA) 3143 The GTKSA is a uni-directional SA created based on the four-way 3144 handshake or the group key handshake. The GTKSA is a multicast 3145 service SA. A GTKSA consists of the following: 3147 - Direction vector (whether the GTK is used for transmit or receive) 3148 - Group cipher suite selector 3149 - Key (GTK) 3150 - Authenticator MAC address 3151 - Via reference to PMKSA, or copied here: 3152 o Authorization parameters 3153 o Reference to accounting context 3155 Service SA Example: IKEv2/IPsec 3157 Note that this example is intended to be informative, and it does 3158 not necessarily include all information stored. 3160 o IKEv2 SA 3162 - Protocol version 3163 - Identities of the parties 3164 - IKEv2 SPIs 3165 - Selected ciphersuite 3166 - Replay protection counters (Message ID) 3167 - Keys for protecting IKEv2 messages (SK_ai/SK_ar/SK_ei/SK_er) 3168 - Key for deriving keys for IPsec SAs (SK_d) 3169 - Lifetime information 3170 - On the authenticator, service authorization information 3171 received from the backend authentication server. 3173 When processing an incoming message, the correct SA is looked up 3174 based on the SPIs. 3176 o IPsec SAs/SPD 3178 - Traffic selectors 3179 - Replay protection counters 3180 - Selected ciphersuite 3181 - IPsec SPI 3182 - Keys 3183 - Lifetime information 3184 - Protocol mode (tunnel or transport) 3186 The correct SA is looked up based on SPI (for inbound packets), or 3187 SPD traffic selectors (for outbound traffic). A separate IPsec SA 3188 exists for each direction. 3190 Intellectual Property Statement 3192 The IETF takes no position regarding the validity or scope of any 3193 intellectual property or other rights that might be claimed to 3194 pertain to the implementation or use of the technology described in 3195 this document or the extent to which any license under such rights 3196 might or might not be available; neither does it represent that it 3197 has made any effort to identify any such rights. Information on the 3198 IETF's procedures with respect to rights in standards-track and 3199 standards-related documentation can be found in BCP-11. Copies of 3200 claims of rights made available for publication and any assurances of 3201 licenses to be made available, or the result of an attempt made to 3202 obtain a general license or permission for the use of such 3203 proprietary rights by implementors or users of this specification can 3204 be obtained from the IETF Secretariat. 3206 The IETF invites any interested party to bring to its attention any 3207 copyrights, patents or patent applications, or other proprietary 3208 rights which may cover technology that may be required to practice 3209 this standard. Please address the information to the IETF Executive 3210 Director. 3212 Disclaimer of Validity 3214 This document and the information contained herein are provided on an 3215 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3216 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 3217 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 3218 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 3219 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3220 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3222 Copyright Statement 3224 Copyright (C) The Internet Society (2005). This document is subject 3225 to the rights, licenses and restrictions contained in BCP 78, and 3226 except as set forth therein, the authors retain all their rights. 3228 Open Issues 3230 Open issues relating to this specification are tracked on the 3231 following web site: 3233 http://www.drizzle.com/~aboba/EAP/eapissues.html