Subject: [eap] Issue 97: Strict interpretation

From: [email-masked] (Bernard Aboba)
Date: Mon, 14 Apr 2003 11:33:25 -0700 (PDT)

Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: April 7, 2003
Reference:
Document: EAP-01
Comment type: Technical
Priority: S
Section: 4.2.1
Rationale/Explanation of issue:

At IETF56 it was proposed to tighten the EAP state
machine so as to preclude a number of possibilities,
including changing Type in the middle of a method, and
sending an EAP Success or Failure before a method is
complete.

Change Section 4.2.1

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

To:

"4.2.1 Strict interpretation

As noted in Section 2.1,
once a peer has sent a Response of the same Type as the initial
Request, an authenticator MUST NOT send a Request of a different Type
prior to completion of the final round of a given method, with
the exception of a Notification-Request. The authenticator also
MUST NOT send a Request for an additional method of any Type
after completion of the initial authentication method. A peer
MUST NOT send a Nak (legacy or expanded) in reply to a Request,
after an initial non-Nak Response has been sent.

EAP Success or Failure packets MUST NOT be sent by an authenticator prior
to completion of the final round of a given method.
A peer EAP implementation receiving an EAP Success
packet prior to completion of the method in progress MUST
silently discard it. By default, an EAP peer MUST silently discard a
"canned" EAP Success message (an EAP Success message sent
immediately upon connection).

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 also MUST silently discard it.

An EAP method wishing to enforce tighter security
MAY indicate within their specification that they follow a
"strict interpretation" of EAP.

When requested by a method, "strict interpretation"
causes the EAP implementation to impose inbound filter
rules from the point where an initial Request is
answered with a Response of the same Type, until
the method completes. "Strict interpretation" also
implies that on completion the peer method will
indicate whether it succeeded (was able to
authenticate the authenticator) or failed (did
not succeed in authenticating the authenticator).

An EAP method making use of "strict interpretation" MUST
include a definition of completion for both the peer
and authenticator, and also MUST indicate the conditions
under which successful completion will be indicated.

The filter rules are as follows:

[a] On the peer, all EAP packets are silently discarded, except
for those with Code=1 (Request) and Type=Method-Type.
This implies that methods supporting "strict interpretation" do not
utilize Notification, but instead support their own method-specific
error messages.

[b] On the peer, once the method completes unsuccessfully,
the EAP conversation is terminated and the link is not enabled.
If the conversation completes successfully, then EAP Failure
packets are silently discarded.

[c] On the EAP server, once the initial EAP Request is responded
to with an EAP Response of the same Type, all EAP packets
are silently discarded, except those with Code=2 (Response) and
Type=EAP-Method-Type.

Implementation note: While none of the methods defined in
this document support strict interpretation, EAP-TLS
[RFC2716] implementations SHOULD support strict interpretation."