Subject: [eap] Re: proposed resolution to Issue 161 -- Take Three

From: Bernard Aboba <[email-masked]>
Date: Sun, 26 Oct 2003 21:38:24 -0800 (PST)

Nick --

Thought about this a bit more.  Given that the Code field allows the EAP
layer to demultiplex packets destined to an authenticator versus peer
listener, a "pass-through authenticator" will only receive EAP
packets destined for the authenticator listener, that is, packets
with Code=2 (Response). Unless the NAS also has a peer listener,
it will silently discard packets with other Code values.  Since
RADIUS and Diameter do not support a "pass-through peer", there
is no way in practice that EAP packets of Codes other than 2 can be
forwarded to the backend authentication server.

Here is another pass at the text in an attempt to get this straight.

Bernard

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.

         +-+-+-+-+-+-+-+-+-+-+-+-+  +-+-+-+-+-+-+-+-+-+-+-+-+
         |           |           |  |           |           |
         | 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 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
   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 listener, or both.

   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 operating as a "pass-through authenticator"  an
   authenticator forwards EAP packets destined to its authenticator
   listener to the backend authentication server, and forwards
   packets received from the backend authentication server to the
   peer.

   The forwarding decision is based on examination of the
   Code, Identifier and Length fields.  Since a "pass-through
   authenticator" only forwards EAP packets destined for its
   authenticator listener, pass-through authenticator
   implementations MUST forward Response (Code=2) packets
   to the backend authentication server.  They also MUST be
   capable of receiving and forwarding to the peer Request
   (Code=1), Success (Code=3) and Failure (Code=4) packets.

   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.

   Since 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 listener,  unless a NAS implements
   an EAP peer listener, these packets will be silently
   discarded.  Since the behavior of a "pass-through peer" is
   undefined, where an EAP peer listener is implemented, the
   NAS will typically act on these packets 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 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 this case it
   is necessary to both peers to implement both EAP authenticator and
   peer listeners.  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.  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 implement both peer and
   authenticator listeners;  would need to support both the peer and
   authenticator roles in the EAP-TLS implementation;  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 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.

   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: Nick Petroni <[email-masked]>
Date: Mon, 27 Oct 2003 15:22:21 -0500 (EST)

Thanks Bernard. I think this makes more sense and I like this more. The
diagram I was trying to describe previously looks something like the
following, but I am happy with yours as it reads.

thanks,
nick

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

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 27 Oct 2003 13:00:29 -0800 (PST)

Yes, I think your diagram says it best.  Mind if I steal it? :)

---

From: Nick Petroni <[email-masked]>
Date: Mon, 27 Oct 2003 17:13:40 -0500 (EST)

sounds like a plan.

Thanks,
nick

Nick L. Petroni, Jr.
Graduate Student, Computer Science
Maryland Information Systems Security Lab
University of Maryland
http://www.cs.umd.edu/~npetroni

---

From: John Vollbrecht <[email-masked]>
Date: Mon, 27 Oct 2003 17:18:19 -0500

This looks very nice to me as well.  -- john

--On Monday, October 27, 2003 5:13 PM -0500 Nick Petroni 
<[email-masked]> wrote:

> > > Thanks Bernard. I think this makes more sense and I like this more.
> > > The diagram I was trying to describe previously looks something like
> > > the following, but I am happy with yours as it reads.
> > >
> > > thanks,
> > > nick
> > >
> > >
> > >       | EAP method |                                   |EAP method |
> > >       |     V     |                                   |     ^     |
> > >       | EAP  ! peer|   |     | +-----------+       |   |EAP  !Auth.|
> > >       |     !     |   |     | !     |     !       |   |     !     |
> > >       | EAP  !layer|   |   EAP !layer| EAP !layer  |   |EAP  !layer|
> > >       |     !     |   |       !     |     !       |   |     !     |
> > >       | Lower!layer|   |  Lower!layer| AAA ! /IP   |   | AAA ! /IP |
> > >       |     !     |   |       !     |     !       |   |     !     |
> > > > Thought about this a bit more.  Given that the Code field allows
> > > > the EAP layer to demultiplex packets destined to an authenticator
> > > > versus peer listener, a "pass-through authenticator" will only
> > > > receive EAP packets destined for the authenticator listener, that
> > > > is, packets with Code=2 (Response). Unless the NAS also has a peer
> > > > listener, it will silently discard packets with other Code values.
> > > > Since RADIUS and Diameter do not support a "pass-through peer",
> > > > there is no way in practice that EAP packets of Codes other than 2
> > > > can be forwarded to the backend authentication server.
> > > >
> > > >    [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
> > > >    [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.
> > > >
> > > >        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.
> > > >
> > > >    that there is no requirement that an implementation conform to
> > > >    this model, as long as the on-the-wire behavior is consistent
> > > >    with it.
> > > >
> > > >    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
> > > >    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 listener, or both.
> > > >
> > > >    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.
> > > >
> > > >    Since 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 listener,  unless a NAS
> > > >    implements an EAP peer listener, these packets will be silently
> > > >          | EAP method |                             |EAP method |
> > > >          |     V     |                             |     ^     |
> > > >          | EAP  ! peer|  |     +-----------+     |  |EAP  !Auth.|
> > > >          |     !     |  |     !     |     !     |  |     !     |
> > > >          | EAP  !layer|  |EAP  !layer| EAP !layer|  |EAP  !layer|
> > > >          |     !     |  |     !     |     !     |  |     !     |
> > > >          | Lower!layer|  |Lower!layer| AAA ! /IP |  | AAA ! /IP  |
> > > >          |     !     |  |     !     |     !     |  |     !     |
> > > >    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.
> > > >
> > > >    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.  In
> > > >    addition, the EAP method implementations on both peers must
> > > >    support both authenticator and peer functionality.
> > > >
> > > >    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 implement
> > > >    both peer and authenticator listeners;  would need to support
> > > >    both the peer and authenticator roles in the EAP-TLS
> > > >    implementation;  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.
> > > >
> > > >    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.
> > > >
> > > >    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.
> > > >
> > > >    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.