eap Mailing List: RFC 2284bis sections 2.3 and 2.4

[CONGDON,PAUL (HP-Roseville,ex1) (paul.congdon]

The EAP working group has asked 802.1 to review (in particular) two areas of
the RFC 2284bis draft.  I've included them below and this will aid in
understanding the email just sent on EAP issue.  The EAP issues can be
reviewed at the following URL
http://www.drizzle.com/~aboba/EAP/eapissues.html.  Also, the entire draft
RFC 2284bis can be extracted from
http://www.drizzle.com/~aboba/EAP/draft-ietf-eap-rfc2284bis-07.txt.

Paul

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 to the backend authentication server EAP
   packets received from the peer with Code=2 (Response).  It also MUST
   be capable of receiving EAP packets from the backend authentication
   server and forwarding EAP packets of Code=1 (Request), Code=3
   (Success), and Code=4 (Failure) to the peer.

   Unless the authenticator implements one or more authentication
   methods locally which support the authenticator role, the EAP method
   layer header fields (Type, Type-Data) are not examined as part of the
   forwarding decision. Where the authenticator supports local
   authentication methods, it MAY examine the Type field to determine
   whether to act on the packet itself or forward it. Compliant
   pass-through authenticator implementations MUST by default forward
   EAP packets of any Type.

   EAP packets received with Code=1 (Request), Code=3 (Success), and
   Code=4 (Failure) are demultiplexed by the EAP layer and delivered to
   the peer layer. Therefore unless a host implements an EAP peer layer,
   these packets will be silently discarded.  Similarly, EAP packets
   received with Code=2 (Response) are demultiplexed by the EAP layer
   and delivered to the authenticator layer. Therefore unless a host
   implements an EAP authenticator layer, these packets will be silently
   discarded.  The behavior of a "pass-through peer" is undefined within
   this specification, and is unsupported by AAA protocols such as
   RADIUS [RFC3579]  and Diameter [DIAM-EAP].

   The forwarding model is illustrated in Figure 2.


              Peer         Pass-through Authenticator   Authentication
                                                            Server

         +-+-+-+-+-+-+                                   +-+-+-+-+-+-+
         |           |                                   |           |
         |EAP method |                                   |EAP method |
         |     V     |                                   |     ^     |
         +-+-+-!-+-+-+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +-+-+-!-+-+-+
         |     !     |   |EAP  |  EAP  |             |   |     !     |
         |     !     |   |Peer |  Auth.| EAP Auth.   |   |     !     |
         |EAP  ! peer|   |     | +-----------+       |   |EAP  !Auth.|
         |     !     |   |     | !     |     !       |   |     !     |
         +-+-+-!-+-+-+   +-+-+-+-!-+-+-+-+-+-!-+-+-+-+   +-+-+-!-+-+-+
         |     !     |   |       !     |     !       |   |     !     |
         |EAP  !layer|   |   EAP !layer| EAP !layer  |   |EAP  !layer|
         |     !     |   |       !     |     !       |   |     !     |
         +-+-+-!-+-+-+   +-+-+-+-!-+-+-+-+-+-!-+-+-+-+   +-+-+-!-+-+-+
         |     !     |   |       !     |     !       |   |     !     |
         |Lower!layer|   |  Lower!layer| AAA ! /IP   |   | AAA ! /IP |
         |     !     |   |       !     |     !       |   |     !     |
         +-+-+-!-+-+-+   +-+-+-+-!-+-+-+-+-+-!-+-+-+-+   +-+-+-!-+-+-+
               !                 !           !                 !
               !                 !           !                 !
               +-------->--------+           +--------->-------+


                  Figure 2: Pass-through Authenticator

   For sessions in which the authenticator acts as a pass-through, it
   MUST determine the outcome of the authentication solely based on the
   Accept/Reject indication sent by the backend authentication server;
   the outcome MUST NOT be determined by the contents of an EAP packet
   sent along with the Accept/Reject indication, or the absence of such
   an encapsulated EAP packet.

2.4 Peer-to-Peer Operation

   Since EAP is a peer-to-peer protocol, an independent and simultaneous
   authentication may take place in the reverse direction (depending on
   the capabilities of the lower layer).  Both peers may act as
   authenticators and authenticatees at the same time, in which case it
   is necessary for both peers 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 with a
   different certificate profile 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 two distinct certificates, one
   appropriate for each role.

   AAA protocols such as RADIUS/EAP [RFC3579] and Diameter EAP
   [DIAM-EAP] only support "passthrough 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
   "passthrough peer" operation.

   Even where a method is used which supports mutual authentication
   and protected result indications, several considerations may 
   dictate that two EAP authentications, (one in each direction) are 
   required.  These include:

   [1] Support for bi-directional session key derivation in the lower
       layer.  Lower layers such as IEEE 802.11 may only support
       uni-directional derivation and transport of transient session
       keys.  For example, the group-key handshake defined in
       [IEEE-802.11i] is uni-directional, since in IEEE 802.11
       infrastructure mode only the Access Point (AP) sends multicast/
       broadcast traffic. In IEEE 802.11 ad-hoc mode where either peer
       may send multicast/broadcast traffic, two uni-directional
       group-key exchanges are required.  Due to limitations of the
       design, this also implies two unicast key derivations and EAP
       method exchanges.

   [2] Support for tie-breaking in the lower layer.  Lower layers such
       as IEEE 802.11 adhoc 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 protected
       result indications, enabling the peer to indicate to the EAP
       server that it successfully authenticated the EAP server.
       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.  As a result, two authentications, one in each
       direction, may still be needed.

       It is also possible that the EAP peer's access policy was not
       satisfied during the EAP method exchange.  For example, the
       authenticator may not have successfully authenticated to the
       peer, or may not have demonstrated authorization to act in both
       peer and server roles.  For example, in EAP-TLS [RFC2716], the
       authenticator may have authenticated using a valid TLS server
       certificate, but not using a valid TLS client certificate.  As a
       result, the peer may require an additional authentication in the
       reverse direction, even if the peer provided a protected result
       indication to the EAP server indicating that the server had
       successfully authenticated to it.