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

[Nick Petroni (npetroni]

Here are some comments on Issue 248.

Thanks,
nick

> Comment #5 - Technical
>
> That's just a triviality about for instance the peer state machine:
> thanks to EAP idleWhile, the method does not have to set timers (EAP
> cares for it). However, in case the method wants to implement a "bad
> packet received" counter (e.g. it is waiting for a packet and to provide
> DoS resilience it wants to allow receiving a limited number of "bad
> packets" before the right one - instead of going automatically to
> failure), it has to do so by itself (and typically will use altReject if
> it wants to fail before the timeout. This is not an issue but perhaps it
> could be worth discussing the usefulness of such a behavior for EAP
> methods (see e..G g. RFC 3748 section 7.5 "Whether a MIC validation
> failure is considered a fatal error or not is determined by the EAP
> method specification") and that it can indeed be implemented in the EAP
> state machines (with a little disymmetry between the timer implemented
> within EAP and the "bad packet received" counter implemented within the
> method. I guess this comment is a way for me to express that I
> wholeheartedly agree with the point .3 Joe made in issue 203 (in other
> words the imbrication of EAP and EAP methods confine to layer violation).
I'm sorry, I don't quite understand how you would like to resolve this
issue. I *think* you want more guidelines for how a method could implement
certain types of error processing for things like possible DoS attacks
etc. Is this correct?

> 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.
This seems mostly editorial, but perhaps not- you are asking for more text
to describe these state, right? I can see why this might be of some use
for someone without the context of the EAP WG discussions (i.e. the
typical reader of this document).

> 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.
This is the condition where a so-called "alternate indication" of success
is received, but the method *might* be done and has not yet concluded it
succeeded on its own. There are three competing issues here:
  1. We received an outside "alternate" indication that EAP is finished
     (e.g. DHCP request or similar)
  2. The method has not explicitly claimed it is still continuing, so it
     is either "possbily done" (methodState == MAY_CONT) or it is
     definitely done (methodState == DONE). Either way, it is possible tha
     the method could be finished so we can't just ignore the indication
  3. we have no indication from the method of success. EAP should never go
     to the SUCCESS state without getting notification that the method
     succeeded (or otherwise is willing to accept the connection)


> 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? Indeed while IIRC RFC 3748 mandates (in section 4.2 "The
No, I think there are two things being confused here. altAccept is NOT to
be used by methods. altAccept corresponds to so-called "alternate
indications" found in RFC2284 (and now RFC3748). (a) is meant to show the
case where IN THE METHOD the peer has been made aware that the
authenticator is happy with the state of authentication and will allow
access. Previously, it was possible to hijack EAP sessions by sending an
EAP Success before the authentication was complete or DoS by sending EAP
Failure. Now, the method has a way to say "I know we succeeded, so
any Failure packet is false" or "if you don't get a Success, it's still
ok."

> Comment #9 - Technical
>
> Apparently Figure 4 (EAP Standalone Authenticator State Machine) leaves
> the door open to a sequence of EAP authentication methods (which is
> explicitly forbidden by RFC 3748 section 2.1 "However, the peer and
> authenticator MUST utilize only one authentication method (Type 4 or
> greater) within an EAP conversation"). This behavior may be prevented
> thanks to Policy.getDecision or PolicygetNextMethod... but I do not find
> this is exactly a matter of policy and at least, this should be pointed
> out (that the policy MUST forbid this behavior).
I agree, this is not correct explicitly. I see a couple ways of handling
this as well. I think the simplest is to add a statement in the definition
of some policy functions, but if others feel the SM should be updated I
would go along with it.

> Comment #10 - Technical
>
> Why include a separate TIMEOUT_FAILURE State? Why not use the FAILURE state?
This is because the symptom is that a requeste has been sent, but no
response received. My recollection is that it was discussed and determined
that EAP should not send a Failure in response to this symptom, it should
simply stop trying.


> Comment #12 - Technical
>
> This one is stupid but what happens, according to Figure 4, when the
> standalone authenticator fails directly, i.e. starts by INITIALIZE,
> transitions to SELECT_ACTION where Policy.getDecision replies FAILURE
> and thus transitions to FAILURE - in the FAILURE state, I bet there is
> some problem with eapReqData = buildFailure(currentId) since currentId=NONE
This is a problem with Canned Success/Failure in general since only
Requests modify the Identifier field. IEEE 802-1X-REV states the following
in 8.2.4.1.3:
  txCannedFail. An EAPOL frame of type EAP-Packet, containing an EAP
                Failure packet constructed by the Authenticator, is
                transmitted to the Supplicant. In the case that
                no EAP communication was taking place on the port, then
                any value of Id may be used in the identifier field of the
                EAP frame. In the case that there was an EAP communication
                taking place on the port, then the value of the Identifier
                field in the EAP packet is set to a value that is different
                from the last delivered EAPOL frame of type EAP-Packet.

We could add similar text if you like.

> Comment #14  - Technical
>
> I am totally novice to DoS (I found a lot of papers on the subject, for
> instance related to IKE - I plan to read them soon :-)) so this point is
> probably not very important (my understanding is that one of the
> difficulties with DoS is to understand what is really relevant and what
> rather belongs to the .11 microwave oven attack, another one could be
> set the trade off between DoS resilience and "efficiency").
>
> It just seems to me that Figure 4 prevents the standalone authenticator
> from ignoring (bogus) NAKs. Indeed, let us consider a corporate WLAN
> deployment where exactly one EAP method is allowed - so that no valid
> user will ever NAK. In this setting, there is no point in processing the
> NAK, possibly loosing the valid user's response if the attacker's NAK
> arrived first and starting all over. I did not find text on this in RFC
> 3748 (the text I found was about preventing NAKs when a response to a
> method has already been received) which is not our case here.
Using forged Naks as a DoS is a known attack against EAP AFAIK. The DoS
attack is mitigated by the case you mention (not allowing after non-Nak
response has been received), but the attack remains nonetheless.

> Comment #17 - Technical
>
> I fail to understand the transition in Figure 7 from
> INITIALIZE_PASSTHROUGH to AAA_IDLE when currentId==None, given that
> AAA_IDLE sets aaaEapResp=TRUE
I think the point here is that aaaEapResp is telling the lower layer that
it's time for that layer to do something. In this case, no packets have
been sent from anyone so the lower layer will see aaaEapRespData is NONE
and know to start. At least I *think* this is what's going on. Others may
be able to correct me.