Subject: [eap] Re: proposed resolution to Issue 161

From: Bernard Aboba <[email-masked]>
Date: Thu, 23 Oct 2003 10:25:55 -0700 (PDT)

I went through RFC 2284bis and tried to identify sections affected by the
proposed resolution to Issue 161 within the State Machine document. I
believe this affects Sections 2.2-2.4.  Here are proposed revisions of
those sections to address this issue:

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.  It is possible for a host to act as both
       EAP peer and authenticator, and in this case both EAP peer and
       authenticator listeners 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.

         +-+-+-+-+-+-+-+-+-+-+-+-+  +-+-+-+-+-+-+-+-+-+-+-+-+
         |           |           |  |           |           |
         | 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 is used much like a protocol number in
   IP.  It is assumed that the EAP layer multiplexes 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 listener, if
   present.  EAP packets with Code=2 (Response) are delivered
   to the EAP authenticator listener, if present.

   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
   multiplex incoming EAP packets according to their Type, and deliver
   them only to the EAP method corresponding to that Type code.

   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.

   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 is 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

   Where an authenticator operates as a pass-through, it forwards
   packets back and forth between the peer and a backend authentication
   server, based on the EAP layer header fields (Code, Identifier,
   Length).  This includes performing checks on the Code,
   Identifier and Length fields, as described in Section 4.1.

   Since pass-through authenticators rely on a backend authenticator
   server to implement methods, the EAP method layer header fields
   (Type, Type-Data) are not examined as part of the forwarding
   decision, except where the authenticator implements one or more
   authentication methods locally.  In this case, the pass-through
   authenticator may examine the Type field to determine whether
   to handle the packet itself or forward it.

   The forwarding model is illustrated in Figure 2. Compliant
   pass-through authenticator implementations MUST by default
   be capable of forwarding EAP packets from any EAP method.
   Pass-through authenticator implementations also MUST be capable
   of forwarding Response (Code=2) packets to the backend
   authentication server, and receiving EAP Request (Code=1),
   Success (Code=3) and Failure (Code=4) packets from the backend
   authentication server.

   Where the pass-through device implements an EAP peer listener,
   it MAY choose not to forward EAP Request (Code=1), Success
   (Code=3) or Failure (Code=4) packets to the backend authentication
   server, in order to handle these locally.  The use of the
   RADIUS protocol for encapsulation of EAP in pass-through
   operation is described in [RFC3579].

              Peer     Pass-through Authenticator  Authentication
                                                       Server

         +-+-+-+-+-+-+                             +-+-+-+-+-+-+
         |           |                             |           |
         |EAP method |                             |EAP method |
         |     V     |                             |     ^     |
         +-+-+-!-+-+-+  +-+-+-+-+-+-+-+-+-+-+-+-+  +-+-+-!-+-+-+
         |     !     |  |           |           |  |     !     |
         |EAP  ! peer|  | EAP peer  | EAP Auth. |  |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 this case it
   is necessary to both peers to implement both EAP authenticator and
   peer listeners.

   Although EAP supports peer-to-peer operation, selected EAP methods,
   AAA protocols and link layers may not support this.  For example,
   EAP-TLS [RFC2716] is a client-server protocol requiring a different
   certificate profile for the client and server.  This implies that a
   host supporting both the EAP-TLS peer and authenticator roles would
   need to be provisioned with two distinct certificates, one
   appropriate for each role.

   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.

   AAA protocols such as RADIUS/EAP [RFC3579] and Diameter EAP
   [DIAM-EAP] only support "passthrough" operation on behalf of an
   authenticator, not a peer.  As noted in [RFC3579] Section
   2.6.2, a RADIUS server responds to an Access-Request encapsulating an
   EAP-Request with an Access-Reject.

   Link 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 only the Access Point (AP) sends multicast
   traffic.  This means that in ad-hoc operation where either peer may
   send multicast traffic, two uni-directional group-key exchanges are
   required.  Due to constraints imposed by the 4-way unicast key
   handshake state machine, this also implies two 4-way handshake and
   EAP method exchanges.

   Link layers such as IEEE 802.11 adhoc also 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.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 25 Oct 2003 06:39:33 -0700 (PDT)

Here is a revision that hopefully addresses Nick's issue...

   [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.  It is possible for a host to act as both
       EAP peer and authenticator, and in this case both EAP peer and
       authenticator layers will be present.

   IP.  It is assumed that the EAP layer demultiplexes incoming EAP

   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.

   Since pass-through authenticators rely on a backend authenticator
   server to implement methods, the EAP method layer header fields
   (Type, Type-Data) are not examined as part of the forwarding
   decision, except where the authenticator implements one or more
   authentication methods locally.  In this case, the authenticator
   may examine the Type field to determine whether to act on the
   packet itself or forward it.

   The forwarding model is illustrated in Figure 2. Compliant
   pass-through authenticator implementations MUST by default
   forward EAP packets of any Type.  Pass-through authenticator
   implementations MUST support forwarding Response (Code=2)
   packets to the backend authentication server, and receiving
   EAP Request (Code=1), Success (Code=3) and Failure (Code=4) packets
   from the backend authentication server.  Implementations  MAY be
   capable of forwarding Request (Code=1), Success (Code=3) and
   Failure (Code=4) packets to the backend authentication server, and
   receiving EAP Response (Code=2) packets from the backend authentication
   server.

   Where the pass-through device implements an EAP peer listener,
   it will not forward to the backend authentication server
   EAP Request (Code=1), Success (Code=3) or Failure (Code=4)
   packets in order to act on them locally.  The use of the
   RADIUS protocol for encapsulation of EAP in pass-through
   operation is described in [RFC3579].

         +-+-+-!-+-+-+                             +-+-+-!-+-+-+
         |EAP  ! peer|                             |EAP  !Auth.|