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

From: [email-masked] (Bernard Aboba)
Date: Tue, 11 Feb 2003 09:23:59 -0800 (PST)

With respect to the "alternative indications" of RFC 2284, the
implementation survey we did about 18 months ago indicated that noone
implemented alternative link indications of success (thankfully). So I
also feel quite comfortable with prohibiting this in Section 3.4.

The issue here I think relates to sequences. If sequences were to be
prohibited (MUST NOT), then it seems to me that a protected success
indication would be enough to transition to the Success state. But if a
sequence is possible, then the peer could receive a Request for another
method after the first one was done.

On the other hand, I do believe that a protected failure indication is
enough to transition to the Failure state. I do not want to leave the
interpretation of failure up to "policy" -- that seems like an invitation
to interoperability problems. Assuming that the peer has been told via a
protected indication that authentication has failed, then an EAP Success
is unexpected.

The part that is trickier is handling of Failure messages. Just because a
method has succeeded doesn't mean that the conversation succeeds. So I
don't know if it makes sense for a peer to believe that a Failure message
is unexpected in that circumstance.

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

---

From: [email-masked] (Nick Petroni)
Date: Tue, 11 Feb 2003 14:46:58 -0500 (EST)

> also feel quite comfortable with prohibiting this in Section 3.4.
I agree.

> protected indication that authentication has failed, then an EAP Success
Couldn't this exact situation result from a configuration problem though?
For example, assume a particular authenticator is configured to allow
either method A or method B (each of which is on a different back-end
server), which are both very secure and trusted. Also,
assume that for some reason (maybe A is just more efficient?) they always
try A first. If the peer has something misconfigured for method A (e.g.
old or corrupted certificate), but has method B configured correctly,
failing A would result in never doing method B, even though the policy
would then be satisfied. Perhaps this is a bit contrived, but it seems
possible nevertheless.

> is unexpected in that circumstance.
I agree. Furthermore, I am having trouble right now determining if there
is ever a time Failure could be ignored.

---

From: [email-masked] (Bernard Aboba)
Date: Tue, 11 Feb 2003 10:46:58 -0800 (PST)

> would then be satisfied. Perhaps this is a bit contrived, but it seems

Yes, that could be the result. But that is why RFC 2284, Security
Considerations says:

   In practice, within or associated with each PPP server, it is not
   anticipated that a particular named user would be authenticated by
   multiple methods.  This would make the user vulnerable to attacks
   which negotiate the least secure method from among a set (such as PAP
   rather than EAP).  Instead, for each named user there should be an
   indication of exactly one method used to authenticate that user name.
   If a user needs to make use of different authentication methods under
   different circumstances, then distinct identities SHOULD be employed,
   each of which identifies exactly one authentication method.

> is ever a time Failure could be ignored.

I'm not sure there is -- unless sequences are prohibited.

---

From: [email-masked] (Nick Petroni)
Date: Tue, 11 Feb 2003 15:11:35 -0500 (EST)

>    each of which identifies exactly one authentication method.
I am reading this as a PPP recommendation, not an EAP recommendation. In
fact, it refers to EAP as one of the methods. I don't read this text as
talking about EAP Methods, just PPP auth methods. Of course, I have no
experience with PPP so this may not make sense. I am not sure I see how
one could "negotiate down" in the situation I presented. Assuming a
correct policy, I don't see the harm in allowing method negotiaton (in
fact, a Naks allows this anyway).