RE: [Emu] EAP-GPSK and Client-Side DoS Attacks

I think the problem is real, although not catastrophic.  I would prefer
not to remove the identity from the key derivation so either option 2 or
3 is good. I think 2 is maybe a little bit cleaner and 3 is less of a
change to the existing draft.  Since we do not have many implementations
yet I would slightly favor 2.  

> -----Original Message-----
> From: Tschofenig,Hannes (NSN - DE/Germany - MiniMD) 
> [mailto:hannes.tschofenig@nsn.com] 
> Sent: Thursday, September 20, 2007 1:51 AM
> To: emu@ietf.org
> Subject: [Emu] EAP-GPSK and Client-Side DoS Attacks
> 
> Hi all, 
> 
> What is the issue? The first message from the server to the 
> peer is not authenticated. This may allow some kind of denial 
> of service attack against the peer. The peer should be ready 
> to accept new sessions from the same server, so the peer must 
> store one server nonce and one peer nonce for each message 1 
> it receives.  An attacker can then flood the network with 
> fake message 1s to overflow the peer's buffer.  This issue is 
> similar to an issue found in the 802.11i 4-way handshake.
> 
> When receiving message 1, the peer checks to see if it has 
> open conversations with the server listed in the message.  If 
> it does, then it will reuse the peer nonce it already sent.  
> In addition, it will not store the server nonce, since the 
> server nonce comes back in message 3.
> Message 3 then contains almost all the information necessary 
> to validate the MAC.  It is only missing the ID_Server.  
> There seem to be three ways to solve this which are discussed 
> in the next paragraph.  
> 
> 1) The first is to drop ID_Server from the input string, 
> allowing the peer to check the MAC without the ID. This might 
> require another NIST review.  
> 
> 2) The second is to add ID_Server to message 3.
> 
> 3) Thirdly, the peer could iterate through its list of 
> associated servers trying to find one which matches.  
> This allows the peer to store state per server instead of 
> storing state per message.  Since the peer has a fixed (for 
> the duration of a DoS
> attack) and limited number of associated servers, this fixes 
> the attack.
> 
> Initially, I was a bit curious about the need to allocate 
> state on the client side with an injected Message 1 by the 
> adversary. The text in Section 4.2 of [1] was, however, 
> convincing that the end host needs to keep state information 
> of multiple sessions even if it only accepts a single one 
> since otherwise you would be able to put the client into a 
> blocking state. [1] focuses on a case where only a single 
> nonce is used in message 3 whereas in EAP-GPSK both nonces 
> are present in message 3.
> When the client receives message (3) then it needs to derive 
> keying material based on the following info: RAND_Peer, 
> ID_Peer, RAND_Server, ID_Server, RAND_Peer, RAND_Server is in 
> message 3 provided by the server and ID_Peer is known to the 
> peer. The EAP peer may have multiple identities too. Hence, 
> in EAP-GPSK at least the ID_Server attribute is missing in 
> message 3. Now, the question is how many EAP server 
> identities a client has. I suspect only a single one, with 
> the realm name for the entire domain (with respect to a 
> particular credential) and how many identities the client uses. 
> 
> In any case, I agree with the assessment and the need to 
> document something in the draft.
> 
> Do you agree that the problem is real?
> If yes, what type of solution approach would the group prefer?
> 
> Ciao
> Hannes
> 
> Reference:
> 
> [1] Changhua He, John C. Mitchell. Analysis of the 802.11i 
> 4-Way Handshake. In Proceedings of the Third ACM 
> International Workshop on Wireless Security (WiSe'04), pages 
> 43-50. Philadelphia, PA, Oct. 2004
>  
> 
>  
> 
> 
> _______________________________________________
> Emu mailing list
> Emu@ietf.org
> https://www1.ietf.org/mailman/listinfo/emu
> 

_______________________________________________
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu