| Issue 235: (Key Framework) Rewrite of Section 1 | <– Date –> <– Thread –> |
From: Bernard Aboba (aboba internaut.com)
|
|
| Date: Sat, 3 Apr 2004 18:26:02 -0500 (EST) | |
Issue 235: Rewrite of Section 1 Submitter name: Bernard Aboba Submitter email address: aboba [at] internaut.com Date first submitted: 4/3/2004 Reference: http://www.drizzle.com/~aboba/EAP/draft-ietf-eap-keying-02.txt Document: Keying-01 Comment type: T/E Priority: S Section: 1 Rationale/Explanation of issue: I've gone and rewritten Section 1 of the Key Framework document in order to improve the organization and readability. Replace Section 1 with the following: "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". Since in EAP keying material is generated by EAP methods, transported by AAA protocols, transformed into session keys by Secure Association Protocols and used by lower layer ciphersuites, it is necessary to describe each of these elements and provide a system-level security analysis. 1.1. Requirements Language In this document, several words are used to signify the requirements of the specification. These words are often capitalized. 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]. 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. 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. The situation is illustrated in Figure 1 below. 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 peer may be stationary, in which case it may establish communications with one or more authenticators while remaining in one location. Alternatively, the peer may be mobile, changing its point of attachment from one authenticator to another, or moving between points of attachment on a single authenticator. 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]. +-+-+-+-+ | | | EAP | | Peer | | | +-+-+-+-+ | | | Peer Ports / | \ / | \ Phase 0: Discovery / | \ Phase 1: Authentication / | \ Phase 2: Secure / | \ Association / | \ / | \ / | \ | | | | | | | | | 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) 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. The conversation phases and relationship between the parties is shown below in Figure 2. 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. 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). Since discovery is handled outside of EAP, there is no need to provide this functionality within EAP. 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- establish EAP security associations in order to decrease handoff or roaming latency. 1.3.3. Secure Association Phase The Secure Association phase (phase 2) always occurs after the completion of EAP authentication (phase 1a) and key transport (phase 1b), and typically supports the following features: [1] Secure capabilties negotiation. This provides for the secure negotiation of usage modes, session parameters, 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. [2] Generation of fresh transient session keys (TSKs). The Secure Association Protocol typically guarantees the freshness of session keys by exchanging nonces and then mixing the nonces with the AAA- Key in order to generate fresh unicast (phase 2a) and 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, and by guaranteeing the freshness of transient session keys, assures that they are not reused. [3] 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 deletion of keys so as to enable seamless rekey, or recovery from partial or complete loss of key state by the peer or authenticator. [4] 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 By utilizing a three phase exchange, the EAP key management framework guarantees that certain basic characteristics, known as the "EAP Invariants" hold true for all implementations of EAP. These include: 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 transproted, 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. 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 data is negotiated within the Secure Association Protocol, out-of-band of EAP. The backend authentication server is not 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 even have knowledge of the ciphersuites implemented by the peer and authenticator, or be aware of the ciphersuite negotiated between them, and therefore does not implement ciphersuite-specific code. Since ciphersuite negotiation occurs in the Secure Association protocol, not in EAP, ciphersuite-specific key generation, if implemented within an EAP method, would potentially conflict with the transient session key derivation occurring in the Secure Association protocol. As a result, EAP methods generate keying material that is ciphersuite-independent. Additional advantages of ciphersuite-independence include: 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. 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. Knowledge of capabilities In practice, an EAP method may not have knowledge of the ciphersuite that has been negotiated between the peer and authenticator, since this negotiation typically occurs within the Secure Association Protocol. For example, PPP ciphersuite negotiation occurs in the Encryption Control Protocol (ECP) [RFC1968]. Since ECP negotiation occurs after authentication, unless an EAP method is utilized that supports ciphersuite negotiation, the peer, authenticator and backend authentication server may not be able to anticipate the negotiated ciphersuite and therefore this information cannot be provided to the EAP method. Since ciphersuite negotiation is assumed to occur out-of-band, there is no need for ciphersuite negotiation within EAP.
-
Issue 235: (Key Framework) Rewrite of Section 1 Bernard Aboba, April 3 2004
-
Re: Issue 235: (Key Framework) Rewrite of Section 1 Florent Bersani, April 8 2004
-
Re: Issue 235: (Key Framework) Rewrite of Section 1 Bernard Aboba, April 8 2004
- Re: Issue 235: (Key Framework) Rewrite of Section 1 Florent Bersani, April 8 2004
- RE: Issue 235: (Key Framework) Rewrite of Section 1 Joseph Salowey, April 8 2004
-
Re: Issue 235: (Key Framework) Rewrite of Section 1 Bernard Aboba, April 8 2004
-
Re: Issue 235: (Key Framework) Rewrite of Section 1 Florent Bersani, April 8 2004
Results generated by Tiger Technologies using MHonArc.