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 PROTECTED]> >Subject: RE: [Emu] EAP-GPSK and Client-Side DoS Attacks >To: "Tschofenig, Hannes (NSN - DE/Germany - MiniMD)" > <[EMAIL PROTECTED]>, <[email protected]> >Message-ID: > <[EMAIL PROTECTED]> >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 PROTECTED] >> Sent: Thursday, September 20, 2007 1:51 AM >> To: [email protected] >> 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 protected] >> https://www1.ietf.org/mailman/listinfo/emu >>
_______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu
