Subject: [eap] Issue 105: Multiplexing Clarification

From: [email-masked] (Bernard Aboba)
Date: Fri, 18 Apr 2003 04:47:45 -0700 (PDT)

Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: April 17th, 2003
Reference:
Document: EAP-01
Comment type: T
Priority: S
Section: 2.2
Rationale/Explanation of issue:

Section 2.2 does not describe how EAP packets are
forwarded by a pass-through authenticator. This is
an area where there are known interoperability
problems (e.g. pass-through authenticators that
cannot handle any EAP method).

Change:

"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.2001]; IEEE 802.11 wireless LANs
       [IEEE.802-11.1999]; UDP (L2TP [RFC2661] and ISAKMP [PIC]); 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 the EAP state machine, and delivers
       and receives EAP messages to and from EAP methods.

   [c] EAP method. EAP methods implement the authentication algorithms
       and receive and transmit EAP messages via the EAP layer. 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.

   Within EAP, the Type field functions much like a port number in UDP
   or TCP.  With the exception of Types handled by the EAP layer, it is
   assumed that the EAP layer multiplexes incoming EAP packets according
   to their Type, and delivers them only to the EAP method corresponding
   to that Type code, with one exception.

   Since EAP methods may wish to access the Identity, the Identity
   Response can be assumed to be stored within the EAP layer so as to be
   available to methods of Types other than 1 (Identity). The Identity
   Type is discussed in Section 5.1.

   	 +-+-+-+-+-+-+-+-+-+-+-+-+  +-+-+-+-+-+-+-+-+-+-+-+-+
   	 |           |           |  |           |           |
   	 | EAP method| EAP method|  | EAP method| EAP method|
   	 | Type = X  | Type = Y  |  | Type = X  | Type = Y  |
   	 |       !   |           |  |       ^   |           |
   	 +-+-+-+-!-+-+-+-+-+-+-+-+  +-+-+-+-!-+-+-+-+-+-+-+-+
   	 |       !               |  |       !               |
   	 |  EAP  ! Layer         |  |  EAP  !  Layer        |
   	 |       !               |  |       !               |
   	 | (Nak, ! Success,      |  | (Nak, ! Success,      |
   	 |       ! Failure,      |  |       ! Failure,      |
   	 |       ! Notification, |  |       ! Notification, |
   	 |       ! Identity)     |  |       ! Identity)     |
   	 |       !               |  |       !               |
   	 +-+-+-+-!-+-+-+-+-+-+-+-+  +-+-+-+-!-+-+-+-+-+-+-+-+
   	 |       !               |  |       !               |
   	 | Lower !  Layer        |  | Lower !  Layer        |
   	 |       !               |  |       !               |
   	 +-+-+-+-!-+-+-+-+-+-+-+-+  +-+-+-+-!-+-+-+-+-+-+-+-+
   		 !                          !
   		 +------------>-------------+

                    Figure 1: EAP Multiplexing Model

   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.

   The Nak method is utilized for the purposes of method negotiation.
   Peers MUST respond to an EAP Request for an unacceptable Type with a
   Nak Response. It cannot be assumed that the contents of the Nak
   Response is available to another method.  The Nak Type is discussed
   in Section 5.3.

   EAP packets with codes of Success or Failure do not include a Type,
   and therefore are not delivered to an EAP method. Success and Failure
   are discussed in Section 4.2.

   Given these considerations, the Success, Failure, Nak Response and
   Notification Request/Response messages MUST NOT used to carry data
   destined for delivery to EAP authentication Types (4 or greater)."

To:

"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.2001]; IEEE 802.11 wireless LANs
       [IEEE.802-11.1999]; UDP (L2TP [RFC2661] and ISAKMP [PIC]); 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 the EAP state machine, and delivers
       and receives EAP messages to and from EAP methods.

   [c] EAP method. EAP methods implement the authentication algorithms
       and receive and transmit EAP messages via the EAP layer. 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  ! Layer         |  |  EAP  !  Layer        |
         |       !               |  |       !               |
   	 +-+-+-+-!-+-+-+-+-+-+-+-+  +-+-+-+-!-+-+-+-+-+-+-+-+
   	 |       !               |  |       !               |
   	 | Lower !  Layer        |  | Lower !  Layer        |
   	 |       !               |  |       !               |
   	 +-+-+-+-!-+-+-+-+-+-+-+-+  +-+-+-+-!-+-+-+-+-+-+-+-+
                 !                          !
   		 !   Peer                   ! Authenticator
   		 +------------>-------------+

                    Figure 1: EAP Multiplexing Model

   Within EAP, the Type field functions much like a port number in UDP
   or TCP.  With the exception of Types handled by the EAP layer, it is
   assumed that the EAP layer multiplexes incoming EAP packets according
   to their Type, and delivers them only to the EAP method corresponding
   to that Type code, with one exception.

   Since EAP methods may wish to access the Identity, the Identity
   Response can be assumed to be stored within the EAP layer so as to be
   available to methods of Types other than 1 (Identity). 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.

   The Nak method is utilized for the purposes of method negotiation.
   Peers MUST respond to an EAP Request for an unacceptable Type with
   a Nak Response (legacy or expanded). It cannot be assumed that
   the contents of the Nak Response is available to another method.
   The Nak Type is discussed in Section 5.3.

   EAP packets with codes of Success or Failure do not include a Type,
   and therefore are not delivered to an EAP method. Success and Failure
   are discussed in Section 4.2.

   Given these considerations, the Success, Failure, Nak Response and
   Notification Request/Response messages MUST NOT used to carry data
   destined for delivery to other EAP methods.

   Where a pass-through authenticator is present, it forwards
   packets back and forth between the peer and a backend authentication
   server, based on the EAP header fields (Code, Identifier,
   Length). Since pass-through authenticators rely on a backend
   authenticator server to implement methods, the EAP method
   header fields (Type, Type-Data) are not examined as part of
   the forwarding decision. The forwarding model is illustrated
   in Figure 2. Compliant pass-through authenticator implementations
   MUST by default be capable of forwarding packets from any EAP method.

+-+-+-+-+-+-+                             +-+-+-+-+-+-+
|           |                             |           |
|EAP method |                             |EAP method |
|   Layer   |                             |   Layer   |
|     V     |                             |     ^     |
+-+-+-!-+-+-+  +-+-+-+-+-+-+-+-+-+-+-+-+  +-+-+-!-+-+-+
|     !     |  |           |           |  |     !     |
|EAP  !Layer|  | EAP Layer | EAP Layer |  |EAP  !Layer|
|     !     |  |     +-----+---------+ |  |     !     |
|     !     |  |     !     |         ! |  |     !     |
+-+-+-!-+-+-+  +-+-+-!-+-+-+-+-+-+-+-!-+  +-+-+-!-+-+-+
|     !     |  |     !     |         ! |  |     !     |
|Lower!Layer|  |Lower!Layer| AAA/IP  ! |  |Lower!Layer|
|     !     |  |     !     |         ! |  |     !     |
+-+-+-!-+-+-+  +-+-+-!-+-+-+-+-+-+-+-!-+  +-+-+-!-+-+-+
      !              !               !          !
      !   Peer       !  Pass-through !     Auth.!Server
      +-------->-----+               +----->----+

      Figure 2: Pass-through Authenticator"

---

From: [email-masked] (Jari Arkko)
Date: Thu, 24 Apr 2003 14:30:47 +0300

>    model, as long as the on-the-wire behavior is consistent with it.

(You used tabs on some lines and spaces on others, better
use one consistently. Could show up as a difference in
some cases.)

>    Notification Request/Response messages MUST NOT used to carry data

s/used/be used/

>    server, based on the EAP header fields (Code, Identifier,

s/EAP header/EAP layer header/ ?

>    authenticator server to implement methods, the EAP method

s/EAP method header/EAP method layer header/ ?

>    MUST by default be capable of forwarding packets from any EAP method.

How about this instead:

    Peer               Pass-through         Auth.Server

+-+-+-+-+-+-+                             +-+-+-+-+-+-+
|           |                             |           |
|EAP method |                             |EAP method |
|   Layer   |                             |   Layer   |
|     V     |                             |     ^     |
+-+-+-!-+-+-+  +-+-+-+-+-+-+-+-+-+-+-+-+  +-+-+-!-+-+-+
|     !     |  |           |           |  |     !     |
| EAP !Layer|  | EAP Layer | EAP Layer |  | EAP !Layer|
|     !     |  |     +-----+-----+     |  |     !     |
|     !     |  |     !     |     !     |  |     !     |
+-+-+-!-+-+-+  +-+-+-!-+-+-+-+-+-+-+-+-+  +-+-+-!-+-+-+
|     !     |  |     !     |     !     |  |     !     |
|Lower!Layer|  |Lower!Layer| AAA ! /IP |  | AAA ! /IP |
|     !     |  |     !     |     !     |  |     !     |
+-+-+-!-+-+-+  +-+-+-!-+-+-+-+-+-!-+-+-+  +-+-+-!-+-+-+
       !              !           !              !
       !              !           !              |
       +-------->-----+           +------->------+

--Jari

---

From: [email-masked] (Yoshihiro Ohba)
Date: Wed, 23 Apr 2003 07:39:20 -0700

>    Peer               Pass-through         Auth.Server

I think these passthrough model figures are misleading because those
gives an impression that the NAS acts as an EAP peer for the backend
EAP server while it acts as an EAP authenticator for the real EAP
peer.  But actually the NAS does not need to have an EAP peer
functionality at all.

Instead of this model, the latest state machine draft introduces a
different model based on using a special "passthough method" for NAS.
The model can be illustrated below.

+-+-+-+-+-+-+  +-+-+-+-+-+-+-+-+-+-+-+-+  +-+-+-+-+-+-+
|           |  |                       |  |           |
|EAP method |  | Passthrough mechanism |  |EAP method |
|   Layer   |  |     +-----------+     |  |   Layer   |
|     V     |  |     !           !     |  |     ^     |
+-+-+-!-+-+-+  +-+-+-!-+-+-+     !     |  +-+-+-!-+-+-+
|     !     |  |     !     |     !     |  |     !     |
| EAP !Layer|  | EAP !Layer|     !     |  | EAP !Layer|
|     !     |  |     !     |     !     |  |     !     |
|     !     |  |     !     |     !     |  |     !     |
+-+-+-!-+-+-+  +-+-+-!-+-+-+-+-+-+-+-+-+  +-+-+-!-+-+-+
|     !     |  |     !     |     !     |  |     !     |
|Lower!Layer|  |Lower!Layer| AAA ! /IP |  | AAA ! /IP |
|     !     |  |     !     |     !     |  |     !     |
+-+-+-!-+-+-+  +-+-+-!-+-+-+-+-+-!-+-+-+  +-+-+-!-+-+-+
      !              !           !              !
      !              !           !              |
      +-------->-----+           +------->------+

Note that I don't want to use the term "passthrough method" in
RFC2284bis, since the definition of passthrough method is specific to
the state machine draft and other implementations are possible without
being based on the state machine draft as long as on-the-wire behavior
satisfies the EAP specification.  That is why I use "passthrough
mechanism" instead of "passthrough method".

Make sense?

Yoshihiro Ohba

---

From: [email-masked] (Bernard Aboba)
Date: Thu, 24 Apr 2003 09:31:25 -0700 (PDT)

> peer.  But actually the NAS does not need to have an EAP peer

The pass-through does validate EAP layer headers (Code, Identifier,
Length), much as a peer would. For example, it looks at the Code field to
see if it is appropriate in both directions; checks or stores state from
the Identifier and checks the Length. So I'm not sure that this is
misleading -- unless there is some EAP layer peer functionality that you
believe that the pass-through does not do. Can you be more specific?

>     Peer               Pass-through         Auth.Server

This figure suggests that the pass-through authenticator acts on EAP
method headers (Type, Type-Code). This is typically not the case.
Pass-through functionality is not a method. Much like a router forwards IP
packets but doesn't terminate TCP connections, an EAP pass-through
forwards EAP packets but doesn't terminate method conversations. Since
we've had interoperability problems relating to this issue where
pass-through authenticators are unable to handle all EAP methods, we've
had to clarify this in the spec. The figure above would be likely to
confuse implementers.
> mechanism" instead of "passthrough method".

Introducing new terminology in the state machine draft probably isn't a
good idea.

---

From: [email-masked] (Yoshihiro Ohba)
Date: Wed, 23 Apr 2003 09:33:52 -0700

> believe that the pass-through does not do. Can you be more specific?

EAP layer peer does not have a functionality to forward EAP packets to
EAP layer authenticator or to AAA client in the same physical box.

If the NAS were to have the EAP layer peer functionality, it is not
allowed to pass a duplicate Request to some other entity other than
returning the copy of the original Response that was sent in response
to the original Request.  This does not allow the following bahavior
described in RFC2869bis:

"A RADIUS server determining that a non-fatal error has occurred MAY send
an Access-Challenge to the  NAS including EAP-Message attribute(s) as
well as an Error-Cause attribute [DynAuth] with value 202 (decimal),
"Invalid EAP Packet (Ignored)".  The Access-Challenge SHOULD encapsulate
within EAP-Message attribute(s) the most recently sent EAP-Request
packet (including the same Identifier value).  On receiving such an
Access-Challenge, a NAS implementing previous versions of this
specification will decapsulate the EAP-Request and send it to the peer,
which will retransmit the EAP-Response."

> had to clarify this in the spec. The figure above would be likely to

I'm not sure how it would confuse implementers.  If we discuss based
on the analogy to TCP/IP stack, the figure above is comparative with
the following figure (this example is based on email access via
SSH-based VPN) :

enterprise
email         enterprise               email
server        VPN gateway              client

+----+   +-------------------+     +---------------+
|POP3|   |  SSH port-        |     |     POP3      |
+----+   +----+ forwarding   |     +---------------+
|TCP |   |TCP | mechanism    |     |     TCP       |
+----+   +----+--------------+     +---------------+
| IP |   | IP |SSH/SSL/TCP/IP|     | SSH/SSL/TCP/IP|
+----+   +----+--------------+     +---------------+

> Introducing new terminology in the state machine draft probably isn't a

This part can be separately discussed.

Yoshihiro Ohba

---

From: [email-masked] (Bernard Aboba)
Date: Thu, 24 Apr 2003 14:07:24 -0700 (PDT)

> EAP layer authenticator or to AAA client in the same physical box.

True. On the other hand, an IP router doesn't act like a host on both
interfaces. For example, an IP router typically won't support
reassembly of IP fragments not addressed to it at the IP layer, so that it
could be argued that a similar diagram shouldn't show a router operating
on the IP layer. My advice would be to clarify the text rather than the
figure -- the figure is meant to show what EAP layers the pass-through
authenticator operates on, not to indicate each layer as a monolithic
entity that is handled exactly the same on all entities. The major point
being made is that pass-through authenticators don't forward based
on EAP method headers.

> to the original Request.  This does not allow the following bahavior

Correct. I think your comment underlines that perhaps we are not 100%
clear on what operations a pass-through authenticator performs on an EAP
packet before forwarding. For example, it might be argued that the NAS
should behave the same as the peer in this case.

> server        VPN gateway              client

Not sure this is analagous because SSH gateways terminate traffic at the
application layer whereas pass-through authenticators don't look at
EAP message layer headers. Also, don't SSH gateways use TCP on both
interfaces? So why is TCP present at different layers of the stack in
each of the entities in the diagram?

---

From: [email-masked] (Yoshihiro Ohba)
Date: Wed, 23 Apr 2003 13:39:11 -0700

> being made is that pass-through authenticators don't forward based

I think text-only is ok if it is diffucult to draw a perfect figure
that does not confuse people at all.

> should behave the same as the peer in this case.

Yes (and I believe that the state machine draft can help understand
and clarify the behavior of pass-through authenticator).

> each of the entities in the diagram?

OK, the ssh example was not a good example.  Please ignore the
example.

Yoshihiro Ohba