Subject: [eap] Re: Issue 80: Success Indications

From: [email-masked] (Bernard Aboba)
Date: Wed, 12 Feb 2003 06:25:43 -0800 (PST)

I'd like to propose a rewrite of Section 4.2.1 to address some of these
concerns:

"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,
       as discussed 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 easily 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 an authenticator provides a
       protected indication that peer authentication has failed, or
       (where a method supporting mutual authentication is supported)
       the authenticator fails to authenticate to the peer,
       the peer implementation MUST silently discard subsequent
       EAP Success 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 80: Success Indications
Submitter name: Nick Petroni
Submitter email address: [email-masked]
Date first submitted: February 10, 2003
Document: EAP-00
Comment type: Technical
Priority: S
Section: 4.2.1
Rationale/Explanation of issue:
I am requesting some comments/clarification on the topic of when the
success state can be reached by the peer.

Executive summary:
-----------------
1. Is a satisfied policy enough for a peer transition to the success
state, or is a SUCCESS packet required?

2. Is the text in 4.2.1 contradicting the current EAP model, or do I have
an incorrect understanding of the model? (these are not mutually
exclusive)

Full explanation:
----------------
Through conversation with the state machine design team, I have come to
question the conditions for success of an EAP conversation. All parties
seem to agree that a satisfied policy is necessary for the peer to begin
using the link, but the question is whether or not the condition is
sufficient. That is, if a SUCCESS message never comes, can the peer
transition to the SUCCESS state? The "alternate indications" of RFC2284
seem to imply that it can, however, section 3.4 of 2284bis explicitly
warns against accepting link-layer indications (and for good reason).
Since SUCCESS messages are neither acknowledged nor retransmitted, it is
possible that SUCCESS messages could be lost causing an unneeded timeout.
Assuming the link never goes down and the peer is satisfied, it may be
acceptable to just begin using the link. If so, when should this happen?
Presumably, it would be when a timeout has occurred and the policy is
satisfied.

This problem is closely related to so-called "protected" indications
discussed in section 4.2.1 (from resolved issue 49). Design team
conversations have concluded that such method-specific indications cannot
actually indicate the success/failure of the overall conversation, but
just the method itself. Some of the text in 4.2.1 seems to contradict this
paradigm. For example, [c] states,

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

I believe I understand the spirit of this text, but I am not sure it fits
the current model- are such indications really "contradictory", or has the
method just said things are going well and the authenticator decided
otherwise?

Note:
I believe I could make an equally long-winded argument for saying this is
all just implementation detail because I could implement EAP such that the
methods DO know the end result and still fits the wire protocol.

Thanks for reading all the way through. Comments welcome.

nick