rfc3748.txt

来自「linux 下通过802.1认证的安装包」· 文本 代码 · 共 1,440 行 · 第 1/5 页

      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].






Aboba, et al.               Standards Track                     [Page 6]

RFC 3748                          EAP                          June 2004


   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,





Aboba, et al.               Standards Track                     [Page 7]

RFC 3748                          EAP                          June 2004


       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.







Aboba, et al.               Standards Track                     [Page 8]

RFC 3748                          EAP                          June 2004


   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





Aboba, et al.               Standards Track                     [Page 9]

RFC 3748                          EAP                          June 2004


   (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.













Aboba, et al.               Standards Track                    [Page 10]

RFC 3748                          EAP                          June 2004


         +-+-+-+-+-+-+-+-+-+-+-+-+  +-+-+-+-+-+-+-+-+-+-+-+-+
         |           |           |  |           |           |
         | EAP method| EAP method|  | EAP method| EAP method|
         | Type = X  | Type = Y  |  | Type = X  | Type = Y  |
         |       V   |           |  |       ^   |           |
         +-+-+-+-!-+-+-+-+-+-+-+-+  +-+-+-+-!-+-+-+-+-+-+-+-+
         |       !               |  |       !               |
         |  EAP  ! Peer layer    |  |  EAP  ! Auth. layer   |
         |       !               |  |       !               |
         +-+-+-+-!-+-+-+-+-+-+-+-+  +-+-+-+-!-+-+-+-+-+-+-+-+