eap Mailing List: Security considerations text in state machine draft (Was: Re: [eap] [Issue 248] Comments on EAP state machine v4)

(continued)

Your text below looks good, Florent. Thanks. I see
that Nick already incorporated this to -04. Good.
--Jari
"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."

Security considerations text in state machine draft (Was: Re: [eap] [Issue 248] Comments on EAP state machine v4)	<– Date –> <– Thread –>
From: Jari Arkko (jari.arkkopiuha.net)
Date: Sat, 24 Jul 2004 05:41:48 -0400 (EDT)