RE: [Emu] EAP-GPSK and Client-Side DoS Attacks
"Joseph Salowey (jsalowey)" <jsalowey@cisco.com> Thu, 04 October 2007 04:22 UTC
Return-path: <emu-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdIEF-00072C-7t; Thu, 04 Oct 2007 00:22:27 -0400
Received: from emu by megatron.ietf.org with local (Exim 4.43) id 1IdIEE-000726-G5 for emu-confirm+ok@megatron.ietf.org; Thu, 04 Oct 2007 00:22:26 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdIEE-00071A-5m for emu@ietf.org; Thu, 04 Oct 2007 00:22:26 -0400
Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdIEC-0006al-T0 for emu@ietf.org; Thu, 04 Oct 2007 00:22:26 -0400
X-IronPort-AV: E=Sophos;i="4.21,227,1188802800"; d="scan'208";a="230186437"
Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 03 Oct 2007 21:22:24 -0700
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l944MOnB032383; Wed, 3 Oct 2007 21:22:24 -0700
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l944MOYt005795; Thu, 4 Oct 2007 04:22:24 GMT
Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Oct 2007 21:22:24 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Emu] EAP-GPSK and Client-Side DoS Attacks
Date: Wed, 03 Oct 2007 21:22:31 -0700
Message-ID: <AC1CFD94F59A264488DC2BEC3E890DE5049B93BB@xmb-sjc-225.amer.cisco.com>
In-Reply-To: <5FB585F183235B42A9E70095055136FB1E52D8@DEMUEXC012.nsn-intra.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Emu] EAP-GPSK and Client-Side DoS Attacks
Thread-Index: Acf7Y2Gkq5KYJC1FS7aKMYexd7FkWgK2nBTQ
From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
To: "Tschofenig, Hannes (NSN - DE/Germany - MiniMD)" <hannes.tschofenig@nsn.com>, emu@ietf.org
X-OriginalArrivalTime: 04 Oct 2007 04:22:24.0106 (UTC) FILETIME=[29EAECA0:01C8063E]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4141; t=1191471744; x=1192335744; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20<jsalowey@cisco.com> |Subject:=20RE=3A=20[Emu]=20EAP-GPSK=20and=20Client-Side=20DoS=20Attacks |Sender:=20; bh=C9R03sncm0bw/QDSSeZRRyj68CU8Y9E4QZhV1Pss7n8=; b=GNW/QUY5/I8U2KMjHDB87vINv3oUIxCNvXsU4TPL0dfrehqKqdi1R3rfvgRTgbBvyLXcST7F UrQ/ekpJzoazY/DwCCtinXGkJvqOsu+Os0zFlwzjl/aMY66q/kz3F5tM;
Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 34d35111647d654d033d58d318c0d21a
Cc:
X-BeenThere: emu@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/emu>
List-Post: <mailto:emu@ietf.org>
List-Help: <mailto:emu-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe>
Errors-To: emu-bounces@ietf.org
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:hannes.tschofenig@nsn.com] > Sent: Thursday, September 20, 2007 1:51 AM > To: emu@ietf.org > 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 > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
- RE: [Emu] EAP-GPSK and Client-Side DoS Attacks Paul Rowe
- RE: [Emu] EAP-GPSK and Client-Side DoS Attacks Joseph Salowey (jsalowey)
- RE: [Emu] EAP-GPSK and Client-Side DoS Attacks Joseph Salowey (jsalowey)