idnits 2.17.1 draft-ietf-eap-keying-22.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 3438. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3449. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3456. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3462. 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 (11 November 2007) is 6005 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) == 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 (~~), 4 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 11, 2008 Nokia 7 11 November 2007 9 Extensible Authentication Protocol (EAP) Key Management Framework 10 draft-ietf-eap-keying-22.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 11, 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 .............................................. 69 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 does 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 Sections 1.4, 2.4 and 2.5 as well as 617 in Appendix A. Key freshness is discussed in Sections 3.4, 3.5 and 618 5.7. 620 Completion of the AAA exchange (Phase 1b) results in the transport of 621 keying material from the EAP server (identified by the Server-Id(s)) 622 to the EAP authenticator (identified by the NAS-Identifier) without 623 disclosure to any other party. Both the EAP server and EAP 624 authenticator know this keying material to be fresh. Disclosure 625 issues are discussed in Sections 3.8 and 5.3; security properties of 626 AAA protocols are discussed in Sections 5.1-5.9. 628 The backend authentication server is trusted to transport keying 629 material only to the authenticator that was established with the 630 peer, and it is trusted to transport that keying material to no other 631 parties. In many systems, EAP keying material established by the EAP 632 peer and EAP server are combined with publicly available data to 633 derive other keys. The backend authentication server is trusted to 634 refrain from deriving these same keys or acting as a man-in-the- 635 middle even though it has access to the keying material that is 636 needed to do so. 638 The authenticator is also a trusted party. The authenticator is 639 trusted not to distribute keying material provided by the backend 640 authentication server to any other parties. If the authenticator 641 uses a key derivation function to derive additional keying material, 642 the authenticator is trusted to distribute the derived keying 643 material only to the appropriate party that is known to the peer, and 644 no other party. When this approach is used, care must be taken to 645 ensure that the resulting key management system meets all of the 646 principles in [RFC4962], confirming that keys used to protect data 647 are to be known only by the peer and authenticator. 649 Completion of the Secure Association Protocol (Phase 2) results in 650 the derivation or transport of Transient Session Keys (TSKs) known 651 only to the EAP peer (identified by the Peer-Id(s)) and authenticator 652 (identified by the NAS-Identifier). Both the EAP peer and 653 authenticator know the TSKs to be fresh. Both the EAP peer and 654 authenticator demonstrate that they are authorized to perform their 655 roles. Authorization issues are discussed in Sections 4.3.2 and 5.5; 656 security properties of Secure Association Protocols are discussed in 657 Section 3.1. 659 1.6. EAP Invariants 661 Certain basic characteristics, known as "EAP Invariants", hold true 662 for EAP implementations: 664 Mode independence 665 Media independence 666 Method independence 667 Ciphersuite independence 669 1.6.1. Mode Independence 671 EAP is typically deployed to support extensible network access 672 authentication in situations where a peer desires network access via 673 one or more authenticators. Where authenticators are deployed 674 standalone, the EAP conversation occurs between the peer and 675 authenticator, and the authenticator locally implements one or more 676 EAP methods. However, when utilized in "pass-through" mode, EAP 677 enables deployment of new authentication methods without requiring 678 development of new code on the authenticator. 680 While the authenticator can implement some EAP methods locally and 681 use those methods to authenticate local users, it can at the same 682 time act as a pass-through for other users and methods, forwarding 683 EAP packets back and forth between the backend authentication server 684 and the peer. This is accomplished by encapsulating EAP packets 685 within the Authentication, Authorization and Accounting (AAA) 686 protocol, spoken between the authenticator and backend authentication 687 server. AAA protocols supporting EAP include RADIUS [RFC3579] and 688 Diameter [RFC4072]. 690 It is a fundamental property of EAP that at the EAP method layer, the 691 conversation between the EAP peer and server is unaffected by whether 692 the EAP authenticator is operating in "pass-through" mode. EAP 693 methods operate identically in all aspects, including key derivation 694 and parameter import/export, regardless of whether the authenticator 695 is operating as a pass-through or not. 697 The successful completion of an EAP method that supports key 698 derivation results in the export of EAP keying material and 699 parameters on the EAP peer and server. Even though the EAP peer or 700 server can import channel binding parameters that can include the 701 identity of the EAP authenticator, this information is treated as 702 opaque octets. As a result, within EAP the only relevant identities 703 are the Peer-Id(s) and Server-Id(s). Channel binding parameters are 704 only interpreted by the lower layer. 706 Within EAP, the primary function of the AAA protocol is to maintain 707 the principle of mode independence. As far as the EAP peer is 708 concerned, its conversation with the EAP authenticator, and all 709 consequences of that conversation, are identical, regardless of the 710 authenticator mode of operation. 712 1.6.2. Media Independence 714 One of the goals of EAP is to allow EAP methods to function on any 715 lower layer meeting the criteria outlined in [RFC3748], Section 3.1. 716 For example, as described in [RFC3748], EAP authentication can be run 717 over PPP [RFC1661], IEEE 802 wired networks [IEEE-802.1X], and 718 wireless networks such as 802.11 [IEEE-802.11] and 802.16 719 [IEEE-802.16e]. 721 In order to maintain media independence, it is necessary for EAP to 722 avoid consideration of media-specific elements. For example, EAP 723 methods cannot be assumed to have knowledge of the lower layer over 724 which they are transported, and cannot be restricted to identifiers 725 associated with a particular usage environment (e.g. MAC addresses). 727 Note that media independence can be retained within EAP methods that 728 support Channel Binding or method-specific identification. An EAP 729 method need not be aware of the content of an identifier in order to 730 use it. This enables an EAP method to use media-specific identifiers 731 such as MAC addresses without compromising media independence. 732 Channel binding parameters are treated as opaque octets by EAP 733 methods, so that handling them does not require media-specific 734 knowledge. 736 1.6.3. Method Independence 738 By enabling pass-through, authenticators can support any method 739 implemented on the peer and server, not just locally implemented 740 methods. This allows the authenticator to avoid having to implement 741 the EAP methods configured for use by peers. In fact, since a pass- 742 through authenticator need not implement any EAP methods at all, it 743 cannot be assumed to support any EAP method-specific code. As noted 744 in [RFC3748] Section 2.3: 746 Compliant pass-through authenticator implementations MUST by 747 default forward EAP packets of any Type. 749 This is useful where there is no single EAP method that is both 750 mandatory-to-implement and offers acceptable security for the media 751 in use. For example, the [RFC3748] mandatory-to-implement EAP method 752 (MD5-Challenge) does not provide dictionary attack resistance, mutual 753 authentication or key derivation, and as a result is not appropriate 754 for use in Wireless Local Area Network (WLAN) authentication 755 [RFC4017]. However, despite this it is possible for the peer and 756 authenticator to interoperate as long as a suitable EAP method is 757 supported both on the EAP peer and server. 759 1.6.4. Ciphersuite Independence 761 Ciphersuite Independence is a requirement for Media Independence. 762 Since lower layer ciphersuites vary between media, media independence 763 requires that exported EAP keying material be large enough (with 764 sufficient entropy) to handle any ciphersuite. 766 While EAP methods can negotiate the ciphersuite used in protection of 767 the EAP conversation, the ciphersuite used for the protection of the 768 data exchanged after EAP authentication has completed is negotiated 769 between the peer and authenticator within the lower layer, outside of 770 EAP. 772 For example, within PPP, the ciphersuite is negotiated within the 773 Encryption Control Protocol (ECP) defined in [RFC1968], after EAP 774 authentication is completed. Within [IEEE-802.11], the AP 775 ciphersuites are advertised in the Beacon and Probe Responses prior 776 to EAP authentication, and are securely verified during a 4-way 777 handshake exchange. 779 Since the ciphersuites used to protect data depend on the lower 780 layer, requiring that EAP methods have knowledge of lower layer 781 ciphersuites would compromise the principle of Media Independence. 782 As a result, methods export EAP keying material that is ciphersuite- 783 independent. Since ciphersuite negotiation occurs in the lower 784 layer, there is no need for lower layer ciphersuite negotiation 785 within EAP. 787 In order to allow a ciphersuite to be usable within the EAP keying 788 framework, the ciphersuite specification needs to describe how TSKs 789 suitable for use with the ciphersuite are derived from exported EAP 790 keying material. To maintain Method Independence, algorithms for 791 deriving TSKs MUST NOT depend on the EAP method, although algorithms 792 for TEK derivation MAY be specific to the EAP method. 794 Advantages of ciphersuite-independence include: 796 Reduced update requirements 797 Ciphersuite independence enables EAP methods to be used with new 798 ciphersuites without requiring the methods to be updated. If EAP 799 methods were to specify how to derive transient session keys for 800 each ciphersuite, they would need to be updated each time a new 801 ciphersuite is developed. In addition, backend authentication 802 servers might not be usable with all EAP-capable authenticators, 803 since the backend authentication server would also need to be 804 updated each time support for a new ciphersuite is added to the 805 authenticator. 807 Reduced EAP method complexity 808 Ciphersuite independence enables EAP methods to avoid having to 809 include ciphersuite-specific code. Requiring each EAP method to 810 include ciphersuite-specific code for transient session key 811 derivation would increase method complexity and result in 812 duplicated effort. 814 Simplified configuration 815 Ciphersuite independence enables EAP method implementations on the 816 peer and server to avoid having to configure ciphersuite-specific 817 parameters. The ciphersuite is negotiated between the peer and 818 authenticator outside of EAP. Where the authenticator operates in 819 "pass-through" mode, the EAP server is not a party to this 820 negotiation, nor is it involved in the data flow between the EAP 821 peer and authenticator. As a result, the EAP server does not have 822 knowledge of the ciphersuites and negotiation policies implemented 823 by the peer and authenticator, nor is it aware of the ciphersuite 824 negotiated between them. For example, since Encryption Control 825 Protocol (ECP) negotiation occurs after authentication, when run 826 over PPP, the EAP peer and server cannot anticipate the negotiated 827 ciphersuite and therefore this information cannot be provided to 828 the EAP method. 830 2. Lower Layer Operation 832 On completion of EAP authentication, EAP keying material and 833 parameters exported by the EAP method are provided to the lower layer 834 and AAA layer (if present). These include the Master Session Key 835 (MSK), Extended Master Session Key (EMSK), Peer-Id(s), Server-Id(s) 836 and Session-Id. The Initialization Vector (IV) is deprecated, but 837 might be provided. 839 In order to preserve the security of EAP keying material derived 840 within methods, lower layers MUST NOT export keys passed down by EAP 841 methods. This implies that EAP keying material passed down to a 842 lower layer is for the exclusive use of that lower layer and MUST NOT 843 be used within another lower layer. This prevents compromise of one 844 lower layer from compromising other applications using EAP keying 845 material. 847 EAP keying material provided to a lower layer MUST NOT be transported 848 to another entity. For example, EAP keying material passed down to 849 the EAP peer lower layer MUST NOT leave the peer; EAP keying 850 material passed down or transported to the EAP authenticator lower 851 layer MUST NOT leave the authenticator. 853 On the EAP server, keying material and parameters requested by and 854 passed down to the AAA layer MAY be replicated to the AAA layer on 855 the authenticator (with the exception of the EMSK). On the 856 authenticator, the AAA layer provides the replicated keying material 857 and parameters to the lower layer over which the EAP authentication 858 conversation took place. This enables mode independence to be 859 maintained. 861 The EAP layer as well as the peer and authenticator layers MUST NOT 862 modify or cache keying material or parameters (including Channel 863 Bindings) passing in either direction between the EAP method layer 864 and the lower layer or AAA layer. 866 2.1. Transient Session Keys 868 Where explicitly supported by the lower layer, lower layers MAY cache 869 keying material, including exported EAP keying material and/or TSKs; 870 the structure of this key cache is defined by the lower layer. So as 871 to enable interoperability, new lower layer specifications MUST 872 describe key caching behavior. Unless explicitly specified by the 873 lower layer, the EAP peer, server and authenticator MUST assume that 874 peers and authenticators do not cache keying material. Existing EAP 875 lower layers and AAA layers handle the generation of transient 876 session keys and caching of EAP keying material in different ways: 878 IEEE 802.1X-2004 879 When used with wired networks, IEEE 802.1X-2004 [IEEE-802.1X] does 880 not support link layer ciphersuites and a result, it does not 881 provide for generation of TSKs, or caching of EAP keying material 882 and parameters. Once EAP authentication completes, it is assumed 883 that EAP keying material and parameters are discarded; on IEEE 802 884 wired networks there is no subsequent Secure Association Protocol 885 exchange. Perfect Forward Secrecy (PFS) is only possible if the 886 negotiated EAP method supports this. 888 PPP PPP, defined in [RFC1661], does not include support for a Secure 889 Association Protocol; nor does it support caching of EAP keying 890 material or parameters. PPP ciphersuites derive their TSKs 891 directly from the MSK, as described in [RFC2716]. This is NOT 892 RECOMMENDED, since if PPP were to support caching of EAP keying 893 material, this could result in TSK reuse. As a result, once the 894 PPP session is terminated, EAP keying material and parameters MUST 895 be discarded. Since caching of EAP keying material is not 896 permitted within PPP, there is no way to handle TSK re-key without 897 EAP re-authentication. Perfect Forward Secrecy (PFS) is only 898 possible if the negotiated EAP method supports this. 900 IKEv2 901 IKEv2, defined in [RFC4306], only uses the MSK for authentication 902 purposes and not key derivation. The EMSK, IV, Peer-Id, Server-Id 903 or Session-Id are not used. As a result, the TSKs derived by IKEv2 904 are cryptographically independent of the EAP keying material and 905 re-key of IPsec SAs can be handled without requiring EAP re- 906 authentication. Within IKEv2 it is possible to negotiate PFS, 907 regardless of which EAP method is negotiated. IKEv2 as specified 908 in [RFC4306] does not cache EAP keying material or parameters; once 909 IKEv2 authentication completes it is assumed that EAP keying 910 material and parameters are discarded. The Session-Timeout 911 attribute is therefore interpreted as a limit on the VPN session 912 time, rather than an indication of the MSK key lifetime. 914 IEEE 802.11 915 IEEE 802.11 enables caching of the MSK, but not the EMSK, IV, Peer- 916 Id, Server-Id, or Session-Id. More details about the structure of 917 the cache are available in [IEEE-802.11]. In IEEE 802.11, TSKs are 918 derived from the MSK using a Secure Association Protocol known as 919 the 4-way handshake, which includes a nonce exchange. This 920 guarantees TSK freshness even if the MSK is reused. The 4-way 921 handshake also enables TSK re-key without EAP re-authentication. 922 PFS is only possible within IEEE 802.11 if caching is not enabled 923 and the negotiated EAP method supports PFS. 925 IEEE 802.16e 926 IEEE 802.16e, defined in [IEEE-802.16e] supports caching of the 927 MSK, but not the EMSK, IV, Peer-Id, Server-Id or Session-Id. IEEE 928 802.16e support a Secure Association Protocol in which TSKs are 929 chosen by the authenticator without any contribution by the peer. 930 The TSKs are encrypted, authenticated and integrity protected using 931 the MSK and are transported from the authenticator to the peer. 932 TSK re-key is possible without EAP re-authentication. PFS is not 933 possible even if the negotiated EAP method supports it. 935 AAA Existing implementations and specifications for RADIUS/EAP 936 [RFC3579] or Diameter EAP [RFC4072] do not support caching of 937 keying material or parameters. In existing AAA client, proxy and 938 server implementations, exported EAP keying material (MSK, EMSK and 939 IV) as well as parameters and derived keys are not cached and MUST 940 be presumed lost after the AAA exchange completes. 942 In order to avoid key reuse, the AAA layer MUST delete transported 943 keys once they are sent. The AAA layer MUST NOT retain keys that 944 it has previously sent. For example, a AAA layer that has 945 transported the MSK MUST delete it, and keys MUST NOT be derived 946 from the MSK from that point forward. 948 2.2. Authenticator and Peer Architecture 950 This specification does not impose constraints on the architecture of 951 the EAP authenticator or peer. For example, any of the authenticator 952 architectures described in [RFC4118] can be used. As a result, lower 953 layers need to identify EAP peers and authenticators unambiguously, 954 without incorporating implicit assumptions about peer and 955 authenticator architectures. 957 For example, it is possible for multiple base stations and a 958 "controller" (e.g. WLAN switch) to comprise a single EAP 959 authenticator. In such a situation, the "base station identity" is 960 irrelevant to the EAP method conversation, except perhaps as an 961 opaque blob to be used in Channel Binding. Many base stations can 962 share the same authenticator identity. An EAP authenticator or peer: 964 (a) can contain one or more physical or logical ports; 965 (b) can advertise itself as one or more "virtual" 966 authenticators or peers; 967 (c) can utilize multiple CPUs; 968 (d) can support clustering services for load balancing or failover. 970 Both the EAP peer and authenticator can have more than one physical 971 or logical port. A peer can simultaneously access the network via 972 multiple authenticators, or via multiple physical or logical ports on 973 a given authenticator. Similarly, an authenticator can offer network 974 access to multiple peers, each via a separate physical or logical 975 port. When a single physical authenticator advertises itself as 976 multiple virtual authenticators, it is possible for a single physical 977 port to belong to multiple virtual authenticators. 979 An authenticator can be configured to communicate with more than one 980 EAP server, each of which is configured to communicate with a subset 981 of the authenticators. The situation is illustrated in Figure 3. 983 2.3. Authenticator Identification 985 The EAP method conversation is between the EAP peer and server. The 986 authenticator identity, if considered at all by the EAP method, is 987 treated as an opaque blob for the purpose of Channel Binding (see 988 Section 5.3.3). However, the authenticator identity is important in 989 two other exchanges - the AAA protocol exchange and the Secure 990 Association Protocol conversation. 992 The AAA conversation is between the EAP authenticator and the backend 993 authentication server. From the point of view of the backend 994 authentication server, keying material and parameters are transported 995 to the EAP authenticator identified by the NAS-Identifier attribute. 996 Since an EAP authenticator MUST NOT share EAP keying material or 997 parameters with another party, if the EAP peer or backend 998 authentication server detects use of EAP keying material and 999 parameters outside the scope defined by the NAS-Identifier, the 1000 keying material MUST be considered compromised. 1002 The Secure Association Protocol conversation is between the peer and 1003 the authenticator. For lower layers which support key caching it is 1004 particularly important for the EAP peer, authenticator and backend 1005 server to have a consistent view of the usage scope of the 1006 transported keying material. In order to enable this, it is 1007 RECOMMENDED that the Secure Association Protocol explicitly 1008 communicate the usage scope of the EAP keying material passed down to 1009 the lower layer, rather than implicitly assuming that this is defined 1010 by the authenticator and peer endpoint addresses. 1012 +-+-+-+-+ 1013 | EAP | 1014 | Peer | 1015 +-+-+-+-+ 1016 | | | Peer Ports 1017 / | \ 1018 / | \ 1019 / | \ 1020 / | \ 1021 / | \ 1022 / | \ 1023 / | \ 1024 / | \ Authenticator 1025 | | | | | | | | | Ports 1026 +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ 1027 | | | | | | 1028 | Auth1 | | Auth2 | | Auth3 | 1029 | | | | | | 1030 +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ 1031 \ | \ | 1032 \ | \ | 1033 \ | \ | 1034 EAP over AAA \ | \ | 1035 (optional) \ | \ | 1036 \ | \ | 1037 \ | \ | 1038 \ | \ | 1039 +-+-+-+-+-+ +-+-+-+-+-+ Backend 1040 | EAP | | EAP | Authentication 1041 | Server1 | | Server2 | Servers 1042 +-+-+-+-+-+ +-+-+-+-+-+ 1044 Figure 3: Relationship between EAP peer, authenticator and server 1046 Since an authenticator can have multiple ports, the scope of the 1047 authenticator key cache cannot be described by a single endpoint 1048 address. Similarly, where a peer can have multiple ports and sharing 1049 of EAP keying material and parameters between peer ports of the same 1050 link type is allowed, the extent of the peer key cache cannot be 1051 communicated by using a single endpoint address. Instead, it is 1052 RECOMMENDED that the EAP peer and authenticator consistently identify 1053 themselves utilizing explicit identifiers, rather than endpoint 1054 addresses or port identifiers. 1056 AAA protocols such as RADIUS [RFC3579] and Diameter [RFC4072] provide 1057 a mechanism for the identification of AAA clients; since the EAP 1058 authenticator and AAA client MUST be co-resident, this mechanism is 1059 applicable to the identification of EAP authenticators. 1061 RADIUS [RFC2865] requires that an Access-Request packet contain one 1062 or more of the NAS-Identifier, NAS-IP-Address and NAS-IPv6-Address 1063 attributes. Since a NAS can have more than one IP address, the NAS- 1064 Identifier attribute is RECOMMENDED for explicit identification of 1065 the authenticator, both within the AAA protocol exchange and the 1066 Secure Association Protocol conversation. 1068 Problems which can arise where the peer and authenticator implicitly 1069 identify themselves using endpoint addresses include the following: 1071 (a) It is possible that the peer will not be able to determine which 1072 authenticator ports are associated with which authenticators. As a 1073 result, the EAP peer will be unable to utilize the authenticator 1074 key cache in an efficient way, and will also be unable to determine 1075 whether EAP keying material has been shared outside its authorized 1076 scope, and therefore needs to be considered compromised. 1078 (b) It is possible that the authenticator will not be able to determine 1079 which peer ports are associated with which peers, preventing the 1080 peer from communicating with it utilizing multiple peer ports. 1082 (c) It is possible that the peer will not be able to determine which 1083 virtual authenticator it is communicating with. For example, 1084 multiple virtual authenticators can share a MAC address, but 1085 utilize different NAS-Identifiers. 1087 (d) It is possible that the authenticator will not be able to determine 1088 which virtual peer it is communicating with. Multiple virtual 1089 peers can share a MAC address, but utilize different Peer-Ids. 1091 (e) It is possible that the EAP peer and server will not be able to 1092 verify the authenticator identity via Channel Binding. 1094 For example, problems (a), (c) and (e) occur in [IEEE-802.11], which 1095 utilizes peer and authenticator MAC addresses within the 4-way 1096 handshake. Problems (b) and (d) do not occur since [IEEE-802.11] 1097 only allows a virtual peer to utilize a single port. 1099 The following steps enable lower layer identities to be securely 1100 verified by all parties: 1102 (f) Specify the lower layer parameters used to identify the 1103 authenticator and peer. As noted earlier, endpoint or port 1104 identifiers are not recommended for identification of the 1105 authenticator or peer when it is possible for them to have multiple 1106 ports. 1108 (g) Communicate the lower layer identities between the peer and 1109 authenticator within phase 0. This allows the peer and 1110 authenticator to determine the key scope if a key cache is 1111 utilized. 1113 (h) Communicate the lower layer authenticator identity between the 1114 authenticator and backend server within the NAS-Identifier 1115 attribute. 1117 (i) Include the lower layer identities within Channel Bindings (if 1118 supported) in phase 1a, ensuring that they are communicated between 1119 the EAP peer and server. 1121 (j) Support the integrity-protected exchange of identities within phase 1122 2a. 1124 (k) Utilize the advertised lower layer identities to enable the peer 1125 and authenticator to verify that keys are maintained within the 1126 advertised scope. 1128 2.3.1. Virtual Authenticators 1130 When a single physical authenticator advertises itself as multiple 1131 virtual authenticators, if the virtual authenticators do not maintain 1132 logically separate key caches, then by authenticating to one virtual 1133 authenticator, the peer can gain access to the other virtual 1134 authenticators sharing a key cache. 1136 For example, where a physical authenticator implements "Guest" and 1137 "Corporate Intranet" virtual authenticators, an attacker acting as a 1138 peer could authenticate with the "Guest" virtual authenticator and 1139 derive EAP keying material. If the "Guest" and "Corporate Intranet" 1140 virtual authenticators share a key cache, then the peer can utilize 1141 the EAP keying material derived for the "Guest" network to obtain 1142 access to the "Corporate Intranet" network. 1144 The following steps can be taken to mitigate this vulnerability: 1146 (a) Authenticators are REQUIRED to cache associated authorizations 1147 along with EAP keying material and parameters and to apply 1148 authorizations to the peer on each network access, regardless of 1149 which virtual authenticator is being accessed. This ensures that 1150 an attacker cannot obtain elevated privileges even where the key 1151 cache is shared between virtual authenticators, and a peer obtains 1152 access to one virtual authenticator utilizing a key cache entry 1153 created for use with another virtual authenticator. 1155 (b) It is RECOMMENDED that physical authenticators maintain separate 1156 key caches for each virtual authenticator. This ensures that a 1157 cache entry created for use with one virtual authenticator cannot 1158 be used for access to another virtual authenticator. Since a key 1159 cache entry can no longer be shared between virtual 1160 authentications, this step provides protection beyond that offered 1161 in (a). This is valuable in situations where authorizations are 1162 not used to enforce access limitations. For example, where access 1163 is limited using a filter installed on a router rather than using 1164 authorizations provided to the authenticator, a peer can gain 1165 unauthorized access to resources by exploiting a shared key cache 1166 entry. 1168 (c) It is RECOMMENDED that each virtual authenticator identify itself 1169 consistently to the peer and to the backend authentication server, 1170 so as to enable the peer to verify the authenticator identity via 1171 Channel Binding (see Section 5.3.3). 1173 (d) It is RECOMMENDED that each virtual authenticator identify itself 1174 distinctly, in order to enable the peer and backend server to tell 1175 them apart. For example, this can be accomplished by utilizing a 1176 distinct value of the NAS-Identifier attribute. 1178 2.4. Peer Identification 1180 As described in [RFC3748] Section 7.3, the peer identity provided in 1181 the EAP-Response/Identity can be different from the peer identities 1182 authenticated by the EAP method. For example, the identity provided 1183 in the EAP-Response/Identity can be a privacy identifier as described 1184 in "The Network Access Identifier" [RFC4282] Section 2. As noted in 1185 [RFC4284], it is also possible to utilize a Network Access Identifier 1186 (NAI) for the purposes of source routing; an NAI utilized for source 1187 routing is said to be "decorated" as described in [RFC4282] Section 1188 2.7. 1190 When EAP peer provides the Network Access Identity (NAI) within the 1191 EAP-Response/Identity, as described in [RFC3579], the authenticator 1192 copies the NAI included in the EAP-Response/Identity into the User- 1193 Name attribute included within the Access-Request. As the Access- 1194 Request is forwarded toward the backend authentication server, AAA 1195 proxies remove decoration from the NAI included in the User-Name 1196 Attribute; the NAI included within the EAP-Response/Identity 1197 encapsulated in the Access-Request remains unchanged. As a result, 1198 when the Access-Request arrives at the backend authentication server, 1199 the EAP-Response/Identity can differ from the User-Name Attribute 1200 (which can have some or all of the decoration removed). In the 1201 absence of a Peer-Id, the backend authentication server SHOULD use 1202 the contents of the User-Name Attribute, rather than the EAP- 1203 Response/Identity as the peer identity. 1205 It is possible for more than one Peer-Id to be exported by an EAP 1206 method. For example, a peer certificate can contain more than one 1207 peer identity; in a tunnel method peer identities can be 1208 authenticated both within an outer and inner exchange and these 1209 identities could be different in type and contents. For example, an 1210 outer exchange could provide a Peer-Id in the form of an RDN, whereas 1211 an inner exchange could identify the peer via its NAI or MAC address. 1212 Where EAP keying material is determined solely from the outer 1213 exchange, only the outer Peer-Id(s) are exported; where the EAP 1214 keying material is determined from both the inner and outer 1215 exchanges, then both the inner and outer Peer-Id(s) are exported by 1216 the tunnel method. 1218 2.5. Server Identification 1220 It is possible for more than one Server-Id to be exported by an EAP 1221 method. For example, a server certificate can contain more than one 1222 server identity; in a tunnel method server identities could be 1223 authenticated both within an outer and inner exchange and these 1224 identities could be different in type and contents. For example, an 1225 outer exchange could provide a Server-Id in the form of an IP 1226 address, whereas an inner exchange could identify the server via its 1227 FQDN or hostname. Where EAP keying material is determined solely 1228 from the outer exchange, only the outer Server-Id(s) are exported by 1229 the EAP method; where the EAP keying material is determined from both 1230 the inner and outer exchanges, then both the inner and outer Server- 1231 Id(s) are exported by the EAP method. 1233 As shown in Figure 3, an authenticator can be configured to 1234 communicate with multiple EAP servers; the EAP server that an 1235 authenticator communicates with can vary according to configuration 1236 and network and server availability. While the EAP peer can assume 1237 that all EAP servers within a realm have access to the credentials 1238 necessary to validate an authentication attempt, it cannot assume 1239 that all EAP servers share persistent state. 1241 Authenticators can be configured with different primary or secondary 1242 EAP servers, in order to balance the load. Also, the authenticator 1243 can dynamically determine the EAP server to which requests will be 1244 sent; in event of a communication failure, the authenticator can fail 1245 over to another EAP server. For example, in Figure 3, Authenticator2 1246 can be initially configured with EAP server1 as its primary backend 1247 authentication server, and EAP server2 as the backup, but if EAP 1248 server1 becomes unavailable, EAP server2 can become the primary 1249 server. 1251 In general, the EAP peer cannot direct an authentication attempt to a 1252 particular EAP server within a realm; this decision is made by AAA 1253 clients. Nor can the peer determine which EAP server it will be 1254 communicating with, prior to the start of the EAP method 1255 conversation. The Server-Id is not included in the EAP- 1256 Request/Identity, and since the EAP server may be determined 1257 dynamically, it typically is not possible for the authenticator to 1258 advertise the Server-Id during the discovery phase. Some EAP methods 1259 do not export the Server-Id so that is is possible that the EAP peer 1260 will not learn which server it was conversing with after the EAP 1261 conversation completes successfully. 1263 As a result, an EAP peer, on connecting to a new authenticator or 1264 reconnecting to the same authenticator, can find itself communicating 1265 with a different EAP server. Fast reconnect, defined in [RFC3748] 1266 Section 7.2, can fail if the EAP server that the peer communicates 1267 with is not the same one with which it initially established a 1268 security association. For example, an EAP peer attempting an EAP-TLS 1269 session resume can find that the new EAP-TLS server will not have 1270 access to the TLS Master Key identified by the TLS Session-Id, and 1271 therefore the session resumption attempt will fail, requiring 1272 completion of a full EAP-TLS exchange. 1274 EAP methods that export the Server-Id MUST authenticate the server. 1275 However, not all EAP methods supporting mutual authentication provide 1276 a non-null Server-Id; some methods only enable the EAP peer to verify 1277 that the EAP server possesses a long-term secret, but do not provide 1278 the identity of the EAP server. In this case the EAP peer will know 1279 that an authenticator has been authorized by an EAP server, but will 1280 not confirm the identity of the EAP server. Where the EAP method 1281 does not provide a Server-Id, the peer cannot identify the EAP server 1282 with which it generated keying material. This can make it difficult 1283 for the EAP peer to identify the location of a key possessed by that 1284 EAP server. 1286 As noted in [I-D.simon-emu-rfc2716bis] Section 5.2, EAP methods 1287 supporting authentication using server certificates can determine the 1288 Server-Id from the subject or subjectAltName fields in the server 1289 certificate. Validating the EAP server identity can help the EAP 1290 peer to decide whether a specific EAP server is authorized. In some 1291 cases, such as where the certificate extensions defined in [RFC4334] 1292 are included in the server certificate, it can even be possible for 1293 the peer to verify some Channel Binding parameters from the server 1294 certificate. 1296 It is possible for problems to arise in situations where the EAP 1297 server identifies itself differently to the EAP peer and 1298 authenticator. For example, it is possible that the Server-Id 1299 exported by EAP methods will not be identical to the Fully Qualified 1300 Domain Name (FQDN) of the backend authentication server. Where 1301 certificate-based authentication is used within RADIUS or Diameter, 1302 it is possible that the subjectAltName used in the backend 1303 authentication server certificate will not be identical to the 1304 Server-Id or backend authentication server FQDN. This is not 1305 normally an issue in EAP, as the authenticator will be unaware of the 1306 identities used between the EAP peer and server. However, this can 1307 be an issue for key caching, if the authenticator is expected to 1308 locate a backend authentication server corresponding to a Server-Id 1309 provided by an EAP peer. 1311 Where the backend authentication server FQDN differs from the 1312 subjectAltName in the backend authentication server certificate, it 1313 is possible that the AAA client will not be able to determine whether 1314 it is talking to the correct backend authentication server. Where 1315 the Server-Id and backend server FQDN differ, it is possible that the 1316 combination of the key scope (Peer-Id(s), Server- Id(s)) and EAP 1317 conversation identifier (Session-Id) will not be sufficient to 1318 determine where the key resides. For example, the authenticator can 1319 identify backend servers by their IP address (as occurs in RADIUS), 1320 or using a Fully Qualified Domain Name (as in Diameter). If the 1321 Server-Id does not correspond to the IP address or FQDN of a known 1322 backend authentication server, then it may not be possible to locate 1323 which backend authentication server possesses the key. 1325 3. Security Association Management 1327 EAP as defined in [RFC3748] supports key derivation, but does not 1328 provide for the management of lower layer security associations. 1329 Missing functionality includes: 1331 (a) Security Association negotiation. EAP does not negotiate lower 1332 layer unicast or multicast security associations, including 1333 cryptographic algorithms or traffic profiles. EAP methods only 1334 negotiate cryptographic algorithms for their own use, not for the 1335 underlying lower layers. EAP also does not negotiate the traffic 1336 profiles to be protected with the negotiated ciphersuites; in some 1337 cases the traffic to be protected can have lower layer source and 1338 destination addresses different from the lower layer peer or 1339 authenticator addresses. 1341 (b) Re-key. EAP does not support re-key of exported EAP keying 1342 material without EAP re-authentication, although EAP methods can 1343 support "fast reconnect" as defined in [RFC3748] Section 7.2.1. 1345 (c) Key delete/install semantics. EAP does not synchronize 1346 installation or deletion of keying material on the EAP peer and 1347 authenticator. 1349 (d) Lifetime negotiation. EAP does not support lifetime negotiation 1350 for exported EAP keying material, and existing EAP methods also do 1351 not support key lifetime negotiation. 1353 (e) Guaranteed TSK freshness. Without a post-EAP handshake, TSKs can 1354 be reused if EAP keying material is cached. 1356 These deficiencies are typically addressed via a post-EAP handshake 1357 known as the Secure Association Protocol. 1359 3.1. Secure Association Protocol 1361 Since neither EAP nor EAP methods provide for establishment of lower 1362 layer security associations, it is RECOMMENDED that these facilities 1363 be provided within the Secure Association Protocol, including: 1365 (a) Entity Naming. A basic feature of a Secure Association Protocol is 1366 the explicit naming of the parties engaged in the exchange. 1367 Without explicit identification, the parties engaged in the 1368 exchange are not identified and the scope of the EAP keying 1369 parameters negotiated during the EAP exchange is undefined. 1371 (b) Mutual proof of possession of EAP keying material. During the 1372 Secure Association Protocol the EAP peer and authenticator MUST 1373 demonstrate possession of the keying material transported between 1374 the backend authentication server and authenticator (e.g. MSK), in 1375 order to demonstrate that the peer and authenticator have been 1376 authorized. Since mutual proof of possession is not the same as 1377 mutual authentication, the peer cannot verify authenticator 1378 assertions (including the authenticator identity) as a result of 1379 this exchange. Authenticator identity verification is discussed in 1380 Section 2.3. 1382 (c) Secure capabilities negotiation. In order to protect against 1383 spoofing during the discovery phase, ensure selection of the "best" 1384 ciphersuite, and protect against forging of negotiated security 1385 parameters, the Secure Association Protocol MUST support secure 1386 capabilities negotiation. This includes the secure negotiation of 1387 usage modes, session parameters (such as security association 1388 identifiers (SAIDs) and key lifetimes), ciphersuites and required 1389 filters, including confirmation of security-relevant capabilities 1390 discovered during phase 0. The Secure Association Protocol MUST 1391 support integrity and replay protection of all capability 1392 negotiation messages. 1394 (d) Key naming and selection. Where key caching is supported, it is 1395 possible for the EAP peer and authenticator to share more than one 1396 key of a given type. As a result, the Secure Association Protocol 1397 MUST explicitly name the keys used in the proof of possession 1398 exchange, so as to prevent confusion when more than one set of 1399 keying material could potentially be used as the basis for the 1400 exchange. Use of the key naming mechanism described in Section 1401 1.4.1 is RECOMMENDED. 1403 In order to support the correct processing of phase 2 security 1404 associations, the Secure Association (phase 2) protocol MUST 1405 support the naming of phase 2 security associations and associated 1406 transient session keys, so that the correct set of transient 1407 session keys can be identified for processing a given packet. The 1408 phase 2 Secure Association Protocol also MUST support transient 1409 session key activation and SHOULD support deletion, so that 1410 establishment and re-establishment of transient session keys can be 1411 synchronized between the parties. 1413 (e) Generation of fresh transient session keys (TSKs). Where the lower 1414 layer supports caching of keying material, the EAP peer lower layer 1415 can initiate a new session using keying material that was derived 1416 in a previous session. Were the TSKs to be derived solely from a 1417 portion of the exported EAP keying material, this would result in 1418 reuse of the session keys which could expose the underlying 1419 ciphersuite to attack. 1421 In lower layers where caching of keying material is supported, the 1422 Secure Association Protocol phase is REQUIRED, and MUST support the 1423 derivation of fresh unicast and multicast TSKs, even when the 1424 transported keying material provided by the backend authentication 1425 server is not fresh. This is typically supported via the exchange 1426 of nonces or counters, which are then mixed with the keying 1427 material in order to generate fresh unicast (phase 2a) and possibly 1428 multicast (phase 2b) session keys. By not using exported EAP 1429 keying material directly to protect data, the Secure Association 1430 Protocol protects it against compromise. 1432 (f) Key lifetime management. This includes explicit key lifetime 1433 negotiation or seamless re-key. EAP does not support re-key of EAP 1434 keying material without re-authentication and existing EAP methods 1435 do not support key lifetime negotiation. As a result, the Secure 1436 Association Protocol MAY handle re-key and determination of the key 1437 lifetime. Where key caching is supported, secure negotiation of 1438 key lifetimes is RECOMMENDED. Lower layers that support re-key, 1439 but not key caching, may not require key lifetime negotiation. For 1440 example, a difference between IKEv1 [RFC2409] and IKEv2 [RFC4306] 1441 is that in IKEv1 SA lifetimes were negotiated; in IKEv2, each end 1442 of the SA is responsible for enforcing its own lifetime policy on 1443 the SA and re-keying the SA when necessary. 1445 (g) Key state resynchronization. It is possible for the peer or 1446 authenticator to reboot or reclaim resources, clearing portions or 1447 all of the key cache. Therefore, key lifetime negotiation cannot 1448 guarantee that the key cache will remain synchronized, and it may 1449 not be possible for the peer to determine before attempting to use 1450 a key whether it exists within the authenticator cache. It is 1451 therefore RECOMMENDED for the EAP lower layer to provide a 1452 mechanism for key state resynchronization, either via the SAP or 1453 using a lower layer indication (see [RFC3748] Section 3.4). Where 1454 the peer and authenticator do not jointly possess a key with which 1455 to protect the resynchronization exchange, secure resynchronization 1456 is not possible and alternatives (such as a initiation of EAP re- 1457 authentication after expiration of a timer) is needed to ensure 1458 timely resynchronization. 1460 (h) Key scope synchronization. To support key scope determination, the 1461 Secure Association Protocol SHOULD provide a mechanism by which the 1462 peer can determine the scope of the key cache on each 1463 authenticator, and by which the authenticator can determine the 1464 scope of the key cache on a peer. This includes negotiation of 1465 restrictions on key usage. 1467 (i) Traffic profile negotiation. The traffic to be protected by a 1468 lower layer security association will not necessarily have the same 1469 lower layer source or destination address as the EAP peer and 1470 authenticator, and it is possible for the peer and authenticator to 1471 negotiate multiple security associations, each with a different 1472 traffic profile. Where this is the case, the profile of protected 1473 traffic SHOULD be explicitly negotiated. For example, in IKEv2 it 1474 is possible for an Initiator and Responder to utilize EAP for 1475 authentication, then negotiate a Tunnel Mode Security Association 1476 (SA) which permits passing of traffic originating from hosts other 1477 than the Initiator and Responder. Similarly, in IEEE 802.16e a 1478 Subscriber Station (SS) can forward traffic to the Base Station 1479 (BS) which originates from the Local Area Network (LAN) to which it 1480 is attached. To enable this, Security Associations within IEEE 1481 802.16e are identified by the Connection Identifier (CID), not by 1482 the EAP peer and authenticator MAC addresses. In both IKEv2 and 1483 IEEE 802.16e, multiple security associations can exist between the 1484 EAP peer and authenticator, each with their own traffic profile and 1485 quality of service parameters. 1487 (j) Direct operation. Since the phase 2 Secure Association Protocol is 1488 concerned with the establishment of security associations between 1489 the EAP peer and authenticator, including the derivation of 1490 transient session keys, only those parties have "a need to know" 1491 the transient session keys. The Secure Association Protocol MUST 1492 operate directly between the peer and authenticator, and MUST NOT 1493 be passed-through to the backend authentication server, or include 1494 additional parties. 1496 (k) Bi-directional operation. While some ciphersuites only require a 1497 single set of transient session keys to protect traffic in both 1498 directions, other ciphersuites require a unique set of transient 1499 session keys in each direction. The phase 2 Secure Association 1500 Protocol SHOULD provide for the derivation of unicast and multicast 1501 keys in each direction, so as not to require two separate phase 2 1502 exchanges in order to create a bi-directional phase 2 security 1503 association. See [RFC3748] Section 2.4 for more discussion. 1505 3.2. Key Scope 1507 Absent explicit specification within the lower layer, after the 1508 completion of phase 1b, transported keying material and parameters 1509 are bound to the EAP peer and authenticator, but are not bound to a 1510 specific peer or authenticator port. 1512 While EAP keying material passed down to the lower layer is not 1513 intrinsically bound to particular authenticator and peer ports, TSKs 1514 MAY be bound to particular authenticator and peer ports by the Secure 1515 Association Protocol. However, a lower layer MAY also permit TSKs to 1516 be used on multiple peer and/or authenticator ports, providing that 1517 TSK freshness is guaranteed (such as by keeping replay counter state 1518 within the authenticator). 1520 In order to further limit the key scope the following measures are 1521 suggested: 1523 (a) The lower layer MAY specify additional restrictions on key usage, 1524 such as limiting the use of EAP keying material and parameters on 1525 the EAP peer to the port over which on the EAP conversation was 1526 conducted. 1528 (b) The backend authentication server and authenticator MAY implement 1529 additional attributes in order to further restrict the scope of 1530 keying material. For example, in IEEE 802.11, the backend 1531 authentication server can provide the authenticator with a list of 1532 authorized Called or Calling-Station-Ids and/or SSIDs for which 1533 keying material is valid. 1535 (c) Where the backend authentication server provides attributes 1536 restricting the key scope, it is RECOMMENDED that restrictions be 1537 securely communicated by the authenticator to the peer. This can 1538 be accomplished using the Secure Association Protocol, but also 1539 can be accomplished via the EAP method or the lower layer. 1541 3.3. Parent-Child Relationships 1543 When an EAP re-authentication takes place, new EAP keying material is 1544 exported by the EAP method. In EAP lower layers where EAP re- 1545 authentication eventually results in TSK replacement, the maximum 1546 lifetime of derived keying material (including TSKs) can be less than 1547 or equal to that of EAP keying material (MSK/EMSK), but it cannot be 1548 greater. 1550 Where TSKs are derived from or are wrapped by exported EAP keying 1551 material, compromise of that exported EAP keying material implies 1552 compromise of TSKs. Therefore if EAP keying material is considered 1553 stale, not only SHOULD EAP re-authentication be initiated, but also 1554 replacement of child keys, including TSKs. 1556 Where EAP keying material is used only for entity authentication but 1557 not for TSK derivation (as in IKEv2), compromise of exported EAP 1558 keying material does not imply compromise of the TSKs. Nevertheless, 1559 the compromise of EAP keying material could enable an attacker to 1560 impersonate an authenticator, so that EAP re-authentication and TSK 1561 re-key are RECOMMENDED. 1563 With respect to IKEv2, "IKEv2 Clarifications and Implementation 1564 Guidelines" [RFC4718] Section 5.2 states: 1566 Rekeying the IKE-SA and reuathentication are different concepts in 1567 IKEv2. Rekeying the IKE_SA establishes new keys for the IKE_SA 1568 and resets the Message ID counters, but it does not authenticate 1569 the parties again (no AUTH or EAP payloads are involved)... This 1570 means that reauthentication also establishes new keys for the 1571 IKE_SA and CHILD_SAs. Therefore while rekeying can be performed 1572 more often than reauthentication, the situation where 1573 "authentication lifetime" is shorter than "key lifetime" does not 1574 make sense. 1576 Child keys that are used frequently (such as TSKs which are used for 1577 traffic protection) can expire sooner than the exported EAP keying 1578 material they are dependent on, so that it is advantageous to support 1579 re-key of child keys prior to EAP re-authentication. Note that 1580 deletion of the MSK/EMSK does not necessarily imply deletion of TSKs 1581 or child keys. 1583 Failure to mutually prove possession of exported EAP keying material 1584 during the Secure Association Protocol exchange need not be grounds 1585 for deletion of keying material by both parties; rate-limiting Secure 1586 Association Protocol exchanges could be used to prevent a brute force 1587 attack. 1589 3.4. Local Key Lifetimes 1591 The Transient EAP Keys (TEKs) are session keys used to protect the 1592 EAP conversation. The TEKs are internal to the EAP method and are 1593 not exported. TEKs are typically created during an EAP conversation, 1594 used until the end of the conversation and then discarded. However, 1595 methods can re-key TEKs during an EAP conversation. 1597 When using TEKs within an EAP conversation or across conversations, 1598 it is necessary to ensure that replay protection and key separation 1599 requirements are fulfilled. For instance, if a replay counter is 1600 used, TEK re-key MUST occur prior to wrapping of the counter. 1601 Similarly, TSKs MUST remain cryptographically separate from TEKs 1602 despite TEK re-keying or caching. This prevents TEK compromise from 1603 leading directly to compromise of the TSKs and vice versa. 1605 EAP methods MAY cache local EAP keying material (TEKs) which can 1606 persist for multiple EAP conversations when fast reconnect is used 1607 [RFC3748]. For example, EAP methods based on TLS (such as EAP-TLS 1608 [I-D.simon-emu-rfc2716bis]) derive and cache the TLS Master Secret, 1609 typically for substantial time periods. The lifetime of other local 1610 EAP keying material calculated within the EAP method is defined by 1611 the method. Note that in general, when using fast reconnect, there 1612 is no guarantee to that the original long-term credentials are still 1613 in the possession of the peer. For instance, a smart-card holding 1614 the private key for EAP-TLS can have been removed. EAP servers 1615 SHOULD also verify that the long-term credentials are still valid, 1616 such as by checking that certificate used in the original 1617 authentication has not yet expired. 1619 3.5. Exported and Calculated Key Lifetimes 1621 The following mechanisms are available for communicating the lifetime 1622 of keying material between the EAP peer, server and authenticator: 1624 AAA protocols (backend server and authenticator) 1625 Lower layer mechanisms (authenticator and peer) 1626 EAP method-specific negotiation (peer and server) 1628 Where the EAP method does not support the negotiation of the lifetime 1629 of exported EAP keying material, and a key lifetime negotiation 1630 mechanism is not provided by the lower layer, it is possible that 1631 there will not be a way for the peer to learn the lifetime of keying 1632 material. This can leave the peer uncertain how long the 1633 authenticator will maintain keying material within the key cache. In 1634 this case the lifetime of keying material can be managed as a system 1635 parameter on the peer and authenticator; a default lifetime of 8 1636 hours is RECOMMENDED. 1638 3.5.1. AAA Protocols 1640 AAA protocols such as RADIUS [RFC2865] and Diameter [RFC4072] can be 1641 used to communicate the maximum key lifetime from the backend 1642 authentication server to the authenticator. 1644 The Session-Timeout attribute is defined for RADIUS in [RFC2865] and 1645 for Diameter in [RFC4005]. Where EAP is used for authentication, 1646 [RFC3580] Section 3.17 indicates that a Session-Timeout attribute 1647 sent in an Access-Accept along with a Termination-Action value of 1648 RADIUS-Request specifies the maximum number of seconds of service 1649 provided prior to EAP re-authentication. 1651 However, there is also a need to be able to specify the maximum 1652 lifetime of cached keying material. Where EAP pre-authentication is 1653 supported, cached keying material can be pre-established on the 1654 authenticator prior to session start, and will remain there until 1655 expiration. EAP lower layers supporting caching of keying material 1656 MAY also persist that material after the end of a session, enabling 1657 the peer to subsequently resume communication utilizing the cached 1658 keying material. In these situations it can be desirable for the 1659 backend authentication server to specify the maximum lifetime of 1660 cached keying material. 1662 To accomplish this, [IEEE-802.11] overloads the Session-Timeout 1663 attribute, assuming that it represents the maximum time after which 1664 transported keying material will expire on the authenticator, 1665 regardless of whether transported keying material is cached. 1667 An IEEE 802.11 authenticator receiving transported keying material is 1668 expected to initialize a timer to the Session-Timeout value, and once 1669 the timer expires, the transported keying material expires. Whether 1670 this results in session termination or EAP re-authentication is 1671 controlled by the value of the Termination-Action attribute. Where 1672 EAP re-authentication occurs the transported keying material is 1673 replaced, and with it, new calculated keys are put in place. Where 1674 session termination occurs, transported and derived keying material 1675 is deleted. 1677 Overloading the Session-Timeout attribute is problematic in 1678 situations where it is necessary to control the maximum session time 1679 and key lifetime independently. For example, it might be desirable 1680 to limit the lifetime of cached keying material to 5 minutes while 1681 permitting a user once authenticated to remain connected for up to an 1682 hour without re-authenticating. As a result, in the future 1683 additional attributes can be specified to control the lifetime of 1684 cached keys; these attributes MAY modify the meaning of the Session- 1685 Timeout attribute in specific circumstances. 1687 Since the TSK lifetime is often determined by authenticator 1688 resources, and the backend authentication server has no insight into 1689 the TSK derivation process, by the principle of ciphersuite 1690 independence, it is not appropriate for the backend authentication 1691 server to manage any aspect of the TSK derivation process, including 1692 the TSK lifetime. 1694 3.5.2. Lower Layer Mechanisms 1696 Lower layer mechanisms can be used to enable the lifetime of keying 1697 material to be negotiated between the peer and authenticator. This 1698 can be accomplished either using the Secure Association Protocol or 1699 within the lower layer transport. 1701 Where TSKs are established as the result of a Secure Association 1702 Protocol exchange, it is RECOMMENDED that the Secure Association 1703 Protocol include support for TSK re-key. Where the TSK is taken 1704 directly from the MSK, there is no need to manage the TSK lifetime as 1705 a separate parameter, since the TSK lifetime and MSK lifetime are 1706 identical. 1708 3.5.3. EAP Method-Specific Negotiation 1710 As noted in [RFC3748] Section 7.10: 1712 In order to provide keying material for use in a subsequently 1713 negotiated ciphersuite, an EAP method supporting key derivation 1714 MUST export a Master Session Key (MSK) of at least 64 octets, and 1715 an Extended Master Session Key (EMSK) of at least 64 octets. EAP 1716 Methods deriving keys MUST provide for mutual authentication 1717 between the EAP peer and the EAP Server. 1719 However, EAP does not itself support the negotiation of lifetimes for 1720 exported EAP keying material such as the MSK, EMSK and IV. 1722 While EAP itself does not support lifetime negotiation, it would be 1723 possible to specify methods that do. However, systems that rely on 1724 key lifetime negotiation within EAP methods would only function with 1725 these methods. Also, there is no guarantee that the key lifetime 1726 negotiated within the EAP method would be compatible with backend 1727 authentication server policy. In the interest of method independence 1728 and compatibility with backend server implementations, management of 1729 the lifetime of keying material SHOULD NOT be provided within EAP 1730 methods. 1732 3.6. Key Cache Synchronization 1734 Key lifetime negotiation alone cannot guarantee key cache 1735 synchronization. Even where a lower layer exchange is run 1736 immediately after EAP in order to determine the lifetime of keying 1737 material, it is still possible for the authenticator to purge all or 1738 part of the key cache prematurely (e.g. due to reboot or need to 1739 reclaim memory). 1741 The lower layer can utilize the Discovery phase 0 to improve key 1742 cache synchronization. For example, if the authenticator manages the 1743 key cache by deleting the oldest key first, the relative creation 1744 time of the last key to be deleted could be advertised within the 1745 Discovery phase, enabling the peer to determine whether keying 1746 material had been prematurely expired from the authenticator key 1747 cache. 1749 3.7. Key Strength 1751 As noted in Section 2.1, EAP lower layers determine TSKs in different 1752 ways. Where exported EAP keying material is utilized in the 1753 derivation, encryption or authentication of TSKs, it is possible for 1754 EAP key generation to represent the weakest link. 1756 In order to ensure that methods produce EAP keying material of an 1757 appropriate symmetric key strength, it is RECOMMENDED that EAP 1758 methods utilizing public key cryptography choose a public key that 1759 has a cryptographic strength providing the required level of attack 1760 resistance. This is typically provided by configuring EAP methods, 1761 since there is no coordination between the lower layer and EAP method 1762 with respect to minimum required symmetric key strength. 1764 BCP 86 [RFC3766] Section 5 offers advice on the required RSA or DH 1765 module and DSA subgroup size in bits, for a given level of attack 1766 resistance in bits. The National Institute for Standards and 1767 Technology (NIST) also offers advice on appropriate key sizes in 1768 [SP800-57]. 1770 3.8. Key Wrap 1772 The key wrap specified in [RFC2548], which is based on an MD5-based 1773 stream cipher, has known problems, as described in [RFC3579] Section 1774 4.3. RADIUS uses the shared secret for multiple purposes, including 1775 per-packet authentication and attribute hiding, considerable 1776 information is exposed about the shared secret with each packet. 1777 This exposes the shared secret to dictionary attacks. MD5 is used 1778 both to compute the RADIUS Response Authenticator and the Message- 1779 Authenticator attribute, and concerns exist relating to the security 1780 of this hash [MD5Collision]. 1782 As discussed in [RFC3579] Section 4.3, the security vulnerabilities 1783 of RADIUS are extensive, and therefore development of an alternative 1784 key wrap technique based on the RADIUS shared secret would not 1785 substantially improve security. As a result, [RFC3579] Section 4.2 1786 recommends running RADIUS over IPsec. The same approach is taken in 1787 Diameter EAP [RFC4072], which defines clear-text key attributes, to 1788 be protected by IPsec or TLS. 1790 4. Handoff Vulnerabilities 1792 A handoff occurs when an EAP peer moves to a new authenticator. 1793 Several mechanisms have been proposed for reducing handoff latency 1794 within networks utilizing EAP. These include: 1796 EAP pre-authentication 1797 In EAP pre-authentication, an EAP peer pre-establishes EAP keying 1798 material with an authenticator prior to arrival. EAP pre- 1799 authentication only affects the timing of EAP authentication, but 1800 does not shorten or eliminate EAP (phase 1a) or AAA (phase 1b) 1801 exchanges; Discovery (phase 0) and Secure Association Protocol 1802 (phase 2) exchanges occur as described in Section 1.3. As a 1803 result, the primary benefit is to enable EAP authentication to be 1804 removed from the handoff critical path, thereby reducing latency. 1805 Use of EAP pre-authentication within IEEE 802.11 is described in 1806 [IEEE-802.11] and [8021XPreAuth]. 1808 Proactive key distribution 1809 In proactive key distribution, keying material and authorizations 1810 are transported from the backend authentication server to a 1811 candidate authenticator in advance of a handoff. As a result, EAP 1812 (phase 1a) is not needed, but the Discovery (phase 0), and Secure 1813 Association Protocol exchanges (phase 2) are still necessary. 1814 Within the AAA exchange (phase 1b), authorization and key 1815 distribution functions are typically supported, but not 1816 authentication. Proactive key distribution is described in 1817 [MishraPro], [IEEE-03-084] and [I-D.irtf-aaaarch-handoff]. 1819 Key caching 1820 Caching of EAP keying material enables an EAP peer to re-attach to 1821 an authenticator without requiring EAP (phase 1a) or AAA (phase 1b) 1822 exchanges. However, Discovery (phase 0) and Secure Association 1823 Protocol (phase 2) exchanges are still needed. Use of key caching 1824 within IEEE 802.11 is described in [IEEE-802.11]. 1826 Context transfer 1827 In context transfer schemes, keying material and authorizations are 1828 transferred between a previous authenticator and a new 1829 authenticator. This can occur in response to a handoff request by 1830 the EAP peer, or in advance, as in proactive key distribution. As 1831 a result, EAP (phase 1a) is eliminated, but not the Discovery 1832 (phase 0) or Secure Association Protocol exchanges (phase 2). If a 1833 secure channel can be established between the new and previous 1834 authenticator without assistance from the backend authentication 1835 server, then the AAA exchange (phase 1b) can be eliminated; 1836 otherwise, it is still needed, although it can be shortened. 1837 Context transfer protocols are described in [IEEE-802.11F] (now 1838 deprecated) and "Context Transfer Protocol (CXTP)" [RFC4067]. 1839 "Fast Authentication Methods for Handovers between IEEE 802.11 1840 Wireless LANs" [Bargh] analyzes fast handoff techniques, including 1841 context transfer mechanisms. 1843 Token distribution 1844 In token distribution schemes the EAP peer is provided with a 1845 credential, subsequently enabling it to authenticate with one or 1846 more additional authenticators. During the subsequent 1847 authentications, EAP (phase 1a) is eliminated or shortened; the 1848 Discovery (phase 0) and Secure Association Protocol exchanges 1849 (phase 2) still occur, although the latter can be shortened. If 1850 the token includes authorizations and can be validated by an 1851 authenticator without assistance from the backend authentication 1852 server, then the AAA exchange (phase 1b) can be eliminated; 1853 otherwise it is still needed, although it can be shortened. Token- 1854 based schemes, initially proposed in early drafts of IEEE 802.11i 1855 [IEEE-802.11i], are described in [Token], [Tokenk] and 1856 [I-D.friedman-ike-short-term-certs]. 1858 The sections that follow discuss the security vulnerabilities 1859 introduced by the above schemes. 1861 4.1. EAP Pre-authentication 1863 EAP pre-authentication differs from a normal EAP conversation 1864 primarily with respect to the lower layer encapsulation. For 1865 example, in [IEEE-802.11], EAP pre-authentication frames utilize a 1866 distinct Ethertype, but otherwise conforms to the encapsulation 1867 described in [IEEE-802.1X]. As a result, an EAP pre-authentication 1868 conversation differs little from the model described in Section 1.3, 1869 other than the introduction of a delay between phase 1 and phase 2. 1871 EAP pre-authentication relies on lower layer mechanisms for discovery 1872 of candidate authenticators. Where discovery can provide information 1873 on candidate authenticators outside the immediate listening range, 1874 and the peer can determine whether it already possesses valid EAP 1875 keying material with candidate authenticators, the peer can avoid 1876 unnecessary EAP pre-authentications and can establish EAP keying 1877 material well in advance, regardless of the coverage overlap between 1878 authenticators. However, if the peer can only discover candidate 1879 authenticators within listening range and cannot determine whether it 1880 can reuse existing EAP keying material, then it is possible that the 1881 peer will not be able to complete EAP pre-authentication prior to 1882 connectivity loss or that it can pre-authenticate multiple times with 1883 the same authenticator, increasing backend authentication server 1884 load. 1886 Since a peer can complete EAP pre-authentication with an 1887 authenticator without eventually attaching to it, it is possible that 1888 phase 2 will not occur. In this case an Accounting-Request 1889 signifying the start of service will not be sent, or will only be 1890 sent with a substantial delay after the completion of authentication. 1892 As noted in "IEEE 802.1X RADIUS Usage Guidelines" [RFC3580], the AAA 1893 exchange resulting from EAP pre-authentication differs little from an 1894 ordinary exchange described in "RADIUS Support for EAP" [RFC3579]. 1895 For example, since in IEEE 802.11 [IEEE-802.11] an Association 1896 exchange does not occur prior to EAP pre-authentication, the SSID is 1897 not known by the authenticator at authentication time, so that an 1898 Access-Request cannot include the SSID within the Called-Station-Id 1899 attribute as described in [RFC3580] Section 3.20. 1901 Since only the absence of an SSID in the Called-Station-Id attribute 1902 distinguishes an EAP pre-authentication attempt, if the authenticator 1903 does not always include the SSID for a normal EAP authentication 1904 attempt, it is possible that the backend authentication server will 1905 not be able to determine whether a session constitutes an EAP pre- 1906 authentication attempt, potentially resulting in authorization or 1907 accounting problems. Where the number of simultaneous sessions is 1908 limited, the backend authentication server can refuse to authorize a 1909 valid EAP pre-authentication attempt or can enable the peer to engage 1910 in more simultaneous sessions than they are authorized for. Where 1911 EAP pre-authentication occurs with an authenticator which the peer 1912 never attaches to, it is possible that the backend accounting server 1913 will not be able to determine whether the absence of an Accounting- 1914 Request was due to packet loss or a session that never started. 1916 In order to enable pre-authentication requests to be handled more 1917 reliably, it is RECOMMENDED that AAA protocols explicitly identify 1918 EAP pre-authentication. In order to suppress unnecessary EAP pre- 1919 authentication exchanges, it is RECOMMENDED that authenticators 1920 unambiguously identify themselves as described in Section 2.3. 1922 4.2. Proactive Key Distribution 1924 In proactive key distribution schemes, the backend authentication 1925 server transports keying material and authorizations to an 1926 authenticator in advance of the arrival of the peer. The 1927 authenticators selected to receive the transported key material are 1928 selected based on past patterns of peer movement between 1929 authenticators known as the "neighbor graph". In order to reduce 1930 handoff latency, proactive key distribution schemes typically only 1931 demonstrate proof of possession of transported keying material 1932 between the EAP peer and authenticator. During a handoff, the 1933 backend authentication server is not provided with proof that the 1934 peer successfully authenticated to an authenticator; instead, the 1935 authenticator generates a stream of accounting messages without a 1936 corresponding set of authentication exchanges. As described in 1937 [MishraPro], knowledge of the neighbor graph can be established via 1938 static configuration or analysis of authentication exchanges. In 1939 order to prevent corruption of the neighbor graph, new neighbor graph 1940 entries can only be created as the result of a successful EAP 1941 exchange, and accounting packets with no corresponding authentication 1942 exchange need to be verified to correspond to neighbor graph entries 1943 (e.g. corresponding to handoffs between neighbors). 1945 In order to prevent compromise of one authenticator from resulting in 1946 compromise of other authenticators, cryptographic separation needs 1947 to be maintained between the keying material transported to each 1948 authenticator. However, even where cryptographic separation is 1949 maintained, an attacker compromising an authenticator can still 1950 disrupt the operation of other authenticators. As noted in [RFC3579] 1951 Section 4.3.7, in the absence of spoofing detection within the AAA 1952 infrastructure, it is possible for EAP authenticators to impersonate 1953 each other. By forging NAS identification attributes within 1954 authentication messages, an attacker compromising one authenticator 1955 could corrupt the neighbor graph, tricking the backend authentication 1956 server into transporting keying material to arbitrary authenticators. 1957 While this would not enable recovery of EAP keying material without 1958 breaking fundamental cryptographic assumptions, it could enable 1959 subsequent fraudulent accounting messages, or allow an attacker to 1960 disrupt service by increasing load on the backend authentication 1961 server or thrashing the authenticator key cache. 1963 Since proactive key distribution requires the distribution of derived 1964 keying material to candidate authenticators, the effectiveness of 1965 this scheme depends on the ability of backend authentication server 1966 to anticipate the movement of the EAP peer. Since proactive key 1967 distribution relies on backend authentication server knowledge of the 1968 neighbor graph it is most applicable to intra-domain handoff 1969 scenarios. However, in inter-domain handoff where there can be many 1970 authenticators, peers can frequently connect to authenticators that 1971 have not been previously encountered, making it difficult for the 1972 backend authentication server to derive a complete neighbor graph. 1974 Since proactive key distribution schemes typically require 1975 introduction of server-initiated messages as described in 1976 [RFC3576bis] and [I-D.irtf-aaaarch-handoff], security issues 1977 described in [RFC3576bis] Section 6 are applicable, including 1978 authorization (Section 6.1) and replay detection (Section 6.3) 1979 problems. 1981 4.3. AAA Bypass 1983 Fast handoff techniques which enable elimination of the AAA exchange 1984 (phase 1b) differ fundamentally from typical network access scenarios 1985 (dial-up, wired LAN, etc.) which include user authentication as well 1986 as authorization for the offered service. Where the AAA exchange 1987 (phase 1b) is omitted, authorizations and keying material are not 1988 provided by the backend authentication server, and as a result they 1989 need to be supplied by other means. This section describes some of 1990 the implications. 1992 4.3.1. Key Transport 1994 Where transported keying material is not supplied by the backend 1995 authentication server, it needs to be provided by another party 1996 authorized to access that keying material. As noted in Section 1.5, 1997 only the EAP peer, authenticator and server are authorized to possess 1998 transported keying material. Since EAP peers do not trust each 1999 other, if the backend authentication server does not supply 2000 transported keying material to a new authenticator, it can only be 2001 provided by a previous authenticator. 2003 As noted in Section 1.5, the goal of the EAP conversation is to 2004 derive session keys known only to the peer and the authenticator. If 2005 keying material is replicated between a previous authenticator and a 2006 new authenticator, then the previous authenticator can possess 2007 session keys used between the peer and new authenticator. Also, the 2008 new authenticator can possess session keys used between the peer and 2009 the previous authenticator. 2011 If a one-way function is used to derive the keying material to be 2012 transported to the new authenticator, then the new authenticator 2013 cannot possess previous session keys without breaking a fundamental 2014 cryptographic assumption. 2016 4.3.2. Authorization 2018 As a part of the authentication process, the backend authentication 2019 server determines the user's authorization profile and transmits the 2020 authorizations to the authenticator along with the transported keying 2021 material. Typically, the profile is determined based on the user 2022 identity, but a certificate presented by the user can also provide 2023 authorization information. 2025 The backend authentication server is responsible for making a user 2026 authorization decision, which requires answering the following 2027 questions: 2029 (a) Is this a legitimate user of this network? 2031 (b) Is the user allowed to access this network? 2033 (c) Is the user permitted to access this network on this day and at 2034 this time? 2036 (d) Is the user within the concurrent session limit? 2038 (e) Are there any fraud, credit limit, or other concerns that could 2039 lead to access denial? 2041 (f) If access is to be granted, what are the service parameters 2042 (mandatory tunneling, bandwidth, filters, and so on) to be 2043 provisioned for the user? 2045 While the authorization decision is in principle simple, the 2046 distributed decision making process can add complexity. Where 2047 brokers or proxies are involved, all of the AAA entities in the chain 2048 from the authenticator to the home backend authentication server are 2049 involved in the decision. For example, a broker can deny access even 2050 if the home backend authentication server would allow it, or a proxy 2051 can add authorizations (e.g., bandwidth limits). 2053 Decisions can be based on static policy definitions and profiles as 2054 well as dynamic state (e.g. time of day or concurrent session 2055 limits). In addition to the Accept/Reject decisions made by AAA 2056 entities, service parameters or constraints can be communicated to 2057 the authenticator. 2059 The criteria for Accept/Reject decisions or the reasons for choosing 2060 particular authorizations are typically not communicated to the 2061 authenticator, only the final result. As a result, the authenticator 2062 has no way to know what the decision was based on. Was a set of 2063 authorization parameters sent because this service is always provided 2064 to the user, or was the decision based on the time of day and the 2065 capabilities of the authenticator? 2067 4.3.3. Correctness 2069 When the AAA exchange (phase 1b) is bypassed, several challenges 2070 arise in ensuring correct authorization: 2072 Theft of service 2073 Bypassing the AAA exchange (phase 1b) SHOULD NOT enable a user to 2074 extend their network access or gain access to services they are not 2075 entitled to. 2077 Consideration of network-wide state 2078 Handoff techniques SHOULD NOT render the backend authentication 2079 server incapable of keeping track of network-wide state. For 2080 example, a backend authentication server can need to keep track of 2081 simultaneous user sessions. 2083 Elevation of privilege 2084 Backend authentication servers often perform conditional 2085 evaluation, in which the authorizations returned in an Access- 2086 Accept message are contingent on the authenticator or on dynamic 2087 state such as the time of day. In this situation, bypassing the 2088 AAA exchange could enable unauthorized access unless the 2089 restrictions are explicitly encoded within the authorizations 2090 provided by the backend authentication server. 2092 A handoff mechanism that provides proper authorization is said to be 2093 "correct". One condition for correctness is as follows: 2095 For a handoff to be "correct" it MUST establish on the new 2096 authenticator the same authorizations as would have been created 2097 had the new authenticator completed a AAA conversation with the 2098 backend authentication server. 2100 A properly designed handoff scheme will only succeed if it is 2101 "correct" in this way. If a successful handoff would establish 2102 "incorrect" authorizations, it is preferable for it to fail. Where 2103 the supported services differ between authenticators, a handoff that 2104 bypasses the backend authentication server is likely to fail. 2105 [RFC2865] section 1.1 states: 2107 A authenticator that does not implement a given service MUST NOT 2108 implement the RADIUS attributes for that service. For example, a 2109 authenticator that is unable to offer ARAP service MUST NOT 2110 implement the RADIUS attributes for ARAP. A authenticator MUST 2111 treat a RADIUS access-accept authorizing an unavailable service as 2112 an access-reject instead. 2114 This behavior applies to attributes that are known, but not 2115 implemented. For attributes that are unknown, [RFC2865] Section 5 2116 states: 2118 A RADIUS server MAY ignore Attributes with an unknown Type. A 2119 RADIUS client MAY ignore Attributes with an unknown Type. 2121 In order to perform a correct handoff, if a new authenticator is 2122 provided with RADIUS authorizations for a known but unavailable 2123 service, then it MUST process these authorizations the same way it 2124 would handle a RADIUS Access-Accept requesting an unavailable 2125 service; this MUST cause the handoff to fail. However, if a new 2126 authenticator is provided with authorizations including unknown 2127 attributes, then these attributes MAY be ignored. The definition of 2128 a "known but unsupported service" MUST encompass requests for 2129 unavailable security services. This includes vendor-specific 2130 attributes related to security, such as those described in [RFC2548]. 2131 Although it can seem somewhat counter-intuitive, failure is indeed 2132 the "correct" result where a known but unsupported service is 2133 requested. 2135 Presumably a correctly configured backend authentication server would 2136 not request that an authenticator provide a service that it does not 2137 implement. This implies that if the new authenticator were to 2138 complete a AAA conversation, it would be likely to receive different 2139 service instructions. Failure of the handoff is the desired result 2140 since it will cause the new authenticator to go back to the backend 2141 server in order to receive the appropriate service definition. 2143 Handoff mechanisms which bypass the backend authentication server are 2144 most likely to be successful when employed in a homogeneous 2145 deployment within a single administrative domain. In a heterogeneous 2146 deployment, the backend authentication server can return different 2147 authorizations depending on the authenticator making the request, in 2148 order to make sure that the requested service is consistent with the 2149 authenticator capabilities. Where a backend authentication server 2150 would send different authorizations to the new authenticator than 2151 were sent to a previous authenticator, transferring authorizations 2152 between the previous authenticator and the new authenticator will 2153 result in incorrect authorization. 2155 Virtual LAN (VLAN) support is defined in [IEEE-802.1Q]; RADIUS 2156 support for dynamic VLANs is described in [RFC3580] and [RFC4675]. 2157 If some authenticators support dynamic VLANs while others do not, 2158 then attributes present in the Access-Request (such as the NAS-Port- 2159 Type, NAS-IP-Address, NAS-IPv6-Address and NAS-Identifier) could be 2160 examined by the backend authentication server to determine when VLAN 2161 attributes will be returned, and if so, which ones. However, if the 2162 backend authenticator is bypassed, then a handoff occurring between 2163 authenticators supporting different VLAN capabilities could result in 2164 a user obtaining access to an unauthorized VLAN (e.g. a user with 2165 access to a guest VLAN being given unrestricted access to the 2166 network). 2168 Similarly, it is preferable for a handoff between an authenticator 2169 providing confidentiality and another that does not to fail, since if 2170 the handoff were successful, the user would be moved from a secure to 2171 an insecure channel without permission from the backend 2172 authentication server. 2174 5. Security Considerations 2176 The EAP threat model is described in [RFC3748] Section 7.1. The 2177 security properties of EAP methods (known as "security claims") are 2178 described in [RFC3748] Section 7.2.1. EAP method requirements for 2179 applications such as Wireless LAN authentication are described in 2180 [RFC4017]. The RADIUS threat model is described in [RFC3579] Section 2181 4.1, and responses to these threats are described in [RFC3579] 2182 Sections 4.2 and 4.3. 2184 However, in addition to threats against EAP and AAA, there are other 2185 system level threats. In developing the threat model, it is assumed 2186 that: 2188 All traffic is visible to the attacker. 2189 The attacker can alter, forge or replay messages. 2190 The attacker can reroute messages to another principal. 2191 The attacker can be a principal or an outsider. 2192 The attacker can compromise any key that is sufficiently old. 2194 Threats arising from these assumptions include: 2196 (a) An attacker can compromise or steal an EAP peer or authenticator, 2197 in an attempt to gain access to other EAP peers or authenticators 2198 or to obtain long-term secrets. 2200 (b) An attacker can attempt a downgrade attack in order to exploit 2201 known weaknesses in an authentication method or cryptographic 2202 algorithm. 2204 (c) An attacker can try to modify or spoof packets, including Discovery 2205 or Secure Association Protocol frames, EAP or AAA packets. 2207 (d) An attacker can attempt to induce an EAP peer, authenticator or 2208 server to disclose keying material to an unauthorized party, or 2209 utilize keying material outside the context that it was intended 2210 for. 2212 (e) An attacker can alter, forge or replay packets. 2214 (f) An attacker can cause an EAP peer, authenticator or server to reuse 2215 a stale key. Use of stale keys can also occur unintentionally. 2216 For example, a poorly implemented backend authentication server can 2217 provide stale keying material to an authenticator, or a poorly 2218 implemented authenticator can reuse nonces. 2220 (g) An authenticated attacker can attempt to obtain elevated privilege 2221 in order to access information that it does not have rights to. 2223 (h) An attacker can attempt a man-in-the-middle attack in order to gain 2224 access to the network. 2226 (i) An attacker can compromise an EAP authenticator in an effort to 2227 commit fraud. For example, a compromised authenticator can provide 2228 incorrect information to the EAP peer and/or server via out-of-band 2229 mechanisms (such as via a AAA or lower layer protocol). This 2230 includes impersonating another authenticator, or providing 2231 inconsistent information to the peer and EAP server. 2233 (j) An attacker can launch a denial of service attack against the EAP 2234 peer, authenticator or backend authentication server. 2236 In order to address these threats, [RFC4962] Section 3 describes 2237 required and recommended security properties. The sections that 2238 follow analyze the compliance of EAP methods, AAA protocols and 2239 Secure Association Protocols with those guidelines. 2241 5.1. Peer and Authenticator Compromise 2243 Requirement: In the event that an authenticator is compromised or 2244 stolen, an attacker can gain access to the network through that 2245 authenticator, or can obtain the credentials needed for the 2246 authenticator/AAA client to communicate with one or more backend 2247 authentication servers. Similarly, if a peer is compromised or 2248 stolen, an attacker can obtain credentials needed to communicate with 2249 one or more authenticators. Mandatory requirement from [RFC4962] 2250 Section 3: 2252 Prevent the Domino effect 2254 Compromise of a single peer MUST NOT compromise keying material 2255 held by any other peer within the system, including session keys 2256 and long-term keys. Likewise, compromise of a single 2257 authenticator MUST NOT compromise keying material held by any 2258 other authenticator within the system. In the context of a key 2259 hierarchy, this means that the compromise of one node in the key 2260 hierarchy must not disclose the information necessary to 2261 compromise other branches in the key hierarchy. Obviously, the 2262 compromise of the root of the key hierarchy will compromise all of 2263 the keys; however, a compromise in one branch MUST NOT result in 2264 the compromise of other branches. There are many implications of 2265 this requirement; however, two implications deserve highlighting. 2266 First, the scope of the keying material must be defined and 2267 understood by all parties that communicate with a party that holds 2268 that keying material. Second, a party that holds keying material 2269 in a key hierarchy must not share that keying material with 2270 parties that are associated with other branches in the key 2271 hierarchy. 2273 Group keys are an obvious exception. Since all members of the 2274 group have a copy of the same key, compromise of any one of the 2275 group members will result in the disclosure of the group key. 2277 Some of the implications of the requirement are as follows: 2279 Key Sharing 2280 In order to be able to determine whether keying material has been 2281 shared, it is necessary for the identity of the EAP authenticator 2282 (NAS-Identifier) to be defined and understood by all parties that 2283 communicate with it. EAP lower layer specifications such as 2284 [IEEE-802.11], [IEEE-802.16e], [IEEE-802.1X], IKEv2 [RFC4306] and 2285 PPP [RFC1661] do not involve key sharing. 2287 AAA Credential Sharing 2288 AAA credentials (such as RADIUS shared secrets, IPsec pre-shared 2289 keys or certificates) MUST NOT be shared between AAA clients, since 2290 if one AAA client were compromised, this would enable an attacker 2291 to impersonate other AAA clients to the backend authentication 2292 server, or even to impersonate a backend authentication server to 2293 other AAA clients. 2295 Compromise of Long-Term Credentials 2296 An attacker obtaining keying material (such as TSKs, TEKs or the 2297 MSK) MUST NOT be able to obtain long-term user credentials such as 2298 pre-shared keys, passwords or private-keys without breaking a 2299 fundamental cryptographic assumption. The mandatory requirements 2300 of [RFC4017] Section 2.2 include generation of EAP keying material, 2301 capability to generate EAP keying material with 128-bits of 2302 effective strength, resistance to dictionary attacks, shared state 2303 equivalence and protection against man-in-the-middle attacks. 2305 5.2. Cryptographic Negotiation 2307 Mandatory requirements from [RFC4962] Section 3: 2309 Cryptographic algorithm independent 2311 The AAA key management protocol MUST be cryptographic algorithm 2312 independent. However, an EAP method MAY depend on a specific 2313 cryptographic algorithm. The ability to negotiate the use of a 2314 particular cryptographic algorithm provides resilience against 2315 compromise of a particular cryptographic algorithm. Algorithm 2316 independence is also REQUIRED with a Secure Association Protocol 2317 if one is defined. This is usually accomplished by including an 2318 algorithm identifier and parameters in the protocol, and by 2319 specifying the algorithm requirements in the protocol 2320 specification. While highly desirable, the ability to negotiate 2321 key derivation functions (KDFs) is not required. For 2322 interoperability, at least one suite of mandatory-to-implement 2323 algorithms MUST be selected. Note that without protection by 2324 IPsec as described in [RFC3579] Section 4.2, RADIUS [RFC2865] does 2325 not meet this requirement, since the integrity protection 2326 algorithm cannot be negotiated. 2328 This requirement does not mean that a protocol must support both 2329 public-key and symmetric-key cryptographic algorithms. It means 2330 that the protocol needs to be structured in such a way that 2331 multiple public-key algorithms can be used whenever a public-key 2332 algorithm is employed. Likewise, it means that the protocol needs 2333 to be structured in such a way that multiple symmetric-key 2334 algorithms can be used whenever a symmetric-key algorithm is 2335 employed. 2337 Confirm ciphersuite selection 2339 The selection of the "best" ciphersuite SHOULD be securely 2340 confirmed. The mechanism SHOULD detect attempted roll-back 2341 attacks. 2343 EAP methods satisfying [RFC4017] Section 2.2 mandatory requirements 2344 and AAA protocols utilizing transmission layer security are capable 2345 of addressing downgrade attacks. [RFC3748] Section 7.2.1 describes 2346 the "protected ciphersuite negotiation" security claim that refers to 2347 the ability of an EAP method to negotiate the ciphersuite used to 2348 protect the EAP method conversation, as well as to integrity protect 2349 the ciphersuite negotiation. [RFC4017] Section 2.2 requires EAP 2350 methods satisfying this security claim. Since TLS v1.2 2352 [I-D.ietf-tls-rfc4346-bis] supports negotiation of Key Distribution 2353 Functions (KDFs), EAP methods based on TLS will, if properly 2354 designed, inherit this capability. However, negotiation of KDFs is 2355 not required by RFC 4962 [RFC4962], and EAP methods not based on TLS 2356 typically do not support KDF negotiation. 2358 Diameter [RFC3588] provides support for cryptographic algorithm 2359 negotiation via use of IPsec [RFC4301] or TLS [RFC4346]. Since IKEv2 2360 [RFC4306] does not support KDF negotiation, support for KDF 2361 negotiation is only available when Diameter runs over TLS v1.2. 2362 RADIUS [RFC3579] does not support cryptographic algorithm negotiation 2363 and relies on MD5 for integrity protection, authentication and 2364 confidentiality. Given the known weaknesses in MD5 [MD5Collision] 2365 this is undesirable, and can be addressed via use of RADIUS over 2366 IPsec, as described in [RFC3579] Section 4.2. 2368 To ensure against downgrade attacks within lower layer protocols, 2369 algorithm independence is REQUIRED with lower layers using EAP for 2370 key derivation. For interoperability, at least one suite of 2371 mandatory-to-implement algorithm MUST be selected. Lower layer 2372 protocols supporting EAP for key derivation SHOULD also support 2373 secure ciphersuite negotiation as well as KDF negotiation. 2375 As described in [RFC1968], PPP ECP does not support secure 2376 ciphersuite negotiation. While [IEEE 802.16e] and [IEEE-802.11] 2377 support ciphersuite negotiation for protection of data, they do not 2378 support negotiation of the cryptographic primitives used within the 2379 Secure Association Protocol, such as message integrity checks (MICs) 2380 and KDFs. 2382 5.3. Confidentiality and Authentication 2384 Mandatory requirements from [RFC4962] Section 3: 2386 Authenticate all parties 2388 Each party in the AAA key management protocol MUST be 2389 authenticated to the other parties with whom they communicate. 2390 Authentication mechanisms MUST maintain the confidentiality of any 2391 secret values used in the authentication process. When a secure 2392 association protocol is used to establish session keys, the 2393 parties involved in the secure association protocol MUST identify 2394 themselves using identities that are meaningful in the lower-layer 2395 protocol environment that will employ the session keys. In this 2396 situation, the authenticator and peer may be known by different 2397 identifiers in the AAA protocol environment and the lower-layer 2398 protocol environment, making authorization decisions difficult 2399 without a clear key scope. If the lower-layer identifier of the 2400 peer will be used to make authorization decisions, then the pair 2401 of identifiers associated with the peer MUST be authorized by the 2402 authenticator and/or the AAA server. 2404 AAA protocols, such as RADIUS [RFC2865] and Diameter [RFC3588], 2405 provide a mechanism for the identification of AAA clients; since 2406 the EAP authenticator and AAA client are always co- resident, this 2407 mechanism is applicable to the identification of EAP 2408 authenticators. 2410 When multiple base stations and a "controller" (such as a WLAN 2411 switch) comprise a single EAP authenticator, the "base station 2412 identity" is not relevant; the EAP method conversation takes place 2413 between the EAP peer and the EAP server. Also, many base stations 2414 can share the same authenticator identity. The authenticator 2415 identity is important in the AAA protocol exchange and the secure 2416 association protocol conversation. 2418 Authentication mechanisms MUST NOT employ plaintext passwords. 2419 Passwords may be used provided that they are not sent to another 2420 party without confidentiality protection. 2422 Keying material confidentiality and integrity 2424 While preserving algorithm independence, confidentiality and 2425 integrity of all keying material MUST be maintained. 2427 Conformance to these requirements are analyzed in the sections that 2428 follow. 2430 5.3.1. Spoofing 2432 Per-packet authentication and integrity protection provides 2433 protection against spoofing attacks. 2435 Diameter [RFC3588] provides support for per-packet authentication and 2436 integrity protection via use of IPsec or TLS. RADIUS/EAP [RFC3579] 2437 provides for per-packet authentication and integrity protection via 2438 use of the Message-Authenticator attribute. 2440 [RFC3748] Section 7.2.1 describes the "integrity protection" security 2441 claim and [RFC4017] Section 2.2 requires EAP methods supporting this 2442 claim. 2444 In order to prevent forgery of Secure Association Protocol frames, 2445 per-frame authentication and integrity protection is RECOMMENDED on 2446 all messages. IKEv2 [RFC4306] supports per-frame integrity 2447 protection and authentication, as does the Secure Association 2448 Protocol defined in [IEEE-802.16e]. [IEEE-802.11] supports per-frame 2449 integrity protection and authentication on all messages within the 2450 4-way handshake except the first message. An attack leveraging this 2451 omission is described in [Analysis]. 2453 5.3.2. Impersonation 2455 Both RADIUS [RFC2865] and Diameter [RFC3588] implementations are 2456 potentially vulnerable to a rogue authenticator impersonating another 2457 authenticator. While both protocols support mutual authentication 2458 between the AAA client/authenticator and the backend authentication 2459 server, the security mechanisms vary. 2461 In RADIUS, the shared secret used for authentication is determined by 2462 the source address of the RADIUS packet. However, when RADIUS 2463 Access-Requests are forwarded by a proxy, the NAS-IP-Address, NAS- 2464 Identifier or NAS-IPv6-Address attributes received by the RADIUS 2465 server will not correspond to the source address. As noted in 2466 [RFC3579] Section 4.3.7, if the first-hop proxy does not check the 2467 NAS identification attributes against the source address in the 2468 Access-Request packet, it is possible for a rogue authenticator to 2469 forge NAS-IP-Address [RFC2865], NAS-IPv6-Address [RFC3162] or NAS- 2470 Identifier [RFC2865] attributes in order to impersonate another 2471 authenticator; attributes such as the Called-Station-Id [RFC2865] and 2472 Calling-Station-Id [RFC2865] can be forged as well. Among other 2473 things, this can result in messages (and transported keying material) 2474 being sent to the wrong authenticator. 2476 While [RFC3588] requires use of the Route-Record AVP, this utilizes 2477 Fully Qualified Domain Names (FQDNs), so that impersonation detection 2478 requires DNS A, AAAA and PTR Resource Records (RRs) to be properly 2479 configured. As a result, Diameter is as vulnerable to this attack as 2480 RADIUS, if not more so. [RFC3579] Section 4.3.7 recommends 2481 mechanisms for impersonation detection; to prevent access to keying 2482 material by proxies without a "need to know", it is necessary to 2483 allow the backend authentication server to communicate with the 2484 authenticator directly, such as via the redirect functionality 2485 supported in [RFC3588]. 2487 5.3.3. Channel Binding 2489 It is possible for a compromised or poorly implemented EAP 2490 authenticator to communicate incorrect information to the EAP peer 2491 and/or server. This can enable an authenticator to impersonate 2492 another authenticator or communicate incorrect information via out- 2493 of-band mechanisms (such as via AAA or the lower layer). 2495 Where EAP is used in pass-through mode, the EAP peer does not verify 2496 the identity of the pass-through authenticator within the EAP 2497 conversation. Within the Secure Association Protocol, the EAP peer 2498 and authenticator only demonstrate mutual possession of the 2499 transported keying material; they do not mutually authenticate. This 2500 creates a potential security vulnerability, described in [RFC3748] 2501 Section 7.15. 2503 As described in [RFC3579] Section 4.3.7, it is possible for a first- 2504 hop AAA proxy to detect a AAA client attempting to impersonate 2505 another authenticator. However, it is possible for a pass-through 2506 authenticator acting as a AAA client to provide correct information 2507 to the backend authentication server while communicating misleading 2508 information to the EAP peer via the lower layer. 2510 For example, a compromised authenticator can utilize another 2511 authenticator's Called-Station-Id or NAS-Identifier in communicating 2512 with the EAP peer via the lower layer. Also, a pass-through 2513 authenticator acting as a AAA client can provide an incorrect peer 2514 Calling-Station-Id [RFC2865][RFC3580] to the backend authentication 2515 server via the AAA protocol. 2517 As noted in [RFC3748] Section 7.15, this vulnerability can be 2518 addressed by EAP methods that support a protected exchange of channel 2519 properties such as endpoint identifiers, including (but not limited 2520 to): Called-Station-Id [RFC2865][RFC3580], Calling-Station-Id 2521 [RFC2865][RFC3580], NAS-Identifier [RFC2865], NAS-IP-Address 2522 [RFC2865], and NAS-IPv6-Address [RFC3162]. 2524 Using such a protected exchange, it is possible to match the channel 2525 properties provided by the authenticator via out-of-band mechanisms 2526 against those exchanged within the EAP method. Typically the EAP 2527 method imports channel binding parameters from the lower layer on the 2528 peer, and transmits them securely to the EAP server, which exports 2529 them to the lower layer or AAA layer. However, transport can occur 2530 from EAP server to peer, or can be bi-directional. On the side of 2531 the exchange (peer or server) where Channel Binding is verified, the 2532 lower layer or AAA layer passes the result of the verification (TRUE 2533 or FALSE) up to the EAP method. While the verification can be done 2534 either by the peer or the server, typically only the server has the 2535 knowledge to determine the correctness of the values, as opposed to 2536 merely verifying their equality. For further discussion, see 2537 [I-D.arkko-eap-service-identity-auth]. 2539 It is also possible to perform Channel Binding without transporting 2540 data over EAP, as described in [I-D.ohba-eap-channel-binding]. In 2541 this approach the EAP method includes channel binding parameters in 2542 the calculation of exported EAP keying material, making it impossible 2543 for the peer and authenticator to complete the Secure Association 2544 Protocol if there is a mismatch in the channel binding parameters. 2545 However, this approach can only be applied where methods generating 2546 EAP keying material are used along with lower layers that utilize EAP 2547 keying material. For example, this mechanism would not enable 2548 verification of Channel Binding on wired IEEE 802 networks using 2549 [IEEE-802.1X]. 2551 5.3.4. Mutual Authentication 2553 [RFC3748] Section 7.2.1 describes the "mutual authentication" and 2554 "dictionary attack resistance" claims, and [RFC4017] requires EAP 2555 methods satisfying these claims. EAP methods complying with 2556 [RFC4017] therefore provide for mutual authentication between the EAP 2557 peer and server. 2559 [RFC3748] Section 7.2.1 also describes the "Cryptographic binding" 2560 security claim, and [RFC4017] Section 2.2 requires support for this 2561 claim. As described in [I-D.puthenkulam-eap-binding], EAP method 2562 sequences and compound authentication mechanisms can be subject to 2563 man-in-the-middle attacks. When such attacks are successfully 2564 carried out, the attacker acts as an intermediary between a victim 2565 and a legitimate authenticator. This allows the attacker to 2566 authenticate successfully to the authenticator, as well as to obtain 2567 access to the network. 2569 In order to prevent these attacks, [I-D.puthenkulam-eap-binding] 2570 recommends derivation of a compound key by which the EAP peer and 2571 server can prove that they have participated in the entire EAP 2572 exchange. Since the compound key MUST NOT be known to an attacker 2573 posing as an authenticator, and yet must be derived from EAP keying 2574 material, it MAY be desirable to derive the compound key from a 2575 portion of the EMSK. Where this is done, in order to provide proper 2576 key hygiene, it is RECOMMENDED that the compound key used for man-in- 2577 the-middle protection be cryptographically separate from other keys 2578 derived from the EMSK. 2580 Diameter [RFC3588] provides for per-packet authentication and 2581 integrity protection via IPsec or TLS, and RADIUS/EAP [RFC3579] also 2582 provides for per-packet authentication and integrity protection. 2583 Where the authenticator/AAA client and backend authentication server 2584 communicate directly and credible key wrap is used (see Section 3.8), 2585 this ensures that the AAA Key Transport (phase 1b) achieves its 2586 security objectives: mutually authenticating the AAA 2587 client/authenticator and backend authentication server and providing 2588 transported keying material to the EAP authenticator and to no other 2589 party. 2591 [RFC2607] Section 7 describes the security issues occurring when the 2592 authenticator/AAA client and backend authentication server do not 2593 communicate directly. Where a AAA intermediary is present (such as a 2594 RADIUS proxy or a Diameter agent), and data object security is not 2595 used, transported keying material can be recovered by an attacker in 2596 control of the intermediary. As discussed in Section 2.1, unless the 2597 TSKs are derived independently from EAP keying material (as in 2598 IKEv2), possession of transported keying material enables decryption 2599 of data traffic sent between the peer and the authenticator to whom 2600 the keying material was transported. It also allows the AAA 2601 intermediary to impersonate the authenticator or the peer. Since the 2602 peer does not authenticate to a AAA intermediary it has no ability to 2603 determine whether it is authentic or authorized to obtain keying 2604 material. 2606 However, as long as transported keying material or keys derived from 2607 it are only utilized by a single authenticator, compromise of the 2608 transported keying material does not enable an attacker to 2609 impersonate the peer to another authenticator. Vulnerability to 2610 compromise of a AAA intermediary can be mitigated by implementation 2611 of redirect functionality, as described in [RFC3588] and [RFC4072]. 2613 The Secure Association Protocol does not provide for mutual 2614 authentication between the EAP peer and authenticator, only mutual 2615 proof of possession of transported keying material. In order for the 2616 peer to verify the identity of the authenticator, mutual proof of 2617 possession needs to be combined with impersonation prevention and 2618 Channel Binding. Impersonation prevention (described in Section 2619 5.3.2) enables the backend authentication server to determine that 2620 the transported keying material has been provided to the correct 2621 authenticator. When utilized along with impersonation prevention, 2622 Channel Binding (described in Section 5.3.3) enables the EAP peer to 2623 verify that the EAP server has authorized the authenticator to 2624 possess the transported keying material. Completion of the Secure 2625 Association Protocol exchange demonstrates that the EAP peer and the 2626 authenticator possess the transported keying material. 2628 5.4. Key Binding 2630 Mandatory requirement from [RFC4962] Section 3: 2632 Bind key to its context 2634 Keying material MUST be bound to the appropriate context. The 2635 context includes the following: 2637 o The manner in which the keying material is expected to 2638 be used. 2640 o The other parties that are expected to have access to 2641 the keying material. 2643 o The expected lifetime of the keying material. Lifetime 2644 of a child key SHOULD NOT be greater than the lifetime of 2645 its parent in the key hierarchy. 2647 Any party with legitimate access to keying material can determine 2648 its context. In addition, the protocol MUST ensure that all 2649 parties with legitimate access to keying material have the same 2650 context for the keying material. This requires that the parties 2651 are properly identified and authenticated, so that all of the 2652 parties that have access to the keying material can be determined. 2654 The context will include the peer and NAS identities in more than 2655 one form. One (or more) name form is needed to identify these 2656 parties in the authentication exchange and the AAA protocol. 2657 Another name form may be needed to identify these parties within 2658 the lower layer that will employ the session key. 2660 Within EAP, exported keying material (MSK, EMSK,IV) is bound to the 2661 Peer-Id(s) and Server-Id(s) which are exported along with the keying 2662 material. However, not all EAP methods support authenticated server 2663 identities (see Appendix A). 2665 Within the AAA protocol, transported keying material is destined for 2666 the EAP authenticator identified by the NAS-Identifier Attribute 2667 within the request, and is for use by the EAP peer identified by the 2668 Peer-Id(s), User-Name [RFC2865] or Chargeable User Identity (CUI) 2669 [RFC4372] attributes. The maximum lifetime of the transported keying 2670 material can be provided, as discussed in Section 3.5.1. Key usage 2671 restrictions can also be included as described in Section 3.2. Key 2672 lifetime issues are discussed in Sections 3.3, 3.4 and 3.5. 2674 5.5. Authorization 2676 Requirement: The Secure Association Protocol (phase 2) conversation 2677 may utilize different identifiers from the EAP conversation (phase 2678 1a), so that binding between the EAP and Secure Association Protocol 2679 identities is REQUIRED. 2681 Mandatory requirement from [RFC4962] Section 3: 2683 Peer and authenticator authorization 2685 Peer and authenticator authorization MUST be performed. These 2686 entities MUST demonstrate possession of the appropriate keying 2687 material, without disclosing it. Authorization is REQUIRED 2688 whenever a peer associates with a new authenticator. The 2689 authorization checking prevents an elevation of privilege attack, 2690 and it ensures that an unauthorized authenticator is detected. 2692 Authorizations SHOULD be synchronized between the peer, NAS, and 2693 backend authentication server. Once the AAA key management 2694 protocol exchanges are complete, all of these parties should hold 2695 a common view of the authorizations associated with the other 2696 parties. 2698 In addition to authenticating all parties, key management 2699 protocols need to demonstrate that the parties are authorized to 2700 possess keying material. Note that proof of possession of keying 2701 material does not necessarily prove authorization to hold that 2702 keying material. For example, within an IEEE 802.11, the 4-way 2703 handshake demonstrates that both the peer and authenticator 2704 possess the same EAP keying material. However, by itself, this 2705 possession proof does not demonstrate that the authenticator was 2706 authorized by the backend authentication server to possess that 2707 keying material. As noted in [RFC3579] in Section 4.3.7, where 2708 AAA proxies are present, it is possible for one authenticator to 2709 impersonate another, unless each link in the AAA chain implements 2710 checks against impersonation. Even with these checks in place, an 2711 authenticator may still claim different identities to the peer and 2712 the backend authentication server. As described in [RFC3748] 2713 Section 7.15, channel binding is required to enable the peer to 2714 verify that the authenticator claim of identity is both consistent 2715 and correct. 2717 Recommendation from [RFC4962] Section 3: 2719 Authorization restriction 2721 If peer authorization is restricted, then the peer SHOULD be made 2722 aware of the restriction. Otherwise, the peer may inadvertently 2723 attempt to circumvent the restriction. For example, authorization 2724 restrictions in an IEEE 802.11 environment include: 2726 o Key lifetimes, where the keying material can only be used 2727 for a certain period of time; 2729 o SSID restrictions, where the keying material can only be 2730 used with a specific IEEE 802.11 SSID; 2732 o Called-Station-ID restrictions, where the keying material 2733 can only be used with a single IEEE 802.11 BSSID; and 2735 o Calling-Station-ID restrictions, where the keying 2736 material can only be used with a single peer IEEE 802 MAC 2737 address. 2739 As described in Section 2.3, consistent identification of the EAP 2740 authenticator enables the EAP peer to determine the scope of keying 2741 material provided to an authenticator, as well as to confirm with the 2742 backend authentication server that an EAP authenticator proving 2743 possession of EAP keying material during the Secure Association 2744 Protocol was authorized to obtain it. 2746 Within the AAA protocol, the authorization attributes are bound to 2747 the transported keying material. While the AAA exchange provides the 2748 AAA client/authenticator with authorizations relating to the EAP 2749 peer, neither the EAP nor AAA exchanges provide authorizations to the 2750 EAP peer. In order to ensure that all parties hold the same view of 2751 the authorizations it is RECOMMENDED that the Secure Association 2752 Protocol enable communication of authorizations between the EAP 2753 authenticator and peer. 2755 In lower layers where the authenticator consistently identifies 2756 itself to the peer and backend authentication server and the EAP peer 2757 completes the Secure Association Protocol exchange with the same 2758 authenticator through which it completed the EAP conversation, 2759 authorization of the authenticator is demonstrated to the peer by 2760 mutual authentication between the peer and authenticator as discussed 2761 in the previous section. Identification issues are discussed in 2762 Sections 2.3, 2.4 and 2.5 and key scope issues are discussed in 2763 Section 3.2. 2765 Where the EAP peer utilizes different identifiers within the EAP 2766 method and Secure Association Protocol conversations, peer 2767 authorization can be difficult to demonstrate to the authenticator 2768 without additional restrictions. This problem does not exist in 2769 IKEv2 where the Identity Payload is used for peer identification both 2770 within IKEv2 and EAP, and where the EAP conversation is 2771 cryptographically protected within IKEv2 binding the EAP and IKEv2 2772 exchanges. However within [IEEE-802.11] the EAP peer identity is not 2773 used within the 4-way handshake, so that it is necessary for the 2774 authenticator to require that the EAP peer utilize the same MAC 2775 address for EAP authentication as for the 4-way handshake. 2777 5.6. Replay Protection 2779 Mandatory requirement from [RFC4962] Section 3: 2781 Replay detection mechanism 2783 The AAA key management protocol exchanges MUST be replay 2784 protected, including AAA, EAP and Secure Association Protocol 2785 exchanges. Replay protection allows a protocol message recipient 2786 to discard any message that was recorded during a previous 2787 legitimate dialogue and presented as though it belonged to the 2788 current dialogue. 2790 [RFC3748] Section 7.2.1 describes the "replay protection" security 2791 claim and [RFC4017] Section 2.2 requires use of EAP methods 2792 supporting this claim. 2794 Diameter [RFC3588] provides support for replay protection via use of 2795 IPsec or TLS. RADIUS/EAP [RFC3579] protects against replay of keying 2796 material via the Request Authenticator. However, some RADIUS packets 2797 are not replay protected. In Accounting, Disconnect and CoA-Request 2798 packets the Request Authenticator contains a keyed MAC rather than a 2799 Nonce. The Response Authenticator in Accounting, Disconnect and CoA 2800 Response packets also contains a keyed MAC whose calculation does not 2801 depend on a Nonce in either the Request or Response packets. 2802 Therefore unless an Event-Timestamp attribute is included or IPsec is 2803 used, it is possible that the recipient will not be able to determine 2804 whether these packets have been replayed. 2806 In order to prevent replay of Secure Association Protocol frames, 2807 replay protection is REQUIRED on all messages. [IEEE-802.11] 2808 supports replay protection on all messages within the 4-way 2809 handshake; IKEv2 [RFC4306] also supports this. 2811 5.7. Key Freshness 2813 Requirement: A session key SHOULD be considered compromised if it 2814 remains in use beyond its authorized lifetime. Mandatory requirement 2815 from [RFC4962] Section 3: 2817 Strong, fresh session keys 2819 While preserving algorithm independence, session keys MUST be 2820 strong and fresh. Each session deserves an independent session 2821 key. Fresh keys are required even when a long replay counter 2822 (that is, one that "will never wrap") is used to ensure that loss 2823 of state does not cause the same counter value to be used more 2824 than once with the same session key. 2826 Some EAP methods are capable of deriving keys of varying strength, 2827 and these EAP methods MUST permit the generation of keys meeting a 2828 minimum equivalent key strength. BCP 86 [RFC3766] offers advice 2829 on appropriate key sizes. The National Institute for Standards 2830 and Technology (NIST) also offers advice on appropriate key sizes 2831 in [SP800-57]. 2833 A fresh cryptographic key is one that is generated specifically 2834 for the intended use. In this situation, a secure association 2835 protocol is used to establish session keys. The AAA protocol and 2836 EAP method MUST ensure that the keying material supplied as an 2837 input to session key derivation is fresh, and the secure 2838 association protocol MUST generate a separate session key for each 2839 session, even if the keying material provided by EAP is cached. A 2840 cached key persists after the authentication exchange has 2841 completed. For the AAA/EAP server, key caching can happen when 2842 state is kept on the server. For the NAS or client, key caching 2843 can happen when the NAS or client does not destroy keying material 2844 immediately following the derivation of session keys. 2846 Session keys MUST NOT be dependent on one another. Multiple 2847 session keys may be derived from a higher-level shared secret as 2848 long as a one-time value, usually called a nonce, is used to 2849 ensure that each session key is fresh. The mechanism used to 2850 generate session keys MUST ensure that the disclosure of one 2851 session key does not aid the attacker in discovering any other 2852 session keys. 2854 EAP, AAA and the lower layer each bear responsibility for ensuring 2855 the use of fresh, strong session keys. EAP methods need to ensure 2856 the freshness and strength of EAP keying material provided as an 2857 input to session key derivation. [RFC3748] Section 7.10 states: 2859 EAP methods SHOULD ensure the freshness of the MSK and EMSK, even 2860 in cases where one party may not have a high quality random number 2861 generator. A RECOMMENDED method is for each party to provide a 2862 nonce of at least 128 bits, used in the derivation of the MSK and 2863 EMSK. 2865 The contribution of nonces enables the EAP peer and server to ensure 2866 that exported EAP keying material is fresh. 2868 [RFC3748] Section 7.2.1 describes the "key strength" and "session 2869 independence" security claims, and [RFC4017] requires EAP methods 2870 supporting these claims as well as methods capable of providing 2871 equivalent key strength of 128 bits or greater. See Section 3.7 for 2872 more information on key strength. 2874 The AAA protocol needs to ensure that transported keying material is 2875 fresh and is not utilized outside its recommended lifetime. Replay 2876 protection is necessary for key freshness, but an attacker can 2877 deliver a stale (and therefore potentially compromised) key in a 2878 replay-protected message, so replay protection is not sufficient. As 2879 discussed in Section 3.5, the Session-Timeout attribute enables the 2880 backend authentication server to limit the exposure of transported 2881 keying material. 2883 The EAP Session-Id, described in Section 1.4, enables the EAP peer, 2884 authenticator and server to distinguish EAP conversations. However, 2885 unless the authenticator keeps track of EAP Session-Ids, the 2886 authenticator cannot use the Session-Id to guarantee the freshness of 2887 keying material. 2889 The Secure Association Protocol, described in Section 3.1, MUST 2890 generate a fresh session key for each session, even if the EAP keying 2891 material and parameters provided by methods are cached, or either the 2892 peer or authenticator lack a high entropy random number generator. A 2893 RECOMMENDED method is for the peer and authenticator to each provide 2894 a nonce or counter used in session key derivation. If a nonce is 2895 used, it is RECOMMENDED that it be at least 128 bits. While 2896 [IEEE-802.11] and IKEv2 [RFC4306] satisfy this requirement, 2897 [IEEE-802.16e] does not, since randomness is only contributed from 2898 the Base Station. 2900 5.8. Key Scope Limitation 2902 Mandatory requirement from [RFC4962] Section 3: 2904 Limit key scope 2906 Following the principle of least privilege, parties MUST NOT have 2907 access to keying material that is not needed to perform their 2908 role. A party has access to a particular key if it has access to 2909 all of the secret information needed to derive it. 2911 Any protocol that is used to establish session keys MUST specify 2912 the scope for session keys, clearly identifying the parties to 2913 whom the session key is available. 2915 Transported keying material is permitted to be accessed by the EAP 2916 peer, authenticator and server. The EAP peer and server derive EAP 2917 keying material during the process of mutually authenticating each 2918 other using the selected EAP method. During the Secure Association 2919 Protocol exchange, the EAP peer utilizes keying material to 2920 demonstrate to the authenticator that it is the same party that 2921 authenticated to the EAP server and was authorized by it. The EAP 2922 authenticator utilizes the transported keying material to prove to 2923 the peer not only that the EAP conversation was transported through 2924 it (this could be demonstrated by a man-in-the-middle), but that it 2925 was uniquely authorized by the EAP server to provide the peer with 2926 access to the network. Unique authorization can only be demonstrated 2927 if the EAP authenticator does not share the transported keying 2928 material with a party other than the EAP peer and server. 2930 TSKs are permitted to be accessed only by the EAP peer and 2931 authenticator (see Section 1.5); TSK derivation is discussed in 2932 Section 2.1. Since demonstration of authorization within the Secure 2933 Association Protocol exchange depends on possession of transported 2934 keying material, the backend authentication server can obtain TSKs 2935 unless it deletes the transported keying material after sending it. 2937 5.9. Key Naming 2939 Mandatory requirement from [RFC4962] Section 3: 2941 Uniquely named keys 2943 AAA key management proposals require a robust key naming scheme, 2944 particularly where key caching is supported. The key name 2945 provides a way to refer to a key in a protocol so that it is clear 2946 to all parties which key is being referenced. Objects that cannot 2947 be named cannot be managed. All keys MUST be uniquely named, and 2948 the key name MUST NOT directly or indirectly disclose the keying 2949 material. If the key name is not based on the keying material, 2950 then one can be sure that it cannot be used to assist in a search 2951 for the key value. 2953 EAP key names (defined in Section 1.4.1), along with the Peer-Id(s) 2954 and Server-Id(s), uniquely identify EAP keying material, and do not 2955 directly or indirectly expose EAP keying material. 2957 Existing AAA server implementations do not distribute key names along 2958 with the transported keying material, although Diameter EAP 2959 [RFC4072], provides the EAP-Key-Name AVP for this purpose. Since the 2960 EAP-Key-Name AVP is defined within the RADIUS attribute space, it can 2961 be used either with RADIUS or Diameter. 2963 Since the authenticator is not provided with the name of the 2964 transported keying material by existing backend authentication server 2965 implementations, existing Secure Association Protocols do not utilize 2966 EAP key names. For example, [IEEE-802.11] supports PMK caching; to 2967 enable the peer and authenticator to determine the cached PMK to 2968 utilize within the 4-way handshake the PMK needs to be named. For 2969 this purpose [IEEE-802.11] utilizes a PMK naming scheme which is 2970 based on the key. Since IKEv2 [RFC4306] does not cache transported 2971 keying material, it does not need to refer to transported keying 2972 material. 2974 5.10. Denial of Service Attacks 2976 Key caching can result in vulnerability to denial of service attacks. 2977 For example, EAP methods that create persistent state can be 2978 vulnerable to denial of service attacks on the EAP server by a rogue 2979 EAP peer. 2981 To address this vulnerability, EAP methods creating persistent state 2982 can limit the persistent state created by an EAP peer. For example, 2983 for each peer an EAP server can choose to limit persistent state to a 2984 few EAP conversations, distinguished by the EAP Session-Id. This 2985 prevents a rogue peer from denying access to other peers. 2987 Similarly, to conserve resources an authenticator can choose to limit 2988 the persistent state corresponding to each peer. This can be 2989 accomplished by limiting each peer to persistent state corresponding 2990 to a few EAP conversations, distinguished by the EAP Session-Id. 2992 Whether creation of new TSKs implies deletion of previously derived 2993 TSKs depends on the EAP lower layer. Where there is no implied 2994 deletion, the authenticator can choose to limit the number of TSKs 2995 and associated state that can be stored for each peer. 2997 6. IANA Considerations 2999 This specification does not request the creation of any new parameter 3000 registries, nor does it require any other IANA assignments. 3002 7. References 3004 7.1. Normative References 3006 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3007 Requirement Levels", BCP 14, RFC 2119, March 1997. 3009 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 3010 Levkowetz, "Extensible Authentication Protocol (EAP)", 3011 RFC 3748, June 2004. 3013 [RFC4962] Housley, R. and B. Aboba, "Guidance for AAA Key 3014 Management", RFC 4962, July 2007. 3016 7.2. Informative References 3018 [8021XPreAuth] Pack, S. and Y. Choi, "Pre-Authenticated Fast Handoff in 3019 a Public Wireless LAN Based on IEEE 802.1x Model", 3020 Proceedings of the IFIP TC6/WG6.8 Working Conference on 3021 Personal Wireless Communications, p.175-182, October 3022 23-25, 2002. 3024 [Analysis] He, C. and J. Mitchell, "Analysis of the 802.11i 4-Way 3025 Handshake", Proceedings of the 2004 ACM Workshop on 3026 Wireless Security, pp. 43-50, ISBN: 1-58113-925-X. 3028 [Bargh] Bargh, M., Hulsebosch, R., Eertink, E., Prasad, A., Wang, 3029 H. and P. Schoo, "Fast Authentication Methods for 3030 Handovers between IEEE 802.11 Wireless LANs", Proceedings 3031 of the 2nd ACM international workshop on Wireless mobile 3032 applications and services on WLAN hotspots, October, 3033 2004. 3035 [GKDP] Dondeti, L., Xiang, J. and S. Rowles, "GKDP: Group Key 3036 Distribution Protocol", Internet draft (work in 3037 progress), draft-ietf-msec-gkdp-01, March 2006. 3039 [He] He, C., Sundararajan, M., Datta, A. Derek, A. and J. C. 3040 Mitchell, "A Modular Correctness Proof of TLS and IEEE 3041 802.11i", ACM Conference on Computer and Communications 3042 Security (CCS '05), November, 2005. 3044 [IEEE-802.11] Institute of Electrical and Electronics Engineers, 3045 "Information technology - Telecommunications and 3046 information exchange between systems - Local and 3047 metropolitan area networks - Specific Requirements Part 3048 11: Wireless LAN Medium Access Control (MAC) and 3049 Physical Layer (PHY) Specifications", IEEE IEEE Standard 3050 802.11-2007, 2007. 3052 [IEEE-802.1X] Institute of Electrical and Electronics Engineers, "Local 3053 and Metropolitan Area Networks: Port-Based Network Access 3054 Control", IEEE Standard 802.1X-2004, December 2004. 3056 [IEEE-802.1Q] IEEE Standards for Local and Metropolitan Area Networks: 3057 Draft Standard for Virtual Bridged Local Area Networks, 3058 P802.1Q-2003, January 2003. 3060 [IEEE-802.11i] Institute of Electrical and Electronics Engineers, 3061 "Supplement to Standard for Telecommunications and 3062 Information Exchange Between Systems - LAN/MAN Specific 3063 Requirements - Part 11: Wireless LAN Medium Access 3064 Control (MAC) and Physical Layer (PHY) Specifications: 3065 Specification for Enhanced Security", IEEE 802.11i/D1, 3066 2001. 3068 [IEEE-802.11F] Institute of Electrical and Electronics Engineers, 3069 "Recommended Practice for Multi-Vendor Access Point 3070 Interoperability via an Inter-Access Point Protocol 3071 Across Distribution Systems Supporting IEEE 802.11 3072 Operation", IEEE 802.11F, July 2003 (now deprecated). 3074 [IEEE-802.16e] Institute of Electrical and Electronics Engineers, "IEEE 3075 Standard for Local and Metropolitan Area Networks: Part 3076 16: Air Interface for Fixed and Mobile Broadband Wireless 3077 Access Systems: Amendment for Physical and Medium Access 3078 Control Layers for Combined Fixed and Mobile Operations 3079 in Licensed Bands" IEEE 802.16e, August 2005. 3081 [IEEE-03-084] Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, 3082 "Proactive Key Distribution to support fast and secure 3083 roaming", IEEE 802.11 Working Group, IEEE-03-084r1-I, 3084 http://www.ieee802.org/11/Documents/DocumentHolder/ 3085 3-084.zip, January 2003. 3087 [I-D.arkko-eap-service-identity-auth] 3088 Arkko, J. and P. Eronen, "Authenticated Service 3089 Information for the Extensible Authentication Protocol 3090 (EAP)", draft-arkko-eap-service-identity-auth-04.txt 3091 Internet draft (work in progress), October 2005. 3093 [I-D.friedman-ike-short-term-certs] 3094 Friedman, A., Sheffer, Y. and A. Shaqed, "Short-Term 3095 Certificates", draft-friedman-ike-short-term-certs-02, 3096 Internet draft (work in progress), June 2007. 3098 [I-D.irtf-aaaarch-handoff] 3099 Arbaugh, W. and B. Aboba, "Handoff Extension to RADIUS", 3100 draft-irtf-aaaarch-handoff-04.txt, Internet Draft (work 3101 in progress), October 2003. 3103 [I-D.ohba-eap-channel-binding] 3104 Ohba, Y., Parthasrathy, M. and M. Yanagiya, "Channel 3105 Binding Mechanism Based on Parameter Binding in Key 3106 Derivation", draft-ohba-eap-channel-binding-02.txt, 3107 Internet draft (work in progress), December 2006. 3109 [I-D.puthenkulam-eap-binding] 3110 Puthenkulam, J., Lortz, V., Palekar, A. and D. Simon, 3111 "The Compound Authentication Binding Problem", draft- 3112 puthenkulam-eap-binding-04, Internet draft (work in 3113 progress), October 2003. 3115 [I-D.simon-emu-rfc2716bis] 3116 Simon, D., Aboba, B. and R. Hurst, "The EAP TLS 3117 Authentication Protocol", draft-simon-emu- 3118 rfc2716bis-11.txt, Internet Draft (work in progress), 3119 July 2007. 3121 [I-D.ietf-tls-rfc4346-bis] 3122 Dierks, T. and E. Rescorla, "The Transport Layer Security 3123 (TLS) Protocol Version 1.2", draft-ietf-tls- 3124 rfc4346-bis-05.txt, Internet draft (work in progress), 3125 September 2007. 3127 [MD5Collision] Klima, V., "Tunnels in Hash Functions: MD5 Collisions 3128 Within a Minute", Cryptology ePrint Archive, March 2006, 3129 http://eprint.iacr.org/2006/105.pdf 3131 [MishraPro] Mishra, A., Shin, M. and W. Arbaugh, "Pro-active Key 3132 Distribution using Neighbor Graphs", IEEE Wireless 3133 Communications, vol. 11, February 2004. 3135 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 3136 RFC 1661, July 1994. 3138 [RFC1968] Meyer, G. and K. Fox, "The PPP Encryption Control 3139 Protocol (ECP)", RFC 1968, June 1996. 3141 [RFC2230] Atkinson, R., "Key Exchange Delegation Record for the 3142 DNS", RFC 2230, November 1997. 3144 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 3145 (IKE)", RFC 2409, November 1998. 3147 [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D. 3148 and R. Wheeler, "A Method for Transmitting PPP Over 3149 Ethernet (PPPoE)", RFC 2516, February 1999. 3151 [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", 3152 RFC 2548, March 1999. 3154 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 3155 Implementation in Roaming", RFC 2607, June 1999. 3157 [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication 3158 Protocol", RFC 2716, October 1999. 3160 [RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for 3161 specifying the location of services (DNS SRV)", RFC 2782, 3162 February 2000. 3164 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. 3165 Wellington, "Secret Key Transaction Authentication for 3166 DNS (TSIG)", RFC 2845, May 2000. 3168 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, 3169 "Remote Authentication Dial In User Service (RADIUS)", 3170 RFC 2865, June 2000. 3172 [RFC3007] Wellington, B., "Simple Secure Domain Name System (DNS) 3173 Dynamic Update", RFC 3007, November 2000. 3175 [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 3176 3162, August 2001. 3178 [RFC3547] Baugher, M., Weis, B., Hardjono, T. and H. Harney, "The 3179 Group Domain of Interpretation", RFC 3547, July 2003. 3181 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 3182 Dial In User Service) Support For Extensible 3183 Authentication Protocol (EAP)", RFC 3579, September 2003. 3185 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese, 3186 "IEEE 802.1X Remote Authentication Dial In User Service 3187 (RADIUS) Usage Guidelines", RFC 3580, September 2003. 3189 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. 3190 Arkko, "Diameter Base Protocol", RFC 3588, September 3191 2003. 3193 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 3194 Public Keys Used For Exchanging Symmetric Keys", RFC 3195 3766, April 2004. 3197 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M. and K. 3198 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 3199 August 2004. 3201 [RFC4005] Calhoun, P., Zorn, G., Spence, D. and D. Mitton, 3202 "Diameter Network Access Server Application", RFC 4005, 3203 August 2005 3205 [RFC4017] Stanley, D., Walker, J. and B. Aboba, "EAP Method 3206 Requirements for Wireless LANs", RFC 4017, March 2005. 3208 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D. and S. 3209 Rose, "DNS Security Introduction and Requirements", RFC 3210 4033, March 2005. 3212 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D. and S. 3213 Rose, "Protocol Modifications for the DNS Security 3214 Extensions", RFC 4035, March 2005. 3216 [RFC4067] Loughney, J., Nakhjiri, M., Perkins, C. and R. Koodli, 3217 "Context Transfer Protocol (CXTP)", RFC 4067, July 2005. 3219 [RFC4072] Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible 3220 Authentication Protocol (EAP) Application", RFC 4072, 3221 August 2005. 3223 [RFC4118] Yang, L., Zerfos, P. and E. Sadot, "Architecture Taxonomy 3224 for Control and Provisioning of Wireless Access Points 3225 (CAPWAP)", RFC 4118, June 2005. 3227 [RFC4186] Haverinen, H. and J. Salowey, "Extensible Authentication 3228 Protocol Method for Global System for Mobile 3229 Communications (GSM) Subscriber Identity Modules (EAP- 3230 SIM)", RFC 4186, January 2006. 3232 [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication 3233 Protocol Method for 3rd Generation Authentication and Key 3234 Agreement (EAP-AKA)", RFC 4187, January 2006. 3236 [RFC4282] Aboba, B., Beadles, M., Arkko, J. and P. Eronen, "The 3237 Network Access Identifier", RFC 4282, December 2005. 3239 [RFC4284] Adrangi, F., Lortz, V., Bari, F. and P. Eronen, "Identity 3240 Selection Hints for the Extensible Authentication 3241 Protocol", RFC 4284, January 2006. 3243 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 3244 Internet Protocol", RFC 4301, December 2005. 3246 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 3247 RFC 4306, December 2005. 3249 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 3250 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 3252 [RFC4372] Adrangi, F., Lior, A., Korhonen, J. and J. Loughney, 3253 "Chargeable User Identity", RFC 4372, January 2006. 3255 [RFC4334] Housley, R. and T. Moore, "Certificate Extensions and 3256 Attributes Supporting Authentication in Point-to-Point 3257 Protocol (PPP) and Wireless Local Area Networks (WLAN)", 3258 RFC 4334, February 2006. 3260 [RFC4535] Harney, H., Meth, U., Colegrove, A. and G. Gross, 3261 "GSAKMP: Group Secure Association Group Management 3262 Protocol", RFC 4535, June 2006. 3264 [RFC4763] Vanderveen, M. and H. Soliman, "Extensible Authentication 3265 Protocol Method for Shared-secret Authentication and Key 3266 Establishment (EAP-SAKE)", RFC 4763, November 2006. 3268 [RFC4675] Congdon, P., Sanchez, M. and B. Aboba, "RADIUS Attributes 3269 for Virtual LAN and Priority Support", RFC 4675, 3270 September 2006. 3272 [RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and 3273 Implementation Guidelines", RFC 4718, October 2006. 3275 [RFC4764] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: a 3276 Pre-Shared Key Extensible Authentication Protocol (EAP) 3277 Method", RFC 4764, January 2007. 3279 [RFC3576bis] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. 3280 Aboba, "Dynamic Authorization Extensions to Remote 3281 Authentication Dial In User Service (RADIUS)", draft- 3282 ietf-radext-rfc3576bis-13.txt, Internet draft (work in 3283 progress), October 2007. 3285 [SP800-57] National Institute of Standards and Technology, 3286 "Recommendation for Key Management", Special Publication 3287 800-57, May 2006. 3289 [Token] Fantacci, R., Maccari, L., Pecorella, T. and F. Frosali, 3290 "A secure and performant token-based authentication for 3291 infrastructure and mesh 802.1X networks", IEEE 3292 Conference on Computer Communications, June 2006. 3294 [Tokenk] Ohba, Y., Das, S. and A. Duttak, "Kerberized Handover 3295 Keying: A Media-Independent Handover Key Management 3296 Architecture", Mobiarch 2007. 3298 Acknowledgments 3300 Thanks to Ashwin Palekar, Charlie Kaufman and Tim Moore of Microsoft, 3301 Jari Arkko of Ericsson, Dorothy Stanley of Aruba Networks, Bob 3302 Moskowitz of TruSecure, Jesse Walker of Intel, Joe Salowey of Cisco 3303 and Russ Housley of Vigil Security for useful feedback. 3305 Authors' Addresses 3307 Bernard Aboba 3308 Microsoft Corporation 3309 One Microsoft Way 3310 Redmond, WA 98052 3312 EMail: bernarda@microsoft.com 3313 Phone: +1 425 706 6605 3314 Fax: +1 425 936 7329 3316 Dan Simon 3317 Microsoft Research 3318 Microsoft Corporation 3319 One Microsoft Way 3320 Redmond, WA 98052 3322 EMail: dansimon@microsoft.com 3323 Phone: +1 425 706 6711 3324 Fax: +1 425 936 7329 3326 Pasi Eronen 3327 Nokia Research Center 3328 P.O. Box 407 3329 FIN-00045 Nokia Group 3330 Finland 3332 EMail: pasi.eronen@nokia.com 3334 Appendix A - Exported Parameters in Existing Methods 3336 This Appendix specifies Session-Id, Peer-Id, Server-Id and Key- 3337 Lifetime for EAP methods that have been published prior to this 3338 specification. Future EAP method specifications MUST include a 3339 definition of the Session-Id, Peer-Id and Server-Id (could be the 3340 null string). 3342 EAP-Identity 3344 The EAP-Identity method is defined in [RFC3748]. It does not derive 3345 keys, and therefore does not define the Session-Id. The Peer-Id and 3346 Server-Id are the null string (zero length). 3348 EAP-Notification 3350 The EAP-Notification method is defined in [RFC3748]. It does not 3351 derive keys and therefore does not define the Session-Id. The Peer- 3352 Id and Server-Id are the null string (zero length). 3354 EAP-MD5-Challenge 3356 The EAP-MD5-Challenge method is defined in [RFC3748]. It does not 3357 derive keys and therefore does not define the Session-Id. The Peer- 3358 Id and Server-Id are the null string (zero length). 3360 EAP-GTC 3362 The EAP-GTC method is defined in [RFC3748]. It does not derive keys 3363 and therefore does not define the Session-Id. The Peer-Id and 3364 Server-Id are the null string (zero length). 3366 EAP-OTP 3368 The EAP-OTP method is defined in [RFC3748]. It does not derive keys 3369 and therefore does not define the Session-Id. The Peer-Id and 3370 Server-Id are the null string (zero length). 3372 EAP-AKA 3374 EAP-AKA is defined in [RFC4187]. The EAP-AKA Session-Id is the 3375 concatenation of the EAP Type Code (0x17) with the contents of the 3376 RAND field from the AT_RAND attribute, followed by the contents of 3377 the AUTN field in the AT_AUTN attribute. 3379 The Peer-Id is the contents of the Identity field from the 3380 AT_IDENTITY attribute, using only the Actual Identity Length octets 3381 from the beginning, however. Note that the contents are used as they 3382 are transmitted, regardless of whether the transmitted identity was a 3383 permanent, pseudonym, or fast EAP re-authentication identity. The 3384 Server-Id is the null string (zero length). 3386 EAP-SIM 3388 EAP-SIM is defined in [RFC4186]. The EAP-SIM Session-Id is the 3389 concatenation of the EAP Type Code (0x12) with the contents of the 3390 RAND field from the AT_RAND attribute, followed by the contents of 3391 the NONCE_MT field in the AT_NONCE_MT attribute. 3393 The Peer-Id is the contents of the Identity field from the 3394 AT_IDENTITY attribute, using only the Actual Identity Length octets 3395 from the beginning, however. Note that the contents are used as they 3396 are transmitted, regardless of whether the transmitted identity was a 3397 permanent, pseudonym, or fast EAP re-authentication identity. The 3398 Server-Id is the null string (zero length). 3400 EAP-PSK 3402 EAP-PSK is defined in [RFC4764]. The EAP-PSK Session-Id is the 3403 concatenation of the EAP Type Code (0x2F) with the peer (RAND_P) and 3404 server (RAND_S) nonces. The Peer-Id is the contents of the ID_P 3405 field and the Server-Id is the contents of the ID_S field. 3407 EAP-SAKE 3409 EAP-SAKE is defined in [RFC4763]. The EAP-SAKE Session-Id is the 3410 concatenation of the EAP Type Code (0x30) with the contents of the 3411 RAND_S field from the AT_RAND_S attribute, followed by the contents 3412 of the RAND_P field in the AT_RAND_P attribute. Note that the EAP- 3413 SAKE Session-Id is not the same as the "Session ID" parameter chosen 3414 by the Server, which is sent in the first message, and replicated in 3415 subsequent messages. The Peer-Id is contained within the value field 3416 of the AT_PEERID attribute and the Server-Id, if available, is 3417 contained in the value field of the AT_SERVERID attribute. 3419 EAP-TLS 3421 For EAP-TLS, the Peer-Id, Server-Id and Session-Id are defined in [I- 3422 D.simon-emu-rfc2716bis]. 3424 Full Copyright Statement 3426 Copyright (C) The IETF Trust (2007). 3428 This document is subject to the rights, licenses and restrictions 3429 contained in BCP 78, and except as set forth therein, the authors 3430 retain all their rights. 3432 This document and the information contained herein are provided on an 3433 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3434 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 3435 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 3436 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 3437 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3438 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3440 Intellectual Property 3442 The IETF takes no position regarding the validity or scope of any 3443 Intellectual Property Rights or other rights that might be claimed to 3444 pertain to the implementation or use of the technology described in 3445 this document or the extent to which any license under such rights 3446 might or might not be available; nor does it represent that it has 3447 made any independent effort to identify any such rights. Information 3448 on the procedures with respect to rights in RFC documents can be 3449 found in BCP 78 and BCP 79. 3451 Copies of IPR disclosures made to the IETF Secretariat and any 3452 assurances of licenses to be made available, or the result of an 3453 attempt made to obtain a general license or permission for the use of 3454 such proprietary rights by implementers or users of this 3455 specification can be obtained from the IETF on-line IPR repository at 3456 http://www.ietf.org/ipr. 3458 The IETF invites any interested party to bring to its attention any 3459 copyrights, patents or patent applications, or other proprietary 3460 rights that may cover technology that may be required to implement 3461 this standard. Please address the information to the IETF at 3462 ietf-ipr@ietf.org. 3464 Acknowledgment 3466 Funding for the RFC Editor function is currently provided by the 3467 Internet Society. 3469 Open Issues 3471 Open issues relating to this specification are tracked on the 3472 following web site: 3474 http://www.drizzle.com/~aboba/EAP/