EAP Working Group Bernard Aboba INTERNET-DRAFT Dan Simon Category: Informational Microsoft J. Arkko 15 November 2004 Ericsson P. Eronen Nokia H. Levkowetz, Ed. ipUnplugged Extensible Authentication Protocol (EAP) Key Management Framework By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 22, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract The Extensible Authentication Protocol (EAP), defined in [RFC3748], enables extensible network access authentication. This document provides a framework for the generation, transport and usage of keying material generated by EAP authentication algorithms, known as "methods". Aboba, et al. Informational [Page 1] INTERNET-DRAFT EAP Key Management Framework 15 November 2004 Table of Contents 1. Introduction .......................................... 3 1.1 Requirements Language ........................... 3 1.2 Terminology ..................................... 3 1.3 Overview ........................................ 4 1.4 EAP Invariants .................................. 10 2. Security associations ................................. 12 2.1 EAP Method SA ................................... 13 2.2 EAP-Key SA ...................................... 14 2.3 AAA SA(s) ....................................... 14 2.4 Service SA(s) ................................... 14 3. Handoff Support ....................................... 17 3.1 Authorization Issues ............................ 18 3.2 Correctness Issues .............................. 19 4. Security Considerations .............................. 22 4.1 Security Terminology ............................ 22 4.2 Threat Model .................................... 22 4.3 Security Analysis ............................... 23 4.4 Man-in-the-middle Attacks ....................... 27 4.5 Denial of Service Attacks ....................... 27 4.6 Impersonation ................................... 28 4.7 Channel Binding ................................. 29 4.8 Key Strength .................................... 30 4.9 Key Wrap ........................................ 31 5. IANA Considerations ................................... 31 6. References ............................................ 31 6.1 Normative References ............................ 31 6.2 Informative References .......................... 32 Acknowledgments .............................................. 36 Author's Addresses ........................................... 36 Appendix A - Security Association Examples.................... 38 Intellectual Property Statement .............................. 42 Disclaimer of Validity ....................................... 42 Copyright Statement .......................................... 42 Aboba, et al. Informational [Page 2] INTERNET-DRAFT EAP Key Management Framework 15 November 2004 1. Introduction The Extensible Authentication Protocol (EAP), defined in [RFC3748], was designed to enable extensible authentication for network access in situations in which the IP protocol is not available. Originally developed for use with PPP [RFC1661], it has subsequently also been applied to IEEE 802 wired networks [IEEE8021X]. This document provides a framework for the generation, transport and usage of keying material generated by EAP authentication algorithms, known as "methods". In EAP keying material is generated by EAP methods. Part of this keying material may be used by EAP methods themselves and part of this material may be exported. The exported keying material may be transported by AAA protocols or transformed by Secure Association Protocols into session keys which are used by lower layer ciphersuites. This document describes each of these elements and provides a system-level security analysis. It also specifies the EAP key hierarchy. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119]. 1.2. Terminology This document frequently uses the following terms: authenticator The end of the link initiating EAP authentication. The term Authenticator is used in [IEEE-802.1X], and authenticator has the same meaning in this document. peer The end of the link that responds to the authenticator. In [IEEE-802.1X], this end is known as the Supplicant. Supplicant The end of the link that responds to the authenticator in [IEEE-802.1X]. In this document, this end of the link is called the peer. backend authentication server A backend authentication server is an entity that provides an authentication service to an authenticator. When used, this server typically executes EAP methods for the authenticator. This terminology is also used in [IEEE-802.1X]. Aboba, et al. Informational [Page 3] INTERNET-DRAFT EAP Key Management Framework 15 November 2004 AAA Authentication, Authorization and Accounting. AAA protocols with EAP support include RADIUS [RFC3579] and Diameter [I-D.ietf-aaa- eap]. In this document, the terms "AAA server" and "backend authentication server" are used interchangeably. EAP server The entity that terminates the EAP authentication method with the peer. In the case where no backend authentication server is used, the EAP server is part of the authenticator. In the case where the authenticator operates in pass-through mode, the EAP server is located on the backend authentication server. security association A set of policies and cryptographic state used to protect information. Elements of a security association may include cryptographic keys, negotiated ciphersuites and other parameters, counters, sequence spaces, authorization attributes, etc. 1.3. Overview EAP is typically deployed in order to support extensible network access authentication in situations where a peer desires network access via one or more authenticators. Since both the peer and authenticator may have more than one physical or logical port, a given peer may simultaneously access the network via multiple authenticators, or via multiple physical or logical ports on a given authenticator. Similarly, an authenticator may offer network access to multiple peers, each via a separate physical or logical port. The situation is illustrated in Figure 1. Where authenticators are deployed standalone, the EAP conversation occurs between the peer and authenticator, and the authenticator must locally implement an EAP method acceptable to the peer. However, one of the advantages of EAP is that it enables deployment of new authentication methods without requiring development of new code on the authenticator. While the authenticator may implement some EAP methods locally and use those methods to authenticate local users, it may at the same time act as a pass-through for other users and methods, forwarding EAP packets back and forth between the backend authentication server and the peer. This is accomplished by encapsulating EAP packets within the Authentication, Authorization and Accounting (AAA) protocol, spoken between the authenticator and backend authentication server. AAA protocols supporting EAP include RADIUS [RFC3579] and Diameter [I- D.ietf-aaa-eap]. Aboba, et al. Informational [Page 4] INTERNET-DRAFT EAP Key Management Framework 15 November 2004 +-+-+-+-+ | | | EAP | | Peer | | | +-+-+-+-+ | | | Peer Ports / | \ / | \ / | \ / | \ / | \ / | \ / | \ / | \ | | | | | | | | | Authenticator Ports +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ | | | | | | | Auth. | | Auth. | | Auth. | | | | | | | +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ \ | / \ | / \ | / EAP over AAA \ | / (optional) \ | / \ | / \ | / \ | / +-+-+-+-+ | | | AAA | |Server | | | +-+-+-+-+ Figure 1: Relationship between peer, authenticator and backend server Where EAP key derivation is supported, the conversation between the peer and the authenticator typically takes place in three phases: Phase 0: Discovery Phase 1: Authentication 1a: EAP authentication 1b: AAA-Key Transport (optional) Phase 2: Secure Association Establishment 2a: Unicast Secure Association 2b: Multicast Secure Association (optional) Aboba, et al. Informational [Page 5] INTERNET-DRAFT EAP Key Management Framework 15 November 2004 In the discovery phase (phase 0), peers locate authenticators and discover their capabilities. For example, a peer may locate an authenticator providing access to a particular network, or a peer may locate an authenticator behind a bridge with which it desires to establish a Secure Association. The authentication phase (phase 1) may begin once the peer and authenticator discover each other. This phase always includes EAP authentication (phase 1a). Where the chosen EAP method supports key derivation, in phase 1a keying material is derived on both the peer and the EAP server. This keying material may be used for multiple purposes, including protection of the EAP conversation and subsequent data exchanges. An additional step (phase 1b) is required in deployments which include a backend authentication server, in order to transport keying material (known as the AAA-Key) from the backend authentication server to the authenticator. A Secure Association exchange (phase 2) then occurs between the peer and authenticator in order to manage the creation and deletion of unicast (phase 2a) and multicast (phase 2b) security associations between the peer and authenticator. EAP may be used in the following scenarios: [a] Stationary peer. Where the peer is stationary it will establish communications with one or more authenticators while remaining in one location. In this scenario, EAP authentication typically represents only a small fraction of the total session time, so that it is acceptable for EAP authentication to occur each time the peer wishes to access the network. In this scenario, the Secure Association Protocol (Phase 2) MAY be ommitted. [b] Mobile peer. Where the peer is mobile, it may move its point of attachment from one authenticator to another, or between points of attachment on a single authenticator. In this scenario, it is often desirable to minimize the handoff latency, so that it is desirable to avoid EAP authentication each time the peer changes its point of attachment. In this scenario, the Secure Association Protocol (Phase 2) is REQUIRED. The conversation phases and relationship between the parties is shown in Figure 2. Aboba, et al. Informational [Page 6] INTERNET-DRAFT EAP Key Management Framework 15 November 2004 EAP peer Authenticator Auth. Server -------- ------------- ------------ |<----------------------------->| | | Discovery (phase 0) | | |<----------------------------->|<----------------------------->| | EAP auth (phase 1a) | AAA pass-through (optional) | | | | | |<----------------------------->| | | AAA-Key transport | | | (optional; phase 1b) | |<----------------------------->| | | Unicast Secure association | | | (phase 2a) | | | | | |<----------------------------->| | | Multicast Secure association | | | (optional; phase 2b) | | | | | Figure 2: Conversation Overview 1.3.1. Discovery Phase In the discovery phase (phase 0), the EAP peer and authenticator locate each other and discover each other's capabilities. Discovery can occur manually or automatically, depending on the lower layer over which EAP runs. Since authenticator discovery is handled outside of EAP, there is no need to provide this functionality within EAP. For example, where EAP runs over PPP, the EAP peer might be configured with a phone book providing phone numbers of authenticators and associated capabilities such as supported rates, authentication protocols or ciphersuites. In contrast, PPPoE [RFC2516] provides support for a Discovery Stage to allow a peer to identify the Ethernet MAC address of one or more authenticators and establish a PPPoE SESSION_ID. IEEE 802.11 [IEEE80211] also provides integrated discovery support utilizing Beacon and/or Probe Request/Response frames, allowing the peer (known as the station or STA) to determine the MAC address and capabilities of one or more authenticators (known as Access Point or APs). Aboba, et al. Informational [Page 7] INTERNET-DRAFT EAP Key Management Framework 15 November 2004 1.3.2. Authentication Phase Once the peer and authenticator discover each other, they exchange EAP packets. Typically, the peer desires access to the network, and the authenticators provide that access. In such a situation, access to the network can be provided by any authenticator attaching to the desired network, and the EAP peer is typically willing to send data traffic through any authenticator that can demonstrate that it is authorized to provide access to the desired network. An EAP authenticator may handle the authentication locally, or it may act as a pass-through to a backend authentication server. In the latter case the EAP exchange occurs between the EAP peer and a backend authenticator server, with the authenticator forwarding EAP packets between the two. The entity which terminates EAP authentication with the peer is known as the EAP server. Where pass- through is supported, the backend authentication server functions as the EAP server; where authentication occurs locally, the EAP server is the authenticator. Where a backend authentication server is present, at the successful completion of an authentication exchange, the AAA-Key is transported to the authenticator (phase 1b). EAP may also be used when it is desired for two network devices (e.g. two switches or routers) to authenticate each other, or where two peers desire to authenticate each other and set up a secure association suitable for protecting data traffic. Some EAP methods exist which only support one-way authentication; however, EAP methods deriving keys are required to support mutual authentication. In either case, it can be assumed that the parties do not utilize the link to exchange data traffic unless their authentication requirements have been met. For example, a peer completing mutual authentication with an EAP server will not send data traffic over the link until the EAP server has authenticated successfully to the peer, and a Secure Association has been negotiated. Since EAP is a peer-to-peer protocol, an independent and simultaneous authentication may take place in the reverse direction. Both peers may act as authenticators and authenticatees at the same time. Successful completion of EAP authentication and key derivation by a peer and EAP server does not necessarily imply that the peer is committed to joining the network associated with an EAP server. Rather, this commitment is implied by the creation of a security association between the EAP peer and authenticator, as part of the Secure Association Protocol (phase 2). As a result, EAP may be used for "pre-authentication" in situations where it is necessary to pre- Aboba, et al. Informational [Page 8] INTERNET-DRAFT EAP Key Management Framework 15 November 2004 establish EAP security associations in order to decrease handoff or roaming latency. 1.3.3. Secure Association Phase The Secure Association phase (phase 2), if it occurs, begins after the completion of EAP authentication (phase 1a) and key transport (phase 1b), and typically supports the following features: [1] Generation of fresh transient session keys (TSKs). Where AAA-Key caching is supported, the EAP peer may initiate a new session using a AAA-Key that was used in a previous session. Were the TSKs to be derived from a portion of the AAA-Key, this would result in reuse of the session keys which could expose the underlying ciphersuite to attack. As a result, where AAA-Key caching is supported, freshness of TSKs MUST be provided by mechanisms outside of EAP. This is typically handled within the Secure Association protocol via the exchange of nonces or counters, which are then mixed with the AAA-Key in order to generate fresh unicast (phase 2a) and possibly multicast (phase 2b) session keys. By not using the AAA-Key directly to protect data, the secure Association Protocol protects against compromise of the AAA-Key. [2] Entity Naming. A basic feature of a Secure Association Protocol is the explicit naming of the parties engaged in the exchange. Explicit identification of the parties is critical, since without this the parties engaged in the exchange are not identified and the scope of the transient session keys (TSKs) generated during the exchange is undefined. As illustrated in Figure 1, both the peer and NAS may have more than one physical or virtual port, so that port identifiers are typically inappropriate as a naming mechanism. [3] Secure capabilities negotiation. This provides for the secure negotiation of usage modes, session parameters (such as key lifetimes), ciphersuites, and required filters, including confirmation of the capabilities discovered during phase 0. By securely negotiating session parameters, the secure Association Protocol protects against spoofing during the discovery phase and ensures that the peer and authenticator are in agreement about how data is to be secured. [4] Key activation and deletion. In order for the peer and authenticator to communicate securely, it is necessary for both sides to derive the same session keys, and remain in sync with respect to key state going forward. One of the functions of the Secure Association Protocol is to synchronize the activation and Aboba, et al. Informational [Page 9] INTERNET-DRAFT EAP Key Management Framework 15 November 2004 deletion of keys so as to enable seamless rekey, or recovery from partial or complete loss of key state by the peer or authenticator. [5] Mutual proof of possession of the AAA-Key. This demonstrates that both the peer and authenticator have been authenticated and authorized by the backend authentication server. Since mutual proof of possession is not the same as mutual authentication, the peer cannot verify authenticator assertions (including the authenticator identity) as a result of this exchange. 1.4. EAP Invariants Certain basic characteristics, known as the "EAP Invariants" hold true for EAP implementations on all media: Media independence Method independence Ciphersuite independence 1.4.1. Media Independence One of the goals of EAP is to allow EAP methods to function on any lower layer meeting the criteria outlined in [RFC3748], Section 3.1. For example, as described in [RFC3748], EAP authentication can be run over PPP [RFC1661], IEEE 802 wired networks [IEEE8021X], and IEEE 802.11 wireless LANs [IEEE80211i]. In order to maintain media independence, it is necessary for EAP to avoid inclusion of media-specific elements. For example, EAP methods cannot be assumed to have knowledge of the lower layer over which they are transported, and cannot utilize identifiers associated with a particular usage environment (e.g. MAC addresses). The need for media independence has also motivated the development of the three phase exchange. Since discovery is typically media- specific, this function is handled outside of EAP, rather than being incorporated within it. Similarly, the Secure Association Protocol often contains media dependencies such as negotiation of media- specific ciphersuites or session parameters, and as a result this functionality also cannot be incorporated within EAP. Note that media independence may be retained within EAP methods that support channel binding or method-specific identification. An EAP method need not be aware of the content of an identifier in order to use it. This enables an EAP method to use media-specific identifiers such as MAC addresses without compromising media independence. To support channel binding, an EAP method can pass binding parameters to the AAA server in the form of an opaque blob, and receive Aboba, et al. Informational [Page 10] INTERNET-DRAFT EAP Key Management Framework 15 November 2004 confirmation of whether the parameters match, without requiring media-specific knowledge. 1.4.2. Method Independence By enabling pass-through, authenticators can support any method implemented on the peer and server, not just locally implemented methods. This allows the authenticator to avoid implementing code for each EAP method required by peers. In fact, since a pass-through authenticator is not required to implement any EAP methods at all, it cannot be assumed to support any EAP method-specific code. As a result, as noted in [RFC3748], authenticators must by default be capable of supporting any EAP method. Since the Discovery and Secure Association exchanges are also method independent, an authenticator can carry out the three phase exchange without having an EAP method in common with the peer. This is useful where there is no single EAP method that is both mandatory-to-implement and offers acceptable security for the media in use. For example, the [RFC3748] mandatory-to-implement EAP method (MD5-Challenge) does not provide dictionary attack resistance, mutual authentication or key derivation, and as a result is not appropriate for use in wireless LAN authentication [WLANREQ]. However, despite this it is possible for the peer and authenticator to interoperate as long as a suitable EAP method is supported on the EAP server. 1.4.3. Ciphersuite Independence While EAP methods may negotiate the ciphersuite used in protection of the EAP conversation, the ciphersuite used for the protection of the data exchanged after EAP authentication has completed is negotiated between the peer and authenticator out-of-band of EAP. Since ciphersuite negotiation is assumed to occur out-of-band, there is no need for ciphersuite negotiation within EAP. Since ciphersuite negotiation occurs outside of EAP, EAP methods generate keying material that is ciphersuite-independent. For example, within PPP, the ciphersuite is negotiated within the Encryption Control Protocol (ECP) defined in [RFC1968], after EAP authentication is completed. Within [IEEE80211i], the AP ciphersuites are advertised in the Beacon and Probe Responses prior to EAP authentication, and are securely verified during a 4-way handshake exchange after EAP authentication has completed. Advantages of ciphersuite-independence include: Aboba, et al. Informational [Page 11] INTERNET-DRAFT EAP Key Management Framework 15 November 2004 Reduced update requirements If EAP methods were to specify how to derive transient session keys for each ciphersuite, they would need to be updated each time a new ciphersuite is developed. In addition, backend authentication servers might not be usable with all EAP-capable authenticators, since the backend authentication server would also need to be updated each time support for a new ciphersuite is added to the authenticator. Reduced EAP method complexity Requiring each EAP method to include ciphersuite-specific code for transient session key derivation would increase method complexity and result in duplicated effort. Simplified configuration The ciphersuite is negotiated between the peer and authenticator out-of-band of EAP. The backend authentication server is neither a party to this negotiation, nor is it an intermediary in the data flow between the EAP peer and authenticator. The backend authentication server may not have knowledge of the ciphersuites and negotiation policies implemented by the peer and authenticator, or be aware of the ciphersuite negotiated between them. This simplifies the configuration of the backend authentication server. For example, since ECP negotiation occurs after authentication, when run over PPP, the EAP peer, authenticator and backend authentication server may not anticipate the negotiated ciphersuite and therefore this information cannot be provided to the EAP method. 2. Security Associations During EAP authentication and subsequent exchanges, four types of security associations (SAs) are created: [1] EAP method SA. This SA is between the peer and EAP server. It stores state that can be used for "fast reconnect" or other functionality in some EAP methods. Not all EAP methods create such an SA. [2] EAP-Key SA. This is an SA between the peer and EAP server, which is used to store the keying material exported by the EAP method. Current EAP server implementations do not retain this SA after the EAP conversation completes, but proposals such as [IEEE-03-084] and [I-D.irtf-aaaarch-handoff] use this SA for purposes such as pre- emptive key distribution. Aboba, et al. Informational [Page 12] INTERNET-DRAFT EAP Key Management Framework 15 November 2004 [3] AAA SA(s). These SAs are between the authenticator and the backend authentication server. They permit the parties to mutually authenticate each other and protect the communications between them. [4] Service SA(s). These SAs are between the peer and authenticator, and they are created as a result of phases 1-2 of the conversation (see Section 1.3). 2.1. EAP Method SA (peer - EAP server) An EAP method may store some state on the peer and EAP server even after phase 1a has completed. Typically, this is used for "fast reconnect": the peer and EAP server can confirm that they are still talking to the same party, perhaps using fewer round-trips or less computational power. In this case, the EAP method SA is essentially a cache for performance optimization, and either party may remove the SA from its cache at any point. An EAP method may also keep state in order to support pseudonym-based identity protection. This is typically a cache as well (the information can be recreated if the original EAP method SA is lost), but may be stored for longer periods of time. The EAP method SA is not restricted to a particular service or authenticator and is most useful when the peer accesses many different authenticators. An EAP method is responsible for specifying how the parties select if an existing EAP method SA should be used, and if so, which one. Where multiple backend authentication servers are used, EAP method SAs are not typically synchronized between them. EAP method implementations should consider the appropriate lifetime for the EAP method SA. "Fast reconnect" assumes that the information required (primarily the keys in the EAP method SA) hasn't been compromised. In case the original authentication was carried out using, for instance, a smart card, it may be easier to compromise the EAP method SA (stored on the PC, for instance), so typically the EAP method SAs have a limited lifetime. Contents: o Implicitly, the EAP method this SA refers to o Internal (non-exported) cryptographic state o EAP method SA name o SA lifetime Aboba, et al. Informational [Page 13] INTERNET-DRAFT EAP Key Management Framework 15 November 2004 2.2. EAP-Key SA This is an SA between the peer and EAP server, which is used to store the keying material exported by the EAP method. Current EAP server implementations do not retain this SA after the EAP conversation completes, but future implementations could use this SA for pre- emptive key distribution. Contents: o MSK and EMSK names o MSK and EMSK o SA lifetime 2.3. AAA SA(s) (authenticator - backend authentication server) In order for the authenticator and backend authentication server to authenticate each other, they need to store some information. In case the authenticator and backend authentication server are colocated, and they communicate using local procedure calls or shared memory, this SA need not necessarily contain any information. 2.4. Service SA(s) (peer - authenticator) The service SAs store information about the service being provided. These include the Root service SA and derived unicast and multicast service SAs. The Root service SA is established as the result of the completion of EAP authentication (phase 1a) and AAA-Key derivation or transport (phase 1b). It includes: o Service parameters (or at least those parameters that are still needed) o On the authenticator, service authorization information received from the backend authentication server (or necessary parts of it) o On the peer, usually locally configured service authorization information. o The AAA-Key, if it can be needed again (to refresh and/or resynchronize other keys or for another reason) o AAA-Key lifetime Unicast and (optionally) multicast service SAs are derived from the Root service SA, via the Secure Association Protocol. In order for unicast and multicast service SAs and associated TSKs to be established, it is not necessary for EAP authentication (phase 1a) to Aboba, et al. Informational [Page 14] INTERNET-DRAFT EAP Key Management Framework 15 November 2004 be rerun each time. Instead, the Secure Association Protocol can be used to mutually prove possession of the AAA-Key and create associated unicast (phase 2a) and multicast (phase 2b) service SAs and TSKs, enabling the EAP exchange to be bypassed. Unicast and multicast service SAs include: o Service parameters negotiated by the Secure Association Protocol. o Endpoint identifiers. o Transient Session Keys used to protect the communication. o Transient Session Key lifetime. One function of the Secure Association Protocol is to bind the the unicast and multicast service SAs and TSKs to endpoint identifiers. For example, within [IEEE802.11i], the 4-way handshake binds the TSKs to the MAC addresses of the endpoints; in [IKEv2], the TSKs are bound to the IP addresses of the endpoints and the negotiated SPI. It is possible for more than one unicast or multicast service SA to be derived from a single Root service SA. However, a unicast or multicast service SA is always descended from only one Root service SA. Unicast or multicast service SAs descended from the same Root service SA may utilize the same security parameters (e.g. mode, ciphersuite, etc.) or they may utilize different parameters. An EAP peer may be able to negotiate multiple service SAs with a given authenticator, or may be able to maintain one or more service SAs with multiple authenticators, depending on the properties of the media. Except where explicitly specified by the Secure Association Protocol, it should not be assumed that the installation of new service SAs implies deletion of old service SAs. It is possible for multicast Root service SAs to between the same EAP peer and authenticator; during a re-key of a unicast or multicast service SA it is possible for two service SAs to exist during the period between when the new service SA and corresponding TSKs are calculated and when they are installed. Similarly, deletion or creation of a unicast or multicast service SA does not necessarily imply deletion or creation of related unicast or multicast service SAs, unless specified by the Secure Association protocol. For example, a unicast service SA may be rekeyed without implying a rekey of the multicast service SA. The deletion of the Root service SA does not necessarily imply the deletion of the derived unicast and multicast service SAs and associated TSKs. Failure to mutually prove possession of the AAA-Key during the Secure Association Protocol exchange need not be grounds Aboba, et al. Informational [Page 15] INTERNET-DRAFT EAP Key Management Framework 15 November 2004 for deletion of the AAA-Key by both parties; the action to be taken is defined by the Secure Association Protocol. 2.4.1. Sharing service SAs A single service may be provided by multiple logical or physical service elements. Each service is responsible for specifying how changing service elements is handled. Some approaches include: Transparent sharing If the service parameters visible to the other party (either peer or authenticator) do not change, the service can be moved without requiring cooperation from the other party. Whether such a move should be supported or used depends on implementation and administrative considerations. For instance, an administrator may decide to configure a group of IKEv2/IPsec gateways in a cluster for high-availability purposes, if the implementation used supports this. The peer does not necessarily have any way of knowing when the change occurs. No sharing If the service parameters require changing, some changes may require terminating the old service, and starting a new conversation from phase 0. This approach is used by all services for at least some parameters, and it doesn't require any protocol for transferring the service SA between the service elements. The service may support keeping the old service element active while the new conversation takes phase, to decrease the time the service is not available. Some sharing The service may allow changing some parameters by simply agreeing about the new values. This may involve a similar exchange as in phase 2, or perhaps a shorter conversation. This option usually requires some protocol for transferring the service SA between the elements. An administrator may decide not to enable this feature at all, and typically the sharing is restricted to some particular service elements (defined either by a service parameter, or simple administrative decision). If the old and new service element do not support such "context transfer", this approach falls back to the previous option (no transfer). Services supporting this feature should also consider what changes require new authorization from the backend authentication server (see Section 4.2). Aboba, et al. Informational [Page 16] INTERNET-DRAFT EAP Key Management Framework 15 November 2004 Note that these considerations are not limited to service parameters related to the authenticator--they apply to peer's parameters as well. 3. Handoff Support With EAP, a number of mechanisms may be utilized in order to reduce the latency of handoff between authenticators. One such mechanism is EAP pre-authentication, in which EAP is utilized to pre-establish a AAA-Key on an authenticator prior to arrival of the peer. "Fast Handoff" is defined as a conversation in which EAP exchange (phase 1a) and associated AAA pass-through is bypassed, so as to reduce latency. Unlike EAP pre-authentication, "Fast Handoff" mechanisms do not result in additional AAA server load. Fast handoff mechanisms include: [a] Pre-emptive handoff. In this technique, the AAA server pre- establishes key state on the authenticator prior to arrival of the peer, without completion of EAP authentication. As described in [IEEE-03-084] and [I.D.irtf-aaaarch-handoff], this technique includes conventional AAA-Key transport, but without an EAP authentication. [b] Context transfer. In this technique, the old authenticator transfers the session text to the new authenticator, either prior to, or after the arrival of the peer. As a result, AAA-Key transport (phase 1b) is bypassed. Regardless of how the AAA-Key is provisioned on a given authenticator, AAA-Key caching may be utilized in order to enable a peer to quickly re-establish a session with an authenticator. Where key caching is supported, once the AAA-Key is derived and/or transported to the authenticator, it may remain cached on the peer and authenticator, even after a subsequent session terminates. To initiate a subsequent session with the same authenticator, the peer may utilize the Secure Association Protocol to confirm mutual possession of the AAA-Key by the peer and authenticator, thereby re- activating the AAA-Key for use in a subsequent session. The introduction of handoff support introduces new security vulnerabilities as well as requirements for the secure handling of authorization context. These issues are discussed in the sections that follow. Aboba, et al. Informational [Page 17] INTERNET-DRAFT EAP Key Management Framework 15 November 2004 3.1. Authorization Issues In a typical network access scenario (dial-in, wireless LAN, etc.) access control mechanisms are typically applied. These mechanisms include user authentication as well as authorization for the offered service. As a part of the authentication process, the AAA network determines the user's authorization profile. The user authorizations are transmitted by the backend authentication server to the EAP authenticator (also known as the Network Access Server or authenticator) included with the AAA-Token, which also contains the AAA-Key, in Phase 1b of the EAP conversation. Typically, the profile is determined based on the user identity, but a certificate presented by the user may also provide authorization information. The backend authentication server is responsible for making a user authorization decision, answering the following questions: [a] Is this a legitimate user for this particular network? [b] Is this user allowed the type of access he or she is requesting? [c] Are there any specific parameters (mandatory tunneling, bandwidth, filters, and so on) that the access network should be aware of for this user? [d] Is this user within the subscription rules regarding time of day? [e] Is this user within his limits for concurrent sessions? [f] Are there any fraud, credit limit, or other concerns that indicate that access should be denied? While the authorization decision is in principle simple, the process is complicated by the distributed nature of AAA decision making. Where brokering entities or proxies are involved, all of the AAA devices in the chain from the authenticator to the home AAA server are involved in the decision. For instance, a broker can disallow access even if the home AAA server would allow it, or a proxy can add authorizations (e.g., bandwidth limits). Decisions can be based on static policy definitions and profiles as well as dynamic state (e.g. time of day or limits on the number of concurrent sessions). In addition to the Accept/Reject decision made by the AAA chain, parameters or constraints can be communicated to the authenticator. Aboba, et al. Informational [Page 18] INTERNET-DRAFT EAP Key Management Framework 15 November 2004 The criteria for Accept/Reject decisions or the reasons for choosing particular authorizations are typically not communicated to the authenticator, only the final result. As a result, the authenticator has no way to know what the decision was based on. Was a set of authorization parameters sent because this service is always provided to the user, or was the decision based on the time/day and the capabilities of the requesting authenticator device? 3.2. Correctness Issues Bypassing all or portions of the AAA conversation creates challenges in ensuring that authorization is properly handled. These include: [a] Consistent application of session time limits. A fast handoff should not automatically increase the available session time, allowing a user to endlessly extend their network access by changing the point of attachment. [b] Avoidance of privilege elevation. A fast handoff should not result in a user being granted access to services which they are not entitled to. [c] Consideration of dynamic state. In situations in which dynamic state is involved in the access decision (day/time, simultaneous session limit) it should be possible to take this state into account either before or after access is granted. Note that consideration of network-wide state such as simultaneous session limits can typically only be taken into account by the backend authentication server. [d] Encoding of restrictions. Since a authenticator may not be aware of the criteria considered by a backend authentication server when allowing access, in order to ensure consistent authorization during a fast handoff it may be necessary to explicitly encode the restrictions within the authorizations provided in the AAA-Token. [e] State validity. The introduction of fast handoff should not render the authentication server incapable of keeping track of network- wide state. A fast handoff mechanism capable of addressing these concerns is said to be "correct". One condition for correctness is as follows: For a fast handoff to be "correct" it MUST establish on the new device the same context as would have been created had the new device completed a AAA conversation with the authentication server. A properly designed fast handoff scheme will only succeed if it is "correct" in this way. If a successful fast handoff would establish Aboba, et al. Informational [Page 19] INTERNET-DRAFT EAP Key Management Framework 15 November 2004 "incorrect" state, it is preferable for it to fail, in order to avoid creation of incorrect context. Some backend authentication server and authenticator configurations are incapable of meeting this definition of "correctness". For example, if the old and new device differ in their capabilities, it may be difficult to meet this definition of correctness in a fast handoff mechanism that bypasses AAA. Backend authentication servers often perform conditional evaluation, in which the authorizations returned in an Access-Accept message are contingent on the authenticator or on dynamic state such as the time of day or number of simultaneous sessions. For example, in a heterogeneous deployment, the backend authentication server might return different authorizations depending on the authenticator making the request, in order to make sure that the requested service is consistent with the authenticator capabilities. If differences between the new and old device would result in the backend authentication server sending a different set of messages to the new device than were sent to the old device, then if the fast handoff mechanism bypasses AAA, then the fast handoff cannot be carried out correctly. For example, if some authenticator devices within a deployment support dynamic VLANs while others do not, then attributes present in the Access-Request (such as the authenticator-IP-Address, authenticator-Identifier, Vendor-Identifier, etc.) could be examined to determine when VLAN attributes will be returned, as described in [RFC3580]. VLAN support is defined in [IEEE8021Q]. If a fast handoff bypassing the backend authentication server were to occur between a authenticator supporting dynamic VLANs and another authenticator which does not, then a guest user with access restricted to a guest VLAN could be given unrestricted access to the network. Similarly, in a network where access is restricted based on the day and time, Service Set Identifier (SSID), Calling-Station-Id or other factors, unless the restrictions are encoded within the authorizations, or a partial AAA conversation is included, then a fast handoff could result in the user bypassing the restrictions. In practice, these considerations limit the situations in which fast handoff mechanisms bypassing AAA can be expected to be successful. Where the deployed devices implement the same set of services, it may be possible to do successful fast handoffs within such mechanisms. However, where the supported services differ between devices, the fast handoff may not succeed. For example, [RFC2865] section 1.1 states: Aboba, et al. Informational [Page 20] INTERNET-DRAFT EAP Key Management Framework 15 November 2004 "A authenticator that does not implement a given service MUST NOT implement the RADIUS attributes for that service. For example, a authenticator that is unable to offer ARAP service MUST NOT implement the RADIUS attributes for ARAP. A authenticator MUST treat a RADIUS access-accept authorizing an unavailable service as an access-reject instead." Note that this behavior only applies to attributes that are known, but not implemented. For attributes that are unknown, [RFC2865] Section 5 states: "A RADIUS server MAY ignore Attributes with an unknown Type. A RADIUS client MAY ignore Attributes with an unknown Type." In order to perform a correct fast handoff, if a new device is provided with RADIUS context for a known but unavailable service, then it MUST process this context the same way it would handle a RADIUS Access-Accept requesting an unavailable service. This MUST cause the fast handoff to fail. However, if a new device is provided with RADIUS context that indicates an unknown attribute, then this attribute MAY be ignored. Although it may seem somewhat counter-intuitive, failure is indeed the "correct" result where a known but unsupported service is requested. Presumably a correctly configured backend authentication server would not request that a device carry out a service that it does not implement. This implies that if the new device were to complete a AAA conversation that it would be likely to receive different service instructions. In such a case, failure of the fast handoff is the desired result. This will cause the new device to go back to the AAA server in order to receive the appropriate service definition. In practice, this implies that fast handoff mechanisms which bypass AAA are most likely to be successful within a homogeneous device deployment within a single administrative domain. For example, it would not be advisable to carry out a fast handoff bypassing AAA between a authenticator providing confidentiality and another authenticator that does not support this service. The correct result of such a fast handoff would be a failure, since if the handoff were blindly carried out, then the user would be moved from a secure to an insecure channel without permission from the backend authentication server. Thus the definition of a "known but unsupported service" MUST encompass requests for unavailable security services. This includes vendor-specific attributes related to security, such as those described in [RFC2548]. Aboba, et al. Informational [Page 21] INTERNET-DRAFT EAP Key Management Framework 15 November 2004 4. Security Considerations 4.1. Security Terminology "Cryptographic binding", "Cryptographic separation", "Key strength" and "Mutual authentication" are defined in [RFC3748] and are used with the same meaning here. 4.2. Threat Model The EAP threat model is described in [RFC3748] Section 7.1. In order to address these threats, EAP relies on the security properties of EAP methods (known as "security claims", described in [RFC3784] Section 7.2.1). EAP method requirements for application such as Wireless LAN authentication are described in [WLANREQ]. The RADIUS threat model is described in [RFC3579] Section 4.1, and responses to these threats are described in [RFC3579] Sections 4.2 and 4.3. Among other things, [RFC3579] Section 4.2 recommends the use of IPsec ESP with non-null transform to provide per-packet authentication and confidentiality, integrity and replay protection for RADIUS/EAP. Given the existing documentation of EAP and AAA threat models and responses, there is no need to duplicate that material here. However, there are many other system-level threats no covered in these document which have not been described or analyzed elsewhere. These include: [1] An attacker may try to modify or spoof Secure Association Protocol packets. [2] An attacker compromising an authenticator may provide incorrect information to the EAP peer and/or server via out-of-band mechanisms (such as via a AAA or lower layer protocol). This includes impersonating another authenticator, or providing inconsistent information to the peer and EAP server. [3] An attacker may attempt to perform downgrading attacks on the ciphersuite negotiation within the Secure Association Protocol in order to ensure that a weaker ciphersuite is used to protect data. Depending on the lower layer, these attacks may be carried out without requiring physical proximity. In order to address these threats, [Housley56] describes the mandatory system security properties: Aboba, et al. Informational [Page 22] INTERNET-DRAFT EAP Key Management Framework 15 November 2004 Algorithm independence Wherever cryptographic algorithms are chosen, the algorithms must be negotiable, in order to provide resilient against compromise of a particular algorithm. Algorithm independence must be demonstrated within all aspects of the system, including within EAP, AAA and the Secure Association Protocol. However, for interoperability, at least one suite of algorithms MUST be implemented. Strong, fresh session keys Session keys must be demonstrated to be strong and fresh in all circumstances, while at the same time retaining algorithm independence. Replay protection All protocol exchanges must be replay protected. This includes exchanges within EAP, AAA, and the Secure Association Protocol. Authentication All parties need to be authenticated. The confidentiality of the authenticator must be maintained. No plaintext passwords are allowed. Authorization EAP peer and authenticator authorization must be performed. Session keys Confidentiality of session keys must be maintained. Ciphersuite negotiation The selection of the "best" ciphersuite must be securely confirmed. Unique naming Session keys must be uniquely named. Domino effect Compromise of a single authenticator cannot compromise any other part of the system, including session keys and long-term secrets. Key binding The key must be bound to the appropriate context. 4.3. Security Analysis Figure 6 illustrates the relationship between the peer, authenticator and backend authentication server. Aboba, et al. Informational [Page 23] INTERNET-DRAFT EAP Key Management Framework 15 November 2004 EAP peer /\ / \ Protocol: EAP / \ Protocol: Secure Association Auth: Mutual / \ Auth: Mutual Unique keys: / \ Unique keys: TSKs TEKs,EMSK / \ / \ EAP server +--------------+ Authenticator Protocol: AAA Auth: Mutual Unique key: AAA session key Figure 6: Relationship between peer, authenticator and auth. server The peer and EAP server communicate using EAP [RFC3748]. The security properties of this communication are largely determined by the chosen EAP method. Method security claims are described in [RFC3748] Section 7.2. These include the key strength, protected ciphersuite negotiation, mutual authentication, integrity protection, replay protection, confidentiality, key derivation, key strength, dictionary attack resistance, fast reconnect, cryptographic binding, session independence, fragmentation and channel binding claims. At a minimum, methods claiming to support key derivation must also support mutual authentication. As noted in [RFC3748] Section 7.10: EAP Methods deriving keys MUST provide for mutual authentication between the EAP peer and the EAP Server. Ciphersuite independence is also required: Keying material exported by EAP methods MUST be independent of the ciphersuite negotiated to protect data. In terms of key strength and freshness, [RFC3748] Section 10 says: EAP methods SHOULD ensure the freshness of the MSK and EMSK even in cases where one party may not have a high quality random number generator.... In order to preserve algorithm independence, EAP methods deriving keys SHOULD support (and document) the protected negotiation of the ciphersuite used to protect the EAP conversation between the peer and server... In order to enable deployments requiring strong keys, EAP methods supporting key derivation SHOULD be capable of generating an MSK and EMSK, each with an effective key strength of at least 128 bits. The authenticator and backend authentication server communicate using a AAA protocol such as RADIUS [RFC3579] or Diameter [I-D.ietf-aaa- Aboba, et al. Informational [Page 24] INTERNET-DRAFT EAP Key Management Framework 15 November 2004 eap]. As noted in [RFC3588] Section 13, Diameter must be protected by either IPsec ESP with non-null transform or TLS. As a result, Diameter requires per-packet integrity and confidentiality. Replay protection must be supported. For RADIUS, [RFC3579] Section 4.2 recommends that RADIUS be protected by IPsec ESP with a non-null transform, and where IPsec is implemented replay protection must be supported. The peer and authenticator communicate using the Secure Association Protocol. As noted in the figure, each party in the exchange mutually authenticates with each of the other parties, and derives a unique key. All parties in the diagram have access to the AAA-Key. The EAP peer and backend authentication server mutually authenticate via the EAP method, and derive the TEKs and EMSK which are known only to them. The TEKs are used to protect some or all of the EAP conversation between the peer and authenticator, so as to guard against modification or insertion of EAP packets by an attacker. The degree of protection afforded by the TEKs is determined by the EAP method; some methods may protect the entire EAP packet, including the EAP header, while other methods may only protect the contents of the Type-Data field, defined in [RFC3748]. Since EAP is spoken only between the EAP peer and server, if a backend authentication server is present then the EAP conversation does not provide mutual authentication between the peer and authenticator, only between the EAP peer and EAP server (backend authentication server). As a result, mutual authentication between the peer and authenticator only occurs where a Secure Association protocol is used, such the unicast and group key derivation handshake supported in [IEEE80211i]. This means that absent use of a secure Association Protocol, from the point of view of the peer, EAP mutual authentication only proves that the authenticator is trusted by the backend authentication server; the identity of the authenticator is not confirmed. Utilizing the AAA protocol, the authenticator and backend authentication server mutually authenticate and derive session keys known only to them, used to provide per-packet integrity and replay protection, authentication and confidentiality. The AAA-Key is distributed by the backend authentication server to the authenticator over this channel, bound to attributes constraining its usage, as part of the AAA-Token. The binding of attributes to the AAA-Key within a protected package is important so the authenticator receiving the AAA-Token can determine that it has not been compromised, and that the keying material has not been replayed, or Aboba, et al. Informational [Page 25] INTERNET-DRAFT EAP Key Management Framework 15 November 2004 mis-directed in some way. The security properties of the EAP exchange are dependent on each leg of the triangle: the selected EAP method, AAA protocol and the Secure Association Protocol. Assuming that the AAA protocol provides protection against rogue authenticators forging their identity, then the AAA-Token can be assumed to be sent to the correct authenticator, and where it is wrapped appropriately, it can be assumed to be immune to compromise by a snooping attacker. Where an untrusted AAA intermediary is present, the AAA-Token must not be provided to the intermediary so as to avoid compromise of the AAA-Token. This can be avoided by use of re-direct as defined in [RFC3588]. When EAP is used for authentication on PPP or wired IEEE 802 networks, it is typically assumed that the link is physically secure, so that an attacker cannot gain access to the link, or insert a rogue device. EAP methods defined in [RFC3748] reflect this usage model. These include EAP MD5, as well as One-Time Password (OTP) and Generic Token Card. These methods support one-way authentication (from EAP peer to authenticator) but not mutual authentication or key derivation. As a result, these methods do not bind the initial authentication and subsequent data traffic, even when the the ciphersuite used to protect data supports per-packet authentication and integrity protection. As a result, EAP methods not supporting mutual authentication are vulnerable to session hijacking as well as attacks by rogue devices. On wireless networks such as IEEE 802.11 [IEEE80211], these attacks become easy to mount, since any attacker within range can access the wireless medium, or act as an access point. As a result, new ciphersuites have been proposed for use with wireless LANs [IEEE80211i] which provide per-packet authentication, integrity and replay protection. In addition, mutual authentication and key derivation, provided by methods such as EAP-TLS [RFC2716] are required [IEEE80211i], so as to address the threat of rogue devices, and provide keying material to bind the initial authentication to subsequent data traffic. If the selected EAP method does not support mutual authentication, then the peer will be vulnerable to attack by rogue authenticators and backend authentication servers. If the EAP method does not derive keys, then TSKs will not be available for use with a negotiated ciphersuite, and there will be no binding between the initial EAP authentication and subsequent data traffic, leaving the session Aboba, et al. Informational [Page 26] INTERNET-DRAFT EAP Key Management Framework 15 November 2004 vulnerable to hijack. If the backend authentication server does not protect against authenticator masquerade, or provide the proper binding of the AAA- Key to the session within the AAA-Token, then one or more AAA-Keys may be sent to an unauthorized party, and an attacker may be able to gain access to the network. If the AAA-Token is provided to an untrusted AAA intermediary, then that intermediary may be able to modify the AAA-Key, or the attributes associated with it, as described in [RFC2607]. If the Secure Association Protocol does not provide mutual proof of possession of the AAA-Key material, then the peer will not have assurance that it is connected to the correct authenticator, only that the authenticator and backend authentication server share a trust relationship (since AAA protocols support mutual authentication). This distinction can become important when multiple authenticators receive AAA-Keys from the backend authentication server, such as where fast handoff is supported. If the TSK derivation does not provide for protected ciphersuite and capabilities negotiation, then downgrade attacks are possible. 4.4. Man-in-the-middle Attacks As described in [I-D.puthenkulam-eap-binding], EAP method sequences and compound authentication mechanisms may be subject to man-in-the- middle attacks. When such attacks are successfully carried out, the attacker acts as an intermediary between a victim and a legitimate authenticator. This allows the attacker to authenticate successfully to the authenticator, as well as to obtain access to the network. In order to prevent these attacks, [I-D.puthenkulam-eap-binding] recommends derivation of a compound key by which the EAP peer and server can prove that they have participated in the entire EAP exchange. Since the compound key must not be known to an attacker posing as an authenticator, and yet must be derived from quantities that are exported by EAP methods, it may be desirable to derive the compound key from a portion of the EMSK. In order to provide proper key hygiene, it is recommended that the compound key used for man-in- the-middle protection be cryptographically separate from other keys derived from the EMSK, such as fast handoff keys, discussed in Section 2.5. 4.5. Denial of Service Attacks The caching of security associations may result in vulnerability to denial of service attacks. Since an EAP peer may derive multiple EAP SAs with a given EAP server, and creation of a new EAP SA does not Aboba, et al. Informational [Page 27] INTERNET-DRAFT EAP Key Management Framework 15 November 2004 implicitly delete a previous EAP SA, EAP methods that result in creation of persistent state may be vulnerable to denial of service attacks by a rogue EAP peer. As a result, EAP methods creating persistent state may wish to limit the number of cached EAP SAs (Phase 1a) corresponding to an EAP peer. For example, an EAP server may choose to only retain a few EAP SAs for each peer. This prevents a rogue peer from denying access to other peers. Similarly, an authenticator may have multiple AAA-Key SAs corresponding to a given EAP peer; to conserve resources an authenticator may choose to limit the number of cached AAA-Key (Phase 1 b) SAs for each peer. Depending on the media, creation of a new unicast Secure Association SA may or may not imply deletion of a previous unicast secure association SA. Where there is no implied deletion, the authenticator may choose to limit Phase 2 (unicast and multicast) Secure Association SAs for each peer. 4.6. Impersonation Both the RADIUS and Diameter protocols are potentially vulnerable to impersonation by a rogue authenticator. While AAA protocols such as RADIUS [RFC2865] or Diameter [RFC3588] support mutual authentication between the authenticator (known as the AAA client) and the backend authentication server (known as the AAA server), the security mechanisms vary according to the AAA protocol. In RADIUS, the shared secret used for authentication is determined by the source address of the RADIUS packet. As noted in [RFC3579] Section 4.3.7, it is highly desirable that the source address be checked against one or more NAS identification attributes so as to detect and prevent impersonation attacks. When RADIUS requests are forwarded by a proxy, the NAS-IP-Address or NAS-IPv6-Address attributes may not correspond to the source address. Since the NAS-Identifier attribute need not contain an FQDN, it also may not correspond to the source address, even indirectly. [RFC2865] Section 3 states: A RADIUS server MUST use the source IP address of the RADIUS UDP packet to decide which shared secret to use, so that RADIUS requests can be proxied. This implies that it is possible for a rogue authenticator to forge Aboba, et al. Informational [Page 28] INTERNET-DRAFT EAP Key Management Framework 15 November 2004 NAS-IP-Address, NAS-IPv6-Address or NAS-Identifier attributes within a RADIUS Access-Request in order to impersonate another authenticator. Among other things, this can result in messages (and MSKs) being sent to the wrong authenticator. Since the rogue authenticator is authenticated by the RADIUS proxy or server purely based on the source address, other mechanisms are required to detect the forgery. In addition, it is possible for attributes such as the Called-Station-Id and Calling-Station-Id to be forged as well. As recommended in [RFC3579], this vulnerability can be mitigated by having RADIUS proxies check authenticator identification attributes against the source address. To allow verification of session parameters such as the Called- Station- Id and Calling-Station-Id, these can be sent by the EAP peer to the server, protected by the TEKs. The RADIUS server can then check the parameters sent by the EAP peer against those claimed by the authenticator. If a discrepancy is found, an error can be logged. While [RFC3588] requires use of the Route-Record AVP, this utilizes FQDNs, so that impersonation detection requires DNS A/AAAA and PTR RRs to be properly configured. As a result, it appears that Diameter is as vulnerable to this attack as RADIUS, if not more so. To address this vulnerability, it is necessary to allow the backend authentication server to communicate with the authenticator directly, such as via the redirect functionality supported in [RFC3588]. 4.7. Channel binding It is possible for a compromised or poorly implemented EAP authenticator to communicate incorrect information to the EAP peer and/or server. This may enable an authenticator to impersonate another authenticator or communicate incorrect information via out- of-band mechanisms (such as via AAA or the lower layer protocol). Where EAP is used in pass-through mode, the EAP peer typically does not verify the identity of the pass-through authenticator, it only verifies that the pass-through authenticator is trusted by the EAP server. This creates a potential security vulnerability, described in [RFC3748] Section 7.15. [RFC3579] Section 4.3.7 describes how an EAP pass-through authenticator acting as a AAA client can be detected if it attempts to impersonate another authenticator (such by sending incorrect NAS- Identifier [RFC2865], NAS-IP-Address [RFC2865] or NAS-IPv6-Address [RFC3162] attributes via the AAA protocol). However, it is possible for a pass-through authenticator acting as a AAA client to provide Aboba, et al. Informational [Page 29] INTERNET-DRAFT EAP Key Management Framework 15 November 2004 correct information to the AAA server while communicating misleading information to the EAP peer via a lower layer protocol. For example, it is possible for a compromised authenticator to utilize another authenticator's Called-Station-Id or NAS-Identifier in communicating with the EAP peer via a lower layer protocol, or for a pass-through authenticator acting as a AAA client to provide an incorrect peer Calling-Station-Id [RFC2865][RFC3580] to the AAA server via the AAA protocol. As noted in [RFC3748] Section 7.15, this vulnerability can be addressed by use of EAP methods that support a protected exchange of channel properties such as endpoint identifiers, including (but not limited to): Called-Station-Id [RFC2865][RFC3580], Calling-Station-Id [RFC2865][RFC3580], NAS-Identifier [RFC2865], NAS-IP-Address [RFC2865], and NAS-IPv6-Address [RFC3162]. Using such a protected exchange, it is possible to match the channel properties provided by the authenticator via out-of-band mechanisms against those exchanged within the EAP method. For example, see [ServiceIdent]. 4.8. Key Strength In order to guard against brute force attacks, EAP methods deriving keys need to be capable of generating keys with an appropriate effective symmetric key strength. In order to ensure that key generation is not the weakest link, it is necessary for EAP methods utilizing public key cryptography to choose a public key that has a cryptographic strength meeting the symmetric key strength requirement. As noted in [RFC3766] Section 5, this results in the following required RSA or DH module and DSA subgroup size in bits, for a given level of attack resistance in bits: Attack Resistance RSA or DH Modulus DSA subgroup (bits) size (bits) size (bits) ----------------- ----------------- ------------ 70 947 128 80 1228 145 90 1553 153 100 1926 184 150 4575 279 200 8719 373 250 14596 475 Aboba, et al. Informational [Page 30] INTERNET-DRAFT EAP Key Management Framework 15 November 2004 4.9. Key Wrap As described in [RFC3579] Section 4.3, known problems exist in the key wrap specified in [RFC2548]. Where the same RADIUS shared secret is used by a PAP authenticator and an EAP authenticator, there is a vulnerability to known plaintext attack. Since RADIUS uses the shared secret for multiple purposes, including per-packet authentication, attribute hiding, considerable information is exposed about the shared secret with each packet. This exposes the shared secret to dictionary attacks. MD5 is used both to compute the RADIUS Response Authenticator and the Message-Authenticator attribute, and some concerns exist relating to the security of this hash [MD5Attack]. As discussed in [RFC3579] Section 4.3, the security vulnerabilities of RADIUS are extensive, and therefore development of an alternative key wrap technique based on the RADIUS shared secret would not substantially improve security. As a result, [RFC3759] Section 4.2 recommends running RADIUS over IPsec. The same approach is taken in Diameter EAP [I-D.ietf-aaa-eap], which defines cleartext key attributes, to be protected by IPsec or TLS. Where an untrusted AAA intermediary is present (such as a RADIUS proxy or a Diameter agent), and data object security is not used, the AAA-Key may be recovered by an attacker in control of the untrusted intermediary. Possession of the AAA-Key enables decryption of data traffic sent between the peer and a specific authenticator; however where key separation is implemented, compromise of the AAA-Key does not enable an attacker to impersonate the peer to another authenticator, since that requires possession of the EMSK, which is not transported by the AAA protocol. This vulnerability may be mitigated by implementation of redirect functionality, as provided in [RFC3588]. 5. IANA Considerations This document does not create any new new spaces, nor does it require assignment of protocol parameters. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Aboba, et al. Informational [Page 31] INTERNET-DRAFT EAP Key Management Framework 15 November 2004 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. Lefkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. 6.2. Informative References [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [RFC1968] Meyer, G. and K. Fox, "The PPP Encryption Control Protocol (ECP)", RFC 1968, June 1996. [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [RFC2246] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [RFC2419] Sklower, K. and G. Meyer, "The PPP DES Encryption Protocol, Version 2 (DESE-bis)", RFC 2419, September 1998. [RFC2420] Kummert, H., "The PPP Triple-DES Encryption Protocol (3DESE)", RFC 2420, September 1998. [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D. and R. Wheeler, "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, February 1999. [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2548, March 1999. [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999. Aboba, et al. Informational [Page 32] INTERNET-DRAFT EAP Key Management Framework 15 November 2004 [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol", RFC 2716, October 1999. [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3078] Pall, G. and G. Zorn, "Microsoft Point-To-Point Encryption (MPPE) Protocol", RFC 3078, March 2001. [RFC3079] Zorn, G., "Deriving Keys for use with Microsoft Point-to-Point Encryption (MPPE)", RFC 3079, March 2001. [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese, "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines", RFC 3580, September 2003. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", RFC 3766, April 2004. [FIPSDES] National Institute of Standards and Technology, "Data Encryption Standard", FIPS PUB 46, January 1977. [DESMODES] National Institute of Standards and Technology, "DES Modes of Operation", FIPS PUB 81, December 1980, . [IEEE802] Institute of Electrical and Electronics Engineers, "IEEE Standards for Local and Metropolitan Area Networks: Overview and Architecture", ANSI/IEEE Standard 802, 1990. [IEEE80211] Institute of Electrical and Electronics Engineers, "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific Requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE IEEE Standard 802.11-1999, 1999. Aboba, et al. Informational [Page 33] INTERNET-DRAFT EAP Key Management Framework 15 November 2004 [IEEE8021X] Institute of Electrical and Electronics Engineers, "Local and Metropolitan Area Networks: Port-Based Network Access Control", IEEE Standard 802.1X-2004, September 2004. [IEEE8021Q] Institute of Electrical and Electronics Engineers, "IEEE Standards for Local and Metropolitan Area Networks: Draft Standard for Virtual Bridged Local Area Networks", IEEE Standard 802.1Q/D8, January 1998. [IEEE80211F] Institute of Electrical and Electronics Engineers, "Recommended Practice for Multi-Vendor Access Point Interoperability via an Inter-Access Point Protocol Across Distribution Systems Supporting IEEE 802.11 Operation", IEEE 802.11F, July 2003. [IEEE80211i] Institute of Electrical and Electronics Engineers, "Draft Supplement to STANDARD FOR Telecommunications and Information Exchange between Systems - LAN/MAN Specific Requirements - Part 11: Wireless Medium Access Control (MAC) and physical layer (PHY) specifications: Specification for Enhanced Security", IEEE Draft 802.11I/ D8, February 2004. [IEEE-02-758] Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, "Proactive Caching Strategies for IAPP Latency Improvement during 802.11 Handoff", IEEE 802.11 Working Group, IEEE-02-758r1-F Draft 802.11I/D5.0, November 2002. [IEEE-03-084] Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, "Proactive Key Distribution to support fast and secure roaming", IEEE 802.11 Working Group, IEEE-03-084r1-I, http://www.ieee802.org/11/Documents/DocumentHolder/ 3-084.zip, January 2003. [IEEE-03-155] Aboba, B., "Fast Handoff Issues", IEEE 802.11 Working Group, IEEE-03-155r0-I, http://www.ieee802.org/11/ Documents/DocumentHolder/3-155.zip, March 2003. [I-D.ietf-roamops-cert] Aboba, B., "Certificate-Based Roaming", draft-ietf-roamops- cert-02 (work in progress), April 1999. Aboba, et al. Informational [Page 34] INTERNET-DRAFT EAP Key Management Framework 15 November 2004 [I-D.ietf-aaa-eap] Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", draft-ietf-aaa- eap-08 (work in progress), June 2004. [I-D.irtf-aaaarch-handoff] Arbaugh, W. and B. Aboba, "Handoff Extension to RADIUS", draft-irtf-aaaarch-handoff-04 (work in progress), October 2003. [I-D.puthenkulam-eap-binding] Puthenkulam, J., "The Compound Authentication Binding Problem", draft-puthenkulam-eap-binding-04 (work in progress), October 2003. [I-D.aboba-802-context] Aboba, B. and T. Moore, "A Model for Context Transfer in IEEE 802", draft-aboba-802-context-03 (work in progress), October 2003. [I-D.arkko-pppext-eap-aka] Arkko, J. and H. Haverinen, "EAP AKA Authentication", draft- arkko-pppext-eap-aka-11 (work in progress), October 2003. [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", draft- ietf-ipsec-ikev2-14 (work in progress), June 2004. [8021XHandoff] Pack, S. and Y. Choi, "Pre-Authenticated Fast Handoff in a Public Wireless LAN Based on IEEE 802.1X Model", School of Computer Science and Engineering, Seoul National University, Seoul, Korea, 2002. [MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent Attack", CryptoBytes, Vol.2 No.2, 1996. [WLANREQ] Stanley, D., Walker, J. and B. Aboba, "EAP Method Requirements for Wireless LANs", draft-walker-ieee802-req-02.txt (work in progress), July 2004. [Housley56] Housley, R., "Key Management in AAA", Presentation to the AAA WG at IETF 56, http://www.ietf.org/proceedings/03mar/slides/aaa-5/index.html, March 2003. Aboba, et al. Informational [Page 35] INTERNET-DRAFT EAP Key Management Framework 15 November 2004 Acknowledgments Thanks to Arun Ayyagari, Ashwin Palekar, and Tim Moore of Microsoft, Dorothy Stanley of Agere, Bob Moskowitz of TruSecure, and Russ Housley of Vigil Security for useful feedback. Author Addresses Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 EMail: bernarda@microsoft.com Phone: +1 425 706 6605 Fax: +1 425 936 7329 Dan Simon Microsoft Research Microsoft Corporation One Microsoft Way Redmond, WA 98052 EMail: dansimon@microsoft.com Phone: +1 425 706 6711 Fax: +1 425 936 7329 Jari Arkko Ericsson Jorvas 02420 Finland Phone: EMail: jari.arkko@ericsson.com Pasi Eronen Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group Finland EMail: pasi.eronen@nokia.com Henrik Levkowetz (editor) ipUnplugged AB Arenavagen 27 Stockholm S-121 28 SWEDEN Aboba, et al. Informational [Page 36] INTERNET-DRAFT EAP Key Management Framework 15 November 2004 Phone: +46 708 32 16 08 EMail: henrik@levkowetz.com Aboba, et al. Informational [Page 37] INTERNET-DRAFT EAP Key Management Framework 15 November 2004 Appendix A - Security Association Examples EAP Method SA Example: EAP-TLS In EAP-TLS [RFC2716], after the EAP authentication the client (peer) and server can store the following information: o Implicitly, the EAP method this SA refers to (EAP-TLS) o Session identifier (a value selected by the server) o Certificate of the other party (server stores the client's certificate and vice versa) o Ciphersuite and compression method o TLS Master secret (known as the EAP-TLS Master Key) o SA lifetime (ensuring that the SA is not stored forever) o If the client has multiple different credentials (certificates and corresponding private keys), a pointer to those credentials When the server initiates EAP-TLS, the client can look up the EAP-TLS SA based on the credentials it was going to use (certificate and private key), and the expected credentials (certificate or name) of the server. If an EAP-TLS SA exists, and it is not too old, the client informs the server about the existence of this SA by including its Session-Id in the TLS ClientHello message. The server then looks up the correct SA based on the Session-Id (or detects that it doesn't yet have one). EAP Method SA Example: EAP-AKA In EAP-AKA [I-D.arkko-pppext-eap-aka], after EAP authentication the client and server can store the following information: o Implicitly, the EAP method this SA refers to (EAP-AKA) o A re-authentication pseudonym o The client's permanent identity (IMSI) o Replay protection counter o Authentication key (K_aut) o Encryption key (K_encr) o Original Master Key (MK) o SA lifetime (ensuring that the SA is not stored forever) When the server initiates EAP-AKA, the client can look up the EAP-AKA SA based on the credentials it was going to use (permanent identity). If an EAP-AKA SA exists, and it is not too old, the client informs the server about the existence of this SA by sending its re- authentication pseudonym as its identity in EAP Identity Response message, instead of its permanent identity. The server then looks up the correct SA based on this identity. Aboba, et al. Informational [Page 38] INTERNET-DRAFT EAP Key Management Framework 15 November 2004 AAA SA Example: RADIUS In RADIUS, where shared secret authentication is used, the client and server store each other's IP address and the shared secret, which is used to calculate the Response Authenticator [RFC2865] and Message- Authenticator [RFC3579] values, and to encrypt some attributes (such as the AAA-Key, see [RFC3580] Section 3.16). Where IPsec is used to protect RADIUS [RFC3579] and IKE is used for key management, the parties store information necessary to authenticate and authorize the other party (e.g. certificates, trust anchors and names). The IKE exchange results in IKE Phase 1 and Phase 2 SAs containing information used to protect the conversation (session keys, selected ciphersuite, etc.) AAA SA Example: Diameter with TLS When using Diameter protected by TLS, the parties store information necessary to authenticate and authorize the other party (e.g. certificates, trust anchors and names). The TLS handshake results in a short-term TLS SA that contains information used to protect the actual communications (session keys, selected TLS ciphersuite, etc.). Service SA Example: 802.11i [IEEE802.11i] Section 8.4.1.1 defines the security associations used within IEEE 802.11. A summary follows; the standard should be consulted for details. o Pairwise Master Key Security Association (PMKSA) The PMKSA is a bi-directional SA, used by both parties for sending and receiving. The PMKSA is the Root Service SA. It is created on the peer when EAP authentication completes successfully or a pre-shared key is configured. The PMKSA is created on the authenticator when the PMK is received or created on the authenticator or a pre-shared key is configured. The PMKSA is used to create the PTKSA. PMKSAs are cached for their lifetimes. The PMKSA consists of the following elements: - PMKID (security association identifier) - Authenticator MAC address - PMK - Lifetime - Authenticated Key Management Protocol (AKMP) - Authorization parameters specified by the AAA server or by local configuration. This can include parameters such as the peer's authorized SSID. Aboba, et al. Informational [Page 39] INTERNET-DRAFT EAP Key Management Framework 15 November 2004 On the peer, this information can be locally configured. - Key replay counters (for EAPOL-Key messages) - Reference to PTKSA (if any), needed to: o delete it (e.g. AAA server-initiated disconnect) o replace it when a new four-way handshake is done - Reference to accounting context, the details of which depend on the accounting protocol used, the implementation and administrative details. In RADIUS, this could include (e.g. packet and octet counters, and Acct-Multi-Session-Id). o Pairwise Transient Key Security Association (PTKSA) The PTKSA is a bi-directional SA created as the result of a successful four-way handshake. The PTKSA is a unicast service SA. There may only be one PTKSA between a pair of peer and authenticator MAC addresses. PTKSAs are cached for the lifetime of the PMKSA. Since the PTKSA is tied to the PMKSA, it only has the additional information from the 4-way handshake. The PTKSA consists of the following: - Key (PTK) - Selected ciphersuite - MAC addresses of the parties - Replay counters, and ciphersuite specific state - Reference to PMKSA: This is needed when: o A new four-way handshake is needed (lifetime, TKIP countermeasures), and we need to know which PMKSA to use o Group Transient Key Security Association (GTKSA) The GTKSA is a uni-directional SA created based on the four-way handshake or the group key handshake. The GTKSA is a multicast service SA. A GTKSA consists of the following: - Direction vector (whether the GTK is used for transmit or receive) - Group cipher suite selector - Key (GTK) - Authenticator MAC address - Via reference to PMKSA, or copied here: o Authorization parameters o Reference to accounting context Service SA Example: IKEv2/IPsec Note that this example is intended to be informative, and it does not necessarily include all information stored. Aboba, et al. Informational [Page 40] INTERNET-DRAFT EAP Key Management Framework 15 November 2004 o IKEv2 SA - Protocol version - Identities of the parties - IKEv2 SPIs - Selected ciphersuite - Replay protection counters (Message ID) - Keys for protecting IKEv2 messages (SK_ai/SK_ar/SK_ei/SK_er) - Key for deriving keys for IPsec SAs (SK_d) - Lifetime information - On the authenticator, service authorization information received from the backend authentication server. When processing an incoming message, the correct SA is looked up based on the SPIs. o IPsec SAs/SPD - Traffic selectors - Replay protection counters - Selected ciphersuite - IPsec SPI - Keys - Lifetime information - Protocol mode (tunnel or transport) The correct SA is looked up based on SPI (for inbound packets), or SPD traffic selectors (for outbound traffic). A separate IPsec SA exists for each direction. Aboba, et al. Informational [Page 41] INTERNET-DRAFT EAP Key Management Framework 15 November 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Open Issues Open issues relating to this specification are tracked on the following web site: http://www.drizzle.com/~aboba/EAP/eapissues.html Aboba, et al. Informational [Page 42]