Subject: [eap] Proposed resolution of Issue 37: Accept

From: [email-masked] (Bernard Aboba)
Date: Thu, 28 Nov 2002 05:01:43 -0800 (PST)

Issue 37: EAP stack representation
Submitter: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: October 5, 2002
Reference:
Document: RFC2284bis-06
Comment type: T
Priority: 1
Section: 2.1
Rationale/Explanation of issue:
RFC 2284bis needs an explanation for how EAP multiplexing works.

Add Section 2.1:

"The EAP layer provides sequencing and duplicate elimination
to EAP methods. During the period after an
EAP Peer receives an EAP-Request, but has not yet sent an
EAP-Response, the Peer EAP layer MUST silently
discard additional EAP packets upon reception, rather
than providing them to the EAP method. This occurs whether
the received packet is a duplicate (same Identifier) or
not (different Identifier). Similarly, during the period after
an EAP Authenticator receives an EAP-Response, but has not
yet sent an EAP-Request, the Authenticator
EAP layer MUST silently discard additional EAP packets
upon reception, rather than providing them to the EAP method.

This provides an opportunity for a denial of service attack:
an attacker can swamp a Peer with EAP Requests,
preventing valid EAP Requests from being processed.
Addressing this requires an EAP method to be able
to indicate to the EAP layer that it wants to handle
duplicate elimination and packet validation itself. This
is not supported.

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

The Nak method is utilized for the purposes of method negotiation,
and is implemented within the EAP layer. Peers MUST respond to an EAP
Request for an unacceptable Type with a Nak Response. Authenticators
receiving an EAP Response with a Type for which the authenticator has no
outstanding Request MUST silently discard the Response.

The Notification method may be considered to reside within the EAP layer.
While a Notification Request may be generated at the behest of an EAP
method residing on the authenticator, a Notification Response is
typically generated automatically by the peer EAP layer, so that
it can only be 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 is available to another method.

The Identity Request may also be generated at the behest of an EAP method
residing on the authenticator. However, 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).

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

Given these considerations, the Success, Failure, Nak and Notification
messages MUST NOT used to carry data destined for delivery to other EAP
methods.The architecture is illustrated in figure 1 below."