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

From: "Tschofenig, Hannes (NSN - DE/Germany - MiniMD)" <[email-masked]>
Date: Thu, 20 Sep 2007 10:51:06 +0200

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.  SiFrom [email-masked] Thu Sep 20 04:51:11 2007
Content-class: urn:content-classes:message
Date: Thu, 20 Sep 2007 10:51:06 +0200
From: "Tschofenig,
	Hannes (NSN - DE/Germany - MiniMD)" <[email-masked]>
To: <[email-masked]>
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/emu