Subject: [eap] Resolution of Issue 25: Accept

From: [email-masked] (Bernard Aboba)
Date: Mon, 16 Dec 2002 22:48:43 -0800 (PST)

The minutes of the 12/11/02 EAP Design team reflects the logic you state
below. However, this has not yet been reflected in new text for resolving
Issue 25.

Care to take a crack at it?

On Mon, 16 Dec 2002, CONGDON,PAUL (HP-Roseville,ex1) wrote:

>
> I don't fully understand the resolution to this issue.  I guess there is no
> queue between the EAP layer and the EAP method, so the EAP layer must
> discard potentially good frames because the EAP method hasn't generated the
> response yet?  Why not simply have the EAP layer deliver frames that it
> thinks are potentially good and potentially retransmissions (because the ID
> field is right) and discard everything else until a response is sent.  It
> would be the responsibility of the EAP method to catch-up or discard the
> duplicate requests.  It doesn't seem like the EAP layer should discard
> things that could be valid retransmissions by the authenticator.
>
> Paul
>
> > -----Original Message-----
> > From: Bernard Aboba [mailto:[email-masked]]
> > Sent: Wednesday, November 27, 2002 6:00 PM
> > To: [email-masked]
> > Subject: [eap] Resolution of Issue 25: Accept
> >
> >
> > Issue 25: Spoofing and duplicate detection
> > Submitter: Jesse Walker
> > Submitter email address: [email-masked]
> > Date first submitted: May 3, 2002
> > Reference:
> > Document: RFC2284bis-04
> > Comment type: T
> > Priority: S
> > Section: 2.2, 7.7
> >
> > Proposed resolution:
> >
> > Delete Section 7.7.
> >
> > Add the following text to Section 2.2:
> >
> > "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).
> >
> > 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, which
> > is not supported."
> >
> >
> > _______________________________________________
> > eap mailing list
> > [email-masked]
> > http://mail.frascone.com/mailman/listinfo/eap
> >
>

---

From: [email-masked] (CONGDON,PAUL (HP-Roseville,ex1))
Date: Mon, 16 Dec 2002 21:45:26 -0800

Paul