idnits 2.17.1 draft-ietf-eap-keying-21.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 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 3441. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3452. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3459. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3465. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3748, but the abstract doesn't seem to directly say this. It does mention RFC3748 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. (Using the creation date from RFC3748, updated by this document, for RFC5378 checks: 2003-02-10) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (31 October 2007) is 6021 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-tls-rfc4346-bis' is defined on line 3124, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-simon-emu-rfc2716bis-11 == Outdated reference: A later version (-10) exists of draft-ietf-tls-rfc4346-bis-05 -- 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 2845 (Obsoleted by RFC 8945) -- Obsolete informational reference (is this intentional?): RFC 3547 (Obsoleted by RFC 6407) -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 4005 (Obsoleted by RFC 7155) -- Obsolete informational reference (is this intentional?): RFC 4282 (Obsoleted by RFC 7542) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) -- Obsolete informational reference (is this intentional?): RFC 4718 (Obsoleted by RFC 5996) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 EAP Working Group Bernard Aboba 3 Internet Draft Dan Simon 4 Updates: 3748 Microsoft Corporation 5 Category: Standards Track P. Eronen 6 Expires: May 1, 2008 Nokia 7 31 October 2007 9 Extensible Authentication Protocol (EAP) Key Management Framework 10 draft-ietf-eap-keying-21.txt 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on May 1, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). All rights reserved. 39 Abstract 41 The Extensible Authentication Protocol (EAP), defined in RFC 3748, 42 enables extensible network access authentication. This document 43 specifies the EAP key hierarchy and provides a framework for the 44 transport and usage of keying material and parameters generated by 45 EAP authentication algorithms, known as "methods". It also provides 46 a detailed system-level security analysis, describing the conditions 47 under which the key management guidelines described in RFC 4962 can 48 be satisfied. 50 Table of Contents 52 1. Introduction .......................................... 3 53 1.1 Requirements Language ........................... 3 54 1.2 Terminology ..................................... 3 55 1.3 Overview ........................................ 7 56 1.4 EAP Key Hierarchy ............................... 9 57 1.5 Security Goals .................................. 13 58 1.6 EAP Invariants .................................. 14 59 2. Lower Layer Operation ................................. 18 60 2.1 Transient Session Keys .......................... 19 61 2.2 Authenticator and Peer Architecture ............. 20 62 2.3 Authenticator Identification ..................... 21 63 2.4 Peer Identification ............................. 25 64 2.5 Server Identification ........................... 26 65 3. Security Association Management ....................... 28 66 3.1 Secure Association Protocol ..................... 29 67 3.2 Key Scope ....................................... 32 68 3.3 Parent-Child Relationships ...................... 33 69 3.4 Local Key Lifetimes ............................. 34 70 3.5 Exported and Calculated Key Lifetimes ........... 34 71 3.6 Key Cache Synchronization ....................... 37 72 3.7 Key Strength .................................... 37 73 3.8 Key Wrap ........................................ 37 74 4. Handoff Vulnerabilities ............................... 38 75 4.1 EAP Pre-authentication .......................... 39 76 4.2 Proactive Key Distribution ...................... 41 77 4.3 AAA Bypass ...................................... 42 78 5. Security Considerations .............................. 46 79 5.1 Peer and Authenticator Compromise ............... 47 80 5.2 Cryptographic Negotiation ....................... 49 81 5.3 Confidentiality and Authentication .............. 50 82 5.4 Key Binding ..................................... 56 83 5.5 Authorization ................................... 57 84 5.6 Replay Protection ............................... 59 85 5.7 Key Freshness ................................... 59 86 5.8 Key Scope Limitation ............................ 61 87 5.9 Key Naming ...................................... 62 88 5.10 Denial of Service Attacks ....................... 63 89 6. IANA Considerations ................................... 63 90 7. References ............................................ 63 91 7.1 Normative References ............................ 63 92 7.2 Informative References .......................... 64 93 Acknowledgments .............................................. 70 94 Author's Addresses ........................................... 70 95 Appendix A - Exported Parameters in Existing Methods ......... 71 96 Full Copyright Statement ..................................... 73 97 Intellectual Property ........................................ 73 99 1. Introduction 101 The Extensible Authentication Protocol (EAP), defined in [RFC3748], 102 was designed to enable extensible authentication for network access 103 in situations in which the Internet Protocol (IP) protocol is not 104 available. Originally developed for use with Point-to-Point Protocol 105 (PPP) [RFC1661], it has subsequently also been applied to IEEE 802 106 wired networks [IEEE-802.1X], IKEv2 [RFC4306] and wireless networks 107 such as [IEEE-802.11] and [IEEE-802.16e]. 109 EAP is a two-party protocol spoken between the EAP peer and server. 110 Within EAP, keying material is generated by EAP authentication 111 algorithms, known as "methods". Part of this keying material can be 112 used by EAP methods themselves and part of this material can be 113 exported. In addition to export of keying material, EAP methods can 114 also export associated parameters such as authenticated peer and 115 server identities and a unique EAP conversation identifier, and can 116 import and export lower layer parameters known as "channel binding 117 parameters", or simply "channel bindings". 119 This document specifies the EAP key hierarchy and provides a 120 framework for the transport and usage of keying material and 121 parameters generated by EAP methods. It also provides a detailed 122 security analysis, describing the conditions under which the 123 requirements described in "Guidance for Authentication, Authorization 124 and Accounting (AAA) Key Management" [RFC4962] can be satisfied. 126 1.1. Requirements Language 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in [RFC2119]. 132 1.2. Terminology 134 The terms "Cryptographic binding", "Cryptographic separation", "Key 135 strength" and "Mutual authentication" are defined in [RFC3748] and 136 are used with the same meaning in this document, which also 137 frequently uses the following terms: 139 4-Way Handshake 140 A pairwise Authentication and Key Management Protocol (AKMP) 141 defined in [IEEE-802.11], which confirms mutual possession of a 142 Pairwise Master Key by two parties and distributes a Group Key. 144 AAA Authentication, Authorization and Accounting. AAA protocols with 145 EAP support include RADIUS [RFC3579] and Diameter [RFC4072]. In 146 this document, the terms "AAA server" and "backend authentication 147 server" are used interchangeably. 149 AAA-Key 150 The term AAA-Key is synonymous with Master Session Key (MSK). 151 Since multiple keys can be transported by AAA, the term is 152 potentially confusing and is not used in this document. 154 authenticator 155 The entity initiating EAP authentication. 157 backend authentication server 158 A backend authentication server is an entity that provides an 159 authentication service to an authenticator. When used, this server 160 typically executes EAP methods for the authenticator. This 161 terminology is also used in [IEEE-802.1X]. 163 Channel Binding 164 A secure mechanism for ensuring that a subset of the parameters 165 transmitted by the authenticator (such as authenticator identifiers 166 and properties) are agreed upon by the EAP peer and server. It is 167 expected that the parameters are also securely agreed upon by the 168 EAP peer and authenticator via the lower layer if the authenticator 169 advertised the parameters. 171 Derived Keying Material 172 Keys derived from EAP keying material, such as Transient Session 173 Keys (TSKs). 175 EAP Keying Material 176 Keys derived by an EAP method; this includes exported keying 177 material (MSK, EMSK, IV) as well as local keying material such as 178 Transient EAP Keys (TEKs). 180 EAP pre-authentication 181 The use of EAP to pre-establish EAP keying material on an 182 authenticator prior to arrival of the peer at the access network 183 managed by that authenticator. 185 EAP re-authentication 186 EAP authentication between an EAP peer and a server with whom the 187 EAP peer shares valid unexpired EAP keying material. 189 EAP server 190 The entity that terminates the EAP authentication method with the 191 peer. In the case where no backend authentication server is used, 192 the EAP server is part of the authenticator. In the case where the 193 authenticator operates in pass-through mode, the EAP server is 194 located on the backend authentication server. 196 Exported keying material 197 The EAP Master Session Key (MSK), Extended Master Session Key 198 (EMSK), and Initialization Vector (IV). 200 Extended Master Session Key (EMSK) 201 Additional keying material derived between the peer and server that 202 is exported by the EAP method. The EMSK is at least 64 octets in 203 length, and is never shared with a third party. The EMSK MUST be 204 at least as long as the MSK in size. 206 Initialization Vector (IV) 207 A quantity of at least 64 octets, suitable for use in an 208 initialization vector field, that is derived between the peer and 209 EAP server. Since the IV is a known value in methods such as EAP- 210 TLS [I-D.simon-emu-rfc2716bis], it cannot be used by itself for 211 computation of any quantity that needs to remain secret. As a 212 result, its use has been deprecated and it is OPTIONAL for EAP 213 methods to generate it. However, when it is generated it MUST be 214 unpredictable. 216 Keying Material 217 Unless otherwise qualified, the term "keying material" refers to 218 EAP keying material as well as derived keying material. 220 Key Scope 221 The parties to whom a key is available. 223 Key Wrap 224 The encryption of one symmetric cryptographic key in another. The 225 algorithm used for the encryption is called a key wrap algorithm or 226 a key encryption algorithm. The key used in the encryption process 227 is called a key-encryption key (KEK). 229 Long Term Credential 230 EAP methods frequently make use of long term secrets in order to 231 enable authentication between the peer and server. In the case of 232 a method based on pre-shared key authentication, the long term 233 credential is the pre-shared key. In the case of a public-key 234 based method, the long term credential is the corresponding private 235 key. 237 Lower Layer 238 The lower layer is responsible for carrying EAP frames between the 239 peer and authenticator. 241 Lower Layer Identity 242 A name used to identify the EAP peer and authenticator within the 243 lower layer. 245 Master Session Key (MSK) 246 Keying material that is derived between the EAP peer and server and 247 exported by the EAP method. The MSK is at least 64 octets in 248 length. 250 Network Access Server (NAS) 251 A device that provides an access service for a user to a network. 253 Pairwise Master Key (PMK) 254 Lower layers use the MSK in lower-layer dependent manner. For 255 instance, in IEEE 802.11 [IEEE-802.11] Octets 0-31 of the MSK are 256 known as the Pairwise Master Key (PMK); the TKIP and AES CCMP 257 ciphersuites derive their Transient Session Keys (TSKs) solely from 258 the PMK, whereas the WEP ciphersuite as noted in [RFC3580], derives 259 its TSKs from both halves of the MSK. In [802.16e], the MSK is 260 truncated to 20 octets for PMK and 20 octets for PMK2. 262 peer The entity that responds to the authenticator. In [IEEE-802.1X], 263 this entity is known as the Supplicant. 265 security association 266 A set of policies and cryptographic state used to protect 267 information. Elements of a security association include 268 cryptographic keys, negotiated ciphersuites and other parameters, 269 counters, sequence spaces, authorization attributes, etc. 271 Secure Association Protocol 272 An exchange that occurs between the EAP peer and authenticator in 273 order to manage security associations derived from EAP exchanges. 274 The protocol establishes unicast and (optionally) multicast 275 security associations, which include symmetric keys and a context 276 for the use of the keys. An example of a Secure Association 277 Protocol is the 4-way handshake defined within [IEEE-802.11]. 279 Session-Id 280 The EAP Session-Id uniquely identifies an EAP authentication 281 exchange between an EAP peer (as identified by the Peer-Id(s)) and 282 server (as identified by the Server-Id(s)). For more information, 283 see Section 1.4. 285 Transient EAP Keys (TEKs) 286 Session keys which are used to establish a protected channel 287 between the EAP peer and server during the EAP authentication 288 exchange. The TEKs are appropriate for use with the ciphersuite 289 negotiated between EAP peer and server for use in protecting the 290 EAP conversation. The TEKs are stored locally by the EAP method 291 and are not exported. Note that the ciphersuite used to set up the 292 protected channel between the EAP peer and server during EAP 293 authentication is unrelated to the ciphersuite used to subsequently 294 protect data sent between the EAP peer and authenticator. 296 Transient Session Keys (TSKs) 297 Keys used to protect data exchanged after EAP authentication has 298 successfully completed, using the ciphersuite negotiated between 299 the EAP peer and authenticator. 301 1.3. Overview 303 Where EAP key derivation is supported, the conversation typically 304 takes place in three phases: 306 Phase 0: Discovery 307 Phase 1: Authentication 308 1a: EAP authentication 309 1b: AAA Key Transport (optional) 310 Phase 2: Secure Association Protocol 311 2a: Unicast Secure Association 312 2b: Multicast Secure Association (optional) 314 Of these phases, Phase 0, 1b and Phase 2 are handled external to EAP. 315 Phases 0 and 2 are handled by the lower layer protocol and phase 1b 316 is typically handled by a AAA protocol. 318 In the discovery phase (phase 0), peers locate authenticators and 319 discover their capabilities. A peer can locate an authenticator 320 providing access to a particular network, or a peer can locate an 321 authenticator behind a bridge with which it desires to establish a 322 Secure Association. Discovery can occur manually or automatically, 323 depending on the lower layer over which EAP runs. 325 The authentication phase (phase 1) can begin once the peer and 326 authenticator discover each other. This phase, if it occurs, always 327 includes EAP authentication (phase 1a). Where the chosen EAP method 328 supports key derivation, in phase 1a EAP keying material is derived 329 on both the peer and the EAP server. 331 An additional step (phase 1b) is needed in deployments which include 332 a backend authentication server, in order to transport keying 333 material from the backend authentication server to the authenticator. 334 In order to obey the principle of mode independence (see Section 335 1.6.1), where a backend server is present, all keying material needed 336 by the lower layer is transported from the EAP server to the 337 authenticator. Since existing TSK derivation and transport 338 techniques depend solely on the MSK, in existing implementations, 339 this is the only keying material replicated in the AAA key transport 340 phase 1b. 342 Successful completion of EAP authentication and key derivation by a 343 peer and EAP server does not necessarily imply that the peer is 344 committed to joining the network associated with an EAP server. 345 Rather, this commitment is implied by the creation of a security 346 association between the EAP peer and authenticator, as part of the 347 Secure Association Protocol (phase 2). The Secure Association 348 Protocol exchange (phase 2) occurs between the peer and authenticator 349 in order to manage the creation and deletion of unicast (phase 2a) 350 and multicast (phase 2b) security associations between the peer and 351 authenticator. The conversation between the parties is shown in 352 Figure 1. 354 EAP peer Authenticator Auth. Server 355 -------- ------------- ------------ 356 |<----------------------------->| | 357 | Discovery (phase 0) | | 358 |<----------------------------->|<----------------------------->| 359 | EAP auth (phase 1a) | AAA pass-through (optional) | 360 | | | 361 | |<----------------------------->| 362 | | AAA Key transport | 363 | | (optional; phase 1b) | 364 |<----------------------------->| | 365 | Unicast Secure association | | 366 | (phase 2a) | | 367 | | | 368 |<----------------------------->| | 369 | Multicast Secure association | | 370 | (optional; phase 2b) | | 371 | | | 373 Figure 1: Conversation Overview 375 1.3.1. Examples 377 Existing EAP lower layers implement phase 0, 2a and 2b in different 378 ways: 380 PPP The Point-to-Point Protocol (PPP), defined in [RFC1661] does not 381 support discovery, nor does it include a Secure Association 382 Protocol. 384 PPPoE 385 PPP over Ethernet (PPPoE), defined in [RFC2516], includes support 386 for a Discovery stage (phase 0). In this step, the EAP peer sends 387 a PPPoE Active Discovery Initiation (PADI) packet to the broadcast 388 address, indicating the service it is requesting. The Access 389 Concentrator replies with a PPPoE Active Discovery Offer (PADO) 390 packet containing its name, the service name and an indication of 391 the services offered by the concentrator. The discovery phase is 392 not secured. PPPoE, like PPP, does not include a Secure 393 Association Protocol. 395 IKEv2 396 Internet Key Exchange v2 (IKEv2), defined in [RFC4306], includes 397 support for EAP and handles the establishment of unicast security 398 associations (phase 2a). However, the establishment of multicast 399 security associations (phase 2b) typically does not involve EAP and 400 needs to be handled by a group key management protocol such as GDOI 401 [RFC3547], GSAKMP [RFC4535], MIKEY [RFC3830], or GKDP [GKDP]. 402 Several mechanisms have been proposed for discovery of IPsec 403 security gateways. [RFC2230] discusses the use of Key eXchange 404 (KX) Resource Records (RRs) for IPsec gateway discovery; while KX 405 RRs are supported by many Domain Name Service (DNS) server 406 implementations, they have not yet been widely deployed. 407 Alternatively, DNS SRV RRs [RFC2782] can be used for this purpose. 408 Where DNS is used for gateway location, DNS security mechanisms 409 such as DNSSEC ([RFC4033], [RFC4035]), TSIG [RFC2845], and Simple 410 Secure Dynamic Update [RFC3007] are available. 412 IEEE 802.11 413 IEEE 802.11, defined in [IEEE-802.11], handles discovery via the 414 Beacon and Probe Request/Response mechanisms. IEEE 802.11 access 415 points periodically announce their Service Set Identifiers (SSIDs) 416 as well as capabilities using Beacon frames. Stations can query 417 for access points by sending a Probe Request to the broadcast 418 address. Neither Beacon nor Probe Request/Response frames are 419 secured. The 4-way handshake defined in [IEEE-802.11] enables the 420 derivation of unicast (phase 2a) and multicast/broadcast (phase 2b) 421 secure associations. Since the group key exchange transports a 422 group key from the access point to the station, two 4-way 423 handshakes can be needed in order to support peer-to-peer 424 communications. A proof of the security of the IEEE 802.11 4-way 425 handshake when used with EAP-TLS is provided in [He]. 427 IEEE 802.1X 428 IEEE 802.1X-2004, defined in [IEEE-802.1X] does not support 429 discovery (phase 0), nor does it provide for derivation of unicast 430 or multicast secure associations. 432 1.4. EAP Key Hierarchy 434 As illustrated in Figure 2, the EAP method key derivation has at the 435 root the long term credential utilized by the selected EAP method. 436 If authentication is based on a pre-shared key, the parties store the 437 EAP method to be used and the pre-shared key. The EAP server also 438 stores the peer's identity as well as additional information. This 439 information is typically used outside of the EAP method to determine 440 whether to grant access to a service. The peer stores information 441 necessary to choose which secret to use for which service. 443 If authentication is based on proof of possession of the private key 444 corresponding to the public key contained within a certificate, the 445 parties store the EAP method to be used and the trust anchors used to 446 validate the certificates. The EAP server also stores the peer's 447 identity and the peer stores information necessary to choose which 448 certificate to use for which service. Based on the long term 449 credential established between the peer and the server, methods 450 derive two types of EAP keying material: 452 (a) Keying material calculated locally by the EAP method 453 but not exported, such as the Transient EAP Keys (TEKs). 454 (b) Keying material exported by the EAP method: Master Session Key 455 (MSK), Extended Master Session Key (EMSK), Initialization 456 Vector (IV). 458 As noted in [RFC3748] Section 7.10: 460 In order to provide keying material for use in a subsequently 461 negotiated ciphersuite, an EAP method supporting key derivation 462 MUST export a Master Session Key (MSK) of at least 64 octets, and 463 an Extended Master Session Key (EMSK) of at least 64 octets. 465 EAP methods also MAY export the IV; however, the use of the IV is 466 deprecated. The EMSK MUST NOT be provided to an entity outside the 467 EAP server or peer, nor is it permitted to pass any quantity to an 468 entity outside the EAP server or peer from which the EMSK could be 469 computed without breaking some cryptographic assumption, such as 470 inverting a one-way function. 472 EAP methods supporting key derivation and mutual authentication 473 SHOULD export a method-specific EAP conversation identifier known as 474 the Session-Id, as well as one or more method-specific peer 475 identifiers (Peer-Id(s)) and MAY export one or more method-specific 476 server identifiers (Server-Id(s)). EAP methods MAY also support the 477 import and export of channel binding parameters. EAP method 478 specifications developed after the publication of this document MUST 479 define the Peer-Id, Server-Id and Session-Id. The Peer-Id(s) and 480 Server-Id(s), when provided, identify the entities involved in 481 generating EAP keying material. For existing EAP methods the Peer-Id, 482 Server-Id and Session-Id are defined in Appendix A. 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 485 | | ^ 486 | EAP Method | | 487 | | | 488 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | | 489 | | | | | | | 490 | | EAP Method Key |<->| Long-Term | | | 491 | | Derivation | | Credential | | | 492 | | | | | | | 493 | | | +-+-+-+-+-+-+-+ | Local to | 494 | | | | EAP | 495 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Method | 496 | | | | | | 497 | | | | | | 498 | | | | | | 499 | | | | | | 500 | | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | | 501 | | | TEK | |MSK, EMSK | |IV | | | 502 | | |Derivation | |Derivation | |Derivation | | | 503 | | | | | | |(Deprecated) | | | 504 | | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | | 505 | | ^ | | | | 506 | | | | | | V 507 +-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+ ---+ 508 | | | | ^ 509 | | | | Exported | 510 | Peer-Id(s), | channel | MSK (64+B) | IV (64B) by | 511 | Server-Id(s), | bindings | EMSK (64+B) | (Optional) EAP | 512 | Session-Id | & Result | | Method | 513 V V V V V 515 Figure 2: EAP Method Parameter Import/Export 517 Peer-Id 519 If an EAP method that generates keys authenticates one or more 520 method-specific peer identities, those identities are exported by 521 the method as the Peer-Id(s). It is possible for more than one 522 Peer-Id to be exported by an EAP method. Not all EAP methods 523 provide a method-specific peer identity; where this is not 524 defined, the Peer-Id is the null string. In EAP methods that do 525 not support key generation, the Peer-Id MUST be the null string. 526 Where an EAP method that derives keys does not provide a Peer-Id, 527 the EAP server will not authenticate the identity of the EAP peer 528 with which it derived keying material. 530 Server-Id 531 If an EAP method that generates keys authenticates one or more 532 method-specific server identities, those identities are exported 533 by the method as the Server-Id(s). It is possible for more than 534 one Server-Id to be exported by an EAP method. Not all EAP 535 methods provide a method-specific server identity; where this is 536 not defined, the Server-Id is the null string. If the EAP method 537 not generate keying material, the Server-Id MUST be the null 538 string. Where an EAP method that derives keys does not provide a 539 Server-Id, the EAP peer will not authenticate the identity of the 540 EAP server with which it derived EAP keying material. 542 Session-Id 544 The Session-Id uniquely identifies an EAP session between an EAP 545 peer (as identified by the Peer-Id) and server (as identified by 546 the Server-Id). Where non-expanded EAP Type Codes are used (EAP 547 Type Code not equal to 254), the EAP Session-Id is the 548 concatenation of the single octet EAP Type Code and a temporally 549 unique identifier obtained from the method (known as the Method- 550 Id). Where expanded EAP Type Codes are used, the EAP Session-Id 551 consists of the Expanded Type Code (including the Type, Vendor-Id 552 and Vendor-Type fields defined in [RFC3748] Section 5.7) 553 concatenated with a temporally unique identifier obtained from the 554 method (Method-Id). The Method-Id is typically constructed from 555 nonces or counters used within the EAP method exchange. The 556 inclusion of the Type Code or Expanded Type Code in the EAP 557 Session-Id ensures that each EAP method has a distinct Session-Id 558 space. Since an EAP session is not bound to a particular 559 authenticator or specific ports on the peer and authenticator, the 560 authenticator port or identity are not included in the Session-Id. 562 Channel Binding 564 Channel Binding is the process by which lower layer parameters are 565 verified for consistency between the EAP peer and server. In 566 order to avoid introducing media dependencies, EAP methods that 567 transport channel binding parameters MUST treat this data as 568 opaque octets. See Section 5.3.3 for further discussion. 570 1.4.1. Key Naming 572 Each key created within the EAP key management framework has a name 573 (a unique identifier), as well as a scope (the parties to whom the 574 key is available). The scope of exported keying material and TEKs is 575 defined by the authenticated method-specific peer identities (Peer- 576 Id(s)) and the authenticated server identities (Server-Id(s)), where 577 available. 579 MSK and EMSK Names 580 The MSK and EMSK are exported by the EAP peer and EAP server, and 581 MUST be named using the EAP Session-Id and a binary or textual 582 indication of the EAP keying material being referred to. 584 PMK Name 585 This document does not specify a naming scheme for the Pairwise 586 Master Key (PMK). The PMK is only identified by the name of the 587 key from which it is derived. 589 Note: IEEE 802.11 names the PMK for the purposes of being able to 590 refer to it in the Secure Association Protocol; the PMK name (known 591 as the PMKID) is based on a hash of the PMK itself as well as some 592 other parameters (see [IEEE-802.11] Section 8.5.1.2). 594 TEK Name 595 Transient EAP Keys (TEKs) MAY be named; their naming is specified 596 in the EAP method specification. 598 TSK Name 599 Transient Session Keys (TSKs) are typically named. Their naming is 600 specified in the lower layer so that the correct set of TSKs can be 601 identified for processing a given packet. 603 1.5. Security Goals 605 The goal of the EAP conversation is to derive fresh session keys 606 between the EAP peer and authenticator that are known only to those 607 parties, and for both the EAP peer and authenticator to demonstrate 608 that they are authorized to perform their roles either by each other 609 or by a trusted third party (the backend authentication server). 611 Completion of an EAP method exchange (Phase 1a) supporting key 612 derivation results in the derivation of EAP keying material (MSK, 613 EMSK, TEKs) known only to the EAP peer (identified by the Peer-Id(s)) 614 and EAP server (identified by the Server-Id(s)). Both the EAP peer 615 and EAP server know this keying material to be fresh. The Peer-Id 616 and Server-Id are discussed in Section 1.4 and Appendix A. Key 617 freshness is discussed in Sections 3.4, 3.5 and 5.7. 619 Completion of the AAA exchange (Phase 1b) results in the transport of 620 keying material from the EAP server (identified by the Server-Id(s)) 621 to the EAP authenticator (identified by the NAS-Identifier) without 622 disclosure to any other party. Both the EAP server and EAP 623 authenticator know this keying material to be fresh. Disclosure 624 issues are discussed in Sections 3.8 and 5.3; security properties of 625 AAA protocols are discussed in Sections 5.1-5.9. 627 The backend authentication server is trusted to transport keying 628 material only to the authenticator that was established with the 629 peer, and it is trusted to transport that keying material to no other 630 parties. In many systems, EAP keying material established by the EAP 631 peer and EAP server are combined with publicly available data to 632 derive other keys. The backend authentication server is trusted to 633 refrain from deriving these same keys or acting as a man-in-the- 634 middle even though it has access to the keying material that is 635 needed to do so. 637 The authenticator is also a trusted party. The authenticator is 638 trusted not to distribute keying material provided by the backend 639 authentication server to any other parties. If the authenticator 640 uses a key derivation function to derive additional keying material, 641 the authenticator is trusted to distribute the derived keying 642 material only to the appropriate party that is known to the peer, and 643 no other party. When this approach is used, care must be taken to 644 ensure that the resulting key management system meets all of the 645 principles in this document, confirming that keys used to protect 646 data are to be known only by the peer and authenticator. 648 Completion of the Secure Association Protocol (Phase 2) results in 649 the derivation or transport of Transient Session Keys (TSKs) known 650 only to the EAP peer (identified by the Peer-Id(s)) and authenticator 651 (identified by the NAS-Identifier). Both the EAP peer and 652 authenticator know the TSKs to be fresh. Both the EAP peer and 653 authenticator demonstrate that they are authorized to perform their 654 roles. Authorization issues are discussed in Sections 4.3.2 and 5.5; 655 security properties of Secure Association Protocols are discussed in 656 Section 3.1. 658 1.6. EAP Invariants 660 Certain basic characteristics, known as "EAP Invariants", hold true 661 for EAP implementations: 663 Mode independence 664 Media independence 665 Method independence 666 Ciphersuite independence 668 1.6.1. Mode Independence 670 EAP is typically deployed to support extensible network access 671 authentication in situations where a peer desires network access via 672 one or more authenticators. Where authenticators are deployed 673 standalone, the EAP conversation occurs between the peer and 674 authenticator, and the authenticator locally implements one or more 675 EAP methods. However, when utilized in "pass-through" mode, EAP 676 enables deployment of new authentication methods without requiring 677 development of new code on the authenticator. 679 While the authenticator can implement some EAP methods locally and 680 use those methods to authenticate local users, it can at the same 681 time act as a pass-through for other users and methods, forwarding 682 EAP packets back and forth between the backend authentication server 683 and the peer. This is accomplished by encapsulating EAP packets 684 within the Authentication, Authorization and Accounting (AAA) 685 protocol, spoken between the authenticator and backend authentication 686 server. AAA protocols supporting EAP include RADIUS [RFC3579] and 687 Diameter [RFC4072]. 689 It is a fundamental property of EAP that at the EAP method layer, the 690 conversation between the EAP peer and server is unaffected by whether 691 the EAP authenticator is operating in "pass-through" mode. EAP 692 methods operate identically in all aspects, including key derivation 693 and parameter import/export, regardless of whether the authenticator 694 is operating as a pass-through or not. 696 The successful completion of an EAP method that supports key 697 derivation results in the export of EAP keying material and 698 parameters on the EAP peer and server. Even though the EAP peer or 699 server can import channel binding parameters that can include the 700 identity of the EAP authenticator, this information is treated as 701 opaque octets. As a result, within EAP the only relevant identities 702 are the Peer-Id(s) and Server-Id(s). Channel binding parameters are 703 only interpreted by the lower layer. 705 Within EAP, the primary function of the AAA protocol is to maintain 706 the principle of mode independence. As far as the EAP peer is 707 concerned, its conversation with the EAP authenticator, and all 708 consequences of that conversation, are identical, regardless of the 709 authenticator mode of operation. 711 1.6.2. Media Independence 713 One of the goals of EAP is to allow EAP methods to function on any 714 lower layer meeting the criteria outlined in [RFC3748], Section 3.1. 715 For example, as described in [RFC3748], EAP authentication can be run 716 over PPP [RFC1661], IEEE 802 wired networks [IEEE-802.1X], and 717 wireless networks such as 802.11 [IEEE-802.11] and 802.16 718 [IEEE-802.16e]. 720 In order to maintain media independence, it is necessary for EAP to 721 avoid consideration of media-specific elements. For example, EAP 722 methods cannot be assumed to have knowledge of the lower layer over 723 which they are transported, and cannot be restricted to identifiers 724 associated with a particular usage environment (e.g. MAC addresses). 726 Note that media independence can be retained within EAP methods that 727 support Channel Binding or method-specific identification. An EAP 728 method need not be aware of the content of an identifier in order to 729 use it. This enables an EAP method to use media-specific identifiers 730 such as MAC addresses without compromising media independence. 731 Channel binding parameters are treated as opaque octets by EAP 732 methods, so that handling them does not require media-specific 733 knowledge. 735 1.6.3. Method Independence 737 By enabling pass-through, authenticators can support any method 738 implemented on the peer and server, not just locally implemented 739 methods. This allows the authenticator to avoid having to implement 740 the EAP methods configured for use by peers. In fact, since a pass- 741 through authenticator need not implement any EAP methods at all, it 742 cannot be assumed to support any EAP method-specific code. As noted 743 in [RFC3748] Section 2.3: 745 Compliant pass-through authenticator implementations MUST by 746 default forward EAP packets of any Type. 748 This is useful where there is no single EAP method that is both 749 mandatory-to-implement and offers acceptable security for the media 750 in use. For example, the [RFC3748] mandatory-to-implement EAP method 751 (MD5-Challenge) does not provide dictionary attack resistance, mutual 752 authentication or key derivation, and as a result is not appropriate 753 for use in Wireless Local Area Network (WLAN) authentication 754 [RFC4017]. However, despite this it is possible for the peer and 755 authenticator to interoperate as long as a suitable EAP method is 756 supported both on the EAP peer and server. 758 1.6.4. Ciphersuite Independence 760 Ciphersuite Independence is a requirement for Media Independence. 761 Since lower layer ciphersuites vary between media, media independence 762 requires that exported EAP keying material be large enough (with 763 sufficient entropy) to handle any ciphersuite. 765 While EAP methods can negotiate the ciphersuite used in protection of 766 the EAP conversation, the ciphersuite used for the protection of the 767 data exchanged after EAP authentication has completed is negotiated 768 between the peer and authenticator within the lower layer, outside of 769 EAP. 771 For example, within PPP, the ciphersuite is negotiated within the 772 Encryption Control Protocol (ECP) defined in [RFC1968], after EAP 773 authentication is completed. Within [IEEE-802.11], the AP 774 ciphersuites are advertised in the Beacon and Probe Responses prior 775 to EAP authentication, and are securely verified during a 4-way 776 handshake exchange. 778 Since the ciphersuites used to protect data depend on the lower 779 layer, requiring that EAP methods have knowledge of lower layer 780 ciphersuites would compromise the principle of Media Independence. 781 As a result, methods export EAP keying material that is ciphersuite- 782 independent. Since ciphersuite negotiation occurs in the lower 783 layer, there is no need for lower layer ciphersuite negotiation 784 within EAP. 786 In order to allow a ciphersuite to be usable within the EAP keying 787 framework, the ciphersuite specification needs to describe how TSKs 788 suitable for use with the ciphersuite are derived from exported EAP 789 keying material. To maintain Method Independence, algorithms for 790 deriving TSKs MUST NOT depend on the EAP method, although algorithms 791 for TEK derivation MAY be specific to the EAP method. 793 Advantages of ciphersuite-independence include: 795 Reduced update requirements 796 Ciphersuite independence enables EAP methods to be used with new 797 ciphersuites without requiring the methods to be updated. If EAP 798 methods were to specify how to derive transient session keys for 799 each ciphersuite, they would need to be updated each time a new 800 ciphersuite is developed. In addition, backend authentication 801 servers might not be usable with all EAP-capable authenticators, 802 since the backend authentication server would also need to be 803 updated each time support for a new ciphersuite is added to the 804 authenticator. 806 Reduced EAP method complexity 807 Ciphersuite independence enables EAP methods to avoid having to 808 include ciphersuite-specific code. Requiring each EAP method to 809 include ciphersuite-specific code for transient session key 810 derivation would increase method complexity and result in 811 duplicated effort. 813 Simplified configuration 814 Ciphersuite independence enables EAP method implementations on the 815 peer and server to avoid having to configure ciphersuite-specific 816 parameters. The ciphersuite is negotiated between the peer and 817 authenticator outside of EAP. Where the authenticator operates in 818 "pass-through" mode, the EAP server is not a party to this 819 negotiation, nor is it involved in the data flow between the EAP 820 peer and authenticator. As a result, the EAP server does not have 821 knowledge of the ciphersuites and negotiation policies implemented 822 by the peer and authenticator, nor is it aware of the ciphersuite 823 negotiated between them. For example, since Encryption Control 824 Protocol (ECP) negotiation occurs after authentication, when run 825 over PPP, the EAP peer and server cannot anticipate the negotiated 826 ciphersuite and therefore this information cannot be provided to 827 the EAP method. 829 2. Lower Layer Operation 831 On completion of EAP authentication, EAP keying material and 832 parameters exported by the EAP method are provided to the lower layer 833 and AAA layer (if present). These include the Master Session Key 834 (MSK), Extended Master Session Key (EMSK), Peer-Id(s), Server-Id(s) 835 and Session-Id. The Initialization Vector (IV) is deprecated, but 836 might be provided. 838 In order to preserve the security of EAP keying material derived 839 within methods, lower layers MUST NOT export keys passed down by EAP 840 methods. This implies that EAP keying material passed down to a 841 lower layer is for the exclusive use of that lower layer and MUST NOT 842 be used within another lower layer. This prevents compromise of one 843 lower layer from compromising other applications using EAP keying 844 material. 846 EAP keying material provided to a lower layer MUST NOT be transported 847 to another entity. For example, EAP keying material passed down to 848 the EAP peer lower layer MUST NOT leave the peer; EAP keying 849 material passed down or transported to the EAP authenticator lower 850 layer MUST NOT leave the authenticator. 852 On the EAP server, keying material and parameters requested by and 853 passed down to the AAA layer MAY be replicated to the AAA layer on 854 the authenticator (with the exception of the EMSK). On the 855 authenticator, the AAA layer provides the replicated keying material 856 and parameters to the lower layer over which the EAP authentication 857 conversation took place. This enables mode independence to be 858 maintained. 860 The EAP layer as well as the peer and authenticator layers MUST NOT 861 modify or cache keying material or parameters (including Channel 862 Bindings) passing in either direction between the EAP method layer 863 and the lower layer or AAA layer. 865 2.1. Transient Session Keys 867 Where explicitly supported by the lower layer, lower layers MAY cache 868 keying material, including exported EAP keying material and/or TSKs; 869 the structure of this key cache is defined by the lower layer. So as 870 to enable interoperability, new lower layer specifications MUST 871 describe key caching behavior. Unless explicitly specified by the 872 lower layer, the EAP peer, server and authenticator MUST assume that 873 peers and authenticators do not cache keying material. Existing EAP 874 lower layers and AAA layers handle the generation of transient 875 session keys and caching of EAP keying material in different ways: 877 IEEE 802.1X-2004 878 When used with wired networks, IEEE 802.1X-2004 [IEEE-802.1X] does 879 not support link layer ciphersuites and a result, it does not 880 provide for generation of TSKs, or caching of EAP keying material 881 and parameters. Once EAP authentication completes, it is assumed 882 that EAP keying material and parameters are discarded; on IEEE 802 883 wired networks there is no subsequent Secure Association Protocol 884 exchange. Perfect Forward Secrecy (PFS) is only possible if the 885 negotiated EAP method supports this. 887 PPP PPP, defined in [RFC1661] does not include support for a Secure 888 Association Protocol; nor does it support caching of EAP keying 889 material or parameters. PPP ciphersuites derive their TSKs 890 directly from the MSK, as described in [RFC2716]. This is NOT 891 RECOMMENDED, since if PPP were to support caching of EAP keying 892 material, this could result in TSK reuse. As a result, once the 893 PPP session is terminated, EAP keying material and parameters MUST 894 be discarded. Since caching of EAP keying material is not 895 permitted within PPP, there is no way to handle TSK re-key without 896 EAP re-authentication. Perfect Forward Secrecy (PFS) is only 897 possible if the negotiated EAP method supports this. 899 IKEv2 900 IKEv2, defined in [RFC4306] only uses the MSK for authentication 901 purposes and not key derivation. The EMSK, IV, Peer-Id, Server-Id 902 or Session-Id are not used. As a result, the TSKs derived by IKEv2 903 are cryptographically independent of the EAP keying material and 904 re-key of IPsec SAs can be handled without requiring EAP re- 905 authentication. Within IKEv2 it is possible to negotiate PFS, 906 regardless of which EAP method is negotiated. IKEv2 as specified 907 in [RFC4306] does not cache EAP keying material or parameters; once 908 IKEv2 authentication completes it is assumed that EAP keying 909 material and parameters are discarded. The Session-Timeout 910 attribute is therefore interpreted as a limit on the VPN session 911 time, rather than an indication of the MSK key lifetime. 913 IEEE 802.11 914 IEEE 802.11 enables caching of the MSK, but not the EMSK, IV, Peer- 915 Id, Server-Id, or Session-Id. More details about the structure of 916 the cache are available in [IEEE-802.11]. In IEEE 802.11, TSKs are 917 derived from the MSK using a Secure Association Protocol known as 918 the 4-way handshake, which includes a nonce exchange. This 919 guarantees TSK freshness even if the MSK is reused. The 4-way 920 handshake also enables TSK re-key without EAP re-authentication. 921 PFS is only possible within IEEE 802.11 if caching is not enabled 922 and the negotiated EAP method supports PFS. 924 IEEE 802.16e 925 IEEE 802.16e, defined in [IEEE-802.16e] supports caching of the 926 MSK, but not the EMSK, IV, Peer-Id, Server-Id or Session-Id. IEEE 927 802.16e support a Secure Association Protocol in which TSKs are 928 chosen by the authenticator without any contribution by the peer. 929 The TSKs are encrypted, authenticated and integrity protected using 930 the MSK and are transported from the authenticator to the peer. 931 TSK re-key is possible without EAP re-authentication. PFS is not 932 possible even if the negotiated EAP method supports it. 934 AAA Existing implementations and specifications for RADIUS/EAP 935 [RFC3579] or Diameter EAP [RFC4072] do not support caching of 936 keying material or parameters. In existing AAA client, proxy and 937 server implementations, exported EAP keying material (MSK, EMSK and 938 IV) as well as parameters and derived keys are not cached and MUST 939 be presumed lost after the AAA exchange completes. 941 In order to avoid key reuse, the AAA layer MUST delete transported 942 keys once they are sent. The AAA layer MUST NOT retain keys that 943 it has previously sent. For example, a AAA layer that has 944 transported the MSK MUST delete it, and keys MUST NOT be derived 945 from the MSK from that point forward. 947 2.2. Authenticator and Peer Architecture 949 This specification does not impose constraints on the architecture of 950 the EAP authenticator or peer. For example, any of the authenticator 951 architectures described in [RFC4118] can be used. As a result, lower 952 layers need to identify EAP peers and authenticators unambiguously, 953 without incorporating implicit assumptions about peer and 954 authenticator architectures. 956 For example, it is possible for multiple base stations and a 957 "controller" (e.g. WLAN switch) to comprise a single EAP 958 authenticator. In such a situation, the "base station identity" is 959 irrelevant to the EAP method conversation, except perhaps as an 960 opaque blob to be used in Channel Binding. Many base stations can 961 share the same authenticator identity. An EAP authenticator or peer: 963 (a) can contain one or more physical or logical ports; 964 (b) can advertise itself as one or more "virtual" 965 authenticators or peers; 966 (c) can utilize multiple CPUs; 967 (d) can support clustering services for load balancing or failover. 969 Both the EAP peer and authenticator can have more than one physical 970 or logical port. A peer can simultaneously access the network via 971 multiple authenticators, or via multiple physical or logical ports on 972 a given authenticator. Similarly, an authenticator can offer network 973 access to multiple peers, each via a separate physical or logical 974 port. When a single physical authenticator advertises itself as 975 multiple virtual authenticators, it is possible for a single physical 976 port to belong to multiple virtual authenticators. 978 An authenticator can be configured to communicate with more than one 979 EAP server, each of which is configured to communicate with a subset 980 of the authenticators. The situation is illustrated in Figure 3. 982 2.3. Authenticator Identification 984 The EAP method conversation is between the EAP peer and server. The 985 authenticator identity, if considered at all by the EAP method, is 986 treated as an opaque blob for the purpose of Channel Binding (see 987 Section 5.3.3). However, the authenticator identity is important in 988 two other exchanges - the AAA protocol exchange and the Secure 989 Association Protocol conversation. 991 The AAA conversation is between the EAP authenticator and the backend 992 authentication server. From the point of view of the backend 993 authentication server, keying material and parameters are transported 994 to the EAP authenticator identified by the NAS-Identifier attribute. 995 Since an EAP authenticator MUST NOT share EAP keying material or 996 parameters with another party, if the EAP peer or backend 997 authentication server detects use of EAP keying material and 998 parameters outside the scope defined by the NAS-Identifier, the 999 keying material MUST be considered compromised. 1001 The Secure Association Protocol conversation is between the peer and 1002 the authenticator. For lower layers which support key caching it is 1003 particularly important for the EAP peer, authenticator and backend 1004 server to have a consistent view of the usage scope of the 1005 transported keying material. In order to enable this, it is 1006 RECOMMENDED that the Secure Association Protocol explicitly 1007 communicate the usage scope of the EAP keying material passed down to 1008 the lower layer, rather than implicitly assuming that this is defined 1009 by the authenticator and peer endpoint addresses. 1011 +-+-+-+-+ 1012 | EAP | 1013 | Peer | 1014 +-+-+-+-+ 1015 | | | Peer Ports 1016 / | \ 1017 / | \ 1018 / | \ 1019 / | \ 1020 / | \ 1021 / | \ 1022 / | \ 1023 / | \ Authenticator 1024 | | | | | | | | | Ports 1025 +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ 1026 | | | | | | 1027 | Auth1 | | Auth2 | | Auth3 | 1028 | | | | | | 1029 +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ 1030 \ | \ | 1031 \ | \ | 1032 \ | \ | 1033 EAP over AAA \ | \ | 1034 (optional) \ | \ | 1035 \ | \ | 1036 \ | \ | 1037 \ | \ | 1038 +-+-+-+-+-+ +-+-+-+-+-+ Backend 1039 | EAP | | EAP | Authentication 1040 | Server1 | | Server2 | Servers 1041 +-+-+-+-+-+ +-+-+-+-+-+ 1043 Figure 3: Relationship between EAP peer, authenticator and server 1045 Since an authenticator can have multiple ports, the scope of the 1046 authenticator key cache cannot be described by a single endpoint 1047 address. Similarly, where a peer can have multiple ports and sharing 1048 of EAP keying material and parameters between peer ports of the same 1049 link type is allowed, the extent of the peer key cache cannot be 1050 communicated by using a single endpoint address. Instead, it is 1051 RECOMMENDED that the EAP peer and authenticator consistently identify 1052 themselves utilizing explicit identifiers, rather than endpoint 1053 addresses or port identifiers. 1055 AAA protocols such as RADIUS [RFC3579] and Diameter [RFC4072] provide 1056 a mechanism for the identification of AAA clients; since the EAP 1057 authenticator and AAA client MUST be co-resident, this mechanism is 1058 applicable to the identification of EAP authenticators. 1060 RADIUS [RFC2865] requires that an Access-Request packet contain one 1061 or more of the NAS-Identifier, NAS-IP-Address and NAS-IPv6-Address 1062 attributes. Since a NAS can have more than one IP address, the NAS- 1063 Identifier attribute is RECOMMENDED for explicit identification of 1064 the authenticator, both within the AAA protocol exchange and the 1065 Secure Association Protocol conversation. 1067 Problems which can arise where the peer and authenticator implicitly 1068 identify themselves using endpoint addresses include the following: 1070 (a) It is possible that the peer will not be able to determine which 1071 authenticator ports are associated with which authenticators. As a 1072 result, the EAP peer will be unable to utilize the authenticator 1073 key cache in an efficient way, and will also be unable to determine 1074 whether EAP keying material has been shared outside its authorized 1075 scope, and therefore needs to be considered compromised. 1077 (b) It is possible that the authenticator will not be able to determine 1078 which peer ports are associated with which peers, preventing the 1079 peer from communicating with it utilizing multiple peer ports. 1081 (c) It is possible that the peer will not be able to determine which 1082 virtual authenticator it is communicating with. For example, 1083 multiple virtual authenticators can share a MAC address, but 1084 utilize different NAS-Identifiers. 1086 (d) It is possible that the authenticator will not be able to determine 1087 which virtual peer it is communicating with. Multiple virtual 1088 peers can share a MAC address, but utilize different Peer-Ids. 1090 (e) It is possible that the EAP peer and server will not be able to 1091 verify the authenticator identity via Channel Binding. 1093 For example, problems (a), (c) and (e) occur in [IEEE-802.11], which 1094 utilizes peer and authenticator MAC addresses within the 4-way 1095 handshake. Problems (b) and (d) do not occur since [IEEE-802.11] 1096 only allows a virtual peer to utilize a single port. 1098 The following steps enable lower layer identities to be securely 1099 verified by all parties: 1101 (f) Specify the lower layer parameters used to identify the 1102 authenticator and peer. As noted earlier, endpoint or port 1103 identifiers are not recommended for identification of the 1104 authenticator or peer when it is possible for them to have multiple 1105 ports. 1107 (g) Communicate the lower layer identities between the peer and 1108 authenticator within phase 0. This allows the peer and 1109 authenticator to determine the key scope if a key cache is 1110 utilized. 1112 (h) Communicate the lower layer authenticator identity between the 1113 authenticator and backend server within the NAS-Identifier 1114 attribute. 1116 (i) Include the lower layer identities within Channel Bindings (if 1117 supported) in phase 1a, ensuring that they are communicated between 1118 the EAP peer and server. 1120 (j) Support the integrity-protected exchange of identities within phase 1121 2a. 1123 (k) Utilize the advertised lower layer identities to enable the peer 1124 and authenticator to verify that keys are maintained within the 1125 advertised scope. 1127 2.3.1. Virtual Authenticators 1129 When a single physical authenticator advertises itself as multiple 1130 virtual authenticators, if the virtual authenticators do not maintain 1131 logically separate key caches, then by authenticating to one virtual 1132 authenticator, the peer can gain access to the other virtual 1133 authenticators sharing a key cache. 1135 For example, where a physical authenticator implements "Guest" and 1136 "Corporate Intranet" virtual authenticators, an attacker acting as a 1137 peer could authenticate with the "Guest" virtual authenticator and 1138 derive EAP keying material. If the "Guest" and "Corporate Intranet" 1139 virtual authenticators share a key cache, then the peer can utilize 1140 the EAP keying material derived for the "Guest" network to obtain 1141 access to the "Corporate Intranet" network. 1143 The following steps can be taken to mitigate this vulnerability: 1145 (a) Authenticators are REQUIRED to cache associated authorizations 1146 along with EAP keying material and parameters and to apply 1147 authorizations to the peer on each network access, regardless of 1148 which virtual authenticator is being accessed. This ensures that 1149 an attacker cannot obtain elevated privileges even where the key 1150 cache is shared between virtual authenticators, and a peer obtains 1151 access to one virtual authenticator utilizing a key cache entry 1152 created for use with another virtual authenticator. 1154 (b) It is RECOMMENDED that physical authenticators maintain separate 1155 key caches for each virtual authenticator. This ensures that a 1156 cache entry created for use with one virtual authenticator cannot 1157 be used for access to another virtual authenticator. Since a key 1158 cache entry can no longer be shared between virtual 1159 authentications, this step provides protection beyond that offered 1160 in (a). This is valuable in situations where authorizations are 1161 not used to enforce access limitations. For example, where access 1162 is limited using a filter installed on a router rather than using 1163 authorizations provided to the authenticator, a peer can gain 1164 unauthorized access to resources by exploiting a shared key cache 1165 entry. 1167 (c) It is RECOMMENDED that each virtual authenticator identify itself 1168 consistently to the peer and to the backend authentication server, 1169 so as to enable the peer to verify the authenticator identity via 1170 Channel Binding (see Section 5.3.3). 1172 (d) It is RECOMMENDED that each virtual authenticator identify itself 1173 distinctly, in order to enable the peer and backend server to tell 1174 them apart. For example, this can be accomplished by utilizing a 1175 distinct NAS-Identifier attribute. 1177 2.4. Peer Identification 1179 As described in [RFC3748] Section 7.3, the peer identity provided in 1180 the EAP-Response/Identity can be different from the peer identities 1181 authenticated by the EAP method. For example, the identity provided 1182 in the EAP-Response/Identity can be a privacy identifier as described 1183 in "The Network Access Identifier" [RFC4282] Section 2. As noted in 1184 [RFC4284], it is also possible to utilize a Network Access Identifier 1185 (NAI) for the purposes of source routing; an NAI utilized for source 1186 routing is said to be "decorated" as described in [RFC4282] Section 1187 2.7. 1189 When EAP peer provides the Network Access Identity (NAI) within the 1190 EAP-Response/Identity, as described in [RFC3579], the authenticator 1191 copies the NAI included in the EAP-Response/Identity into the User- 1192 Name attribute included within the Access-Request. As the Access- 1193 Request is forwarded toward the backend authentication server, AAA 1194 proxies remove decoration from the NAI included in the User-Name 1195 Attribute; the NAI included within the EAP-Response/Identity 1196 encapsulated in the Access-Request remains unchanged. As a result, 1197 when the Access-Request arrives at the backend authentication server, 1198 the EAP-Response/Identity can differ from the User-Name Attribute 1199 (which can have some or all of the decoration removed). In the 1200 absence of a Peer-Id, the backend authentication server SHOULD use 1201 the contents of the User-Name Attribute, rather than the EAP- 1202 Response/Identity as the peer identity. 1204 It is possible for more than one Peer-Id to be exported by an EAP 1205 method. For example, a peer certificate can contain more than one 1206 peer identity; in a tunnel method peer identities can be 1207 authenticated both within an outer and inner exchange and these 1208 identities could be different in type and contents. For example, an 1209 outer exchange could provide a Peer-Id in the form of an RDN, whereas 1210 an inner exchange could identify the peer via its NAI or MAC address. 1211 Where EAP keying material is determined solely from the outer 1212 exchange, only the outer Peer-Id(s) are exported; where the EAP 1213 keying material is determined from both the inner and outer 1214 exchanges, then both the inner and outer Peer-Id(s) are exported by 1215 the tunnel method. 1217 2.5. Server Identification 1219 It is possible for more than one Server-Id to be exported by an EAP 1220 method. For example, a server certificate can contain more than one 1221 server identity; in a tunnel method server identities could be 1222 authenticated both within an outer and inner exchange and these 1223 identities could be different in type and contents. For example, an 1224 outer exchange could provide a Server-Id in the form of an IP 1225 address, whereas an inner exchange could identify the server via its 1226 FQDN or hostname. Where EAP keying material is determined solely 1227 from the outer exchange, only the outer Server-Id(s) are exported by 1228 the EAP method; where the EAP keying material is determined from both 1229 the inner and outer exchanges, then both the inner and outer Server- 1230 Id(s) are exported by the EAP method. 1232 As shown in Figure 3, an authenticator can be configured to 1233 communicate with multiple EAP servers; the EAP server that an 1234 authenticator communicates with can vary according to configuration 1235 and network and server availability. While the EAP peer can assume 1236 that all EAP servers within a realm have access to the credentials 1237 necessary to validate an authentication attempt, it cannot assume 1238 that all EAP servers share persistent state. 1240 Authenticators can be configured with different primary or secondary 1241 EAP servers, in order to balance the load. Also, the authenticator 1242 can dynamically determine the EAP server to which requests will be 1243 sent; in event of a communication failure, the authenticator can fail 1244 over to another EAP server. For example, in Figure 3, Authenticator2 1245 can be initially configured with EAP server1 as its primary backend 1246 authentication server, and EAP server2 as the backup, but if EAP 1247 server1 becomes unavailable, EAP server2 can become the primary 1248 server. 1250 In general, the EAP peer cannot direct an authentication attempt to a 1251 particular EAP server within a realm; this decision is made by AAA 1252 clients. Nor can the peer determine which EAP server it will be 1253 communicating with, prior to the start of the EAP method 1254 conversation. The Server-Id is not included in the EAP- 1255 Request/Identity, and since the EAP server may be determined 1256 dynamically, it typically is not possible for the authenticator to 1257 advertise the Server-Id during the discovery phase. Some EAP methods 1258 do not export the Server-Id so that is is possible that the EAP peer 1259 will not learn which server it was conversing with after the EAP 1260 conversation completes successfully. 1262 As a result, an EAP peer, on connecting to a new authenticator or 1263 reconnecting to the same authenticator, can find itself communicating 1264 with a different EAP server. Fast reconnect, defined in [RFC3748] 1265 Section 7.2, can fail if the EAP server that the peer communicates 1266 with is not the same one with which it initially established a 1267 security association. For example, an EAP peer attempting an EAP-TLS 1268 session resume can find that the new EAP-TLS server will not have 1269 access to the TLS Master Key identified by the TLS Session-Id, and 1270 therefore the session resumption attempt will fail, requiring 1271 completion of a full EAP-TLS exchange. 1273 EAP methods that export the Server-Id MUST authenticate the server. 1274 However, not all EAP methods supporting mutual authentication provide 1275 a non-null Server-Id; some methods only enable the EAP peer to verify 1276 that the EAP server possesses a long-term secret, but do not provide 1277 the identity of the EAP server. In this case the EAP peer will know 1278 that an authenticator has been authorized by an EAP server, but will 1279 not confirm the identity of the EAP server. Where the EAP method 1280 does not provide a Server-Id, the peer cannot identify the EAP server 1281 with which it generated keying material. This can make it difficult 1282 for the EAP peer to identify the location of a key possessed by that 1283 EAP server. 1285 As noted in [I-D.simon-emu-rfc2716bis] Section 5.2, EAP methods 1286 supporting authentication using server certificates can determine the 1287 Server-Id from the subject or subjectAltName fields in the server 1288 certificate. Validating the EAP server identity can help the EAP 1289 peer to decide whether a specific EAP server is authorized. In some 1290 cases, such as where the certificate extensions defined in [RFC4334] 1291 are included in the server certificate, it can even be possible for 1292 the peer to verify some Channel Binding parameters from the server 1293 certificate. 1295 It is possible for problems to arise in situations where the EAP 1296 server identifies itself differently to the EAP peer and 1297 authenticator. For example, it is possible that the Server-Id 1298 exported by EAP methods will not be identical to the Fully Qualified 1299 Domain Name (FQDN) of the backend authentication server. Where 1300 certificate-based authentication is used within RADIUS or Diameter, 1301 it is possible that the subjectAltName used in the backend 1302 authentication server certificate will not be identical to the 1303 Server-Id or backend authentication server FQDN. This is not 1304 normally an issue in EAP, as the authenticator will be unaware of the 1305 identities used between the EAP peer and server. However, this can 1306 be an issue for key caching, if the authenticator is expected to 1307 locate a backend authentication server corresponding to a Server-Id 1308 provided by an EAP peer. 1310 Where the backend authentication server FQDN differs from the 1311 subjectAltName in the backend authentication server certificate, it 1312 is possible that the AAA client will not be able to determine whether 1313 it is talking to the correct backend authentication server. Where 1314 the Server-Id and backend server FQDN differ, it is possible that the 1315 combination of the key scope (Peer-Id(s), Server- Id(s)) and EAP 1316 conversation identifier (Session-Id) will not be sufficient to 1317 determine where the key resides. For example, the authenticator can 1318 identify backend servers by their IP address (as occurs in RADIUS), 1319 or using a Fully Qualified Domain Name (as in Diameter). If the 1320 Server-Id does not correspond to the IP address or FQDN of a known 1321 backend authentication server, then it may not be possible to locate 1322 which backend authentication server possesses the key. 1324 3. Security Association Management 1326 EAP as defined in [RFC3748] supports key derivation, but does not 1327 provide for the management of lower layer security associations. 1328 Missing functionality includes: 1330 (a) Security Association negotiation. EAP does not negotiate lower 1331 layer unicast or multicast security associations, including 1332 cryptographic algorithms or traffic profiles. EAP methods only 1333 negotiate cryptographic algorithms for their own use, not for the 1334 underlying lower layers. EAP also does not negotiate the traffic 1335 profiles to be protected with the negotiated ciphersuites; in some 1336 cases the traffic to be protected can have lower layer source and 1337 destination addresses different from the lower layer peer or 1338 authenticator addresses. 1340 (b) Re-key. EAP does not support re-key of exported EAP keying 1341 material without EAP re-authentication, although EAP methods can 1342 support "fast reconnect" as defined in [RFC3748] Section 7.2.1. 1344 (c) Key delete/install semantics. EAP does not synchronize 1345 installation or deletion of keying material on the EAP peer and 1346 authenticator. 1348 (d) Lifetime negotiation. EAP does not support lifetime negotiation 1349 for exported EAP keying material, and existing EAP methods also do 1350 not support key lifetime negotiation. 1352 (e) Guaranteed TSK freshness. Without a post-EAP handshake, TSKs can 1353 be reused if EAP keying material is cached. 1355 These deficiencies are typically addressed via a post-EAP handshake 1356 known as the Secure Association Protocol. 1358 3.1. Secure Association Protocol 1360 Since neither EAP nor EAP methods provide for establishment of lower 1361 layer security associations, it is RECOMMENDED that these facilities 1362 be provided within the Secure Association Protocol, including: 1364 (a) Entity Naming. A basic feature of a Secure Association Protocol is 1365 the explicit naming of the parties engaged in the exchange. 1366 Without explicit identification, the parties engaged in the 1367 exchange are not identified and the scope of the EAP keying 1368 parameters negotiated during the EAP exchange is undefined. 1370 (b) Mutual proof of possession of EAP keying material. During the 1371 Secure Association Protocol the EAP peer and authenticator MUST 1372 demonstrate possession of the keying material transported between 1373 the backend authentication server and authenticator (e.g. MSK), in 1374 order to demonstrate that the peer and authenticator have been 1375 authorized. Since mutual proof of possession is not the same as 1376 mutual authentication, the peer cannot verify authenticator 1377 assertions (including the authenticator identity) as a result of 1378 this exchange. Authenticator identity verification is discussed in 1379 Section 2.3. 1381 (c) Secure capabilities negotiation. In order to protect against 1382 spoofing during the discovery phase, ensure selection of the "best" 1383 ciphersuite, and protect against forging of negotiated security 1384 parameters, the Secure Association Protocol MUST support secure 1385 capabilities negotiation. This includes the secure negotiation of 1386 usage modes, session parameters (such as security association 1387 identifiers (SAIDs) and key lifetimes), ciphersuites and required 1388 filters, including confirmation of security-relevant capabilities 1389 discovered during phase 0. The Secure Association Protocol MUST 1390 support integrity and replay protection of all capability 1391 negotiation messages. 1393 (d) Key naming and selection. Where key caching is supported, it is 1394 possible for the EAP peer and authenticator to share more than one 1395 key of a given type. As a result, the Secure Association Protocol 1396 MUST explicitly name the keys used in the proof of possession 1397 exchange, so as to prevent confusion when more than one set of 1398 keying material could potentially be used as the basis for the 1399 exchange. Use of the key naming mechanism described in Section 1400 1.4.1 is RECOMMENDED. 1402 In order to support the correct processing of phase 2 security 1403 associations, the Secure Association (phase 2) protocol MUST 1404 support the naming of phase 2 security associations and associated 1405 transient session keys, so that the correct set of transient 1406 session keys can be identified for processing a given packet. The 1407 phase 2 Secure Association Protocol also MUST support transient 1408 session key activation and SHOULD support deletion, so that 1409 establishment and re-establishment of transient session keys can be 1410 synchronized between the parties. 1412 (e) Generation of fresh transient session keys (TSKs). Where the lower 1413 layer supports caching of keying material, the EAP peer lower layer 1414 can initiate a new session using keying material that was derived 1415 in a previous session. Were the TSKs to be derived solely from a 1416 portion of the exported EAP keying material, this would result in 1417 reuse of the session keys which could expose the underlying 1418 ciphersuite to attack. 1420 In lower layers where caching of keying material is supported, the 1421 Secure Association Protocol phase is REQUIRED, and MUST support the 1422 derivation of fresh unicast and multicast TSKs, even when the 1423 transported keying material provided by the backend authentication 1424 server is not fresh. This is typically supported via the exchange 1425 of nonces or counters, which are then mixed with the keying 1426 material in order to generate fresh unicast (phase 2a) and possibly 1427 multicast (phase 2b) session keys. By not using exported EAP 1428 keying material directly to protect data, the Secure Association 1429 Protocol protects it against compromise. 1431 (f) Key lifetime management. This includes explicit key lifetime 1432 negotiation or seamless re-key. EAP does not support re-key of EAP 1433 keying material without re-authentication and existing EAP methods 1434 do not support key lifetime negotiation. As a result, the Secure 1435 Association Protocol MAY handle re-key and determination of the key 1436 lifetime. Where key caching is supported, secure negotiation of 1437 key lifetimes is RECOMMENDED. Lower layers that support re-key, 1438 but not key caching, may not require key lifetime negotiation. For 1439 example, a difference between IKEv1 [RFC2409] and IKEv2 [RFC4306] 1440 is that in IKEv1 SA lifetimes were negotiated; in IKEv2, each end 1441 of the SA is responsible for enforcing its own lifetime policy on 1442 the SA and re-keying the SA when necessary. 1444 (g) Key state resynchronization. It is possible for the peer or 1445 authenticator to reboot or reclaim resources, clearing portions or 1446 all of the key cache. Therefore, key lifetime negotiation cannot 1447 guarantee that the key cache will remain synchronized, and it may 1448 not be possible for the peer to determine before attempting to use 1449 a key whether it exists within the authenticator cache. It is 1450 therefore RECOMMENDED for the EAP lower layer to provide a 1451 mechanism for key state resynchronization, either via the SAP or 1452 using a lower layer indication (see [RFC3748] Section 3.4). Where 1453 the peer and authenticator do not jointly possess a key with which 1454 to protect the resynchronization exchange, secure resynchronization 1455 is not possible and alternatives (such as a initiation of EAP re- 1456 authentication after expiration of a timer) is needed to ensure 1457 timely resynchronization. 1459 (h) Key scope synchronization. To support key scope determination, the 1460 Secure Association Protocol SHOULD provide a mechanism by which the 1461 peer can determine the scope of the key cache on each 1462 authenticator, and by which the authenticator can determine the 1463 scope of the key cache on a peer. This includes negotiation of 1464 restrictions on key usage. 1466 (i) Traffic profile negotiation. The traffic to be protected by a 1467 lower layer security association will not necessarily have the same 1468 lower layer source or destination address as the EAP peer and 1469 authenticator, and it is possible for the peer and authenticator to 1470 negotiate multiple security associations, each with a different 1471 traffic profile. Where this is the case, the profile of protected 1472 traffic SHOULD be explicitly negotiated. For example, in IKEv2 it 1473 is possible for an Initiator and Responder to utilize EAP for 1474 authentication, then negotiate a Tunnel Mode Security Association 1475 (SA) which permits passing of traffic originating from hosts other 1476 than the Initiator and Responder. Similarly, in IEEE 802.16e a 1477 Subscriber Station (SS) can forward traffic to the Base Station 1478 (BS) which originates from the Local Area Network (LAN) to which it 1479 is attached. To enable this, Security Associations within IEEE 1480 802.16e are identified by the Connection Identifier (CID), not by 1481 the EAP peer and authenticator MAC addresses. In both IKEv2 and 1482 IEEE 802.16e, multiple security associations can exist between the 1483 EAP peer and authenticator, each with their own traffic profile and 1484 quality of service parameters. 1486 (j) Direct operation. Since the phase 2 Secure Association Protocol is 1487 concerned with the establishment of security associations between 1488 the EAP peer and authenticator, including the derivation of 1489 transient session keys, only those parties have "a need to know" 1490 the transient session keys. The Secure Association Protocol MUST 1491 operate directly between the peer and authenticator, and MUST NOT 1492 be passed-through to the backend authentication server, or include 1493 additional parties. 1495 (k) Bi-directional operation. While some ciphersuites only require a 1496 single set of transient session keys to protect traffic in both 1497 directions, other ciphersuites require a unique set of transient 1498 session keys in each direction. The phase 2 Secure Association 1499 Protocol SHOULD provide for the derivation of unicast and multicast 1500 keys in each direction, so as not to require two separate phase 2 1501 exchanges in order to create a bi-directional phase 2 security 1502 association. See [RFC3748] Section 2.4 for more discussion. 1504 3.2. Key Scope 1506 Absent explicit specification within the lower layer, after the 1507 completion of phase 1b, transported keying material and parameters 1508 are bound to the EAP peer and authenticator, but are not bound to a 1509 specific peer or authenticator port. 1511 While EAP keying material passed down to the lower layer is not 1512 intrinsically bound to particular authenticator and peer ports, TSKs 1513 MAY be bound to particular authenticator and peer ports by the Secure 1514 Association Protocol. However, a lower layer MAY also permit TSKs to 1515 be used on multiple peer and/or authenticator ports, providing that 1516 TSK freshness is guaranteed (such as by keeping replay counter state 1517 within the authenticator). 1519 In order to further limit the key scope the following measures are 1520 suggested: 1522 (a) The lower layer MAY specify additional restrictions on key usage, 1523 such as limiting the use of EAP keying material and parameters on 1524 the EAP peer to the port over which on the EAP conversation was 1525 conducted. 1527 (b) The backend authentication server and authenticator MAY implement 1528 additional attributes in order to further restrict the scope of 1529 keying material. For example, in IEEE 802.11, the backend 1530 authentication server can provide the authenticator with a list of 1531 authorized Called or Calling-Station-Ids and/or SSIDs for which 1532 keying material is valid. 1534 (c) Where the backend authentication server provides attributes 1535 restricting the key scope, it is RECOMMENDED that restrictions be 1536 securely communicated by the authenticator to the peer. This can 1537 be accomplished using the Secure Association Protocol, but also 1538 can be accomplished via the EAP method or the lower layer. 1540 3.3. Parent-Child Relationships 1542 When an EAP re-authentication takes place, new EAP keying material is 1543 exported by the EAP method. In EAP lower layers where EAP re- 1544 authentication eventually results in TSK replacement, the maximum 1545 lifetime of derived keying material (including TSKs) can be less than 1546 or equal to that of EAP keying material (MSK/EMSK), but it cannot be 1547 greater. 1549 Where TSKs are derived from or are wrapped by exported EAP keying 1550 material, compromise of that exported EAP keying material implies 1551 compromise of TSKs. Therefore if EAP keying material is considered 1552 stale, not only SHOULD EAP re-authentication be initiated, but also 1553 replacement of child keys, including TSKs. 1555 Where EAP keying material is used only for entity authentication but 1556 not for TSK derivation (as in IKEv2), compromise of exported EAP 1557 keying material does not imply compromise of the TSKs. Nevertheless, 1558 the compromise of EAP keying material could enable an attacker to 1559 impersonate an authenticator, so that EAP re-authentication and TSK 1560 re-key are RECOMMENDED. 1562 With respect to IKEv2, "IKEv2 Clarifications and Implementation 1563 Guidelines" [RFC4718] Section 5.2 states: 1565 Rekeying the IKE-SA and reuathentication are different concepts in 1566 IKEv2. Rekeying the IKE_SA establishes new keys for the IKE_SA 1567 and resets the Message ID counters, but it does not authenticate 1568 the parties again (no AUTH or EAP payloads are involved)... This 1569 means that reauthentication also establishes new keys for the 1570 IKE_SA and CHILD_SAs. Therefore while rekeying can be performed 1571 more often than reauthentication, the situation where 1572 "authentication lifetime" is shorter than "key lifetime" does not 1573 make sense. 1575 Child keys that are used frequently (such as TSKs which are used for 1576 traffic protection) can expire sooner than the exported EAP keying 1577 material they are dependent on, so that it is advantageous to support 1578 re-key of child keys prior to EAP re-authentication. Note that 1579 deletion of the MSK/EMSK does not necessarily imply deletion of TSKs 1580 or child keys. 1582 Failure to mutually prove possession of exported EAP keying material 1583 during the Secure Association Protocol exchange need not be grounds 1584 for deletion of keying material by both parties; rate-limiting Secure 1585 Association Protocol exchanges could be used to prevent a brute force 1586 attack. 1588 3.4. Local Key Lifetimes 1590 The Transient EAP Keys (TEKs) are session keys used to protect the 1591 EAP conversation. The TEKs are internal to the EAP method and are 1592 not exported. TEKs are typically created during an EAP conversation, 1593 used until the end of the conversation and then discarded. However, 1594 methods can re-key TEKs during an EAP conversation. 1596 When using TEKs within an EAP conversation or across conversations, 1597 it is necessary to ensure that replay protection and key separation 1598 requirements are fulfilled. For instance, if a replay counter is 1599 used, TEK re-key MUST occur prior to wrapping of the counter. 1600 Similarly, TSKs MUST remain cryptographically separate from TEKs 1601 despite TEK re-keying or caching. This prevents TEK compromise from 1602 leading directly to compromise of the TSKs and vice versa. 1604 EAP methods MAY cache local EAP keying material (TEKs) which can 1605 persist for multiple EAP conversations when fast reconnect is used 1606 [RFC3748]. For example, EAP methods based on TLS (such as EAP-TLS 1607 [I-D.simon-emu-rfc2716bis]) derive and cache the TLS Master Secret, 1608 typically for substantial time periods. The lifetime of other local 1609 EAP keying material calculated within the EAP method is defined by 1610 the method. Note that in general, when using fast reconnect, there 1611 is no guarantee to that the original long-term credentials are still 1612 in the possession of the peer. For instance, a smart-card holding 1613 the private key for EAP-TLS can have been removed. EAP servers 1614 SHOULD also verify that the long-term credentials are still valid, 1615 such as by checking that certificate used in the original 1616 authentication has not yet expired. 1618 3.5. Exported and Calculated Key Lifetimes 1620 The following mechanisms are available for communicating the lifetime 1621 of keying material between the EAP peer, server and authenticator: 1623 AAA protocols (backend server and authenticator) 1624 Lower layer mechanisms (authenticator and peer) 1625 EAP method-specific negotiation (peer and server) 1627 Where the EAP method does not support the negotiation of the lifetime 1628 of exported EAP keying material, and a key lifetime negotiation 1629 mechanism is not provided by the lower layer, it is possible that 1630 there will not be a way for the peer to learn the lifetime of keying 1631 material. This can leave the peer uncertain how long the 1632 authenticator will maintain keying material within the key cache. In 1633 this case the lifetime of keying material can be managed as a system 1634 parameter on the peer and authenticator; a default lifetime of 8 1635 hours is RECOMMENDED. 1637 3.5.1. AAA Protocols 1639 AAA protocols such as RADIUS [RFC2865] and Diameter [RFC4072] can be 1640 used to communicate the maximum key lifetime from the backend 1641 authentication server to the authenticator. 1643 The Session-Timeout attribute is defined for RADIUS in [RFC2865] and 1644 for Diameter in [RFC4005]. Where EAP is used for authentication, 1645 [RFC3580] Section 3.17 indicates that a Session-Timeout attribute 1646 sent in an Access-Accept along with a Termination-Action value of 1647 RADIUS-Request specifies the maximum number of seconds of service 1648 provided prior to EAP re-authentication. 1650 However, there is also a need to be able to specify the maximum 1651 lifetime of cached keying material. Where EAP pre-authentication is 1652 supported, cached keying material can be pre-established on the 1653 authenticator prior to session start, and will remain there until 1654 expiration. EAP lower layers supporting caching of keying material 1655 MAY also persist that material after the end of a session, enabling 1656 the peer to subsequently resume communication utilizing the cached 1657 keying material. In these situations it can be desirable for the 1658 backend authentication server to specify the maximum lifetime of 1659 cached keying material. 1661 To accomplish this, [IEEE-802.11] overloads the Session-Timeout 1662 attribute, assuming that it represents the maximum time after which 1663 transported keying material will expire on the authenticator, 1664 regardless of whether transported keying material is cached. 1666 An IEEE 802.11 authenticator receiving transported keying material is 1667 expected to initialize a timer to the Session-Timeout value, and once 1668 the timer expires, the transported keying material expires. Whether 1669 this results in session termination or EAP re-authentication is 1670 controlled by the value of the Termination-Action attribute. Where 1671 EAP re-authentication occurs the transported keying material is 1672 replaced, and with it, new calculated keys are put in place. Where 1673 session termination occurs, transported and derived keying material 1674 is deleted. 1676 Overloading the Session-Timeout attribute is problematic in 1677 situations where it is necessary to control the maximum session time 1678 and key lifetime independently. For example, it might be desirable 1679 to limit the lifetime of cached keying material to 5 minutes while 1680 permitting a user once authenticated to remain connected for up to an 1681 hour without re-authenticating. As a result, in the future 1682 additional attributes can be specified to control the lifetime of 1683 cached keys; these attributes MAY modify the meaning of the Session- 1684 Timeout attribute in specific circumstances. 1686 Since the TSK lifetime is often determined by authenticator 1687 resources, and the backend authentication server has no insight into 1688 the TSK derivation process, by the principle of ciphersuite 1689 independence, it is not appropriate for the backend authentication 1690 server to manage any aspect of the TSK derivation process, including 1691 the TSK lifetime. 1693 3.5.2. Lower Layer Mechanisms 1695 Lower layer mechanisms can be used to enable the lifetime of keying 1696 material to be negotiated between the peer and authenticator. This 1697 can be accomplished either using the Secure Association Protocol or 1698 within the lower layer transport. 1700 Where TSKs are established as the result of a Secure Association 1701 Protocol exchange, it is RECOMMENDED that the Secure Association 1702 Protocol include support for TSK re-key. Where the TSK is taken 1703 directly from the MSK, there is no need to manage the TSK lifetime as 1704 a separate parameter, since the TSK lifetime and MSK lifetime are 1705 identical. 1707 3.5.3. EAP Method-Specific Negotiation 1709 As noted in [RFC3748] Section 7.10: 1711 In order to provide keying material for use in a subsequently 1712 negotiated ciphersuite, an EAP method supporting key derivation 1713 MUST export a Master Session Key (MSK) of at least 64 octets, and 1714 an Extended Master Session Key (EMSK) of at least 64 octets. EAP 1715 Methods deriving keys MUST provide for mutual authentication 1716 between the EAP peer and the EAP Server. 1718 However, EAP does not itself support the negotiation of lifetimes for 1719 exported EAP keying material such as the MSK, EMSK and IV. 1721 While EAP itself does not support lifetime negotiation, it would be 1722 possible to specify methods that do. However, systems that rely on 1723 key lifetime negotiation within EAP methods would only function with 1724 these methods. Also, there is no guarantee that the key lifetime 1725 negotiated within the EAP method would be compatible with backend 1726 authentication server policy. In the interest of method independence 1727 and compatibility with backend server implementations, management of 1728 the lifetime of keying material SHOULD NOT be provided within EAP 1729 methods. 1731 3.6. Key Cache Synchronization 1733 Key lifetime negotiation alone cannot guarantee key cache 1734 synchronization. Even where a lower layer exchange is run 1735 immediately after EAP in order to determine the lifetime of keying 1736 material, it is still possible for the authenticator to purge all or 1737 part of the key cache prematurely (e.g. due to reboot or need to 1738 reclaim memory). 1740 The lower layer can utilize the Discovery phase 0 to improve key 1741 cache synchronization. For example, if the authenticator manages the 1742 key cache by deleting the oldest key first, the relative creation 1743 time of the last key to be deleted could be advertised within the 1744 Discovery phase, enabling the peer to determine whether keying 1745 material had been prematurely expired from the authenticator key 1746 cache. 1748 3.7. Key Strength 1750 As noted in Section 2.1, EAP lower layers determine TSKs in different 1751 ways. Where exported EAP keying material is utilized in the 1752 derivation, encryption or authentication of TSKs, it is possible for 1753 EAP key generation to represent the weakest link. 1755 In order to ensure that methods produce EAP keying material of an 1756 appropriate symmetric key strength, it is RECOMMENDED that EAP 1757 methods utilizing public key cryptography choose a public key that 1758 has a cryptographic strength providing the required level of attack 1759 resistance. This is typically provided by configuring EAP methods, 1760 since there is no coordination between the lower layer and EAP method 1761 with respect to minimum required symmetric key strength. 1763 BCP 86 [RFC3766] Section 5 offers advice on the required RSA or DH 1764 module and DSA subgroup size in bits, for a given level of attack 1765 resistance in bits. The National Institute for Standards and 1766 Technology (NIST) also offers advice on appropriate key sizes in 1767 [SP800-57]. 1769 3.8. Key Wrap 1771 The key wrap specified in [RFC2548], which is based on an MD5-based 1772 stream cipher, has known problems, as described in [RFC3579] Section 1773 4.3. RADIUS uses the shared secret for multiple purposes, including 1774 per-packet authentication and attribute hiding, considerable 1775 information is exposed about the shared secret with each packet. 1776 This exposes the shared secret to dictionary attacks. MD5 is used 1777 both to compute the RADIUS Response Authenticator and the Message- 1778 Authenticator attribute, and concerns exist relating to the security 1779 of this hash [MD5Collision]. 1781 As discussed in [RFC3579] Section 4.3, the security vulnerabilities 1782 of RADIUS are extensive, and therefore development of an alternative 1783 key wrap technique based on the RADIUS shared secret would not 1784 substantially improve security. As a result, [RFC3579] Section 4.2 1785 recommends running RADIUS over IPsec. The same approach is taken in 1786 Diameter EAP [RFC4072], which defines clear-text key attributes, to 1787 be protected by IPsec or TLS. 1789 4. Handoff Vulnerabilities 1791 A handoff occurs when an EAP peer moves to a new authenticator. 1792 Several mechanisms have been proposed for reducing handoff latency 1793 within networks utilizing EAP. These include: 1795 EAP pre-authentication 1796 In EAP pre-authentication, an EAP peer pre-establishes EAP keying 1797 material with an authenticator prior to arrival. EAP pre- 1798 authentication only affects the timing of EAP authentication, but 1799 does not shorten or eliminate EAP (phase 1a) or AAA (phase 1b) 1800 exchanges; Discovery (phase 0) and Secure Association Protocol 1801 (phase 2) exchanges occur as described in Section 1.3. As a 1802 result, the primary benefit is to enable EAP authentication to be 1803 removed from the handoff critical path, thereby reducing latency. 1804 Use of EAP pre-authentication within IEEE 802.11 is described in 1805 [IEEE-802.11] and [8021XPreAuth]. 1807 Proactive key distribution 1808 In proactive key distribution, keying material and authorizations 1809 are transported from the backend authentication server to a 1810 candidate authenticator in advance of a handoff. As a result, EAP 1811 (phase 1a) is not needed, but the Discovery (phase 0), and Secure 1812 Association Protocol exchanges (phase 2) are still necessary. 1813 Within the AAA exchange (phase 1b), authorization and key 1814 distribution functions are typically supported, but not 1815 authentication. Proactive key distribution is described in 1816 [MishraPro], [IEEE-03-084] and [I-D.irtf-aaaarch-handoff]. 1818 Key caching 1819 Caching of EAP keying material enables an EAP peer to re-attach to 1820 an authenticator without requiring EAP (phase 1a) or AAA (phase 1b) 1821 exchanges. However, Discovery (phase 0) and Secure Association 1822 Protocol (phase 2) exchanges are still needed. Use of key caching 1823 within IEEE 802.11 is described in [IEEE-802.11]. 1825 Context transfer 1826 In context transfer schemes, keying material and authorizations are 1827 transferred between a previous authenticator and a new 1828 authenticator. This can occur in response to a handoff request by 1829 the EAP peer, or in advance, as in proactive key distribution. As 1830 a result, EAP (phase 1a) is eliminated, but not the Discovery 1831 (phase 0) or Secure Association Protocol exchanges (phase 2). If a 1832 secure channel can be established between the new and previous 1833 authenticator without assistance from the backend authentication 1834 server, then the AAA exchange (phase 1b) can be eliminated; 1835 otherwise, it is still needed, although it can be shortened. 1836 Context transfer protocols are described in [IEEE-802.11F] (now 1837 deprecated) and "Context Transfer Protocol (CXTP)" [RFC4067]. 1838 "Fast Authentication Methods for Handovers between IEEE 802.11 1839 Wireless LANs" [Bargh] analyzes fast handoff techniques, including 1840 context transfer mechanisms. 1842 Token distribution 1843 In token distribution schemes the EAP peer is provided with a 1844 credential, subsequently enabling it to authenticate with one or 1845 more additional authenticators. During the subsequent 1846 authentications, EAP (phase 1a) is eliminated or shortened; the 1847 Discovery (phase 0) and Secure Association Protocol exchanges 1848 (phase 2) still occur, although the latter can be shortened. If 1849 the token includes authorizations and can be validated by an 1850 authenticator without assistance from the backend authentication 1851 server, then the AAA exchange (phase 1b) can be eliminated; 1852 otherwise it is still needed, although it can be shortened. Token- 1853 based schemes, initially proposed in early drafts of IEEE 802.11i 1854 [IEEE-802.11i], are described in [Token], [Tokenk] and 1855 [I-D.friedman-ike-short-term-certs]. 1857 The sections that follow discuss the security vulnerabilities 1858 introduced by the above schemes. 1860 4.1. EAP Pre-authentication 1862 EAP pre-authentication differs from a normal EAP conversation 1863 primarily with respect to the lower layer encapsulation. For 1864 example, in [IEEE-802.11], EAP pre-authentication frames utilize a 1865 distinct Ethertype, but otherwise conforms to the encapsulation 1866 described in [IEEE-802.1X]. As a result, an EAP pre-authentication 1867 conversation differs little from the model described in Section 1.3, 1868 other than the introduction of a delay between phase 1 and phase 2. 1870 EAP pre-authentication relies on lower layer mechanisms for discovery 1871 of candidate authenticators. Where discovery can provide information 1872 on candidate authenticators outside the immediate listening range, 1873 and the peer can determine whether it already possesses valid EAP 1874 keying material with candidate authenticators, the peer can avoid 1875 unnecessary EAP pre-authentications and can establish EAP keying 1876 material well in advance, regardless of the coverage overlap between 1877 authenticators. However, if the peer can only discover candidate 1878 authenticators within listening range and cannot determine whether it 1879 can reuse existing EAP keying material, then it is possible that the 1880 peer will not be able to complete EAP pre-authentication prior to 1881 connectivity loss or that it can pre-authenticate multiple times with 1882 the same authenticator, increasing backend authentication server 1883 load. 1885 Since a peer can complete EAP pre-authentication with an 1886 authenticator without eventually attaching to it, it is possible that 1887 phase 2 will not occur. In this case an Accounting-Request 1888 signifying the start of service will not be sent, or will only be 1889 sent with a substantial delay after the completion of authentication. 1891 As noted in "IEEE 802.1X RADIUS Usage Guidelines" [RFC3580], the AAA 1892 exchange resulting from EAP pre-authentication differs little from an 1893 ordinary exchange described in "RADIUS Support for EAP" [RFC3579]. 1894 For example, since in IEEE 802.11 [IEEE-802.11] an Association 1895 exchange does not occur prior to EAP pre-authentication, the SSID is 1896 not known by the authenticator at authentication time, so that an 1897 Access-Request cannot include the SSID within the Called-Station-Id 1898 attribute as described in [RFC3580] Section 3.20. 1900 Since only the absence of an SSID in the Called-Station-Id attribute 1901 distinguishes an EAP pre-authentication attempt, if the authenticator 1902 does not always include the SSID for a normal EAP authentication 1903 attempt, it is possible that the backend authentication server will 1904 not be able to determine whether a session constitutes an EAP pre- 1905 authentication attempt, potentially resulting in authorization or 1906 accounting problems. Where the number of simultaneous sessions is 1907 limited, the backend authentication server can refuse to authorize a 1908 valid EAP pre-authentication attempt or can enable the peer to engage 1909 in more simultaneous sessions than they are authorized for. Where 1910 EAP pre-authentication occurs with an authenticator which the peer 1911 never attaches to, it is possible that the backend accounting server 1912 will not be able to determine whether the absence of an Accounting- 1913 Request was due to packet loss or a session that never started. 1915 In order to enable pre-authentication requests to be handled more 1916 reliably, it is RECOMMENDED that AAA protocols explicitly identify 1917 EAP pre-authentication. In order to suppress unnecessary EAP pre- 1918 authentication exchanges, it is RECOMMENDED that authenticators 1919 unambiguously identify themselves as described in Section 2.3. 1921 4.2. Proactive Key Distribution 1923 In proactive key distribution schemes, the backend authentication 1924 server transports keying material and authorizations to an 1925 authenticator in advance of the arrival of the peer. The 1926 authenticators selected to receive the transported key material are 1927 selected based on past patterns of peer movement between 1928 authenticators known as the "neighbor graph". In order to reduce 1929 handoff latency, proactive key distribution schemes typically only 1930 demonstrate proof of possession of transported keying material 1931 between the EAP peer and authenticator. During a handoff, the 1932 backend authentication server is not provided with proof that the 1933 peer successfully authenticated to an authenticator; instead, the 1934 authenticator generates a stream of accounting messages without a 1935 corresponding set of authentication exchanges. As described in 1936 [MishraPro], knowledge of the neighbor graph can be established via 1937 static configuration or analysis of authentication exchanges. In 1938 order to prevent corruption of the neighbor graph, new neighbor graph 1939 entries can only be created as the result of a successful EAP 1940 exchange, and accounting packets with no corresponding authentication 1941 exchange need to be verified to correspond to neighbor graph entries 1942 (e.g. corresponding to handoffs between neighbors). 1944 In order to prevent compromise of one authenticator from resulting in 1945 compromise of other authenticators, cryptographic separation needs 1946 to be maintained between the keying material transported to each 1947 authenticator. However, even where cryptographic separation is 1948 maintained, an attacker compromising an authenticator can still 1949 disrupt the operation of other authenticators. As noted in [RFC3579] 1950 Section 4.3.7, in the absence of spoofing detection within the AAA 1951 infrastructure, it is possible for EAP authenticators to impersonate 1952 each other. By forging NAS identification attributes within 1953 authentication messages, an attacker compromising one authenticator 1954 could corrupt the neighbor graph, tricking the backend authentication 1955 server into transporting keying material to arbitrary authenticators. 1956 While this would not enable recovery of EAP keying material without 1957 breaking fundamental cryptographic assumptions, it could enable 1958 subsequent fraudulent accounting messages, or allow an attacker to 1959 disrupt service by increasing load on the backend authentication 1960 server or thrashing the authenticator key cache. 1962 Since proactive key distribution requires the distribution of derived 1963 keying material to candidate authenticators, the effectiveness of 1964 this scheme depends on the ability of backend authentication server 1965 to anticipate the movement of the EAP peer. Since proactive key 1966 distribution relies on backend authentication server knowledge of the 1967 neighbor graph it is most applicable to intra-domain handoff 1968 scenarios. However, in inter-domain handoff where there can be many 1969 authenticators, peers can frequently connect to authenticators that 1970 have not been previously encountered, making it difficult for the 1971 backend authentication server to derive a complete neighbor graph. 1973 Since proactive key distribution schemes typically require 1974 introduction of server-initiated messages as described in 1975 [RFC3576bis] and [I-D.irtf-aaaarch-handoff], security issues 1976 described in [RFC3576bis] Section 6 are applicable, including 1977 authorization (Section 6.1) and replay detection (Section 6.3) 1978 problems. 1980 4.3. AAA Bypass 1982 Fast handoff techniques which enable elimination of the AAA exchange 1983 (phase 1b) differ fundamentally from typical network access scenarios 1984 (dial-up, wired LAN, etc.) which include user authentication as well 1985 as authorization for the offered service. Where the AAA exchange 1986 (phase 1b) is omitted, authorizations and keying material are not 1987 provided by the backend authentication server, and as a result they 1988 need to be supplied by other means. This section describes some of 1989 the implications. 1991 4.3.1. Key Transport 1993 Where transported keying material is not supplied by the backend 1994 authentication server, it needs to be provided by another party 1995 authorized to access that keying material. As noted in Section 1.5, 1996 only the EAP peer, authenticator and server are authorized to possess 1997 transported keying material. Since EAP peers do not trust each 1998 other, if the backend authentication server does not supply 1999 transported keying material to a new authenticator, it can only be 2000 provided by a previous authenticator. 2002 As noted in Section 1.5, the goal of the EAP conversation is to 2003 derive session keys known only to the peer and the authenticator. If 2004 keying material is replicated between a previous authenticator and a 2005 new authenticator, then the previous authenticator can possess 2006 session keys used between the peer and new authenticator. Also, the 2007 new authenticator can possess session keys used between the peer and 2008 the previous authenticator. 2010 If a one-way function is used to derive the keying material to be 2011 transported to the new authenticator, then the new authenticator 2012 cannot possess previous session keys without breaking a fundamental 2013 cryptographic assumption. 2015 4.3.2. Authorization 2017 As a part of the authentication process, the backend authentication 2018 server determines the user's authorization profile and transmits the 2019 authorizations to the authenticator along with the transported keying 2020 material. Typically, the profile is determined based on the user 2021 identity, but a certificate presented by the user can also provide 2022 authorization information. 2024 The backend authentication server is responsible for making a user 2025 authorization decision, which requires answering the following 2026 questions: 2028 (a) Is this a legitimate user of this network? 2030 (b) Is the user allowed to access this network? 2032 (c) Is the user permitted to access this network on this day and at 2033 this time? 2035 (d) Is the user within the concurrent session limit? 2037 (e) Are there any fraud, credit limit, or other concerns that could 2038 lead to access denial? 2040 (f) If access is to be granted, what are the service parameters 2041 (mandatory tunneling, bandwidth, filters, and so on) to be 2042 provisioned for the user? 2044 While the authorization decision is in principle simple, the 2045 distributed decision making process can add complexity. Where 2046 brokers or proxies are involved, all of the AAA entities in the chain 2047 from the authenticator to the home backend authentication server are 2048 involved in the decision. For example, a broker can deny access even 2049 if the home backend authentication server would allow it, or a proxy 2050 can add authorizations (e.g., bandwidth limits). 2052 Decisions can be based on static policy definitions and profiles as 2053 well as dynamic state (e.g. time of day or concurrent session 2054 limits). In addition to the Accept/Reject decisions made by AAA 2055 entities, service parameters or constraints can be communicated to 2056 the authenticator. 2058 The criteria for Accept/Reject decisions or the reasons for choosing 2059 particular authorizations are typically not communicated to the 2060 authenticator, only the final result. As a result, the authenticator 2061 has no way to know what the decision was based on. Was a set of 2062 authorization parameters sent because this service is always provided 2063 to the user, or was the decision based on the time of day and the 2064 capabilities of the authenticator? 2066 4.3.3. Correctness 2068 When the AAA exchange (phase 1b) is bypassed, several challenges 2069 arise in ensuring correct authorization: 2071 Theft of service 2072 Bypassing the AAA exchange (phase 1b) SHOULD NOT enable a user to 2073 extend their network access or gain access to services they are not 2074 entitled to. 2076 Consideration of network-wide state 2077 Handoff techniques SHOULD NOT render the backend authentication 2078 server incapable of keeping track of network-wide state. For 2079 example, a backend authentication server can need to keep track of 2080 simultaneous user sessions. 2082 Elevation of privilege 2083 Backend authentication servers often perform conditional 2084 evaluation, in which the authorizations returned in an Access- 2085 Accept message are contingent on the authenticator or on dynamic 2086 state such as the time of day. In this situation, bypassing the 2087 AAA exchange could enable unauthorized access unless the 2088 restrictions are explicitly encoded within the authorizations 2089 provided by the backend authentication server. 2091 A handoff mechanism that provides proper authorization is said to be 2092 "correct". One condition for correctness is as follows: 2094 For a handoff to be "correct" it MUST establish on the new 2095 authenticator the same authorizations as would have been created 2096 had the new authenticator completed a AAA conversation with the 2097 backend authentication server. 2099 A properly designed handoff scheme will only succeed if it is 2100 "correct" in this way. If a successful handoff would establish 2101 "incorrect" authorizations, it is preferable for it to fail. Where 2102 the supported services differ between authenticators, a handoff that 2103 bypasses the backend authentication server is likely to fail. 2104 [RFC2865] section 1.1 states: 2106 A authenticator that does not implement a given service MUST NOT 2107 implement the RADIUS attributes for that service. For example, a 2108 authenticator that is unable to offer ARAP service MUST NOT 2109 implement the RADIUS attributes for ARAP. A authenticator MUST 2110 treat a RADIUS access-accept authorizing an unavailable service as 2111 an access-reject instead. 2113 This behavior applies to attributes that are known, but not 2114 implemented. For attributes that are unknown, [RFC2865] Section 5 2115 states: 2117 A RADIUS server MAY ignore Attributes with an unknown Type. A 2118 RADIUS client MAY ignore Attributes with an unknown Type. 2120 In order to perform a correct handoff, if a new authenticator is 2121 provided with RADIUS authorizations for a known but unavailable 2122 service, then it MUST process these authorizations the same way it 2123 would handle a RADIUS Access-Accept requesting an unavailable 2124 service; this MUST cause the handoff to fail. However, if a new 2125 authenticator is provided with authorizations including unknown 2126 attributes, then these attributes MAY be ignored. The definition of 2127 a "known but unsupported service" MUST encompass requests for 2128 unavailable security services. This includes vendor-specific 2129 attributes related to security, such as those described in [RFC2548]. 2130 Although it can seem somewhat counter-intuitive, failure is indeed 2131 the "correct" result where a known but unsupported service is 2132 requested. 2134 Presumably a correctly configured backend authentication server would 2135 not request that an authenticator provide a service that it does not 2136 implement. This implies that if the new authenticator were to 2137 complete a AAA conversation, it would be likely to receive different 2138 service instructions. Failure of the handoff is the desired result 2139 since it will cause the new authenticator to go back to the backend 2140 server in order to receive the appropriate service definition. 2142 Handoff mechanisms which bypass the backend authentication server are 2143 most likely to be successful when employed in a homogeneous 2144 deployment within a single administrative domain. In a heterogeneous 2145 deployment, the backend authentication server can return different 2146 authorizations depending on the authenticator making the request, in 2147 order to make sure that the requested service is consistent with the 2148 authenticator capabilities. Where a backend authentication server 2149 would send different authorizations to the new authenticator than 2150 were sent to a previous authenticator, transferring authorizations 2151 between the previous authenticator and the new authenticator will 2152 result in incorrect authorization. 2154 Virtual LAN (VLAN) support is defined in [IEEE-802.1Q]; RADIUS 2155 support for dynamic VLANs is described in [RFC3580] and [RFC4675]. 2156 If some authenticators support dynamic VLANs while others do not, 2157 then attributes present in the Access-Request (such as the NAS-Port- 2158 Type, NAS-IP-Address, NAS-IPv6-Address and NAS-Identifier) could be 2159 examined by the backend authentication server to determine when VLAN 2160 attributes will be returned, and if so, which ones. However, if the 2161 backend authenticator is bypassed, then a handoff occurring between 2162 authenticators supporting different VLAN capabilities could result in 2163 a user obtaining access to an unauthorized VLAN (e.g. a user with 2164 access to a guest VLAN being given unrestricted access to the 2165 network). 2167 Similarly, it is preferable for a handoff between an authenticator 2168 providing confidentiality and another that does not to fail, since if 2169 the handoff were successful, the user would be moved from a secure to 2170 an insecure channel without permission from the backend 2171 authentication server. 2173 5. Security Considerations 2175 The EAP threat model is described in [RFC3748] Section 7.1. The 2176 security properties of EAP methods (known as "security claims") are 2177 described in [RFC3748] Section 7.2.1. EAP method requirements for 2178 applications such as Wireless LAN authentication are described in 2179 [RFC4017]. The RADIUS threat model is described in [RFC3579] Section 2180 4.1, and responses to these threats are described in [RFC3579] 2181 Sections 4.2 and 4.3. 2183 However, in addition to threats against EAP and AAA, there are other 2184 system level threats. In developing the threat model, it is assumed 2185 that: 2187 All traffic is visible to the attacker. 2188 The attacker can alter, forge or replay messages. 2189 The attacker can reroute messages to another principal. 2190 The attacker can be a principal or an outsider. 2191 The attacker can compromise any key that is sufficiently old. 2193 Threats arising from these assumptions include: 2195 (a) An attacker can compromise or steal an EAP peer or authenticator, 2196 in an attempt to gain access to other EAP peers or authenticators 2197 or to obtain long-term secrets. 2199 (b) An attacker can attempt a downgrade attack in order to exploit 2200 known weaknesses in an authentication method or cryptographic 2201 algorithm. 2203 (c) An attacker can try to modify or spoof packets, including Discovery 2204 or Secure Association Protocol frames, EAP or AAA packets. 2206 (d) An attacker can attempt to induce an EAP peer, authenticator or 2207 server to disclose keying material to an unauthorized party, or 2208 utilize keying material outside the context that it was intended 2209 for. 2211 (e) An attacker can alter, forge or replay packets. 2213 (f) An attacker can cause an EAP peer, authenticator or server to reuse 2214 a stale key. Use of stale keys can also occur unintentionally. 2215 For example, a poorly implemented backend authentication server can 2216 provide stale keying material to an authenticator, or a poorly 2217 implemented authenticator can reuse nonces. 2219 (g) An authenticated attacker can attempt to obtain elevated privilege 2220 in order to access information that it does not have rights to. 2222 (h) An attacker can attempt a man-in-the-middle attack in order to gain 2223 access to the network. 2225 (i) An attacker can compromise an EAP authenticator in an effort to 2226 commit fraud. For example, a compromised authenticator can provide 2227 incorrect information to the EAP peer and/or server via out-of-band 2228 mechanisms (such as via a AAA or lower layer protocol). This 2229 includes impersonating another authenticator, or providing 2230 inconsistent information to the peer and EAP server. 2232 (j) An attacker can launch a denial of service attack against the EAP 2233 peer, authenticator or backend authentication server. 2235 In order to address these threats, [RFC4962] Section 3 describes 2236 required and recommended security properties. The sections that 2237 follow analyze the compliance of EAP methods, AAA protocols and 2238 Secure Association Protocols with those guidelines. 2240 5.1. Peer and Authenticator Compromise 2242 Requirement: In the event that an authenticator is compromised or 2243 stolen, an attacker can gain access to the network through that 2244 authenticator, or can obtain the credentials needed for the 2245 authenticator/AAA client to communicate with one or more backend 2246 authentication servers. Similarly, if a peer is compromised or 2247 stolen, an attacker can obtain credentials needed to communicate with 2248 one or more authenticators. Mandatory requirement from [RFC4962] 2249 Section 3: 2251 Prevent the Domino effect 2253 Compromise of a single peer MUST NOT compromise keying material 2254 held by any other peer within the system, including session keys 2255 and long-term keys. Likewise, compromise of a single 2256 authenticator MUST NOT compromise keying material held by any 2257 other authenticator within the system. In the context of a key 2258 hierarchy, this means that the compromise of one node in the key 2259 hierarchy must not disclose the information necessary to 2260 compromise other branches in the key hierarchy. Obviously, the 2261 compromise of the root of the key hierarchy will compromise all of 2262 the keys; however, a compromise in one branch MUST NOT result in 2263 the compromise of other branches. There are many implications of 2264 this requirement; however, two implications deserve highlighting. 2265 First, the scope of the keying material must be defined and 2266 understood by all parties that communicate with a party that holds 2267 that keying material. Second, a party that holds keying material 2268 in a key hierarchy must not share that keying material with 2269 parties that are associated with other branches in the key 2270 hierarchy. 2272 Group keys are an obvious exception. Since all members of the 2273 group have a copy of the same key, compromise of any one of the 2274 group members will result in the disclosure of the group key. 2276 Some of the implications of the requirement are as follows: 2278 No Key Sharing 2279 An EAP authenticator MUST NOT share any keying material with 2280 another EAP authenticator, since if one EAP authenticator were 2281 compromised, this would enable the compromise of keying material on 2282 another authenticator. In order to be able to determine whether 2283 keying material has been shared, it is necessary for the identity 2284 of the EAP authenticator (NAS-Identifier) to be defined and 2285 understood by all parties that communicate with it. Similarly, an 2286 EAP peer MUST NOT share any keying material with another EAP peer. 2287 EAP lower layer specifications such as [IEEE-802.11], 2288 [IEEE-802.16e], [IEEE-802.1X], IKEv2 [RFC4306] and PPP [RFC1661] do 2289 not involve key sharing. 2291 No AAA Credential Sharing 2292 AAA credentials (such as RADIUS shared secrets, IPsec pre-shared 2293 keys or certificates) MUST NOT be shared between AAA clients, since 2294 if one AAA client were compromised, this would enable an attacker 2295 to impersonate other AAA clients to the backend authentication 2296 server, or even to impersonate a backend authentication server to 2297 other AAA clients. 2299 No Compromise of Long-Term Credentials 2300 An attacker obtaining keying material (such as TSKs, TEKs or the 2301 MSK) MUST NOT be able to obtain long-term user credentials such as 2302 pre-shared keys, passwords or private-keys without breaking a 2303 fundamental cryptographic assumption. The mandatory requirements 2304 of [RFC4017] Section 2.2 include generation of EAP keying material, 2305 capability to generate EAP keying material with 128-bits of 2306 effective strength, resistance to dictionary attacks, shared state 2307 equivalence and protection against man-in-the-middle attacks. 2309 5.2. Cryptographic Negotiation 2311 Mandatory requirements from [RFC4962] Section 3: 2313 Cryptographic algorithm independent 2315 The AAA key management protocol MUST be cryptographic algorithm 2316 independent. However, an EAP method MAY depend on a specific 2317 cryptographic algorithm. The ability to negotiate the use of a 2318 particular cryptographic algorithm provides resilience against 2319 compromise of a particular cryptographic algorithm. Algorithm 2320 independence is also REQUIRED with a Secure Association Protocol 2321 if one is defined. This is usually accomplished by including an 2322 algorithm identifier and parameters in the protocol, and by 2323 specifying the algorithm requirements in the protocol 2324 specification. While highly desirable, the ability to negotiate 2325 key derivation functions (KDFs) is not required. For 2326 interoperability, at least one suite of mandatory-to-implement 2327 algorithms MUST be selected. Note that without protection by 2328 IPsec as described in [RFC3579] Section 4.2, RADIUS [RFC2865] does 2329 not meet this requirement, since the integrity protection 2330 algorithm cannot be negotiated. 2332 This requirement does not mean that a protocol must support both 2333 public-key and symmetric-key cryptographic algorithms. It means 2334 that the protocol needs to be structured in such a way that 2335 multiple public-key algorithms can be used whenever a public-key 2336 algorithm is employed. Likewise, it means that the protocol needs 2337 to be structured in such a way that multiple symmetric-key 2338 algorithms can be used whenever a symmetric-key algorithm is 2339 employed. 2341 Confirm ciphersuite selection 2343 The selection of the "best" ciphersuite SHOULD be securely 2344 confirmed. The mechanism SHOULD detect attempted roll-back 2345 attacks. 2347 EAP methods satisfying [RFC4017] Section 2.2 mandatory requirements 2348 and AAA protocols utilizing transmission layer security are capable 2349 of addressing downgrade attacks. [RFC3748] Section 7.2.1 describes 2350 the "protected ciphersuite negotiation" security claim that refers to 2351 the ability of an EAP method to negotiate the ciphersuite used to 2352 protect the EAP method conversation, as well as to integrity protect 2353 the ciphersuite negotiation. [RFC4017] Section 2.2 requires EAP 2354 methods satisfying this security claim. Since TLS v1.2 [I-D.ietf- 2355 tls-rfc4346-bis] supports negotiation of Key Distribution Functions 2356 (KDFs), EAP methods based on TLS will, if properly designed, inherit 2357 this capability. However, negotiation of KDFs is not required by RFC 2358 4962 [RFC4962], and EAP methods not based on TLS typically do not 2359 support KDF negotiation. 2361 Diameter [RFC3588] provides support for cryptographic algorithm 2362 negotiation via use of IPsec [RFC4301] or TLS [RFC4346]. Since IKEv2 2363 [RFC4306] does not support KDF negotiation, support for KDF 2364 negotiation is only available when Diameter runs over TLS v1.2. 2365 RADIUS [RFC3579] does not support cryptographic algorithm negotiation 2366 and relies on MD5 for integrity protection, authentication and 2367 confidentiality. Given the known weaknesses in MD5 [MD5Collision] 2368 this is undesirable, and can be addressed via use of RADIUS over 2369 IPsec, as described in [RFC3579] Section 4.2. 2371 To ensure against downgrade attacks within lower layer protocols, 2372 algorithm independence is REQUIRED with lower layers using EAP for 2373 key derivation. For interoperability, at least one suite of 2374 mandatory-to-implement algorithm MUST be selected. Lower layer 2375 protocols supporting EAP for key derivation SHOULD also support 2376 secure ciphersuite negotiation as well as KDF negotiation. 2378 As described in [RFC1968], PPP ECP does not support secure 2379 ciphersuite negotiation. While [IEEE 802.16e] and [IEEE-802.11] 2380 support ciphersuite negotiation for protection of data, they do not 2381 support negotiation of the cryptographic primitives used within the 2382 Secure Association Protocol, such as message integrity checks (MICs) 2383 and KDFs. 2385 5.3. Confidentiality and Authentication 2387 Requirement: Each party in the EAP, AAA and Secure Association 2388 Protocol conversations MUST be authenticated to the other parties 2389 with whom they communicate. Mandatory requirements from [RFC4962] 2390 Section 3: 2392 Authenticate all parties 2394 Authentication mechanisms MUST maintain the confidentiality of any 2395 secret values used in the authentication process. When a secure 2396 association protocol is used to establish session keys, the 2397 parties involved in the secure association protocol MUST identify 2398 themselves using identities that are meaningful in the lower-layer 2399 protocol environment that will employ the session keys. In this 2400 situation, the authenticator and peer may be known by different 2401 identifiers in the AAA protocol environment and the lower-layer 2402 protocol environment, making authorization decisions difficult 2403 without a clear key scope. If the lower-layer identifier of the 2404 peer will be used to make authorization decisions, then the pair 2405 of identifiers associated with the peer MUST be authorized by the 2406 authenticator and/or the AAA server. 2408 AAA protocols, such as RADIUS [RFC2865] and Diameter [RFC3588], 2409 provide a mechanism for the identification of AAA clients; since 2410 the EAP authenticator and AAA client are always co- resident, this 2411 mechanism is applicable to the identification of EAP 2412 authenticators. 2414 When multiple base stations and a "controller" (such as a WLAN 2415 switch) comprise a single EAP authenticator, the "base station 2416 identity" is not relevant; the EAP method conversation takes place 2417 between the EAP peer and the EAP server. Also, many base stations 2418 can share the same authenticator identity. The authenticator 2419 identity is important in the AAA protocol exchange and the secure 2420 association protocol conversation. 2422 Authentication mechanisms MUST NOT employ plaintext passwords. 2423 Passwords may be used provided that they are not sent to another 2424 party without confidentiality protection. 2426 Keying material confidentiality and integrity 2428 While preserving algorithm independence, confidentiality and 2429 integrity of all keying material MUST be maintained. 2431 Conformance to these requirements are analyzed in the sections that 2432 follow. 2434 5.3.1. Spoofing 2436 Per-packet authentication and integrity protection provides 2437 protection against spoofing attacks. 2439 Diameter [RFC3588] provides support for per-packet authentication and 2440 integrity protection via use of IPsec or TLS. RADIUS/EAP [RFC3579] 2441 provides for per-packet authentication and integrity protection via 2442 use of the Message-Authenticator attribute. 2444 [RFC3748] Section 7.2.1 describes the "integrity protection" security 2445 claim and [RFC4017] Section 2.2 requires EAP methods supporting this 2446 claim. 2448 In order to prevent forgery of Secure Association Protocol frames, 2449 per-frame authentication and integrity protection is RECOMMENDED on 2450 all messages. IKEv2 [RFC4306] supports per-frame integrity 2451 protection and authentication, as does the Secure Association 2452 Protocol defined in [IEEE-802.16e]. [IEEE-802.11] supports per-frame 2453 integrity protection and authentication on all messages within the 2454 4-way handshake except the first message. An attack leveraging this 2455 omission is described in [Analysis]. 2457 5.3.2. Impersonation 2459 Both RADIUS [RFC2865] and Diameter [RFC3588] implementations are 2460 potentially vulnerable to a rogue authenticator impersonating another 2461 authenticator. While both protocols support mutual authentication 2462 between the AAA client/authenticator and the backend authentication 2463 server, the security mechanisms vary. 2465 In RADIUS, the shared secret used for authentication is determined by 2466 the source address of the RADIUS packet. However, when RADIUS 2467 Access-Requests are forwarded by a proxy, the NAS-IP-Address, NAS- 2468 Identifier or NAS-IPv6-Address attributes received by the RADIUS 2469 server will not correspond to the source address. As noted in 2470 [RFC3579] Section 4.3.7, if the first-hop proxy does not check the 2471 NAS identification attributes against the source address in the 2472 Access-Request packet, it is possible for a rogue authenticator to 2473 forge NAS-IP-Address [RFC2865], NAS-IPv6-Address [RFC3162] or NAS- 2474 Identifier [RFC2865] attributes in order to impersonate another 2475 authenticator; attributes such as the Called-Station-Id [RFC2865] and 2476 Calling-Station-Id [RFC2865] can be forged as well. Among other 2477 things, this can result in messages (and transported keying material) 2478 being sent to the wrong authenticator. 2480 While [RFC3588] requires use of the Route-Record AVP, this utilizes 2481 Fully Qualified Domain Names (FQDNs), so that impersonation detection 2482 requires DNS A, AAAA and PTR Resource Records (RRs) to be properly 2483 configured. As a result, Diameter is as vulnerable to this attack as 2484 RADIUS, if not more so. [RFC3579] Section 4.3.7 recommends 2485 mechanisms for impersonation detection; to prevent access to keying 2486 material by proxies without a "need to know", it is necessary to 2487 allow the backend authentication server to communicate with the 2488 authenticator directly, such as via the redirect functionality 2489 supported in [RFC3588]. 2491 5.3.3. Channel Binding 2493 It is possible for a compromised or poorly implemented EAP 2494 authenticator to communicate incorrect information to the EAP peer 2495 and/or server. This can enable an authenticator to impersonate 2496 another authenticator or communicate incorrect information via out- 2497 of-band mechanisms (such as via AAA or the lower layer). 2499 Where EAP is used in pass-through mode, the EAP peer does not verify 2500 the identity of the pass-through authenticator within the EAP 2501 conversation. Within the Secure Association Protocol, the EAP peer 2502 and authenticator only demonstrate mutual possession of the 2503 transported keying material; they do not mutually authenticate. This 2504 creates a potential security vulnerability, described in [RFC3748] 2505 Section 7.15. 2507 As described in [RFC3579] Section 4.3.7, it is possible for a first- 2508 hop AAA proxy to detect a AAA client attempting to impersonate 2509 another authenticator. However, it is possible for a pass-through 2510 authenticator acting as a AAA client to provide correct information 2511 to the backend authentication server while communicating misleading 2512 information to the EAP peer via the lower layer. 2514 For example, a compromised authenticator can utilize another 2515 authenticator's Called-Station-Id or NAS-Identifier in communicating 2516 with the EAP peer via the lower layer. Also, a pass-through 2517 authenticator acting as a AAA client can provide an incorrect peer 2518 Calling-Station-Id [RFC2865][RFC3580] to the backend authentication 2519 server via the AAA protocol. 2521 As noted in [RFC3748] Section 7.15, this vulnerability can be 2522 addressed by EAP methods that support a protected exchange of channel 2523 properties such as endpoint identifiers, including (but not limited 2524 to): Called-Station-Id [RFC2865][RFC3580], Calling-Station-Id 2525 [RFC2865][RFC3580], NAS-Identifier [RFC2865], NAS-IP-Address 2526 [RFC2865], and NAS-IPv6-Address [RFC3162]. 2528 Using such a protected exchange, it is possible to match the channel 2529 properties provided by the authenticator via out-of-band mechanisms 2530 against those exchanged within the EAP method. Typically the EAP 2531 method imports channel binding parameters from the lower layer on the 2532 peer, and transmits them securely to the EAP server, which exports 2533 them to the lower layer or AAA layer. However, transport can occur 2534 from EAP server to peer, or can be bi-directional. On the side of 2535 the exchange (peer or server) where Channel Binding is verified, the 2536 lower layer or AAA layer passes the result of the verification (TRUE 2537 or FALSE) up to the EAP method. While the verification can be done 2538 either by the peer or the server, typically only the server has the 2539 knowledge to determine the correctness of the values, as opposed to 2540 merely verifying their equality. For further discussion, see 2541 [I-D.arkko-eap-service-identity-auth]. 2543 It is also possible to perform Channel Binding without transporting 2544 data over EAP, as described in [I-D.ohba-eap-channel-binding]. In 2545 this approach the EAP method includes channel binding parameters in 2546 the calculation of exported EAP keying material, making it impossible 2547 for the peer and authenticator to complete the Secure Association 2548 Protocol if there is a mismatch in the channel binding parameters. 2549 However, this approach can only be applied where methods generating 2550 EAP keying material are used along with lower layers that utilize EAP 2551 keying material. For example, this mechanism would not enable 2552 verification of Channel Binding on wired IEEE 802 networks using 2553 [IEEE-802.1X]. 2555 5.3.4. Mutual Authentication 2557 [RFC3748] Section 7.2.1 describes the "mutual authentication" and 2558 "dictionary attack resistance" claims, and [RFC4017] requires EAP 2559 methods satisfying these claims. EAP methods complying with 2560 [RFC4017] therefore provide for mutual authentication between the EAP 2561 peer and server. 2563 [RFC3748] Section 7.2.1 also describes the "Cryptographic binding" 2564 security claim, and [RFC4017] Section 2.2 requires support for this 2565 claim. As described in [I-D.puthenkulam-eap-binding], EAP method 2566 sequences and compound authentication mechanisms can be subject to 2567 man-in-the-middle attacks. When such attacks are successfully 2568 carried out, the attacker acts as an intermediary between a victim 2569 and a legitimate authenticator. This allows the attacker to 2570 authenticate successfully to the authenticator, as well as to obtain 2571 access to the network. 2573 In order to prevent these attacks, [I-D.puthenkulam-eap-binding] 2574 recommends derivation of a compound key by which the EAP peer and 2575 server can prove that they have participated in the entire EAP 2576 exchange. Since the compound key MUST NOT be known to an attacker 2577 posing as an authenticator, and yet must be derived from EAP keying 2578 material, it MAY be desirable to derive the compound key from a 2579 portion of the EMSK. Where this is done, in order to provide proper 2580 key hygiene, it is RECOMMENDED that the compound key used for man-in- 2581 the-middle protection be cryptographically separate from other keys 2582 derived from the EMSK. 2584 Diameter [RFC3588] provides for per-packet authentication and 2585 integrity protection via IPsec or TLS, and RADIUS/EAP [RFC3579] also 2586 provides for per-packet authentication and integrity protection. 2588 Where the authenticator/AAA client and backend authentication server 2589 communicate directly and credible key wrap is used (see Section 3.8), 2590 this ensures that the AAA Key Transport (phase 1b) achieves its 2591 security objectives: mutually authenticating the AAA 2592 client/authenticator and backend authentication server and providing 2593 transported keying material to the EAP authenticator and to no other 2594 party. 2596 [RFC2607] Section 7 describes the security issues occurring when the 2597 authenticator/AAA client and backend authentication server do not 2598 communicate directly. Where a AAA intermediary is present (such as a 2599 RADIUS proxy or a Diameter agent), and data object security is not 2600 used, transported keying material can be recovered by an attacker in 2601 control of the intermediary. As discussed in Section 2.1, unless the 2602 TSKs are derived independently from EAP keying material (as in 2603 IKEv2), possession of transported keying material enables decryption 2604 of data traffic sent between the peer and the authenticator to whom 2605 the keying material was transported. It also allows the AAA 2606 intermediary to impersonate the authenticator or the peer. Since the 2607 peer does not authenticate to a AAA intermediary it has no ability to 2608 determine whether it is authentic or authorized to obtain keying 2609 material. 2611 However, as long as transported keying material or keys derived from 2612 it are only utilized by a single authenticator, compromise of the 2613 transported keying material does not enable an attacker to 2614 impersonate the peer to another authenticator. Vulnerability to 2615 compromise of a AAA intermediary can be mitigated by implementation 2616 of redirect functionality, as described in [RFC3588] and [RFC4072]. 2618 The Secure Association Protocol does not provide for mutual 2619 authentication between the EAP peer and authenticator, only mutual 2620 proof of possession of transported keying material. In order for the 2621 peer to verify the identity of the authenticator, mutual proof of 2622 possession needs to be combined with impersonation prevention and 2623 Channel Binding. Impersonation prevention (described in Section 2624 5.3.2) enables the backend authentication server to determine that 2625 the transported keying material has been provided to the correct 2626 authenticator. When utilized along with impersonation prevention, 2627 Channel Binding (described in Section 5.3.3) enables the EAP peer to 2628 verify that the EAP server has authorized the authenticator to 2629 possess the transported keying material. Completion of the Secure 2630 Association Protocol exchange demonstrates that the EAP peer and the 2631 authenticator possess the transported keying material. 2633 5.4. Key Binding 2635 Mandatory requirement from [RFC4962] Section 3: 2637 Bind key to its context 2639 Keying material MUST be bound to the appropriate context. The 2640 context includes the following: 2642 o The manner in which the keying material is expected to 2643 be used. 2645 o The other parties that are expected to have access to 2646 the keying material. 2648 o The expected lifetime of the keying material. Lifetime 2649 of a child key SHOULD NOT be greater than the lifetime of 2650 its parent in the key hierarchy. 2652 Any party with legitimate access to keying material can determine 2653 its context. In addition, the protocol MUST ensure that all 2654 parties with legitimate access to keying material have the same 2655 context for the keying material. This requires that the parties 2656 are properly identified and authenticated, so that all of the 2657 parties that have access to the keying material can be determined. 2659 The context will include the peer and NAS identities in more than 2660 one form. One (or more) name form is needed to identify these 2661 parties in the authentication exchange and the AAA protocol. 2662 Another name form may be needed to identify these parties within 2663 the lower layer that will employ the session key. 2665 Within EAP, exported keying material (MSK, EMSK,IV) is bound to the 2666 Peer-Id(s) and Server-Id(s) which are exported along with the keying 2667 material. However, not all EAP methods support authenticated server 2668 identities (see Appendix A). 2670 Within the AAA protocol, transported keying material is destined for 2671 the EAP authenticator identified by the NAS-Identifier Attribute 2672 within the request, and is for use by the EAP peer identified by the 2673 Peer-Id(s), User-Name [RFC2865] or Chargeable User Identity (CUI) 2674 [RFC4372] attributes. The maximum lifetime of the transported keying 2675 material can be provided, as discussed in Section 3.5.1. Key usage 2676 restrictions can also be included as described in Section 3.2. Key 2677 lifetime issues are discussed in Sections 3.3, 3.4 and 3.5. 2679 5.5. Authorization 2681 Requirement: The Secure Association Protocol (phase 2) conversation 2682 may utilize different identifiers from the EAP conversation (phase 2683 1a), so that binding between the EAP and Secure Association Protocol 2684 identities is REQUIRED. 2686 Mandatory requirement from [RFC4962] Section 3: 2688 Peer and authenticator authorization 2690 Peer and authenticator authorization MUST be performed. These 2691 entities MUST demonstrate possession of the appropriate keying 2692 material, without disclosing it. Authorization is REQUIRED 2693 whenever a peer associates with a new authenticator. The 2694 authorization checking prevents an elevation of privilege attack, 2695 and it ensures that an unauthorized authenticator is detected. 2697 Authorizations SHOULD be synchronized between the peer, NAS, and 2698 backend authentication server. Once the AAA key management 2699 protocol exchanges are complete, all of these parties should hold 2700 a common view of the authorizations associated the other parties. 2702 In addition to authenticating all parties, key management 2703 protocols need to demonstrate that the parties are authorized to 2704 possess keying material. Note that proof of possession of keying 2705 material does not necessarily prove authorization to hold that 2706 keying material. For example, within an IEEE 802.11, the 4-way 2707 handshake demonstrates that both the peer and authenticator 2708 possess the same EAP keying material. However, by itself, this 2709 possession proof does not demonstrate that the authenticator was 2710 authorized by the backend authentication server to possess that 2711 keying material. As noted in [RFC3579] in Section 4.3.7, where 2712 AAA proxies are present, it is possible for one authenticator to 2713 impersonate another, unless each link in the AAA chain implements 2714 checks against impersonation. Even with these checks in place, an 2715 authenticator may still claim different identities to the peer and 2716 the backend authentication server. As described in [RFC3748] 2717 Section 7.15, channel binding enables the peer to verify that the 2718 authenticator claim of identity is both consistent and correct. 2720 Recommendation from [RFC4962] Section 3: 2722 Authorization restriction 2724 If peer authorization is restricted, then the peer SHOULD be made 2725 aware of the restriction. Otherwise, the peer may inadvertently 2726 attempt to circumvent the restriction. For example, authorization 2727 restrictions in an IEEE 802.11 environment include: 2729 o Key lifetimes, where the keying material can only be used 2730 for a certain period of time; 2732 o SSID restrictions, where the keying material can only be 2733 used with a specific IEEE 802.11 SSID; 2735 o Called-Station-ID restrictions, where the keying material 2736 can only be used with a single IEEE 802.11 BSSID; and 2738 o Calling-Station-ID restrictions, where the keying 2739 material can only be used with a single peer IEEE 802 MAC 2740 address. 2742 As described in Section 2.3, consistent identification of the EAP 2743 authenticator enables the EAP peer to determine the scope of keying 2744 material provided to an authenticator, as well as to confirm with the 2745 backend authentication server that an EAP authenticator proving 2746 possession of EAP keying material during the Secure Association 2747 Protocol was authorized to obtain it. 2749 Within the AAA protocol, the authorization attributes are bound to 2750 the transported keying material. While the AAA exchange provides the 2751 AAA client/authenticator with authorizations relating to the EAP 2752 peer, neither the EAP nor AAA exchanges provide authorizations to the 2753 EAP peer. In order to ensure that all parties hold the same view of 2754 the authorizations it is RECOMMENDED that the Secure Association 2755 Protocol enable communication of authorizations between the EAP 2756 authenticator and peer. 2758 In lower layers where the authenticator consistently identifies 2759 itself to the peer and backend authentication server and the EAP peer 2760 completes the Secure Association Protocol exchange with the same 2761 authenticator through which it completed the EAP conversation, 2762 authorization of the authenticator is demonstrated to the peer by 2763 mutual authentication between the peer and authenticator as discussed 2764 in the previous section. Identification issues are discussed in 2765 Sections 2.3, 2.4 and 2.5 and key scope issues are discussed in 2766 Section 3.2. 2768 Where the EAP peer utilizes different identifiers within the EAP 2769 method and Secure Association Protocol conversations, peer 2770 authorization can be difficult to demonstrate to the authenticator 2771 without additional restrictions. This problem does not exist in 2772 IKEv2 where the Identity Payload is used for peer identification both 2773 within IKEv2 and EAP, and where the EAP conversation is 2774 cryptographically protected within IKEv2 binding the EAP and IKEv2 2775 exchanges. However within [IEEE-802.11] the EAP peer identity is not 2776 used within the 4-way handshake, so that it is necessary for the 2777 authenticator to require that the EAP peer utilize the same MAC 2778 address for EAP authentication as for the 4-way handshake. 2780 5.6. Replay Protection 2782 Mandatory requirement from [RFC4962] Section 3: 2784 Replay detection mechanism 2786 The AAA key management protocol exchanges MUST be replay 2787 protected, including AAA, EAP and Secure Association Protocol 2788 exchanges. Replay protection allows a protocol message recipient 2789 to discard any message that was recorded during a previous 2790 legitimate dialogue and presented as though it belonged to the 2791 current dialogue. 2793 [RFC3748] Section 7.2.1 describes the "replay protection" security 2794 claim and [RFC4017] Section 2.2 requires use of EAP methods 2795 supporting this claim. 2797 Diameter [RFC3588] provides support for replay protection via use of 2798 IPsec or TLS. RADIUS/EAP [RFC3579] protects against replay of keying 2799 material via the Request Authenticator. However, some RADIUS packets 2800 are not replay protected. In Accounting, Disconnect and CoA-Request 2801 packets the Request Authenticator contains a keyed MAC rather than a 2802 Nonce. The Response Authenticator in Accounting, Disconnect and CoA 2803 Response packets also contains a keyed MAC whose calculation does not 2804 depend on a Nonce in either the Request or Response packets. 2805 Therefore unless an Event-Timestamp attribute is included or IPsec is 2806 used, it is possible that the recipient will not be able to determine 2807 whether these packets have been replayed. 2809 In order to prevent replay of Secure Association Protocol frames, 2810 replay protection is REQUIRED on all messages. [IEEE-802.11] 2811 supports replay protection on all messages within the 4-way 2812 handshake; IKEv2 [RFC4306] also supports this. 2814 5.7. Key Freshness 2816 Requirement: A session key SHOULD be considered compromised if it 2817 remains in use beyond its authorized lifetime. Mandatory requirement 2818 from [RFC4962] Section 3: 2820 Strong, fresh session keys 2822 While preserving algorithm independence, session keys MUST be 2823 strong and fresh. Each session deserves an independent session 2824 key. Fresh keys are required even when a long replay counter 2825 (that is, one that "will never wrap") is used to ensure that loss 2826 of state does not cause the same counter value to be used more 2827 than once with the same session key. 2829 Some EAP methods are capable of deriving keys of varying strength, 2830 and these EAP methods MUST permit the generation of keys meeting a 2831 minimum equivalent key strength. BCP 86 [RFC3766] offers advice 2832 on appropriate key sizes. The National Institute for Standards 2833 and Technology (NIST) also offers advice on appropriate key sizes 2834 in [SP800-57]. 2836 A fresh cryptographic key is one that is generated specifically 2837 for the intended use. In this situation, a secure association 2838 protocol is used to establish session keys. The AAA protocol and 2839 EAP method MUST ensure that the keying material supplied as an 2840 input to session key derivation is fresh, and the secure 2841 association protocol MUST generate a separate session key for each 2842 session, even if the keying material provided by EAP is cached. A 2843 cached key persists after the authentication exchange has 2844 completed. For the AAA/EAP server, key caching can happen when 2845 state is kept on the server. For the NAS or client, key caching 2846 can happen when the NAS or client does not destroy keying material 2847 immediately following the derivation of session keys. 2849 Session keys MUST NOT be dependent on one another. Multiple 2850 session keys may be derived from a higher-level shared secret as 2851 long as a one-time value, usually called a nonce, is used to 2852 ensure that each session key is fresh. The mechanism used to 2853 generate session keys MUST ensure that the disclosure of one 2854 session key does not aid the attacker in discovering any other 2855 session keys. 2857 EAP, AAA and the lower layer each bear responsibility for ensuring 2858 the use of fresh, strong session keys. EAP methods need to ensure 2859 the freshness and strength of EAP keying material provided as an 2860 input to session key derivation. [RFC3748] Section 7.10 states: 2862 EAP methods SHOULD ensure the freshness of the MSK and EMSK, even 2863 in cases where one party may not have a high quality random number 2864 generator. A RECOMMENDED method is for each party to provide a 2865 nonce of at least 128 bits, used in the derivation of the MSK and 2866 EMSK. 2868 The contribution of nonces enables the EAP peer and server to ensure 2869 that exported EAP keying material is fresh. 2871 [RFC3748] Section 7.2.1 describes the "key strength" and "session 2872 independence" security claims, and [RFC4017] requires EAP methods 2873 supporting these claims as well as methods capable of providing 2874 equivalent key strength of 128 bits or greater. See Section 3.7 for 2875 more information on key strength. 2877 The AAA protocol needs to ensure that transported keying material is 2878 fresh and is not utilized outside its recommended lifetime. Replay 2879 protection is necessary for key freshness, but an attacker can 2880 deliver a stale (and therefore potentially compromised) key in a 2881 replay-protected message, so replay protection is not sufficient. As 2882 discussed in Section 3.5, the Session-Timeout attribute enables the 2883 backend authentication server to limit the exposure of transported 2884 keying material. 2886 The EAP Session-Id, described in Section 1.4, enables the EAP peer, 2887 authenticator and server to distinguish EAP conversations. However, 2888 unless the authenticator keeps track of EAP Session-Ids, the 2889 authenticator cannot use the Session-Id to guarantee the freshness of 2890 keying material. 2892 The Secure Association Protocol, described in Section 3.1, MUST 2893 generate a fresh session key for each session, even if the EAP keying 2894 material and parameters provided by methods are cached, or either the 2895 peer or authenticator lack a high entropy random number generator. A 2896 RECOMMENDED method is for the peer and authenticator to each provide 2897 a nonce or counter used in session key derivation. If a nonce is 2898 used, it is RECOMMENDED that it be at least 128 bits. While 2899 [IEEE-802.11] and IKEv2 [RFC4306] satisfy this requirement, 2900 [IEEE-802.16e] does not, since randomness is only contributed from 2901 the Base Station. 2903 5.8. Key Scope Limitation 2905 Mandatory requirement from [RFC4962] Section 3: 2907 Limit key scope 2909 Following the principle of least privilege, parties MUST NOT have 2910 access to keying material that is not needed to perform their 2911 role. A party has access to a particular key if it has access to 2912 all of the secret information needed to derive it. 2914 Any protocol that is used to establish session keys MUST specify 2915 the scope for session keys, clearly identifying the parties to 2916 whom the session key is available. 2918 Transported keying material is permitted to be accessed by the EAP 2919 peer, authenticator and server. The EAP peer and server derive EAP 2920 keying material during the process of mutually authenticating each 2921 other using the selected EAP method. During the Secure Association 2922 Protocol exchange, the EAP peer utilizes keying material to 2923 demonstrate to the authenticator that it is the same party that 2924 authenticated to the EAP server and was authorized by it. The EAP 2925 authenticator utilizes the transported keying material to prove to 2926 the peer not only that the EAP conversation was transported through 2927 it (this could be demonstrated by a man-in-the-middle), but that it 2928 was uniquely authorized by the EAP server to provide the peer with 2929 access to the network. Unique authorization can only be demonstrated 2930 if the EAP authenticator does not share the transported keying 2931 material with a party other than the EAP peer and server. 2933 TSKs are permitted to be accessed only by the EAP peer and 2934 authenticator (see Section 1.5); TSK derivation is discussed in 2935 Section 2.1. Since demonstration of authorization within the Secure 2936 Association Protocol exchange depends on possession of transported 2937 keying material, the backend authentication server can obtain TSKs 2938 unless it deletes the transported keying material after sending it. 2940 5.9. Key Naming 2942 Mandatory requirement from [RFC4962] Section 3: 2944 Uniquely named keys 2946 AAA key management proposals require a robust key naming scheme, 2947 particularly where key caching is supported. The key name 2948 provides a way to refer to a key in a protocol so that it is clear 2949 to all parties which key is being referenced. Objects that cannot 2950 be named cannot be managed. All keys MUST be uniquely named, and 2951 the key name MUST NOT directly or indirectly disclose the keying 2952 material. If the key name is not based on the keying material, 2953 then one can be sure that it cannot be used to assist in a search 2954 for the key value. 2956 EAP key names (defined in Section 1.4.1), along with the Peer-Id(s) 2957 and Server-Id(s), uniquely identify EAP keying material, and do not 2958 directly or indirectly expose EAP keying material. 2960 Existing AAA server implementations do not distribute key names along 2961 with the transported keying material, although Diameter EAP 2962 [RFC4072], provides the EAP-Key-Name AVP for this purpose. Since the 2963 EAP-Key-Name AVP is defined within the RADIUS attribute space, it can 2964 be used either with RADIUS or Diameter. 2966 Since the authenticator is not provided with the name of the 2967 transported keying material by existing backend authentication server 2968 implementations, existing Secure Association Protocols do not utilize 2969 EAP key names. For example, [IEEE-802.11] supports PMK caching; to 2970 enable the peer and authenticator to determine the cached PMK to 2971 utilize within the 4-way handshake the PMK needs to be named. For 2972 this purpose [IEEE-802.11] utilizes a PMK naming scheme which is 2973 based on the key. Since IKEv2 [RFC4306] does not cache transported 2974 keying material, it does not need to refer to transported keying 2975 material. 2977 5.10. Denial of Service Attacks 2979 Key caching can result in vulnerability to denial of service attacks. 2980 For example, EAP methods that create persistent state can be 2981 vulnerable to denial of service attacks on the EAP server by a rogue 2982 EAP peer. 2984 To address this vulnerability, EAP methods creating persistent state 2985 can limit the persistent state created by an EAP peer. For example, 2986 for each peer an EAP server can choose to limit persistent state to a 2987 few EAP conversations, distinguished by the EAP Session-Id. This 2988 prevents a rogue peer from denying access to other peers. 2990 Similarly, to conserve resources an authenticator can choose to limit 2991 the persistent state corresponding to each peer. This can be 2992 accomplished by limiting each peer to persistent state corresponding 2993 to a few EAP conversations, distinguished by the EAP Session-Id. 2995 Whether creation of new TSKs implies deletion of previously derived 2996 TSKs depends on the EAP lower layer. Where there is no implied 2997 deletion, the authenticator can choose to limit the number of TSKs 2998 and associated state that can be stored for each peer. 3000 6. IANA Considerations 3002 This specification does not request the creation of any new parameter 3003 registries, nor does it require any other IANA assignments. 3005 7. References 3007 7.1. Normative References 3009 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3010 Requirement Levels", BCP 14, RFC 2119, March 1997. 3012 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 3013 Levkowetz, "Extensible Authentication Protocol (EAP)", 3014 RFC 3748, June 2004. 3016 [RFC4962] Housley, R. and B. Aboba, "Guidance for AAA Key 3017 Management", RFC 4962, July 2007. 3019 7.2. Informative References 3021 [8021XPreAuth] Pack, S. and Y. Choi, "Pre-Authenticated Fast Handoff in 3022 a Public Wireless LAN Based on IEEE 802.1x Model", 3023 Proceedings of the IFIP TC6/WG6.8 Working Conference on 3024 Personal Wireless Communications, p.175-182, October 3025 23-25, 2002. 3027 [Analysis] He, C. and J. Mitchell, "Analysis of the 802.11i 4-Way 3028 Handshake", Proceedings of the 2004 ACM Workshop on 3029 Wireless Security, pp. 43-50, ISBN: 1-58113-925-X. 3031 [Bargh] Bargh, M., Hulsebosch, R., Eertink, E., Prasad, A., Wang, 3032 H. and P. Schoo, "Fast Authentication Methods for 3033 Handovers between IEEE 802.11 Wireless LANs", Proceedings 3034 of the 2nd ACM international workshop on Wireless mobile 3035 applications and services on WLAN hotspots, October, 3036 2004. 3038 [GKDP] Dondeti, L., Xiang, J. and S. Rowles, "GKDP: Group Key 3039 Distribution Protocol", Internet draft (work in 3040 progress), draft-ietf-msec-gkdp-01, March 2006. 3042 [He] He, C., Sundararajan, M., Datta, A. Derek, A. and J. C. 3043 Mitchell, "A Modular Correctness Proof of TLS and IEEE 3044 802.11i", ACM Conference on Computer and Communications 3045 Security (CCS '05), November, 2005. 3047 [IEEE-802.11] Institute of Electrical and Electronics Engineers, 3048 "Information technology - Telecommunications and 3049 information exchange between systems - Local and 3050 metropolitan area networks - Specific Requirements Part 3051 11: Wireless LAN Medium Access Control (MAC) and 3052 Physical Layer (PHY) Specifications", IEEE IEEE Standard 3053 802.11-2007, 2007. 3055 [IEEE-802.1X] Institute of Electrical and Electronics Engineers, "Local 3056 and Metropolitan Area Networks: Port-Based Network Access 3057 Control", IEEE Standard 802.1X-2004, December 2004. 3059 [IEEE-802.1Q] IEEE Standards for Local and Metropolitan Area Networks: 3060 Draft Standard for Virtual Bridged Local Area Networks, 3061 P802.1Q-2003, January 2003. 3063 [IEEE-802.11i] Institute of Electrical and Electronics Engineers, 3064 "Supplement to Standard for Telecommunications and 3065 Information Exchange Between Systems - LAN/MAN Specific 3066 Requirements - Part 11: Wireless LAN Medium Access 3067 Control (MAC) and Physical Layer (PHY) Specifications: 3068 Specification for Enhanced Security", IEEE 802.11i/D1, 3069 2001. 3071 [IEEE-802.11F] Institute of Electrical and Electronics Engineers, 3072 "Recommended Practice for Multi-Vendor Access Point 3073 Interoperability via an Inter-Access Point Protocol 3074 Across Distribution Systems Supporting IEEE 802.11 3075 Operation", IEEE 802.11F, July 2003 (now deprecated). 3077 [IEEE-802.16e] Institute of Electrical and Electronics Engineers, "IEEE 3078 Standard for Local and Metropolitan Area Networks: Part 3079 16: Air Interface for Fixed and Mobile Broadband Wireless 3080 Access Systems: Amendment for Physical and Medium Access 3081 Control Layers for Combined Fixed and Mobile Operations 3082 in Licensed Bands" IEEE 802.16e, August 2005. 3084 [IEEE-03-084] Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, 3085 "Proactive Key Distribution to support fast and secure 3086 roaming", IEEE 802.11 Working Group, IEEE-03-084r1-I, 3087 http://www.ieee802.org/11/Documents/DocumentHolder/ 3088 3-084.zip, January 2003. 3090 [I-D.arkko-eap-service-identity-auth] 3091 Arkko, J. and P. Eronen, "Authenticated Service 3092 Information for the Extensible Authentication Protocol 3093 (EAP)", draft-arkko-eap-service-identity-auth-04.txt 3094 Internet draft (work in progress), October 2005. 3096 [I-D.friedman-ike-short-term-certs] 3097 Friedman, A., Sheffer, Y. and A. Shaqed, "Short-Term 3098 Certificates", draft-friedman-ike-short-term-certs-02, 3099 Internet draft (work in progress), June 2007. 3101 [I-D.irtf-aaaarch-handoff] 3102 Arbaugh, W. and B. Aboba, "Handoff Extension to RADIUS", 3103 draft-irtf-aaaarch-handoff-04.txt, Internet Draft (work 3104 in progress), October 2003. 3106 [I-D.ohba-eap-channel-binding] 3107 Ohba, Y., Parthasrathy, M. and M. Yanagiya, "Channel 3108 Binding Mechanism Based on Parameter Binding in Key 3109 Derivation", draft-ohba-eap-channel-binding-02.txt, 3110 Internet draft (work in progress), December 2006. 3112 [I-D.puthenkulam-eap-binding] 3113 Puthenkulam, J., Lortz, V., Palekar, A. and D. Simon, 3114 "The Compound Authentication Binding Problem", draft- 3115 puthenkulam-eap-binding-04, Internet draft (work in 3116 progress), October 2003. 3118 [I-D.simon-emu-rfc2716bis] 3119 Simon, D., Aboba, B. and R. Hurst, "The EAP TLS 3120 Authentication Protocol", draft-simon-emu- 3121 rfc2716bis-11.txt, Internet Draft (work in progress), 3122 July 2007. 3124 [I-D.ietf-tls-rfc4346-bis] 3125 Dierks, T. and E. Rescorla, "The Transport Layer Security 3126 (TLS) Protocol Version 1.2", draft-ietf-tls- 3127 rfc4346-bis-05.txt, Internet draft (work in progress), 3128 September 2007. 3130 [MD5Collision] Klima, V., "Tunnels in Hash Functions: MD5 Collisions 3131 Within a Minute", Cryptology ePrint Archive, March 2006, 3132 http://eprint.iacr.org/2006/105.pdf 3134 [MishraPro] Mishra, A., Shin, M. and W. Arbaugh, "Pro-active Key 3135 Distribution using Neighbor Graphs", IEEE Wireless 3136 Communications, vol. 11, February 2004. 3138 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 3139 RFC 1661, July 1994. 3141 [RFC1968] Meyer, G. and K. Fox, "The PPP Encryption Control 3142 Protocol (ECP)", RFC 1968, June 1996. 3144 [RFC2230] Atkinson, R., "Key Exchange Delegation Record for the 3145 DNS", RFC 2230, November 1997. 3147 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 3148 (IKE)", RFC 2409, November 1998. 3150 [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D. 3151 and R. Wheeler, "A Method for Transmitting PPP Over 3152 Ethernet (PPPoE)", RFC 2516, February 1999. 3154 [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", 3155 RFC 2548, March 1999. 3157 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 3158 Implementation in Roaming", RFC 2607, June 1999. 3160 [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication 3161 Protocol", RFC 2716, October 1999. 3163 [RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for 3164 specifying the location of services (DNS SRV)", RFC 2782, 3165 February 2000. 3167 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. 3168 Wellington, "Secret Key Transaction Authentication for 3169 DNS (TSIG)", RFC 2845, May 2000. 3171 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, 3172 "Remote Authentication Dial In User Service (RADIUS)", 3173 RFC 2865, June 2000. 3175 [RFC3007] Wellington, B., "Simple Secure Domain Name System (DNS) 3176 Dynamic Update", RFC 3007, November 2000. 3178 [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 3179 3162, August 2001. 3181 [RFC3547] Baugher, M., Weis, B., Hardjono, T. and H. Harney, "The 3182 Group Domain of Interpretation", RFC 3547, July 2003. 3184 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 3185 Dial In User Service) Support For Extensible 3186 Authentication Protocol (EAP)", RFC 3579, September 2003. 3188 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese, 3189 "IEEE 802.1X Remote Authentication Dial In User Service 3190 (RADIUS) Usage Guidelines", RFC 3580, September 2003. 3192 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. 3193 Arkko, "Diameter Base Protocol", RFC 3588, September 3194 2003. 3196 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 3197 Public Keys Used For Exchanging Symmetric Keys", RFC 3198 3766, April 2004. 3200 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M. and K. 3201 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 3202 August 2004. 3204 [RFC4005] Calhoun, P., Zorn, G., Spence, D. and D. Mitton, 3205 "Diameter Network Access Server Application", RFC 4005, 3206 August 2005 3208 [RFC4017] Stanley, D., Walker, J. and B. Aboba, "EAP Method 3209 Requirements for Wireless LANs", RFC 4017, March 2005. 3211 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D. and S. 3212 Rose, "DNS Security Introduction and Requirements", RFC 3213 4033, March 2005. 3215 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D. and S. 3216 Rose, "Protocol Modifications for the DNS Security 3217 Extensions", RFC 4035, March 2005. 3219 [RFC4067] Loughney, J., Nakhjiri, M., Perkins, C. and R. Koodli, 3220 "Context Transfer Protocol (CXTP)", RFC 4067, July 2005. 3222 [RFC4072] Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible 3223 Authentication Protocol (EAP) Application", RFC 4072, 3224 August 2005. 3226 [RFC4118] Yang, L., Zerfos, P. and E. Sadot, "Architecture Taxonomy 3227 for Control and Provisioning of Wireless Access Points 3228 (CAPWAP)", RFC 4118, June 2005. 3230 [RFC4186] Haverinen, H. and J. Salowey, "Extensible Authentication 3231 Protocol Method for Global System for Mobile 3232 Communications (GSM) Subscriber Identity Modules (EAP- 3233 SIM)", RFC 4186, January 2006. 3235 [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication 3236 Protocol Method for 3rd Generation Authentication and Key 3237 Agreement (EAP-AKA)", RFC 4187, January 2006. 3239 [RFC4282] Aboba, B., Beadles, M., Arkko, J. and P. Eronen, "The 3240 Network Access Identifier", RFC 4282, December 2005. 3242 [RFC4284] Adrangi, F., Lortz, V., Bari, F. and P. Eronen, "Identity 3243 Selection Hints for the Extensible Authentication 3244 Protocol", RFC 4284, January 2006. 3246 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 3247 Internet Protocol", RFC 4301, December 2005. 3249 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 3250 RFC 4306, December 2005. 3252 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 3253 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 3255 [RFC4372] Adrangi, F., Lior, A., Korhonen, J. and J. Loughney, 3256 "Chargeable User Identity", RFC 4372, January 2006. 3258 [RFC4334] Housley, R. and T. Moore, "Certificate Extensions and 3259 Attributes Supporting Authentication in Point-to-Point 3260 Protocol (PPP) and Wireless Local Area Networks (WLAN)", 3261 RFC 4334, February 2006. 3263 [RFC4535] Harney, H., Meth, U., Colegrove, A. and G. Gross, 3264 "GSAKMP: Group Secure Association Group Management 3265 Protocol", RFC 4535, June 2006. 3267 [RFC4763] Vanderveen, M. and H. Soliman, "Extensible Authentication 3268 Protocol Method for Shared-secret Authentication and Key 3269 Establishment (EAP-SAKE)", RFC 4763, November 2006. 3271 [RFC4675] Congdon, P., Sanchez, M. and B. Aboba, "RADIUS Attributes 3272 for Virtual LAN and Priority Support", RFC 4675, 3273 September 2006. 3275 [RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and 3276 Implementation Guidelines", RFC 4718, October 2006. 3278 [RFC4764] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: a 3279 Pre-Shared Key Extensible Authentication Protocol (EAP) 3280 Method", RFC 4764, January 2007. 3282 [RFC3576bis] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. 3283 Aboba, "Dynamic Authorization Extensions to Remote 3284 Authentication Dial In User Service (RADIUS)", draft- 3285 ietf-radext-rfc3576bis-13.txt, Internet draft (work in 3286 progress), October 2007. 3288 [SP800-57] National Institute of Standards and Technology, 3289 "Recommendation for Key Management", Special Publication 3290 800-57, May 2006. 3292 [Token] Fantacci, R., Maccari, L., Pecorella, T. and F. Frosali, 3293 "A secure and performant token-based authentication for 3294 infrastructure and mesh 802.1X networks", IEEE 3295 Conference on Computer Communications, June 2006. 3297 [Tokenk] Ohba, Y., Das, S. and A. Duttak, "Kerberized Handover 3298 Keying: A Media-Independent Handover Key Management 3299 Architecture", Mobiarch 2007. 3301 Acknowledgments 3303 Thanks to Ashwin Palekar, Charlie Kaufman and Tim Moore of Microsoft, 3304 Jari Arkko of Ericsson, Dorothy Stanley of Aruba Networks, Bob 3305 Moskowitz of TruSecure, Jesse Walker of Intel, Joe Salowey of Cisco 3306 and Russ Housley of Vigil Security for useful feedback. 3308 Authors' Addresses 3310 Bernard Aboba 3311 Microsoft Corporation 3312 One Microsoft Way 3313 Redmond, WA 98052 3315 EMail: bernarda@microsoft.com 3316 Phone: +1 425 706 6605 3317 Fax: +1 425 936 7329 3319 Dan Simon 3320 Microsoft Research 3321 Microsoft Corporation 3322 One Microsoft Way 3323 Redmond, WA 98052 3325 EMail: dansimon@microsoft.com 3326 Phone: +1 425 706 6711 3327 Fax: +1 425 936 7329 3329 Pasi Eronen 3330 Nokia Research Center 3331 P.O. Box 407 3332 FIN-00045 Nokia Group 3333 Finland 3335 EMail: pasi.eronen@nokia.com 3337 Appendix A - Exported Parameters in Existing Methods 3339 This Appendix specifies Session-Id, Peer-Id, Server-Id and Key- 3340 Lifetime for EAP methods that have been published prior to this 3341 specification. Future EAP method specifications MUST include a 3342 definition of the Session-Id, Peer-Id and Server-Id (could be the 3343 null string). 3345 EAP-Identity 3347 The EAP-Identity method is defined in [RFC3748]. It does not derive 3348 keys, and therefore does not define the Session-Id. The Peer-Id and 3349 Server-Id are the null string (zero length). 3351 EAP-Notification 3353 The EAP-Notification method is defined in [RFC3748]. It does not 3354 derive keys and therefore does not define the Session-Id. The Peer- 3355 Id and Server-Id are the null string (zero length). 3357 EAP-MD5-Challenge 3359 The EAP-MD5-Challenge method is defined in [RFC3748]. It does not 3360 derive keys and therefore does not define the Session-Id. The Peer- 3361 Id and Server-Id are the null string (zero length). 3363 EAP-GTC 3365 The EAP-GTC method is defined in [RFC3748]. It does not derive keys 3366 and therefore does not define the Session-Id. The Peer-Id and 3367 Server-Id are the null string (zero length). 3369 EAP-OTP 3371 The EAP-OTP method is defined in [RFC3748]. It does not derive keys 3372 and therefore does not define the Session-Id. The Peer-Id and 3373 Server-Id are the null string (zero length). 3375 EAP-AKA 3377 EAP-AKA is defined in [RFC4187]. The EAP-AKA Session-Id is the 3378 concatenation of the EAP Type Code (0x17) with the contents of the 3379 RAND field from the AT_RAND attribute, followed by the contents of 3380 the AUTN field in the AT_AUTN attribute. 3382 The Peer-Id is the contents of the Identity field from the 3383 AT_IDENTITY attribute, using only the Actual Identity Length octets 3384 from the beginning, however. Note that the contents are used as they 3385 are transmitted, regardless of whether the transmitted identity was a 3386 permanent, pseudonym, or fast EAP re-authentication identity. The 3387 Server-Id is the null string (zero length). 3389 EAP-SIM 3391 EAP-SIM is defined in [RFC4186]. The EAP-SIM Session-Id is the 3392 concatenation of the EAP Type Code (0x12) with the contents of the 3393 RAND field from the AT_RAND attribute, followed by the contents of 3394 the NONCE_MT field in the AT_NONCE_MT attribute. 3396 The Peer-Id is the contents of the Identity field from the 3397 AT_IDENTITY attribute, using only the Actual Identity Length octets 3398 from the beginning, however. Note that the contents are used as they 3399 are transmitted, regardless of whether the transmitted identity was a 3400 permanent, pseudonym, or fast EAP re-authentication identity. The 3401 Server-Id is the null string (zero length). 3403 EAP-PSK 3405 EAP-PSK is defined in [RFC4764]. The EAP-PSK Session-Id is the 3406 concatenation of the EAP Type Code (0x2F) with the peer (RAND_P) and 3407 server (RAND_S) nonces. The Peer-Id is the contents of the ID_P 3408 field and the Server-Id is the contents of the ID_S field. 3410 EAP-SAKE 3412 EAP-SAKE is defined in [RFC4763]. The EAP-SAKE Session-Id is the 3413 concatenation of the EAP Type Code (0x30) with the contents of the 3414 RAND_S field from the AT_RAND_S attribute, followed by the contents 3415 of the RAND_P field in the AT_RAND_P attribute. Note that the EAP- 3416 SAKE Session-Id is not the same as the "Session ID" parameter chosen 3417 by the Server, which is sent in the first message, and replicated in 3418 subsequent messages. The Peer-Id is contained within the value field 3419 of the AT_PEERID attribute and the Server-Id, if available, is 3420 contained in the value field of the AT_SERVERID attribute. 3422 EAP-TLS 3424 For EAP-TLS, the Peer-Id, Server-Id and Session-Id are defined in [I- 3425 D.simon-emu-rfc2716bis]. 3427 Full Copyright Statement 3429 Copyright (C) The IETF Trust (2007). 3431 This document is subject to the rights, licenses and restrictions 3432 contained in BCP 78, and except as set forth therein, the authors 3433 retain all their rights. 3435 This document and the information contained herein are provided on an 3436 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3437 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 3438 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 3439 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 3440 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3441 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3443 Intellectual Property 3445 The IETF takes no position regarding the validity or scope of any 3446 Intellectual Property Rights or other rights that might be claimed to 3447 pertain to the implementation or use of the technology described in 3448 this document or the extent to which any license under such rights 3449 might or might not be available; nor does it represent that it has 3450 made any independent effort to identify any such rights. Information 3451 on the procedures with respect to rights in RFC documents can be 3452 found in BCP 78 and BCP 79. 3454 Copies of IPR disclosures made to the IETF Secretariat and any 3455 assurances of licenses to be made available, or the result of an 3456 attempt made to obtain a general license or permission for the use of 3457 such proprietary rights by implementers or users of this 3458 specification can be obtained from the IETF on-line IPR repository at 3459 http://www.ietf.org/ipr. 3461 The IETF invites any interested party to bring to its attention any 3462 copyrights, patents or patent applications, or other proprietary 3463 rights that may cover technology that may be required to implement 3464 this standard. Please address the information to the IETF at 3465 ietf-ipr@ietf.org. 3467 Acknowledgment 3469 Funding for the RFC Editor function is currently provided by the 3470 Internet Society. 3472 Open Issues 3474 Open issues relating to this specification are tracked on the 3475 following web site: 3477 http://www.drizzle.com/~aboba/EAP/