eap Mailing List: Re: [Issue 248] Comments on EAP state machine v4

[Nick Petroni (npetroni]

> This reflexion led me to the mechanism EAP-PSK currently uses to (try
> to) end properly its dialog, see
> http://perso.rd.francetelecom.fr/bersani/EAP_PSK/draft-bersani-eap-psk-03-d.html#rflag
> for a presentation of this mechanism (sorry for this rude ad on EAP-PSK
> but I think that what's in there could clarify my comment... and
> possibly get me some feedback ;-)).
>
> After rereading the state machine draft , I believe that the text of
> section 4.2 is pretty clear (congratulations ;-)). My only remaining
> unanswered question is: do we want to keep COND_SUCC?
I think the answer is we have to. Some methods simply will not know
whether or not they are complete and actually must wait for Success or
Failure or another request to be received. We cannot exclude (for
legacy purposes) methods that cannot say for certain that they are not
complete or do not know the success of the method itself. COND_SUCC is
the only way to handle methods like MD5 where you have no idea if you
authenticated correctly or not. you have to wait for success or failure.

> ... but I understand that I am probably *unfortunately* the only one to
> have this position and that it is probably too late to change this
> direction (don't worry, I am not going at this point  to try and reopen
> issues like #26
> http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%2026 or others by
> saying that the current EAP-Success/Failure packet is not only useless
> but harmful ;-))
I don't think you could change it if you wanted to... I think the charter
is pretty clear that existing methods can't be made obsolete. I could be
wrong though.

> As a fall-back solution, I would recommend inserting something like the
> following text advising that COND_SUCC may be dangerous:
>
> "In case the peer reaches the decision COND_SUCC, please note that the
> peer is vulnerable to an active attacker that may easily lead him to
> believe that the authenticator has reached any decision the attacker
> chooses. In situations where security is a concern, it is RECOMMENDED to
> avoid using the value COND_SUCC of the decision variable"
This would be a good recommendation to method writers I think, but I am
not sure a general claim about setting that variable alone is enough. We
could add some guidelines for method authors in the Implementation
Considerations section or perhaps better somewhere else? IMHO, the
middle of the SM description is not the place to get into this.