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
