GPSK authors, Please update the draft to reflect the addition of the ID_Server to message 3 and the key derivation proposal.
Thanks, Joe > -----Original Message----- > From: Paul Rowe [mailto:[EMAIL PROTECTED] > Sent: Sunday, October 21, 2007 7:34 AM > To: [email protected] > Subject: RE: [Emu] EAP-GPSK and Client-Side DoS Attacks > > 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] > ><mailto:[EMAIL PROTECTED]> > > >Subject: RE: [Emu] EAP-GPSK and Client-Side DoS Attacks > >To: "Tschofenig, Hannes (NSN - DE/Germany - MiniMD)" > > < [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> >, <[email protected]> > >Message-ID: > > < > [EMAIL PROTECTED] > o.com > <mailto:[EMAIL PROTECTED] > mer.cisco.com> > > >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] > <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 > >><https://www1.ietf.org/mailman/listinfo/emu> > >> > > _______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu
