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