Subject: [eap] Proposed resolution to Issue 49: Spoofing of EAP Success/Failure

From: [email-masked] (Bernard Aboba)
Date: Sat, 18 Jan 2003 23:27:45 -0800 (PST)

For Section 4.2.1, substitute:

"4.2.1. Processing of success and failure

Within EAP, success and failure indications consist of the EAP Success
and Failure messages, as well as method-specific indications. Within
EAP, these indications may be protected or unprotected.

EAP Success and Failure packets are considered unprotected indications
which may be spoofed, since as described in Section 4.2, they contain no
message integrity check (MIC).

In order to provide additional protection against tampering, EAP methods
MAY support a MIC that covers some or all of the EAP packet, including
headers. In addition, such a MIC MAY include coverage of previous
Request and Response messages, so as to enable protection of other
packets to that do not contain MICs, such as Identity Request/Response,
Notification Request/Response and Nak Response.

EAP methods also MAY include support for method-specific acknowledged
success and failure indications. This enables the authenticator to
indicate whether the peer has successfully authenticated, as well as for
the peer to acknowledge receipt of that indication, and respond with an
indication of whether the authenticator has successfully authenticated
to the peer. If a key has previously been derived, the result exchange
MAY be protected by a Message Integrity Check (MIC), and if so, then
this success/failure indication is considered protected.

In order to decrease vulnerability to spoofing of success and failure
indications, the following processing rules are recommended:

[a] Processing of protected success and failure indications. Where a
method-specific protected success/failure indication has been
received, the implementation MUST validate the EAP method MIC, with
a MIC failure handled via silent discard, as specified in Section
4.1.

[b] Receipt of EAP Success and Failure packets prior to method
completion. A peer EAP implementation receiving an EAP Success
packet prior to completion of the method in progress MUST silently
discard it. This ensures that a rogue authenticator will not be
able to bypass mutual authentication by sending an EAP Success
prior to conclusion of the EAP method conversation. A peer EAP
implementation receiving an EAP Failure packet prior to completion
of the method in progress MAY silently discard it. When using EAP
methods that provide their own (protected) error indications,
premature EAP Failure packets are unexpected, so that this
technique may be more readily employed.

[c] Authentication requirement. An EAP peer implementation that has
been configured to require authentication MUST silently discard a
"canned" EAP Success message (an EAP Success message sent
immediately upon connection).

[d] Contradictory indications. Where protected and unprotected result
indications are both available, protected indications take
precedence. For example, where an EAP method provides a protected
indication that authentication failure has occurred in either
direction, the implementation MUST silently discard subsequent EAP
Success packets. Similarly, where an EAP method provides a
protected indication that authentication has succeeded in both
directions, the EAP implementation MAY silently discard EAP Failure
packets.

[e] Processing of EAP Success and Failure in the absence of protected
indications. Subsequent to the completion of the EAP authentication
method (Types 4 and greater), and in the absence of protected
result indications, EAP Success and Failure packets MUST be
accepted and processed by the EAP implementation."

--------------------------------------------------------------------------
Issue 49: Spoofing of EAP Success/Failure
Submitter: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: December 11, 2002
Reference:
Document: RFC2284bis-08
Comment type: T
Priority: S
Section:  2.1
Rationale/Explanation of issue:

The text in section 2.1 does not provide protection against spoofing of
EAP Failure.