Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3748

Extensible Authentication Protocol (EAP)

Pages: 67
Proposed Standard
Errata
Obsoletes:  2284
Updated by:  52477057
Part 1 of 3 – Pages 1 to 15
None   None   Next

Top   ToC   RFC3748 - Page 1
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.
Top   ToC   RFC3748 - Page 2

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
Top   ToC   RFC3748 - Page 3
        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.
Top   ToC   RFC3748 - Page 4

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].
Top   ToC   RFC3748 - Page 5
   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.
Top   ToC   RFC3748 - Page 6
   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].
Top   ToC   RFC3748 - Page 7
   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,
Top   ToC   RFC3748 - Page 8
       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.
Top   ToC   RFC3748 - Page 9
   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
Top   ToC   RFC3748 - Page 10
   (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.
Top   ToC   RFC3748 - Page 11
         +-+-+-+-+-+-+-+-+-+-+-+-+  +-+-+-+-+-+-+-+-+-+-+-+-+
         |           |           |  |           |           |
         | 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.
Top   ToC   RFC3748 - Page 12
   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.
Top   ToC   RFC3748 - Page 13
   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.
Top   ToC   RFC3748 - Page 14

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
Top   ToC   RFC3748 - Page 15
       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)

Next Section