RFC 3748
Extensible Authentication Protocol (EAP)
Pages: 67
Proposed Standard
→ Errata
Obsoletes: 2284
Updated by: 5247 7057
Proposed Standard
→ Errata
Obsoletes: 2284
Updated by: 5247 7057
Part 1 of 3 – Pages 1 to 15
Network Working Group B. Aboba Request for Comments: 3748 Microsoft Obsoletes: 2284 L. Blunk Category: Standards Track Merit Network, Inc J. Vollbrecht Vollbrecht Consulting LLC J. Carlson Sun H. Levkowetz, Ed. ipUnplugged June 2004 Extensible Authentication Protocol (EAP) Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2004).Abstract
This document defines the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication methods. EAP typically runs directly over data link layers such as Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP. EAP provides its own support for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees. Fragmentation is not supported within EAP itself; however, individual EAP methods may support this. This document obsoletes RFC 2284. A summary of the changes between this document and RFC 2284 is available in Appendix A.
Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Specification of Requirements . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Applicability . . . . . . . . . . . . . . . . . . . . . 6 2. Extensible Authentication Protocol (EAP). . . . . . . . . . . 7 2.1. Support for Sequences . . . . . . . . . . . . . . . . . 9 2.2. EAP Multiplexing Model. . . . . . . . . . . . . . . . . 10 2.3. Pass-Through Behavior . . . . . . . . . . . . . . . . . 12 2.4. Peer-to-Peer Operation. . . . . . . . . . . . . . . . . 14 3. Lower Layer Behavior. . . . . . . . . . . . . . . . . . . . . 15 3.1. Lower Layer Requirements. . . . . . . . . . . . . . . . 15 3.2. EAP Usage Within PPP. . . . . . . . . . . . . . . . . . 18 3.2.1. PPP Configuration Option Format. . . . . . . . . 18 3.3. EAP Usage Within IEEE 802 . . . . . . . . . . . . . . . 19 3.4. Lower Layer Indications . . . . . . . . . . . . . . . . 19 4. EAP Packet Format . . . . . . . . . . . . . . . . . . . . . . 20 4.1. Request and Response. . . . . . . . . . . . . . . . . . 21 4.2. Success and Failure . . . . . . . . . . . . . . . . . . 23 4.3. Retransmission Behavior . . . . . . . . . . . . . . . . 26 5. Initial EAP Request/Response Types. . . . . . . . . . . . . . 27 5.1. Identity. . . . . . . . . . . . . . . . . . . . . . . . 28 5.2. Notification. . . . . . . . . . . . . . . . . . . . . . 29 5.3. Nak . . . . . . . . . . . . . . . . . . . . . . . . . . 31 5.3.1. Legacy Nak . . . . . . . . . . . . . . . . . . . 31 5.3.2. Expanded Nak . . . . . . . . . . . . . . . . . . 32 5.4. MD5-Challenge . . . . . . . . . . . . . . . . . . . . . 35 5.5. One-Time Password (OTP) . . . . . . . . . . . . . . . . 36 5.6. Generic Token Card (GTC). . . . . . . . . . . . . . . . 37 5.7. Expanded Types. . . . . . . . . . . . . . . . . . . . . 38 5.8. Experimental. . . . . . . . . . . . . . . . . . . . . . 40 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 6.1. Packet Codes. . . . . . . . . . . . . . . . . . . . . . 41 6.2. Method Types. . . . . . . . . . . . . . . . . . . . . . 41 7. Security Considerations . . . . . . . . . . . . . . . . . . . 42 7.1. Threat Model. . . . . . . . . . . . . . . . . . . . . . 42 7.2. Security Claims . . . . . . . . . . . . . . . . . . . . 43 7.2.1. Security Claims Terminology for EAP Methods. . . 44 7.3. Identity Protection . . . . . . . . . . . . . . . . . . 46 7.4. Man-in-the-Middle Attacks . . . . . . . . . . . . . . . 47 7.5. Packet Modification Attacks . . . . . . . . . . . . . . 48 7.6. Dictionary Attacks. . . . . . . . . . . . . . . . . . . 49 7.7. Connection to an Untrusted Network. . . . . . . . . . . 49 7.8. Negotiation Attacks . . . . . . . . . . . . . . . . . . 50 7.9. Implementation Idiosyncrasies . . . . . . . . . . . . . 50 7.10. Key Derivation. . . . . . . . . . . . . . . . . . . . . 51 7.11. Weak Ciphersuites . . . . . . . . . . . . . . . . . . . 53
7.12. Link Layer. . . . . . . . . . . . . . . . . . . . . . . 53
7.13. Separation of Authenticator and Backend Authentication
Server. . . . . . . . . . . . . . . . . . . . . . . . . 54
7.14. Cleartext Passwords . . . . . . . . . . . . . . . . . . 55
7.15. Channel Binding . . . . . . . . . . . . . . . . . . . . 55
7.16. Protected Result Indications. . . . . . . . . . . . . . 56
8. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 58
9. References. . . . . . . . . . . . . . . . . . . . . . . . . . 59
9.1. Normative References. . . . . . . . . . . . . . . . . . 59
9.2. Informative References. . . . . . . . . . . . . . . . . 60
Appendix A. Changes from RFC 2284. . . . . . . . . . . . . . . . . 64
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 66
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 67
1. Introduction
This document defines the Extensible Authentication Protocol (EAP),
an authentication framework which supports multiple authentication
methods. EAP typically runs directly over data link layers such as
Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP. EAP
provides its own support for duplicate elimination and
retransmission, but is reliant on lower layer ordering guarantees.
Fragmentation is not supported within EAP itself; however, individual
EAP methods may support this.
EAP may be used on dedicated links, as well as switched circuits, and
wired as well as wireless links. To date, EAP has been implemented
with hosts and routers that connect via switched circuits or dial-up
lines using PPP [RFC1661]. It has also been implemented with
switches and access points using IEEE 802 [IEEE-802]. EAP
encapsulation on IEEE 802 wired media is described in [IEEE-802.1X],
and encapsulation on IEEE wireless LANs in [IEEE-802.11i].
One of the advantages of the EAP architecture is its flexibility.
EAP is used to select a specific authentication mechanism, typically
after the authenticator requests more information in order to
determine the specific authentication method to be used. Rather than
requiring the authenticator to be updated to support each new
authentication method, EAP permits the use of a backend
authentication server, which may implement some or all authentication
methods, with the authenticator acting as a pass-through for some or
all methods and peers.
Within this document, authenticator requirements apply regardless of
whether the authenticator is operating as a pass-through or not.
Where the requirement is meant to apply to either the authenticator
or backend authentication server, depending on where the EAP
authentication is terminated, the term "EAP server" will be used.
1.1. Specification of Requirements
In this document, several words are used to signify the requirements of the specification. 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 [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 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 [DIAM-EAP]. In this document, the terms "AAA server" and "backend authentication server" are used interchangeably. Displayable Message This is interpreted to be a human readable string of characters. The message encoding MUST follow the UTF-8 transformation format [RFC2279].
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.
Silently Discard
This means the implementation discards the packet without further
processing. The implementation SHOULD provide the capability of
logging the event, including the contents of the silently
discarded packet, and SHOULD record the event in a statistics
counter.
Successful Authentication
In the context of this document, "successful authentication" is an
exchange of EAP messages, as a result of which the authenticator
decides to allow access by the peer, and the peer decides to use
this access. The authenticator's decision typically involves both
authentication and authorization aspects; the peer may
successfully authenticate to the authenticator, but access may be
denied by the authenticator due to policy reasons.
Message Integrity Check (MIC)
A keyed hash function used for authentication and integrity
protection of data. This is usually called a Message
Authentication Code (MAC), but IEEE 802 specifications (and this
document) use the acronym MIC to avoid confusion with Medium
Access Control.
Cryptographic Separation
Two keys (x and y) are "cryptographically separate" if an
adversary that knows all messages exchanged in the protocol cannot
compute x from y or y from x without "breaking" some cryptographic
assumption. In particular, this definition allows that the
adversary has the knowledge of all nonces sent in cleartext, as
well as all predictable counter values used in the protocol.
Breaking a cryptographic assumption would typically require
inverting a one-way function or predicting the outcome of a
cryptographic pseudo-random number generator without knowledge of
the secret state. In other words, if the keys are
cryptographically separate, there is no shortcut to compute x from
y or y from x, but the work an adversary must do to perform this
computation is equivalent to performing an exhaustive search for
the secret state value.
Master Session Key (MSK)
Keying material that is derived between the EAP peer and server
and exported by the EAP method. The MSK is at least 64 octets in
length. In existing implementations, a AAA server acting as an
EAP server transports the MSK to the authenticator.
Extended Master Session Key (EMSK)
Additional keying material derived between the EAP client and
server that is exported by the EAP method. The EMSK is at least
64 octets in length. The EMSK is not shared with the
authenticator or any other third party. The EMSK is reserved for
future uses that are not defined yet.
Result indications
A method provides result indications if after the method's last
message is sent and received:
1) The peer is aware of whether it has authenticated the server,
as well as whether the server has authenticated it.
2) The server is aware of whether it has authenticated the peer,
as well as whether the peer has authenticated it.
In the case where successful authentication is sufficient to
authorize access, then the peer and authenticator will also know if
the other party is willing to provide or accept access. This may not
always be the case. An authenticated peer may be denied access due
to lack of authorization (e.g., session limit) or other reasons.
Since the EAP exchange is run between the peer and the server, other
nodes (such as AAA proxies) may also affect the authorization
decision. This is discussed in more detail in Section 7.16.
1.3. Applicability
EAP was designed for use in network access authentication, where IP
layer connectivity may not be available. Use of EAP for other
purposes, such as bulk data transport, is NOT RECOMMENDED.
Since EAP does not require IP connectivity, it provides just enough
support for the reliable transport of authentication protocols, and
no more.
EAP is a lock-step protocol which only supports a single packet in
flight. As a result, EAP cannot efficiently transport bulk data,
unlike transport protocols such as TCP [RFC793] or SCTP [RFC2960].
While EAP provides support for retransmission, it assumes ordering guarantees provided by the lower layer, so out of order reception is not supported. Since EAP does not support fragmentation and reassembly, EAP authentication methods generating payloads larger than the minimum EAP MTU need to provide fragmentation support. While authentication methods such as EAP-TLS [RFC2716] provide support for fragmentation and reassembly, the EAP methods defined in this document do not. As a result, if the EAP packet size exceeds the EAP MTU of the link, these methods will encounter difficulties. EAP authentication is initiated by the server (authenticator), whereas many authentication protocols are initiated by the client (peer). As a result, it may be necessary for an authentication algorithm to add one or two additional messages (at most one roundtrip) in order to run over EAP. Where certificate-based authentication is supported, the number of additional roundtrips may be much larger due to fragmentation of certificate chains. In general, a fragmented EAP packet will require as many round-trips to send as there are fragments. For example, a certificate chain 14960 octets in size would require ten round-trips to send with a 1496 octet EAP MTU. Where EAP runs over a lower layer in which significant packet loss is experienced, or where the connection between the authenticator and authentication server experiences significant packet loss, EAP methods requiring many round-trips can experience difficulties. In these situations, use of EAP methods with fewer roundtrips is advisable.2. Extensible Authentication Protocol (EAP)
The EAP authentication exchange proceeds as follows: [1] The authenticator sends a Request to authenticate the peer. The Request has a Type field to indicate what is being requested. Examples of Request Types include Identity, MD5-challenge, etc. The MD5-challenge Type corresponds closely to the CHAP authentication protocol [RFC1994]. Typically, the authenticator will send an initial Identity Request; however, an initial Identity Request is not required, and MAY be bypassed. For example, the identity may not be required where it is determined by the port to which the peer has connected (leased lines,
dedicated switch or dial-up ports), or where the identity is
obtained in another fashion (via calling station identity or MAC
address, in the Name field of the MD5-Challenge Response, etc.).
[2] The peer sends a Response packet in reply to a valid Request. As
with the Request packet, the Response packet contains a Type
field, which corresponds to the Type field of the Request.
[3] The authenticator sends an additional Request packet, and the
peer replies with a Response. The sequence of Requests and
Responses continues as long as needed. EAP is a 'lock step'
protocol, so that other than the initial Request, a new Request
cannot be sent prior to receiving a valid Response. The
authenticator is responsible for retransmitting requests as
described in Section 4.1. After a suitable number of
retransmissions, the authenticator SHOULD end the EAP
conversation. The authenticator MUST NOT send a Success or
Failure packet when retransmitting or when it fails to get a
response from the peer.
[4] The conversation continues until the authenticator cannot
authenticate the peer (unacceptable Responses to one or more
Requests), in which case the authenticator implementation MUST
transmit an EAP Failure (Code 4). Alternatively, the
authentication conversation can continue until the authenticator
determines that successful authentication has occurred, in which
case the authenticator MUST transmit an EAP Success (Code 3).
Advantages:
o The EAP protocol can support multiple authentication mechanisms
without having to pre-negotiate a particular one.
o Network Access Server (NAS) devices (e.g., a switch or access
point) do not have to understand each authentication method and
MAY act as a pass-through agent for a backend authentication
server. Support for pass-through is optional. An authenticator
MAY authenticate local peers, while at the same time acting as a
pass-through for non-local peers and authentication methods it
does not implement locally.
o Separation of the authenticator from the backend authentication
server simplifies credentials management and policy decision
making.
Disadvantages:
o For use in PPP, EAP requires the addition of a new authentication
Type to PPP LCP and thus PPP implementations will need to be
modified to use it. It also strays from the previous PPP
authentication model of negotiating a specific authentication
mechanism during LCP. Similarly, switch or access point
implementations need to support [IEEE-802.1X] in order to use EAP.
o Where the authenticator is separate from the backend
authentication server, this complicates the security analysis and,
if needed, key distribution.
2.1. Support for Sequences
An EAP conversation MAY utilize a sequence of methods. A common
example of this is an Identity request followed by a single EAP
authentication method such as an MD5-Challenge. However, the peer
and authenticator MUST utilize only one authentication method (Type 4
or greater) within an EAP conversation, after which the authenticator
MUST send a Success or Failure packet.
Once a peer has sent a Response of the same Type as the initial
Request, an authenticator MUST NOT send a Request of a different Type
prior to completion of the final round of a given method (with the
exception of a Notification-Request) and MUST NOT send a Request for
an additional method of any Type after completion of the initial
authentication method; a peer receiving such Requests MUST treat them
as invalid, and silently discard them. As a result, Identity Requery
is not supported.
A peer MUST NOT send a Nak (legacy or expanded) in reply to a Request
after an initial non-Nak Response has been sent. Since spoofed EAP
Request packets may be sent by an attacker, an authenticator
receiving an unexpected Nak SHOULD discard it and log the event.
Multiple authentication methods within an EAP conversation are not
supported due to their vulnerability to man-in-the-middle attacks
(see Section 7.4) and incompatibility with existing implementations.
Where a single EAP authentication method is utilized, but other
methods are run within it (a "tunneled" method), the prohibition
against multiple authentication methods does not apply. Such
"tunneled" methods appear as a single authentication method to EAP.
Backward compatibility can be provided, since a peer not supporting a
"tunneled" method can reply to the initial EAP-Request with a Nak
(legacy or expanded). To address security vulnerabilities, "tunneled" methods MUST support protection against man-in-the-middle attacks.2.2. EAP Multiplexing Model
Conceptually, EAP implementations consist of the following components: [a] Lower layer. The lower layer is responsible for transmitting and receiving EAP frames between the peer and authenticator. EAP has been run over a variety of lower layers including PPP, wired IEEE 802 LANs [IEEE-802.1X], IEEE 802.11 wireless LANs [IEEE-802.11], UDP (L2TP [RFC2661] and IKEv2 [IKEv2]), and TCP [PIC]. Lower layer behavior is discussed in Section 3. [b] EAP layer. The EAP layer receives and transmits EAP packets via the lower layer, implements duplicate detection and retransmission, and delivers and receives EAP messages to and from the EAP peer and authenticator layers. [c] EAP peer and authenticator layers. Based on the Code field, the EAP layer demultiplexes incoming EAP packets to the EAP peer and authenticator layers. Typically, an EAP implementation on a given host will support either peer or authenticator functionality, but it is possible for a host to act as both an EAP peer and authenticator. In such an implementation both EAP peer and authenticator layers will be present. [d] EAP method layers. EAP methods implement the authentication algorithms and receive and transmit EAP messages via the EAP peer and authenticator layers. Since fragmentation support is not provided by EAP itself, this is the responsibility of EAP methods, which are discussed in Section 5. The EAP multiplexing model is illustrated in Figure 1 below. Note that there is no requirement that an implementation conform to this model, as long as the on-the-wire behavior is consistent with it.
+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | EAP method| EAP method| | EAP method| EAP method| | Type = X | Type = Y | | Type = X | Type = Y | | V | | | ^ | | +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ | ! | | ! | | EAP ! Peer layer | | EAP ! Auth. layer | | ! | | ! | +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ | ! | | ! | | EAP ! layer | | EAP ! layer | | ! | | ! | +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ | ! | | ! | | Lower ! layer | | Lower ! layer | | ! | | ! | +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ ! ! ! Peer ! Authenticator +------------>-------------+ Figure 1: EAP Multiplexing Model Within EAP, the Code field functions much like a protocol number in IP. It is assumed that the EAP layer demultiplexes incoming EAP packets according to the Code field. Received EAP packets with Code=1 (Request), 3 (Success), and 4 (Failure) are delivered by the EAP layer to the EAP peer layer, if implemented. EAP packets with Code=2 (Response) are delivered to the EAP authenticator layer, if implemented. Within EAP, the Type field functions much like a port number in UDP or TCP. It is assumed that the EAP peer and authenticator layers demultiplex incoming EAP packets according to their Type, and deliver them only to the EAP method corresponding to that Type. An EAP method implementation on a host may register to receive packets from the peer or authenticator layers, or both, depending on which role(s) it supports. Since EAP authentication methods may wish to access the Identity, implementations SHOULD make the Identity Request and Response accessible to authentication methods (Types 4 or greater), in addition to the Identity method. The Identity Type is discussed in Section 5.1.
A Notification Response is only used as confirmation that the peer received the Notification Request, not that it has processed it, or displayed the message to the user. It cannot be assumed that the contents of the Notification Request or Response are available to another method. The Notification Type is discussed in Section 5.2. Nak (Type 3) or Expanded Nak (Type 254) are utilized for the purposes of method negotiation. Peers respond to an initial EAP Request for an unacceptable Type with a Nak Response (Type 3) or Expanded Nak Response (Type 254). It cannot be assumed that the contents of the Nak Response(s) are available to another method. The Nak Type(s) are discussed in Section 5.3. EAP packets with Codes of Success or Failure do not include a Type field, and are not delivered to an EAP method. Success and Failure are discussed in Section 4.2. Given these considerations, the Success, Failure, Nak Response(s), and Notification Request/Response messages MUST NOT be used to carry data destined for delivery to other EAP methods.2.3. Pass-Through Behavior
When operating as a "pass-through authenticator", an authenticator performs checks on the Code, Identifier, and Length fields as described in Section 4.1. It forwards EAP packets received from the peer and destined to its authenticator layer to the backend authentication server; packets received from the backend authentication server destined to the peer are forwarded to it. A host receiving an EAP packet may only do one of three things with it: act on it, drop it, or forward it. The forwarding decision is typically based only on examination of the Code, Identifier, and Length fields. A pass-through authenticator implementation MUST be capable of forwarding EAP packets received from the peer with Code=2 (Response) to the backend authentication server. It also MUST be capable of receiving EAP packets from the backend authentication server and forwarding EAP packets of Code=1 (Request), Code=3 (Success), and Code=4 (Failure) to the peer. Unless the authenticator implements one or more authentication methods locally which support the authenticator role, the EAP method layer header fields (Type, Type-Data) are not examined as part of the forwarding decision. Where the authenticator supports local authentication methods, it MAY examine the Type field to determine whether to act on the packet itself or forward it. Compliant pass- through authenticator implementations MUST by default forward EAP packets of any Type.
EAP packets received with Code=1 (Request), Code=3 (Success), and Code=4 (Failure) are demultiplexed by the EAP layer and delivered to the peer layer. Therefore, unless a host implements an EAP peer layer, these packets will be silently discarded. Similarly, EAP packets received with Code=2 (Response) are demultiplexed by the EAP layer and delivered to the authenticator layer. Therefore, unless a host implements an EAP authenticator layer, these packets will be silently discarded. The behavior of a "pass-through peer" is undefined within this specification, and is unsupported by AAA protocols such as RADIUS [RFC3579] and Diameter [DIAM-EAP]. The forwarding model is illustrated in Figure 2. Peer Pass-through Authenticator Authentication Server +-+-+-+-+-+-+ +-+-+-+-+-+-+ | | | | |EAP method | |EAP method | | V | | ^ | +-+-+-!-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+ | ! | |EAP | EAP | | | ! | | ! | |Peer | Auth.| EAP Auth. | | ! | |EAP ! peer| | | +-----------+ | |EAP !Auth.| | ! | | | ! | ! | | ! | +-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+ | ! | | ! | ! | | ! | |EAP !layer| | EAP !layer| EAP !layer | |EAP !layer| | ! | | ! | ! | | ! | +-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+ | ! | | ! | ! | | ! | |Lower!layer| | Lower!layer| AAA ! /IP | | AAA ! /IP | | ! | | ! | ! | | ! | +-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+ ! ! ! ! ! ! ! ! +-------->--------+ +--------->-------+ Figure 2: Pass-through Authenticator For sessions in which the authenticator acts as a pass-through, it MUST determine the outcome of the authentication solely based on the Accept/Reject indication sent by the backend authentication server; the outcome MUST NOT be determined by the contents of an EAP packet sent along with the Accept/Reject indication, or the absence of such an encapsulated EAP packet.
2.4. Peer-to-Peer Operation
Since EAP is a peer-to-peer protocol, an independent and simultaneous authentication may take place in the reverse direction (depending on the capabilities of the lower layer). Both ends of the link may act as authenticators and peers at the same time. In this case, it is necessary for both ends to implement EAP authenticator and peer layers. In addition, the EAP method implementations on both peers must support both authenticator and peer functionality. Although EAP supports peer-to-peer operation, some EAP implementations, methods, AAA protocols, and link layers may not support this. Some EAP methods may support asymmetric authentication, with one type of credential being required for the peer and another type for the authenticator. Hosts supporting peer- to-peer operation with such a method would need to be provisioned with both types of credentials. For example, EAP-TLS [RFC2716] is a client-server protocol in which distinct certificate profiles are typically utilized for the client and server. This implies that a host supporting peer-to-peer authentication with EAP-TLS would need to implement both the EAP peer and authenticator layers, support both peer and authenticator roles in the EAP-TLS implementation, and provision certificates appropriate for each role. AAA protocols such as RADIUS/EAP [RFC3579] and Diameter EAP [DIAM- EAP] only support "pass-through authenticator" operation. As noted in [RFC3579] Section 2.6.2, a RADIUS server responds to an Access- Request encapsulating an EAP-Request, Success, or Failure packet with an Access-Reject. There is therefore no support for "pass-through peer" operation. Even where a method is used which supports mutual authentication and result indications, several considerations may dictate that two EAP authentications (one in each direction) are required. These include: [1] Support for bi-directional session key derivation in the lower layer. Lower layers such as IEEE 802.11 may only support uni- directional derivation and transport of transient session keys. For example, the group-key handshake defined in [IEEE-802.11i] is uni-directional, since in IEEE 802.11 infrastructure mode, only the Access Point (AP) sends multicast/broadcast traffic. In IEEE 802.11 ad hoc mode, where either peer may send multicast/broadcast traffic, two uni-directional group-key
exchanges are required. Due to limitations of the design, this
also implies the need for unicast key derivations and EAP method
exchanges to occur in each direction.
[2] Support for tie-breaking in the lower layer. Lower layers such
as IEEE 802.11 ad hoc do not support "tie breaking" wherein two
hosts initiating authentication with each other will only go
forward with a single authentication. This implies that even if
802.11 were to support a bi-directional group-key handshake, then
two authentications, one in each direction, might still occur.
[3] Peer policy satisfaction. EAP methods may support result
indications, enabling the peer to indicate to the EAP server
within the method that it successfully authenticated the EAP
server, as well as for the server to indicate that it has
authenticated the peer. However, a pass-through authenticator
will not be aware that the peer has accepted the credentials
offered by the EAP server, unless this information is provided to
the authenticator via the AAA protocol. The authenticator SHOULD
interpret the receipt of a key attribute within an Accept packet
as an indication that the peer has successfully authenticated the
server.
However, it is possible that the EAP peer's access policy was not
satisfied during the initial EAP exchange, even though mutual
authentication occurred. For example, the EAP authenticator may not
have demonstrated authorization to act in both peer and authenticator
roles. As a result, the peer may require an additional
authentication in the reverse direction, even if the peer provided an
indication that the EAP server had successfully authenticated to it.
(page 15 continued on part 2)