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

[Nick Petroni (npetroni]

> Although I disagree stricto sensu with this example (the peer will not
> receive a DHCP request, IINM, it will send one), I essentially agree
> with you: I confused alternate lower layer indications and protected
> method indications.
Typically, no, it would not receive a DHCP request. However, you are
thinking of a particular scenario (Roaming client == EAP Peer). I know of no
strict mapping that this must occur. There can certainly be cases, at
least theoretically, where the entity playing the role of EAP Peer
provides some sort of network service. The authenticator's use of that
service could serve as an "alternate indication of success." That
service COULD be DHCP, although I don't know why it would be. Anyway, as
you say, it's not important to the conversation. We both understand.

> >>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.
> >
> Thx for the explanation (and sorry I missed it in the archives). Why not
> include it in the document?
We could. I see no reason why this can't be added.


> >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)
> >
> This is not the case I mention!!
I know it isn't. My point is, that this DoS is known and well understood.
Furthermore, the ONLY mitigation of Nak DoS is the one both you and I
described.

> I precisely mention the case, when the server has sent his initial
> request and an attacker replies with a NAKs before the peer replies with
> the correct response. In this scenario, IINM, although the server may be
However, the server has no way to know the Peer was not a valid peer.
Think about a new person trying to use the network or simply someone using
the wrong configuration file for their peer software. Even legacy
software that doesn't support the deployed method could be an issue. If
they send a Nak and get NO RESPONSE this would make for difficult
debugging. Sending a Nak at this point is valid and they should at least
receive a Failure to indicate that their proposal was rejected.

> sure that a valid peer won't NAK (a policy decision), figure 4 mandates
> that it processes the NAK. I find it an unnecessary open a door to a
> stupid & useless & inefficient DoS (and when one cans close such doors
> without much trouble, then I recommend closing them although the DoS
> attack is not dramatic). So my proposed resolution is to allow the
> policy to set methodstate directly to CONTINUE (while still authorizing
> it to set the state to PROPOSED) in the PROPOSE_METHOD state. What do
> you think?
I think this is not a useful mitigation. The reason is simple- an attacker
can still spoof a Failure packet in the opposite direction at almost any
point for just as easy a DoS. Even if you are using a smart method, there
will be a window when the attacker can sneak in a Failure in most
environments. I think the general rule of "it's no worse than a DoS that
we know we can't mitigate so why mitigate this one." Furthermore, IMHO the
protocol issue discussed above is all the more reason not to disallow
Naks at this point. Some implementations may do so, but I don't see the
value of mitigating this particular attack in the SM.

> >>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.
> >
> well, according to the definition of aaaEapResp (section 7.1.1 "Set to
> TRUE in lower layer, FALSE in authenticator state machine. Indicates an
> EAP response is available for processing."), aaaEapResp is *not* a vague
> flag to say to the lower layer to do to do something but a precise flag
> to say to it that it has a  response available for processing.
> So I still hold onto this issue. It arises when an authenticator boots
> and decides directly that it will be pass-through whatever the id of the
> peer (this behavior appears to be allowed by the state machine). I think
> it needs a fix.
What is the issue precisely? The problem as I see it is if you DON'T set
aaaEapResp in AAA_IDLE then you will just hang waiting for the lower layer
when it doesn't know that it's its turn.