idnits 2.17.00 (12 Aug 2021) /tmp/idnits53785/draft-ietf-eap-keying-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 877 has weird spacing: '...backend authe...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (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.) -- The document date (October 27, 2003) is 6781 days in the past. Is this intentional? 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 961 -- Looks like a reference, but probably isn't: '2' on line 964 -- Looks like a reference, but probably isn't: '3' on line 969 -- Looks like a reference, but probably isn't: '4' on line 975 == Unused Reference: 'RFC2434' is defined on line 1845, but no explicit reference was found in the text == Unused Reference: 'RFC0793' is defined on line 1860, but no explicit reference was found in the text == Unused Reference: 'RFC1321' is defined on line 1863, but no explicit reference was found in the text == Unused Reference: 'RFC2104' is defined on line 1869, but no explicit reference was found in the text == Unused Reference: 'RFC2855' is defined on line 1899, but no explicit reference was found in the text == Unused Reference: 'RFC2960' is defined on line 1905, but no explicit reference was found in the text == Unused Reference: 'RFC3079' is defined on line 1913, but no explicit reference was found in the text == Unused Reference: 'RFC3394' is defined on line 1916, but no explicit reference was found in the text == Unused Reference: 'FIPS197' is defined on line 1938, but no explicit reference was found in the text == Unused Reference: 'EAPAPI' is defined on line 2000, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) == Outdated reference: draft-ietf-eap-rfc2284bis has been published as RFC 3748 -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802' -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- 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 2960 (Obsoleted by RFC 4960) -- 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: draft-ietf-aaa-eap has been published as RFC 4072 == Outdated reference: A later version (-04) exists of draft-irtf-aaaarch-handoff-03 == Outdated reference: draft-orman-public-key-lengths has been published as RFC 3766 == Outdated reference: A later version (-04) exists of draft-puthenkulam-eap-binding-03 -- Unexpected draft version: The latest known version of draft-aboba-802-context is -02, but you're referring to -03. (However, the state information for draft-puthenkulam-eap-binding is not up-to-date. The last update was 2022-05-20) == Outdated reference: draft-arkko-pppext-eap-aka has been published as RFC 4187 Summary: 2 errors (**), 0 flaws (~~), 20 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 EAP Working Group B. Aboba 3 Internet-Draft D. Simon 4 Expires: April 26, 2004 Microsoft 5 J. Arkko 6 Ericsson 7 H. Levkowetz, Ed. 8 ipUnplugged 9 October 27, 2003 11 EAP Key Management Framework 12 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress". 28 The list of current Internet-Drafts can be accessed at http:// 29 www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on April 26, 2004. 36 Copyright Notice 38 Copyright (C) The Internet Society (2003). All Rights Reserved. 40 Abstract 42 This document provides a framework for EAP key management, including 43 a statement of applicability and guidelines for generation, transport 44 and usage of EAP keying material. Algorithms for key derivation or 45 mechanisms for key transport are not specified in this document. 46 Rather, this document provides a framework within which algorithms 47 and transport mechanisms can be discussed and evaluated. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 52 1.1 Requirements Language . . . . . . . . . . . . . . . . 4 53 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . 4 54 1.3 Conversation Overview . . . . . . . . . . . . . . . . 6 55 1.3.1 Discovery Phase . . . . . . . . . . . . . . . . 7 56 1.3.2 Authentication Phase . . . . . . . . . . . . . . 8 57 1.3.3 Secure Association Phase . . . . . . . . . . . . 9 58 1.4 Authorization issues . . . . . . . . . . . . . . . . . 9 59 1.4.1 Correctness in fast handoff . . . . . . . . . . 11 60 2. EAP Key Hierarchy . . . . . . . . . . . . . . . . . . . . . 13 61 2.1 EAP Invariants . . . . . . . . . . . . . . . . . . . . 14 62 2.1.1 Media Independence . . . . . . . . . . . . . . . 14 63 2.1.2 Method Independence . . . . . . . . . . . . . . 14 64 2.1.3 Ciphersuite Independence . . . . . . . . . . . . 14 65 2.2 Key Hierarchy . . . . . . . . . . . . . . . . . . . . 15 66 2.3 Exchanges . . . . . . . . . . . . . . . . . . . . . . 19 67 3. Security Associations . . . . . . . . . . . . . . . . . . . 22 68 3.1 EAP SA (peer - EAP server) . . . . . . . . . . . . . . 23 69 3.2 EAP method SA (peer - EAP server) . . . . . . . . . . 23 70 3.2.1 Example: EAP-TLS . . . . . . . . . . . . . . . . 24 71 3.2.2 Example: EAP-AKA . . . . . . . . . . . . . . . . 24 72 3.3 EAP-key SA . . . . . . . . . . . . . . . . . . . . . . 25 73 3.4 AAA SA(s) (authenticator - backend auth. server) . . . 25 74 3.4.1 Example: RADIUS . . . . . . . . . . . . . . . . 25 75 3.4.2 Example: Diameter with TLS . . . . . . . . . . . 25 76 3.5 Unicast Secure Association SA . . . . . . . . . . . . 26 77 3.6 Multicast Secure Association SA . . . . . . . . . . . 27 78 3.7 Key Naming . . . . . . . . . . . . . . . . . . . . . . 28 79 4. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 29 80 4.1 Security Assumptions . . . . . . . . . . . . . . . . . 29 81 4.2 Security Requirements . . . . . . . . . . . . . . . . 32 82 4.2.1 EAP method requirements . . . . . . . . . . . . 32 83 4.2.2 AAA Protocol Requirements . . . . . . . . . . . 34 84 4.2.3 Secure Association Protocol Requirements . . . . 36 85 4.2.4 Ciphersuite Requirements . . . . . . . . . . . . 37 86 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 38 87 6. Security Considerations . . . . . . . . . . . . . . . . . . 38 88 6.1 Key Strength . . . . . . . . . . . . . . . . . . . . . 38 89 6.2 Key Wrap . . . . . . . . . . . . . . . . . . . . . . . 38 90 6.3 Man-in-the-middle Attacks . . . . . . . . . . . . . . 39 91 6.4 Impersonation . . . . . . . . . . . . . . . . . . . . 39 92 6.5 Denial of Service Attacks . . . . . . . . . . . . . . 40 93 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41 94 Normative References . . . . . . . . . . . . . . . . . . . . 41 95 Informative References . . . . . . . . . . . . . . . . . . . 41 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 45 98 A. Ciphersuite Keying Requirements . . . . . . . . . . . . . . 46 99 B. Transient EAP Key (TEK) Hierarchy . . . . . . . . . . . . . 47 100 C. MSK and EMSK Hierarchy . . . . . . . . . . . . . . . . . . . 48 101 D. Transient Session Key (TSK) Derivation . . . . . . . . . . . 51 102 E. AAA-Key Derivation . . . . . . . . . . . . . . . . . . . . . 52 103 F. Open issues . . . . . . . . . . . . . . . . . . . . . . . . 53 104 Intellectual Property and Copyright Statements . . . . . . . 54 106 1. Introduction 108 The Extensible Authentication Protocol (EAP), defined in 109 [I-D.ietf-eap-rfc2284bis], was designed to enable extensible 110 authentication for network access in situations in which the IP 111 protocol is not available. Originally developed for use with PPP 112 [RFC1661], it has subsequently also been applied to IEEE 802 wired 113 networks [IEEE8021X]. 115 This document provides a framework for the generation, transport and 116 usage of keying material generated by EAP authentication algorithms, 117 known as "methods". Since in EAP keying material is generated by EAP 118 methods, transported by AAA protocols, transformed into session keys 119 by secure association protocols and used by lower layer ciphersuites, 120 it is necessary to describe each of these elements and provide a 121 system-level security analysis. 123 1.1 Requirements Language 125 In this document, several words are used to signify the requirements 126 of the specification. These words are often capitalized. The key 127 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 128 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 129 are to be interpreted as described in BCP 14 [RFC2119]. 131 1.2 Terminology 133 This document frequently uses the following terms: 135 authenticator 136 The end of the link initiating EAP authentication. Where no 137 backend authentication server is present, the authenticator acts 138 as the EAP server, terminating the EAP conversation with the peer. 139 Where a backend authentication server is present, the 140 authenticator may act as a pass-through for one or more 141 authentication methods and for non-local users. This terminology 142 is also used in [IEEE8021X], and has the same meaning in this 143 document. 145 backend authentication server 146 A backend authentication server is an entity that provides an 147 authentication service to an authenticator. When used, this 148 server typically executes EAP Methods for the authenticator. This 149 terminology is also used in [IEEE8021X]. 151 AAA-Token 152 The package within which keying material and one or more 153 attributes is transported between the backend authentication 154 server and the authenticator. The attributes provide the 155 authenticator with usage context and key names suitable to bind 156 the key to the appropriate context. The format and wrapping of the 157 AAA-Token, which is intended to be accessible only to the backend 158 authentication server and authenticator, is defined by the AAA 159 protocol. Examples include RADIUS [RFC2548], and Diameter 160 [I-D.ietf-aaa-eap]. 162 Cryptographic binding 163 The demonstration of the EAP peer to the EAP server that a single 164 entity has acted as the EAP peer for all methods executed within a 165 sequence or tunnel. Binding MAY also imply that the EAP server 166 demonstrates to the peer that a single entity has acted as the EAP 167 server for all methods executed within a sequence or tunnel. If 168 executed correctly, binding serves to mitigate man-in-the-middle 169 vulnerabilities. 171 Cryptographic separation 172 Two keys (x and y) are "cryptographically separate" if an 173 adversary that knows all messages exchanged in the protocol cannot 174 compute x from y or y from x without "breaking" some cryptographic 175 assumption. In particular, this definition allows that the 176 adversary has the knowledge of all nonces sent in cleartext as 177 well as all predictable counter values used in the protocol. 178 Breaking a cryptographic assumption would typically require 179 inverting a one-way function or predicting the outcome of a 180 cryptographic pseudo-random number generator without knowledge of 181 the secret state. In other words, if the keys are 182 cryptographically separate, there is no shortcut to compute x from 183 y or y from x. 185 EAP server 186 The entity which terminates EAP authentication with the peer is 187 known as the EAP server. Where pass-through is supported, the 188 backend authentication server functions as the EAP server; where 189 authentication occurs locally, the EAP server is the 190 authenticator. 192 AAA-Key 193 A key derived by the EAP peer and EAP server and transported to 194 the authenticator. In 802.11 terminology, the first 32 octets of 195 the AAA-Key is known as the Pairwise Master Key (PMK). 197 Key strength 198 If the effective key strength is N bits, the best currently known 199 methods to recover the key (with non-negligible probability) 200 require an effort comparable to 2^N operations of a typical block 201 cipher. 203 Mutual authentication 204 This refers to an EAP method in which, within an interlocked 205 exchange, the authenticator authenticates the peer and the peer 206 authenticates the authenticator. Two one-way conversations, 207 running in opposite directions do not provide mutual 208 authentication as defined here. 210 peer 211 The end of the link that responds to the authenticator. In 212 [IEEE8021X], this end is known as the Supplicant. 214 1.3 Conversation Overview 216 Where EAP key derivation is supported, EAP authentication is 217 typically a component of a three phase exchange: 219 Discovery phase (phase 0) 220 EAP authentication, key derivation and transport (phase 1) 221 Unicast and multicast secure association establishment (phase 2) 223 In the discovery phase (phase 0), the EAP peers locate each other 224 and discover their capabilities. This can include an EAP peer 225 locating an authenticator suitable for access to a particular 226 network, or it could involve an EAP peer locating an authenticator 227 behind a bridge with which it desires to establish a secure 228 association. Typically the discovery phase takes place between the 229 EAP peer and authenticator. 231 Once the EAP peer and authenticator discover each other, EAP 232 authentication may begin (phase 1a). EAP enables deployment of new 233 authentication methods without requiring development of new code on 234 the authenticator. While the authenticator may implement some EAP 235 methods locally and use those methods to authenticate local users, it 236 may at the same time act as a pass-through for other users and 237 methods, forwarding EAP packets back and forth between the backend 238 authentication server and the peer. 240 As described in Section 2, in addition to supporting authentication, 241 EAP methods may also support derivation of keying material for 242 purposes including protection of the EAP conversation and subsequent 243 data exchanges. EAP key derivation takes place between the EAP peer 244 and EAP server, and methods supporting key derivation MUST also 245 support mutual authentication. Where an authenticator server is 246 present, it acts as the EAP server and transports derived keying 247 material (known as the AAA-Key) to the authenticator (phase 1b). 249 EAP methods may mutually authenticate and derive keys. However a 250 distinct secure association exchange is required in order to manage 251 the creation and deletion of unicast (phase 2a) and multicast (phase 252 2b) security associations between the EAP peer and authenticator. 254 The phases and the relationship between the parties is illustrated 255 below. 257 EAP peer Authenticator Auth. Server 258 -------- ------------- ------------ 259 |<----------------------------->| | 260 | Discovery (phase 0) | | 261 |<----------------------------->|<----------------------------->| 262 | EAP auth (phase 1a) | AAA pass-through (optional) | 263 | | | 264 | |<----------------------------->| 265 | | AAA-Key transport | 266 | | (optional; phase 1b) | 267 |<----------------------------->| | 268 | Unicast Secure association | | 269 | (phase 2a) | | 270 | | | 271 |<----------------------------->| | 272 | Multicast Secure association | | 273 | (optional; phase 2b) | | 274 | | | 276 Figure 1: Conversation Overview 278 1.3.1 Discovery Phase 280 In the peer discovery exchange (phase 0), the EAP peer and 281 authenticator locate each other and discover each other's 282 capabilities. For example, PPPoE [RFC2516] includes support for a 283 Discovery Stage to allow a peer to identify the Ethernet MAC address 284 of one or more authenticators and establish a PPPoE SESSION_ID. In 285 IEEE 802.11 [IEEE80211], the EAP peer (also known as the Station or 286 STA) discovers the authenticator (Access Point or AP) and determines 287 its capabilities using Beacon or Probe Request/Response frames. 288 Since device discovery is handled outside of EAP, there is no need to 289 provide this functionality within EAP. 291 Device discovery can occur manually or automatically. In EAP 292 implementations running over PPP, the EAP peer might be configured 293 with a phone book providing phone numbers of authenticators and 294 associated capabilities such as supported rates, authentication 295 protocols or ciphersuites. 297 Since device discovery can occur prior to authentication and key 298 derivation, it may not be possible for the discovery phase to be 299 protected using keying material derived during an authentication 300 exchange. As a result, device discovery protocols may be insecure, 301 leaving them vulnerable to spoofing unless the discovered parameters 302 can subsequently be securely verified. 304 1.3.2 Authentication Phase 306 Once the EAP peer and authenticator discover each other, they 307 exchange EAP packets. Typically, the peer desires access to the 308 network, and the authenticators are Network Access Servers (NASes) 309 providing that access. In such a situation, access to the network 310 can be provided by any authenticator attaching to the desired 311 network, and the EAP peer is typically willing to send data traffic 312 through any authenticator that can demonstrate that it is authorized 313 to provide access to the desired network. 315 An EAP authenticator may handle the authentication locally, or it may 316 act as a pass-through to a backend authentication server. In the 317 latter case the EAP exchange occurs between the EAP peer and a 318 backend authenticator server, with the authenticator forwarding EAP 319 packets between the two. The entity which terminates EAP 320 authentication with the peer is known as the EAP server. Where 321 pass-through is supported, the backend authentication server 322 functions as the EAP server; where authentication occurs locally, the 323 EAP server is the authenticator. Where a backend authentication 324 server is present, at the successful completion of an authentication 325 exchange, the AAA-Key is transported to the authenticator (phase 1b). 327 EAP may also be used when it is desired for two network devices (e.g. 328 two switches or routers) to authenticate each other, or where two 329 peers desire to authenticate each other and set up a secure 330 association suitable for protecting data traffic. 332 Some EAP methods exist which only support one-way authentication; 333 however, EAP methods deriving keys are required to support mutual 334 authentication. In either case, it can be assumed that the parties 335 do not utilize the link to exchange data traffic unless their 336 authentication requirements have been met. For example, a peer 337 completing mutual authentication with an EAP server will not send 338 data traffic over the link until the EAP server has authenticated 339 successfully to the peer, and a secure association has been 340 negotiated. 342 Since EAP is a peer-to-peer protocol, an independent and simultaneous 343 authentication may take place in the reverse direction. Both peers 344 may act as authenticators and authenticatees at the same time. 346 Successful completion of EAP authentication and key derivation by an 347 EAP peer and EAP server does not necessarily imply that the peer is 348 committed to joining the network associated with an EAP server. 349 Rather, this commitment is implied by the creation of a security 350 association between the EAP peer and authenticator, as part of the 351 secure association protocol (phase 2). As a result, EAP may be used 352 for "pre-authentication" in situations where it is necessary to 353 pre-establish EAP security associations in order to decrease handoff 354 or roaming latency. 356 1.3.3 Secure Association Phase 358 The secure association phase (phase 2) always occurs after the 359 completion of EAP authentication (phase 1a) and key transport (phase 360 1b), and typically supports the following features: 362 [1] The secure negotiation of capabilities. This includes usage 363 modes, session parameters and ciphersuites, and required filters, 364 including confirmation of the capabilities discovered during 365 phase 0. By securely negotiating session parameters, the secure 366 association protocol protects against spoofing during the 367 discovery phase and ensures that the peer and authenticator are 368 in agreement about how data is to be secured. 370 [2] Generation of fresh transient session keys. This is typically 371 accomplished via the exchange of nonces within the secure 372 association protocol, and includes generation of both unicast 373 (phase 2a) and multicast (phase 2b) session keys. By not using 374 the AAA-Key directly to protect data, the secure association 375 protocol protects against compromise of the AAA-Key, and by 376 guaranteeing the freshness of transient session key, assures that 377 session keys are not reused. 379 [3] Key activation and deletion. 381 [4] Mutual proof of possession of the AAA-Key. This demonstrates 382 that both the EAP peer and authenticator have been authenticated 383 and authorized by the AAA server. Since mutual proof of 384 possession is not the same as mutual authentication, the EAP peer 385 cannot verify authenticator assertions (including the 386 authenticator identity) as a result of this exchange. 388 1.4 Authorization issues 390 In a typical network access scenario (dial-in, wireless LAN, etc.) 391 access control mechanisms are typically applied. These mechanisms 392 include user authentication as well as authorization for the offered 393 service. 395 As a part of the authentication process, the AAA network determines 396 the user's authorization profile. The user authorizations are 397 transmitted by the AAA server to the EAP authenticator (also known as 398 the Network Access Server or NAS) included with the AAA-Token, which 399 also contains the AAA-Key, in Phase 1b of the EAP conversation. 400 Typically, the profile is determined based on the user identity, but 401 a certificate presented by the user may also provide authorization 402 information. 404 The AAA server is responsible for making a user authorization 405 decision, answering the following questions: 407 o Is this a legitimate user for this particular network? 409 o Is this user allowed the type of access he or she is requesting? 411 o Are there any specific parameters (mandatory tunneling, bandwidth, 412 filters, and so on) that the access network should be aware of for 413 this user? 415 o Is this user within the subscription rules regarding time of day? 417 o Is this user within his limits for concurrent sessions? 419 o Are there any fraud, credit limit, or other concerns that indicate 420 that access should be denied? 422 While the authorization decision is in principle simple, the process 423 is complicated by the distributed nature of AAA decision making. 424 Where brokering entities or proxies are involved, all of the AAA 425 devices in the chain from the NAS to the home AAA server are involved 426 in the decision. For instance, a broker can disallow access even if 427 the home AAA server would allow it, or a proxy can add authorizations 428 (e.g., bandwidth limits). 430 Decisions can be based on static policy definitions and profiles as 431 well as dynamic state (e.g. time of day or limits on the number of 432 concurrent sessions). In addition to the Accept/Reject decision made 433 by the AAA chain, parameters or constraints can be communicated to 434 the NAS. 436 The criteria for Accept/Reject decisions or the reasons for choosing 437 particular authorizations are typically not communicated to the NAS, 438 only the final result. As a result, the NAS has no way to know what 439 the decision was based on. Was a set of authorization parameters 440 sent because this service is always provided to the user, or was the 441 decision based on the time/day and the capabilities of the requesting 442 NAS device? 444 Within EAP, "fast handoff" is defined as a conversation in which the 445 EAP exchange (phase 1a) and associated AAA passthrough is bypassed, 446 so as to reduce latency. Depending on the fast handoff mechanism, 447 AAA-Key transport (phase 1b) may also be bypassed in favor a context 448 transfer (see [IEEE80211f] and [I-D.aboba-802-context]) or it may be 449 provided in a pre-emptive manner as in [IEEE-03-084] and 450 [I-D.irtf-aaaarch-handoff]. 452 As we will discuss, the introduction of fast handoff creates a new 453 class of security vulnerabilities as well as requirements for the 454 secure handling of authorization context. 456 1.4.1 Correctness in fast handoff 458 Bypassing all or portions of the AAA conversation creates challenges 459 in ensuring that authorization is properly handled. These include: 461 o Consistent application of session time limits. A fast handoff 462 should not automatically increase the available session time, 463 allowing a user to endlessly extend their network access by 464 changing the point of attachment. 466 o Avoidance of privilege elevation. A fast handoff should not 467 result in a user being granted access to services which they are 468 not entitled to. 470 o Consideration of dynamic state. In situations in which dynamic 471 state is involved in the access decision (day/time, simultaneous 472 session limit) it should be possible to take this state into 473 account either before or after access is granted. Note that 474 consideration of network-wide state such as simultaneous session 475 limits can typically only be taken into account by the AAA server. 477 o Encoding of restrictions. Since a NAS may not be aware of the 478 criteria considered by a AAA server when allowing access, in order 479 to ensure consistent authorization during a fast handoff it may be 480 necessary to explicitly encode the restrictions within the 481 authorizations provided in the AAA-Token. 483 o State validity. The introduction of fast handoff should not 484 render the authentication server incapable of keeping track of 485 network-wide state. 487 A fast handoff mechanism capable of addressing these concerns is said 488 to be "correct". One condition for correctness is as follows: 490 For a fast handoff to be "correct" it MUST establish on the new 491 device the same context as would have been created had the new device 492 completed a AAA conversation with the authentication server. 494 A properly designed fast handoff scheme will only succeed if it is 495 "correct" in this way. If a successful fast handoff would establish 496 "incorrect" state, it is preferable for it to fail, in order to avoid 497 creation of incorrect context. 499 Some AAA server and NAS configurations are incapable of meeting this 500 definition of "correctness". For example, if the old and new device 501 differ in their capabilities, it may be difficult to meet this 502 definition of correctness in a fast handoff mechanism that bypasses 503 AAA. AAA servers often perform conditional evaluation, in which the 504 authorizations returned in an Access-Accept message are contingent on 505 the NAS or on dynamic state such as the time of day or number of 506 simultaneous sessions. For example, in a heterogeneous deployment, 507 the AAA server might return different authorizations depending on the 508 NAS making the request, in order to make sure that the requested 509 service is consistent with the NAS capabilities. 511 If differences between the new and old device would result in the AAA 512 server sending a different set of messages to the new device than 513 were sent to the old device, then if the fast handoff mechanism 514 bypasses AAA, then the fast handoff cannot be carried out correctly. 516 For example, if some NAS devices within a deployment support dynamic 517 VLANs while others do not, then attributes present in the 518 Access-Request (such as the NAS-IP-Address, NAS-Identifier, 519 Vendor-Identifier, etc.) could be examined to determine when VLAN 520 attributes will be returned, as described in [RFC3580]. VLAN 521 support is defined in [IEEE8021Q]. If a fast handoff bypassing the 522 AAA server were to occur between a NAS supporting dynamic VLANs and 523 another NAS which does not, then a guest user with access restricted 524 to a guest VLAN could be given unrestricted access to the network. 526 Similarly, in a network where access is restricted based on the day 527 and time, SSID, Calling-Station-Id or other factors, unless the 528 restrictions are encoded within the authorizations, or a partial AAA 529 conversation is included, then a fast handoff could result in the 530 user bypassing the restrictions. 532 In practice, these considerations limit the situations in which fast 533 handoff mechanisms bypassing AAA can be expected to be successful. 534 Where the deployed devices implement the same set of services, it may 535 be possible to do successful fast handoffs within such mechanisms. 536 However, where the supported services differ between devices, the 537 fast handoff may not succeed. For example, [RFC2865], section 1.1 538 states: 540 "A NAS that does not implement a given service MUST NOT implement 541 the RADIUS attributes for that service. For example, a NAS that 542 is unable to offer ARAP service MUST NOT implement the RADIUS 543 attributes for ARAP. A NAS MUST treat a RADIUS access-accept 544 authorizing an unavailable service as an access-reject instead." 546 Note that this behavior only applies to attributes that are known, 547 but not implemented. For attributes that are unknown, section of 5 548 of [RFC2865] states: 550 "A RADIUS server MAY ignore Attributes with an unknown Type. A 551 RADIUS client MAY ignore Attributes with an unknown Type." 553 In order to perform a correct fast handoff, if a new device is 554 provided with RADIUS context for a known but unavailable service, 555 then it MUST process this context the same way it would handle a 556 RADIUS Access-Accept requesting an unavailable service. This MUST 557 cause the fast handoff to fail. However, if a new device is provided 558 with RADIUS context that indicates an unknown attribute, then this 559 attribute MAY be ignored. 561 Although it may seem somewhat counter-intuitive, failure is indeed 562 the "correct" result where a known but unsupported service is 563 requested. Presumably a correctly configured AAA server would not 564 request that a device carry out a service that it does not implement. 565 This implies that if the new device were to complete a AAA 566 conversation that it would be likely to receive different service 567 instructions. In such a case, failure of the fast handoff is the 568 desired result. This will cause the new device to go back to the AAA 569 server in order to receive the appropriate service definition. 571 In practice, this implies that fast handoff mechanisms which bypass 572 AAA are most likely to be successful within a homogeneous device 573 deployment within a single administrative domain. For example, it 574 would not be advisable to carry out a fast handoff bypassing AAA 575 between a NAS providing confidentiality and another NAS that does not 576 support this service. The correct result of such a fast handoff 577 would be a failure, since if the handoff were blindly carried out, 578 then the user would be moved from a secure to an insecure channel 579 without permission from the AAA server. Thus the definition of a 580 "known but unsupported service" MUST encompass requests for 581 unavailable security services. This includes vendor-specific 582 attributes related to security, such as those described in 583 [RFC2548]." 585 2. EAP Key Hierarchy 587 2.1 EAP Invariants 589 The EAP key management framework assumes that certain basic 590 characteristics, known as the "EAP Invariants" hold true for all 591 implementations of EAP. These include: 593 Media independence 594 Method independence 595 Ciphersuite independence 597 2.1.1 Media Independence 599 As described in [I-D.ietf-eap-rfc2284bis], EAP authentication can run 600 over multiple lower layers, including PPP [RFC1661] and IEEE 802 601 wired networks [IEEE8021X]. Use with IEEE 802.11 wireless LANs is 602 also contemplated [IEEE80211i]. Since EAP methods cannot be assumed 603 to have knowledge of the lower layer over which they are transported, 604 EAP methods can function on any lower layer meeting the criteria 605 outlined in [I-D.ietf-eap-rfc2284bis], Section 3.1. As a result, EAP 606 methods should not utilize identifiers associated with a particular 607 usage environment (e.g. MAC addresses). 609 2.1.2 Method Independence 611 Supporting pass-through of authentication to the backend 612 authentication server enables the authenticator to support any 613 authentication method implemented on the backend authentication 614 server and peer, not just locally implemented methods. 616 This implies that the authenticator need not implement code for each 617 EAP method required by authenticating peers. In fact, the 618 authenticator is not required to implement any EAP methods at all, 619 nor can it be assumed to implement code specific to any EAP method. 621 This is useful where there is no single EAP method that is both 622 mandatory-to-implement and offers acceptable security for the media 623 in use. For example, the [I-D.ietf-eap-rfc2284bis] 624 mandatory-to-implement EAP method (MD5-Challenge) does not provide 625 dictionary attack resistance, mutual authentication or key 626 derivation, and as a result is not appropriate for use in wireless 627 authentication. 629 2.1.3 Ciphersuite Independence 631 While EAP methods may negotiate the ciphersuite used in protection of 632 the EAP conversation, the ciphersuite used for the protection of data 633 is negotiated within the secure association protocol, out-of-band of 634 EAP. The backend authentication server is not a party to this 635 negotiation nor is it an intermediary in the data flow between the 636 EAP peer and authenticator. The backend authentication server may 637 not even have knowledge of the ciphersuites implemented by the peer 638 and authenticator, or be aware of the ciphersuite negotiated between 639 them, and therefore does not implement ciphersuite-specific code. 641 Since ciphersuite negotiation occurs in the secure association 642 protocol, not in EAP, ciphersuite-specific key generation, if 643 implemented within an EAP method, would potentially conflict with the 644 transient session key derivation occurring in the secure association 645 protocol. As a result, EAP methods generate keying material that is 646 ciphersuite-independent. Additional advantages of 647 ciphersuite-independence include: 649 Update requirements 650 If EAP methods were to specify how to derive transient session 651 keys for each ciphersuite, they would need to be updated each time 652 a new ciphersuite is developed. In addition, backend 653 authentication servers might not be usable with all EAP-capable 654 authenticators, since the backend authentication server would also 655 need to be updated each time support for a new ciphersuite is 656 added to the authenticator. 658 EAP method complexity 659 Requiring each EAP method to include ciphersuite-specific code for 660 transient session key derivation would increase the complexity of 661 each EAP method and would result in duplicated effort. 663 Knowledge of capabilities 664 In practice, an EAP method may not have knowledge of the 665 ciphersuite that has been negotiated between the peer and 666 authenticator. In PPP, ciphersuite negotiation occurs in the 667 Encryption Control Protocol (ECP) [RFC1968]. Since ECP 668 negotiation occurs after authentication, unless an EAP method is 669 utilized that supports ciphersuite negotiation, the peer, 670 authenticator and backend authentication server may not be able to 671 anticipate the negotiated ciphersuite and therefore this 672 information cannot be provided to the EAP method. Since 673 ciphersuite negotiation is assumed to occur out-of-band, there is 674 no need for ciphersuite negotiation within EAP. 676 2.2 Key Hierarchy 678 The EAP keying hierarchy, illustrated in Figure 2, makes use of the 679 following types of keys: 681 EAP Master key (MK) 682 A key derived between the EAP client and server during the EAP 683 authentication process, and that is kept local to the EAP method 684 and not exported or made available to a third party. 686 Master Session Key (MSK) 687 Keying material (at least 64 octets) that is derived between the 688 EAP client and server and exported by the EAP method. 690 AAA-Key 691 Where a backend authentication server is present, acting as an EAP 692 server, keying material known as the AAA-Key is transported from 693 the authentication server to the authenticator wrapped within the 694 AAA-Token. The AAA-Key is used by the EAP peer and authenticator 695 in the derivation of Transient Session Keys (TSKs) for the 696 ciphersuite negotiated between the EAP peer and authenticator. As 697 a result, the AAA-Key is typically known by all parties in the EAP 698 exchange: the peer, authenticator and the authentication server 699 (if present). AAA-Key derivation is discussed in Appendix E. 701 Extended Master Session Key (EMSK) 702 Additional keying material (64 octets) derived between the EAP 703 client and server that is exported by the EAP method. The EMSK is 704 known only to the EAP peer and server and is not provided to a 705 third party. 707 Initialization Vector (IV) 708 A quantity of at least 64 octets, suitable for use in an 709 initialization vector field, that is derived between the EAP 710 client and server. Since the IV is a known value in methods such 711 as EAP-TLS [RFC2716], it cannot be used by itself for computation 712 of any quantity that needs to remain secret. As a result, its use 713 has been deprecated and EAP methods are not required to generate 714 it. 716 Pairwise Master Key (PMK) 717 The AAA-Key is divided into two halves, the "Peer to Authenticator 718 Encryption Key" (Enc-RECV-Key) and "Authenticator to Peer 719 Encryption Key" (Enc-SEND-Key) (reception is defined from the 720 point of view of the authenticator). Within [IEEE80211i] Octets 721 0-31 of the AAA-Key (Enc-RECV-Key) are known as the Pairwise 722 Master Key (PMK). IEEE 802.11i ciphersuites [IEEE80211i] derive 723 their Transient Session Keys (TSKs) solely from the PMK, whereas 724 the WEP ciphersuite, when used with [IEEE8021X], as noted in 725 [RFC3580], derives its TSKs from both halves of the AAA-Key, the 726 Enc-RECV-Key and the Enc-SEND-Key. 728 Transient EAP Keys (TEKs) 729 Session keys which are used to establish a protected channel 730 between the EAP peer and server during the EAP authentication 731 exchange. The TEKs are appropriate for use with the ciphersuite 732 negotiated between EAP peer and server for use in protecting the 733 EAP conversation. Note that the ciphersuite used to set up the 734 protected channel between the EAP peer and server during EAP 735 authentication is unrelated to the ciphersuite used to 736 subsequently protect data sent between the EAP peer and 737 authenticator. An example TEK key hierarchy is described in 738 Appendix C. 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 741 | | ^ 742 | EAP Method | | 743 | | | 744 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 745 | | | | | 746 | | EAP Method Key | | | 747 | | Derivation | | | 748 | | | | Local | 749 | | | | to EAP | 750 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Method | 751 | | | | | | 752 | | | | | | 753 | | | | | | 754 | | | | | | 755 | V | | | | 756 | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | | 757 | | TEK | | MSK | |EMSK | |IV | | | 758 | |Derivation | |Derivation | |Derivation | |Derivation | | | 759 | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | | 760 | | | | | | 761 | | | | | V 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 763 | | | ^ 764 | MSK (64B) | EMSK (64B) | IV (64B) | 765 | | | | 766 | | | Exported | 767 | | | by EAP | 768 V V V Method | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | 770 | AAA Key Derivation, | | Known | | 771 | Naming & Binding | |(Not Secret) | | 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ V 773 | ---+ 774 | Transported | 775 | AAA-Key by AAA | 776 | Protocol | 777 V V 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 779 | | ^ 780 | TSK | Ciphersuite | 781 | Derivation | Specific | 782 | | V 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 785 Figure 2: EAP Key Hierarchy 787 Transient Session Keys (TSKs) 788 Session keys used to protect data which are appropriate for the 789 ciphersuite negotiated between the EAP peer and authenticator. 790 The TSKs are derived from the keying material included in the 791 AAA-Token via the secure association protocol. In the case of IEEE 792 802.11, the role of the secure association protocol is handled by 793 the 4-way handshake and group key derivation. An example TSK 794 derivation is provided in Appendix D. 796 2.3 Exchanges 798 EAP supports both a two party exchange between an EAP peer and an 799 authenticator, as well as a three party exchange between an EAP peer, 800 an authenticator and an EAP server. 802 Figure 3 illustrates the two party exchange. Here EAP is spoken 803 between the peer and authenticator, encapsulated within a lower layer 804 protocol, such as PPP, defined in [RFC1661] or IEEE 802, defined in 805 [IEEE802]. 807 Since the authenticator acts as an endpoint of the EAP conversation 808 rather than a pass-through, EAP methods are implemented on the 809 authenticator as well as the peer. If the EAP method negotiated 810 between the EAP peer and authenticator supports mutual authentication 811 and key derivation, the EAP Master Session Key (MSK) and Extended 812 Master Session Key (EMSK) are derived on the EAP peer and 813 authenticator and exported by the EAP method. 815 Where no backend authentication server is present, the MSK and EMSK 816 are known only to the peer and authenticator and neither is 817 transported to a third party. As demonstrated in 818 [I-D.ietf-roamops-cert], despite the absence of a backend 819 authentication server, such exchanges can support roaming between 820 providers; it is even possible to support fast handoff without 821 re-authentication. However, this is typically only possible where 822 both the EAP peer and authenticator support certificate-based 823 authentication, or where the user base is sufficiently small that EAP 824 authentication can occur locally. 826 In order to protect the EAP conversation, the EAP method may 827 negotiate a ciphersuite and derive Transient EAP Keys (TEKs) to 828 provide keys for that ciphersuite in order to protect some or all of 829 the EAP exchange. The TEKs are stored locally within the EAP method 830 and are not exported. 832 Once EAP mutual authentication completes and is successful, the 833 secure association protocol is run between the peer and 834 authenticator. This derives fresh transient session keys (TSKs), 835 provides for the secure negotiation of the ciphersuite used to 836 protect data, and supports mutual proof of possession of the AAA-Key. 838 +-+-+-+-+-+ +-+-+-+-+-+ 839 | | | | 840 | Cipher- | | Cipher- | 841 | Suite | | Suite | 842 | | | | 843 +-+-+-+-+-+ +-+-+-+-+-+ 844 ^ ^ 845 | | 846 V V 847 +-+-+-+-+-+ +-+-+-+-+-+ 848 | | | | 849 | |===============| | 850 | |EAP, TEK Deriv.|Authenti-| 851 | |<------------->| cator | 852 | | | | 853 | | Secure Assoc. | | 854 | peer |<------------->| (EAP | 855 | |===============| server) | 856 | | Link layer | | 857 | | (PPP,IEEE802) | | 858 | | | | 859 |MSK,EMSK | |MSK,EMSK | 860 | (TSKs) | | (TSKs) | 861 | | | | 862 +-+-+-+-+-+ +-+-+-+-+-+ 863 ^ ^ 864 | | 865 | MSK, EMSK | MSK, EMSK 866 | | 867 +-+-+-+-+-+ +-+-+-+-+-+ 868 | | | | 869 | EAP | | EAP | 870 | Method | | Method | 871 | | | | 872 |(MK,TEKs)| |(MK,TEKs)| 873 | | | | 874 +-+-+-+-+-+ +-+-+-+-+-+ 876 Figure 3: Relationship between EAP peer and authenticator (acting as 877 an EAP server), where no backend authentication server is present. 879 +-+-+-+-+-+ +-+-+-+-+-+ 880 | | | | 881 | | | | 882 | Cipher- | | Cipher- | 883 | Suite | | Suite | 884 | | | | 885 +-+-+-+-+-+ +-+-+-+-+-+ 886 ^ ^ 887 | | 888 | | 889 | | 890 V V 891 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 892 | |===============| |========| | 893 | |EAP, TEK Deriv.| | | | 894 | |<-------------------------------->| backend | 895 | | | | | | 896 | | Secure Assoc. | | AAA-Key| | 897 | peer |<------------->|Authenti-|<-------| auth | 898 | |===============| cator |========| server | 899 | | Link Layer | | AAA | (EAP | 900 | | (PPP,IEEE 802)| |Protocol| server) | 901 | | | | | | 902 |MSK,EMSK | | MSK | |MSK,EMSK | 903 | (TSKs) | | (TSKs) | | | 904 | | | | | | 905 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 906 ^ ^ 907 | | 908 | MSK, EMSK | MSK, EMSK 909 | | 910 | | 911 +-+-+-+-+-+ +-+-+-+-+-+ 912 | | | | 913 | EAP | | EAP | 914 | Method | | Method | 915 | | | | 916 |(MK,TEKs)| |(MK,TEKs)| 917 | | | | 918 +-+-+-+-+-+ +-+-+-+-+-+ 920 Figure 4: Pass-through relationship between EAP peer, authenticator 921 and backend authentication server. 923 Where these conditions cannot be met, a backend authentication server 924 is typically required. In this exchange, as described in [RFC3579], 925 the authenticator acts as a pass-through between the EAP peer and a 926 backend authentication server. In this model, the authenticator 927 delegates the access control decision to the backend authentication 928 server, which acts as a Key Distribution Center (KDC), supplying 929 keying material to both the EAP peer and authenticator. 931 Figure 4 illustrates the case where the authenticator acts as a 932 pass-through. Here EAP is spoken between the peer and authenticator 933 as before. The authenticator then encapsulates EAP packets within a 934 AAA protocol such as RADIUS [RFC3579] or Diameter [I-D.ietf-aaa-eap], 935 and forwards packets to and from the backend authentication server, 936 which acts as the EAP server. Since the authenticator acts as a 937 pass-through, EAP methods (as well as the derived EAP Master Key, and 938 TEKs) reside only on the peer and backend authentication server. 940 On completion of a successful authentication, EAP methods on the EAP 941 peer and EAP server export the Master Session Key (MSK) and Extended 942 Master Session Key (EMSK). The backend authentication server then 943 sends a message to the authenticator indicating that authentication 944 has been successful, providing the AAA-Key within a protected package 945 known as the AAA-Token. Along with the keying material, the 946 AAA-Token contains attributes naming the enclosed keys and providing 947 context. 949 The MSK and EMSK are used to derive the AAA-Key and key name which 950 are enclosed within the AAA-Token, transported to the NAS by the AAA 951 server, and used within the secure association protocol for 952 derivation of Transient Session Keys (TSKs) required for the 953 negotiated ciphersuite. The TSKs are known only to the peer and 954 authenticator. 956 3. Security Associations 958 EAP key management involves four types of security associations 959 (SAs): 961 [1] EAP SA. This is an SA between the peer and EAP server, which 962 allows them to authenticate each other. 964 [2] EAP method SA. This SA is also between the peer and EAP server. 965 It stores state that can be used for "fast resume" or other 966 functionality in some EAP methods. Not all EAP methods create 967 such an SA. 969 [3] EAP-Key SA. This is an SA between the peer and EAP server, which 970 is used to store the keying material exported by the EAP method. 971 Current EAP server implementations do not retain this SA after 972 the EAP conversation completes, but future implementations could 973 use this SA for pre-emptive key distribution. 975 [4] AAA SA(s). These SAs are between the authenticator and the 976 backend authentication server. They permit the parties to 977 mutually authenticate each other and protect the communications 978 between them. 980 3.1 EAP SA (peer - EAP server) 982 In order for the peer and EAP server to authenticate each other, they 983 need to store some information. 985 The authentication can be based on different mechanisms, such as 986 shared secrets or certificates. If the authentication is based on a 987 shared secret key, the parties store the EAP method to be used and 988 the key. The EAP server also stores the peer's identity and/or other 989 information necessary to decide whether access to some service should 990 be granted. The peer stores information necessary to choose which 991 secret to use for which service. 993 3.2 EAP method SA (peer - EAP server) 995 An EAP method may store some state on the peer and EAP server even 996 after phase 1a has completed. 998 Typically, this is used for "fast resume": the peer and EAP server 999 can confirm that they are still talking to the same party, perhaps 1000 using fewer roundtrips or less computational power. In this case, 1001 the EAP method SA is essentially a cache for performance 1002 optimization, and either party may remove the SA from its cache at 1003 any point. 1005 An EAP method may also keep state in order to support pseudonym-based 1006 identity protection. This is typically a cache as well (the 1007 information can be recreated if the original EAP method SA is lost), 1008 but may be stored for longer periods of time. 1010 The EAP method SA is not restricted to a particular service or 1011 authenticator and is most useful when the peer accesses many 1012 different authenticators. 1014 An EAP method is responsible for specifying how the parties select if 1015 an existing EAP method SA should be used, and if so, which one. 1016 Where multiple backend authentication servers are used, EAP method 1017 SAs are not typically synchronized between them. 1019 EAP method implementations should consider the appropriate lifetime 1020 for the EAP method SA. "Fast resume" assumes that the information 1021 required (primarily the keys in the EAP method SA) hasn't been 1022 compromised. In case the original authentication was carried out 1023 using, for instance, a smart card, it may be easier to compromise the 1024 EAP method SA (stored on the PC, for instance), so typically the EAP 1025 method SAs have a limited lifetime. 1027 Contents: 1028 o Implicitly, the EAP method this SA refers to 1029 o One or more internal (non-exported) keys 1030 o EAP method SA name 1031 o SA lifetime 1033 3.2.1 Example: EAP-TLS 1035 In EAP-TLS [RFC2716], after the EAP authentication the client (peer) 1036 and server can store the following information: 1038 o Implicitly, the EAP method this SA refers to (EAP-TLS) 1039 o Session identifier (a value selected by the server) 1040 o Certificate of the other party (server stores the clients's 1041 certificate and vice versa) 1042 o Ciphersuite and compression method 1043 o TLS Master secret (known as the EAP-TLS Master Key or MK) 1044 o SA lifetime (ensuring that the SA is not stored forever) 1045 o If the client has multiple different credentials (certificates and 1046 corresponding private keys), a pointer to those credentials 1048 When the server initiates EAP-TLS, the client can look up the EAP-TLS 1049 SA based on the credentials it was going to use (certificate and 1050 private key), and the expected credentials (certificate or name) of 1051 the server. If an EAP-TLS SA exists, and it is not too old, the 1052 client informs the server about the existence of this SA by including 1053 its Session-Id in the TLS ClientHello message. The server then looks 1054 up the correct SA based on the Session-Id (or detects that it doesn't 1055 yet have one). 1057 3.2.2 Example: EAP-AKA 1059 In EAP-AKA [I-D.arkko-pppext-eap-aka], after EAP authentication the 1060 client and server can store the following information: 1062 o Implicitly, the EAP method this SA refers to (EAP-AKA) 1063 o A re-authentication pseudonym 1064 o The client's permanent identity (IMSI) (server) 1065 o Replay protection counter 1066 o Authentication key (K_aut) 1067 o Encryption key (K_encr) 1068 o Original Master Key (MK) 1069 o SA lifetime (ensuring that the SA is not stored forever) 1071 When the server initiates EAP-AKA, the client can look up the EAP-AKA 1072 SA based on the credentials it was going to use (permanent identity). 1073 If an EAP-AKA SA exists, and it is not too old, the client informs 1074 the server about the existence of this SA by sending its 1075 re-authentication pseudonym as its identity in EAP Identity Response 1076 message, instead of its permanent identity. The server then looks up 1077 the correct SA based on this identity. 1079 3.3 EAP-key SA 1081 This is an SA between the peer and EAP server, which is used to store 1082 the keying material exported by the EAP method. Current EAP server 1083 implementations do not retain this SA after the EAP conversation 1084 completes, but future implementations could use this SA for 1085 pre-emptive key distribution. 1087 Contents: 1088 o Name/identifier for this SA 1089 o Identities of the parties 1090 o MSK and EMSK 1092 3.4 AAA SA(s) (authenticator - backend auth. server) 1094 In order for the authenticator and backend authentication server to 1095 authenticate each other, they need to store some information. 1097 In case the authenticator and backend authentication server are 1098 colocated, and they communicate using local procedure calls or shared 1099 memory, this SA need not necessarily contain any information. 1101 3.4.1 Example: RADIUS 1103 In RADIUS, where shared secret authentication is used, the client and 1104 server store each other's IP address and the shared secret, which is 1105 used to calculate the Response Authenticator [RFC2865] and 1106 Message-Authenticator [RFC3579] values, and to encrypt some 1107 attributes (such as the AAA-Key [RFC2548]). 1109 Where IPsec is used to protect RADIUS [RFC3579] and IKE is used for 1110 key management, the parties store information necessary to 1111 authenticate and authorize the other party (e.g. certificates, trust 1112 anchors and names). The IKE exchange results in IKE Phase 1 and 1113 Phase 2 SAs containing information used to protect the conversation 1114 (session keys, selected ciphersuite, etc.) 1116 3.4.2 Example: Diameter with TLS 1118 When using Diameter protected by TLS, the parties store information 1119 necessary to authenticate and authorize the other party (e.g. 1120 certificates, trust anchors and names). The TLS handshake results in 1121 a short-term TLS SA that contains information used to protect the 1122 actual communications (session keys, selected TLS ciphersuite, etc.). 1124 3.5 Unicast Secure Association SA 1126 The unicast secure association SA exists between the EAP peer and 1127 authenticator. It includes: 1129 the peer port identifier (Calling-Station-Id) 1130 the NAS port identifier (Called-Station-Id) 1131 the unicast Transient Session Keys (TSKs) 1132 the unicast secure association peer nonce 1133 the unicast secure association authenticator nonce 1134 the negotiated unicast capabilities and unicast ciphersuite. 1136 During the phase 2a exchange, the EAP peer and authenticator 1137 demonstrate mutual possession of the AAA-Key derived and transported 1138 in phase 1; securely negotiate the session capabilities (including 1139 unicast ciphersuites), and derive fresh unicast transient session 1140 keys. The AAA-Key SA (phase 1b) is therefore used to create the 1141 unicast secure association SA (phase 2a), and in the process the 1142 phase 2a unicast secure association SA is bound to ports on the EAP 1143 peer and authenticator. However in order for a phase 2a security 1144 association to be established, it is not necessary for the phase 1a 1145 exchange to be rerun each time. This enables the EAP exchange to be 1146 bypassed when fast handoff support is desired. 1148 Since both peer and authenticator nonces are used in the creation of 1149 the unicast secure association SA, the transient session keys (TSKs) 1150 are guaranteed to be fresh, even if the AAA-Key is not. As a result 1151 one or more unicast secure association SAs (phase 2a) may be derived 1152 from a single AAA-Key SA (phase 1b). The phase 2a security 1153 associations may utilize the same security parameters (e.g. mode, 1154 ciphersuite, etc.) or they may utilize different parameters. 1156 A unicast secure association SA (phase 2a) may not persist longer 1157 than the maximum lifetime of its parent AAA-Key SA (if known). 1158 However, the deletion of a parent EAP or AAA-Key SA does not 1159 necessarily imply deletion of the corresponding unicast secure 1160 association SA. Similarly, the deletion of a unicast secure 1161 association protocol SA does not imply the deletion of the parent 1162 AAA-key SA or EAP SA. Failure to mutually prove possession of the 1163 AAA-Key during the unicast secure association protocol exchange 1164 (phase 2a) need not be grounds for removal of a AAA-Key SA by both 1165 parties; rate-limiting unicast secure association exchanges should 1166 suffice to prevent a brute force attack. 1168 An EAP peer may be able to negotiate multiple phase 2a SAs with a 1169 single EAP authenticator, or may be able to maintain multiple phase 1170 2a SAs with multiple authenticators, based on a single EAP SA derived 1171 in phase 1a. For example, during a re-key of the secure association 1172 protocol SA, it is possible for two phase 2a SAs to exist during the 1173 period between when the new phase 2a SA parameters (such as the TSKs) 1174 are calculated and when they are installed. Except where explicitly 1175 specified by the semantics of the unicast secure association 1176 protocol, it should not be assumed that the installation of a new 1177 phase 2a SA necessarily implies deletion of the old phase 2a SA. 1179 On some media (e.g. 802.11) a port on an EAP peer may only establish 1180 phase 2a and 2b SAs with a single port of an authenticator within a 1181 given Local Area Network (LAN). This implies that the successful 1182 negotiation of phase 2a and/or 2b SAs between an EAP peer port and a 1183 new authentiator port within a given LAN implies the deletion of 1184 existing phase 2a and 2b SAs with authenticators offering access to 1185 that Local Area Network (LAN). However, since a given IEEE 802.11 1186 SSID may be comprised of multiple LANs, this does not imply an 1187 implicit binding of phase 2a and 2b SAs to an SSID. 1189 3.6 Multicast Secure Association SA 1191 The multicast secure association SA includes: 1193 the multicast Transient Session Keys 1194 the direction vector (for a uni-directional SA) 1195 the negotiated multicast capabilities and multicast ciphersuite 1197 It is possible for more than one multicast secure association SA to 1198 be derived from a single unicast secure association SA. However, a 1199 multicast secure association SA is bound to a single EAP SA and a 1200 single AAA-Key SA. 1202 During a re-key of the multicast secure association protocol SA, it 1203 is possible for two phase 2b SAs to exist during the period between 1204 when the new phase 2b SA parameters (such as the multicast TSKs) are 1205 calculated and when they are installed. Except where explicitly 1206 specified by the semantics of the multicast secure association 1207 protocol, it should not be assumed that the installation of a new 1208 phase 2b SA necessarily implies deletion of the old phase 2b SA. 1210 A multicast secure association SA (phase 2b) may not persist longer 1211 than the maximum lifetime of its parent AAA-Key or unicast secure 1212 association SA. However, the deletion of a parent EAP, AAA-Key or 1213 unicast secure association SA does not necessarily imply deletion of 1214 the corresponding multicast secure association SA. For example, a 1215 unicast secure association SA may be rekeyed without implying a rekey 1216 of the multicast secure association SA. 1218 Similarly, the deletion of a multicast secure association protocol SA 1219 does not imply the deletion of the parent EAP, AAA-Key or unicast 1220 secure association SA. Failure to mutually prove possession of the 1221 AAA-Key during the unicast secure association protocol exchange 1222 (phase 2a) need not be grounds for removal of the AAA-Key, unicast 1223 secure association and multicast secure association SAs; 1224 rate-limiting unicast secure association exchanges should suffice to 1225 prevent a brute force attack. 1227 3.7 Key Naming 1229 In order to support the correct processing of phase 2 security 1230 associations, the secure association (phase 2) protocol supports the 1231 naming of phase 2 security associations and associated transient 1232 session keys, so that the correct set of transient session keys can 1233 be identified for processing a given packet. Explicit creation and 1234 deletion operations are also typically supported so that 1235 establishment and re-establishment of transient session keys can be 1236 synchronized between the parties. 1238 In order to securely bind the AAA SA (phase 1b) to its child phase 2 1239 security associations, the phase 2 secure association protocol allows 1240 the EAP peer and authenticator to mutually prove possession of the 1241 AAA-Key. In order to avoid confusion in the case where an EAP peer 1242 has more than one AAA-Key (phase 1b) applicable to establishment of a 1243 phase 2 security association, it is necessary for the secure 1244 association protocol (phase 2) to support key selection, so that the 1245 appropriate phase 1b keying material can be utilized by both parties 1246 in the secure association protocol exchange. 1248 For example, a peer might be pre-configured with policy indicating 1249 the ciphersuite to be used in communicating with a given 1250 authenticator. Within PPP, the ciphersuite is negotiated within the 1251 Encryption Control Protocol (ECP), after EAP authentication is 1252 completed. Within [IEEE80211i], the AP ciphersuites are advertised 1253 in the Beacon and Probe Responses, and are securely verified during a 1254 4-way exchange after EAP authentication has completed. 1256 As part of the secure association protocol (phase 2), it is necessary 1257 to bind the Transient Session Keys (TSKs) to the keying material 1258 provided in the AAA-Token. This ensures that the EAP peer and 1259 authenticator are both clear about what key to use to provide mutual 1260 proof of possession. Keys within the EAP key hierarchy are named as 1261 follows: 1263 EAP SA name 1264 The EAP security association is negotiated between the EAP peer 1265 and EAP server, and is uniquely named as follows . Here the EAP peer name and EAP server name are the 1268 identifiers securely exchanged within the EAP method. Since 1269 multiple EAP SAs may exist between an EAP peer and EAP server, the 1270 EAP peer nonce and EAP server nonce allow EAP SAs to be 1271 differentiated. The inclusion of the Method Type in the EAP SA 1272 name ensures that each EAP method has a distinct EAP SA space. 1274 MK Name 1275 The EAP Master Key, if supported by an EAP method, is named by the 1276 concatenation of the EAP SA name and a method-specific session-id. 1278 AAA-Key Name 1279 The AAA-Key is named by the concatenation of the EAP SA name, 1280 "AAA-Key" and the authenticator name, since the AAA-Key is bound 1281 to a particular authenticator. For the purpose of identification, 1282 the NAS-Identifier attribute is recommended. In order to ensure 1283 that all parties can agree on the NAS name this requires the NAS 1284 to advertise its name (typically using a media-specific mechanism, 1285 such as the 802.11 Beacon/Probe Response)." 1287 4. Threat Model 1289 4.1 Security Assumptions 1291 Figure 5 illustrates the relationship between the peer, authenticator 1292 and backend authentication server. As noted in the figure, each party 1293 in the exchange mutually authenticates with each of the other 1294 parties, and derives a unique key. All parties in the diagram have 1295 access to the AAA-Key. 1297 EAP peer 1298 /\\ 1299 / \\ 1300 Protocol: EAP / \\ Protocol: Secure Association 1301 Auth: Mutual / \\ Auth: Mutual 1302 Unique keys: MK, / \\ Unique keys: TSKs 1303 TEKs,EMSK / \\ 1304 / \\ 1305 Auth. server +--------------+ Authenticator 1306 Protocol: AAA 1307 Auth: Mutual 1308 Unique key: AAA session key 1310 Figure 5: Three-party EAP key distribution 1312 The EAP peer and backend authentication server mutually authenticate 1313 via the EAP method, and derive the MK, TEKs and EMSK which are known 1314 only to them. The TEKs are used to protect some or all of the EAP 1315 conversation between the peer and authenticator, so as to guard 1316 against modification or insertion of EAP packets by an attacker. The 1317 degree of protection afforded by the TEKs is determined by the EAP 1318 method; some methods may protect the entire EAP packet, including the 1319 EAP header, while other methods may only protect the contents of the 1320 Type-Data field, defined in [I-D.ietf-eap-rfc2284bis]. 1322 Since EAP is spoken only between the EAP peer and server, if a 1323 backend authentication server is present then the EAP conversation 1324 does not provide mutual authentication between the peer and 1325 authenticator, only between the EAP peer and EAP server (backend 1326 authentication server). As a result, mutual authentication between 1327 the peer and authenticator only occurs where a secure association 1328 protocol is used, such the unicast and group key derivation handshake 1329 supported in [IEEE80211i]. This means that absent use of a secure 1330 association protocol, from the point of view of the peer, EAP mutual 1331 authentication only proves that the authenticator is trusted by the 1332 backend authentication server; the identity of the authenticator is 1333 not confirmed. 1335 Utilizing the AAA protocol, the authenticator and backend 1336 authentication server mutually authenticate and derive session keys 1337 known only to them, used to provide per-packet integrity and replay 1338 protection, authentication and confidentiality. The MSK is 1339 distributed by the backend authentication server to the authenticator 1340 over this channel, bound to attributes constraining its usage, as 1341 part of the AAA-Token. The binding of attributes to the MSK within a 1342 protected package is important so the authenticator receiving the 1343 AAA-Token can determine that it has not been compromised, and that 1344 the keying material has not been replayed, or mis-directed in some 1345 way. 1347 The security properties of the EAP exchange are dependent on each leg 1348 of the triangle: the selected EAP method, AAA protocol and the secure 1349 association protocol. 1351 Assuming that the AAA protocol provides protection against rogue 1352 authenticators forging their identity, then the AAA-Token can be 1353 assumed to be sent to the correct authenticator, and where it is 1354 wrapped appropriately, it can be assumed to be immune to compromise 1355 by a snooping attacker. 1357 Where an untrusted AAA intermediary is present, the AAA-Token must 1358 not be provided to the intermediary so as to avoid compromise of the 1359 AAA-Token. This can be avoided by use of re-direct as defined in 1360 [RFC3588]. 1362 When EAP is used for authentication on PPP or wired IEEE 802 1363 networks, it is typically assumed that the link is physically secure, 1364 so that an attacker cannot gain access to the link, or insert a rogue 1365 device. EAP methods defined in [I-D.ietf-eap-rfc2284bis] reflect this 1366 usage model. These include EAP MD5, as well as One-Time Password 1367 (OTP) and Generic Token Card. These methods support one-way 1368 authentication (from EAP peer to authenticator) but not mutual 1369 authentication or key derivation. As a result, these methods do not 1370 bind the initial authentication and subsequent data traffic, even 1371 when the the ciphersuite used to protect data supports per-packet 1372 authentication and integrity protection. As a result, EAP methods not 1373 supporting mutual authentication are vulnerable to session hijacking 1374 as well as attacks by rogue devices. 1376 On wireless networks such as IEEE 802.11 [IEEE80211], these attacks 1377 become easy to mount, since any attacker within range can access the 1378 wireless medium, or act as an access point. As a result, new 1379 ciphersuites have been proposed for use with wireless LANs 1380 [IEEE80211i] which provide per-packet authentication, integrity and 1381 replay protection. In addition, mutual authentication and key 1382 derivation, provided by methods such as EAP-TLS [RFC2716] are 1383 required [IEEE80211i], so as to address the threat of rogue devices, 1384 and provide keying material to bind the initial authentication to 1385 subsequent data traffic. 1387 If the selected EAP method does not support mutual authentication, 1388 then the peer will be vulnerable to attack by rogue authenticators 1389 and backend authentication servers. If the EAP method does not derive 1390 keys, then TSKs will not be available for use with a negotiated 1391 ciphersuite, and there will be no binding between the initial EAP 1392 authentication and subsequent data traffic, leaving the session 1393 vulnerable to hijack. 1395 If the backend authentication server does not protect against 1396 authenticator masquerade, or provide the proper binding of the 1397 AAA-Key to the session within the AAA-Token, then one or more 1398 AAA-Keys may be sent to an unauthorized party, and an attacker may be 1399 able to gain access to the network. If the AAA-Token is provided to 1400 an untrusted AAA intermediary, then that intermediary may be able to 1401 modify the AAA-Key, or the attributes associated with it, as 1402 described in [RFC2607]. 1404 If the secure association protocol does not provide mutual proof of 1405 possession of the AAA-Key material, then the peer will not have 1406 assurance that it is connected to the correct authenticator, only 1407 that the authenticator and backend authentication server share a 1408 trust relationship (since AAA protocols support mutual 1409 authentication). This distinction can become important when multiple 1410 authenticators receive AAA-Keys from the backend authentication 1411 server, such as where fast handoff is supported. If the TSK 1412 derivation does not provide for protected ciphersuite and 1413 capabilities negotiation, then downgrade attacks are possible. 1415 4.2 Security Requirements 1417 This section describes the security requirements for EAP methods, AAA 1418 protocols, secure association protocols and Ciphersuites. These 1419 requirements MUST be met by specifications requesting publication as 1420 an RFC. Based on these requirements, the security properties of EAP 1421 exchanges are analyzed. 1423 4.2.1 EAP method requirements 1425 It is possible for the peer and EAP server to mutually authenticate 1426 and derive keys. In order to provide keying material for use in a 1427 subsequently negotiated ciphersuite, an EAP method supporting key 1428 derivation MUST export a Master Session Key (MSK) of at least 64 1429 octets, and an Extended Master Session Key (EMSK) of at least 64 1430 octets. EAP Methods deriving keys MUST provide for mutual 1431 authentication between the EAP peer and the EAP Server. 1433 The MSK and EMSK MUST NOT be used directly to protect data; however, 1434 they are of sufficient size to enable derivation of a AAA-Key 1435 subsequently used to derive Transient Session Keys (TSKs) for use 1436 with the selected ciphersuite. Each ciphersuite is responsible for 1437 specifying how to derive the TSKs from the AAA-Key. 1439 The AAA-Key is derived from the keying material exported by the EAP 1440 method (MSK and EMSK). This derivation occurs on the AAA server. In 1441 many existing protocols that use EAP, the AAA-Key and MSK are 1442 equivalent, but more complicated mechanisms are possible (see 1443 Appendix E for details). 1445 EAP methods SHOULD ensure the freshness of the MSK and EMSK even in 1446 cases where one party may not have a high quality random number 1447 generator. A RECOMMENDED method is for each party to provide a nonce 1448 of at least 128 bits, used in the derivation of the MSK and EMSK. 1450 EAP methods export the MSK and EMSK and not Transient Session Keys so 1451 as to allow EAP methods to be ciphersuite and media independent. 1452 Keying material exported by EAP methods MUST be independent of the 1453 ciphersuite negotiated to protect data. 1455 Depending on the lower layer, EAP methods may run before or after 1456 ciphersuite negotiation, so that the selected ciphersuite may not be 1457 known to the EAP method. By providing keying material usable with 1458 any ciphersuite, EAP methods can used with a wide range of 1459 ciphersuites and media. 1461 It is RECOMMENDED that methods providing integrity protection of EAP 1462 packets include coverage of all the EAP header fields, including the 1463 Code, Identifier, Length, Type and Type-Data fields. 1465 In order to preserve algorithm independence, EAP methods deriving 1466 keys SHOULD support (and document) the protected negotiation of the 1467 ciphersuite used to protect the EAP conversation between the peer and 1468 server. This is distinct from the ciphersuite negotiated between the 1469 peer and authenticator, used to protect data. 1471 The strength of Transient Session Keys (TSKs) used to protect data is 1472 ultimately dependent on the strength of keys generated by the EAP 1473 method. If an EAP method cannot produce keying material of 1474 sufficient strength, then the TSKs may be subject to brute force 1475 attack. In order to enable deployments requiring strong keys, EAP 1476 methods supporting key derivation SHOULD be capable of generating an 1477 MSK and EMSK, each with an effective key strength of at least 128 1478 bits. 1480 Methods supporting key derivation MUST demonstrate cryptographic 1481 separation between the MSK and EMSK branches of the EAP key 1482 hierarchy. Without violating a fundamental cryptographic assumption 1483 (such as the non-invertibility of a one-way function) an attacker 1484 recovering the MSK or EMSK MUST NOT be able to recover the other 1485 quantity with a level of effort less than brute force. 1487 Non-overlapping substrings of the MSK MUST be cryptographically 1488 separate from each other. That is, knowledge of one substring MUST 1489 NOT help in recovering some other substring without breaking some 1490 hard cryptographic assumption. This is required because some 1491 existing ciphersuites form TSKs by simply splitting the AAA-Key to 1492 pieces of appropriate length. Likewise, non-overlapping substrings 1493 of the EMSK MUST be cryptographically separate from each other, and 1494 from substrings of the MSK. 1496 The EMSK MUST remain on the EAP peer and EAP server where it is 1497 derived; it MUST NOT be transported to, or shared with, additional 1498 parties, or used to derive any other keys. 1500 Since EAP does not provide for explicit key lifetime negotiation, EAP 1501 peers, authenticators and authentication servers MUST be prepared for 1502 situations in which one of the parties discards key state which 1503 remains valid on another party. 1505 The development and validation of key derivation algorithms is 1506 difficult, and as a result EAP methods SHOULD reuse well established 1507 and analyzed mechanisms for key derivation (such as those specified 1508 in IKE [RFC2409] or TLS [RFC2246]), rather than inventing new ones. 1509 EAP methods SHOULD also utilize well established and analyzed 1510 mechanisms for MSK and EMSK derivation. 1512 4.2.2 AAA Protocol Requirements 1514 AAA protocols suitable for use in transporting EAP MUST provide the 1515 following facilities: 1517 Security services 1518 AAA protocols used for transport of EAP keying material MUST 1519 implement and SHOULD use per-packet integrity and authentication, 1520 replay protection and confidentiality. These requirements are met 1521 by Diameter EAP [I-D.ietf-aaa-eap], as well as RADIUS over IPsec 1522 [RFC3579]. 1524 Session Keys 1525 AAA protocols used for transport of EAP keying material MUST 1526 implement and SHOULD use dynamic key management in order to derive 1527 fresh session keys, as in Diameter EAP [I-D.ietf-aaa-eap] and 1528 RADIUS over IPsec [RFC3579], rather than using a static key, as 1529 originally defined in RADIUS [RFC2865]. 1531 Mutual authentication 1532 AAA protocols used for transport of EAP keying material MUST 1533 provide for mutual authentication between the authenticator and 1534 backend authentication server. These requirements are met by 1535 Diameter EAP [I-D.ietf-aaa-eap] as well as by RADIUS EAP 1536 [RFC3579]. 1538 Authorization 1539 AAA protocols used for transport of EAP keying material SHOULD 1540 provide protection against rogue authenticators masquerading as 1541 other authenticators. This can be accomplished, for example, by 1542 requiring that AAA agents check the source address of packets 1543 against the origin attributes (Origin-Host AVP in Diameter, 1544 NAS-IP-Address, NAS-IPv6-Address, NAS-Identifier in RADIUS). For 1545 details, see Section 4.3.7 of [RFC3579]. 1547 Key transport 1548 Since EAP methods do not export Transient Session Keys (TSKs) in 1549 order to maintain media and ciphersuite independence, the AAA 1550 server MUST NOT transport TSKs from the backend authentication 1551 server to authenticator. 1553 Key transport specification 1554 In order to enable backend authentication servers to provide 1555 keying material to the authenticator in a well defined format, AAA 1556 protocols suitable for use with EAP MUST define the format and 1557 wrapping of the AAA-Token. 1559 EMSK transport 1560 Since the EMSK is a secret known only to the backend 1561 authentication server and peer, the AAA-Token MUST NOT transport 1562 the EMSK from the backend authentication server to the 1563 authenticator. 1565 AAA-Token protection 1566 To ensure against compromise, the AAA-Token MUST be integrity 1567 protected, authenticated, replay protected and encrypted in 1568 transit, using well-established cryptographic algorithms. 1570 Session Keys 1571 The AAA-Token SHOULD be protected with session keys as in Diameter 1572 [RFC3588] or RADIUS over IPsec [RFC3579] rather than static keys, 1573 as in [RFC2548]. 1575 Key naming 1576 In order to ensure against confusion between the appropriate 1577 keying material to be used in a given secure association protocol 1578 exchange, the AAA-Token SHOULD include explicit key names and 1579 context appropriate for informing the authenticator how the keying 1580 material is to be used. 1582 Key Compromise 1583 Where untrusted intermediaries are present, the AAA-Token SHOULD 1584 NOT be provided to the intermediaries. In Diameter, handling of 1585 keys by intermediaries can be avoided using Redirect functionality 1587 [RFC3588]. 1589 4.2.3 Secure Association Protocol Requirements 1591 The Secure Association Protocol supports the following: 1593 Mutual proof of possession 1594 The peer and authenticator MUST each demonstrate possession of the 1595 keying material transported between the AAA server and 1596 authenticator (AAA-Key). 1598 Key Naming 1599 The Secure Association Protocol MUST explicitly name the keys used 1600 in the proof of possession exchange, so as to prevent confusion 1601 when more than one set of keying material could potentially be 1602 used as the basis for the exchange. 1604 Creation and Deletion 1605 In order to support the correct processing of phase 2 security 1606 associations, the secure association (phase 2) protocol MUST 1607 support the naming of phase 2 security associations and associated 1608 transient session keys, so that the correct set of transient 1609 session keys can be identified for processing a given packet. The 1610 phase 2 secure association protocol also MUST support transient 1611 session key activation and SHOULD support deletion, so that 1612 establishment and re-establishment of transient session keys can 1613 be synchronized between the parties. 1615 Integrity and Replay Protection 1616 The Secure Association Protocol MUST support integrity and replay 1617 protection of all messages. 1619 Direct operation 1620 Since the phase 2 secure association protocol is concerned with 1621 the establishment of security associations between the EAP peer 1622 and authenticator, including the derivation of transient session 1623 keys, only those parties have "a need to know" the transient 1624 session keys. The secure association protocol MUST operate 1625 directly between the peer and authenticator, and MUST NOT be 1626 passed-through to the backend authentication server, or include 1627 additional parties. 1629 Derivation of transient session keys 1630 The secure association protocol negotiation MUST support 1631 derivation of unicast and multicast transient session keys 1632 suitable for use with the negotiated ciphersuite. 1634 TSK freshness 1635 The secure association (phase 2) protocol MUST support the 1636 derivation of fresh unicast and multicast transient session keys, 1637 even when the keying material provided by the AAA server is not 1638 fresh. This is typically supported by including an exchange of 1639 nonces within the secure association protocol. 1641 Bi-directional operation 1642 While some ciphersuites only require a single set of transient 1643 session keys to protect traffic in both directions, other 1644 ciphersuites require a unique set of transient session keys in 1645 each direction. The phase 2 secure association protocol SHOULD 1646 provide for the derivation of unicast and multicast keys in each 1647 direction, so as not to require two separate phase 2 exchanges in 1648 order to create a bi-directional phase 2 security association. 1650 Secure capabilities negotiation 1651 The Secure Association Protocol MUST support secure capabilities 1652 negotiation. This includes security parameters such as the 1653 security association identifier (SAID) and ciphersuites. It also 1654 includes confirmation of the capabilities discovered during the 1655 discovery phase (phase 0), so as to ensure that the announced 1656 capabilities have not been forged. 1658 4.2.4 Ciphersuite Requirements 1660 Ciphersuites suitable for keying by EAP methods MUST provide the 1661 following facilities: 1663 TSK derivation 1664 In order to allow a ciphersuite to be usable within the EAP keying 1665 framework, a specification MUST be provided describing how 1666 transient session keys suitable for use with the ciphersuite are 1667 derived from the AAA-Key. 1669 EAP method independence 1670 Algorithms for deriving transient session keys from the AAA-Key 1671 MUST NOT depend on the EAP method. However, algorithms for 1672 deriving TEKs MAY be specific to the EAP method. 1674 Cryptographic separation 1675 The TSKs derived from the AAA-Key MUST be cryptographically 1676 separate from each other. Similarly, TEKs MUST be 1677 cryptographically separate from each other. In addition, the TSKs 1678 MUST be cryptographically separate from the TEKs. 1680 5. IANA Considerations 1682 This specification does not create any new registries, or define any 1683 new EAP codes or types. 1685 6. Security Considerations 1687 6.1 Key Strength 1689 In order to guard against brute force attacks, EAP methods deriving 1690 keys need to be capable of generating keys with an appropriate 1691 effective symmetric key strength. In order to ensure that key 1692 generation is not the weakest link, it is necessary for EAP methods 1693 utilizing public key cryptography to choose a public key that has a 1694 cryptographic strength meeting the symmetric key strength 1695 requirement. 1697 As noted in Section 5 of [I-D.orman-public-key-lengths], this results 1698 in the following required RSA or DH module and DSA subgroup size in 1699 bits, for a given level of attack resistance in bits: 1701 Attack Resistance RSA or DH Modulus DSA subgroup 1702 (bits) size (bits) size (bits) 1703 ----------------- ----------------- ------------ 1704 70 947 128 1705 80 1228 145 1706 90 1553 153 1707 100 1926 184 1708 150 4575 279 1709 200 8719 373 1710 250 14596 475 1712 6.2 Key Wrap 1714 As described in [RFC3579], Section 4.3, known problems exist in the 1715 key wrap specified in [RFC2548]. Where the same RADIUS shared secret 1716 is used by a PAP authenticator and an EAP authenticator, there is a 1717 vulnerability to known plaintext attack. Since RADIUS uses the 1718 shared secret for multiple purposes, including per-packet 1719 authentication, attribute hiding, considerable information is exposed 1720 about the shared secret with each packet. This exposes the shared 1721 secret to dictionary attacks. MD5 is used both to compute the RADIUS 1722 Response Authenticator and the Message-Authenticator attribute, and 1723 some concerns exist relating to the security of this hash 1724 [MD5Attack]. As discussed in [RFC3579], Section 4.2, these and other 1725 RADIUS vulnerabilities may be addressed by running RADIUS over IPsec. 1727 Where an untrusted AAA intermediary is present (such as a RADIUS 1728 proxy or a Diameter agent), and data object security is not used, the 1729 AAA-Key may be recovered by an attacker in control of the untrusted 1730 intermediary. Possession of the AAA-Key enables decryption of data 1731 traffic sent between the peer and a specific authenticator; however 1732 where key separation is implemented, compromise of the AAA-Key does 1733 not enable an attacker to impersonate the peer to another 1734 authenticator, since that requires possession of the MK or EMSK, 1735 which are not transported by the AAA protocol. This vulnerability 1736 may be mitigated by implementation of redirect functionality, as 1737 provided in[RFC3588]. 1739 6.3 Man-in-the-middle Attacks 1741 As described in [I-D.puthenkulam-eap-binding], EAP method sequences 1742 and compound authentication mechanisms may be subject to 1743 man-in-the-middle attacks. When such attacks are successfully 1744 carried out, the attacker acts as an intermediary between a victim 1745 and a legitimate authenticator. This allows the attacker to 1746 authenticate successfully to the authenticator, as well as to obtain 1747 access to the network. 1749 In order to prevent these attacks, [I-D.puthenkulam-eap-binding] 1750 recommends derivation of a compound key by which the EAP peer and 1751 server can prove that they have participated in the entire EAP 1752 exchange. Since the compound key must not be known to an attacker 1753 posing as an authenticator, and yet must be derived from quantities 1754 that are exported by EAP methods, it may be desirable to derive the 1755 compound key from a portion of the EMSK. In order to provide proper 1756 key hygiene, it is recommended that the compound key used for 1757 man-in-the-middle protection be cryptographically separate from other 1758 keys derived from the EMSK, such as fast handoff keys, discussed in 1759 Appendix E. 1761 6.4 Impersonation 1763 Both the RADIUS and Diameter protocols are potentially vulnerable to 1764 impersonation by a rogue authenticator. 1766 When RADIUS requests are forwarded by a proxy, the NAS-IP-Address or 1767 NAS-IPv6-Address attributes may not correspond to the source address. 1768 Since the NAS-Identifier attribute need not contain an FQDN, it also 1769 may not correspond to the source address, even indirectly. [RFC2865] 1770 Section 3 states: 1772 A RADIUS server MUST use the source IP address of the RADIUS 1773 UDP packet to decide which shared secret to use, so that 1774 RADIUS requests can be proxied. 1776 This implies that it is possible for a rogue authenticator to forge 1777 NAS-IP-Address, NAS-IPv6-Address or NAS-Identifier attributes within 1778 a RADIUS Access-Request in order to impersonate another 1779 authenticator. Among other things, this can result in messages (and 1780 MSKs) being sent to the wrong authenticator. Since the rogue 1781 authenticator is authenticated by the RADIUS proxy or server purely 1782 based on the source address, other mechanisms are required to detect 1783 the forgery. In addition, it is possible for attributes such as the 1784 Called-Station-Id and Calling-Station-Id to be forged as well. 1786 As recommended in [RFC3579], this vulnerability can be mitigated by 1787 having RADIUS proxies check authenticator identification attributes 1788 against the source address. 1790 To allow verification of session parameters such as the 1791 Called-Station- Id and Calling-Station-Id, these can be sent by the 1792 EAP peer to the server, protected by the TEKs. The RADIUS server can 1793 then check the parameters sent by the EAP peer against those claimed 1794 by the authenticator. If a discrepancy is found, an error can be 1795 logged. 1797 While [RFC3588] requires use of the Route-Record AVP, this utilizes 1798 FQDNs, so that impersonation detection requires DNS A/AAAA and PTR 1799 RRs to be properly configured. As a result, it appears that Diameter 1800 is as vulnerable to this attack as RADIUS, if not more so. To address 1801 this vulnerability, it is necessary to allow the backend 1802 authentication server to communicate with the authenticator directly, 1803 such as via the redirect functionality supported in [RFC3588]. 1805 6.5 Denial of Service Attacks 1807 The caching of security associations may result in vulnerability to 1808 denial of service attacks. Since an EAP peer may derive multiple EAP 1809 SAs with a given EAP server, and creation of a new EAP SA does not 1810 implicitly delete a previous EAP SA, EAP methods that result in 1811 creation of persistant state may be vulnerable to denial of service 1812 attacks by a rogue EAP peer. 1814 As a result, EAP methods creating persistent state may wish to limit 1815 the number of cached EAP SAs (Phase 1a) corresponding to an EAP peer. 1816 For example, an EAP server may choose to only retain a few EAP SAs 1817 for each peer. This prevents a rogue peer from denying access to 1818 other peers. 1820 Similarly, an authenticator may have multiple AAA-Key SAs 1821 corresponding to a given EAP peer; to conserve resources an 1822 authenticator may choose to limit the number of cached AAA-Key (Phase 1823 1 b) SAs for each peer. 1825 Depending on the media, creation of a new unicast secure association 1826 SA may or may not imply deletion of a previous unicast secure 1827 association SA. Where there is no implied deletion, the 1828 authenticator may choose to limit Phase 2 (unicast and multicast) 1829 secure association SAs for each peer. 1831 7. Acknowledgements 1833 Thanks to Arun Ayyagari, Ashwin Palekar, and Tim Moore of Microsoft, 1834 Dorothy Stanley of Agere, Bob Moskowitz of TruSecure, and Russ 1835 Housley of Vigil Security for useful feedback. 1837 Normative References 1839 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 1840 RFC 1661, July 1994. 1842 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1843 Requirement Levels", BCP 14, RFC 2119, March 1997. 1845 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1846 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1847 October 1998. 1849 [I-D.ietf-eap-rfc2284bis] 1850 Blunk, L., "Extensible Authentication Protocol (EAP)", 1851 draft-ietf-eap-rfc2284bis-06 (work in progress), September 1852 2003. 1854 [IEEE802] Institute of Electrical and Electronics Engineers, "IEEE 1855 Standards for Local and Metropolitan Area Networks: 1856 Overview and Architecture", ANSI/IEEE Standard 802, 1990. 1858 Informative References 1860 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 1861 793, September 1981. 1863 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1864 April 1992. 1866 [RFC1968] Meyer, G. and K. Fox, "The PPP Encryption Control Protocol 1867 (ECP)", RFC 1968, June 1996. 1869 [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: 1870 Keyed-Hashing for Message Authentication", RFC 2104, 1871 February 1997. 1873 [RFC2246] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. 1874 and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, 1875 January 1999. 1877 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 1878 (IKE)", RFC 2409, November 1998. 1880 [RFC2419] Sklower, K. and G. Meyer, "The PPP DES Encryption 1881 Protocol, Version 2 (DESE-bis)", RFC 2419, September 1998. 1883 [RFC2420] Kummert, H., "The PPP Triple-DES Encryption Protocol 1884 (3DESE)", RFC 2420, September 1998. 1886 [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D. 1887 and R. Wheeler, "A Method for Transmitting PPP Over 1888 Ethernet (PPPoE)", RFC 2516, February 1999. 1890 [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", 1891 RFC 2548, March 1999. 1893 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 1894 Implementation in Roaming", RFC 2607, June 1999. 1896 [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication 1897 Protocol", RFC 2716, October 1999. 1899 [RFC2855] Fujisawa, K., "DHCP for IEEE 1394", RFC 2855, June 2000. 1901 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, 1902 "Remote Authentication Dial In User Service (RADIUS)", RFC 1903 2865, June 2000. 1905 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 1906 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 1907 Zhang, L. and V. Paxson, "Stream Control Transmission 1908 Protocol", RFC 2960, October 2000. 1910 [RFC3078] Pall, G. and G. Zorn, "Microsoft Point-To-Point Encryption 1911 (MPPE) Protocol", RFC 3078, March 2001. 1913 [RFC3079] Zorn, G., "Deriving Keys for use with Microsoft 1914 Point-to-Point Encryption (MPPE)", RFC 3079, March 2001. 1916 [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard 1917 (AES) Key Wrap Algorithm", RFC 3394, September 2002. 1919 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 1920 Dial In User Service) Support For Extensible 1921 Authentication Protocol (EAP)", RFC 3579, September 2003. 1923 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese, 1924 "IEEE 802.1X Remote Authentication Dial In User Service 1925 (RADIUS) Usage Guidelines", RFC 3580, September 2003. 1927 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. 1928 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1930 [FIPSDES] National Institute of Standards and Technology, "Data 1931 Encryption Standard", FIPS PUB 46, January 1977. 1933 [DESMODES] 1934 National Institute of Standards and Technology, "DES Modes 1935 of Operation", FIPS PUB 81, December 1980, . 1938 [FIPS197] National Institute of Standards and Technology, "Advanced 1939 Encryption Standard (AES)", FIPS PUB 197, November 2001. 1941 [FIPS.180-1.1995] 1942 National Institute of Standards and Technology, "Secure 1943 Hash Standard", FIPS PUB 180-1, April 1995, . 1946 [IEEE80211] 1947 Institute of Electrical and Electronics Engineers, 1948 "Information technology - Telecommunications and 1949 information exchange between systems - Local and 1950 metropolitan area networks - Specific Requirements Part 1951 11: Wireless LAN Medium Access Control (MAC) and Physical 1952 Layer (PHY) Specifications", IEEE IEEE Standard 1953 802.11-1997, 1997. 1955 [IEEE8021X] 1956 Institute of Electrical and Electronics Engineers, "Local 1957 and Metropolitan Area Networks: Port-Based Network Access 1958 Control", IEEE Standard 802.1X-2001, June 2002. 1960 [IEEE8021Q] 1961 Institute of Electrical and Electronics Engineers, "IEEE 1962 Standards for Local and Metropolitan Area Networks: Draft 1963 Standard for Virtual Bridged Local Area Networks", IEEE 1964 Standard 802.1Q/D8, January 1998. 1966 [IEEE80211f] 1967 Institute of Electrical and Electronics Engineers, 1968 "Recommended Practice for Multi-Vendor Access Point 1969 Interoperability via an Inter-Access Point Protocol Across 1970 Distribution Systems Supporting IEEE 802.11 Operation", 1971 IEEE 802.11F, July 2003. 1973 [IEEE80211i] 1974 Institute of Electrical and Electronics Engineers, "Draft 1975 Supplement to STANDARD FOR Telecommunications and 1976 Information Exchange between Systems - LAN/MAN Specific 1977 Requirements - Part 11: Wireless Medium Access Control 1978 (MAC) and physical layer (PHY) specifications: 1979 Specification for Enhanced Security", IEEE Draft 802.11I/ 1980 D6.1, August 2003. 1982 [IEEE-02-758] 1983 Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, 1984 "Proactive Caching Strategies for IAPP Latency Improvement 1985 during 802.11 Handoff", IEEE 802.11 Working Group, 1986 IEEE-02-758r1-F Draft 802.11I/D5.0, November 2002. 1988 [IEEE-03-084] 1989 Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, 1990 "Proactive Key Distribution to support fast and secure 1991 roaming", IEEE 802.11 Working Group, IEEE-03-084r1-I, 1992 http://www.ieee802.org/11/Documents/DocumentHolder/ 1993 3-084.zip, January 2003. 1995 [IEEE-03-155] 1996 Aboba, B., "Fast Handoff Issues", IEEE 802.11 Working 1997 Group, IEEE-03-155r0-I, http://www.ieee802.org/11/ 1998 Documents/DocumentHolder/3-155.zip, March 2003. 2000 [EAPAPI] Microsoft Developer Network, "Windows 2000 EAP API", 2001 http://msdn.microsoft.com/library/default.asp?url=/ 2002 library/en-us/eap/eapport_0fj9.asp, August 2000. 2004 [I-D.ietf-roamops-cert] 2005 Aboba, B., "Certificate-Based Roaming", 2006 draft-ietf-roamops-cert-02 (work in progress), April 1999. 2008 [I-D.ietf-aaa-eap] 2009 Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible 2010 Authentication Protocol (EAP) Application", 2011 draft-ietf-aaa-eap-02 (work in progress), July 2003. 2013 [I-D.irtf-aaaarch-handoff] 2014 Arbaugh, W. and B. Aboba, "Experimental Handoff Extension 2015 to RADIUS", draft-irtf-aaaarch-handoff-03 (work in 2016 progress), October 2003. 2018 [I-D.orman-public-key-lengths] 2019 Orman, H. and P. Hoffman, "Determining Strengths For 2020 Public Keys Used For Exchanging Symmetric Keys", 2021 draft-orman-public-key-lengths-05 (work in progress), 2022 January 2002. 2024 [I-D.puthenkulam-eap-binding] 2025 Puthenkulam, J., "The Compound Authentication Binding 2026 Problem", draft-puthenkulam-eap-binding-03 (work in 2027 progress), July 2003. 2029 [I-D.aboba-802-context] 2030 Aboba, B. and T. Moore, "A Model for Context Transfer in 2031 IEEE 802", draft-aboba-802-context-03 (work in progress), 2032 October 2003. 2034 [I-D.arkko-pppext-eap-aka] 2035 Arkko, J. and H. Haverinen, "EAP AKA Authentication", 2036 draft-arkko-pppext-eap-aka-10 (work in progress), June 2037 2003. 2039 [8021XHandoff] 2040 Pack, S. and Y. Choi, "Pre-Authenticated Fast Handoff in a 2041 Public Wireless LAN Based on IEEE 802.1X Model", School of 2042 Computer Science and Engineering, Seoul National 2043 University, Seoul, Korea, 2002. 2045 [MD5Attack] 2046 Dobbertin, H., "The Status of MD5 After a Recent Attack", 2047 CryptoBytes, Vol.2 No.2, 1996. 2049 Authors' Addresses 2051 Bernard Aboba 2052 Microsoft Corporation 2053 One Microsoft Way 2054 Redmond, WA 98052 2055 USA 2057 Phone: +1 425 706 6605 2058 Fax: +1 425 936 6605 2059 EMail: bernarda@microsoft.com 2060 Dan Simon 2061 Microsoft Research 2062 One Microsoft Way 2063 Redmond, WA 98052 2064 USA 2066 Phone: +1 425 706 6711 2067 Fax: +1 425 936 7329 2068 EMail: dansimon@microsoft.com 2070 Jari Arkko 2071 Ericsson 2072 Jorvas 02420 2073 Finland 2075 Phone: 2076 EMail: jari.arkko@ericsson.com 2078 Henrik Levkowetz (editor) 2079 ipUnplugged AB 2080 Arenavagen 27 2081 Stockholm S-121 28 2082 SWEDEN 2084 Phone: +46 708 32 16 08 2085 EMail: henrik@levkowetz.com 2087 Appendix A. Ciphersuite Keying Requirements 2089 To date, PPP and IEEE 802.11 ciphersuites are suitable for keying by 2090 EAP. This Appendix describes the keying requirements of common PPP 2091 and 802.11 ciphersuites. 2093 PPP ciphersuites include DESEbis [RFC2419], 3DES [RFC2420], and MPPE 2094 [RFC3078]. The DES algorithm is described in [FIPSDES], and DES modes 2095 (such as CBC, used in [RFC2419] and DES-EDE3-CBC, used in [RFC2420]) 2096 are described in [DESMODES]. For PPP DESEbis, a single 56-bit 2097 encryption key is required, used in both directions. For PPP 3DES, a 2098 168-bit encryption key is needed, used in both directions. As 2099 described in [RFC2419] for DESEbis and [RFC2420] for 3DES, the IV, 2100 which is different in each direction, is "deduced from an explicit 2101 64-bit nonce, which is exchanged in the clear during the ECP 2102 negotiation phase [RFC1968]." There is therefore no need for the IV 2103 to be provided by EAP. 2105 For MPPE, 40-bit, 56-bit or 128-bit encryption keys are required in 2106 each direction, as described in [RFC3078]. No initialization vector 2107 is required. 2109 While these PPP ciphersuites provide encryption, they do not provide 2110 per-packet authentication or integrity protection, so an 2111 authentication key is not required in either direction. 2113 Within [IEEE80211], Transient Session Keys (TSKs) are required both 2114 for unicast traffic as well as for multicast traffic, and therefore 2115 separate key hierarchies are required for unicast keys and multicast 2116 keys. IEEE 802.11 ciphersuites include WEP-40, described in 2117 [IEEE80211], which requires a 40-bit encryption key, the same in 2118 either direction; and WEP-128, which requires a 104-bit encryption 2119 key, the same in either direction. These ciphersuites also do not 2120 support per-packet authentication and integrity protection. In 2121 addition to these unicast keys, authentication and encryption keys 2122 are required to wrap the multicast encryption key. 2124 Recently, new ciphersuites have been proposed for use with IEEE 2125 802.11 that provide per-packet authentication and integrity 2126 protection as well as encryption [IEEE80211i]. These include TKIP, 2127 which requires a single 128-bit encryption key and a 128-bit 2128 authentication key (used in both directions); AES CCMP, which 2129 requires a single 128-bit key (used in both directions) in order to 2130 authenticate and encrypt data; and WRAP, which requires a single 2131 128-bit key (used in both directions). 2133 As with WEP, authentication and encryption keys are also required to 2134 wrap the multicast encryption (and possibly, authentication) keys. 2136 Appendix B. Transient EAP Key (TEK) Hierarchy 2138 Figure B-1 illustrates the TEK key hierarchy for EAP-TLS [RFC2716], 2139 which is based on the TLS key hierarchy [RFC2246]. The TLS-negotiated 2140 ciphersuite is used to set up a protected channel for use in 2141 protecting the EAP conversation, keyed by the derived TEKs. The TEK 2142 derivation proceeds as follows: 2144 master_secret = TLS-PRF-48(pre_master_secret, "master secret", 2145 client.random || server.random) 2147 TEK = TLS-PRF-X(master_secret, "key expansion", 2148 server.random || client.random) 2150 Where: 2152 TLS-PRF-X = TLS pseudo-random function [RFC2246], computed to X 2153 octets. 2155 master_secret = TLS term for the MK. 2157 | | | 2158 | | pre_master_secret | 2159 server| | | client 2160 Random| V | Random 2161 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2162 | | | | 2163 | | | | 2164 +---->| master_secret |<------+ 2165 | | (MK) | | 2166 | | | | 2167 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2168 | | | 2169 | | | 2170 | | | 2171 V V V 2172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2173 | | 2174 | | 2175 | Key Block | 2176 | (TEKs) | 2177 | | 2178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2179 | | | | | | 2180 | client | server | client | server | client | server 2181 | MAC | MAC | write | write | IV | IV 2182 | | | | | | 2183 V V V V V V 2185 Figure B-1 - TLS [RFC2246] Key Hierarchy 2187 Appendix C. MSK and EMSK Hierarchy 2189 In EAP-TLS [RFC2716], the MSK is divided into two halves, 2190 corresponding to the "Peer to Authenticator Encryption Key" 2191 (Enc-RECV-Key, 32 octets, also known as the PMK) and "Authenticator 2192 to Peer Encryption Key" (Enc-SEND-Key, 32 octets). In [RFC2548], the 2193 Enc-RECV-Key (the PMK) is transported in the MS-MPPE-Recv-Key 2194 attribute, and the Enc-SEND-Key is transported in the 2195 MS-MPPE-Send-Key attribute. 2197 The EMSK is also divided into two halves, corresponding to the "Peer 2198 to Authenticator Authentication Key" (Auth-RECV-Key, 32 octets) and 2199 "Authenticator to Peer Authentication Key" (Auth-SEND-Key, 32 2200 octets). The IV is a 64 octet quantity that is a known value; octets 2201 0-31 are known as the "Peer to Authenticator IV" or RECV-IV, and 2202 Octets 32-63 are known as the "Authenticator to Peer IV", or SEND-IV. 2204 In EAP-TLS, the MSK, EMSK and IV are derived from the MK via a 2205 one-way function. This ensures that the MK cannot be derived from 2206 the MSK, EMSK or IV unless the one-way function (TLS PRF) is broken. 2207 Since the MSK is derived from the MK, if the MK is compromised then 2208 the MSK is also compromised. 2210 As described in [RFC2716], the formula for the derivation of the MSK, 2211 EMSK and IV from the MK is as follows: 2213 MSK = TLS-PRF-64(MK, "client EAP encryption", 2214 client.random || server.random) 2216 EMSK = second 64 octets of: 2217 TLS-PRF-128(MK, "client EAP encryption", 2218 client.random || server.random) 2220 IV = TLS-PRF-64("", "client EAP encryption", 2221 client.random || server.random) 2223 AAA-Key(0,31) = Peer to Authenticator Encryption Key (Enc-RECV-Key) 2224 (MS-MPPE-Recv-Key in [RFC2548]). Also known as the 2225 PMK. 2227 AAA-Key(32,63) = Authenticator to Peer Encryption Key (Enc-SEND-Key) 2228 (MS-MPPE-Send-Key in [RFC2548]) 2230 EMSK(0,31) = Peer to Authenticator Authentication Key 2231 (Auth-RECV-Key) 2233 EMSK(32,63) = Authenticator to Peer Authentication Key 2234 (Auth-Send-Key) 2236 IV(0,31) = Peer to Authenticator Initialization Vector 2237 (RECV-IV) 2239 IV(32,63) = Authenticator to Peer Initialization vector 2240 (SEND-IV) 2242 Where: 2244 AAA-Key(W,Z) = Octets W through Z inclusive of the AAA-Key. 2246 IV(W,Z) = Octets W through Z inclusive of the IV. 2248 MSK(W,Z) = Octets W through Z inclusive of the MSK. 2250 EMSK(W,Z) = Octets W through Z inclusive of the EMSK. 2252 MK = TLS master_secret 2254 TLS-PRF-X = TLS PRF function [RFC2246], computed to X octets 2256 client.random = Nonce generated by the TLS client. 2258 server.random = Nonce generated by the TLS server. 2260 Figure C-1 describes the process by which the MSK,EMSK,IV and 2261 ultimately the TSKs, are derived from the MK. Note that in 2262 [RFC2716], the MK is referred to as the "TLS Master Secret". 2264 ---+ 2265 | ^ 2266 | TLS Master Secret (MK) | 2267 | | 2268 V | 2269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2270 | | EAP 2271 | Master Session Key (MSK) | Method 2272 | Derivation | | 2273 | | V 2274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 2275 | | | ^ 2276 | MSK | EMSK | IV EAP 2277 | | | API 2278 V V V v 2279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 2280 | | | 2281 | | | 2282 | AAA server | | 2283 | | | 2284 | | V 2285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 2286 | | ^ 2287 | AAA-Key(0,31) | AAA-Key(32,63) | 2288 | (PMK) | Transported 2289 | | via AAA 2290 | | | 2291 V V V 2292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 2293 | | ^ 2294 | Ciphersuite-Specific Transient Session | Auth. 2295 | Key Derivation | | 2296 | | V 2297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 2299 Figure C-1 - EAP TLS [RFC2716] Key hierarchy 2301 Appendix D. Transient Session Key (TSK) Derivation 2303 Within IEEE 802.11 RSN, the Pairwise Transient Key (PTK), a transient 2304 session key used to protect unicast traffic, is derived from the PMK 2305 (octets 0-31 of the MSK), known in [RFC2716] as the Peer to 2306 Authenticator Encryption Key. In [IEEE80211i], the PTK is derived 2307 from the PMK via the following formula: 2309 PTK = EAPOL-PRF-X(PMK, "Pairwise key expansion", 2310 Min(AA,SA) || Max(AA, SA) || Min(ANonce,SNonce) || 2311 Max(ANonce,SNonce)) 2313 Where: 2315 PMK = AAA-Key(0,31) 2317 SA = Station MAC address (Calling-Station-Id) 2319 AA = Access Point MAC address (Called-Station-Id) 2321 ANonce = Access Point Nonce 2323 SNonce = Station Nonce 2325 EAPOL-PRF-X = Pseudo-Random Function based on HMAC-SHA1, 2326 generating a PTK of size X octets. 2328 TKIP uses X = 64, while CCMP, WRAP, and WEP use X = 48. 2330 The EAPOL-Key Confirmation Key (KCK) is used to provide data origin 2331 authenticity in the TSK derivation. It utilizes the first 128 bits 2332 (bits 0-127) of the PTK. The EAPOL-Key Encryption Key (KEK) provides 2333 confidentiality in the TSK derivation. It utilizes bits 128-255 of 2334 the PTK. Bits 256-383 of the PTK are used by Temporal Key 1, and 2335 Bits 384-511 are used by Temporal Key 2. Usage of TK1 and TK2 is 2336 ciphersuite specific. Details are available in [IEEE80211i]. 2338 Appendix E. AAA-Key Derivation 2340 As discussed in [I-D.irtf-aaaarch-handoff], [IEEE-02-758], 2341 [IEEE-03-084], and [8021XHandoff], keying material may be required 2342 for use in fast handoff between IEEE 802.11 authenticators. Where the 2343 backend authentication server provides keying material to multiple 2344 authenticators in order to fascilitate fast handoff, it is highly 2345 desirable for the keying material used on different authenticators to 2346 be cryptographically separate, so that if one authenticator is 2347 compromised, it does not lead to the compromise of other 2348 authenticators. Where keying material is provided by the backend 2349 authentication server, a key hierarchy derived from the EMSK, as 2350 suggested in [IEEE-03-155] can be used to provide cryptographically 2351 separate keying material for use in fast handoff: 2353 AAA-Key-A = MSK(0,63) 2354 AAA-Key-B = PRF(EMSK(0,63),AAA-Key-A, 2355 B-Called-Station-Id,Calling-Station-Id) 2357 AAA-Key-E = PRF(EMSK(0,63),AAA-Key-A, 2358 E-Called-Station-Id,Calling-Station-Id) 2360 Where: 2362 Calling-Station-Id = STA MAC address 2364 B-Called-Station-Id = AP B MAC address 2366 E-Called-Station-Id = AP E MAC address 2368 Here AAA-Key-A is the AAA-Key derived during the initial EAP 2369 authentication between the peer and authenticator A. Based on this 2370 initial EAP authentication, the EMSK is also derived, which can be 2371 used to derive AAA-Keys for fast authentication between the EAP peer 2372 and authenticators B and E. Since the EMSK is cryptographically 2373 separate from the MSK, each of these AAA-Keys is cryptographically 2374 separate from each other, and are guaranteed to be unique between the 2375 EAP peer (also known as the STA) and the authenticator (also known as 2376 the AP). 2378 Appendix F. Open issues 2380 (This section should be removed by the RFC editor before publication) 2382 Open issues relating to this specification are tracked on the 2383 following web site: 2385 http://www.drizzle.com/~aboba/EAP/eapissues.html 2387 The current working documents for this draft are available at this 2388 web site: 2390 http://www.levkowetz.com/pub/ietf/drafts/eap/keying/ 2392 Intellectual Property Statement 2394 The IETF takes no position regarding the validity or scope of any 2395 intellectual property or other rights that might be claimed to 2396 pertain to the implementation or use of the technology described in 2397 this document or the extent to which any license under such rights 2398 might or might not be available; neither does it represent that it 2399 has made any effort to identify any such rights. Information on the 2400 IETF's procedures with respect to rights in standards-track and 2401 standards-related documentation can be found in BCP-11. Copies of 2402 claims of rights made available for publication and any assurances of 2403 licenses to be made available, or the result of an attempt made to 2404 obtain a general license or permission for the use of such 2405 proprietary rights by implementors or users of this specification can 2406 be obtained from the IETF Secretariat. 2408 The IETF invites any interested party to bring to its attention any 2409 copyrights, patents or patent applications, or other proprietary 2410 rights which may cover technology that may be required to practice 2411 this standard. Please address the information to the IETF Executive 2412 Director. 2414 Full Copyright Statement 2416 Copyright (C) The Internet Society (2003). All Rights Reserved. 2418 This document and translations of it may be copied and furnished to 2419 others, and derivative works that comment on or otherwise explain it 2420 or assist in its implementation may be prepared, copied, published 2421 and distributed, in whole or in part, without restriction of any 2422 kind, provided that the above copyright notice and this paragraph are 2423 included on all such copies and derivative works. However, this 2424 document itself may not be modified in any way, such as by removing 2425 the copyright notice or references to the Internet Society or other 2426 Internet organizations, except as needed for the purpose of 2427 developing Internet standards in which case the procedures for 2428 copyrights defined in the Internet Standards process must be 2429 followed, or as required to translate it into languages other than 2430 English. 2432 The limited permissions granted above are perpetual and will not be 2433 revoked by the Internet Society or its successors or assignees. 2435 This document and the information contained herein is provided on an 2436 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2437 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2438 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2439 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2440 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2442 Acknowledgment 2444 Funding for the RFC Editor function is currently provided by the 2445 Internet Society.