Subject: Re: [eap] Discussion of Issue 152: Lower layer indications/comment

From: John Vollbrecht <[email-masked]>
Date: Mon, 04 Aug 2003 12:07:18 -0400

I agree with Bernard and Pasi that this is fine.  I have one small note 
about Bernard's comment (copied from below)

> So that the peer doesn't encounter a timeout, it probably makes sense to
> have some assurance that the link is actually providing IP connectivity or
> is likely to do so.
>
EAP could support any type of connectivity - in 802.1X is supprts turning 
on the Control Port, so it really is level 2 connectivity not IP 
connectivity that is being supported.

-- John

--On Saturday, August 2, 2003 7:24 PM -0700 Bernard Aboba 
<[email-masked]> wrote:

> The text of Issue 152 is enclosed below.
>
> I think the major difference between the two
> approaches is for one-way methods such as EAP-MD5 Challenge.
>
> With one-way methods a peer is ready to accept an EAP Success
> after sending its Response. Since the peer does not
> authenticate the authenticator it is willing to access
> any network that indicates it is willing to grant access.
>
> In this case the proposed change is for a lower layer success
> indication to cause the peer to conclude that it has been granted
> access, even though it had no indication from EAP that the
> authenticator was willing to grant access.
>
> This doesn't really create any new security vulnerabilities since a
> one-way method is vulnerable to a spoofed EAP Success anyway.  On the
> other hand, one-way methods are really only appropriate for physically
> secure wired media in which the loss rate should be very low, so that I
> don't think there is that much benefit to be provided.
>
> So that the peer doesn't encounter a timeout, it probably makes sense to
> have some assurance that the link is actually providing IP connectivity or
> is likely to do so.
>
> So I think we might need to revise the definition of a
> "lower layer success indication" so that it is likely to
> be indicative of IP connectivity (e.g. PPP NCP or IP packets)
> rather than just a layer 2 frame (e.g. Reassociation Response).
>
> If we take these factors into account, I think the change is ok, although
> it is not all that beneficial.
>
> Of course, one issue with lower layer success indications
> in general is that I don't believe there are any EAP implementations
> that incorporate them.   If that remains true then if
> and when EAP goes to Draft Standard, we would need to
> remove this functionality from RFC 2284bis.
>
> As far as lower layer failure indications are concerned, I think we
> concluded that they would translate into "link down" indications in which
> case the EAP conversation would abort anyway.  Therefore there was no need
> to discuss them explicitly.
>
> --------------------------------------------------------------
> Issue 152: Lower layer indications
> Submitter name: Pasi Eronen
> Submitter email address: [email-masked]
> Date first submitted: July 6, 2003
> Reference:
> http://mail.frascone.com/pipermail/public/eap/2003-July/001413.html
> Document: EAP-04
> Comment type: T
> Priority: 1
> Section: 3.4
> Rationale/Explanation of issue:
> Section 3.4 says that
>
>    "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."
>
> This is not exactly what the current state machine does...
>
> 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."
>
> 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.
>
> Both are IMHO quite reasonable approaches, and I just
> wanted to clarify which one we really want to use?
> [Jari Arkko] 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?
> [Pasi Eronen] 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
> 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?
>
> A second issue: Earlier versions of the draft also mentioned
> lower-layer failure indications (e.g. "Lower layer failure
> indications provided to EAP by the lower layer MUST be processed
> and will cause an EAP exchange in progress to be aborted." in
> -03 version).  This seems to be missing from -04, and I think
> the old text still applies?
>
>
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap

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

---

From: Jari Arkko <[email-masked]>
Date: Tue, 12 Aug 2003 14:44:19 +0300

> it is not all that beneficial.

I agree with this conclusion.

So where does that leave us? Accept the issue, and thus clear the
disagreement between 2284bis and the state machine? Or reject based
on lack of big benefit? Hmm... in the interest of moving forward
why don't we accept it and move on?

> to discuss them explicitly.

Yes. But do we discuss even the "link down" indications
explicitly? On a quick scan I couldn't find an explicit statement
saying that one needs to abort EAP. In a number of places
the discussion touches upon this, but stops short of saying
what has to be done. Section 7.12 says for instance that in 802.11
one shouldn't abort upon a link down event without dampening.

--Jari

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 12 Aug 2003 05:49:06 -0700 (PDT)

> why don't we accept it and move on?

I've suggested text for Issue 152, which didn't include any proposed
changes.  Is this enough?  If not, can someone suggest additional
text/changes?

> one shouldn't abort upon a link down event without dampening.

I actually wouldn't necessarily say that one needs to abort EAP because
depending on the reliability of the "link down" indication this might not
be necessary.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Thu, 14 Aug 2003 14:36:26 +0300

Bernard Aboba wrote:

> I've suggested text for Issue 152...  Is this enough?

The current proposed text is OK. THanks.

--Jari