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

[Nick Petroni (npetroni]

Florent,

I certainly appreciate your opinion, but I hope you know that it is not
me with whom you are disagreeing. I am simply explaining what I understand
the constraints of this working group to be. I share your admonishment for
using bad methods, but it has been my understanding from the beginning
that these are our constraints. Sorry if this ruins your day :(. If I am
wrong, someone else can certainly correct me freely. It has certainly
happened on more than one occasion :).

Take care,
nick

Nick L. Petroni, Jr.
Graduate Student, Computer Science
Maryland Information Systems Security Lab
University of Maryland
http://www.cs.umd.edu/~npetroni

On Fri, 16 Jul 2004, Florent Bersani wrote:

> Nick,
>
> see in-line
>
> Florent
>
> Nick Petroni wrote:
>
> >>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.
> >
> Aaaaaaaaaaaaaarghn the L word in a protocol that apparently is becoming
> pervasive for the future (invading IKEv2, IEEE 802.1X, IEEE 802.11, IEEE
> 802.16e, and why not IEEE 802.20)!
>
> I am aware of what you say but I respectfully and strongly disagree.: if
> EAP is going to be a protocol of the future why cripple it with problems
> of the past.
>
> This being said (and I expected your answer), I won't keep bothering
> with old (and given the point where we are now, slightly unconstructive)
> remarks.
>
> > 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.
> >
> >
> Again I wish that MD5-Challenge would disappear ;-)
>
> >
> >
> >>... 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.
> >
> >
> No, no I think you are right
>
> >
> >
> >>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.
> >
> I think that you have seen only the aspect: "a good EAP method SHOULD
> provide protected result indications to avoid using COND_SUCC" but you
> have overlooked the aspect "EAP peer and server SHOULD use only good EAP
> methods" ;-)
>
> I agree that the EAP state machine is probably not the best doc for his
> manifesto but since it is the State Machine that introduces COND_SUCC
> (which is not mandated by RFC 3748), then I'd recommend providing
> guidance on the usage of this "dangerous" variable.
>
> > 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.
> >
> >
> The IEEE 802 requirements probably have a word on protected result
> indications (I got to check that)... but I'd rather have IETF also state
> its opinion on EAP methods (while this could be done in a future IETF
> "how to design a good EAP method" document, I'd rather not count on the
> future and do what is possible now ;-)
>