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

[Florent Bersani (florent.bersani]

Nick,

Please see in-line some answer to your email and Jari's... and some 
proposed text for the "DoS issues".

Hope this helps,

Florent

Jari Arkko wrote:

> Florent, Nick,
>
> First: thanks for going through the remaining issues!
>
> ...
>
> Fortunately or unfortunately, EAP is already deployed. We have
> created this working group in the IETF to "fully document and
> improve the interoperability of the existing EAP protocol" (quoting
> our charter). I think we should adopt better alternatives
> and designs whenever we can -- and I think we have often done
> that when working with the details -- but not when it would affect
> backwards compatibility. EAPv2 is also off-limits for our
> working group, though of course individuals in the group
> can pursue, say, next-gen network access protocol designs
> in their research work.
>
> So, lets keep resolve the other stuff the best we can,
> but not outlaw existing EAP methods. And as I have
> said before, it would be good to have text to point
> out specific vulnerabilities and issues in existing
> EAP methods and the "L" part of the state machine.

> I think RFC 3748 is our primary document regarding
> the security properties of EAP (or lack thereof),
> so I don't think we should hold the publication of the
> state machine to develop such text. But if you already
> have such text or you can clearly see what the implications
> are, please send text so that Nick can put it in.

What about the following text (alluding to the potential well-known 
vulnerabilities):

Add to section 8 "Implementation considerations" of the EAP state 
machine draft (or to section 9 "security considerations"):

"As noted in RFC 3748 there are some security concerns that arise 
because of the following EAP packets:

  1. EAP-Request/Response Identity
  2. EAP-Response/NAK
  3. EAP-Success/Failure

Since these packets are not cryptographically protected by themselves, 
an attacker can modify them without immediate detection by the peer or 
the server.

Following Figure 3 specification, an attacker may cause denial of 
service by:

   * Sending an EAP-Failure to the peer before the peer has started an
     EAP authentication method. Indeed, as long as the peer has not
     modified the methodState variable which is initialized to NONE,
     the peer MUST accept an EAP-Failure.
   * Forcing the peer to engage in endless EAP-Request/Response
     Identity exchanges before it has started an EAP authentication
     method. Indeed, as long as the peer has not modified the
     selectedMethod variable which is initialized to NONE, the peer
     MUST accept an EAP-Request/Identity and respond to it with an
     EAP-Response/Identity

Following Figure 4 specification, an attacker may cause denial of 
service by:

   * Sending a NAK to the server after the server first proposes an EAP
     authentication method to the peer. Indeed, as the methodState
     takes the value PROPOSED, the server is obliged to process a NAK
     that is included in response to its first packet of an EAP
     authentication method.

There MAY be some cases when it is desired to prevent such attacks. This 
can be done by modifying initial values of some variables of the EAP 
state machines. However, such modifications are NOT RECOMMENDED.

There is indeed a tradeofff between mitigating these denial of service 
attacks and being able to deal with EAP peers and servers in general. 
For instance, should the sending of a NAK to the server after it has 
just proposed an EAP authentication method to the peer be ignored, then 
a legitimate peer that is not able or willing to process the proposed 
EAP authentication method would fail without an opportunity to negotiate 
another EAP method."

What do you reckon?

> --Jari (the co-chair hat on)

Nice hat ;-)

Nick Petroni wrote:

> Florent,
>
> I certainly appreciate your opinion, but I hope you know that it is not
> me with whom you are disagreeing.
I know that, don't worry.

> I am simply explaining what I understand
> the constraints of this working group to be.
It seemed like I just felt being reminded them by our beloved chairs ;-)

> 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.
I think (as Jari) that you are right :-))

> It has certainly
> happened on more than one occasion :).
> Take care,
> nick