tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 3748

Proposed STD
Pages: 67
Top     in Index     Prev     Next
in Group Index     No Prev: Lowest Number in Group     Next in Group     Group: EAP

Extensible Authentication Protocol (EAP)

Part 1 of 3, p. 1 to 15
None       Next RFC Part

Obsoletes:    2284
Updated by:    5247    7057


Top       ToC       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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 RFC Part