rfc3748.txt

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

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






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


   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.



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


   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.




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


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






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


       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.

3.  Lower Layer Behavior

3.1.  Lower Layer Requirements

   EAP makes the following assumptions about lower layers:

   [1] Unreliable transport.  In EAP, the authenticator retransmits
       Requests that have not yet received Responses so that EAP does
       not assume that lower layers are reliable.  Since EAP defines its
       own retransmission behavior, it is possible (though undesirable)
       for retransmission to occur both in the lower layer and the EAP
       layer when EAP is run over a reliable lower layer.








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


   Note that EAP Success and Failure packets are not retransmitted.
   Without a reliable lower layer, and with a non-negligible error rate,
   these packets can be lost, resulting in timeouts.  It is therefore
   desirable for implementations to improve their resilience to loss of
   EAP Success or Failure packets, as described in Section 4.2.

   [2] Lower layer error detection.  While EAP does not assume that the
       lower layer is reliable, it does rely on lower layer error
       detection (e.g., CRC, Checksum, MIC, etc.).  EAP methods may not
       include a MIC, or if they do, it may not be computed over all the
       fields in the EAP packet, such as the Code, Identifier, Length,
       or Type fields.  As a result, without lower layer error
       detection, undetected errors could creep into the EAP layer or
       EAP method layer header fields, resulting in authentication
       failures.

       For example, EAP TLS [RFC2716], which computes its MIC over the
       Type-Data field only, regards MIC validation failures as a fatal