Subject: [eap] Resolution of Issue 2

From: [email-masked] (Bernard Aboba)
Date: Wed, 27 Nov 2002 13:30:25 -0800 (PST)

Issue 2: Alternative indications not well defined
Submitter: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: March 25, 2002
Reference:
Document: RFC2284bis-02
Comment type: T
Priority: S
Section: 2.1, 3.2.1, 3.3.1, 3.3.2, 3.4, 4.2
Rationale/Explanation of issue:

The EAP Implementation Survey results disclose that alternative
indications are not being implemented. In addition, alternative
indications are not described in enough detail to be interoperable. What
is an alternative indication, exactly? It would appear that alternative
indications are not available on every media, and also that they increase
the ability of an attacker to spoof packets.

Changes:

Delete sections 3.2.1, 3.3.1 and 3.3.2. Change the following text in
section 4.2 from:

"Implementation Note: Because the Success and Failure packets are
not acknowledged, they may be potentially lost. A peer SHOULD
allow for this circumstance, by taking alternate indications of
Success and Failure into account. The alternate indications are
media-specific, and are described in section 3."

To:

"Implementation Note: Because the Success and Failure packets are
not acknowledged, they may be potentially lost."

Insert Section 2.1:

"Success and failure indications

Within EAP, success and failure indications may
be protected or unprotected. EAP Success and Failure messages
are unprotected indications which may be spoofed, since they are sent in
cleartext and
contain no embedded message integrity check. However, individual
EAP methods may include support for acknowledged and protected
success and failure indications.

Where a protected success/failure indication
has been received at the EAP layer by an EAP peer,
it MUST accept and process the protected indication.
Subsequent unprotected success or failure EAP layer
indications MUST be silently discarded by the peer if they
contradict the protected indication.
For example, if the Peer is configured to require an EAP method providing
mutual authentication, then it MUST silently discard a Success packet
sent by the Authenticator, prior to the conclusion of mutual
authentication.

In the absence of a protected EAP layer indication, unprotected
EAP layer failure indications MAY be accepted and processed by the
EAP implementation. This can result in a denial of service
attack.

Unprotected EAP layer success indications are only accepted and processed
once methods have completed successfully.

Whether authentication is mandatory is determined by the
Authenticator and Peer configurations. If authentication
is not required by the Authenticator, or if the identity of the Peer is
verified by another mechanism (e.g. Calling-Station-ID or MAC address),
then the Authenticator MAY send a "canned" Success message.
However, the Peer may be configured to
require the Authenticator to authenticate itself prior to
being willing to process a Success message."

Insert Section 3.4 :

Link layer indications

The reliability and security of link layer indications is
dependent on the medium. Link layer failure indications accepted by
the link layer and provided to EAP MUST be processed. However, as
described in Section 2.1, only
EAP layer success/failure indications (not link layer
success indications) can cause
an EAP implementation to conclude that authentication has succeeded.

In PPP, link layer indications are not authenticated.
They are therefore subject to
spoofing. This includes LCP-Terminate (a link failure indication)
and NCP (a link success indication). In PPP, a "link down" indication
is considered a reliable indication of link failure.

In 802.11, control and management frames are not authenticated
and are therefore subject to spoofing. This includes Disassociate
and Deauthenticate frames (link failure indications), and
Association and Reassociation Response frames (link success
indications).

In IEEE 802 wired networks, the IEEE 802.1X EAPOL-Start and
EAPOL-Logoff frames are not authenticated,
whereas within 802.11, authentication is possible depending on when
they are sent and the ciphersuite that has been negotiated.
Therefore, depending on the circumstances, EAPOL-Start and
EAPOL-Logoff frames may or may not be subject to spoofing.
In 802.11 a "link down" signal is considered an unreliable indication
of link failure, since wireless signal strength can come and go."