Subject: [eap] Another stab at text for Issue 49

From: [email-masked] (Bernard Aboba)
Date: Sat, 11 Jan 2003 11:21:46 -0800 (PST)

This still isn't right, but hopefully it's a step in the right direction.

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
result indications. These indications may be protected or
unprotected.

Where a lower layer ciphersuite is in use that
provides per-packet integrity and authentication protection,
or where the lower layer is considered physically secure,
EAP may be considered secure from tampering, and
EAP Success and Failure packets may qualify as protected
indications.

Otherwise, EAP Success and Failure packets
are considered unprotected indications which may be
spoofed, since they contain no embedded message integrity check.
Note that Where EAP itself is used to provide the keys
for use with a lower layer ciphersuite, protection may
not be enabled until key derivation is complete so that
only a portion of the EAP conversation may be protected.
If the lower layer ciphersuite is not enabled when the
EAP Success or Failure packet is sent, then these indications
are considered unprotected.

In order to provide additional protection against tampering,
EAP methods MAY support a method-specific MIC that
covers the entire EAP conversation,
including messages of types Identity, Nak, and
Notification (similar to the
Finished message in [RFC2246]). In addition,
EAP methods MAY include support for method-specific
acknowledged and protected 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 protect against spoofing of success and failure indications,
EAP implementations SHOULD obey the following processing rules:

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

[b] Receipt of unprotected indications prior to completion.
A peer EAP implementation receiving an unprotected EAP Success
packet prior to completion of the method in progress MUST
silently discard it. A peer EAP implementation receiving an
unprotected EAP Failure packet prior to completion of the
method in progress MAY 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.

[c] Authentication requirement. An EAP peer implementation
that has been configured to require authentication MUST silently
discard an unprotected "canned" EAP Success message
(an unprotected 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 unprotected 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
unprotected EAP Failure packets.

[e] Processing of unprotected indications 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, unprotected success and failure indications MUST be accepted and processed
by the EAP implementation.