Subject: [eap] Proposed resolution to Issue 152: Link layer indications

From: Bernard Aboba <[email-masked]>
Date: Sat, 9 Aug 2003 18:27:19 -0700 (PDT)

The text of Issue 152 is enclosed below.  The proposed resolution is:

In Section 3.4, change:

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

To:

"Section 4.2 defines the circumstances in which a peer
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.12, it MAY conclude that a
Success packet has been lost without waiting for a
timeout."

-------------------------------------------------------------------
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?

[BA] 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.

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

---

From: John Vollbrecht <[email-masked]>
Date: Mon, 11 Aug 2003 11:28:02 -0400

sounds good to me.  -- John