idnits 2.17.1 draft-ietf-eap-keying-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 3443. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 3449), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 38. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(A) Disclaimer.) ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(B) IPR Disclosure Invitation.) ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 73 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 74 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 46 instances of too long lines in the document, the longest one being 10 characters in excess of 72. ** The abstract seems to contain references ([RFC3748]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 413 has weird spacing: '...enerate fresh...' == Line 2057 has weird spacing: '...ude the key s...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'IEEE-802.1X' is mentioned on line 154, but not defined -- Looks like a reference, but probably isn't: '1' on line 1973 -- Looks like a reference, but probably isn't: '2' on line 1976 -- Looks like a reference, but probably isn't: '3' on line 1982 -- Looks like a reference, but probably isn't: '4' on line 1175 -- Looks like a reference, but probably isn't: '5' on line 458 == Missing Reference: 'SHA1' is mentioned on line 979, but not defined == Missing Reference: 'TLS' is mentioned on line 998, but not defined == Missing Reference: 'SIGMA' is mentioned on line 999, but not defined == Missing Reference: 'IEEE802.11i' is mentioned on line 3311, but not defined == Missing Reference: 'RFC 3748' is mentioned on line 1486, but not defined == Missing Reference: 'DiamEAP' is mentioned on line 1508, but not defined == Missing Reference: 'RFC3759' is mentioned on line 1706, but not defined == Missing Reference: 'RFC3784' is mentioned on line 1956, but not defined ** Obsolete undefined reference: RFC 3784 (Obsoleted by RFC 5305) == Missing Reference: 'RFC3162' is mentioned on line 2344, but not defined == Missing Reference: 'ServiceIdent' is mentioned on line 2349, but not defined == Missing Reference: 'ECP' is mentioned on line 2985, but not defined == Unused Reference: 'RFC0793' is defined on line 2737, but no explicit reference was found in the text == Unused Reference: 'RFC2401' is defined on line 2753, but no explicit reference was found in the text == Unused Reference: 'RFC3079' is defined on line 2785, but no explicit reference was found in the text == Unused Reference: 'IEEE802' is defined on line 2811, but no explicit reference was found in the text == Unused Reference: 'IEEE80211F' is defined on line 2834, but no explicit reference was found in the text == Unused Reference: 'IEEE-03-155' is defined on line 2862, but no explicit reference was found in the text == Unused Reference: 'I-D.aboba-802-context' is defined on line 2886, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2716 (Obsoleted by RFC 5216) -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) -- Unexpected draft version: The latest known version of draft-ietf-roamops-cert is -01, but you're referring to -02. -- Unexpected draft version: The latest known version of draft-aboba-802-context is -02, but you're referring to -03. == Outdated reference: A later version (-16) exists of draft-arkko-pppext-eap-aka-15 Summary: 13 errors (**), 0 flaws (~~), 27 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 EAP Working Group Bernard Aboba 2 INTERNET-DRAFT Dan Simon 3 Category: Standards Track Microsoft 4 J. Arkko 5 18 February 2005 Ericsson 6 P. Eronen 7 Nokia 8 H. Levkowetz, Ed. 9 ipUnplugged 11 Extensible Authentication Protocol (EAP) Key Management Framework 13 By submitting this Internet-Draft, I certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, 15 and any of which I become aware will be disclosed, in accordance with 16 RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 22, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). All Rights Reserved. 40 Abstract 42 The Extensible Authentication Protocol (EAP), defined in [RFC3748], 43 enables extensible network access authentication. This document 44 provides a framework for the generation, transport and usage of 45 keying material generated by EAP authentication algorithms, known as 46 "methods". It also specifies the EAP key hierarchy. 48 Table of Contents 50 1. Introduction .......................................... 4 51 1.1 Requirements Language ........................... 4 52 1.2 Terminology ..................................... 4 53 1.3 Overview ........................................ 5 54 1.4 EAP Invariants .................................. 11 55 2. Key Derivation ........................................ 14 56 2.1 Key Terminology ................................. 14 57 2.2 Key Hierarchy ................................... 15 58 2.3 AAA-Key Derivation .............................. 21 59 2.4 AMSK Key Derivation ............................. 22 60 2.5 Key Naming ...................................... 23 61 3. Security associations ................................. 26 62 3.1 EAP Method SA ................................... 26 63 3.2 EAP-Key SA ...................................... 27 64 3.3 AAA SA(s) ....................................... 28 65 3.4 Service SA(s) ................................... 28 66 4. Key Management ........................................ 30 67 4.1 Key Caching ..................................... 31 68 4.2 Parent-Child Relationships ...................... 32 69 4.3 Local Key Lifetimes ............................. 32 70 4.4 Exported and Calculated Key Lifetimes ........... 33 71 4.5 Key Cache Synchronization ....................... 34 72 4.6 Key Scope ....................................... 35 73 4.7 Key Strength .................................... 36 74 4.8 Key Wrap ........................................ 37 75 5. Handoff Support ....................................... 38 76 5.1 Authorization ................................... 38 77 5.2 Correctness ..................................... 39 78 6. Security Considerations .............................. 42 79 6.1 Security Terminology ............................ 42 80 6.2 Threat Model .................................... 42 81 6.3 Security Analysis ............................... 44 82 6.4 Man-in-the-middle Attacks ....................... 48 83 6.5 Denial of Service Attacks ....................... 48 84 6.6 Impersonation ................................... 49 85 6.7 Channel Binding ................................. 50 87 7. Security Requirements ................................. 51 88 7.1 EAP Method Requirements ......................... 51 89 7.2 AAA Protocol Requirements ....................... 54 90 7.3 Secure Association Protocol Requirements ........ 55 91 7.4 Ciphersuite Requirements ........................ 57 92 8. IANA Considerations ................................... 57 93 9. References ............................................ 58 94 9.1 Normative References ............................ 58 95 9.2 Informative References .......................... 59 96 Acknowledgments .............................................. 62 97 Author's Addresses ........................................... 63 98 Appendix A - Ciphersuite Keying Requirements ................. 64 99 Appendix B - Example Transient EAP Key (TEK) Hierarchy ....... 65 100 Appendix C - EAP-TLS Key Hierarchy ........................... 66 101 Appendix D - Example Transient Session Key (TSK) Derivation .. 68 102 Appendix E - Key Names and Scope in Existing Methods ......... 69 103 Appendix F - Security Association Examples ................... 70 104 Intellectual Property Statement .............................. 73 105 Disclaimer of Validity ....................................... 74 106 Copyright Statement .......................................... 74 108 1. Introduction 110 The Extensible Authentication Protocol (EAP), defined in [RFC3748], 111 was designed to enable extensible authentication for network access 112 in situations in which the IP protocol is not available. Originally 113 developed for use with PPP [RFC1661], it has subsequently also been 114 applied to IEEE 802 wired networks [IEEE8021X]. 116 This document provides a framework for the generation, transport and 117 usage of keying material generated by EAP authentication algorithms, 118 known as "methods". In EAP keying material is generated by EAP 119 methods. Part of this keying material may be used by EAP methods 120 themselves and part of this material may be exported. The exported 121 keying material may be transported by AAA protocols or transformed by 122 Secure Association Protocols into session keys which are used by 123 lower layer ciphersuites. This document describes each of these 124 elements and provides a system-level security analysis. It also 125 specifies the EAP key hierarchy. 127 1.1. Requirements Language 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in BCP 14 [RFC2119]. 133 1.2. Terminology 135 This document frequently uses the following terms: 137 authenticator 138 The end of the link initiating EAP authentication. The term 139 Authenticator is used in [IEEE-802.1X], and authenticator has the 140 same meaning in this document. 142 peer The end of the link that responds to the authenticator. In 143 [IEEE-802.1X], this end is known as the Supplicant. 145 Supplicant 146 The end of the link that responds to the authenticator in 147 [IEEE-802.1X]. In this document, this end of the link is called 148 the peer. 150 backend authentication server 151 A backend authentication server is an entity that provides an 152 authentication service to an authenticator. When used, this server 153 typically executes EAP methods for the authenticator. This 154 terminology is also used in [IEEE-802.1X]. 156 AAA Authentication, Authorization and Accounting. AAA protocols with 157 EAP support include RADIUS [RFC3579] and Diameter [I-D.ietf-aaa- 158 eap]. In this document, the terms "AAA server" and "backend 159 authentication server" are used interchangeably. 161 EAP server 162 The entity that terminates the EAP authentication method with the 163 peer. In the case where no backend authentication server is used, 164 the EAP server is part of the authenticator. In the case where the 165 authenticator operates in pass-through mode, the EAP server is 166 located on the backend authentication server. 168 security association 169 A set of policies and cryptographic state used to protect 170 information. Elements of a security association may include 171 cryptographic keys, negotiated ciphersuites and other parameters, 172 counters, sequence spaces, authorization attributes, etc. 174 1.3. Overview 176 EAP is typically deployed in order to support extensible network 177 access authentication in situations where a peer desires network 178 access via one or more authenticators. Since both the peer and 179 authenticator may have more than one physical or logical port, a 180 given peer may simultaneously access the network via multiple 181 authenticators, or via multiple physical or logical ports on a given 182 authenticator. Similarly, an authenticator may offer network access 183 to multiple peers, each via a separate physical or logical port. The 184 situation is illustrated in Figure 1. 186 Where authenticators are deployed standalone, the EAP conversation 187 occurs between the peer and authenticator, and the authenticator must 188 locally implement an EAP method acceptable to the peer. However, one 189 of the advantages of EAP is that it enables deployment of new 190 authentication methods without requiring development of new code on 191 the authenticator. While the authenticator may implement some EAP 192 methods locally and use those methods to authenticate local users, it 193 may at the same time act as a pass-through for other users and 194 methods, forwarding EAP packets back and forth between the backend 195 authentication server and the peer. 197 This is accomplished by encapsulating EAP packets within the 198 Authentication, Authorization and Accounting (AAA) protocol, spoken 199 between the authenticator and backend authentication server. AAA 200 protocols supporting EAP include RADIUS [RFC3579] and Diameter [I- 201 D.ietf-aaa-eap]. 203 +-+-+-+-+ 204 | | 205 | EAP | 206 | Peer | 207 | | 208 +-+-+-+-+ 209 | | | Peer Ports 210 / | \ 211 / | \ 212 / | \ 213 / | \ 214 / | \ 215 / | \ 216 / | \ 217 / | \ 218 | | | | | | | | | Authenticator Ports 219 +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ 220 | | | | | | 221 | Auth. | | Auth. | | Auth. | 222 | | | | | | 223 +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ 224 \ | / 225 \ | / 226 \ | / 227 EAP over AAA \ | / 228 (optional) \ | / 229 \ | / 230 \ | / 231 \ | / 232 +-+-+-+-+ 233 | | 234 | AAA | 235 |Server | 236 | | 237 +-+-+-+-+ 239 Figure 1: Relationship between peer, authenticator and backend server 241 Where EAP key derivation is supported, the conversation between the 242 peer and the authenticator typically takes place in three phases: 244 Phase 0: Discovery 245 Phase 1: Authentication 246 1a: EAP authentication 247 1b: AAA-Key Transport (optional) 248 Phase 2: Secure Association Establishment 249 2a: Unicast Secure Association 250 2b: Multicast Secure Association (optional) 252 In the discovery phase (phase 0), peers locate authenticators and 253 discover their capabilities. For example, a peer may locate an 254 authenticator providing access to a particular network, or a peer may 255 locate an authenticator behind a bridge with which it desires to 256 establish a Secure Association. 258 The authentication phase (phase 1) may begin once the peer and 259 authenticator discover each other. This phase always includes EAP 260 authentication (phase 1a). Where the chosen EAP method supports key 261 derivation, in phase 1a keying material is derived on both the peer 262 and the EAP server. This keying material may be used for multiple 263 purposes, including protection of the EAP conversation and subsequent 264 data exchanges. 266 An additional step (phase 1b) is required in deployments which 267 include a backend authentication server, in order to transport keying 268 material (known as the AAA-Key) from the backend authentication 269 server to the authenticator. 271 A Secure Association exchange (phase 2) then occurs between the peer 272 and authenticator in order to manage the creation and deletion of 273 unicast (phase 2a) and multicast (phase 2b) security associations 274 between the peer and authenticator. 276 The conversation phases and relationship between the parties is shown 277 in Figure 2. 279 EAP peer Authenticator Auth. Server 280 -------- ------------- ------------ 281 |<----------------------------->| | 282 | Discovery (phase 0) | | 283 |<----------------------------->|<----------------------------->| 284 | EAP auth (phase 1a) | AAA pass-through (optional) | 285 | | | 286 | |<----------------------------->| 287 | | AAA-Key transport | 288 | | (optional; phase 1b) | 289 |<----------------------------->| | 290 | Unicast Secure association | | 291 | (phase 2a) | | 292 | | | 293 |<----------------------------->| | 294 | Multicast Secure association | | 295 | (optional; phase 2b) | | 296 | | | 298 Figure 2: Conversation Overview 300 1.3.1. Discovery Phase 302 In the discovery phase (phase 0), the EAP peer and authenticator 303 locate each other and discover each other's capabilities. Discovery 304 can occur manually or automatically, depending on the lower layer 305 over which EAP runs. Since authenticator discovery is handled 306 outside of EAP, there is no need to provide this functionality within 307 EAP. 309 For example, where EAP runs over PPP, the EAP peer might be 310 configured with a phone book providing phone numbers of 311 authenticators and associated capabilities such as supported rates, 312 authentication protocols or ciphersuites. 314 In contrast, PPPoE [RFC2516] provides support for a Discovery Stage 315 to allow a peer to identify the Ethernet MAC address of one or more 316 authenticators and establish a PPPoE SESSION_ID. 318 IEEE 802.11 [IEEE80211] also provides integrated discovery support 319 utilizing Beacon and/or Probe Request/Response frames, allowing the 320 peer (known as the station or STA) to determine the MAC address and 321 capabilities of one or more authenticators (known as Access Point or 322 APs). 324 1.3.2. Authentication Phase 326 Once the peer and authenticator discover each other, they exchange 327 EAP packets. Typically, the peer desires access to the network, and 328 the authenticators provide that access. In such a situation, access 329 to the network can be provided by any authenticator attaching to the 330 desired network, and the EAP peer is typically willing to send data 331 traffic through any authenticator that can demonstrate that it is 332 authorized to provide access to the desired network. 334 An EAP authenticator may handle the authentication locally, or it may 335 act as a pass-through to a backend authentication server. In the 336 latter case the EAP exchange occurs between the EAP peer and a 337 backend authenticator server, with the authenticator forwarding EAP 338 packets between the two. The entity which terminates EAP 339 authentication with the peer is known as the EAP server. Where pass- 340 through is supported, the backend authentication server functions as 341 the EAP server; where authentication occurs locally, the EAP server 342 is the authenticator. Where a backend authentication server is 343 present, at the successful completion of an authentication exchange, 344 the AAA-Key is transported to the authenticator (phase 1b). 346 EAP may also be used when it is desired for two network devices (e.g. 347 two switches or routers) to authenticate each other, or where two 348 peers desire to authenticate each other and set up a secure 349 association suitable for protecting data traffic. 351 Some EAP methods exist which only support one-way authentication; 352 however, EAP methods deriving keys are required to support mutual 353 authentication. In either case, it can be assumed that the parties 354 do not utilize the link to exchange data traffic unless their 355 authentication requirements have been met. For example, a peer 356 completing mutual authentication with an EAP server will not send 357 data traffic over the link until the EAP server has authenticated 358 successfully to the peer, and a Secure Association has been 359 negotiated. 361 Since EAP is a peer-to-peer protocol, an independent and simultaneous 362 authentication may take place in the reverse direction. Both peers 363 may act as authenticators and authenticatees at the same time. 365 Successful completion of EAP authentication and key derivation by a 366 peer and EAP server does not necessarily imply that the peer is 367 committed to joining the network associated with an EAP server. 368 Rather, this commitment is implied by the creation of a security 369 association between the EAP peer and authenticator, as part of the 370 Secure Association Protocol (phase 2). As a result, EAP may be used 371 for "pre-authentication" in situations where it is necessary to pre- 372 establish EAP security associations in order to decrease handoff or 373 roaming latency. 375 1.3.3. Secure Association Phase 377 The Secure Association phase (phase 2), if it occurs, begins after 378 the completion of EAP authentication (phase 1a) and key transport 379 (phase 1b). EAP may be used in the following scenarios: 381 [a] Stationary peer. Where the peer is stationary it will establish 382 communications with one or more authenticators while remaining in 383 one location. In this scenario, EAP authentication typically 384 represents only a small fraction of the total session time, so that 385 it is acceptable for EAP authentication to occur each time the peer 386 wishes to access the network. In this scenario, the Secure 387 Association Protocol phase may be omitted. 389 [b] Mobile peer. Where the peer is mobile, it may move its point of 390 attachment from one authenticator to another, or between points of 391 attachment on a single authenticator. In this scenario, it is 392 often desirable to minimize the handoff latency, so that it is 393 desirable to avoid EAP authentication each time the peer changes 394 its point of attachment. In this scenario, caching of the AAA-Key 395 be supported on the EAP peer and authenticator. In this, a Secure 396 Assocation Protocol phase is required to allow EAP to be used 397 securely. 399 A Secure Association Protocol used with EAP typically supports the 400 following features: 402 [1] Generation of fresh transient session keys (TSKs). Where AAA-Key 403 caching is supported, the EAP peer may initiate a new session using 404 a AAA-Key that was used in a previous session. Were the TSKs to be 405 derived from a portion of the AAA-Key, this would result in reuse 406 of the session keys which could expose the underlying ciphersuite 407 to attack. 409 As a result, where AAA-Key caching is supported, the Secure 410 Association Protocol phase is REQUIRED, and MUST provide for 411 freshness of the TSKs. This is typically handled via the exchange 412 of nonces or counters, which are then mixed with the AAA-Key in 413 order to generate fresh unicast (phase 2a) and possibly multicast 414 (phase 2b) session keys. By not using the AAA-Key directly to 415 protect data, the Secure Association Protocol protects against 416 compromise of the AAA-Key. 418 [2] Entity Naming. A basic feature of a Secure Association Protocol is 419 the explicit naming of the parties engaged in the exchange. 420 Explicit identification of the parties is critical, since without 421 this the parties engaged in the exchange are not identified and the 422 scope of the transient session keys (TSKs) generated during the 423 exchange is undefined. As illustrated in Figure 1, both the peer 424 and NAS may have more than one physical or virtual port, so that 425 port identifiers are not recommended a naming mechanism. 427 [3] Secure capabilities negotiation. This includes the secure 428 negotiation of usage modes, session parameters (such as key 429 lifetimes), ciphersuites and required filters, including 430 confirmation of the capabilities discovered during phase 0. It is 431 RECOMMENDED that the Secure Association Protocol support secure 432 capabilities negotiation, in order to protect against spoofing 433 during the discovery phase, and to ensure agreement between the 434 peer and authenticator about how data is to be secured. 436 [4] Key management. EAP as defined in [RFC3748] supports key 437 derivation, but not key management. While EAP methods may derive 438 keying material, EAP does provide for the management of exported or 439 derived keys. For example, EAP does not support negotiation of the 440 key lifetime of exported or derived keys, nor does it support 441 rekey. Although EAP methods may support "fast reconnect" as 442 defined in [RFC3748] Section 7.2.1, rekey of exported keys cannot 443 occur without reauthentication. In order to provide method 444 independence, key management of exported or derived keys SHOULD NOT 445 be provided within EAP methods. 447 Since neither EAP nor EAP methods provide key management support, 448 it is RECOMMENDED that key management facilities be provided within 449 the Secure Association Protocol. This includes key lifetime 450 management (such as via explicit key lifetime negotiation, or 451 seamless rekey), as well synchronization of the installation and 452 deletion of keys so as to enable recovery from partial or complete 453 loss of key state by the peer or authenticator. Since key 454 management requires a key naming scheme, Secure Association 455 Protocols supporting key management support MUST also support key 456 naming. 458 [5] Mutual proof of possession of the AAA-Key. The Secure Association 459 Protocol MUST demonstrate mutual proof of posession of the AAA-Key, 460 in order to show that both the peer and authenticator have been 461 authenticated and authorized by the backend authentication server. 462 Since mutual proof of possession is not the same as mutual 463 authentication, the peer cannot verify authenticator assertions 464 (including the authenticator identity) as a result of this 465 exchange. 467 1.4. EAP Invariants 469 Certain basic characteristics, known as the "EAP Invariants" hold 470 true for EAP implementations on all media: 472 Media independence 473 Method independence 474 Ciphersuite independence 476 1.4.1. Media Independence 478 One of the goals of EAP is to allow EAP methods to function on any 479 lower layer meeting the criteria outlined in [RFC3748], Section 3.1. 480 For example, as described in [RFC3748], EAP authentication can be run 481 over PPP [RFC1661], IEEE 802 wired networks [IEEE8021X], and IEEE 482 802.11 wireless LANs [IEEE80211i]. 484 In order to maintain media independence, it is necessary for EAP to 485 avoid inclusion of media-specific elements. For example, EAP methods 486 cannot be assumed to have knowledge of the lower layer over which 487 they are transported, and cannot utilize identifiers associated with 488 a particular usage environment (e.g. MAC addresses). 490 The need for media independence has also motivated the development of 491 the three phase exchange. Since discovery is typically media- 492 specific, this function is handled outside of EAP, rather than being 493 incorporated within it. Similarly, the Secure Association Protocol 494 often contains media dependencies such as negotiation of media- 495 specific ciphersuites or session parameters, and as a result this 496 functionality also cannot be incorporated within EAP. 498 Note that media independence may be retained within EAP methods that 499 support channel binding or method-specific identification. An EAP 500 method need not be aware of the content of an identifier in order to 501 use it. This enables an EAP method to use media-specific identifiers 502 such as MAC addresses without compromising media independence. To 503 support channel binding, an EAP method can pass binding parameters to 504 the AAA server in the form of an opaque blob, and receive 505 confirmation of whether the parameters match, without requiring 506 media-specific knowledge. 508 1.4.2. Method Independence 510 By enabling pass-through, authenticators can support any method 511 implemented on the peer and server, not just locally implemented 512 methods. This allows the authenticator to avoid implementing code 513 for each EAP method required by peers. In fact, since a pass-through 514 authenticator is not required to implement any EAP methods at all, it 515 cannot be assumed to support any EAP method-specific code. 517 As a result, as noted in [RFC3748], authenticators must by default be 518 capable of supporting any EAP method. Since the Discovery and Secure 519 Association exchanges are also method independent, an authenticator 520 can carry out the three phase exchange without having an EAP method 521 in common with the peer. 523 This is useful where there is no single EAP method that is both 524 mandatory-to-implement and offers acceptable security for the media 525 in use. For example, the [RFC3748] mandatory-to-implement EAP method 526 (MD5-Challenge) does not provide dictionary attack resistance, mutual 527 authentication or key derivation, and as a result is not appropriate 528 for use in wireless LAN authentication [WLANREQ]. However, despite 529 this it is possible for the peer and authenticator to interoperate as 530 long as a suitable EAP method is supported on the EAP server. 532 1.4.3. Ciphersuite Independence 534 While EAP methods may negotiate the ciphersuite used in protection of 535 the EAP conversation, the ciphersuite used for the protection of the 536 data exchanged after EAP authentication has completed is negotiated 537 between the peer and authenticator out-of-band of EAP. Since 538 ciphersuite negotiation is assumed to occur out-of-band, there is no 539 need for ciphersuite negotiation within EAP. Since ciphersuite 540 negotiation occurs outside of EAP, EAP methods generate keying 541 material that is ciphersuite-independent. 543 For example, within PPP, the ciphersuite is negotiated within the 544 Encryption Control Protocol (ECP) defined in [RFC1968], after EAP 545 authentication is completed. Within [IEEE80211i], the AP 546 ciphersuites are advertised in the Beacon and Probe Responses prior 547 to EAP authentication, and are securely verified during a 4-way 548 handshake exchange after EAP authentication has completed. 550 Advantages of ciphersuite-independence include: 552 Reduced update requirements 553 If EAP methods were to specify how to derive transient session keys 554 for each ciphersuite, they would need to be updated each time a new 555 ciphersuite is developed. In addition, backend authentication 556 servers might not be usable with all EAP-capable authenticators, 557 since the backend authentication server would also need to be 558 updated each time support for a new ciphersuite is added to the 559 authenticator. 561 Reduced EAP method complexity 562 Requiring each EAP method to include ciphersuite-specific code for 563 transient session key derivation would increase method complexity 564 and result in duplicated effort. 566 Simplified configuration 567 The ciphersuite is negotiated between the peer and authenticator 568 out-of-band of EAP. The backend authentication server is neither a 569 party to this negotiation, nor is it an intermediary in the data 570 flow between the EAP peer and authenticator. The backend 571 authentication server may not have knowledge of the ciphersuites 572 and negotiation policies implemented by the peer and authenticator, 573 or be aware of the ciphersuite negotiated between them. This 574 simplifies the configuration of the backend authentication server. 576 For example, since ECP negotiation occurs after authentication, 577 when run over PPP, the EAP peer, authenticator and backend 578 authentication server may not anticipate the negotiated ciphersuite 579 and therefore this information cannot be provided to the EAP 580 method. 582 2. Key Derivation 584 2.1. Key Terminology 586 The EAP Key Hierarchy makes use of the following types of keys: 588 Long Term Credential 589 EAP methods frequently make use of long term secrets in order to 590 enable authentication between the peer and server. In the case of 591 a method based on pre-shared key authentication, the long term 592 credential is the pre-shared key. In the case of a public-key 593 based method, the long term credential is the corresponding private 594 key. 596 Master Session Key (MSK) 597 Keying material that is derived between the EAP peer and server and 598 exported by the EAP method. The MSK is at least 64 octets in 599 length. 601 Extended Master Session Key (EMSK) 602 Additional keying material derived between the peer and server that 603 is exported by the EAP method. The EMSK is at least 64 octets in 604 length, and is never shared with a third party. 606 AAA-Key 607 A key derived by the peer and EAP server, used by the peer and 608 authenticator in the derivation of Transient Session Keys (TSKs). 609 Where a backend authentication server is present, the AAA-Key is 610 transported from the backend authentication server to the 611 authenticator, wrapped within the AAA-Token; it is therefore known 612 by the peer, authenticator and backend authentication server. 613 Despite the name, the AAA-Key is computed regardless of whether a 614 backend authentication server is present. AAA-Key derivation is 615 discussed in Section 2.3; in existing implementations the MSK is 616 used as the AAA-Key. 618 Application-specific Master Session Keys (AMSKs) 619 Keys derived from the EMSK which are cryptographically separate 620 from each other and may be subsequently used in the derivation of 621 Transient Session Keys (TSKs) for extended uses. AMSK derivation 622 is discussed in Section 2.4. 624 AAA-Token 625 Where a backend server is present, the AAA-Key and one or more 626 attributes is transported between the backend authentication server 627 and the authenticator within a package known as the AAA-Token. The 628 format and wrapping of the AAA-Token, which is intended to be 629 accessible only to the backend authentication server and 630 authenticator, is defined by the AAA protocol. Examples include 631 RADIUS [RFC2548] and Diameter [I-D.ietf-aaa-eap]. 633 Initialization Vector (IV) 634 A quantity of at least 64 octets, suitable for use in an 635 initialization vector field, that is derived between the peer and 636 EAP server. Since the IV is a known value in methods such as EAP- 637 TLS [RFC2716], it cannot be used by itself for computation of any 638 quantity that needs to remain secret. As a result, its use has 639 been deprecated and EAP methods are not required to generate it. 640 However, when it is generated it MUST be unpredictable. 642 Pairwise Master Key (PMK) 643 The AAA-Key is divided into two halves, the "Peer to Authenticator 644 Encryption Key" (Enc-RECV-Key) and "Authenticator to Peer 645 Encryption Key" (Enc-SEND-Key) (reception is defined from the point 646 of view of the authenticator). Within [IEEE80211i] Octets 0-31 of 647 the AAA-Key (Enc-RECV-Key) are known as the Pairwise Master Key 648 (PMK). In [IEEE80211i] the TKIP and AES CCMP ciphersuites derive 649 their Transient Session Keys (TSKs) solely from the PMK, whereas 650 the WEP ciphersuite as noted in [RFC3580], derives its TSKs from 651 both halves of the AAA-Key. 653 Transient EAP Keys (TEKs) 654 Session keys which are used to establish a protected channel 655 between the EAP peer and server during the EAP authentication 656 exchange. The TEKs are appropriate for use with the ciphersuite 657 negotiated between EAP peer and server for use in protecting the 658 EAP conversation. Note that the ciphersuite used to set up the 659 protected channel between the EAP peer and server during EAP 660 authentication is unrelated to the ciphersuite used to subsequently 661 protect data sent between the EAP peer and authenticator. An 662 example TEK key hierarchy is described in Appendix C. 664 Transient Session Keys (TSKs) 665 Session keys used to protect data exchanged between the peer and 666 the authenticator after the EAP authentication has successfully 667 completed. TSKs are appropriate for the lower layer ciphersuite 668 negotiated between the EAP peer and authenticator. Examples of TSK 669 derivation are provided in Appendix D. 671 2.2. Key Hierarchy 673 The EAP Key Hierarchy, illustrated in Figure 3, has at the root the 674 long term credential utilized by the selected EAP method. If 675 authentication is based on a pre-shared key, the parties store the 676 EAP method to be used and the pre-shared key. The EAP server also 677 stores the peer's identity and/or other information necessary to 678 decide whether access to some service should be granted. The peer 679 stores information necessary to choose which secret to use for which 680 service. 682 If authentication is based on proof of possession of the private key 683 corresponding to the public key contained within a certificate, the 684 parties store the EAP method to be used and the trust anchors used to 685 validate the certificates. The EAP server also stores the peer's 686 identity and/or other information necessary to decide whether access 687 to some service should be granted. The peer stores information 688 necessary to choose which certificate to use for which service. 690 Based on the long term credential established between the peer and 691 the server, EAP derives two types of keys: 693 [1] Keys calculated locally by the EAP method but not exported 694 by the EAP method, such as the TEKs. 695 [2] Keys exported by the EAP method: MSK, EMSK, IV 697 From the keys exported by the EAP method, two other types of keys may 698 be derived: 700 [3] Keys calculated from exported quantities: AAA-Key, AMSKs. 701 [4] Keys calculated by the Secure Association Protocol from the 702 AAA-Key or AMSKs: TSKs. 704 In order to protect the EAP conversation, methods supporting key 705 derivation typically negotiate a ciphersuite and derive Transient EAP 706 Keys (TEKs) for use with that ciphersuite. The TEKs are stored 707 locally by the EAP method and are not exported. 709 As noted in [RFC3748] Section 7.10, EAP methods generating keys are 710 required to calculate and export the MSK and EMSK, which must be at 711 least 64 octets in length. EAP methods also may export the IV; 712 however, the use of the IV is deprecated. On both the peer and EAP 713 server, the exported MSK and keys derived from the AMSK are utilized 714 in order to calculate the AAA-Key, as described in Section 2.3. 716 Where a backend authentication server is present, the AAA-Key is 717 transported from the backend authentication server to the 718 authenticator within the AAA-Token, using the AAA protocol. 720 Once EAP authentication completes and is successful, the peer and 721 authenticator obtain the AAA-Key and the Secure Association Protocol 722 is run between the peer and authenticator in order to securely 723 negotiate the ciphersuite, derive fresh TSKs used to protect data, 724 and provide mutual proof of possession of the AAA-Key. 726 When the authenticator acts as an endpoint of the EAP conversation 727 rather than a pass-through, EAP methods are implemented on the 728 authenticator as well as the peer. If the EAP method negotiated 729 between the EAP peer and authenticator supports mutual authentication 730 and key derivation, the EAP Master Session Key (MSK) and Extended 731 Master Session Key (EMSK) are derived on the EAP peer and 732 authenticator and exported by the EAP method. In this case, the MSK 733 and EMSK are known only to the peer and authenticator and no other 734 parties. The TEKs and TSKs also reside solely on the peer and 735 authenticator. This is illustrated in Figure 4. As demonstrated in 736 [I-D.ietf-roamops-cert], in this case it is still possible to support 737 roaming between providers, using certificate-based authentication. 739 Where a backend authentication server is utilized, the situation is 740 illustrated in Figure 5. Here the authenticator acts as a pass- 741 through between the EAP peer and a backend authentication server. In 742 this model, the authenticator delegates the access control decision 743 to the backend authentication server, which acts as a Key 744 Distribution Center (KDC). In this case, the authenticator 745 encapsulates EAP packet with a AAA protocol such as RADIUS [RFC3579] 746 or Diameter [I-D.ietf-aaa-eap], and forwards packets to and from the 747 backend authentication server, which acts as the EAP server. Since 748 the authenticator acts as a pass-through, EAP methods reside only on 749 the peer and EAP server As a result, the TEKs, MSK and EMSK are 750 derived on the peer and EAP server. 752 On completion of EAP authentication, EAP methods on the peer and EAP 753 server export the Master Session Key (MSK) and Extended Master 754 Session Key (EMSK). The peer and EAP server then calculate the AAA- 755 Key from the MSK and EMSK, and the backend authentication server 756 sends an Access-Accept to the authenticator, providing the AAA-Key 757 within a protected package known as the AAA-Token. 759 The AAA-Key is then used by the peer and authenticator within the 760 Secure Association Protocol to derive Transient Session Keys (TSKs) 761 required for the negotiated ciphersuite. The TSKs are known only to 762 the peer and authenticator. 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 765 | | ^ 766 | EAP Method | | 767 | | | 768 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | | 769 | | | | | | | 770 | | EAP Method Key |<->| Long-Term | | | 771 | | Derivation | | Credential | | | 772 | | | | | | | 773 | | | +-+-+-+-+-+-+-+ | Local to | 774 | | | | EAP | 775 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Method | 776 | | | | | | 777 | | | | | | 778 | | | | | | 779 | | | | | | 780 | V | | | | 781 | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | | 782 | | TEK | | MSK | |EMSK | |IV | | | 783 | |Derivation | |Derivation | |Derivation | |Derivation | | | 784 | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | | 785 | | | | | | 786 | | | | | V 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 788 | | | ^ 789 | | | | 790 | MSK (64B) | EMSK (64B) | IV (64B) | 791 | | | Exported| 792 | | | by | 793 V V V EAP | 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ Method| 795 | AAA Key Derivation, | | Known | | 796 | Naming & Binding | |(Not Secret) | | 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ V 798 | ---+ 799 | AAA-Key/ Transported | 800 | Name by AAA | 801 | Protocol | 802 V V 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 804 | | ^ 805 | TSK Derivation | Lower layer | 806 | [AAA-Key Cache] | Specific | 807 | | V 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 810 Figure 3: EAP Key Hierarchy 812 +-+-+-+-+-+ +-+-+-+-+-+ 813 | | | | 814 | | | | 815 | Cipher- | | Cipher- | 816 | Suite | | Suite | 817 | | | | 818 +-+-+-+-+-+ +-+-+-+-+-+ 819 ^ ^ 820 | | 821 | | 822 | | 823 V V 824 +-+-+-+-+-+ +-+-+-+-+-+ 825 | | | | 826 | |===============| | 827 | |EAP, TEK Deriv.|Authenti-| 828 | |<------------->| cator | 829 | | | | 830 | | Secure Assoc. | | 831 | peer |<------------->| (EAP | 832 | |===============| server) | 833 | | Link layer | | 834 | | (PPP,IEEE802) | | 835 | | | | 836 |MSK,EMSK | |MSK,EMSK | 837 | AAA-Key/| | AAA-Key/| 838 | Name | | Name | 839 | (TSKs) | | (TSKs) | 840 +-+-+-+-+-+ +-+-+-+-+-+ 841 ^ ^ 842 | | 843 | MSK, EMSK | MSK, EMSK 844 | | 845 | | 846 +-+-+-+-+-+ +-+-+-+-+-+ 847 | | | | 848 | EAP | | EAP | 849 | Method | | Method | 850 | | | | 851 | (TEKs) | | (TEKs) | 852 | | | | 853 +-+-+-+-+-+ +-+-+-+-+-+ 855 Figure 4: Relationship between EAP peer and authenticator (acting as 856 an EAP server), where no backend authentication server is present. 858 +-+-+-+-+-+ +-+-+-+-+-+ 859 | | | | 860 | | | | 861 | Cipher- | | Cipher- | 862 | Suite | | Suite | 863 | | | | 864 +-+-+-+-+-+ +-+-+-+-+-+ 865 ^ ^ 866 | | 867 | | 868 | | 869 V V 870 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 871 | |===============| |========| | 872 | |EAP, TEK Deriv.| | | | 873 | |<-------------------------------->| backend | 874 | | | |AAA-Key/| | 875 | | Secure Assoc. | | Name | | 876 | peer |<------------->|Authenti-|<-------| auth | 877 | |===============| cator |========| server | 878 | | Link Layer | | AAA | (EAP | 879 | | (PPP,IEEE 802)| |Protocol| server) | 880 |MSK,EMSK | | | | | 881 | AAA-Key/| | AAA-Key/| |MSK,EMSK,| 882 | Name | | Name | | AAA-Key/| 883 | (TSKs) | | (TSKs) | | Name | 884 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 885 ^ ^ 886 | | 887 | MSK, EMSK | MSK, EMSK 888 | | 889 | | 890 +-+-+-+-+-+ +-+-+-+-+-+ 891 | | | | 892 | EAP | | EAP | 893 | Method | | Method | 894 | | | | 895 | (TEKs) | | (TEKs) | 896 | | | | 897 +-+-+-+-+-+ +-+-+-+-+-+ 899 Figure 5: Pass-through relationship between EAP peer, authenticator 900 and backend authentication server. 902 2.3. AAA-Key Derivation 904 Where a AAA-Key is generated as the result of a successful EAP 905 authentication with the authenticator A, the AAA-Key is based on the 906 MSK: AAA-Key = MSK(0,63). 908 As discussed in [I-D.irtf-aaaarch-handoff], [IEEE-02-758], 909 [IEEE-03-084], and [8021XHandoff], keying material may be required 910 for use in fast handoff between authenticators. Where the backend 911 authentication server provides keying material to additional 912 authenticators in order to facilitate fast handoff, it is highly 913 desirable for the keying material used on different authenticators B, 914 C to be cryptographically separate, so that if one authenticator is 915 compromised, it does not lead to the compromise of other 916 authenticators. Where keying material is provided by the backend 917 authentication server, a key hierarchy derived from the AMSK can be 918 used to provide cryptographically separate keying material for use in 919 fast handoff. Instead of using the EMSK directly an application 920 specific key (AMSK) is derived as described in Section 2.4: 922 AAA-Key = MSK(0,63) 924 AMSK = KDF(EMSK, "EAP AAA-Key derivation for multiple attachments", 925 length) 927 AAA-Key-B = prf(AMSK(0,63),"EAP AAA-Key derivation for 928 multiple attachments", AAA-Key, B-Called-Station-Id, 929 Calling-Station-Id,length) 931 AAA-Key-C = prf(AMSK(0,63),"EAP AAA-Key derivation for 932 multiple attachments",AAA-Key, C-Called-Station-Id, 933 Calling-Station-Id, length) 935 Where: 936 Calling-Station-Id = STA MAC address 937 B-Called-Station-Id = AP B MAC address 938 C-Called-Station-Id = AP C MAC address 939 prf = HMAC-SHA1 940 KDF = defined in Section 2.4 941 length = length of derived key material 943 Here AAA-Key is derived during the initial EAP authentication between 944 the peer and authenticator A. Based on this initial EAP 945 authentication, an AMSK is also derived, which can be used to derive 946 AAA-Keys for fast authentication between the EAP peer and 947 authenticators B and C. Since the AMSK is cryptographically separate 948 from the MSK, each of these AAA-Keys is cryptographically separate 949 from each other, and are guaranteed to be unique between the EAP peer 950 (also known as the STA) and the authenticator (also known as the AP). 952 2.4. AMSK Key Derivation 954 The EAP AMSK key derivation function (KDF) derives an AMSK from the 955 Extended Master Session Key (EMSK), an application key label, 956 optional application data, and output length. 958 AMSK = KDF(EMSK, key label, optional application data, length) 960 The key labels are printable ASCII strings unique for each 961 application (see Section 8 for IANA Considerations). 963 Additional ciphering keys (TSKs) can be derived from the AMSK using 964 an application specific key derivation mechanism. In many cases, 965 this AMSK->TSK derivation can simply split the AMSK to pieces of 966 correct length. In particular, it is not necessary to use a 967 cryptographic one-way function. The length of the AMSK MUST be 968 specified by the application. 970 The AMSK key derivation function is taken from the PRF+ key expansion 971 PRF from [IKEv2]. This KDF takes 4 parameters as input: secret, 972 label, application data, and output length. It is only defined for 973 255 iterations so it may produce up to 5100 bytes of key material. 975 For the purposes of this specification the secret is taken as the 976 EMSK, the label is the key label described above concatenated with a 977 NUL byte, the application data is also described above and the output 978 length is two bytes. Application data MAY be an empty string. The 979 KDF is based on HMAC-SHA1 [RFC2104] [SHA1]. For this specification we 980 have: 982 KDF (K,L,D,O) = T1 | T2 | T3 | T4 | ... 984 where: 985 T1 = prf (K, S | 0x01) 986 T2 = prf (K, T1 | S | 0x02) 987 T3 = prf (K, T2 | S | 0x03) 988 T4 = prf (K, T3 | S | 0x04) 990 prf = HMAC-SHA1 991 K = EMSK 992 L = key label 993 D = application data 994 O = OutputLength (2 bytes) 995 S = L | " " | D | O 997 The prf+ construction was chosen because of its simplicity and 998 efficiency over other PRFs such as those used in [TLS]. The 999 motivation for the design of this PRF is described in [SIGMA]. 1001 The NUL byte after the key label is used to avoid collisions if one 1002 key label is a prefix of another label (e.g. "foobar" and 1003 "foobarExtendedV2"). This is considered a simpler solution than 1004 requiring a key label assignment policy that prevents prefixes from 1005 occurring. 1007 Where another prf needs to be negotiated, this can be handled within 1008 the EAP method. 1010 2.5. Key Naming 1012 Each key created within the EAP key management framework has a name 1013 (the identifier by which the key can be identified), as well as a 1014 scope (the parties to whom the key is available). This section 1015 describes how keys are named, and the scope within which that name 1016 applies. 1018 Session-Id 1020 EAP methods supporting key naming MUST specify a temporally unique 1021 method identifier known as the EAP Method-Id, which is typically 1022 constructed from nonces or counters used within the exchange. Since 1023 multiple EAP sessions may exist between an EAP peer and EAP server, 1024 the Method-Id allows MSKs to be differentiated. 1026 The concatenation of the EAP Type (expressed in ASCII text), ":" and 1027 the Method-Id (also expressed in ASCII text) is known as the EAP 1028 Session-Id. The inclusion of the Type in the EAP Session-Id ensures 1029 that each EAP method has a distinct name space. 1031 The EAP Session-Id uniquely identifies the EAP session to the EAP 1032 peer and server terminating the EAP conversation. However, suitable 1033 EAP peer and server names may not always be available. As described 1034 in [RFC3748] Section 7.3, the identity provided in the EAP- 1035 Response/Identity, may be different from the identity authenticated 1036 by the EAP method, and as a result the EAP-Response/Identity is 1037 unsuitable for determination of the peer identity. As a result, the 1038 Session-Id scope is defined by the EAP peer name (if securely 1039 exchanged within the method) concatenated with the EAP server name 1040 (also only if securely exchanged). Where a peer or server name is 1041 missing the null string is used. Since an EAP session is not bound 1042 to a particular authentication or specific ports on the peer and 1043 authenticator, the authenticator port or identity are not included in 1044 the Session-Id scope. 1046 The EAP Session-Id is exported by the EAP method along with the 1047 Session-Id scope, if available, and is used to construct names for 1048 other EAP keys. Note that the EAP Session-Id and scope are only 1049 known by the EAP method. As a result, the format of the EAP Session- 1050 Id and the definition of the Session-Id scope needs to be specified 1051 within the method. Appendix E defines the EAP Session-Id and scope 1052 provided by existing methods. 1054 MSK Name 1056 This key is created between the EAP peer and EAP server, and can be 1057 referred to using the string "MSK:", concatenated with the EAP 1058 Session-Id. As with the EAP Session-Id, the MSK scope is defined by 1059 the EAP peer name (if securely exchanged within the method) and the 1060 EAP server name (also only if securely exchanged). Where a peer or 1061 server name is missing the null string is used. 1063 EMSK Name 1065 The EMSK can be referred to using the string "EMSK:", concatenated 1066 with the EAP Session-Id. 1068 As with the EAP Session-Id, the EMSK scope is defined by the EAP peer 1069 name (if securely exchanged within the method) and the EAP server 1070 name (also only if securely exchanged). Where a peer or server name 1071 is missing the null string is used. 1073 AMSK Name 1075 AMSKs, if any, can be referred to using the string "AMSK:", the key 1076 label, ":", application data (see Section 2.4), ":", and the EAP 1077 Session-Id. 1079 As with the EAP Session-Id, the AMSK scope is defined by the EAP peer 1080 name (if securely exchanged within the method), ":" and the EAP 1081 server name (also only if securely exchanged). Where a peer or 1082 server name is missing the null string is used. 1084 AAA-Key Name 1086 The AAA-Key is derived from either the MSK or AMSK and so can be 1087 referred to using the MSK or AMSK names. 1089 The AAA-Key scope is provided by the concatenation of the EAP peer 1090 name (if securely provided to the authenticator), and the 1091 authenticator name (if securely provided to the peer). 1093 For the purpose of identifying the authenticator to the peer, the 1094 value of the NAS-Identifier attribute is recommended. The 1095 authenticator may include the NAS-Identifier attribute to the AAA 1096 server in an Access-Request, and the authenticator may provide the 1097 NAS-Identifier (unsecured) to the EAP peer in the EAP- 1098 Request/Identity or via a lower layer mechanism (such as the 802.11 1099 Beacon/Probe Response). Where the NAS-Identifier is provided by the 1100 authenticator to the peer a secure mechanism is RECOMMENDED. 1102 For the purpose of identifying the peer to the authenticator, the EAP 1103 peer identifier provided within the EAP method is recommended. It 1104 cannot be assumed that the authenticator is aware of the EAP peer 1105 name used within the method. Therefore alternatives mechanisms need 1106 to be used to provide the EAP peer name to the authenticator. For 1107 example, the AAA server may include the EAP peer name in the User- 1108 Name attribute of the Access-Accept or the peer may provide the 1109 authenticator with its name via a lower layer mechanism. 1111 Absent an explicit binding step within the Secure Association 1112 Protocol, the AAA-Key is not bound to a specific peer or 1113 authenticator port. As a result, the peer or authenticator port over 1114 which the EAP conversation takes place is not included in the AAA-Key 1115 scope. 1117 PMK Name 1119 This document does not specify a naming scheme for the PMK. The PMK 1120 is only identified by the AAA-Key from which it is derived. 1121 Similarly, the PMK scope is the same as the AAA-Key scope. 1123 Note: IEEE 802.11i names the PMKID for the purposes of being able to 1124 refer to it in the Secure Association protocol; this naming is based 1125 on a hash of the PMK itself as well as some other parameters (see 1126 Section 8.5.1.2 [IEEE80211i]). 1128 TEKs 1130 The TEKs may or may not be named. Their naming is specified in the 1131 EAP method. Since the TEKs are only known by the EAP peer and 1132 server, the TEK scope is the same as the Session-Id scope. 1134 TSKs 1136 The TSKs are typically named. Their naming is specified in the Secure 1137 Association (phase 2) protocol, so that the correct set of transient 1138 session keys can be identified for processing a given packet. The 1139 scope of the TSKs is negotiated within the Secure Association 1140 Protocol. 1142 TSK creation and deletion operations are typically supported so that 1143 establishment and re-establishment of TSKs can be synchronized 1144 between the parties. 1146 In order to avoid confusion in the case where an EAP peer has more 1147 than one AAA-Key (phase 1b) applicable to establishment of a phase 2 1148 security association, the secure Association protocol needs to 1149 utilize the AAA-Key name so that the appropriate phase 1b keying 1150 material can be identified for use in the Secure Association Protocol 1151 exchange. 1153 3. Security Associations 1155 During EAP authentication and subsequent exchanges, four types of 1156 security associations (SAs) are created: 1158 [1] EAP method SA. This SA is between the peer and EAP server. It 1159 stores state that can be used for "fast reconnect" or other 1160 functionality in some EAP methods. Not all EAP methods create such 1161 an SA. 1163 [2] EAP-Key SA. This is an SA between the peer and EAP server, which 1164 is used to store the keying material exported by the EAP method. 1165 Current EAP server implementations do not retain this SA after the 1166 EAP conversation completes, but proposals such as [IEEE-03-084] and 1167 [I-D.irtf-aaaarch-handoff] use this SA for purposes such as pre- 1168 emptive key distribution. 1170 [3] AAA SA(s). These SAs are between the authenticator and the backend 1171 authentication server. They permit the parties to mutually 1172 authenticate each other and protect the communications between 1173 them. 1175 [4] Service SA(s). These SAs are between the peer and authenticator, 1176 and they are created as a result of phases 1-2 of the conversation 1177 (see Section 1.3). 1179 Examples of security associations are provided in Appendix F. 1181 3.1. EAP Method SA (peer - EAP server) 1183 An EAP method may store some state on the peer and EAP server even 1184 after phase 1a has completed. 1186 Typically, this is used for "fast reconnect": the peer and EAP server 1187 can confirm that they are still talking to the same party, perhaps 1188 using fewer round-trips or less computational power. In this case, 1189 the EAP method SA is essentially a cache for performance 1190 optimization, and either party may remove the SA from its cache at 1191 any point. 1193 An EAP method may also keep state in order to support pseudonym-based 1194 identity protection. This is typically a cache as well (the 1195 information can be recreated if the original EAP method SA is lost), 1196 but may be stored for longer periods of time. 1198 The EAP method SA is not restricted to a particular service or 1199 authenticator and is most useful when the peer accesses many 1200 different authenticators. An EAP method is responsible for 1201 specifying how the parties select if an existing EAP method SA should 1202 be used, and if so, which one. Where multiple backend authentication 1203 servers are used, EAP method SAs are not typically synchronized 1204 between them. 1206 EAP method implementations should consider the appropriate lifetime 1207 for the EAP method SA. "Fast reconnect" assumes that the information 1208 required (primarily the keys in the EAP method SA) hasn't been 1209 compromised. In case the original authentication was carried out 1210 using, for instance, a smart card, it may be easier to compromise the 1211 EAP method SA (stored on the PC, for instance), so typically the EAP 1212 method SAs have a limited lifetime. 1214 Contents: 1216 o Implicitly, the EAP method this SA refers to 1217 o Internal (non-exported) cryptographic state 1218 o EAP method SA name 1219 o SA lifetime 1221 3.2. EAP-Key SA 1223 This is an SA between the peer and EAP server, which is used to store 1224 the keying material exported by the EAP method. Current EAP server 1225 implementations do not retain this SA after the EAP conversation 1226 completes, but future implementations could use this SA for pre- 1227 emptive key distribution. 1229 Contents: 1231 o MSK and EMSK names 1232 o MSK and EMSK 1233 o SA lifetime 1235 3.3. AAA SA(s) (authenticator - backend authentication server) 1237 In order for the authenticator and backend authentication server to 1238 authenticate each other, they need to store some information. 1240 In case the authenticator and backend authentication server are 1241 colocated, and they communicate using local procedure calls or shared 1242 memory, this SA need not necessarily contain any information. 1244 3.4. Service SA(s) (peer - authenticator) 1246 The service SAs store information about the service being provided. 1247 These include the Root service SA and derived unicast and multicast 1248 service SAs. 1250 The Root service SA is established as the result of the completion of 1251 EAP authentication (phase 1a) and AAA-Key derivation or transport 1252 (phase 1b). It includes: 1254 o Service parameters (or at least those parameters 1255 that are still needed) 1256 o On the authenticator, service authorization 1257 information received from the backend authentication 1258 server (or necessary parts of it) 1259 o On the peer, usually locally configured service 1260 authorization information. 1261 o The AAA-Key, if it can be needed again (to refresh 1262 and/or resynchronize other keys or for another reason) 1263 o AAA-Key lifetime 1265 Unicast and (optionally) multicast service SAs are derived from the 1266 Root service SA, via the Secure Association Protocol. In order for 1267 unicast and multicast service SAs and associated TSKs to be 1268 established, it is not necessary for EAP authentication (phase 1a) to 1269 be rerun each time. Instead, the Secure Association Protocol can be 1270 used to mutually prove possession of the AAA-Key and create 1271 associated unicast (phase 2a) and multicast (phase 2b) service SAs 1272 and TSKs, enabling the EAP exchange to be bypassed. Unicast and 1273 multicast service SAs include: 1275 o Service parameters negotiated by the Secure Association Protocol. 1276 o Endpoint identifiers. 1277 o Transient Session Keys used to protect the communication. 1278 o Transient Session Key lifetime. 1280 One function of the Secure Association Protocol is to bind the the 1281 unicast and multicast service SAs and TSKs to endpoint identifiers. 1282 For example, within [IEEE802.11i], the 4-way handshake binds the TSKs 1283 to the MAC addresses of the endpoints; in [IKEv2], the TSKs are bound 1284 to the IP addresses of the endpoints and the negotiated SPI. 1286 It is possible for more than one unicast or multicast service SA to 1287 be derived from a single Root service SA. However, a unicast or 1288 multicast service SA is always descended from only one Root service 1289 SA. Unicast or multicast service SAs descended from the same Root 1290 service SA may utilize the same security parameters (e.g. mode, 1291 ciphersuite, etc.) or they may utilize different parameters. 1293 An EAP peer may be able to negotiate multiple service SAs with a 1294 given authenticator, or may be able to maintain one or more service 1295 SAs with multiple authenticators, depending on the properties of the 1296 media. 1298 Except where explicitly specified by the Secure Association Protocol, 1299 it should not be assumed that the installation of new service SAs 1300 implies deletion of old service SAs. It is possible for multicast 1301 Root service SAs to between the same EAP peer and authenticator; 1302 during a re-key of a unicast or multicast service SA it is possible 1303 for two service SAs to exist during the period between when the new 1304 service SA and corresponding TSKs are calculated and when they are 1305 installed. 1307 Similarly, deletion or creation of a unicast or multicast service SA 1308 does not necessarily imply deletion or creation of related unicast or 1309 multicast service SAs, unless specified by the Secure Association 1310 protocol. For example, a unicast service SA may be rekeyed without 1311 implying a rekey of the multicast service SA. 1313 The deletion of the Root service SA does not necessarily imply the 1314 deletion of the derived unicast and multicast service SAs and 1315 associated TSKs. Failure to mutually prove possession of the AAA-Key 1316 during the Secure Association Protocol exchange need not be grounds 1317 for deletion of the AAA-Key by both parties; the action to be taken 1318 is defined by the Secure Association Protocol. 1320 3.4.1. Sharing service SAs 1322 A single service may be provided by multiple logical or physical 1323 service elements. Each service is responsible for specifying how 1324 changing service elements is handled. Some approaches include: 1326 Transparent sharing 1327 If the service parameters visible to the other party (either peer 1328 or authenticator) do not change, the service can be moved without 1329 requiring cooperation from the other party. 1331 Whether such a move should be supported or used depends on 1332 implementation and administrative considerations. For instance, an 1333 administrator may decide to configure a group of IKEv2/IPsec 1334 gateways in a cluster for high-availability purposes, if the 1335 implementation used supports this. The peer does not necessarily 1336 have any way of knowing when the change occurs. 1338 No sharing 1339 If the service parameters require changing, some changes may 1340 require terminating the old service, and starting a new 1341 conversation from phase 0. This approach is used by all services 1342 for at least some parameters, and it doesn't require any protocol 1343 for transferring the service SA between the service elements. 1345 The service may support keeping the old service element active 1346 while the new conversation takes phase, to decrease the time the 1347 service is not available. 1349 Some sharing 1350 The service may allow changing some parameters by simply agreeing 1351 about the new values. This may involve a similar exchange as in 1352 phase 2, or perhaps a shorter conversation. 1354 This option usually requires some protocol for transferring the 1355 service SA between the elements. An administrator may decide not to 1356 enable this feature at all, and typically the sharing is restricted 1357 to some particular service elements (defined either by a service 1358 parameter, or simple administrative decision). If the old and new 1359 service element do not support such "context transfer", this 1360 approach falls back to the previous option (no transfer). 1362 Services supporting this feature should also consider what changes 1363 require new authorization from the backend authentication server 1364 (see Section 4.2). 1366 Note that these considerations are not limited to service 1367 parameters related to the authenticator--they apply to peer 1368 parameters as well. 1370 4. Key Management 1372 The EAP peer, authenticator and backend server may support key 1373 caching. Since EAP supports key derivation, but not key management, 1374 this functionality needs to be provided by the Secure Association 1375 Protocol. Key management support includes: 1377 [a] Key lifetime determination. EAP does not support negotiation of 1378 key lifetimes, nor does it support rekey without reauthentication. 1380 As a result, the Secure Association Protocol is responsible for 1381 rekey and determination of the key lifetime. Where key caching is 1382 supported, secure negotiation of key lifetimes is RECOMMENDED. 1383 Lower layers that support rekey, but not key caching may not 1384 require key lifetime negotiation. To take an example from IKE, the 1385 difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes 1386 were negotiated. In IKEv2, each end of the SA is responsible for 1387 enforcing its own lifetime policy on the SA and rekeying the SA 1388 when necessary. 1390 [b] Key resynchronization. It is possible for the peer or 1391 authenticator to reboot or reclaim resources, clearing portions or 1392 all of the key cache. Therefore, key lifetime negotiation cannot 1393 guarantee that the key cache will remain synchronized, and the peer 1394 may not be able to determine before attempting to use a AAA-Key 1395 whether it exists within the authenticator cache. It is therefore 1396 RECOMMENDED for the Secure Association Protocol to provide a 1397 mechanism for key state resynchronization. Since in this situation 1398 one or more of the parties initially do not possess a key with 1399 which to protect the resynchronization exchange, securing this 1400 mechanism may be difficult. 1402 [c] Key selection. Where key caching is supported, it may be possible 1403 for the EAP peer and authenticator to share more than one key of a 1404 given type. As a result, the Secure Association Protocol needs to 1405 support key selection, using the EAP Key Naming scheme described in 1406 this document. 1408 [d] Key scope determination. Since the Discovery phase is handled out- 1409 of-band, EAP does not provide a mechanism by which the peer can 1410 determine the authenticator identity. As a result, where the 1411 authenticator has multiple ports and AAA-Key caching is supported, 1412 the EAP peer may not be able to determine the scope of validity of 1413 a AAA-Key. Similarly, where the EAP peer has multiple ports, the 1414 authenticator may not be able to determine whether a peer has 1415 authorization to use a particular AAA-Key. To allow key scope 1416 determination, the lower layer SHOULD provide a mechanism by which 1417 the peer can determine the scope of the AAA-Key cache on each 1418 authenticator, and by which the authenticator can determine the 1419 scope of the AAA-Key cache on a peer. 1421 4.1. Key Caching 1423 Key caching may be supported on the EAP peer, authenticator and 1424 backend server. Where explicitly supported by the lower layer, the 1425 EAP peer and authenticator MAY cache the AAA-Key and/or TSKs. The 1426 structure of the key cache on the peer and authenticator is defined 1427 by the lower layer. Unless specified by the lower layer, the EAP 1428 peer, authenticator and server MUST assume that peers and 1429 authenticators do not cache the AAA-Key or TSKs. 1431 The EAP peer and server MAY cache keys exported by the EAP method as 1432 well as keys derived from them, subject to the following 1433 restrictions: 1435 [1] In order to avoid key reuse, on the EAP server, transported keys 1436 are deleted once they are sent. An EAP server MUST NOT retain keys 1437 that it has previously sent to the authenticator. For example, an 1438 EAP server that has transported a AAA-Key based on the MSK MUST 1439 delete both the AAA-Key and the MSK, and no keys may be derived 1440 from either the AAA-Key or the MSK from that point forward by the 1441 server. 1443 [2] Keys which are not transported, such as the EMSK, MAY be cached on 1444 the EAP server. While AMSKs calculated from the EMSK MUST be 1445 deleted from the EAP server once they are transported, the parent 1446 EMSK may remain in the EAP server cache. 1448 4.2. Parent-Child Relationships 1450 When keying material exported by EAP methods expires, all keying 1451 material derived from the exported keying material expires, including 1452 the AAA-Key, AMSKs and TSKs. 1454 When an EAP reauthentication takes place, new keying material is 1455 derived and exported by the EAP method, which eventually results in 1456 replacement of calculated keys, including the AAA-Key, AMSKs, and 1457 TSKs. 1459 As a result, while the lifetime of calculated keys can be less than 1460 or equal that of the exported keys they are derived from, it cannot 1461 be greater. For example, TSK rekey may occur prior to EAP 1462 reauthentication. 1464 Failure to mutually prove possession of the AAA-Key during the Secure 1465 Association Protocol exchange need not be grounds for deletion of the 1466 AAA-Key by both parties; rate-limiting Secure Association Protocol 1467 exchanges could be used to prevent a brute force attack. 1469 4.3. Local Key Lifetimes 1471 The Transient EAP Keys (TEKs) are session keys used to protect the 1472 EAP conversation. The TEKs are internal to the EAP method and are 1473 not exported. TEKs are typically created during an EAP conversation, 1474 used until the end of the conversation and then discarded. However, 1475 methods may rekey TEKs during a conversation. 1477 When using TEKs within an EAP conversation or across conversations, 1478 it is necessary to ensure that replay protection and key separation 1479 requirements are fulfilled. For instance, if a replay counter is 1480 used, TEK rekey MUST occur prior to wrapping of the counter. 1481 Similarly, TSKs MUST remain cryptographically separate from TEKs 1482 despite TEK rekeying or caching. This prevents TEK compromise from 1483 leading directly to compromise of the TSKs and vice versa. 1485 EAP methods may cache local keying material which may persist for 1486 multiple EAP conversations when fast reconnect is used [RFC 3748]. 1487 For example, EAP methods based on TLS (such as EAP-TLS [RFC2716]) 1488 derive and cache the TLS Master Secret, typically for substantial 1489 time periods. The lifetime of other local keying material calculated 1490 within the EAP method is defined by the method. Note that in 1491 general, when using fast reconnect, there is no guarantee to that the 1492 original long-term credentials are still in the possession of the 1493 peer. For instance, a card hold holding the private key for EAP-TLS 1494 may have been removed. EAP servers SHOULD also verify that the long- 1495 term credentials are still valid, such as by checking that 1496 certificate used in the original authentication has not yet expired. 1498 4.4. Exported and Calculated Key Lifetimes 1500 All EAP methods generating keys are required to generate the MSK and 1501 EMSK, and may optionally generate the IV. However, EAP, defined in 1502 [RFC3748], does not support the negotiation of lifetimes for exported 1503 keying material such as the MSK, EMSK and IV. 1505 Several mechanisms exist for managing key lifetimes: 1507 [a] AAA attributes. AAA protocols such as RADIUS [RFC2865] and 1508 Diameter [DiamEAP] support the Session-Timeout attribute. The 1509 Session-Timeout value represents the maximum lifetime of the 1510 exported keys, and all keys calculated from it. If the AAA server 1511 caches exported keys, then it MUST expire the exported keys and all 1512 keys calculated from them, no later than the future time indicated 1513 by Session-Timeout. 1515 On the authenticator, where EAP is used for authentication, the 1516 Session-Timeout value represents the maximum session time prior to 1517 re-authentication, as described in [RFC3580]. Where EAP is used 1518 for pre-authentication, the session may not start until some future 1519 time, or may never occur. Nevertheless, the Session-Timeout value 1520 represents the time after which the AAA-Key, and all keys 1521 calculated from it, will have expired on the authenticator. If the 1522 session subsequently starts, re-authentication will be initiated 1523 once the Session-Time has expired. If the session never started, 1524 or started and ended, the AAA-Key and all keys calculated from it 1525 will be expired by the authenticator prior to the future time 1526 indicated by Session-Timeout. 1528 Since the TSK lifetime is often determined by authenticator 1529 resources, the AAA server has no insight into the TSK derivation 1530 process, and by the principle of ciphersuite independence, it is 1531 not appropriate for the AAA server to manage any aspect of the TSK 1532 derivation process, including the TSK lifetime. 1534 [b] Lower layer mechanisms. While AAA attributes can communicate the 1535 maximum exported key lifetime, this only serves to synchronize the 1536 key lifetime between the backend authentication server and the 1537 authenticator. Lower layer mechanisms can then be used to enable 1538 the lifetime of exported and calculated keys to be negotiated 1539 between the peer and authenticator. 1541 Where TSKs are established as the result of a Secure Association 1542 Protocol exchange, it is RECOMMENDED that the Secure Association 1543 Protocol include support for TSK resynchronization. Where the TSK 1544 is taken from the AAA-Key, there is no need to manage the TSK 1545 lifetime as a separate parameter, since the TSK lifetime and AAA- 1546 Key lifetime are identical. 1548 [c] System defaults. Where the EAP method does not support the 1549 negotiation of the exported key lifetime, and a key lifetime 1550 negotiation mechanism is not provided by the lower lower, there may 1551 be no way for the peer to learn the exported key liftime. In this 1552 case it is RECOMMENDED that the peer assume a default value of the 1553 exported key lifetime; 8 hours is suggested. Similarly, the 1554 lifetime of calculated keys can also be managed as a system 1555 parameter on the authenticator. 1557 4.5. Key cache synchronization 1559 Issues arise when attempting to synchronize the key cache on the peer 1560 and authenticator. Lifetime negotiation alone cannot guarantee key 1561 cache synchronization. 1563 One problem is that the AAA protocol cannot guarantee synchronization 1564 of key lifetimes between the peer and authenticator. Where the 1565 Secure Association Protocol is not run immediately after EAP 1566 authentication, the exported and calculated key lifetimes will not be 1567 known by the peer during the hiatus. Where EAP pre-authentication 1568 occurs, this can leave the peer uncertain whether a subsequent 1569 attempt to use the exported keys will prove successful. 1571 However, even where the Secure Association Protocol is run 1572 immediately after EAP, it is still possible for the authenticator to 1573 reclaim resources if the created key state is not immediately 1574 utilized. 1576 The lower layer may utilize Discovery mechanisms to assist in this. 1577 For example, the authenticator manages the AAA-Key cache by deleting 1578 the oldest AAA-Key first (LIFO), the relative creation time of the 1579 last AAA-Key to be deleted could be advertised with the Discovery 1580 phase, enabling the peer to determine whether a given AAA-Key had 1581 been expired from the authenticator key cache prematurely. 1583 4.6. Key Scope Issues 1585 As described in Section 2.3, the AAA-Key is calculated from the EMSK 1586 and MSK by the EAP peer and server, and is used as the root of the 1587 ciphersuite-specific key hierarchy. Where a backend authentication 1588 server is present, the AAA-Key is transported from the EAP server to 1589 the authenticator; where it is not present, the AAA-Key is calculated 1590 on the authenticator. 1592 Regardless of how many sessions are initiated using it, the AAA-Key 1593 scope is between the EAP peer that calculates it, and the 1594 authenticator that either calculates it (where no backend 1595 authenticator is present) or receives it from the server (where a 1596 backend authenticator server is present). 1598 It should be understood that an authenticator or peer: 1600 [a] may contain multiple physical ports; 1601 [b] may advertise itself as multiple "virtual" authenticators 1602 or peers; 1603 [c] may utilize multiple CPUs; 1604 [d] may support clustering services for load balancing or failover. 1606 As illustrated in Figure 1, an EAP peer with multiple ports may be 1607 attached to one or more authenticators, each with multiple ports. 1608 Where the peer and authenticator identify themselves using a port 1609 identifier such as a link layer address, it may not be obvious to the 1610 peer which authenticator ports are associated with which 1611 authenticators. Similarly, it may not be obvious to the 1612 authenticator which peer ports are associated with which peers. As a 1613 result, the peer and authenticator may not be able to determine the 1614 scope of the AAA-Key. 1616 When a single physical authenticator advertises itself as multiple 1617 "virtual authenticators", the EAP peer and authenticator also may not 1618 be able to agree on the scope of the AAA-Key, creating a security 1619 vulnerability. For example, the peer may assume that the "virtual 1620 authenticators" are distinct and do not share a key cache, whereas, 1621 depending on the architecture of the physical AP, a shared key cache 1622 may or may not be implemented. 1624 Where the AAA-Key is shared between "virtual authenticators" an 1625 attacker acting as a peer could authenticate with the "Guest" 1626 "virtual authenticator" and derive a AAA-Key. If the virtual 1627 authenticators share a key cache, then the peer can utilize the AAA- 1628 Key derived for the "Guest" network to obtain access to the 1629 "Corporate Intranet" virtual authenticator. 1631 Several measures are recommended to address these issues: 1633 [a] Authenticators are REQUIRED to cache associated authorizations 1634 along with the AAA-Key and apply authorizations consistently. This 1635 ensures that an attacker cannot obtain elevated privileges even 1636 where the AAA-Key cache is shared between "virtual authenticators". 1638 [b] It is RECOMMENDED that physical authenticators maintain separate 1639 AAA-Key caches for each "virtual authenticator". 1641 [c] It is RECOMMENDED that each "virtual authenticator" identify itself 1642 distinctly to the AAA server, such as by utilizing a distinct NAS- 1643 identifier attribute. This enables the AAA server to utilize a 1644 separate credential to authenticate each "virtual authenticator". 1646 [d] It is RECOMMENDED that Secure Association Protocols identify peers 1647 and authenticators unambiguously, without incorporating implicit 1648 assumptions about peer and authenticator architectures. Using 1649 port-specific MAC addresses as identifiers is NOT RECOMMENDED where 1650 peers and authenticators may support multiple ports. 1652 [e] The AAA server and authenticator MAY implement additional 1653 attributes in order to further restrict the AAA-Key scope. For 1654 example, in 802.11, the AAA server may provide the authenticator 1655 with a list of authorized Called or Calling-Station-Ids and/or 1656 SSIDs for which the AAA-Key is valid. 1658 [f] Where the AAA server provides attributes restricting the key scope, 1659 it is RECOMMENDED that restrictions be securely communicated by the 1660 authenticator to the peer. This is typically accomplished using 1661 the Secure Association Protocol, but also can be accomplished via 1662 the EAP method or the lower layer. 1664 4.7. Key Strength 1666 In order to guard against brute force attacks, EAP methods deriving 1667 keys need to be capable of generating keys with an appropriate 1668 effective symmetric key strength. In order to ensure that key 1669 generation is not the weakest link, it is RECOMMENDED that EAP 1670 methods utilizing public key cryptography choose a public key that 1671 has a cryptographic strength meeting the symmetric key strength 1672 requirement. 1674 As noted in [RFC3766] Section 5, this results in the following 1675 required RSA or DH module and DSA subgroup size in bits, for a given 1676 level of attack resistance in bits: 1678 Attack Resistance RSA or DH Modulus DSA subgroup 1679 (bits) size (bits) size (bits) 1680 ----------------- ----------------- ------------ 1681 70 947 128 1682 80 1228 145 1683 90 1553 153 1684 100 1926 184 1685 150 4575 279 1686 200 8719 373 1687 250 14596 475 1689 4.8. Key Wrap 1691 As described in [RFC3579] Section 4.3, known problems exist in the 1692 key wrap specified in [RFC2548]. Where the same RADIUS shared secret 1693 is used by a PAP authenticator and an EAP authenticator, there is a 1694 vulnerability to known plaintext attack. Since RADIUS uses the 1695 shared secret for multiple purposes, including per-packet 1696 authentication, attribute hiding, considerable information is exposed 1697 about the shared secret with each packet. This exposes the shared 1698 secret to dictionary attacks. MD5 is used both to compute the RADIUS 1699 Response Authenticator and the Message-Authenticator attribute, and 1700 some concerns exist relating to the security of this hash 1701 [MD5Attack]. 1703 As discussed in [RFC3579] Section 4.3, the security vulnerabilities 1704 of RADIUS are extensive, and therefore development of an alternative 1705 key wrap technique based on the RADIUS shared secret would not 1706 substantially improve security. As a result, [RFC3759] Section 4.2 1707 recommends running RADIUS over IPsec. The same approach is taken in 1708 Diameter EAP [I-D.ietf-aaa-eap], which defines cleartext key 1709 attributes, to be protected by IPsec or TLS. 1711 Where an untrusted AAA intermediary is present (such as a RADIUS 1712 proxy or a Diameter agent), and data object security is not used, the 1713 AAA-Key may be recovered by an attacker in control of the untrusted 1714 intermediary. Possession of the AAA-Key enables decryption of data 1715 traffic sent between the peer and a specific authenticator; however 1716 where key separation is implemented, compromise of the AAA-Key does 1717 not enable an attacker to impersonate the peer to another 1718 authenticator, since that requires possession of the EMSK, which is 1719 not transported by the AAA protocol. This vulnerability may be 1720 mitigated by implementation of redirect functionality, as provided in 1721 [RFC3588]. 1723 5. Handoff Support 1725 With EAP, a number of mechanisms may be utilized in order to reduce 1726 the latency of handoff between authenticators. One such mechanism is 1727 EAP pre-authentication, in which EAP is utilized to pre-establish a 1728 AAA-Key on an authenticator prior to arrival of the peer. 1730 "Fast Handoff" is defined as a conversation in which the EAP exchange 1731 (phase 1a) and associated AAA pass-through is bypassed, so as to 1732 reduce latency. Fast handoff mechanisms include: 1734 [a] Pre-emptive handoff. In this technique, the AAA server pre- 1735 establishes key state on the authenticator prior to arrival of the 1736 peer, without completion of EAP authentication. As described in 1737 [IEEE-03-084] and [I.D.irtf-aaaarch-handoff], this technique 1738 includes conventional AAA-Key transport, but without an EAP 1739 authentication. 1741 [b] Context transfer. In this technique, the old authenticator 1742 transfers the session text to the new authenticator, either prior 1743 to, or after the arrival of the peer. As a result, AAA-Key 1744 transport (phase 1b) is bypassed. 1746 [c] Key Request. In this technique, the peer requests that the new 1747 authenticator retrieve a named key from the EAP server for 1748 potential use in a forthcoming session. In this technique, EAP 1749 authentication (phase 1a) is bypassed, but AAA-Key transport (phase 1750 1b) is not. 1752 5.1. Authorization 1754 In a typical network access scenario (dial-in, wireless LAN, etc.) 1755 access control mechanisms are typically applied. These mechanisms 1756 include user authentication as well as authorization for the offered 1757 service. 1759 As a part of the authentication process, the AAA network determines 1760 the user's authorization profile. The user authorizations are 1761 transmitted by the backend authentication server to the EAP 1762 authenticator (also known as the Network Access Server or 1763 authenticator) included with the AAA-Token, which also contains the 1764 AAA-Key, in Phase 1b of the EAP conversation. Typically, the profile 1765 is determined based on the user identity, but a certificate presented 1766 by the user may also provide authorization information. 1768 The backend authentication server is responsible for making a user 1769 authorization decision, answering the following questions: 1771 [a] Is this a legitimate user for this particular network? 1773 [b] Is this user allowed the type of access he or she is requesting? 1775 [c] Are there any specific parameters (mandatory tunneling, bandwidth, 1776 filters, and so on) that the access network should be aware of for 1777 this user? 1779 [d] Is this user within the subscription rules regarding time of day? 1781 [e] Is this user within his limits for concurrent sessions? 1783 [f] Are there any fraud, credit limit, or other concerns that indicate 1784 that access should be denied? 1786 While the authorization decision is in principle simple, the process 1787 is complicated by the distributed nature of AAA decision making. 1788 Where brokering entities or proxies are involved, all of the AAA 1789 devices in the chain from the authenticator to the home AAA server 1790 are involved in the decision. For instance, a broker can disallow 1791 access even if the home AAA server would allow it, or a proxy can add 1792 authorizations (e.g., bandwidth limits). 1794 Decisions can be based on static policy definitions and profiles as 1795 well as dynamic state (e.g. time of day or limits on the number of 1796 concurrent sessions). In addition to the Accept/Reject decision made 1797 by the AAA chain, parameters or constraints can be communicated to 1798 the authenticator. 1800 The criteria for Accept/Reject decisions or the reasons for choosing 1801 particular authorizations are typically not communicated to the 1802 authenticator, only the final result. As a result, the authenticator 1803 has no way to know what the decision was based on. Was a set of 1804 authorization parameters sent because this service is always provided 1805 to the user, or was the decision based on the time/day and the 1806 capabilities of the requesting authenticator device? 1808 5.2. Correctness 1810 Bypassing all or portions of the AAA conversation creates challenges 1811 in ensuring that authorization is properly handled. These include: 1813 [a] Consistent application of session time limits. A fast handoff 1814 should not automatically increase the available session time, 1815 allowing a user to endlessly extend their network access by 1816 changing the point of attachment. 1818 [b] Avoidance of privilege elevation. A fast handoff should not result 1819 in a user being granted access to services which they are not 1820 entitled to. 1822 [c] Consideration of dynamic state. In situations in which dynamic 1823 state is involved in the access decision (day/time, simultaneous 1824 session limit) it should be possible to take this state into 1825 account either before or after access is granted. Note that 1826 consideration of network-wide state such as simultaneous session 1827 limits can typically only be taken into account by the backend 1828 authentication server. 1830 [d] Encoding of restrictions. Since a authenticator may not be aware 1831 of the criteria considered by a backend authentication server when 1832 allowing access, in order to ensure consistent authorization during 1833 a fast handoff it may be necessary to explicitly encode the 1834 restrictions within the authorizations provided in the AAA-Token. 1836 [e] State validity. The introduction of fast handoff should not render 1837 the authentication server incapable of keeping track of network- 1838 wide state. 1840 A fast handoff mechanism capable of addressing these concerns is said 1841 to be "correct". One condition for correctness is as follows: For a 1842 fast handoff to be "correct" it MUST establish on the new device the 1843 same context as would have been created had the new device completed 1844 a AAA conversation with the authentication server. 1846 A properly designed fast handoff scheme will only succeed if it is 1847 "correct" in this way. If a successful fast handoff would establish 1848 "incorrect" state, it is preferable for it to fail, in order to avoid 1849 creation of incorrect context. 1851 Some backend authentication server and authenticator configurations 1852 are incapable of meeting this definition of "correctness". For 1853 example, if the old and new device differ in their capabilities, it 1854 may be difficult to meet this definition of correctness in a fast 1855 handoff mechanism that bypasses AAA. Backend authentication servers 1856 often perform conditional evaluation, in which the authorizations 1857 returned in an Access-Accept message are contingent on the 1858 authenticator or on dynamic state such as the time of day or number 1859 of simultaneous sessions. For example, in a heterogeneous 1860 deployment, the backend authentication server might return different 1861 authorizations depending on the authenticator making the request, in 1862 order to make sure that the requested service is consistent with the 1863 authenticator capabilities. 1865 If differences between the new and old device would result in the 1866 backend authentication server sending a different set of messages to 1867 the new device than were sent to the old device, then if the fast 1868 handoff mechanism bypasses AAA, then the fast handoff cannot be 1869 carried out correctly. 1871 For example, if some authenticator devices within a deployment 1872 support dynamic VLANs while others do not, then attributes present in 1873 the Access-Request (such as the authenticator-IP-Address, 1874 authenticator-Identifier, Vendor-Identifier, etc.) could be examined 1875 to determine when VLAN attributes will be returned, as described in 1876 [RFC3580]. VLAN support is defined in [IEEE8021Q]. If a fast 1877 handoff bypassing the backend authentication server were to occur 1878 between a authenticator supporting dynamic VLANs and another 1879 authenticator which does not, then a guest user with access 1880 restricted to a guest VLAN could be given unrestricted access to the 1881 network. 1883 Similarly, in a network where access is restricted based on the day 1884 and time, Service Set Identifier (SSID), Calling-Station-Id or other 1885 factors, unless the restrictions are encoded within the 1886 authorizations, or a partial AAA conversation is included, then a 1887 fast handoff could result in the user bypassing the restrictions. 1889 In practice, these considerations limit the situations in which fast 1890 handoff mechanisms bypassing AAA can be expected to be successful. 1891 Where the deployed devices implement the same set of services, it may 1892 be possible to do successful fast handoffs within such mechanisms. 1893 However, where the supported services differ between devices, the 1894 fast handoff may not succeed. For example, [RFC2865] section 1.1 1895 states: 1897 "A authenticator that does not implement a given service MUST NOT 1898 implement the RADIUS attributes for that service. For example, a 1899 authenticator that is unable to offer ARAP service MUST NOT 1900 implement the RADIUS attributes for ARAP. A authenticator MUST 1901 treat a RADIUS access-accept authorizing an unavailable service as 1902 an access-reject instead." 1904 Note that this behavior only applies to attributes that are known, 1905 but not implemented. For attributes that are unknown, [RFC2865] 1906 Section 5 states: 1908 "A RADIUS server MAY ignore Attributes with an unknown Type. A 1909 RADIUS client MAY ignore Attributes with an unknown Type." 1911 In order to perform a correct fast handoff, if a new device is 1912 provided with RADIUS context for a known but unavailable service, 1913 then it MUST process this context the same way it would handle a 1914 RADIUS Access-Accept requesting an unavailable service. This MUST 1915 cause the fast handoff to fail. However, if a new device is provided 1916 with RADIUS context that indicates an unknown attribute, then this 1917 attribute MAY be ignored. 1919 Although it may seem somewhat counter-intuitive, failure is indeed 1920 the "correct" result where a known but unsupported service is 1921 requested. Presumably a correctly configured backend authentication 1922 server would not request that a device carry out a service that it 1923 does not implement. This implies that if the new device were to 1924 complete a AAA conversation that it would be likely to receive 1925 different service instructions. In such a case, failure of the fast 1926 handoff is the desired result. This will cause the new device to go 1927 back to the AAA server in order to receive the appropriate service 1928 definition. 1930 In practice, this implies that fast handoff mechanisms which bypass 1931 AAA are most likely to be successful within a homogeneous device 1932 deployment within a single administrative domain. For example, it 1933 would not be advisable to carry out a fast handoff bypassing AAA 1934 between a authenticator providing confidentiality and another 1935 authenticator that does not support this service. The correct result 1936 of such a fast handoff would be a failure, since if the handoff were 1937 blindly carried out, then the user would be moved from a secure to an 1938 insecure channel without permission from the backend authentication 1939 server. Thus the definition of a "known but unsupported service" 1940 MUST encompass requests for unavailable security services. This 1941 includes vendor-specific attributes related to security, such as 1942 those described in [RFC2548]. 1944 6. Security Considerations 1946 6.1. Security Terminology 1948 "Cryptographic binding", "Cryptographic separation", "Key strength" 1949 and "Mutual authentication" are defined in [RFC3748] and are used 1950 with the same meaning here. 1952 6.2. Threat Model 1954 The EAP threat model is described in [RFC3748] Section 7.1. In order 1955 to address these threats, EAP relies on the security properties of 1956 EAP methods (known as "security claims", described in [RFC3784] 1957 Section 7.2.1). EAP method requirements for application such as 1958 Wireless LAN authentication are described in [WLANREQ]. 1960 The RADIUS threat model is described in [RFC3579] Section 4.1, and 1961 responses to these threats are described in [RFC3579] Sections 4.2 1962 and 4.3. Among other things, [RFC3579] Section 4.2 recommends the 1963 use of IPsec ESP with non-null transform to provide per-packet 1964 authentication and confidentiality, integrity and replay protection 1965 for RADIUS/EAP. 1967 Given the existing documentation of EAP and AAA threat models and 1968 responses, there is no need to duplicate that material here. 1969 However, there are many other system-level threats no covered in 1970 these document which have not been described or analyzed elsewhere. 1971 These include: 1973 [1] An attacker may try to modify or spoof Secure Association Protocol 1974 packets. 1976 [2] An attacker compromising an authenticator may provide incorrect 1977 information to the EAP peer and/or server via out-of-band 1978 mechanisms (such as via a AAA or lower layer protocol). This 1979 includes impersonating another authenticator, or providing 1980 inconsistent information to the peer and EAP server. 1982 [3] An attacker may attempt to perform downgrading attacks on the 1983 ciphersuite negotiation within the Secure Association Protocol in 1984 order to ensure that a weaker ciphersuite is used to protect data. 1986 Depending on the lower layer, these attacks may be carried out 1987 without requiring physical proximity. 1989 In order to address these threats, [Housley56] describes the 1990 mandatory system security properties: 1992 Algorithm independence 1993 Wherever cryptographic algorithms are chosen, the algorithms must 1994 be negotiable, in order to provide resilient against compromise of 1995 a particular algorithm. Algorithm independence must be 1996 demonstrated within all aspects of the system, including within 1997 EAP, AAA and the Secure Association Protocol. However, for 1998 interoperability, at least one suite of algorithms MUST be 1999 implemented. 2001 Strong, fresh session keys 2002 Session keys must be demonstrated to be strong and fresh in all 2003 circumstances, while at the same time retaining algorithm 2004 independence. 2006 Replay protection 2007 All protocol exchanges must be replay protected. This includes 2008 exchanges within EAP, AAA, and the Secure Association Protocol. 2010 Authentication 2011 All parties need to be authenticated. The confidentiality of the 2012 authenticator must be maintained. No plaintext passwords are 2013 allowed. 2015 Authorization 2016 EAP peer and authenticator authorization must be performed. 2018 Session keys 2019 Confidentiality of session keys must be maintained. 2021 Ciphersuite negotiation 2022 The selection of the "best" ciphersuite must be securely confirmed. 2024 Unique naming 2025 Session keys must be uniquely named. 2027 Domino effect 2028 Compromise of a single authenticator cannot compromise any other 2029 part of the system, including session keys and long-term secrets. 2031 Key binding 2032 The key must be bound to the appropriate context. 2034 6.3. Security Analysis 2036 Figure 6 illustrates the relationship between the peer, authenticator 2037 and backend authentication server. 2039 EAP peer 2040 /\ 2041 / \ 2042 Protocol: EAP / \ Protocol: Secure Association 2043 Auth: Mutual / \ Auth: Mutual 2044 Unique keys: / \ Unique keys: TSKs 2045 TEKs,EMSK / \ 2046 / \ 2047 EAP server +--------------+ Authenticator 2048 Protocol: AAA 2049 Auth: Mutual 2050 Unique key: AAA session key 2052 Figure 6: Relationship between peer, authenticator and auth. server 2054 The peer and EAP server communicate using EAP [RFC3748]. The 2055 security properties of this communication are largely determined by 2056 the chosen EAP method. Method security claims are described in 2057 [RFC3748] Section 7.2. These include the key strength, protected 2058 ciphersuite negotiation, mutual authentication, integrity protection, 2059 replay protection, confidentiality, key derivation, key strength, 2060 dictionary attack resistance, fast reconnect, cryptographic binding, 2061 session independence, fragmentation and channel binding claims. At a 2062 minimum, methods claiming to support key derivation must also support 2063 mutual authentication. As noted in [RFC3748] Section 7.10: 2065 EAP Methods deriving keys MUST provide for mutual authentication 2066 between the EAP peer and the EAP Server. 2068 Ciphersuite independence is also required: 2070 Keying material exported by EAP methods MUST be independent of the 2071 ciphersuite negotiated to protect data. 2073 In terms of key strength and freshness, [RFC3748] Section 10 says: 2075 EAP methods SHOULD ensure the freshness of the MSK and EMSK even 2076 in cases where one party may not have a high quality random number 2077 generator.... In order to preserve algorithm independence, EAP 2078 methods deriving keys SHOULD support (and document) the protected 2079 negotiation of the ciphersuite used to protect the EAP 2080 conversation between the peer and server... In order to enable 2081 deployments requiring strong keys, EAP methods supporting key 2082 derivation SHOULD be capable of generating an MSK and EMSK, each 2083 with an effective key strength of at least 128 bits. 2085 The authenticator and backend authentication server communicate using 2086 a AAA protocol such as RADIUS [RFC3579] or Diameter [I-D.ietf-aaa- 2087 eap]. As noted in [RFC3588] Section 13, Diameter must be protected 2088 by either IPsec ESP with non-null transform or TLS. As a result, 2089 Diameter requires per-packet integrity and confidentiality. Replay 2090 protection must be supported. For RADIUS, [RFC3579] Section 4.2 2091 recommends that RADIUS be protected by IPsec ESP with a non-null 2092 transform, and where IPsec is implemented replay protection must be 2093 supported. 2095 The peer and authenticator communicate using the Secure Association 2096 Protocol. 2098 As noted in the figure, each party in the exchange mutually 2099 authenticates with each of the other parties, and derives a unique 2100 key. All parties in the diagram have access to the AAA-Key. 2102 The EAP peer and backend authentication server mutually authenticate 2103 via the EAP method, and derive the TEKs and EMSK which are known only 2104 to them. The TEKs are used to protect some or all of the EAP 2105 conversation between the peer and authenticator, so as to guard 2106 against modification or insertion of EAP packets by an attacker. The 2107 degree of protection afforded by the TEKs is determined by the EAP 2108 method; some methods may protect the entire EAP packet, including the 2109 EAP header, while other methods may only protect the contents of the 2110 Type-Data field, defined in [RFC3748]. 2112 Since EAP is spoken only between the EAP peer and server, if a 2113 backend authentication server is present then the EAP conversation 2114 does not provide mutual authentication between the peer and 2115 authenticator, only between the EAP peer and EAP server (backend 2116 authentication server). As a result, mutual authentication between 2117 the peer and authenticator only occurs where a Secure Association 2118 protocol is used, such the unicast and group key derivation handshake 2119 supported in [IEEE80211i]. This means that absent use of a secure 2120 Association Protocol, from the point of view of the peer, EAP mutual 2121 authentication only proves that the authenticator is trusted by the 2122 backend authentication server; the identity of the authenticator is 2123 not confirmed. 2125 Utilizing the AAA protocol, the authenticator and backend 2126 authentication server mutually authenticate and derive session keys 2127 known only to them, used to provide per-packet integrity and replay 2128 protection, authentication and confidentiality. The AAA-Key is 2129 distributed by the backend authentication server to the authenticator 2130 over this channel, bound to attributes constraining its usage, as 2131 part of the AAA-Token. The binding of attributes to the AAA-Key 2132 within a protected package is important so the authenticator 2133 receiving the AAA-Token can determine that it has not been 2134 compromised, and that the keying material has not been replayed, or 2135 mis-directed in some way. 2137 The security properties of the EAP exchange are dependent on each leg 2138 of the triangle: the selected EAP method, AAA protocol and the Secure 2139 Association Protocol. 2141 Assuming that the AAA protocol provides protection against rogue 2142 authenticators forging their identity, then the AAA-Token can be 2143 assumed to be sent to the correct authenticator, and where it is 2144 wrapped appropriately, it can be assumed to be immune to compromise 2145 by a snooping attacker. 2147 Where an untrusted AAA intermediary is present, the AAA-Token must 2148 not be provided to the intermediary so as to avoid compromise of the 2149 AAA-Token. This can be avoided by use of re-direct as defined in 2151 [RFC3588]. 2153 When EAP is used for authentication on PPP or wired IEEE 802 2154 networks, it is typically assumed that the link is physically secure, 2155 so that an attacker cannot gain access to the link, or insert a rogue 2156 device. EAP methods defined in [RFC3748] reflect this usage model. 2157 These include EAP MD5, as well as One-Time Password (OTP) and Generic 2158 Token Card. These methods support one-way authentication (from EAP 2159 peer to authenticator) but not mutual authentication or key 2160 derivation. As a result, these methods do not bind the initial 2161 authentication and subsequent data traffic, even when the the 2162 ciphersuite used to protect data supports per-packet authentication 2163 and integrity protection. As a result, EAP methods not supporting 2164 mutual authentication are vulnerable to session hijacking as well as 2165 attacks by rogue devices. 2167 On wireless networks such as IEEE 802.11 [IEEE80211], these attacks 2168 become easy to mount, since any attacker within range can access the 2169 wireless medium, or act as an access point. As a result, new 2170 ciphersuites have been proposed for use with wireless LANs 2171 [IEEE80211i] which provide per-packet authentication, integrity and 2172 replay protection. In addition, mutual authentication and key 2173 derivation, provided by methods such as EAP-TLS [RFC2716] are 2174 required [IEEE80211i], so as to address the threat of rogue devices, 2175 and provide keying material to bind the initial authentication to 2176 subsequent data traffic. 2178 If the selected EAP method does not support mutual authentication, 2179 then the peer will be vulnerable to attack by rogue authenticators 2180 and backend authentication servers. If the EAP method does not derive 2181 keys, then TSKs will not be available for use with a negotiated 2182 ciphersuite, and there will be no binding between the initial EAP 2183 authentication and subsequent data traffic, leaving the session 2184 vulnerable to hijack. 2186 If the backend authentication server does not protect against 2187 authenticator masquerade, or provide the proper binding of the AAA- 2188 Key to the session within the AAA-Token, then one or more AAA-Keys 2189 may be sent to an unauthorized party, and an attacker may be able to 2190 gain access to the network. If the AAA-Token is provided to an 2191 untrusted AAA intermediary, then that intermediary may be able to 2192 modify the AAA-Key, or the attributes associated with it, as 2193 described in [RFC2607]. 2195 If the Secure Association Protocol does not provide mutual proof of 2196 possession of the AAA-Key material, then the peer will not have 2197 assurance that it is connected to the correct authenticator, only 2198 that the authenticator and backend authentication server share a 2199 trust relationship (since AAA protocols support mutual 2200 authentication). This distinction can become important when multiple 2201 authenticators receive AAA-Keys from the backend authentication 2202 server, such as where fast handoff is supported. If the TSK 2203 derivation does not provide for protected ciphersuite and 2204 capabilities negotiation, then downgrade attacks are possible. 2206 6.4. Man-in-the-middle Attacks 2208 As described in [I-D.puthenkulam-eap-binding], EAP method sequences 2209 and compound authentication mechanisms may be subject to man-in-the- 2210 middle attacks. When such attacks are successfully carried out, the 2211 attacker acts as an intermediary between a victim and a legitimate 2212 authenticator. This allows the attacker to authenticate successfully 2213 to the authenticator, as well as to obtain access to the network. 2215 In order to prevent these attacks, [I-D.puthenkulam-eap-binding] 2216 recommends derivation of a compound key by which the EAP peer and 2217 server can prove that they have participated in the entire EAP 2218 exchange. Since the compound key must not be known to an attacker 2219 posing as an authenticator, and yet must be derived from quantities 2220 that are exported by EAP methods, it may be desirable to derive the 2221 compound key from a portion of the EMSK. In order to provide proper 2222 key hygiene, it is recommended that the compound key used for man-in- 2223 the-middle protection be cryptographically separate from other keys 2224 derived from the EMSK, such as fast handoff keys, discussed in 2225 Section 2.3. 2227 6.5. Denial of Service Attacks 2229 The caching of security associations may result in vulnerability to 2230 denial of service attacks. Since an EAP peer may derive multiple EAP 2231 SAs with a given EAP server, and creation of a new EAP SA does not 2232 implicitly delete a previous EAP SA, EAP methods that result in 2233 creation of persistent state may be vulnerable to denial of service 2234 attacks by a rogue EAP peer. 2236 As a result, EAP methods creating persistent state may wish to limit 2237 the number of cached EAP SAs (Phase 1a) corresponding to an EAP peer. 2238 For example, an EAP server may choose to only retain a few EAP SAs 2239 for each peer. This prevents a rogue peer from denying access to 2240 other peers. 2242 Similarly, an authenticator may have multiple AAA-Key SAs 2243 corresponding to a given EAP peer; to conserve resources an 2244 authenticator may choose to limit the number of cached AAA-Key (Phase 2245 1 b) SAs for each peer. 2247 Depending on the media, creation of a new unicast Secure Association 2248 SA may or may not imply deletion of a previous unicast secure 2249 association SA. Where there is no implied deletion, the 2250 authenticator may choose to limit Phase 2 (unicast and multicast) 2251 Secure Association SAs for each peer. 2253 6.6. Impersonation 2255 Both the RADIUS and Diameter protocols are potentially vulnerable to 2256 impersonation by a rogue authenticator. 2258 While AAA protocols such as RADIUS [RFC2865] or Diameter [RFC3588] 2259 support mutual authentication between the authenticator (known as the 2260 AAA client) and the backend authentication server (known as the AAA 2261 server), the security mechanisms vary according to the AAA protocol. 2263 In RADIUS, the shared secret used for authentication is determined by 2264 the source address of the RADIUS packet. As noted in [RFC3579] 2265 Section 4.3.7, it is highly desirable that the source address be 2266 checked against one or more NAS identification attributes so as to 2267 detect and prevent impersonation attacks. 2269 When RADIUS requests are forwarded by a proxy, the NAS-IP-Address or 2270 NAS-IPv6-Address attributes may not correspond to the source address. 2271 Since the NAS-Identifier attribute need not contain an FQDN, it also 2272 may not correspond to the source address, even indirectly. [RFC2865] 2273 Section 3 states: 2275 A RADIUS server MUST use the source IP address of the RADIUS 2276 UDP packet to decide which shared secret to use, so that 2277 RADIUS requests can be proxied. 2279 This implies that it is possible for a rogue authenticator to forge 2280 NAS-IP-Address, NAS-IPv6-Address or NAS-Identifier attributes within 2281 a RADIUS Access-Request in order to impersonate another 2282 authenticator. Among other things, this can result in messages (and 2283 MSKs) being sent to the wrong authenticator. Since the rogue 2284 authenticator is authenticated by the RADIUS proxy or server purely 2285 based on the source address, other mechanisms are required to detect 2286 the forgery. In addition, it is possible for attributes such as the 2287 Called-Station-Id and Calling-Station-Id to be forged as well. 2289 As recommended in [RFC3579], this vulnerability can be mitigated by 2290 having RADIUS proxies check authenticator identification attributes 2291 against the source address. 2293 To allow verification of session parameters such as the Called- 2294 Station- Id and Calling-Station-Id, these can be sent by the EAP peer 2295 to the server, protected by the TEKs. The RADIUS server can then 2296 check the parameters sent by the EAP peer against those claimed by 2297 the authenticator. If a discrepancy is found, an error can be 2298 logged. 2300 While [RFC3588] requires use of the Route-Record AVP, this utilizes 2301 FQDNs, so that impersonation detection requires DNS A/AAAA and PTR 2302 RRs to be properly configured. As a result, it appears that Diameter 2303 is as vulnerable to this attack as RADIUS, if not more so. To address 2304 this vulnerability, it is necessary to allow the backend 2305 authentication server to communicate with the authenticator directly, 2306 such as via the redirect functionality supported in [RFC3588]. 2308 6.7. Channel binding 2310 It is possible for a compromised or poorly implemented EAP 2311 authenticator to communicate incorrect information to the EAP peer 2312 and/or server. This may enable an authenticator to impersonate 2313 another authenticator or communicate incorrect information via out- 2314 of-band mechanisms (such as via AAA or the lower layer protocol). 2316 Where EAP is used in pass-through mode, the EAP peer typically does 2317 not verify the identity of the pass-through authenticator, it only 2318 verifies that the pass-through authenticator is trusted by the EAP 2319 server. This creates a potential security vulnerability, described in 2320 [RFC3748] Section 7.15. 2322 [RFC3579] Section 4.3.7 describes how an EAP pass-through 2323 authenticator acting as a AAA client can be detected if it attempts 2324 to impersonate another authenticator (such by sending incorrect NAS- 2325 Identifier [RFC2865], NAS-IP-Address [RFC2865] or NAS-IPv6-Address 2326 [RFC3162] attributes via the AAA protocol). However, it is possible 2327 for a pass-through authenticator acting as a AAA client to provide 2328 correct information to the AAA server while communicating misleading 2329 information to the EAP peer via a lower layer protocol. 2331 For example, it is possible for a compromised authenticator to 2332 utilize another authenticator's Called-Station-Id or NAS-Identifier 2333 in communicating with the EAP peer via a lower layer protocol, or for 2334 a pass-through authenticator acting as a AAA client to provide an 2335 incorrect peer Calling-Station-Id [RFC2865][RFC3580] to the AAA 2336 server via the AAA protocol. 2338 As noted in [RFC3748] Section 7.15, this vulnerability can be 2339 addressed by use of EAP methods that support a protected exchange of 2340 channel properties such as endpoint identifiers, including (but not 2341 limited to): Called-Station-Id [RFC2865][RFC3580], Calling-Station-Id 2342 [RFC2865][RFC3580], NAS-Identifier [RFC2865], NAS-IP-Address 2344 [RFC2865], and NAS-IPv6-Address [RFC3162]. 2346 Using such a protected exchange, it is possible to match the channel 2347 properties provided by the authenticator via out-of-band mechanisms 2348 against those exchanged within the EAP method. For example, see 2349 [ServiceIdent]. 2351 7. Security Requirements 2353 This section summarizes the security requirements that must be met by 2354 EAP methods, AAA protocols, Secure Association Protocols and 2355 Ciphersuites in order to address the security threats described in 2356 this document. These requirements MUST be met by specifications 2357 requesting publication as an RFC. Each requirement provides a 2358 pointer to the sections of this document describing the threat that 2359 it mitigates. 2361 7.1. EAP Method Requirements 2363 It is possible for the peer and EAP server to mutually authenticate 2364 and derive keys. In order to provide keying material for use in a 2365 subsequently negotiated ciphersuite, an EAP method supporting key 2366 derivation MUST export a Master Session Key (MSK) of at least 64 2367 octets, and an Extended Master Session Key (EMSK) of at least 64 2368 octets. EAP Methods deriving keys MUST provide for mutual 2369 authentication between the EAP peer and the EAP Server. 2371 The MSK and EMSK MUST NOT be used directly to protect data; however, 2372 they are of sufficient size to enable derivation of a AAA-Key 2373 subsequently used to derive Transient Session Keys (TSKs) for use 2374 with the selected ciphersuite. Each ciphersuite is responsible for 2375 specifying how to derive the TSKs from the AAA-Key. 2377 The AAA-Key is derived from the keying material exported by the EAP 2378 method (MSK and EMSK). This derivation occurs on the AAA server. In 2379 many existing protocols that use EAP, the AAA-Key and MSK are 2380 equivalent, but more complicated mechanisms are possible (see Section 2381 2.3 for details). 2383 EAP methods SHOULD ensure the freshness of the MSK and EMSK even in 2384 cases where one party may not have a high quality random number 2385 generator. A RECOMMENDED method is for each party to provide a nonce 2386 of at least 128 bits, used in the derivation of the MSK and EMSK. 2388 EAP methods export the MSK and EMSK and not Transient Session Keys so 2389 as to allow EAP methods to be ciphersuite and media independent. 2390 Keying material exported by EAP methods MUST be independent of the 2391 ciphersuite negotiated to protect data. 2393 Depending on the lower layer, EAP methods may run before or after 2394 ciphersuite negotiation, so that the selected ciphersuite may not be 2395 known to the EAP method. By providing keying material usable with 2396 any ciphersuite, EAP methods can used with a wide range of 2397 ciphersuites and media. 2399 It is RECOMMENDED that methods providing integrity protection of EAP 2400 packets include coverage of all the EAP header fields, including the 2401 Code, Identifier, Length, Type and Type-Data fields. 2403 In order to preserve algorithm independence, EAP methods deriving 2404 keys SHOULD support (and document) the protected negotiation of the 2405 ciphersuite used to protect the EAP conversation between the peer and 2406 server. This is distinct from the ciphersuite negotiated between the 2407 peer and authenticator, used to protect data. 2409 The strength of Transient Session Keys (TSKs) used to protect data is 2410 ultimately dependent on the strength of keys generated by the EAP 2411 method. If an EAP method cannot produce keying material of 2412 sufficient strength, then the TSKs may be subject to brute force 2413 attack. In order to enable deployments requiring strong keys, EAP 2414 methods supporting key derivation SHOULD be capable of generating an 2415 MSK and EMSK, each with an effective key strength of at least 128 2416 bits. 2418 Methods supporting key derivation MUST demonstrate cryptographic 2419 separation between the MSK and EMSK branches of the EAP key 2420 hierarchy. Without violating a fundamental cryptographic assumption 2421 (such as the non-invertibility of a one-way function) an attacker 2422 recovering the MSK or EMSK MUST NOT be able to recover the other 2423 quantity with a level of effort less than brute force. 2425 Non-overlapping substrings of the MSK MUST be cryptographically 2426 separate from each other. That is, knowledge of one substring MUST 2427 NOT help in recovering some other non-overlapping substring without 2428 breaking some hard cryptographic assumption. This is required 2429 because some existing ciphersuites form TSKs by simply splitting the 2430 AAA-Key to pieces of appropriate length. Likewise, non-overlapping 2431 substrings of the EMSK MUST be cryptographically separate from each 2432 other, and from substrings of the MSK. 2434 The EMSK MUST remain on the EAP peer and EAP server where it is 2435 derived; it MUST NOT be transported to, or shared with, additional 2436 parties, or used for purposes other than AMSK derivation (see Section 2437 2.4). 2439 Since EAP does not provide for explicit key lifetime negotiation, EAP 2440 peers, authenticators and authentication servers MUST be prepared for 2441 situations in which one of the parties discards key state which 2442 remains valid on another party. 2444 The development and validation of key derivation algorithms is 2445 difficult, and as a result EAP methods SHOULD reuse well established 2446 and analyzed mechanisms for MSK and EMSK key derivation (such as 2447 those specified in IKE [RFC2409] or TLS [RFC2246]), rather than 2448 inventing new ones. 2450 7.1.1. Requirements for EAP methods 2452 In order for an EAP method to meet the guidelines for EMSK usage it 2453 must meet the following requirements: 2455 o It MUST specify how to derive the EMSK 2457 o The key material used for the EMSK MUST be 2458 computationally independent of the MSK and TEKs. 2460 o The EMSK MUST NOT be used for any other purpose than the key 2461 derivation described in this document. 2463 o The EMSK MUST be secret and not known to someone observing 2464 the authentication mechanism protocol exchange. 2466 o The EMSK MUST NOT be exported from the EAP server. 2467 Only keys (AMSKs) derived according to this specification 2468 may be exported from the EAP server. 2470 o The EMSK MUST be unique for each session. 2472 o The EAP mechanism SHOULD a unique identifier suitable for naming the EMSK. 2474 Implementations of EAP frameworks on the EAP-Peer and EAP-Server 2475 SHOULD provide an interface to obtain AMSKs. The implementation MAY 2476 restrict which callers can obtain which keys. 2478 7.1.2. Requirements for EAP applications 2480 In order for an application to meet the guidelines for EMSK usage it 2481 must meet the following requirements: 2483 o New applications following this specification SHOULD NOT use the 2484 MSK. If more than one application uses the MSK, then the 2485 cryptographic separation is not achieved. Implementations SHOULD 2486 prevent such combinations. 2488 o A peer MUST NOT use the EMSK in any other way except to 2489 derive Application Master Session Keys (AMSKs) using the 2490 key derivation specified in Section 2.4. It MUST NOT 2491 use the EMSK directly for cryptographic protection of data, 2492 and SHOULD provide only the AMSKs to applications. 2494 o Applications MUST define distinct key labels, application 2495 specific data, and the length of derived key material used in the key 2496 derivation described in Section 2.4. 2498 o Applications MUST define how they use their AMSK to derive TSKs 2499 for their use. 2501 7.2. AAA Protocol Requirements 2503 AAA protocols suitable for use in transporting EAP MUST provide the 2504 following facilities: 2506 Security services 2507 AAA protocols used for transport of EAP keying material MUST 2508 implement and SHOULD use per-packet integrity and authentication, 2509 replay protection and confidentiality. These requirements are met 2510 by Diameter EAP [I-D.ietf-aaa-eap], as well as RADIUS over IPsec 2511 [RFC3579]. 2513 Session Keys 2514 AAA protocols used for transport of EAP keying material MUST 2515 implement and SHOULD use dynamic key management in order to derive 2516 fresh session keys, as in Diameter EAP [I-D.ietf-aaa-eap] and 2517 RADIUS over IPsec [RFC3579], rather than using a static key, as 2518 originally defined in RADIUS [RFC2865]. 2520 Mutual authentication 2521 AAA protocols used for transport of EAP keying material MUST 2522 provide for mutual authentication between the authenticator and 2523 backend authentication server. These requirements are met by 2524 Diameter EAP [I-D.ietf-aaa-eap] as well as by RADIUS EAP [RFC3579]. 2526 Authorization 2527 AAA protocols used for transport of EAP keying material SHOULD 2528 provide protection against rogue authenticators masquerading as 2529 other authenticators. This can be accomplished, for example, by 2530 requiring that AAA agents check the source address of packets 2531 against the origin attributes (Origin-Host AVP in Diameter, NAS-IP- 2532 Address, NAS-IPv6-Address, NAS-Identifier in RADIUS). For details, 2533 see [RFC3579] Section 4.3.7. 2535 Key transport 2536 Since EAP methods do not export Transient Session Keys (TSKs) in 2537 order to maintain media and ciphersuite independence, the AAA 2538 server MUST NOT transport TSKs from the backend authentication 2539 server to authenticator. 2541 Key transport specification 2542 In order to enable backend authentication servers to provide keying 2543 material to the authenticator in a well defined format, AAA 2544 protocols suitable for use with EAP MUST define the format and 2545 wrapping of the AAA-Token. 2547 EMSK transport 2548 Since the EMSK is a secret known only to the backend authentication 2549 server and peer, the AAA-Token MUST NOT transport the EMSK from the 2550 backend authentication server to the authenticator. 2552 AAA-Token protection 2553 To ensure against compromise, the AAA-Token MUST be integrity 2554 protected, authenticated, replay protected and encrypted in 2555 transit, using well-established cryptographic algorithms. 2557 Session Keys 2558 The AAA-Token SHOULD be protected with session keys as in Diameter 2559 [RFC3588] or RADIUS over IPsec [RFC3579] rather than static keys, 2560 as in [RFC2548]. 2562 Key naming 2563 In order to ensure against confusion between the appropriate keying 2564 material to be used in a given Secure Association Protocol 2565 exchange, the AAA-Token SHOULD include explicit key names and 2566 context appropriate for informing the authenticator how the keying 2567 material is to be used. 2569 Key Compromise 2570 Where untrusted intermediaries are present, the AAA-Token SHOULD 2571 NOT be provided to the intermediaries. In Diameter, handling of 2572 keys by intermediaries can be avoided using Redirect functionality 2573 [RFC3588]. 2575 7.3. Secure Association Protocol Requirements 2577 The Secure Association Protocol supports the following: 2579 Entity Naming 2580 The peer and authenticator SHOULD identify themselves in a manner 2581 that is independent of their attached ports. 2583 Mutual proof of possession 2584 The peer and authenticator MUST each demonstrate possession of the 2585 keying material transported between the backend authentication 2586 server and authenticator (AAA-Key). 2588 Key Naming 2589 The Secure Association Protocol MUST explicitly name the keys used 2590 in the proof of possession exchange, so as to prevent confusion 2591 when more than one set of keying material could potentially be used 2592 as the basis for the exchange. 2594 Creation and Deletion 2595 In order to support the correct processing of phase 2 security 2596 associations, the Secure Association (phase 2) protocol MUST 2597 support the naming of phase 2 security associations and associated 2598 transient session keys, so that the correct set of transient 2599 session keys can be identified for processing a given packet. The 2600 phase 2 Secure Association Protocol also MUST support transient 2601 session key activation and SHOULD support deletion, so that 2602 establishment and re-establishment of transient session keys can be 2603 synchronized between the parties. 2605 Integrity and Replay Protection 2606 The Secure Association Protocol MUST support integrity and replay 2607 protection of all messages. 2609 Direct operation 2610 Since the phase 2 Secure Association Protocol is concerned with the 2611 establishment of security associations between the EAP peer and 2612 authenticator, including the derivation of transient session keys, 2613 only those parties have "a need to know" the transient session 2614 keys. The Secure Association Protocol MUST operate directly between 2615 the peer and authenticator, and MUST NOT be passed-through to the 2616 backend authentication server, or include additional parties. 2618 Derivation of transient session keys 2619 The Secure Association Protocol negotiation MUST support derivation 2620 of unicast and multicast transient session keys suitable for use 2621 with the negotiated ciphersuite. 2623 TSK freshness 2624 The Secure Association (phase 2) Protocol MUST support the 2625 derivation of fresh unicast and multicast transient session keys, 2626 even when the keying material provided by the backend 2627 authentication server is not fresh. This is typically supported by 2628 including an exchange of nonces within the Secure Association 2629 Protocol. 2631 Bi-directional operation 2632 While some ciphersuites only require a single set of transient 2633 session keys to protect traffic in both directions, other 2634 ciphersuites require a unique set of transient session keys in each 2635 direction. The phase 2 Secure Association Protocol SHOULD provide 2636 for the derivation of unicast and multicast keys in each direction, 2637 so as not to require two separate phase 2 exchanges in order to 2638 create a bi-directional phase 2 security association. 2640 Secure capabilities negotiation 2641 The Secure Association Protocol MUST support secure capabilities 2642 negotiation. This includes security parameters such as the 2643 security association identifier (SAID) and ciphersuites, as well as 2644 negotiation of the lifetime of the TSKs, AAA-Key and exported EAP 2645 keys. Secure capabilities negotiation also includes confirmation 2646 of the capabilities discovered during the discovery phase (phase 2647 0), so as to ensure that the announced capabilities have not been 2648 forged. 2650 Key Scoping 2651 The Secure Association Protocol MUST ensure the synchronization of 2652 key scope between the peer and authenticator. This includes 2653 negotiation of restrictions on key usage. 2655 7.4. Ciphersuite Requirements 2657 Ciphersuites suitable for keying by EAP methods MUST provide the 2658 following facilities: 2660 TSK derivation 2661 In order to allow a ciphersuite to be usable within the EAP keying 2662 framework, a specification MUST be provided describing how 2663 transient session keys suitable for use with the ciphersuite are 2664 derived from the AAA-Key. 2666 EAP method independence 2667 Algorithms for deriving transient session keys from the AAA-Key 2668 MUST NOT depend on the EAP method. However, algorithms for 2669 deriving TEKs MAY be specific to the EAP method. 2671 Cryptographic separation 2672 The TSKs derived from the AAA-Key MUST be cryptographically 2673 separate from each other. Similarly, TEKs MUST be 2674 cryptographically separate from each other. In addition, the TSKs 2675 MUST be cryptographically separate from the TEKs. 2677 8. IANA Considerations 2679 This section provides guidance to the Internet Assigned Numbers 2680 Authority (IANA) regarding registration of values related to EAP key 2681 management, in accordance with BCP 26, [RFC2434]. 2683 The following terms are used here with the meanings defined in BCP 2684 26: "name space", "assigned value", "registration". 2686 The following policies are used here with the meanings defined in BCP 2687 26: "Private Use", "First Come First Served", "Expert Review", 2688 "Specification Required", "IETF Consensus", "Standards Action". 2690 For registration requests where a Designated Expert should be 2691 consulted, the responsible IESG area director should appoint the 2692 Designated Expert. The intention is that any allocation will be 2693 accompanied by a published RFC. But in order to allow for the 2694 allocation of values prior to the RFC being approved for publication, 2695 the Designated Expert can approve allocations once it seems clear 2696 that an RFC will be published. The Designated expert will post a 2697 request to the EAP WG mailing list (or a successor designated by the 2698 Area Director) for comment and review, including an Internet-Draft. 2699 Before a period of 30 days has passed, the Designated Expert will 2700 either approve or deny the registration request and publish a notice 2701 of the decision to the EAP WG mailing list or its successor, as well 2702 as informing IANA. A denial notice must be justified by an 2703 explanation and, in the cases where it is possible, concrete 2704 suggestions on how the request can be modified so as to become 2705 acceptable. 2707 This document introduces a new name space for "key labels". Key 2708 labels are ASCII strings and are assigned via IETF Consensus. It is 2709 expected that key label specifications will include the following 2710 information: 2712 o A description of the application 2713 o The key label to be used 2714 o How TSKs will be derived from the AMSK and how they will be used 2715 o If application specific data is used, what it is and how it is 2716 maintained 2717 o Where the AMSKs or TSKs will be used and how they are 2718 communicated if necessary. 2720 9. References 2722 9.1. Normative References 2724 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2725 Requirement Levels", BCP 14, RFC 2119, March 1997. 2727 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 2728 Considerations Section in RFCs", BCP 26, RFC 2434, October 2729 1998. 2731 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 2732 Lefkowetz, "Extensible Authentication Protocol (EAP)", RFC 2733 3748, June 2004. 2735 9.2. Informative References 2737 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 2738 September 1981. 2740 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 2741 1661, July 1994. 2743 [RFC1968] Meyer, G. and K. Fox, "The PPP Encryption Control Protocol 2744 (ECP)", RFC 1968, June 1996. 2746 [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing 2747 for Message Authentication", RFC 2104, February 1997. 2749 [RFC2246] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. 2750 and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, 2751 January 1999. 2753 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 2754 Internet Protocol", RFC 2401, November 1998. 2756 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 2757 RFC 2409, November 1998. 2759 [RFC2419] Sklower, K. and G. Meyer, "The PPP DES Encryption Protocol, 2760 Version 2 (DESE-bis)", RFC 2419, September 1998. 2762 [RFC2420] Kummert, H., "The PPP Triple-DES Encryption Protocol (3DESE)", 2763 RFC 2420, September 1998. 2765 [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D. and 2766 R. Wheeler, "A Method for Transmitting PPP Over Ethernet 2767 (PPPoE)", RFC 2516, February 1999. 2769 [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2770 2548, March 1999. 2772 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 2773 Implementation in Roaming", RFC 2607, June 1999. 2775 [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol", 2776 RFC 2716, October 1999. 2778 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 2779 Authentication Dial In User Service (RADIUS)", RFC 2865, June 2780 2000. 2782 [RFC3078] Pall, G. and G. Zorn, "Microsoft Point-To-Point Encryption 2783 (MPPE) Protocol", RFC 3078, March 2001. 2785 [RFC3079] Zorn, G., "Deriving Keys for use with Microsoft Point-to-Point 2786 Encryption (MPPE)", RFC 3079, March 2001. 2788 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial 2789 In User Service) Support For Extensible Authentication 2790 Protocol (EAP)", RFC 3579, September 2003. 2792 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese, 2793 "IEEE 802.1X Remote Authentication Dial In User Service 2794 (RADIUS) Usage Guidelines", RFC 3580, September 2003. 2796 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. 2797 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 2799 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public 2800 Keys Used For Exchanging Symmetric Keys", RFC 3766, April 2801 2004. 2803 [FIPSDES] National Institute of Standards and Technology, "Data 2804 Encryption Standard", FIPS PUB 46, January 1977. 2806 [DESMODES] 2807 National Institute of Standards and Technology, "DES Modes of 2808 Operation", FIPS PUB 81, December 1980, . 2811 [IEEE802] Institute of Electrical and Electronics Engineers, "IEEE 2812 Standards for Local and Metropolitan Area Networks: Overview 2813 and Architecture", ANSI/IEEE Standard 802, 1990. 2815 [IEEE80211] 2816 Institute of Electrical and Electronics Engineers, 2817 "Information technology - Telecommunications and information 2818 exchange between systems - Local and metropolitan area 2819 networks - Specific Requirements Part 11: Wireless LAN Medium 2820 Access Control (MAC) and Physical Layer (PHY) Specifications", 2821 IEEE IEEE Standard 802.11-2003, 2003. 2823 [IEEE8021X] 2824 Institute of Electrical and Electronics Engineers, "Local and 2825 Metropolitan Area Networks: Port-Based Network Access 2826 Control", IEEE Standard 802.1X-2004, December 2004. 2828 [IEEE8021Q] 2829 Institute of Electrical and Electronics Engineers, "IEEE 2830 Standards for Local and Metropolitan Area Networks: Draft 2831 Standard for Virtual Bridged Local Area Networks", IEEE 2832 Standard 802.1Q/D8, January 1998. 2834 [IEEE80211F] 2835 Institute of Electrical and Electronics Engineers, 2836 "Recommended Practice for Multi-Vendor Access Point 2837 Interoperability via an Inter-Access Point Protocol Across 2838 Distribution Systems Supporting IEEE 802.11 Operation", IEEE 2839 802.11F, July 2003. 2841 [IEEE80211i] 2842 Institute of Electrical and Electronics Engineers, "Supplement 2843 to STANDARD FOR Telecommunications and Information Exchange 2844 between Systems - LAN/MAN Specific Requirements - Part 11: 2845 Wireless Medium Access Control (MAC) and physical layer (PHY) 2846 specifications: Specification for Enhanced Security", IEEE 2847 802.11i, December 2004. 2849 [IEEE-02-758] 2850 Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, 2851 "Proactive Caching Strategies for IAPP Latency Improvement 2852 during 802.11 Handoff", IEEE 802.11 Working Group, 2853 IEEE-02-758r1-F Draft 802.11I/D5.0, November 2002. 2855 [IEEE-03-084] 2856 Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, 2857 "Proactive Key Distribution to support fast and secure 2858 roaming", IEEE 802.11 Working Group, IEEE-03-084r1-I, 2859 http://www.ieee802.org/11/Documents/DocumentHolder/ 3-084.zip, 2860 January 2003. 2862 [IEEE-03-155] 2863 Aboba, B., "Fast Handoff Issues", IEEE 802.11 Working Group, 2864 IEEE-03-155r0-I, http://www.ieee802.org/11/ 2865 Documents/DocumentHolder/3-155.zip, March 2003. 2867 [I-D.ietf-roamops-cert] 2868 Aboba, B., "Certificate-Based Roaming", draft-ietf-roamops- 2869 cert-02 (work in progress), April 1999. 2871 [I-D.ietf-aaa-eap] 2872 Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible 2873 Authentication Protocol (EAP) Application", draft-ietf-aaa- 2874 eap-10 (work in progress), November 2004. 2876 [I-D.irtf-aaaarch-handoff] 2877 Arbaugh, W. and B. Aboba, "Handoff Extension to RADIUS", 2878 draft-irtf-aaaarch-handoff-04 (work in progress), October 2879 2003. 2881 [I-D.puthenkulam-eap-binding] 2882 Puthenkulam, J., "The Compound Authentication Binding 2883 Problem", draft-puthenkulam-eap-binding-04 (work in progress), 2884 October 2003. 2886 [I-D.aboba-802-context] 2887 Aboba, B. and T. Moore, "A Model for Context Transfer in IEEE 2888 802", draft-aboba-802-context-03 (work in progress), October 2889 2003. 2891 [I-D.arkko-pppext-eap-aka] 2892 Arkko, J. and H. Haverinen, "EAP AKA Authentication", draft- 2893 arkko-pppext-eap-aka-15.txt (work in progress), December 2004. 2895 [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", draft- 2896 ietf-ipsec-ikev2-17 (work in progress), September 2004. 2898 [8021XHandoff] 2899 Pack, S. and Y. Choi, "Pre-Authenticated Fast Handoff in a 2900 Public Wireless LAN Based on IEEE 802.1X Model", School of 2901 Computer Science and Engineering, Seoul National University, 2902 Seoul, Korea, 2002. 2904 [MD5Attack] 2905 Dobbertin, H., "The Status of MD5 After a Recent Attack", 2906 CryptoBytes, Vol.2 No.2, 1996. 2908 [WLANREQ] Stanley, D., Walker, J. and B. Aboba, "EAP Method Requirements 2909 for Wireless LANs", draft-walker-ieee802-req-04.txt (work in 2910 progress), August 2004. 2912 [Housley56] 2913 Housley, R., "Key Management in AAA", Presentation to the AAA 2914 WG at IETF 56, 2915 http://www.ietf.org/proceedings/03mar/slides/aaa-5/index.html, 2916 March 2003. 2918 Acknowledgments 2920 Thanks to Arun Ayyagari, Ashwin Palekar, and Tim Moore of Microsoft, 2921 Dorothy Stanley of Agere, Bob Moskowitz of TruSecure, Jesse Walker of 2922 Intel, Joe Salowey of Cisco and Russ Housley of Vigil Security for 2923 useful feedback. 2925 Author Addresses 2927 Bernard Aboba 2928 Microsoft Corporation 2929 One Microsoft Way 2930 Redmond, WA 98052 2932 EMail: bernarda@microsoft.com 2933 Phone: +1 425 706 6605 2934 Fax: +1 425 936 7329 2936 Dan Simon 2937 Microsoft Research 2938 Microsoft Corporation 2939 One Microsoft Way 2940 Redmond, WA 98052 2942 EMail: dansimon@microsoft.com 2943 Phone: +1 425 706 6711 2944 Fax: +1 425 936 7329 2946 Jari Arkko 2947 Ericsson 2948 Jorvas 02420 2949 Finland 2951 Phone: 2952 EMail: jari.arkko@ericsson.com 2954 Pasi Eronen 2955 Nokia Research Center 2956 P.O. Box 407 2957 FIN-00045 Nokia Group 2958 Finland 2960 EMail: pasi.eronen@nokia.com 2962 Henrik Levkowetz (editor) 2963 ipUnplugged AB 2964 Arenavagen 27 2965 Stockholm S-121 28 2966 SWEDEN 2968 Phone: +46 708 32 16 08 2969 EMail: henrik@levkowetz.com 2971 Appendix A - Ciphersuite Keying Requirements 2973 To date, PPP and IEEE 802.11 ciphersuites are suitable for keying by 2974 EAP. This Appendix describes the keying requirements of common PPP 2975 and 802.11 ciphersuites. 2977 PPP ciphersuites include DESEbis [RFC2419], 3DES [RFC2420], and MPPE 2978 [RFC3078]. The DES algorithm is described in [FIPSDES], and DES 2979 modes (such as CBC, used in [RFC2419] and DES-EDE3-CBC, used in 2980 [RFC2420]) are described in [DESMODES]. For PPP DESEbis, a single 2981 56-bit encryption key is required, used in both directions. For PPP 2982 3DES, a 168-bit encryption key is needed, used in both directions. As 2983 described in [RFC2419] for DESEbis and [RFC2420] for 3DES, the IV, 2984 which is different in each direction, is "deduced from an explicit 2985 64-bit nonce, which is exchanged in the clear during the [ECP] 2986 negotiation phase." There is therefore no need for the IV to be 2987 provided by EAP. 2989 For MPPE, 40-bit, 56-bit or 128-bit encryption keys are required in 2990 each direction, as described in [RFC3078]. No initialization vector 2991 is required. 2993 While these PPP ciphersuites provide encryption, they do not provide 2994 per-packet authentication or integrity protection, so an 2995 authentication key is not required in either direction. 2997 Within [IEEE80211], Transient Session Keys (TSKs) are required both 2998 for unicast traffic as well as for multicast traffic, and therefore 2999 separate key hierarchies are required for unicast keys and multicast 3000 keys. IEEE 802.11 ciphersuites include WEP-40, described in 3001 [IEEE80211], which requires a 40-bit encryption key, the same in 3002 either direction; and WEP-128, which requires a 104-bit encryption 3003 key, the same in either direction. These ciphersuites also do not 3004 support per-packet authentication and integrity protection. In 3005 addition to these unicast keys, authentication and encryption keys 3006 are required to wrap the multicast encryption key. 3008 Recently, new ciphersuites have been proposed for use with IEEE 3009 802.11 that provide per-packet authentication and integrity 3010 protection as well as encryption [IEEE80211i]. These include TKIP, 3011 which requires a single 128-bit encryption key and two 64-bit 3012 authentication keys (one for each direction); and AES CCMP, which 3013 requires a single 128-bit key (used in both directions) in order to 3014 authenticate and encrypt data. 3016 As with WEP, authentication and encryption keys are also required to 3017 wrap the multicast encryption (and possibly, authentication) keys. 3019 Appendix B - Transient EAP Key (TEK) Hierarchy 3021 Figure B-1 illustrates the TEK key hierarchy for EAP-TLS [RFC2716], 3022 which is based on the TLS key hierarchy described in [RFC2246]. The 3023 TLS-negotiated ciphersuite is used to set up a protected channel for 3024 use in protecting the EAP conversation, keyed by the derived TEKs. 3025 The TEK derivation proceeds as follows: 3027 master_secret = TLS-PRF-48(pre_master_secret, "master secret", 3028 client.random || server.random) 3029 TEK = TLS-PRF-X(master_secret, "key expansion", 3030 server.random || client.random) 3031 Where: 3032 TLS-PRF-X = TLS pseudo-random function defined in [RFC2246], 3033 computed to X octets. 3035 | | | 3036 | | pre_master_secret | 3037 server| | | client 3038 Random| V | Random 3039 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3040 | | | | 3041 | | | | 3042 +---->| master_secret |<------+ 3043 | | (TMS) | | 3044 | | | | 3045 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3046 | | | 3047 | | | 3048 | | | 3049 V V V 3050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3051 | | 3052 | | 3053 | Key Block | 3054 | (TEKs) | 3055 | | 3056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3057 | | | | | | 3058 | client | server | client | server | client | server 3059 | MAC | MAC | write | write | IV | IV 3060 | | | | | | 3061 V V V V V V 3063 Figure B-1 - TLS [RFC2246] Key Hierarchy 3065 Appendix C - EAP-TLS Key Hierarchy 3067 In EAP-TLS [RFC2716], the MSK is divided into two halves, 3068 corresponding to the "Peer to Authenticator Encryption Key" (Enc- 3069 RECV-Key, 32 octets, also known as the PMK) and "Authenticator to 3070 Peer Encryption Key" (Enc-SEND-Key, 32 octets). In [RFC2548], the 3071 Enc-RECV-Key (the PMK) is transported in the MS-MPPE-Recv-Key 3072 attribute, and the Enc-SEND-Key is transported in the MS-MPPE-Send- 3073 Key attribute. 3075 The EMSK is also divided into two halves, corresponding to the "Peer 3076 to Authenticator Authentication Key" (Auth-RECV-Key, 32 octets) and 3077 "Authenticator to Peer Authentication Key" (Auth-SEND-Key, 32 3078 octets). The IV is a 64 octet quantity that is a known value; octets 3079 0-31 are known as the "Peer to Authenticator IV" or RECV-IV, and 3080 Octets 32-63 are known as the "Authenticator to Peer IV", or SEND-IV. 3082 In EAP-TLS, the MSK, EMSK and IV are derived from the TLS master 3083 secret via a one-way function. This ensures that the TLS master 3084 secret cannot be derived from the MSK, EMSK or IV unless the one-way 3085 function (TLS PRF) is broken. Since the MSK is derived from the the 3086 TLS master secret, if the TLS master secret is compromised then the 3087 MSK is also compromised. 3089 As described in [RFC2716], the formula for the derivation of the MSK, 3090 EMSK and IV is as follows: 3092 MSK = TLS-PRF-64(TMS, "client EAP encryption", 3093 client.random || server.random) 3094 EMSK = second 64 octets of: 3095 TLS-PRF-128(TMS, "client EAP encryption", 3096 client.random || server.random) 3097 IV = TLS-PRF-64("", "client EAP encryption", 3098 client.random || server.random) 3100 AAA-Key(0,31) = Peer to Authenticator Encryption Key (Enc-RECV-Key) 3101 (MS-MPPE-Recv-Key in [RFC2548]). Also known as the 3102 PMK. 3103 AAA-Key(32,63)= Authenticator to Peer Encryption Key (Enc-SEND-Key) 3104 (MS-MPPE-Send-Key in [RFC2548]) 3105 EMSK(0,31) = Peer to Authenticator Authentication Key (Auth-RECV-Key) 3106 EMSK(32,63) = Authenticator to Peer Authentication Key (Auth-Send-Key) 3107 IV(0,31) = Peer to Authenticator Initialization Vector (RECV-IV) 3108 IV(32,63) = Authenticator to Peer Initialization vector (SEND-IV) 3110 Where: 3112 AAA-Key(W,Z) = Octets W through Z includes of the AAA-Key. 3113 IV(W,Z) = Octets W through Z inclusive of the IV. 3114 MSK(W,Z) = Octets W through Z inclusive of the MSK. 3115 EMSK(W,Z) = Octets W through Z inclusive of the EMSK. 3116 TMS = TLS master_secret 3117 TLS-PRF-X = TLS PRF function defined in [RFC2246] computed to X octets 3118 client.random = Nonce generated by the TLS client. 3119 server.random = Nonce generated by the TLS server. 3121 Figure C-1 describes the process by which the MSK,EMSK,IV and 3122 ultimately the TSKs, are derived from the TLS Master Secret. 3124 ---+ 3125 | ^ 3126 | TLS Master Secret (TMS) | 3127 | | 3128 V | 3129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3130 | | EAP | 3131 | Master Session Key (MSK) | Method | 3132 | Derivation | | 3133 | | V 3134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ EAP ---+ 3135 | | | API ^ 3136 | MSK | EMSK | IV | 3137 | | | | 3138 V V V v 3139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 3140 | | | 3141 | | | 3142 | backend authentication server | | 3143 | | | 3144 | | V 3145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 3146 | | ^ 3147 | AAA-Key(0,31) | AAA-Key(32,63) | 3148 | (PMK) | Transported | 3149 | | via AAA | 3150 | | | 3151 V V V 3152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 3153 | | ^ 3154 | Ciphersuite-Specific Transient Session | Auth.| 3155 | Key Derivation | | 3156 | | V 3157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 3159 Figure C-1 - EAP TLS [RFC2716] Key hierarchy 3161 Appendix D - Example Transient Session Key (TSK) Derivation 3163 Within IEEE 802.11 RSN, the Pairwise Transient Key (PTK), a transient 3164 session key used to protect unicast traffic, is derived from the PMK 3165 (octets 0-31 of the MSK), known in [RFC2716] as the Peer to 3166 Authenticator Encryption Key. In [IEEE80211i], the PTK is derived 3167 from the PMK via the following formula: 3169 PTK = EAPOL-PRF-X(PMK, "Pairwise key expansion", Min(AA,SA) || 3170 Max(AA, SA) || Min(ANonce,SNonce) || Max(ANonce,SNonce)) 3172 Where: 3174 PMK = AAA-Key(0,31) 3175 SA = Station MAC address (Calling-Station-Id) 3176 AA = Access Point MAC address (Called-Station-Id) 3177 ANonce = Access Point Nonce 3178 SNonce = Station Nonce 3179 EAPOL-PRF-X = Pseudo-Random Function based on HMAC-SHA1, generating 3180 a PTK of size X octets. 3182 TKIP uses X = 64, while CCMP, WRAP, and WEP use X = 48. 3184 The EAPOL-Key Confirmation Key (KCK) is used to provide data origin 3185 authenticity in the TSK derivation. It utilizes the first 128 bits 3186 (bits 0-127) of the PTK. The EAPOL-Key Encryption Key (KEK) provides 3187 confidentiality in the TSK derivation. It utilizes bits 128-255 of 3188 the PTK. Bits 256-383 of the PTK are used by Temporal Key 1, and Bits 3189 384-511 are used by Temporal Key 2. Usage of TK1 and TK2 is 3190 ciphersuite specific. Details are available in [IEEE80211i]. 3192 Appendix E - Key Names and Scope in Existing Methods 3194 This appendix specifies the key names and scope in methods that have 3195 been published prior to the publication of this RFC. What is needed 3196 in addition to the rules in Section 2.4 is the definition of what EAP 3197 peer and server names are used, what Method-Id is used, and how these 3198 are encoded. 3200 EAP-TLS 3202 The EAP-TLS Method-Id is provided by the concatenation of the peer 3203 and server nonces. 3205 Where certificates are used, the Session-Id scope is determined via 3206 the EAP peer and server names, deduced from the altSubjectName in the 3207 peer and server certificates. 3209 Issue: What happens if a pre-shaked key ciphersuite is negotiated? 3210 How are the EAP peer and server names determined? 3212 EAP-AKA 3214 The EAP-AKA Method-Id is the contents of the RAND field from the 3215 AT_RAND attribute, followed by the contents of the AUTN field in the 3216 AT_AUTN attribute. 3218 The EAP peer name is the contents of the Identity field from the 3219 AT_IDENTITY attribute, using only the Actual Identity Length octets 3220 from the beginning, however. Note that the contents are used as they 3221 are transmitted, regardless of whether the transmitted identity was a 3222 permanent, pseudonym, or fast reauthentication identity. The EAP 3223 server name is an empty string. 3225 EAP-SIM 3227 The Method-Id is the contents of the RAND field from the AT_RAND 3228 attribute, followed by the contents of the NONCE_MT field in the 3229 AT_NONCE_MT attribute. 3231 The EAP peer name is the contents of the Identity field from the 3232 AT_IDENTITY attribute, using only the Actual Identity Length octets 3233 from the beginning, however. Note that the contents are used as they 3234 are transmitted, regardless of whether the transmitted identity was a 3235 permanent, pseudonym, or fast reauthentication identity. The EAP 3236 server name is an empty string. 3238 Appendix F - Security Association Examples 3240 EAP Method SA Example: EAP-TLS 3242 In EAP-TLS [RFC2716], after the EAP authentication the client (peer) 3243 and server can store the following information: 3245 o Implicitly, the EAP method this SA refers to (EAP-TLS) 3246 o Session identifier (a value selected by the server) 3247 o Certificate of the other party (server stores the client's 3248 certificate and vice versa) 3249 o Ciphersuite and compression method 3250 o TLS Master secret (known as the EAP-TLS Master Key) 3251 o SA lifetime (ensuring that the SA is not stored forever) 3252 o If the client has multiple different credentials (certificates 3253 and corresponding private keys), a pointer to those credentials 3255 When the server initiates EAP-TLS, the client can look up the EAP-TLS 3256 SA based on the credentials it was going to use (certificate and 3257 private key), and the expected credentials (certificate or name) of 3258 the server. If an EAP-TLS SA exists, and it is not too old, the 3259 client informs the server about the existence of this SA by including 3260 its Session-Id in the TLS ClientHello message. The server then looks 3261 up the correct SA based on the Session-Id (or detects that it doesn't 3262 yet have one). 3264 EAP Method SA Example: EAP-AKA 3266 In EAP-AKA [I-D.arkko-pppext-eap-aka], after EAP authentication the 3267 client and server can store the following information: 3269 o Implicitly, the EAP method this SA refers to (EAP-AKA) 3270 o A re-authentication pseudonym 3271 o The client's permanent identity (IMSI) 3272 o Replay protection counter 3273 o Authentication key (K_aut) 3274 o Encryption key (K_encr) 3275 o Original Master Key (MK) 3276 o SA lifetime (ensuring that the SA is not stored forever) 3278 When the server initiates EAP-AKA, the client can look up the EAP-AKA 3279 SA based on the credentials it was going to use (permanent identity). 3280 If an EAP-AKA SA exists, and it is not too old, the client informs 3281 the server about the existence of this SA by sending its re- 3282 authentication pseudonym as its identity in EAP Identity Response 3283 message, instead of its permanent identity. The server then looks up 3284 the correct SA based on this identity. 3286 AAA SA Example: RADIUS 3288 In RADIUS, where shared secret authentication is used, the client and 3289 server store each other's IP address and the shared secret, which is 3290 used to calculate the Response Authenticator [RFC2865] and Message- 3291 Authenticator [RFC3579] values, and to encrypt some attributes (such 3292 as the AAA-Key, see [RFC3580] Section 3.16). 3294 Where IPsec is used to protect RADIUS [RFC3579] and IKE is used for 3295 key management, the parties store information necessary to 3296 authenticate and authorize the other party (e.g. certificates, trust 3297 anchors and names). The IKE exchange results in IKE Phase 1 and Phase 3298 2 SAs containing information used to protect the conversation 3299 (session keys, selected ciphersuite, etc.) 3301 AAA SA Example: Diameter with TLS 3303 When using Diameter protected by TLS, the parties store information 3304 necessary to authenticate and authorize the other party (e.g. 3305 certificates, trust anchors and names). The TLS handshake results in 3306 a short-term TLS SA that contains information used to protect the 3307 actual communications (session keys, selected TLS ciphersuite, etc.). 3309 Service SA Example: 802.11i 3311 [IEEE802.11i] Section 8.4.1.1 defines the security associations used 3312 within IEEE 802.11. A summary follows; the standard should be 3313 consulted for details. 3315 o Pairwise Master Key Security Association (PMKSA) 3317 The PMKSA is a bi-directional SA, used by both parties for sending 3318 and receiving. The PMKSA is the Root Service SA. It is created 3319 on the peer when EAP authentication completes successfully or a 3320 pre-shared key is configured. The PMKSA is created on the 3321 authenticator when the PMK is received or created on the 3322 authenticator or a pre-shared key is configured. The PMKSA is 3323 used to create the PTKSA. PMKSAs are cached for their lifetimes. 3324 The PMKSA consists of the following elements: 3326 - PMKID (security association identifier) 3327 - Authenticator MAC address 3328 - PMK 3329 - Lifetime 3330 - Authenticated Key Management Protocol (AKMP) 3331 - Authorization parameters specified by the AAA server or 3332 by local configuration. This can include 3333 parameters such as the peer's authorized SSID. 3335 On the peer, this information can be locally 3336 configured. 3337 - Key replay counters (for EAPOL-Key messages) 3338 - Reference to PTKSA (if any), needed to: 3339 o delete it (e.g. AAA server-initiated disconnect) 3340 o replace it when a new four-way handshake is done 3341 - Reference to accounting context, the details of which depend 3342 on the accounting protocol used, the implementation 3343 and administrative details. In RADIUS, this could include 3344 (e.g. packet and octet counters, and Acct-Multi-Session-Id). 3346 o Pairwise Transient Key Security Association (PTKSA) 3348 The PTKSA is a bi-directional SA created as the result of a 3349 successful four-way handshake. The PTKSA is a unicast service SA. 3350 There may only be one PTKSA between a pair of peer and 3351 authenticator MAC addresses. PTKSAs are cached for the lifetime 3352 of the PMKSA. Since the PTKSA is tied to the PMKSA, it only has 3353 the additional information from the 4-way handshake. The PTKSA 3354 consists of the following: 3356 - Key (PTK) 3357 - Selected ciphersuite 3358 - MAC addresses of the parties 3359 - Replay counters, and ciphersuite specific state 3360 - Reference to PMKSA: This is needed when: 3361 o A new four-way handshake is needed (lifetime, TKIP 3362 countermeasures), and we need to know which PMKSA to use 3364 o Group Transient Key Security Association (GTKSA) 3366 The GTKSA is a uni-directional SA created based on the four-way 3367 handshake or the group key handshake. The GTKSA is a multicast 3368 service SA. A GTKSA consists of the following: 3370 - Direction vector (whether the GTK is used for transmit or receive) 3371 - Group cipher suite selector 3372 - Key (GTK) 3373 - Authenticator MAC address 3374 - Via reference to PMKSA, or copied here: 3375 o Authorization parameters 3376 o Reference to accounting context 3378 Service SA Example: IKEv2/IPsec 3380 Note that this example is intended to be informative, and it does 3381 not necessarily include all information stored. 3383 o IKEv2 SA 3385 - Protocol version 3386 - Identities of the parties 3387 - IKEv2 SPIs 3388 - Selected ciphersuite 3389 - Replay protection counters (Message ID) 3390 - Keys for protecting IKEv2 messages (SK_ai/SK_ar/SK_ei/SK_er) 3391 - Key for deriving keys for IPsec SAs (SK_d) 3392 - Lifetime information 3393 - On the authenticator, service authorization information 3394 received from the backend authentication server. 3396 When processing an incoming message, the correct SA is looked up 3397 based on the SPIs. 3399 o IPsec SAs/SPD 3401 - Traffic selectors 3402 - Replay protection counters 3403 - Selected ciphersuite 3404 - IPsec SPI 3405 - Keys 3406 - Lifetime information 3407 - Protocol mode (tunnel or transport) 3409 The correct SA is looked up based on SPI (for inbound packets), or 3410 SPD traffic selectors (for outbound traffic). A separate IPsec SA 3411 exists for each direction. 3413 Intellectual Property Statement 3415 The IETF takes no position regarding the validity or scope of any 3416 intellectual property or other rights that might be claimed to 3417 pertain to the implementation or use of the technology described in 3418 this document or the extent to which any license under such rights 3419 might or might not be available; neither does it represent that it 3420 has made any effort to identify any such rights. Information on the 3421 IETF's procedures with respect to rights in standards-track and 3422 standards-related documentation can be found in BCP-11. Copies of 3423 claims of rights made available for publication and any assurances of 3424 licenses to be made available, or the result of an attempt made to 3425 obtain a general license or permission for the use of such 3426 proprietary rights by implementors or users of this specification can 3427 be obtained from the IETF Secretariat. 3429 The IETF invites any interested party to bring to its attention any 3430 copyrights, patents or patent applications, or other proprietary 3431 rights which may cover technology that may be required to practice 3432 this standard. Please address the information to the IETF Executive 3433 Director. 3435 Disclaimer of Validity 3437 This document and the information contained herein are provided on an 3438 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3439 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 3440 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 3441 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 3442 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3443 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3445 Copyright Statement 3447 Copyright (C) The Internet Society (2005). This document is subject 3448 to the rights, licenses and restrictions contained in BCP 78, and 3449 except as set forth therein, the authors retain all their rights. 3451 Open Issues 3453 Open issues relating to this specification are tracked on the 3454 following web site: 3456 http://www.drizzle.com/~aboba/EAP/eapissues.html