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
