Subject: [eap] EAP-04 lower layer indications

From: [email-masked] ([email-masked])
Date: Mon, 7 Jul 2003 11:14:12 +0300

Jari Arkko wrote:

> [email-masked] wrote:
>=20
> > Section 3.4 says that=20
> >=20
> >    "Section 4.2 defines the circumstances in which a peer,
> >    having concluded an EAP method with successful acknowledged
> >    result indications, may conclude that a Success packet has
> >    been lost after expiration of a timeout.  In those same
> >    circumstances, if a peer receives a lower layer success
> >    indication as defined in Section 7.2, it MAY conclude that a
> >    Success packet has been lost without waiting for a
> >    timeout. This ensures that an attacker spoofing lower layer
> >    indications can at best succeed in a denial of service
> >    attack."
> >=20
> > This is not exactly what the current state machine does...
> >=20
> > The current text says that "if you are in a situation where a
> > timeout would lead to success (that is, you have received a
> > method-specific success indication), also lower-layer success
> > indication does."
> >=20
> > What the current state mechine does is "if you are in a
> > situation where receiving an EAP Success packet would lead to
> > success, also lower-layer success indication does." Or in other
> > words, the effect of receiving a lower-layer success indication
> > is identical to receiving an EAP Success: if an EAP Success
> > packet would be silently discarded, so is the lower-layer
> > success indication.
> >=20
> > Both are IMHO quite reasonable approaches, and I just
> > wanted to clarify which one we really want to use?
>=20
> Hmm... if we get a method specific success indication, shouldn't
> we enable then in all three cases below:
> (a) Success received
> (b) Lower-layer success indication
> (c) Timeout?

You're right, and that happens in both approaches.  The only=20
difference is in what to do when we don't have a method specific=20
indication.  In this case,

- both approaches enable the link if Success is received
- both approaches fail on timeout
- the current state machine enables the link if lower-layer
  success indication is received, while 2284bis-04 says that
  the lower-layer success indication must be ignored
  (presumably leading to failure in timeout later).

Which approach do you think we should use?

Best regards,
Pasi

---

From: [email-masked] (Jari Arkko)
Date: Tue, 08 Jul 2003 10:14:59 +0300

[email-masked] wrote:

> You're right, and that happens in both approaches.  The only 
> difference is in what to do when we don't have a method specific 

Ok, I see. There doesn't appear to be a security
difference, since Success can most likely be spoofed
at least as easily as lower-layer success indication.
But there has been a lot of discussion around lower
layer indications in the past, so I'm inclined to
trust 2284bis more on this. Bernard, do you remember
why 2284bis ignores lower-layer success indications?

--Jari

---

From: [email-masked] (Bernard Aboba)
Date: Tue, 8 Jul 2003 05:29:36 -0700 (PDT)

> why 2284bis ignores lower-layer success indications?

When we did the implementation survey, we found that nobody implemented
this part of the specification.

---

From: [email-masked] (Jari Arkko)
Date: Tue, 08 Jul 2003 17:00:18 +0300

> this part of the specification.

Oh. While it seems perhaps a bit funny way to look
at the implementations for guidance in what the
specification should do, this is a fact of life
when working with an already deployed protocol.
Maybe we should keep 2284bis as is, and change
the state machine regarding this point. Pasi,
what do you think?

--Jari

---

From: [email-masked] (John Vollbrecht)
Date: Tue, 08 Jul 2003 18:16:38 -0400

> this part of the specification.

Was there a reason we chose one rather than the other?  I don't remember.
John

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

---

From: [email-masked] (Bernard Aboba)
Date: Tue, 8 Jul 2003 15:18:27 -0700 (PDT)

> Was there a reason we chose one rather than the other?  I don't remember.

I don't remember either.  In fact, I don't even remember making a
decision.  I'll probably forget this email too, so please bring this
subject up at IETF 57 so we can figure it out there :)