Subject: [eap] Issue 73: Rewrite of Section 3.4

From: [email-masked] (Bernard Aboba)
Date: Sat, 8 Feb 2003 23:54:14 -0800 (PST)

Here is a partial solution to Issue 73, requiring a rewrite of Section
3.4. Comments welcome.

---------------------------------------------------------------------
3.4.  Link layer indications

The reliability and security of link layer indications is
dependent on the medium. Since EAP is media independent,
the presence or absence of link layer security is not
taken into account in the processing of EAP messages.

Link layer failure indications provided to EAP by the link layer
MUST be processed and will cause an EAP exchange
in progress to be aborted. However, link layer success indications
MUST NOT affect EAP message processing so that an EAP implementation
MUST NOT conclude that authentication has succeeded based on those
indications. This ensures that an attacker spoofing link layer
indications can at best succeed in a denial of service attack.

Below is a discussion of some of the reliability and security
issues with link layer indications in PPP, IEEE 802 wired
networks and IEEE 802.11 wireless LANs:

[1] PPP.  In PPP, link layer indications such as LCP-Terminate
(a link failure indication) and NCP (a link success indication) are
not authenticated or integrity protected. They can therefore be
spoofed by an attacker with access to the physical medium.

[2] IEEE 802 wired networks. On wired networks, IEEE 802.1X
messages are sent to a non-forwardable multicast MAC address.
As a result, while the IEEE 802.1X EAPOL-Start and
EAPOL-Logoff frames are not authenticated or integrity protected,
only an attacker with access to the physical link can spoof these
messages.

[3] IEEE 802.11 wireless LANs. In IEEE 802.11, link layer
indications include Disassociate and Deauthenticate frames
(link failure indications), and Association
and Reassociation Response frames (link success indications).
These messages are not authenticated or integrity protected,
and although they are not forwardable, they are spoofable by
an attacker within range.

In IEEE 802.11, IEEE 802.1X data frames are sent as Class 3
unicast data frames, are therefore forwardable. This implies
that while EAPOL-Start and EAPOL-Logoff messages may be
authenticated and integrity protected, they can be spoofed
by an authenticated attacker far from the target
when "pre-authentication" is enabled.

In IEEE 802.11 a "link down" indication is an unreliable
indication of link failure, since wireless signal strength
can come and go and may be influenced by radio frequency
interference generated by an attacker. To avoid unnecessary
resets, it is advisable to damp these indications,
rather than passing them directly to the EAP. Since EAP supports
retransmission, it is robust against transient connectivity losses.

---

From: [email-masked] (Henrik Levkowetz)
Date: Sun, 9 Feb 2003 10:38:28 +0100

The text looks good to me. However, I'd like to propose that we
keep the first two and the last proposed paragraph in 3.4, while the
remaining paragraphs are moved to Security Considerations, with
a reference to them in 3.4. Specifics inline:

> Here is a partial solution to Issue 73, requiring a rewrite of Section

Yes, keep in 3.4

> indications can at best succeed in a denial of service attack.

Yes, keep in 3.4

In 3.4, replace the next para. with:

A discussion of some reliability and security
issues with link layer indications in PPP, IEEE 802 wired
networks and IEEE 802.11 wireless LANs can be found in the
Security Considerations, Section 7.xx.

In Section 7, Security considerations, add a subsection
"Link layer", with the following 5 para's:

> Below is a discussion of some reliability and security

> retransmission, it is robust against transient connectivity losses.

	Regards,
		Henrik

---

From: [email-masked] (Bernard Aboba)
Date: Sun, 9 Feb 2003 10:23:11 -0800 (PST)

Sounds fine.

---

From: [email-masked] (John Vollbrecht)
Date: Tue, 11 Feb 2003 13:20:08 -0500

The following is a discussion of the alternative indication issue, not yet 
a set of wording for the rfc.  Before going to specific wording I would 
like to be sure we are all on the same page as far as what we want to 
happen.

I would like to see the wording tied to L2 implemetation issues, and more 
EAP specific. It seems to me that EAP implementations have two ends, each 
of which is capable of determining whether to "enable" a link (or 
application).  At the end of a sequence each end may decide independently 
whether to enable the link, and if both do not enable it, then the link 
will not work.

The authenticator is the sole controller of this for most existing 
implementations, but 802.1x allows both ends to have such control.  Other 
future implementations where mutual authentication/authorization is 
required will likely also support this ability of each end to "enable" its 
end of the link.

When the peer determines it is "ok" to connect to the authenticator, it 
could enable its end of the connection.  One reason NOT to do that would be 
if the authenticator has not completed its sequence of methods.  In that 
case subsequent EAP methods might be sent out both the controlled and 
uncontrolled port (in 802.1x PAE model).  I am not sure that this is bad, 
but it does get messages beyond the authenticator and so could be dangerous.

A reason FOR permitting this would be to allow a link to be enabled in the 
face of loss of a EAP Success message.  This would seem to be advantageous 
only if we expect high packet losses.  I think that 802.11 may have higher 
loss rate than other media, and it is a primary target for EAP.    I would 
be interested in comments on that.

Both of the have some problems, so the alternative indication is 
introduced. If the peer is in a state where it would accept a "Success" (it 
is "ok" to connect to the authenticator) and it gets some link layer 
indication that the authenticator believes it has sent a Success and has 
turned on its controlled port (in 802.1x case), then the peer could take 
this as a "virtual Success" and enable the port.  This would require the 
peer,s lower layer to recognize something from the controlled port on the 
authenticator and communicate it to the EAP layer.  It is this recognition 
that is the "alternative" indication, and is probably different for 
different media layers.

My suggestion is that the peer not enable the link until it gets either a 
Success or an "alternative indication" from the authenticator.  Alternative 
indications are from the lower layer, but EAP must allow for them.  -- 
Discussion?

John

--On Saturday, February 8, 2003 11:54 PM -0800 Bernard Aboba 
<[email-masked]> wrote:

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