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

[Florent Bersani (florent.bersani]

Nick, all

I looked again at my comment #6 and the current text in the draft.

I guess that my original comment was twofold:
1) Since among the 9 theoretically possible (methodState,decision) 
pairs, only 6 were allowed (namely (CONT,FAIL), (MAY_CONT,COND_SUCC), 
(MAY_CONT, FAIL), (DONE, COND_SUCC), (DONE, UNCOND_SUCC) and 
(DONE,FAIL), I took this as a hint that there might be simpler way to 
implement things...
1) While thinking on simpler ways, I came to question the usefulness of 
COND_SUCC: to me this decision value is harmful from a security POV. An 
attacker has no problem whatsoever to make the peer believe anything 
(i.e. success or failure) as soon as the peer has set COND_SUCC. So my 
comment was about: do we want to keep COND_SUCC? (same comment applies 
to MAY_CONT: I fail to see why we have (MAY_CONT,FAIL) - it could be 
replaced by (CONT,FAIL), couldn't it?)

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 am in favor of deleting it (as a legacy venue for irritating - though 
perhaps not very important - security trouble)...

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

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"

What do you think?

Florent, so tired he does not doubt that he may well again be totally 
off the rocket :-(

Nick Petroni wrote:

> Florent and all,
>
> As Monday 7/19 is the cut-off for document submission, I would like to ask
> for help in resolving as much of the remaining issues as possible in the
> state machine document. Here is a list of necessary changes as I see them
> for Issue 248. Please let me know how these look in principle and
> contribute text if possible. I also will attempt to contribute text over
> the next couple of days.
>
> Thanks,
> nick
>
> ...
>
> Comment #6 - Technical
>  Request text to clarify the use the methodState variable in section
>  4.2.
>
>  
Florent Bersani wrote:

> Comment #6 - Technical
>
> This is about DONE, CONT and MAY_CONT/UNCOND_SUCC, COND_SUCC and FAIL.
>
> While I do not doubt that there are could technical reasons to use 
> these variables (rather than simply CONT and DONE) and that the EAP 
> state machine does not claim to be THE way to implement EAP (in its 
> introduction "The State Machine and associated model are informative 
> only. Implementations may achieve the same results using different 
> methods"), I think that giving briefly the rationales behind this 
> choice (which is not explicit in section 4.2 IMHO) would help the 
> reader. In particular, giving an example of MAY_CONT's usefulness.
>
> About the decision variable, here also an explanation of the design 
> (maybe with an example) could help. Indeed, it seems to me that not 
> all pairs (state, decision) are acceptable so state/decision are not 
> totally independent. Here again, giving an example why COND_SUCC was 
> introduced could help.
>
> I think this concern is also related to the conditions in the state 
> machine that allow the peer to transition to success or failure. They 
> do not appear to be either trivial or symmetric. The newbie I 
> unfortunately am, needs much more time to (fully) understand them than 
> any other transition condition in the state machine. Bernard for 
> instance questioned about these Success/Failure transitions in Issue 
> 229. For instance, I am wondering, how the condition "altAccept && 
> methodState != CONT && decision == FAIL" may occur.
>
> Also in section 4.2 I tend to feel dizzy with some text in the 
> paragraph methodState=DONE: "If both (a) the server has informed us 
> that it will allow access and the next packet will be EAP Success,and 
> (b) we're willing to use this access, set decision=UNCOND SUCC." I 
> guess that condition (a) should rather be formulated in terms of 
> altAccept, shouldn't it?

As a reminder, this has been clarified. I was totally wrong and 
confused. altAccept referred to lower layer indications and not method 
protected result indication. altAccept has been relaebeled 
lowerLayerAccept (or something like this IINM).

> Indeed while IIRC RFC 3748 mandates (in section 4.2 "The authenticator 
> MUST transmit an EAP packet with the Code field set to 3 (Success)"  
> that a success packet be sent, this does not guarantee that the peer 
> will ever receive it.