Subject: [eap] success indications and protected success/failure

From: [email-masked] (Nick Petroni)
Date: Mon, 10 Feb 2003 18:34:21 -0500 (EST)

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