idnits 2.17.1 draft-ietf-eap-keying-00.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 870 has weird spacing: '...backend authe...' == Line 968 has weird spacing: '...created as th...' == 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 10, 2003) is 7504 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 953 -- Looks like a reference, but probably isn't: '2' on line 958 -- Looks like a reference, but probably isn't: '3' on line 967 -- Looks like a reference, but probably isn't: '4' on line 972 == Unused Reference: 'RFC2434' is defined on line 1846, but no explicit reference was found in the text == Unused Reference: 'RFC0793' is defined on line 1861, but no explicit reference was found in the text == Unused Reference: 'RFC1321' is defined on line 1864, but no explicit reference was found in the text == Unused Reference: 'RFC2104' is defined on line 1870, but no explicit reference was found in the text == Unused Reference: 'RFC2855' is defined on line 1900, but no explicit reference was found in the text == Unused Reference: 'RFC2960' is defined on line 1906, but no explicit reference was found in the text == Unused Reference: 'RFC3079' is defined on line 1914, but no explicit reference was found in the text == Unused Reference: 'RFC3394' is defined on line 1917, but no explicit reference was found in the text == Unused Reference: 'FIPS197' is defined on line 1939, but no explicit reference was found in the text == Unused Reference: 'EAPAPI' is defined on line 2001, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) == Outdated reference: A later version (-09) exists of draft-ietf-eap-rfc2284bis-06 -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802' -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 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: A later version (-10) exists of draft-ietf-aaa-eap-02 == Outdated reference: A later version (-04) exists of draft-irtf-aaaarch-handoff-02 == Outdated reference: A later version (-08) exists of draft-orman-public-key-lengths-05 == 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. Summary: 2 errors (**), 0 flaws (~~), 20 warnings (==), 15 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 9, 2004 Microsoft 5 J. Arkko 6 Ericsson 7 H. Levkowetz, Ed. 8 ipUnplugged 9 October 10, 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 9, 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 . . . . . . . . . . . . . . . . . . . . . . . . 23 69 3.2 AAA-Key SA . . . . . . . . . . . . . . . . . . . . . . 24 70 3.3 Unicast Secure Association SA . . . . . . . . . . . . 26 71 3.4 Multicast Secure Association SA . . . . . . . . . . . 27 72 3.5 Key Naming . . . . . . . . . . . . . . . . . . . . . . 28 73 4. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 29 74 4.1 Security Assumptions . . . . . . . . . . . . . . . . . 29 75 4.2 Security Requirements . . . . . . . . . . . . . . . . 32 76 4.2.1 EAP method requirements . . . . . . . . . . . . 32 77 4.2.2 AAA Protocol Requirements . . . . . . . . . . . 34 78 4.2.3 Secure Association Protocol Requirements . . . . 36 79 4.2.4 Ciphersuite Requirements . . . . . . . . . . . . 37 80 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 38 81 6. Security Considerations . . . . . . . . . . . . . . . . . . 38 82 6.1 Key Strength . . . . . . . . . . . . . . . . . . . . . 38 83 6.2 Key Wrap . . . . . . . . . . . . . . . . . . . . . . . 38 84 6.3 Man-in-the-middle Attacks . . . . . . . . . . . . . . 39 85 6.4 Impersonation . . . . . . . . . . . . . . . . . . . . 39 86 6.5 Denial of Service Attacks . . . . . . . . . . . . . . 40 87 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41 88 Normative References . . . . . . . . . . . . . . . . . . . . 41 89 Informative References . . . . . . . . . . . . . . . . . . . 41 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 45 91 A. Ciphersuite Keying Requirements . . . . . . . . . . . . . . 46 92 B. Transient EAP Key (TEK) Hierarchy . . . . . . . . . . . . . 47 93 C. MSK and EMSK Hierarchy . . . . . . . . . . . . . . . . . . . 48 94 D. Transient Session Key (TSK) Derivation . . . . . . . . . . . 51 95 E. AAA-Key Derivation . . . . . . . . . . . . . . . . . . . . . 52 96 F. Open issues . . . . . . . . . . . . . . . . . . . . . . . . 53 97 Intellectual Property and Copyright Statements . . . . . . . 54 99 1. Introduction 101 The Extensible Authentication Protocol (EAP), defined in 102 [I-D.ietf-eap-rfc2284bis], was designed to enable extensible 103 authentication for network access in situations in which the IP 104 protocol is not available. Originally developed for use with PPP 105 [RFC1661], it has subsequently also been applied to IEEE 802 wired 106 networks [IEEE8021X]. 108 This document provides a framework for the generation, transport and 109 usage of keying material generated by EAP authentication algorithms, 110 known as "methods". Since in EAP keying material is generated by EAP 111 methods, transported by AAA protocols, transformed into session keys 112 by secure association protocols and used by lower layer ciphersuites, 113 it is necessary to describe each of these elements and provide a 114 system-level security analysis. 116 1.1 Requirements Language 118 In this document, several words are used to signify the requirements 119 of the specification. These words are often capitalized. The key 120 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 121 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 122 are to be interpreted as described in BCP 14 [RFC2119]. 124 1.2 Terminology 126 This document frequently uses the following terms: 128 authenticator 129 The end of the link initiating EAP authentication. Where no 130 backend authentication server is present, the authenticator acts 131 as the EAP server, terminating the EAP conversation with the peer. 132 Where a backend authentication server is present, the 133 authenticator may act as a pass-through for one or more 134 authentication methods and for non-local users. This terminology 135 is also used in [IEEE8021X], and has the same meaning in this 136 document. 138 backend authentication server 139 A backend authentication server is an entity that provides an 140 authentication service to an authenticator. When used, this 141 server typically executes EAP Methods for the authenticator. This 142 terminology is also used in [IEEE8021X]. 144 AAA-Token 145 The package within which keying material and one or more 146 attributes is transported between the backend authentication 147 server and the authenticator. The attributes provide the 148 authenticator with usage context and key names suitable to bind 149 the key to the appropriate context. The format and wrapping of the 150 AAA-Token, which is intended to be accessible only to the backend 151 authentication server and authenticator, is defined by the AAA 152 protocol. Examples include RADIUS [RFC2548], and Diameter 153 [I-D.ietf-aaa-eap]. 155 Cryptographic binding 156 The demonstration of the EAP peer to the EAP server that a single 157 entity has acted as the EAP peer for all methods executed within a 158 sequence or tunnel. Binding MAY also imply that the EAP server 159 demonstrates to the peer that a single entity has acted as the EAP 160 server for all methods executed within a sequence or tunnel. If 161 executed correctly, binding serves to mitigate man-in-the-middle 162 vulnerabilities. 164 Cryptographic separation 165 Two keys (x and y) are "cryptographically separate" if an 166 adversary that knows all messages exchanged in the protocol cannot 167 compute x from y or y from x without "breaking" some cryptographic 168 assumption. In particular, this definition allows that the 169 adversary has the knowledge of all nonces sent in cleartext as 170 well as all predictable counter values used in the protocol. 171 Breaking a cryptographic assumption would typically require 172 inverting a one-way function or predicting the outcome of a 173 cryptographic pseudo-random number generator without knowledge of 174 the secret state. In other words, if the keys are 175 cryptographically separate, there is no shortcut to compute x from 176 y or y from x. 178 EAP server 179 The entity which terminates EAP authentication with the peer is 180 known as the EAP server. Where pass-through is supported, the 181 backend authentication server functions as the EAP server; where 182 authentication occurs locally, the EAP server is the 183 authenticator. 185 AAA-Key 186 A key derived by the EAP peer and EAP server and transported to 187 the authenticator. In 802.11 terminology, the first 32 octets of 188 the AAA-Key is known as the Pairwise Master Key (PMK). 190 Key strength 191 If the effective key strength is N bits, the best currently known 192 methods to recover the key (with non-negligible probability) 193 require an effort comparable to 2^N operations of a typical block 194 cipher. 196 Mutual authentication 197 This refers to an EAP method in which, within an interlocked 198 exchange, the authenticator authenticates the peer and the peer 199 authenticates the authenticator. Two one-way conversations, 200 running in opposite directions do not provide mutual 201 authentication as defined here. 203 peer 204 The end of the link that responds to the authenticator. In 205 [IEEE8021X], this end is known as the Supplicant. 207 1.3 Conversation Overview 209 Where EAP key derivation is supported, EAP authentication is 210 typically a component of a three phase exchange: 212 Discovery phase (phase 0) 213 EAP authentication, key derivation and transport (phase 1) 214 Unicast and multicast secure association establishment (phase 2) 216 In the discovery phase (phase 0), the EAP peers locate each other 217 and discover their capabilities. This can include an EAP peer 218 locating an authenticator suitable for access to a particular 219 network, or it could involve an EAP peer locating an authenticator 220 behind a bridge with which it desires to establish a secure 221 association. Typically the discovery phase takes place between the 222 EAP peer and authenticator. 224 Once the EAP peer and authenticator discover each other, EAP 225 authentication may begin (phase 1a). EAP enables deployment of new 226 authentication methods without requiring development of new code on 227 the authenticator. While the authenticator may implement some EAP 228 methods locally and use those methods to authenticate local users, it 229 may at the same time act as a pass-through for other users and 230 methods, forwarding EAP packets back and forth between the backend 231 authentication server and the peer. 233 As described in Section 2, in addition to supporting authentication, 234 EAP methods may also support derivation of keying material for 235 purposes including protection of the EAP conversation and subsequent 236 data exchanges. EAP key derivation takes place between the EAP peer 237 and EAP server, and methods supporting key derivation MUST also 238 support mutual authentication. Where an authenticator server is 239 present, it acts as the EAP server and transports derived keying 240 material (known as the AAA-Key) to the authenticator (phase 1b). 242 EAP methods may mutually authenticate and derive keys. However a 243 distinct secure association exchange is required in order to manage 244 the creation and deletion of unicast (phase 2a) and multicast (phase 245 2b) security associations between the EAP peer and authenticator. 247 The phases and the relationship between the parties is illustrated 248 below. 250 EAP peer Authenticator Auth. Server 251 -------- ------------- ------------ 252 |<----------------------------->| | 253 | Discovery (phase 0) | | 254 |<----------------------------->|<----------------------------->| 255 | EAP auth (phase 1a) | AAA pass-through (optional) | 256 | | | 257 | |<----------------------------->| 258 | | AAA-Key transport | 259 | | (optional; phase 1b) | 260 |<----------------------------->| | 261 | Unicast Secure association | | 262 | (phase 2a) | | 263 | | | 264 |<----------------------------->| | 265 | Multicast Secure association | | 266 | (optional; phase 2b) | | 267 | | | 269 Figure 1: Conversation Overview 271 1.3.1 Discovery Phase 273 In the peer discovery exchange (phase 0), the EAP peer and 274 authenticator locate each other and discover each other's 275 capabilities. For example, PPPoE [RFC2516] includes support for a 276 Discovery Stage to allow a peer to identify the Ethernet MAC address 277 of one or more authenticators and establish a PPPoE SESSION_ID. In 278 IEEE 802.11 [IEEE80211], the EAP peer (also known as the Station or 279 STA) discovers the authenticator (Access Point or AP) and determines 280 its capabilities using Beacon or Probe Request/Response frames. 281 Since device discovery is handled outside of EAP, there is no need to 282 provide this functionality within EAP. 284 Device discovery can occur manually or automatically. In EAP 285 implementations running over PPP, the EAP peer might be configured 286 with a phone book providing phone numbers of authenticators and 287 associated capabilities such as supported rates, authentication 288 protocols or ciphersuites. 290 Since device discovery can occur prior to authentication and key 291 derivation, it may not be possible for the discovery phase to be 292 protected using keying material derived during an authentication 293 exchange. As a result, device discovery protocols may be insecure, 294 leaving them vulnerable to spoofing unless the discovered parameters 295 can subsequently be securely verified. 297 1.3.2 Authentication Phase 299 Once the EAP peer and authenticator discover each other, they 300 exchange EAP packets. Typically, the peer desires access to the 301 network, and the authenticators are Network Access Servers (NASes) 302 providing that access. In such a situation, access to the network 303 can be provided by any authenticator attaching to the desired 304 network, and the EAP peer is typically willing to send data traffic 305 through any authenticator that can demonstrate that it is authorized 306 to provide access to the desired network. 308 An EAP authenticator may handle the authentication locally, or it may 309 act as a pass-through to a backend authentication server. In the 310 latter case the EAP exchange occurs between the EAP peer and a 311 backend authenticator server, with the authenticator forwarding EAP 312 packets between the two. The entity which terminates EAP 313 authentication with the peer is known as the EAP server. Where 314 pass-through is supported, the backend authentication server 315 functions as the EAP server; where authentication occurs locally, the 316 EAP server is the authenticator. Where a backend authentication 317 server is present, at the successful completion of an authentication 318 exchange, the AAA-Key is transported to the authenticator (phase 1b). 320 EAP may also be used when it is desired for two network devices (e.g. 321 two switches or routers) to authenticate each other, or where two 322 peers desire to authenticate each other and set up a secure 323 association suitable for protecting data traffic. 325 Some EAP methods exist which only support one-way authentication; 326 however, EAP methods deriving keys are required to support mutual 327 authentication. In either case, it can be assumed that the parties 328 do not utilize the link to exchange data traffic unless their 329 authentication requirements have been met. For example, a peer 330 completing mutual authentication with an EAP server will not send 331 data traffic over the link until the EAP server has authenticated 332 successfully to the peer, and a secure association has been 333 negotiated. 335 Since EAP is a peer-to-peer protocol, an independent and simultaneous 336 authentication may take place in the reverse direction. Both peers 337 may act as authenticators and authenticatees at the same time. 339 Successful completion of EAP authentication and key derivation by an 340 EAP peer and EAP server does not necessarily imply that the peer is 341 committed to joining the network associated with an EAP server. 342 Rather, this commitment is implied by the creation of a security 343 association between the EAP peer and authenticator, as part of the 344 secure association protocol (phase 2). As a result, EAP may be used 345 for "pre-authentication" in situations where it is necessary to 346 pre-establish EAP security associations in order to decrease handoff 347 or roaming latency. 349 1.3.3 Secure Association Phase 351 The secure association phase (phase 2) always occurs after the 352 completion of EAP authentication (phase 1a) and key transport (phase 353 1b), and typically supports the following features: 355 [1] The secure negotiation of capabilities. This includes usage 356 modes, session parameters and ciphersuites, and required filters, 357 including confirmation of the capabilities discovered during 358 phase 0. By securely negotiating session parameters, the secure 359 association protocol protects against spoofing during the 360 discovery phase and ensures that the peer and authenticator are 361 in agreement about how data is to be secured. 363 [2] Generation of fresh transient session keys. This is typically 364 accomplished via the exchange of nonces within the secure 365 association protocol, and includes generation of both unicast 366 (phase 2a) and multicast (phase 2b) session keys. By not using 367 the AAA-Key directly to protect data, the secure association 368 protocol protects against compromise of the AAA-Key, and by 369 guaranteeing the freshness of transient session key, assures that 370 session keys are not reused. 372 [3] Key activation and deletion. 374 [4] Mutual proof of possession of the AAA-Key. This demonstrates 375 that both the EAP peer and authenticator have been authenticated 376 and authorized by the AAA server. Since mutual proof of 377 possession is not the same as mutual authentication, the EAP peer 378 cannot verify authenticator assertions (including the 379 authenticator identity) as a result of this exchange. 381 1.4 Authorization issues 383 In a typical network access scenario (dial-in, wireless LAN, etc.) 384 access control mechanisms are typically applied. These mechanisms 385 include user authentication as well as authorization for the offered 386 service. 388 As a part of the authentication process, the AAA network determines 389 the user's authorization profile. The user authorizations are 390 transmitted by the AAA server to the EAP authenticator (also known as 391 the Network Access Server or NAS) included with the AAA-Token, which 392 also contains the AAA-Key, in Phase 1b of the EAP conversation. 393 Typically, the profile is determined based on the user identity, but 394 a certificate presented by the user may also provide authorization 395 information. 397 The AAA server is responsible for making a user authorization 398 decision, answering the following questions: 400 o Is this a legitimate user for this particular network? 402 o Is this user allowed the type of access he or she is requesting? 404 o Are there any specific parameters (mandatory tunneling, bandwidth, 405 filters, and so on) that the access network should be aware of for 406 this user? 408 o Is this user within the subscription rules regarding time of day? 410 o Is this user within his limits for concurrent sessions? 412 o Are there any fraud, credit limit, or other concerns that indicate 413 that access should be denied? 415 While the authorization decision is in principle simple, the process 416 is complicated by the distributed nature of AAA decision making. 417 Where brokering entities or proxies are involved, all of the AAA 418 devices in the chain from the NAS to the home AAA server are involved 419 in the decision. For instance, a broker can disallow access even if 420 the home AAA server would allow it, or a proxy can add authorizations 421 (e.g., bandwidth limits). 423 Decisions can be based on static policy definitions and profiles as 424 well as dynamic state (e.g. time of day or limits on the number of 425 concurrent sessions). In addition to the Accept/Reject decision made 426 by the AAA chain, parameters or constraints can be communicated to 427 the NAS. 429 The criteria for Accept/Reject decisions or the reasons for choosing 430 particular authorizations are typically not communicated to the NAS, 431 only the final result. As a result, the NAS has no way to know what 432 the decision was based on. Was a set of authorization parameters 433 sent because this service is always provided to the user, or was the 434 decision based on the time/day and the capabilities of the requesting 435 NAS device? 437 Within EAP, "fast handoff" is defined as a conversation in which the 438 EAP exchange (phase 1a) and associated AAA passthrough is bypassed, 439 so as to reduce latency. Depending on the fast handoff mechanism, 440 AAA-Key transport (phase 1b) may also be bypassed in favor a context 441 transfer (see [IEEE80211f] and [I-D.aboba-802-context]) or it may be 442 provided in a pre-emptive manner as in [IEEE-03-084] and 443 [I-D.irtf-aaaarch-handoff]. 445 As we will discuss, the introduction of fast handoff creates a new 446 class of security vulnerabilities as well as requirements for the 447 secure handling of authorization context. 449 1.4.1 Correctness in fast handoff 451 Bypassing all or portions of the AAA conversation creates challenges 452 in ensuring that authorization is properly handled. These include: 454 o Consistent application of session time limits. A fast handoff 455 should not automatically increase the available session time, 456 allowing a user to endlessly extend their network access by 457 changing the point of attachment. 459 o Avoidance of privilege elevation. A fast handoff should not 460 result in a user being granted access to services which they are 461 not entitled to. 463 o Consideration of dynamic state. In situations in which dynamic 464 state is involved in the access decision (day/time, simultaneous 465 session limit) it should be possible to take this state into 466 account either before or after access is granted. Note that 467 consideration of network-wide state such as simultaneous session 468 limits can typically only be taken into account by the AAA server. 470 o Encoding of restrictions. Since a NAS may not be aware of the 471 criteria considered by a AAA server when allowing access, in order 472 to ensure consistent authorization during a fast handoff it may be 473 necessary to explicitly encode the restrictions within the 474 authorizations provided in the AAA-Token. 476 o State validity. The introduction of fast handoff should not 477 render the authentication server incapable of keeping track of 478 network-wide state. 480 A fast handoff mechanism capable of addressing these concerns is said 481 to be "correct". One condition for correctness is as follows: 483 For a fast handoff to be "correct" it MUST establish on the new 484 device the same context as would have been created had the new device 485 completed a AAA conversation with the authentication server. 487 A properly designed fast handoff scheme will only succeed if it is 488 "correct" in this way. If a successful fast handoff would establish 489 "incorrect" state, it is preferable for it to fail, in order to avoid 490 creation of incorrect context. 492 Some AAA server and NAS configurations are incapable of meeting this 493 definition of "correctness". For example, if the old and new device 494 differ in their capabilities, it may be difficult to meet this 495 definition of correctness in a fast handoff mechanism that bypasses 496 AAA. AAA servers often perform conditional evaluation, in which the 497 authorizations returned in an Access-Accept message are contingent on 498 the NAS or on dynamic state such as the time of day or number of 499 simultaneous sessions. For example, in a heterogeneous deployment, 500 the AAA server might return different authorizations depending on the 501 NAS making the request, in order to make sure that the requested 502 service is consistent with the NAS capabilities. 504 If differences between the new and old device would result in the AAA 505 server sending a different set of messages to the new device than 506 were sent to the old device, then if the fast handoff mechanism 507 bypasses AAA, then the fast handoff cannot be carried out correctly. 509 For example, if some NAS devices within a deployment support dynamic 510 VLANs while others do not, then attributes present in the 511 Access-Request (such as the NAS-IP-Address, NAS-Identifier, 512 Vendor-Identifier, etc.) could be examined to determine when VLAN 513 attributes will be returned, as described in [RFC3580]. VLAN 514 support is defined in [IEEE8021Q]. If a fast handoff bypassing the 515 AAA server were to occur between a NAS supporting dynamic VLANs and 516 another NAS which does not, then a guest user with access restricted 517 to a guest VLAN could be given unrestricted access to the network. 519 Similarly, in a network where access is restricted based on the day 520 and time, SSID, Calling-Station-Id or other factors, unless the 521 restrictions are encoded within the authorizations, or a partial AAA 522 conversation is included, then a fast handoff could result in the 523 user bypassing the restrictions. 525 In practice, these considerations limit the situations in which fast 526 handoff mechanisms bypassing AAA can be expected to be successful. 527 Where the deployed devices implement the same set of services, it may 528 be possible to do successful fast handoffs within such mechanisms. 529 However, where the supported services differ between devices, the 530 fast handoff may not succeed. For example, [RFC2865], section 1.1 531 states: 533 "A NAS that does not implement a given service MUST NOT implement 534 the RADIUS attributes for that service. For example, a NAS that 535 is unable to offer ARAP service MUST NOT implement the RADIUS 536 attributes for ARAP. A NAS MUST treat a RADIUS access-accept 537 authorizing an unavailable service as an access-reject instead." 539 Note that this behavior only applies to attributes that are known, 540 but not implemented. For attributes that are unknown, section of 5 541 of [RFC2865] states: 543 "A RADIUS server MAY ignore Attributes with an unknown Type. A 544 RADIUS client MAY ignore Attributes with an unknown Type." 546 In order to perform a correct fast handoff, if a new device is 547 provided with RADIUS context for a known but unavailable service, 548 then it MUST process this context the same way it would handle a 549 RADIUS Access-Accept requesting an unavailable service. This MUST 550 cause the fast handoff to fail. However, if a new device is provided 551 with RADIUS context that indicates an unknown attribute, then this 552 attribute MAY be ignored. 554 Although it may seem somewhat counter-intuitive, failure is indeed 555 the "correct" result where a known but unsupported service is 556 requested. Presumably a correctly configured AAA server would not 557 request that a device carry out a service that it does not implement. 558 This implies that if the new device were to complete a AAA 559 conversation that it would be likely to receive different service 560 instructions. In such a case, failure of the fast handoff is the 561 desired result. This will cause the new device to go back to the AAA 562 server in order to receive the appropriate service definition. 564 In practice, this implies that fast handoff mechanisms which bypass 565 AAA are most likely to be successful within a homogeneous device 566 deployment within a single administrative domain. For example, it 567 would not be advisable to carry out a fast handoff bypassing AAA 568 between a NAS providing confidentiality and another NAS that does not 569 support this service. The correct result of such a fast handoff 570 would be a failure, since if the handoff were blindly carried out, 571 then the user would be moved from a secure to an insecure channel 572 without permission from the AAA server. Thus the definition of a 573 "known but unsupported service" MUST encompass requests for 574 unavailable security services. This includes vendor-specific 575 attributes related to security, such as those described in 576 [RFC2548]." 578 2. EAP Key Hierarchy 580 2.1 EAP Invariants 582 The EAP key management framework assumes that certain basic 583 characteristics, known as the "EAP Invariants" hold true for all 584 implementations of EAP. These include: 586 Media independence 587 Method independence 588 Ciphersuite independence 590 2.1.1 Media Independence 592 As described in [I-D.ietf-eap-rfc2284bis], EAP authentication can run 593 over multiple lower layers, including PPP [RFC1661] and IEEE 802 594 wired networks [IEEE8021X]. Use with IEEE 802.11 wireless LANs is 595 also contemplated [IEEE80211i]. Since EAP methods cannot be assumed 596 to have knowledge of the lower layer over which they are transported, 597 EAP methods can function on any lower layer meeting the criteria 598 outlined in [I-D.ietf-eap-rfc2284bis], Section 3.1. As a result, EAP 599 methods should not utilize identifiers associated with a particular 600 usage environment (e.g. MAC addresses). 602 2.1.2 Method Independence 604 Supporting pass-through of authentication to the backend 605 authentication server enables the authenticator to support any 606 authentication method implemented on the backend authentication 607 server and peer, not just locally implemented methods. 609 This implies that the authenticator need not implement code for each 610 EAP method required by authenticating peers. In fact, the 611 authenticator is not required to implement any EAP methods at all, 612 nor cannot it be assumed to implement code specific to any EAP 613 method. 615 This is useful where there is no single EAP method that is both 616 mandatory-to-implement and offers acceptable security for the media 617 in use. For example, the [I-D.ietf-eap-rfc2284bis] 618 mandatory-to-implement EAP method (MD5-Challenge) does not provide 619 dictionary attack resistance, mutual authentication or key 620 derivation, and as a result is not appropriate for use in wireless 621 authentication. 623 2.1.3 Ciphersuite Independence 624 While EAP methods may negotiate the ciphersuite used in protection of 625 the EAP conversation, the ciphersuite used for the protection of data 626 is negotiated within the secure association protocol, out-of-band of 627 EAP. The backend authentication server is not a party to this 628 negotiation nor is it an intermediary in the data flow between the 629 EAP peer and authenticator. The backend authentication server may 630 not even have knowledge of the ciphersuites implemented by the peer 631 and authenticator, or be aware of the ciphersuite negotiated between 632 them, and therefore does not implement ciphersuite-specific code. 634 Since ciphersuite negotiation occurs in the secure association 635 protocol, not in EAP, ciphersuite-specific key generation, if 636 implemented within an EAP method, would potentially conflict with the 637 transient session key derivation occurring in the secure association 638 protocol. As a result, EAP methods generate keying material that is 639 ciphersuite-independent. Additional advantages of 640 ciphersuite-independence include: 642 Update requirements 643 If EAP methods were to specify how to derive transient session 644 keys for each ciphersuite, they would need to be updated each time 645 a new ciphersuite is developed. In addition, backend 646 authentication servers might not be usable with all EAP-capable 647 authenticators, since the backend authentication server would also 648 need to be updated each time support for a new ciphersuite is 649 added to the authenticator. 651 EAP method complexity 652 Requiring each EAP method to include ciphersuite-specific code for 653 transient session key derivation would increase the complexity of 654 each EAP method and would result in duplicated effort. 656 Knowledge of capabilities 657 In practice, an EAP method may not have knowledge of the 658 ciphersuite that has been negotiated between the peer and 659 authenticator. In PPP, ciphersuite negotiation occurs in the 660 Encryption Control Protocol (ECP) [RFC1968]. Since ECP 661 negotiation occurs after authentication, unless an EAP method is 662 utilized that supports ciphersuite negotiation, the peer, 663 authenticator and backend authentication server may not be able to 664 anticipate the negotiated ciphersuite and therefore this 665 information cannot be provided to the EAP method. Since 666 ciphersuite negotiation is assumed to occur out-of-band, there is 667 no need for ciphersuite negotiation within EAP. 669 2.2 Key Hierarchy 671 The EAP keying hierarchy, illustrated in Figure 2, makes use of the 672 following types of keys: 674 EAP Master key (MK) 675 A key derived between the EAP client and server during the EAP 676 authentication process, and that is kept local to the EAP method 677 and not exported or made available to a third party. 679 Master Session Key (MSK) 680 Keying material (at least 64 octets) that is derived between the 681 EAP client and server and exported by the EAP method. 683 AAA-Key 684 Where a backend authentication server is present, acting as an EAP 685 server, keying material known as the AAA-Key is transported from 686 the authentication server to the authenticator wrapped within the 687 AAA-Token. The AAA-Key is used by the EAP peer and authenticator 688 in the derivation of Transient Session Keys (TSKs) for the 689 ciphersuite negotiated between the EAP peer and authenticator. As 690 a result, the AAA-Key is typically known by all parties in the EAP 691 exchange: the peer, authenticator and the authentication server 692 (if present). AAA-Key derivation is discussed in Appendix E. 694 Extended Master Session Key (EMSK) 695 Additional keying material (64 octets) derived between the EAP 696 client and server that is exported by the EAP method. The EMSK is 697 known only to the EAP peer and server and is not provided to a 698 third party. 700 Initialization Vector (IV) 701 A quantity of at least 64 octets, suitable for use in an 702 initialization vector field, that is derived between the EAP 703 client and server. Since the IV is a known value in methods such 704 as EAP-TLS [RFC2716], it cannot be used by itself for computation 705 of any quantity that needs to remain secret. As a result, its use 706 has been deprecated and EAP methods are not required to generate 707 it. 709 Pairwise Master Key (PMK) 710 The AAA-Key is divided into two halves, the "Peer to Authenticator 711 Encryption Key" (Enc-RECV-Key) and "Authenticator to Peer 712 Encryption Key" (Enc-SEND-Key) (reception is defined from the 713 point of view of the authenticator). Within [IEEE80211i] Octets 714 0-31 of the AAA-Key (Enc-RECV-Key) are known as the Pairwise 715 Master Key (PMK). IEEE 802.11i ciphersuites [IEEE80211i] derive 716 their Transient Session Keys (TSKs) solely from the PMK, whereas 717 the WEP ciphersuite, when used with [IEEE8021X], as noted in 718 [RFC3580], derives its TSKs from both halves of the AAA-Key, the 719 Enc-RECV-Key and the Enc-SEND-Key. 721 Transient EAP Keys (TEKs) 722 Session keys which are used to establish a protected channel 723 between the EAP peer and server during the EAP authentication 724 exchange. The TEKs are appropriate for use with the ciphersuite 725 negotiated between EAP peer and server for use in protecting the 726 EAP conversation. Note that the ciphersuite used to set up the 727 protected channel between the EAP peer and server during EAP 728 authentication is unrelated to the ciphersuite used to 729 subsequently protect data sent between the EAP peer and 730 authenticator. An example TEK key hierarchy is described in 731 Appendix C. 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 734 | | ^ 735 | EAP Method | | 736 | | | 737 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 738 | | | | | 739 | | EAP Method Key | | | 740 | | Derivation | | | 741 | | | | Local | 742 | | | | to EAP | 743 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Method | 744 | | | | | | 745 | | | | | | 746 | | | | | | 747 | | | | | | 748 | V | | | | 749 | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | | 750 | | TEK | | MSK | |EMSK | |IV | | | 751 | |Derivation | |Derivation | |Derivation | |Derivation | | | 752 | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | | 753 | | | | | | 754 | | | | | V 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 756 | | | ^ 757 | MSK (64B) | EMSK (64B) | IV (64B) | 758 | | | | 759 | | | Exported | 760 | | | by EAP | 761 V V V Method | 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | 763 | AAA Key Derivation, | | Known | | 764 | Naming & Binding | |(Not Secret) | | 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ V 766 | ---+ 767 | Transported | 768 | AAA-Key by AAA | 769 | Protocol | 770 V V 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 772 | | ^ 773 | TSK | Ciphersuite | 774 | Derivation | Specific | 775 | | V 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 778 Figure 2: EAP Key Hierarchy 780 Transient Session Keys (TSKs) 781 Session keys used to protect data which are appropriate for the 782 ciphersuite negotiated between the EAP peer and authenticator. 783 The TSKs are derived from the keying material included in the 784 AAA-Token via the secure association protocol. In the case of IEEE 785 802.11, the role of the secure association protocol is handled by 786 the 4-way handshake and group key derivation. An example TSK 787 derivation is provided in Appendix D. 789 2.3 Exchanges 791 EAP supports both a two party exchange between an EAP peer and an 792 authenticator, as well as a three party exchange between an EAP peer, 793 an authenticator and an EAP server. 795 Figure 3 illustrates the two party exchange. Here EAP is spoken 796 between the peer and authenticator, encapsulated within a lower layer 797 protocol, such as PPP, defined in [RFC1661] or IEEE 802, defined in 798 [IEEE802]. 800 Since the authenticator acts as an endpoint of the EAP conversation 801 rather than a pass-through, EAP methods are implemented on the 802 authenticator as well as the peer. If the EAP method negotiated 803 between the EAP peer and authenticator supports mutual authentication 804 and key derivation, the EAP Master Session Key (MSK) and Extended 805 Master Session Key (EMSK) are derived on the EAP peer and 806 authenticator and exported by the EAP method. 808 Where no backend authentication server is present, the MSK and EMSK 809 are known only to the peer and authenticator and neither is 810 transported to a third party. As demonstrated in 811 [I-D.ietf-roamops-cert], despite the absence of a backend 812 authentication server, such exchanges can support roaming between 813 providers; it is even possible to support fast handoff without 814 re-authentication. However, this is typically only possible where 815 both the EAP peer and authenticator support certificate-based 816 authentication, or where the user base is sufficiently small that EAP 817 authentication can occur locally. 819 In order to protect the EAP conversation, the EAP method may 820 negotiate a ciphersuite and derive Transient EAP Keys (TEKs) to 821 provide keys for that ciphersuite in order to protect some or all of 822 the EAP exchange. The TEKs are stored locally within the EAP method 823 and are not exported. 825 Once EAP mutual authentication completes and is successful, the 826 secure association protocol is run between the peer and 827 authenticator. This derives fresh transient session keys (TSKs), 828 provides for the secure negotiation of the ciphersuite used to 829 protect data, and supports mutual proof of possession of the AAA-Key. 831 +-+-+-+-+-+ +-+-+-+-+-+ 832 | | | | 833 | Cipher- | | Cipher- | 834 | Suite | | Suite | 835 | | | | 836 +-+-+-+-+-+ +-+-+-+-+-+ 837 ^ ^ 838 | | 839 V V 840 +-+-+-+-+-+ +-+-+-+-+-+ 841 | | | | 842 | |===============| | 843 | |EAP, TEK Deriv.|Authenti-| 844 | |<------------->| cator | 845 | | | | 846 | | Secure Assoc. | | 847 | peer |<------------->| (EAP | 848 | |===============| server) | 849 | | Link layer | | 850 | | (PPP,IEEE802) | | 851 | | | | 852 |MSK,EMSK | |MSK,EMSK | 853 | (TSKs) | | (TSKs) | 854 | | | | 855 +-+-+-+-+-+ +-+-+-+-+-+ 856 ^ ^ 857 | | 858 | MSK, EMSK | MSK, EMSK 859 | | 860 +-+-+-+-+-+ +-+-+-+-+-+ 861 | | | | 862 | EAP | | EAP | 863 | Method | | Method | 864 | | | | 865 |(MK,TEKs)| |(MK,TEKs)| 866 | | | | 867 +-+-+-+-+-+ +-+-+-+-+-+ 869 Figure 3: Relationship between EAP peer and authenticator (acting as 870 an EAP server), where no backend authentication server is present. 872 +-+-+-+-+-+ +-+-+-+-+-+ 873 | | | | 874 | | | | 875 | Cipher- | | Cipher- | 876 | Suite | | Suite | 877 | | | | 878 +-+-+-+-+-+ +-+-+-+-+-+ 879 ^ ^ 880 | | 881 | | 882 | | 883 V V 884 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 885 | |===============| |========| | 886 | |EAP, TEK Deriv.| | | | 887 | |<-------------------------------->| backend | 888 | | | | | | 889 | | Secure Assoc. | | AAA-Key| | 890 | peer |<------------->|Authenti-|<-------| auth | 891 | |===============| cator |========| server | 892 | | Link Layer | | AAA | (EAP | 893 | | (PPP,IEEE 802)| |Protocol| server) | 894 | | | | | | 895 |MSK,EMSK | | MSK | |MSK,EMSK | 896 | (TSKs) | | (TSKs) | | | 897 | | | | | | 898 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 899 ^ ^ 900 | | 901 | MSK, EMSK | MSK, EMSK 902 | | 903 | | 904 +-+-+-+-+-+ +-+-+-+-+-+ 905 | | | | 906 | EAP | | EAP | 907 | Method | | Method | 908 | | | | 909 |(MK,TEKs)| |(MK,TEKs)| 910 | | | | 911 +-+-+-+-+-+ +-+-+-+-+-+ 913 Figure 4: Pass-through relationship between EAP peer, authenticator 914 and backend authentication server. 916 Where these conditions cannot be met, a backend authentication server 917 is typically required. In this exchange, as described in [RFC3579], 918 the authenticator acts as a pass-through between the EAP peer and a 919 backend authentication server. In this model, the authenticator 920 delegates the access control decision to the backend authentication 921 server, which acts as a Key Distribution Center (KDC), supplying 922 keying material to both the EAP peer and authenticator. 924 Figure 4 illustrates the case where the authenticator acts as a 925 pass-through. Here EAP is spoken between the peer and authenticator 926 as before. The authenticator then encapsulates EAP packets within a 927 AAA protocol such as RADIUS [RFC3579] or Diameter [I-D.ietf-aaa-eap], 928 and forwards packets to and from the backend authentication server, 929 which acts as the EAP server. Since the authenticator acts as a 930 pass-through, EAP methods (as well as the derived EAP Master Key, and 931 TEKs) reside only on the peer and backend authentication server. 933 On completion of a successful authentication, EAP methods on the EAP 934 peer and EAP server export the Master Session Key (MSK) and Extended 935 Master Session Key (EMSK). The backend authentication server then 936 sends a message to the authenticator indicating that authentication 937 has been successful, providing the AAA-Key within a protected package 938 known as the AAA-Token. Along with the keying material, the 939 AAA-Token contains attributes naming the enclosed keys and providing 940 context. 942 The MSK and EMSK are used to derive the AAA-Key and key name which 943 are enclosed within the AAA-Token, transported to the NAS by the AAA 944 server, and used within the secure association protocol for 945 derivation of Transient Session Keys (TSKs) required for the 946 negotiated ciphersuite. The TSKs are known only to the peer and 947 authenticator. 949 3. Security Associations 951 The EAP model has four types of security associations (SAs): 953 [1] An EAP SA. This is an SA between the EAP peer and the EAP 954 server, created as the result of an EAP authentication exchange 955 (phase 1a). This is a bi-directional SA; that is, both parties 956 use the information in the SA for both sending and receiving. 958 [2] A AAA-Key SA, known in [IEEE80211i] as a PMK SA. This is a 959 bi-directional SA between the EAP peer and authenticator. The 960 keying material for the AAA-Key SA (known as the AAA-Key) is 961 derived on the EAP peer and server, and transported by the EAP 962 server to the authenticator (phase 1b). The choice of keying 963 material is proposed by the EAP peer and confirmed by the EAP 964 authenticator during the unicast secure association protocol 965 (phase 2a). 967 [3] A unicast secure association SA. This is a bi-directional SA 968 created as the result of a successful unicast secure association 969 exchange (phase 2a). A unicast secure association SA is bound to 970 a single EAP SA and a single AAA-Key SA. 972 [4] A multicast secure association SA (phase 2b). This SA is created 973 as the result of a successful multicast secure association 974 exchange. This SA may be uni-directional (e.g. 802.11 group-key 975 exchange) or bi-directional depending on the design of the 976 multicast secure association protocol, and can be created either 977 from the unicast secure association SA (phase 2a) or directly as 978 the result of a multicast secure association exchange (phase 2b). 980 3.1 EAP SA 982 An EAP SA exists between the EAP peer and server. It includes: 984 the EAP peer identity 985 the EAP server identity 986 the EAP method type 987 the EAP peer and server nonces 988 the Transient EAP Keys (TEKs) 989 the Master Session Key (MSK) 990 the Extended Master Session Key (EMSK) 992 The EAP SA is not explicitly bound to a particular port on the EAP 993 peer. An EAP peer with multiple ports may create an EAP SA on one 994 port and then choose to use that SA to subsequently create a phase 2 995 SA on another port. 997 It cannot be assumed that the EAP SA expires after the EAP 998 authentication and key derivation is complete. Some methods may be 999 support "fast resume" by caching EAP SA state on the EAP peer and 1000 server. 1002 EAP does not support SA lifetime negotiation or an SA "delete" 1003 operation, although some EAP methods may support this. Either the 1004 EAP peer or EAP server may delete an EAP SA at any time, and methods 1005 which allow an EAP SA to persist need to permit the EAP peer and 1006 server to recognize when they have gotten out of sync with respect to 1007 the EAP SA state. 1009 For example, EAP-TLS [RFC2716] supports "fast resume" (TLS session 1010 resumption), which assumes that both the EAP peer and server cache 1011 EAP master keys (the TLS master secret). An EAP peer attempting a 1012 fast resume provides the session-id identifying the session that it 1013 wishes to resume. If the EAP server retains the master key 1014 corresponding to this session in its cache, then the "fast resume" 1015 can proceed; otherwise a full TLS exchange ensues. 1017 An EAP peer may negotiate EAP SAs with one or more EAP servers as the 1018 result of pre-authentication or AAA load balancing and failover 1019 effects. For example, an EAP peer may pre-authenticate to one or 1020 more EAP servers, or may be directed to more than one EAP server as 1021 the result of an authentication server becoming unreachable. In 1022 general, EAP servers cannot be assumed to be synchronized with 1023 respect to EAP SA state, particularly since they may not exist within 1024 the same administrative domain. Since an EAP SA is typically created 1025 prior to secure association, the EAP SA is not bound to a particular 1026 target network. 1028 3.2 AAA-Key SA 1030 An AAA-Key SA exists between the authenticator and authentication 1031 server. It includes: 1033 the EAP peer name 1034 the NAS/authenticator name 1035 the AAA-Key 1036 the AAA-Key maximum lifetime (if known) 1037 the AAA attributes sent in the Access-Accept 1039 The AAA-Key SA is created as the result of the transport of the 1040 AAA-Token from the authentication server to the NAS/authenticator. 1041 The AAA-Key SA is more specific than the EAP SA in that it is bound 1042 to a particular authenticator, as defined by the NAS identification 1043 attributes included in the AAA request. 1045 For example, within RADIUS the NAS is identified by the 1046 NAS-Identifier, NAS-IP-Address and NAS-IPv6-Address attributes. 1047 Unless the attributes providing explicit scoping are providing, it is 1048 assumed that the AAA-Key is usable by the NAS to which it is 1049 delivered, without restriction. 1051 Since the AAA-Key SA is bound to the NAS identified in the AAA 1052 Request, a NAS/authenticator that operates on a shared use network 1053 will share the AAA-Key SA between multiple virtual NAS devices. 1054 Since these virtual NAS devices might appear to the peer to be 1055 different NASes, a mechanism is needed for the EAP peer to 1056 differentiate them, so that the peer can determine which devices a 1057 AAA-Key can be used with. 1059 In the case of IEEE 802.11, it has been proposed that a "Group 1060 Identifier" be added to the Beacon and Probe Response messages, 1061 containing a MAC address uniquely identifying a particular Access 1062 Point. Such a "Group Identifier" could be included in the 1063 NAS-Identifier attribute so as to uniquely identify a particular NAS 1064 to the AAA server. 1066 Since a AAA-Key SA may be shared between virtual NASes, it is 1067 possible for an EAP peer to successfully complete a fast handoff 1068 between virtual NASes operating on the same physical NAS. Since the 1069 virtual NASes may have access to different networks or even exist 1070 within different administrative domains, this creates a security 1071 problem unless the AAA attributes are applied to the new session. 1073 For example, an EAP peer authenticating to a GUEST network could 1074 successfully complete a fast handoff to the CORPORATE network. This 1075 would be harmless if it only resulted in the peer receiving the GUEST 1076 service, without obtaining additional time on the network. 1078 Existing RADIUS attributes may not be adequate to this task. For 1079 example, today there are no standard attributes usable to indicate: 1081 [a] Which SSIDs a peer is authorized to attach to. 1083 [b] The absolute time at which a session is to end (as opposed to the 1084 Session-Time attribute which is relative) 1086 [c] The times of day during which access is allowed 1088 [d] The Calling-Station-Ids from which a client may access the 1089 network 1091 [e] Whether fast handoff is permitted. 1093 Attribute a) is useful so that when a client attempts a fast handoff 1094 to the CORPORATE network from the GUEST network, the NAS checking the 1095 AAA attributes will discover that the peer is only authorized for 1096 GUEST, not CORPORATE. As a result, the fast handoff attempt will 1097 fail. 1099 Attribute b) can be used to prevent a peer attempting a fast handoff 1100 between the GUEST network and another network from obtaining 1101 additional session time. 1103 Attribute c) can be used to prevent a peer from accessing the network 1104 outside of authorized hours. 1106 Attribute d) can be used to ensure that a peer is accessing the 1107 network only from an administrator-authorized NIC. This might be 1108 important in high security installations. 1110 Attribute e) might be useful in situations where the administrator 1111 desires to limit deployment of fast handoff. 1113 In fast handoff, a single EAP SA may be used to establish multiple 1114 AAA- Key SAs (see Appendix E for details). Although a AAA-Key SA may 1115 not persist longer than the maximum SA lifetime negotiated for an EAP 1116 SA (for methods that support such a negotiation), if an EAP SA is 1117 deleted by an EAP peer or authenticator, this does not necessarily 1118 imply deletion of the child AAA-Key SA. For example, fast handoff 1119 keying material provided by an authentication server may continue to 1120 be cached by NASes/authenticators after the corresponding EAP SA has 1121 been deleted by the authentication server and/or peer. 1123 3.3 Unicast Secure Association SA 1125 The unicast secure association SA exists between the EAP peer and 1126 authenticator. It includes: 1128 the peer port identifier (Calling-Station-Id) 1129 the NAS port identifier (Called-Station-Id) 1130 the unicast Transient Session Keys (TSKs) 1131 the unicast secure association peer nonce 1132 the unicast secure association authenticator nonce 1133 the negotiated unicast capabilities and unicast ciphersuite. 1135 During the phase 2a exchange, the EAP peer and authenticator 1136 demonstrate mutual possession of the AAA-Key derived and transported 1137 in phase 1; securely negotiate the session capabilities (including 1138 unicast ciphersuites), and derive fresh unicast transient session 1139 keys. The AAA-Key SA (phase 1b) is therefore used to create the 1140 unicast secure association SA (phase 2a), and in the process the 1141 phase 2a unicast secure association SA is bound to ports on the EAP 1142 peer and authenticator. However in order for a phase 2a security 1143 association to be established, it is not necessary for the phase 1a 1144 exchange to be rerun each time. This enables the EAP exchange to be 1145 bypassed when fast handoff support is desired. 1147 Since both peer and authenticator nonces are used in the creation of 1148 the unicast secure association SA, the transient session keys (TSKs) 1149 are guaranteed to be fresh, even if the AAA-Key is not. As a result 1150 one or more unicast secure association SAs (phase 2a) may be derived 1151 from a single AAA-Key SA (phase 1b). The phase 2a security 1152 associations may utilize the same security parameters (e.g. mode, 1153 ciphersuite, etc.) or they may utilize different parameters. 1155 A unicast secure association SA (phase 2a) may not persist longer 1156 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.4 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.5 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-Key security association (phase 1b) 1239 to its child phase 2 security associations, the phase 2 secure 1240 association protocol allows the EAP peer and authenticator to 1241 mutually prove possession of the AAA-Key. In order to avoid 1242 confusion in the case where an EAP peer has more than one AAA-Key 1243 (phase 1b) applicable to establishment of a phase 2 security 1244 association, it is necessary for the secure association protocol 1245 (phase 2) to support key selection, so that the appropriate phase 1b 1246 keying material can be utilized by both parties in the secure 1247 association protocol exchange. 1249 For example, a peer might be pre-configured with policy indicating 1250 the ciphersuite to be used in communicating with a given 1251 authenticator. Within PPP, the ciphersuite is negotiated within the 1252 Encryption Control Protocol (ECP), after EAP authentication is 1253 completed. Within [IEEE80211i], the AP ciphersuites are advertised 1254 in the Beacon and Probe Responses, and are securely verified during a 1255 4-way exchange after EAP authentication has completed. 1257 As part of the secure association protocol (phase 2), it is necessary 1258 to bind the Transient Session Keys (TSKs) to the keying material 1259 provided in the AAA-Token. This ensures that the EAP peer and 1260 authenticator are both clear about what key to use to provide mutual 1261 proof of possession. Keys within the EAP key hierarchy are named as 1262 follows: 1264 EAP SA name 1265 The EAP security association is negotiated between the EAP peer 1266 and EAP server, and is uniquely named as follows . Here the EAP peer name and EAP server name are the 1269 identifiers securely exchanged within the EAP method. Since 1270 multiple EAP SAs may exist between an EAP peer and EAP server, the 1271 EAP peer nonce and EAP server nonce allow EAP SAs to be 1272 differentiated. The inclusion of the Method Type in the EAP SA 1273 name ensures that each EAP method has a distinct EAP SA space. 1275 MK Name 1276 The EAP Master Key, if supported by an EAP method, is named by the 1277 concatenation of the EAP SA name and a method-specific session-id. 1279 AAA-Key Name 1280 The AAA-Key is named by the concatenation of the EAP SA name, 1281 "AAA-Key" and the authenticator name, since the AAA-Key is bound 1282 to a particular authenticator. For the purpose of identification, 1283 the NAS-Identifier attribute is recommended. In order to ensure 1284 that all parties can agree on the NAS name this requires the NAS 1285 to advertise its name (typically using a media-specific mechanism, 1286 such as the 802.11 Beacon/Probe Response)." 1288 4. Threat Model 1290 4.1 Security Assumptions 1292 Figure 5 illustrates the relationship between the peer, authenticator 1293 and backend authentication server. As noted in the figure, each party 1294 in the exchange mutually authenticates with each of the other 1295 parties, and derives a unique key. All parties in the diagram have 1296 access to the AAA-Key. 1298 EAP peer 1299 /\\ 1300 / \\ 1301 Protocol: EAP / \\ Protocol: Secure Association 1302 Auth: Mutual / \\ Auth: Mutual 1303 Unique keys: MK, / \\ Unique keys: TSKs 1304 TEKs,EMSK / \\ 1305 / \\ 1306 Auth. server +--------------+ Authenticator 1307 Protocol: AAA 1308 Auth: Mutual 1309 Unique key: AAA session key 1311 Figure 5: Three-party EAP key distribution 1313 The EAP peer and backend authentication server mutually authenticate 1314 via the EAP method, and derive the MK, TEKs and EMSK which are known 1315 only to them. The TEKs are used to protect some or all of the EAP 1316 conversation between the peer and authenticator, so as to guard 1317 against modification or insertion of EAP packets by an attacker. The 1318 degree of protection afforded by the TEKs is determined by the EAP 1319 method; some methods may protect the entire EAP packet, including the 1320 EAP header, while other methods may only protect the contents of the 1321 Type-Data field, defined in [I-D.ietf-eap-rfc2284bis]. 1323 Since EAP is spoken only between the EAP peer and server, if a 1324 backend authentication server is present then the EAP conversation 1325 does not provide mutual authentication between the peer and 1326 authenticator, only between the EAP peer and EAP server (backend 1327 authentication server). As a result, mutual authentication between 1328 the peer and authenticator only occurs where a secure association 1329 protocol is used, such the unicast and group key derivation handshake 1330 supported in [IEEE80211i]. This means that absent use of a secure 1331 association protocol, from the point of view of the peer, EAP mutual 1332 authentication only proves that the authenticator is trusted by the 1333 backend authentication server; the identity of the authenticator is 1334 not confirmed. 1336 Utilizing the AAA protocol, the authenticator and backend 1337 authentication server mutually authenticate and derive session keys 1338 known only to them, used to provide per-packet integrity and replay 1339 protection, authentication and confidentiality. The MSK is 1340 distributed by the backend authentication server to the authenticator 1341 over this channel, bound to attributes constraining its usage, as 1342 part of the AAA-Token. The binding of attributes to the MSK within a 1343 protected package is important so the authenticator receiving the 1344 AAA-Token can determine that it has not been compromised, and that 1345 the keying material has not been replayed, or mis-directed in some 1346 way. 1348 The security properties of the EAP exchange are dependent on each leg 1349 of the triangle: the selected EAP method, AAA protocol and the secure 1350 association protocol. 1352 Assuming that the AAA protocol provides protection against rogue 1353 authenticators forging their identity, then the AAA-Token can be 1354 assumed to be sent to the correct authenticator, and where it is 1355 wrapped appropriately, it can be assumed to be immune to compromise 1356 by a snooping attacker. 1358 Where an untrusted AAA intermediary is present, the AAA-Token must 1359 not be provided to the intermediary so as to avoid compromise of the 1360 AAA-Token. This can be avoided by use of re-direct as defined in 1361 [RFC3588]. 1363 When EAP is used for authentication on PPP or wired IEEE 802 1364 networks, it is typically assumed that the link is physically secure, 1365 so that an attacker cannot gain access to the link, or insert a rogue 1366 device. EAP methods defined in [I-D.ietf-eap-rfc2284bis] reflect this 1367 usage model. These include EAP MD5, as well as One-Time Password 1368 (OTP) and Generic Token Card. These methods support one-way 1369 authentication (from EAP peer to authenticator) but not mutual 1370 authentication or key derivation. As a result, these methods do not 1371 bind the initial authentication and subsequent data traffic, even 1372 when the the ciphersuite used to protect data supports per-packet 1373 authentication and integrity protection. As a result, EAP methods not 1374 supporting mutual authentication are vulnerable to session hijacking 1375 as well as attacks by rogue devices. 1377 On wireless networks such as IEEE 802.11 [IEEE80211], these attacks 1378 become easy to mount, since any attacker within range can access the 1379 wireless medium, or act as an access point. As a result, new 1380 ciphersuites have been proposed for use with wireless LANs 1381 [IEEE80211i] which provide per-packet authentication, integrity and 1382 replay protection. In addition, mutual authentication and key 1383 derivation, provided by methods such as EAP-TLS [RFC2716] are 1384 required [IEEE80211i], so as to address the threat of rogue devices, 1385 and provide keying material to bind the initial authentication to 1386 subsequent data traffic. 1388 If the selected EAP method does not support mutual authentication, 1389 then the peer will be vulnerable to attack by rogue authenticators 1390 and backend authentication servers. If the EAP method does not derive 1391 keys, then TSKs will not be available for use with a negotiated 1392 ciphersuite, and there will be no binding between the initial EAP 1393 authentication and subsequent data traffic, leaving the session 1394 vulnerable to hijack. 1396 If the backend authentication server does not protect against 1397 authenticator masquerade, or provide the proper binding of the 1398 AAA-Key to the session within the AAA-Token, then one or more 1399 AAA-Keys may be sent to an unauthorized party, and an attacker may be 1400 able to gain access to the network. If the AAA-Token is provided to 1401 an untrusted AAA intermediary, then that intermediary may be able to 1402 modify the AAA-Key, or the attributes associated with it, as 1403 described in [RFC2607]. 1405 If the secure association protocol does not provide mutual proof of 1406 possession of the AAA-Key material, then the peer will not have 1407 assurance that it is connected to the correct authenticator, only 1408 that the authenticator and backend authentication server share a 1409 trust relationship (since AAA protocols support mutual 1410 authentication). This distinction can become important when multiple 1411 authenticators receive AAA-Keys from the backend authentication 1412 server, such as where fast handoff is supported. If the TSK 1413 derivation does not provide for protected ciphersuite and 1414 capabilities negotiation, then downgrade attacks are possible. 1416 4.2 Security Requirements 1418 This section describes the security requirements for EAP methods, AAA 1419 protocols, secure association protocols and Ciphersuites. These 1420 requirements MUST be met by specifications requesting publication as 1421 an RFC. Based on these requirements, the security properties of EAP 1422 exchanges are analyzed. 1424 4.2.1 EAP method requirements 1426 It is possible for the peer and EAP server to mutually authenticate 1427 and derive keys. In order to provide keying material for use in a 1428 subsequently negotiated ciphersuite, an EAP method supporting key 1429 derivation MUST export a Master Session Key (MSK) of at least 64 1430 octets, and an Extended Master Session Key (EMSK) of at least 64 1431 octets. EAP Methods deriving keys MUST provide for mutual 1432 authentication between the EAP peer and the EAP Server. 1434 The MSK and EMSK MUST NOT be used directly to protect data; however, 1435 they are of sufficient size to enable derivation of a AAA-Key 1436 subsequently used to derive Transient Session Keys (TSKs) for use 1437 with the selected ciphersuite. Each ciphersuite is responsible for 1438 specifying how to derive the TSKs from the AAA-Key. 1440 The AAA-Key is derived from the keying material exported by the EAP 1441 method (MSK and EMSK). This derivation occurs on the AAA server. In 1442 many existing protocols that use EAP, the AAA-Key and MSK are 1443 equivalent, but more complicated mechanisms are possible (see 1444 Appendix E for details). 1446 EAP methods SHOULD ensure the freshness of the MSK and EMSK even in 1447 cases where one party may not have a high quality random number 1448 generator. A RECOMMENDED method is for each party to provide a nonce 1449 of at least 128 bits, used in the derivation of the MSK and EMSK. 1451 EAP methods export the MSK and EMSK and not Transient Session Keys so 1452 as to allow EAP methods to be ciphersuite and media independent. 1453 Keying material exported by EAP methods MUST be independent of the 1454 ciphersuite negotiated to protect data. 1456 Depending on the lower layer, EAP methods may run before or after 1457 ciphersuite negotiation, so that the selected ciphersuite may not be 1458 known to the EAP method. By providing keying material usable with 1459 any ciphersuite, EAP methods can used with a wide range of 1460 ciphersuites and media. 1462 It is RECOMMENDED that methods providing integrity protection of EAP 1463 packets include coverage of all the EAP header fields, including the 1464 Code, Identifier, Length, Type and Type-Data fields. 1466 In order to preserve algorithm independence, EAP methods deriving 1467 keys SHOULD support (and document) the protected negotiation of the 1468 ciphersuite used to protect the EAP conversation between the peer and 1469 server. This is distinct from the ciphersuite negotiated between the 1470 peer and authenticator, used to protect data. 1472 The strength of Transient Session Keys (TSKs) used to protect data is 1473 ultimately dependent on the strength of keys generated by the EAP 1474 method. If an EAP method cannot produce keying material of 1475 sufficient strength, then the TSKs may be subject to brute force 1476 attack. In order to enable deployments requiring strong keys, EAP 1477 methods supporting key derivation SHOULD be capable of generating an 1478 MSK and EMSK, each with an effective key strength of at least 128 1479 bits. 1481 Methods supporting key derivation MUST demonstrate cryptographic 1482 separation between the MSK and EMSK branches of the EAP key 1483 hierarchy. Without violating a fundamental cryptographic assumption 1484 (such as the non-invertibility of a one-way function) an attacker 1485 recovering the MSK or EMSK MUST NOT be able to recover the other 1486 quantity with a level of effort less than brute force. 1488 Non-overlapping substrings of the MSK MUST be cryptographically 1489 separate from each other. That is, knowledge of one substring MUST 1490 NOT help in recovering some other substring without breaking some 1491 hard cryptographic assumption. This is required because some 1492 existing ciphersuites form TSKs by simply splitting the AAA-Key to 1493 pieces of appropriate length. Likewise, non-overlapping substrings 1494 of the EMSK MUST be cryptographically separate from each other, and 1495 from substrings of the MSK. 1497 The EMSK MUST remain on the EAP peer and EAP server where it is 1498 derived; it MUST NOT be transported to, or shared with, additional 1499 parties, or used to derive any other keys. 1501 Since EAP does not provide for explicit key lifetime negotiation, EAP 1502 peers, authenticators and authentication servers MUST be prepared for 1503 situations in which one of the parties discards key state which 1504 remains valid on another party. 1506 The development and validation of key derivation algorithms is 1507 difficult, and as a result EAP methods SHOULD reuse well established 1508 and analyzed mechanisms for key derivation (such as those specified 1509 in IKE [RFC2409] or TLS [RFC2246]), rather than inventing new ones. 1510 EAP methods SHOULD also utilize well established and analyzed 1511 mechanisms for MSK and EMSK derivation. 1513 4.2.2 AAA Protocol Requirements 1515 AAA protocols suitable for use in transporting EAP MUST provide the 1516 following facilities: 1518 Security services 1519 AAA protocols used for transport of EAP keying material MUST 1520 implement and SHOULD use per-packet integrity and authentication, 1521 replay protection and confidentiality. These requirements are met 1522 by Diameter EAP [I-D.ietf-aaa-eap], as well as RADIUS over IPsec 1523 [RFC3579]. 1525 Session Keys 1526 AAA protocols used for transport of EAP keying material MUST 1527 implement and SHOULD use dynamic key management in order to derive 1528 fresh session keys, as in Diameter EAP [I-D.ietf-aaa-eap] and 1529 RADIUS over IPsec [RFC3579], rather than using a static key, as 1530 originally defined in RADIUS [RFC2865]. 1532 Mutual authentication 1533 AAA protocols used for transport of EAP keying material MUST 1534 provide for mutual authentication between the authenticator and 1535 backend authentication server. These requirements are met by 1536 Diameter EAP [I-D.ietf-aaa-eap] as well as by RADIUS EAP 1537 [RFC3579]. 1539 Authorization 1540 AAA protocols used for transport of EAP keying material SHOULD 1541 provide protection against rogue authenticators masquerading as 1542 other authenticators. This can be accomplished, for example, by 1543 requiring that AAA agents check the source address of packets 1544 against the origin attributes (Origin-Host AVP in Diameter, 1545 NAS-IP-Address, NAS-IPv6-Address, NAS-Identifier in RADIUS). For 1546 details, see Section 4.3.7 of [RFC3579]. 1548 Key transport 1549 Since EAP methods do not export Transient Session Keys (TSKs) in 1550 order to maintain media and ciphersuite independence, the AAA 1551 server MUST NOT transport TSKs from the backend authentication 1552 server to authenticator. 1554 Key transport specification 1555 In order to enable backend authentication servers to provide 1556 keying material to the authenticator in a well defined format, AAA 1557 protocols suitable for use with EAP MUST define the format and 1558 wrapping of the AAA-Token. 1560 EMSK transport 1561 Since the EMSK is a secret known only to the backend 1562 authentication server and peer, the AAA-Token MUST NOT transport 1563 the EMSK from the backend authentication server to the 1564 authenticator. 1566 AAA-Token protection 1567 To ensure against compromise, the AAA-Token MUST be integrity 1568 protected, authenticated, replay protected and encrypted in 1569 transit, using well-established cryptographic algorithms. 1571 Session Keys 1572 The AAA-Token SHOULD be protected with session keys as in Diameter 1573 [RFC3588] or RADIUS over IPsec [RFC3579] rather than static keys, 1574 as in [RFC2548]. 1576 Key naming 1577 In order to ensure against confusion between the appropriate 1578 keying material to be used in a given secure association protocol 1579 exchange, the AAA-Token SHOULD include explicit key names and 1580 context appropriate for informing the authenticator how the keying 1581 material is to be used. 1583 Key Compromise 1584 Where untrusted intermediaries are present, the AAA-Token SHOULD 1585 NOT be provided to the intermediaries. In Diameter, handling of 1586 keys by intermediaries can be avoided using Redirect functionality 1588 [RFC3588]. 1590 4.2.3 Secure Association Protocol Requirements 1592 The Secure Association Protocol supports the following: 1594 Mutual proof of possession 1595 The peer and authenticator MUST each demonstrate possession of the 1596 keying material transported between the AAA server and 1597 authenticator (AAA-Key). 1599 Key Naming 1600 The Secure Association Protocol MUST explicitly name the keys used 1601 in the proof of possession exchange, so as to prevent confusion 1602 when more than one set of keying material could potentially be 1603 used as the basis for the exchange. 1605 Creation and Deletion 1606 In order to support the correct processing of phase 2 security 1607 associations, the secure association (phase 2) protocol MUST 1608 support the naming of phase 2 security associations and associated 1609 transient session keys, so that the correct set of transient 1610 session keys can be identified for processing a given packet. The 1611 phase 2 secure association protocol also MUST support transient 1612 session key activation and SHOULD support deletion, so that 1613 establishment and re-establishment of transient session keys can 1614 be synchronized between the parties. 1616 Integrity and Replay Protection 1617 The Secure Association Protocol MUST support integrity and replay 1618 protection of all messages. 1620 Direct operation 1621 Since the phase 2 secure association protocol is concerned with 1622 the establishment of security associations between the EAP peer 1623 and authenticator, including the derivation of transient session 1624 keys, only those parties have "a need to know" the transient 1625 session keys. The secure association protocol MUST operate 1626 directly between the peer and authenticator, and MUST NOT be 1627 passed-through to the backend authentication server, or include 1628 additional parties. 1630 Derivation of transient session keys 1631 The secure association protocol negotiation MUST support 1632 derivation of unicast and multicast transient session keys 1633 suitable for use with the negotiated ciphersuite. 1635 TSK freshness 1636 The secure association (phase 2) protocol MUST support the 1637 derivation of fresh unicast and multicast transient session keys, 1638 even when the keying material provided by the AAA server is not 1639 fresh. This is typically supported by including an exchange of 1640 nonces within the secure association protocol. 1642 Bi-directional operation 1643 While some ciphersuites only require a single set of transient 1644 session keys to protect traffic in both directions, other 1645 ciphersuites require a unique set of transient session keys in 1646 each direction. The phase 2 secure association protocol SHOULD 1647 provide for the derivation of unicast and multicast keys in each 1648 direction, so as not to require two separate phase 2 exchanges in 1649 order to create a bi-directional phase 2 security association. 1651 Secure capabilities negotiation 1652 The Secure Association Protocol MUST support secure capabilities 1653 negotiation. This includes security parameters such as the 1654 security association identifier (SAID) and ciphersuites. It also 1655 includes confirmation of the capabilities discovered during the 1656 discovery phase (phase 0), so as to ensure that the announced 1657 capabilities have not been forged. 1659 4.2.4 Ciphersuite Requirements 1661 Ciphersuites suitable for keying by EAP methods MUST provide the 1662 following facilities: 1664 TSK derivation 1665 In order to allow a ciphersuite to be usable within the EAP keying 1666 framework, a specification MUST be provided describing how 1667 transient session keys suitable for use with the ciphersuite are 1668 derived from the AAA-Key. 1670 EAP method independence 1671 Algorithms for deriving transient session keys from the AAA-Key 1672 MUST NOT depend on the EAP method. However, algorithms for 1673 deriving TEKs MAY be specific to the EAP method. 1675 Cryptographic separation 1676 The TSKs derived from the AAA-Key MUST be cryptographically 1677 separate from each other. Similarly, TEKs MUST be 1678 cryptographically separate from each other. In addition, the TSKs 1679 MUST be cryptographically separate from the TEKs. 1681 5. IANA Considerations 1683 This specification does not create any new registries, or define any 1684 new EAP codes or types. 1686 6. Security Considerations 1688 6.1 Key Strength 1690 In order to guard against brute force attacks, EAP methods deriving 1691 keys need to be capable of generating keys with an appropriate 1692 effective symmetric key strength. In order to ensure that key 1693 generation is not the weakest link, it is necessary for EAP methods 1694 utilizing public key cryptography to choose a public key that has a 1695 cryptographic strength meeting the symmetric key strength 1696 requirement. 1698 As noted in Section 5 of [I-D.orman-public-key-lengths], this results 1699 in the following required RSA or DH module and DSA subgroup size in 1700 bits, for a given level of attack resistance in bits: 1702 Attack Resistance RSA or DH Modulus DSA subgroup 1703 (bits) size (bits) size (bits) 1704 ----------------- ----------------- ------------ 1705 70 947 128 1706 80 1228 145 1707 90 1553 153 1708 100 1926 184 1709 150 4575 279 1710 200 8719 373 1711 250 14596 475 1713 6.2 Key Wrap 1715 As described in [RFC3579], Section 4.3, known problems exist in the 1716 key wrap specified in [RFC2548]. Where the same RADIUS shared secret 1717 is used by a PAP authenticator and an EAP authenticator, there is a 1718 vulnerability to known plaintext attack. Since RADIUS uses the 1719 shared secret for multiple purposes, including per-packet 1720 authentication, attribute hiding, considerable information is exposed 1721 about the shared secret with each packet. This exposes the shared 1722 secret to dictionary attacks. MD5 is used both to compute the RADIUS 1723 Response Authenticator and the Message-Authenticator attribute, and 1724 some concerns exist relating to the security of this hash 1725 [MD5Attack]. As discussed in [RFC3579], Section 4.2, these and other 1726 RADIUS vulnerabilities may be addressed by running RADIUS over IPsec. 1728 Where an untrusted AAA intermediary is present (such as a RADIUS 1729 proxy or a Diameter agent), and data object security is not used, the 1730 AAA-Key may be recovered by an attacker in control of the untrusted 1731 intermediary. Possession of the AAA-Key enables decryption of data 1732 traffic sent between the peer and a specific authenticator; however 1733 where key separation is implemented, compromise of the AAA-Key does 1734 not enable an attacker to impersonate the peer to another 1735 authenticator, since that requires possession of the MK or EMSK, 1736 which are not transported by the AAA protocol. This vulnerability 1737 may be mitigated by implementation of redirect functionality, as 1738 provided in[RFC3588]. 1740 6.3 Man-in-the-middle Attacks 1742 As described in [I-D.puthenkulam-eap-binding], EAP method sequences 1743 and compound authentication mechanisms may be subject to 1744 man-in-the-middle attacks. When such attacks are successfully 1745 carried out, the attacker acts as an intermediary between a victim 1746 and a legitimate authenticator. This allows the attacker to 1747 authenticate successfully to the authenticator, as well as to obtain 1748 access to the network. 1750 In order to prevent these attacks, [I-D.puthenkulam-eap-binding] 1751 recommends derivation of a compound key by which the EAP peer and 1752 server can prove that they have participated in the entire EAP 1753 exchange. Since the compound key must not be known to an attacker 1754 posing as an authenticator, and yet must be derived from quantities 1755 that are exported by EAP methods, it may be desirable to derive the 1756 compound key from a portion of the EMSK. In order to provide proper 1757 key hygiene, it is recommended that the compound key used for 1758 man-in-the-middle protection be cryptographically separate from other 1759 keys derived from the EMSK, such as fast handoff keys, discussed in 1760 Appendix E. 1762 6.4 Impersonation 1764 Both the RADIUS and Diameter protocols are potentially vulnerable to 1765 impersonation by a rogue authenticator. 1767 When RADIUS requests are forwarded by a proxy, the NAS-IP-Address or 1768 NAS-IPv6-Address attributes may not correspond to the source address. 1769 Since the NAS-Identifier attribute need not contain an FQDN, it also 1770 may not correspond to the source address, even indirectly. [RFC2865] 1771 Section 3 states: 1773 A RADIUS server MUST use the source IP address of the RADIUS 1774 UDP packet to decide which shared secret to use, so that 1775 RADIUS requests can be proxied. 1777 This implies that it is possible for a rogue authenticator to forge 1778 NAS-IP-Address, NAS-IPv6-Address or NAS-Identifier attributes within 1779 a RADIUS Access-Request in order to impersonate another 1780 authenticator. Among other things, this can result in messages (and 1781 MSKs) being sent to the wrong authenticator. Since the rogue 1782 authenticator is authenticated by the RADIUS proxy or server purely 1783 based on the source address, other mechanisms are required to detect 1784 the forgery. In addition, it is possible for attributes such as the 1785 Called-Station-Id and Calling-Station-Id to be forged as well. 1787 As recommended in [RFC3579], this vulnerability can be mitigated by 1788 having RADIUS proxies check authenticator identification attributes 1789 against the source address. 1791 To allow verification of session parameters such as the 1792 Called-Station- Id and Calling-Station-Id, these can be sent by the 1793 EAP peer to the server, protected by the TEKs. The RADIUS server can 1794 then check the parameters sent by the EAP peer against those claimed 1795 by the authenticator. If a discrepancy is found, an error can be 1796 logged. 1798 While [RFC3588] requires use of the Route-Record AVP, this utilizes 1799 FQDNs, so that impersonation detection requires DNS A/AAAA and PTR 1800 RRs to be properly configured. As a result, it appears that Diameter 1801 is as vulnerable to this attack as RADIUS, if not more so. To address 1802 this vulnerability, it is necessary to allow the backend 1803 authentication server to communicate with the authenticator directly, 1804 such as via the redirect functionality supported in [RFC3588]. 1806 6.5 Denial of Service Attacks 1808 The caching of security associations may result in vulnerability to 1809 denial of service attacks. Since an EAP peer may derive multiple EAP 1810 SAs with a given EAP server, and creation of a new EAP SA does not 1811 implicitly delete a previous EAP SA, EAP methods that result in 1812 creation of persistant state may be vulnerable to denial of service 1813 attacks by a rogue EAP peer. 1815 As a result, EAP methods creating persistent state may wish to limit 1816 the number of cached EAP SAs (Phase 1a) corresponding to an EAP peer. 1817 For example, an EAP server may choose to only retain a few EAP SAs 1818 for each peer. This prevents a rogue peer from denying access to 1819 other peers. 1821 Similarly, an authenticator may have multiple AAA-Key SAs 1822 corresponding to a given EAP peer; to conserve resources an 1823 authenticator may choose to limit the number of cached AAA-Key (Phase 1824 1 b) SAs for each peer. 1826 Depending on the media, creation of a new unicast secure association 1827 SA may or may not imply deletion of a previous unicast secure 1828 association SA. Where there is no implied deletion, the 1829 authenticator may choose to limit Phase 2 (unicast and multicast) 1830 secure association SAs for each peer. 1832 7. Acknowledgements 1834 Thanks to Arun Ayyagari, Ashwin Palekar, and Tim Moore of Microsoft, 1835 Dorothy Stanley of Agere, Bob Moskowitz of TruSecure, and Russ 1836 Housley of Vigil Security for useful feedback. 1838 Normative References 1840 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 1841 RFC 1661, July 1994. 1843 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1844 Requirement Levels", BCP 14, RFC 2119, March 1997. 1846 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1847 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1848 October 1998. 1850 [I-D.ietf-eap-rfc2284bis] 1851 Blunk, L., "Extensible Authentication Protocol (EAP)", 1852 draft-ietf-eap-rfc2284bis-06 (work in progress), September 1853 2003. 1855 [IEEE802] Institute of Electrical and Electronics Engineers, "IEEE 1856 Standards for Local and Metropolitan Area Networks: 1857 Overview and Architecture", ANSI/IEEE Standard 802, 1990. 1859 Informative References 1861 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 1862 793, September 1981. 1864 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1865 April 1992. 1867 [RFC1968] Meyer, G. and K. Fox, "The PPP Encryption Control Protocol 1868 (ECP)", RFC 1968, June 1996. 1870 [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: 1871 Keyed-Hashing for Message Authentication", RFC 2104, 1872 February 1997. 1874 [RFC2246] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. 1875 and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, 1876 January 1999. 1878 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 1879 (IKE)", RFC 2409, November 1998. 1881 [RFC2419] Sklower, K. and G. Meyer, "The PPP DES Encryption 1882 Protocol, Version 2 (DESE-bis)", RFC 2419, September 1998. 1884 [RFC2420] Kummert, H., "The PPP Triple-DES Encryption Protocol 1885 (3DESE)", RFC 2420, September 1998. 1887 [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D. 1888 and R. Wheeler, "A Method for Transmitting PPP Over 1889 Ethernet (PPPoE)", RFC 2516, February 1999. 1891 [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", 1892 RFC 2548, March 1999. 1894 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 1895 Implementation in Roaming", RFC 2607, June 1999. 1897 [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication 1898 Protocol", RFC 2716, October 1999. 1900 [RFC2855] Fujisawa, K., "DHCP for IEEE 1394", RFC 2855, June 2000. 1902 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, 1903 "Remote Authentication Dial In User Service (RADIUS)", RFC 1904 2865, June 2000. 1906 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 1907 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 1908 Zhang, L. and V. Paxson, "Stream Control Transmission 1909 Protocol", RFC 2960, October 2000. 1911 [RFC3078] Pall, G. and G. Zorn, "Microsoft Point-To-Point Encryption 1912 (MPPE) Protocol", RFC 3078, March 2001. 1914 [RFC3079] Zorn, G., "Deriving Keys for use with Microsoft 1915 Point-to-Point Encryption (MPPE)", RFC 3079, March 2001. 1917 [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard 1918 (AES) Key Wrap Algorithm", RFC 3394, September 2002. 1920 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 1921 Dial In User Service) Support For Extensible 1922 Authentication Protocol (EAP)", RFC 3579, September 2003. 1924 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese, 1925 "IEEE 802.1X Remote Authentication Dial In User Service 1926 (RADIUS) Usage Guidelines", RFC 3580, September 2003. 1928 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. 1929 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1931 [FIPSDES] National Institute of Standards and Technology, "Data 1932 Encryption Standard", FIPS PUB 46, January 1977. 1934 [DESMODES] 1935 National Institute of Standards and Technology, "DES Modes 1936 of Operation", FIPS PUB 81, December 1980, . 1939 [FIPS197] National Institute of Standards and Technology, "Advanced 1940 Encryption Standard (AES)", FIPS PUB 197, November 2001. 1942 [FIPS.180-1.1995] 1943 National Institute of Standards and Technology, "Secure 1944 Hash Standard", FIPS PUB 180-1, April 1995, . 1947 [IEEE80211] 1948 Institute of Electrical and Electronics Engineers, 1949 "Information technology - Telecommunications and 1950 information exchange between systems - Local and 1951 metropolitan area networks - Specific Requirements Part 1952 11: Wireless LAN Medium Access Control (MAC) and Physical 1953 Layer (PHY) Specifications", IEEE IEEE Standard 1954 802.11-1997, 1997. 1956 [IEEE8021X] 1957 Institute of Electrical and Electronics Engineers, "Local 1958 and Metropolitan Area Networks: Port-Based Network Access 1959 Control", IEEE Standard 802.1X-2001, June 2002. 1961 [IEEE8021Q] 1962 Institute of Electrical and Electronics Engineers, "IEEE 1963 Standards for Local and Metropolitan Area Networks: Draft 1964 Standard for Virtual Bridged Local Area Networks", IEEE 1965 Standard 802.1Q/D8, January 1998. 1967 [IEEE80211f] 1968 Institute of Electrical and Electronics Engineers, 1969 "Recommended Practice for Multi-Vendor Access Point 1970 Interoperability via an Inter-Access Point Protocol Across 1971 Distribution Systems Supporting IEEE 802.11 Operation", 1972 IEEE 802.11F, July 2003. 1974 [IEEE80211i] 1975 Institute of Electrical and Electronics Engineers, "Draft 1976 Supplement to STANDARD FOR Telecommunications and 1977 Information Exchange between Systems - LAN/MAN Specific 1978 Requirements - Part 11: Wireless Medium Access Control 1979 (MAC) and physical layer (PHY) specifications: 1980 Specification for Enhanced Security", IEEE Draft 802.11I/ 1981 D6.1, August 2003. 1983 [IEEE-02-758] 1984 Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, 1985 "Proactive Caching Strategies for IAPP Latency Improvement 1986 during 802.11 Handoff", IEEE 802.11 Working Group, 1987 IEEE-02-758r1-F Draft 802.11I/D5.0, November 2002. 1989 [IEEE-03-084] 1990 Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, 1991 "Proactive Key Distribution to support fast and secure 1992 roaming", IEEE 802.11 Working Group, IEEE-03-084r1-I, 1993 http://www.ieee802.org/11/Documents/DocumentHolder/ 1994 3-084.zip, January 2003. 1996 [IEEE-03-155] 1997 Aboba, B., "Fast Handoff Issues", IEEE 802.11 Working 1998 Group, IEEE-03-155r0-I, http://www.ieee802.org/11/ 1999 Documents/DocumentHolder/3-155.zip, March 2003. 2001 [EAPAPI] Microsoft Developer Network, "Windows 2000 EAP API", 2002 http://msdn.microsoft.com/library/default.asp?url=/ 2003 library/en-us/eap/eapport_0fj9.asp, August 2000. 2005 [I-D.ietf-roamops-cert] 2006 Aboba, B., "Certificate-Based Roaming", 2007 draft-ietf-roamops-cert-02 (work in progress), April 1999. 2009 [I-D.ietf-aaa-eap] 2010 Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible 2011 Authentication Protocol (EAP) Application", 2012 draft-ietf-aaa-eap-02 (work in progress), July 2003. 2014 [I-D.irtf-aaaarch-handoff] 2015 Arbaugh, W. and B. Aboba, "Experimental Handoff Extension 2016 to RADIUS", draft-irtf-aaaarch-handoff-02 (work in 2017 progress), May 2003. 2019 [I-D.orman-public-key-lengths] 2020 Orman, H. and P. Hoffman, "Determining Strengths For 2021 Public Keys Used For Exchanging Symmetric Keys", 2022 draft-orman-public-key-lengths-05 (work in progress), 2023 January 2002. 2025 [I-D.puthenkulam-eap-binding] 2026 Puthenkulam, J., "The Compound Authentication Binding 2027 Problem", draft-puthenkulam-eap-binding-03 (work in 2028 progress), July 2003. 2030 [I-D.aboba-802-context] 2031 Aboba, B. and T. Moore, "A Model for Context Transfer in 2032 IEEE 802", draft-aboba-802-context-03 (work in progress), 2033 October 2003. 2035 [8021XHandoff] 2036 Pack, S. and Y. Choi, "Pre-Authenticated Fast Handoff in a 2037 Public Wireless LAN Based on IEEE 802.1X Model", School of 2038 Computer Science and Engineering, Seoul National 2039 University, Seoul, Korea, 2002. 2041 [MD5Attack] 2042 Dobbertin, H., "The Status of MD5 After a Recent Attack", 2043 CryptoBytes, Vol.2 No.2, 1996. 2045 Authors' Addresses 2047 Bernard Aboba 2048 Microsoft Corporation 2049 One Microsoft Way 2050 Redmond, WA 98052 2051 USA 2053 Phone: +1 425 706 6605 2054 Fax: +1 425 936 6605 2055 EMail: bernarda@microsoft.com 2056 Dan Simon 2057 Microsoft Research 2058 One Microsoft Way 2059 Redmond, WA 98052 2060 USA 2062 Phone: +1 425 706 6711 2063 Fax: +1 425 936 7329 2064 EMail: dansimon@microsoft.com 2066 Jari Arkko 2067 Ericsson 2068 Jorvas 02420 2069 Finland 2071 Phone: 2072 EMail: jari.arkko@ericsson.com 2074 Henrik Levkowetz 2075 ipUnplugged AB 2076 Arenavagen 27 2077 Stockholm S-121 28 2078 SWEDEN 2080 Phone: +46 708 32 16 08 2081 EMail: henrik@levkowetz.com 2083 Appendix A. Ciphersuite Keying Requirements 2085 To date, PPP and IEEE 802.11 ciphersuites are suitable for keying by 2086 EAP. This Appendix describes the keying requirements of common PPP 2087 and 802.11 ciphersuites. 2089 PPP ciphersuites include DESEbis [RFC2419], 3DES [RFC2420], and MPPE 2090 [RFC3078]. The DES algorithm is described in [FIPSDES], and DES modes 2091 (such as CBC, used in [RFC2419] and DES-EDE3-CBC, used in [RFC2420]) 2092 are described in [DESMODES]. For PPP DESEbis, a single 56-bit 2093 encryption key is required, used in both directions. For PPP 3DES, a 2094 168-bit encryption key is needed, used in both directions. As 2095 described in [RFC2419] for DESEbis and [RFC2420] for 3DES, the IV, 2096 which is different in each direction, is "deduced from an explicit 2097 64-bit nonce, which is exchanged in the clear during the ECP 2098 negotiation phase [RFC1968]." There is therefore no need for the IV 2099 to be provided by EAP. 2101 For MPPE, 40-bit, 56-bit or 128-bit encryption keys are required in 2102 each direction, as described in [RFC3078]. No initialization vector 2103 is required. 2105 While these PPP ciphersuites provide encryption, they do not provide 2106 per-packet authentication or integrity protection, so an 2107 authentication key is not required in either direction. 2109 Within [IEEE80211], Transient Session Keys (TSKs) are required both 2110 for unicast traffic as well as for multicast traffic, and therefore 2111 separate key hierarchies are required for unicast keys and multicast 2112 keys. IEEE 802.11 ciphersuites include WEP-40, described in 2113 [IEEE80211], which requires a 40-bit encryption key, the same in 2114 either direction; and WEP-128, which requires a 104-bit encryption 2115 key, the same in either direction. These ciphersuites also do not 2116 support per-packet authentication and integrity protection. In 2117 addition to these unicast keys, authentication and encryption keys 2118 are required to wrap the multicast encryption key. 2120 Recently, new ciphersuites have been proposed for use with IEEE 2121 802.11 that provide per-packet authentication and integrity 2122 protection as well as encryption [IEEE80211i]. These include TKIP, 2123 which requires a single 128-bit encryption key and a 128-bit 2124 authentication key (used in both directions); AES CCMP, which 2125 requires a single 128-bit key (used in both directions) in order to 2126 authenticate and encrypt data; and WRAP, which requires a single 2127 128-bit key (used in both directions). 2129 As with WEP, authentication and encryption keys are also required to 2130 wrap the multicast encryption (and possibly, authentication) keys. 2132 Appendix B. Transient EAP Key (TEK) Hierarchy 2134 Figure B-1 illustrates the TEK key hierarchy for EAP-TLS [RFC2716], 2135 which is based on the TLS key hierarchy [RFC2246]. The TLS-negotiated 2136 ciphersuite is used to set up a protected channel for use in 2137 protecting the EAP conversation, keyed by the derived TEKs. The TEK 2138 derivation proceeds as follows: 2140 master_secret = TLS-PRF-48(pre_master_secret, "master secret", 2141 client.random || server.random) 2143 TEK = TLS-PRF-X(master_secret, "key expansion", 2144 server.random || client.random) 2146 Where: 2148 TLS-PRF-X = TLS pseudo-random function [RFC2246], computed to X 2149 octets. 2151 master_secret = TLS term for the MK. 2153 | | | 2154 | | pre_master_secret | 2155 server| | | client 2156 Random| V | Random 2157 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2158 | | | | 2159 | | | | 2160 +---->| master_secret |<------+ 2161 | | (MK) | | 2162 | | | | 2163 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2164 | | | 2165 | | | 2166 | | | 2167 V V V 2168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2169 | | 2170 | | 2171 | Key Block | 2172 | (TEKs) | 2173 | | 2174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2175 | | | | | | 2176 | client | server | client | server | client | server 2177 | MAC | MAC | write | write | IV | IV 2178 | | | | | | 2179 V V V V V V 2181 Figure B-1 - TLS [RFC2246] Key Hierarchy 2183 Appendix C. MSK and EMSK Hierarchy 2185 In EAP-TLS [RFC2716], the MSK is divided into two halves, 2186 corresponding to the "Peer to Authenticator Encryption Key" 2187 (Enc-RECV-Key, 32 octets, also known as the PMK) and "Authenticator 2188 to Peer Encryption Key" (Enc-SEND-Key, 32 octets). In [RFC2548], the 2189 Enc-RECV-Key (the PMK) is transported in the MS-MPPE-Recv-Key 2190 attribute, and the Enc-SEND-Key is transported in the 2191 MS-MPPE-Send-Key attribute. 2193 The EMSK is also divided into two halves, corresponding to the "Peer 2194 to Authenticator Authentication Key" (Auth-RECV-Key, 32 octets) and 2195 "Authenticator to Peer Authentication Key" (Auth-SEND-Key, 32 2196 octets). The IV is a 64 octet quantity that is a known value; octets 2197 0-31 are known as the "Peer to Authenticator IV" or RECV-IV, and 2198 Octets 32-63 are known as the "Authenticator to Peer IV", or SEND-IV. 2200 In EAP-TLS, the MSK, EMSK and IV are derived from the MK via a 2201 one-way function. This ensures that the MK cannot be derived from 2202 the MSK, EMSK or IV unless the one-way function (TLS PRF) is broken. 2203 Since the MSK is derived from the MK, if the MK is compromised then 2204 the MSK is also compromised. 2206 As described in [RFC2716], the formula for the derivation of the MSK, 2207 EMSK and IV from the MK is as follows: 2209 MSK = TLS-PRF-64(MK, "client EAP encryption", 2210 client.random || server.random) 2212 EMSK = second 64 octets of: 2213 TLS-PRF-128(MK, "client EAP encryption", 2214 client.random || server.random) 2216 IV = TLS-PRF-64("", "client EAP encryption", 2217 client.random || server.random) 2219 AAA-Key(0,31) = Peer to Authenticator Encryption Key (Enc-RECV-Key) 2220 (MS-MPPE-Recv-Key in [RFC2548]). Also known as the 2221 PMK. 2223 AAA-Key(32,63) = Authenticator to Peer Encryption Key (Enc-SEND-Key) 2224 (MS-MPPE-Send-Key in [RFC2548]) 2226 EMSK(0,31) = Peer to Authenticator Authentication Key 2227 (Auth-RECV-Key) 2229 EMSK(32,63) = Authenticator to Peer Authentication Key 2230 (Auth-Send-Key) 2232 IV(0,31) = Peer to Authenticator Initialization Vector 2233 (RECV-IV) 2235 IV(32,63) = Authenticator to Peer Initialization vector 2236 (SEND-IV) 2238 Where: 2240 AAA-Key(W,Z) = Octets W through Z includes of the AAA-Key. 2242 IV(W,Z) = Octets W through Z inclusive of the IV. 2244 MSK(W,Z) = Octets W through Z inclusive of the MSK. 2246 EMSK(W,Z) = Octets W through Z inclusive of the EMSK. 2248 MK = TLS master_secret 2250 TLS-PRF-X = TLS PRF function [RFC2246], computed to X octets 2252 client.random = Nonce generated by the TLS client. 2254 server.random = Nonce generated by the TLS server. 2256 Figure C-1 describes the process by which the MSK,EMSK,IV and 2257 ultimately the TSKs, are derived from the MK. Note that in 2258 [RFC2716], the MK is referred to as the "TLS Master Secret". 2260 ---+ 2261 | ^ 2262 | TLS Master Secret (MK) | 2263 | | 2264 V | 2265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2266 | | EAP 2267 | Master Session Key (MSK) | Method 2268 | Derivation | | 2269 | | V 2270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 2271 | | | ^ 2272 | MSK | EMSK | IV EAP 2273 | | | API 2274 V V V v 2275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 2276 | | | 2277 | | | 2278 | AAA server | | 2279 | | | 2280 | | V 2281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 2282 | | ^ 2283 | AAA-Key(0,31) | AAA-Key(32,63) | 2284 | (PMK) | Transported 2285 | | via AAA 2286 | | | 2287 V V V 2288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 2289 | | ^ 2290 | Ciphersuite-Specific Transient Session | Auth. 2291 | Key Derivation | | 2292 | | V 2293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 2295 Figure C-1 - EAP TLS [RFC2716] Key hierarchy 2297 Appendix D. Transient Session Key (TSK) Derivation 2299 Within IEEE 802.11 RSN, the Pairwise Transient Key (PTK), a transient 2300 session key used to protect unicast traffic, is derived from the PMK 2301 (octets 0-31 of the MSK), known in [RFC2716] as the Peer to 2302 Authenticator Encryption Key. In [IEEE80211i], the PTK is derived 2303 from the PMK via the following formula: 2305 PTK = EAPOL-PRF-X(PMK, "Pairwise key expansion", 2306 Min(AA,SA) || Max(AA, SA) || Min(ANonce,SNonce) || 2307 Max(ANonce,SNonce)) 2309 Where: 2311 PMK = AAA-Key(0,31) 2313 SA = Station MAC address (Calling-Station-Id) 2315 AA = Access Point MAC address (Called-Station-Id) 2317 ANonce = Access Point Nonce 2319 SNonce = Station Nonce 2321 EAPOL-PRF-X = Pseudo-Random Function based on HMAC-SHA1, 2322 generating a PTK of size X octets. 2324 TKIP uses X = 64, while CCMP, WRAP, and WEP use X = 48. 2326 The EAPOL-Key Confirmation Key (KCK) is used to provide data origin 2327 authenticity in the TSK derivation. It utilizes the first 128 bits 2328 (bits 0-127) of the PTK. The EAPOL-Key Encryption Key (KEK) provides 2329 confidentiality in the TSK derivation. It utilizes bits 128-255 of 2330 the PTK. Bits 256-383 of the PTK are used by Temporal Key 1, and 2331 Bits 384-511 are used by Temporal Key 2. Usage of TK1 and TK2 is 2332 ciphersuite specific. Details are available in [IEEE80211i]. 2334 Appendix E. AAA-Key Derivation 2336 As discussed in [I-D.irtf-aaaarch-handoff], [IEEE-02-758], 2337 [IEEE-03-084], and [8021XHandoff], keying material may be required 2338 for use in fast handoff between IEEE 802.11 authenticators. Where the 2339 backend authentication server provides keying material to multiple 2340 authenticators in order to fascilitate fast handoff, it is highly 2341 desirable for the keying material used on different authenticators to 2342 be cryptographically separate, so that if one authenticator is 2343 compromised, it does not lead to the compromise of other 2344 authenticators. Where keying material is provided by the backend 2345 authentication server, a key hierarchy derived from the EMSK, as 2346 suggested in [IEEE-03-155] can be used to provide cryptographically 2347 separate keying material for use in fast handoff: 2349 AAA-Key-A = MSK(0,63) 2350 AAA-Key-B = PRF(EMSK(0,63),AAA-Key-A, 2351 B-Called-Station-Id,Calling-Station-Id) 2353 AAA-Key-E = PRF(EMSK(0,63),AAA-Key-A, 2354 E-Called-Station-Id,Calling-Station-Id) 2356 Where: 2358 Calling-Station-Id = STA MAC address 2360 B-Called-Station-Id = AP B MAC address 2362 E-Called-Station-Id = AP E MAC address 2364 Here AAA-Key-A is the AAA-Key derived during the initial EAP 2365 authentication between the peer and authenticator A. Based on this 2366 initial EAP authentication, the EMSK is also derived, which can be 2367 used to derive AAA-Keys for fast authentication between the EAP peer 2368 and authenticators B and E. Since the EMSK is cryptographically 2369 separate from the MSK, each of these AAA-Keys is cryptographically 2370 separate from each other, and are guaranteed to be unique between the 2371 EAP peer (also known as the STA) and the authenticator (also known as 2372 the AP). 2374 Appendix F. Open issues 2376 (This section should be removed by the RFC editor before publication) 2378 Open issues relating to this specification are tracked on the 2379 following web site: 2381 http://www.drizzle.com/~aboba/EAP/eapissues.html 2383 The current working documents for this draft are available at this 2384 web site: 2386 http://www.levkowetz.com/pub/ietf/drafts/eap/keying/ 2388 Intellectual Property Statement 2390 The IETF takes no position regarding the validity or scope of any 2391 intellectual property or other rights that might be claimed to 2392 pertain to the implementation or use of the technology described in 2393 this document or the extent to which any license under such rights 2394 might or might not be available; neither does it represent that it 2395 has made any effort to identify any such rights. Information on the 2396 IETF's procedures with respect to rights in standards-track and 2397 standards-related documentation can be found in BCP-11. Copies of 2398 claims of rights made available for publication and any assurances of 2399 licenses to be made available, or the result of an attempt made to 2400 obtain a general license or permission for the use of such 2401 proprietary rights by implementors or users of this specification can 2402 be obtained from the IETF Secretariat. 2404 The IETF invites any interested party to bring to its attention any 2405 copyrights, patents or patent applications, or other proprietary 2406 rights which may cover technology that may be required to practice 2407 this standard. Please address the information to the IETF Executive 2408 Director. 2410 Full Copyright Statement 2412 Copyright (C) The Internet Society (2003). All Rights Reserved. 2414 This document and translations of it may be copied and furnished to 2415 others, and derivative works that comment on or otherwise explain it 2416 or assist in its implementation may be prepared, copied, published 2417 and distributed, in whole or in part, without restriction of any 2418 kind, provided that the above copyright notice and this paragraph are 2419 included on all such copies and derivative works. However, this 2420 document itself may not be modified in any way, such as by removing 2421 the copyright notice or references to the Internet Society or other 2422 Internet organizations, except as needed for the purpose of 2423 developing Internet standards in which case the procedures for 2424 copyrights defined in the Internet Standards process must be 2425 followed, or as required to translate it into languages other than 2426 English. 2428 The limited permissions granted above are perpetual and will not be 2429 revoked by the Internet Society or its successors or assignees. 2431 This document and the information contained herein is provided on an 2432 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2433 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2434 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2435 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2436 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2438 Acknowledgment 2440 Funding for the RFC Editor function is currently provided by the 2441 Internet Society.