Subject: [eap] Another shot at Issue 80

From: [email-masked] (Bernard Aboba)
Date: Sun, 16 Feb 2003 07:41:33 -0800 (PST)

Based on the recent discussion, here is another try at resolving Issue 80.

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.
EAP Success and Failure packets may be spoofed, since as described in
Section 4.2, they contain no message integrity check (MIC). They are
therefore considered unprotected.

EAP methods also MAY include support for acknowledged
success and failure indications. This enables the authenticator to
indicate whether the peer has successfully authenticated to it, 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),
(see Section 7.13) and if so, then these success/failure indications are
considered protected.

In order to decrease vulnerability to spoofing of success and failure
indications, the following implementation advice is provided:

[a] Authentication requirement. Where mutual authentication
is required, and the authenticator fails to authenticate
successfully to the peer, the peer SHOULD silently discard
an EAP Success packet.

This implies, for an example, that a peer configured to
require mutual authentication will not consider
authentication to be successful on receipt of a "canned"
EAP Success message (an EAP Success message sent
immediately upon connection).

[b] Orderly termination. Methods may define states in which
an EAP Failure message is unexpected. For example, once
a method derives a key, it may require that a protected
error message be sent prior to termination. When such
methods are run, an EAP Failure message MAY be silently discarded
in keeping with the method specification.

[c] Processing of EAP Success and Failure. With the exception
of the above cases, EAP Success and Failure packets are
accepted and processed by the EAP implementation."

---

From: [email-masked] (John Vollbrecht)
Date: Mon, 17 Feb 2003 16:25:55 -0500

This is better.  some editorial suggestions in line

--On Sunday, February 16, 2003 7:41 AM -0800 Bernard Aboba 
<[email-masked]> wrote:

> EAP Success and Failure packets may be spoofed, since
**remove** (as described in Section 4.2,)
they contain no message integrity check (MIC). They are
> success and failure indications.
**insert**( This is described in appendix XX)
**move to appendix** (This enables the authenticator to
> considered protected.)
**discuss** I am not sure we have consensus on this.  the problem is with 
sequences which may fail even if the authentication method succeeds.
> accepted and processed by the EAP implementation."
**discuss** I am again not sure we have consensus on this.  We still have 
to know when an "inappropriate" success or fail occurs, so it is easy to 
silently discard.  It does guard against some DOS attacks. I am not sure 
what criteria we use to decide if this is the right design.
>
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap

---

From: [email-masked] (Bernard Aboba)
Date: Mon, 17 Feb 2003 14:30:16 -0800 (PST)

> sequences which may fail even if the authentication method succeeds.

This case isn't about authentication methods which succeed. It's about
receiving an EAP Failure in a state where the method says that isn't
possible.

> what criteria we use to decide if this is the right design.

Other than the cases above, EAP Success and Failure messages are processed
normally. This is how they are handled in RFC 2284, no?