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

[Florent Bersani (florent.bersani]

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