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