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

From: "Paul Rowe" <[email-masked]>
Date: Sun, 21 Oct 2007 10:34:01 -0400

Regarding the client-side DoS attack in EAP-GPSK:

The proposed solution is to add ID_Server to message 3, allowing the client
to maintain state per server instead of state per message 1 received:

http://www1.ietf.org/mail-archive/web/emu/current/msg00670.html

We agree that this solution seems to solve the issue in the cleanest way.

Andre Scedrov, John Mitchell, Arnab Roy, Paul Rowe

>Date: Wed, 3 Oct 2007 21:22:31 -0700
>From: "Joseph Salowey (jsalowey)" <[email-masked]>
>Subject: RE: [Emu] EAP-GPSK and Client-Side DoS Attacks
>To: "Tschofenig,        Hannes (NSN - DE/Germany - MiniMD)"
>       <[email-masked]>,    <[email-masked]>
>Message-ID:
>      <[email-masked]>
>Content-Type: text/plain;       charset="us-ascii"
>
>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:[email-masked]]
>> Sent: Thursday, September 20, 2007 1:51 AM
>> 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
>>
_______________________________________________
Emu mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/emu

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 30 Oct 2007 11:29:27 -0700

GPSK authors,

Please update the draft to reflect the addition of the ID_Server to
message 3 and the key derivation proposal.  

Thanks,

Joe 

> From: Paul Rowe [mailto:[email-masked]] 
> Sent: Sunday, October 21, 2007 7:34 AM
> To: [email-masked]
> The proposed solution is to add ID_Server to message 3, 
> allowing the client to maintain state per server instead of 
> state per message 1 received:
> 
> >From: "Joseph Salowey (jsalowey)" < [email-masked] 
> ><mailto:[email-masked]> >
> >       < [email-masked] 
> <mailto:[email-masked]> >,    <[email-masked]>
> >Message-ID:
> >      < 
> [email-masked]
> o.com 
> <mailto:[email-masked]
> mer.cisco.com> >
> >not to remove the identity from the key derivation so either 
> option 2 
> >or
> >change to the existing draft.  Since we do not have many 
> >implementations yet I would slightly favor 2.
> >
> >
> >
> >> [mailto: [email-masked] 
> <mailto:[email-masked]> 
> >> ]
> >> 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.
> >>
> allowing the 
> >> peer to check the MAC without the ID. This might require 
> another NIST 
> >> review.
> >>
> >> 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 
> >> In any case, I agree with the assessment and the need to document 
> >> something in the draft.
> >>
> >> [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
> >>
> >>
> >>
> >>
> >>
> >><https://www1.ietf.org/mailman/listinfo/emu>
> >>
> 
>