Subject: [eap] Issue 115: Multiplexing fixes

From: [email-masked] (Bernard Aboba)
Date: Sat, 26 Apr 2003 17:41:21 -0700 (PDT)

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

It is necessary to clarify what aspects of on the wire behavior are
determined by the EAP layer versus other layers. Also, the sharing of
Identity Request as well as Response info could be made more clear.
Finally it is somewhat confusing to talk about method implemented in the
EAP layer.

Change:

" [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."

To:

" [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 EAP methods."

Change:

"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 be 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 layer header fields (Code, Identifier, Length).
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. 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."

To:

"Within EAP, the Type field functions much like a port number in UDP
or TCP. 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.

Since EAP authentication methods may wish to access the Identity,
the Identity Request and Response can be assumed to be
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
an authentication method. The Notification Type is discussed in Section
5.2.

The Nak method is utilized for the purposes of method negotiation.
Peers respond to an initial 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 be used to carry data
destined for delivery to other EAP methods.

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).
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. 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."

---

From: [email-masked] (Jari Arkko)
Date: Sun, 27 Apr 2003 20:34:24 +0300

Looks good to me. --Jari

Bernard Aboba wrote:
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap
> 
>