Re: [Emu] Review of draft-ietf-emu-eap-gpsk-08 (1st round of comments)
Jouni Malinen <j@w1.fi> Sat, 02 August 2008 07:57 UTC
Return-Path: <emu-bounces@ietf.org>
X-Original-To: emu-archive@megatron.ietf.org
Delivered-To: ietfarch-emu-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB4E63A6A66; Sat, 2 Aug 2008 00:57:02 -0700 (PDT)
X-Original-To: emu@core3.amsl.com
Delivered-To: emu@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B85C3A6A66 for <emu@core3.amsl.com>; Sat, 2 Aug 2008 00:57:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.639
X-Spam-Level:
X-Spam-Status: No, score=-0.639 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfzkDpq-jD8k for <emu@core3.amsl.com>; Sat, 2 Aug 2008 00:56:58 -0700 (PDT)
Received: from hostap.isc.org (hostap.isc.org [149.20.54.63]) by core3.amsl.com (Postfix) with ESMTP id 411A63A6889 for <emu@ietf.org>; Sat, 2 Aug 2008 00:56:58 -0700 (PDT)
Received: from gprs-internet.mobile.sonera.net ([212.213.204.99] helo=jm) by hostap.isc.org with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <j@w1.fi>) id 1KPBRs-0003QC-Ks; Sat, 02 Aug 2008 00:22:53 -0700
Received: by jm (sSMTP sendmail emulation); Sat, 2 Aug 2008 10:54:00 +0300
Date: Sat, 02 Aug 2008 10:54:00 +0300
From: Jouni Malinen <j@w1.fi>
To: Charles Clancy <clancy@cs.umd.edu>
Message-ID: <20080802075359.GA5504@jm.kir.nu>
References: <47E95784.8060407@cs.umd.edu> <486501B9.1060601@cs.umd.edu> <1696498986EFEC4D9153717DA325CB720112AAB1@vaebe104.NOE.Nokia.com> <486F8C8E.5030207@gmx.net> <1696498986EFEC4D9153717DA325CB72012C1584@vaebe104.NOE.Nokia.com> <488F020D.9090801@umd.edu> <1696498986EFEC4D9153717DA325CB72013BAB71@vaebe104.NOE.Nokia.com> <488F4512.7040706@cs.umd.edu>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <488F4512.7040706@cs.umd.edu>
User-Agent: Mutt/1.5.16 (2007-06-09)
X-Spam-Bar: ---
Cc: Pasi.Eronen@nokia.com, emu@ietf.org
Subject: Re: [Emu] Review of draft-ietf-emu-eap-gpsk-08 (1st round of comments)
X-BeenThere: emu@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/emu>
List-Post: <mailto:emu@ietf.org>
List-Help: <mailto:emu-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: emu-bounces@ietf.org
Errors-To: emu-bounces@ietf.org
On Tue, Jul 29, 2008 at 12:28:02PM -0400, Charles Clancy wrote: > This state-minimization approach was proposed by the Stanford security > review. In earlier versions of the draft, CSuite_Sel and RAND_Server were > not included in GPSK-3, and were not verified. I'm not sure why the > language you referenced below got updated after they were added to GPSK-3. > > All -- Does anyone in the WG object to this change? I would assume the validation was removed in order to allow peer implementation to not store RAND_Server after having derived the keys and sent GPSK-2. Peer will need to know CSuite_Sel for verifying the MIC in GPSK-3 and I would rather not rely on the value sent in GPSK-3 to do this, so that part of the change would not reduce any space in the peer implementation. Anyway, if the values in GPSK-3 are not verified, I don't see much point including them there.. Consequently, I would prefer to revert this change of removing validation of RAND_Server and CSuite_Sel in GPSK-3 and go back to -10 version of that text. By the way, I just noticed that there seems to be something even more seriously broken in this paragraph: For GPSK-3, a peer MUST silently discard messages where the RAND_Peer field does match the value transmitted in GPSK-2. The "discard where _does_ match" does not sound correct; it should be _does not_ match. ;-) This has been incorrect since the text was added in -02.. Clearly this have been too obvious for anyone to notice before (yes, I must have read that, too, and still, I ended up implementing the correct "does not" behavior, not the one specified here). This a text I would actually like to see here: For GPSK-3, a peer MUST silently discard messages where the RAND_Peer, the RAND_Server, or the CSuite_Sel fields do not match those transmitted in GPSK-2. An EAP peer MUST silently discard any packet whose MAC fails. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
- Re: [Emu] Review of draft-ietf-emu-eap-gpsk-08 (1… Charles Clancy
- Re: [Emu] Review of draft-ietf-emu-eap-gpsk-08 (1… Dan Harkins
- Re: [Emu] Review of draft-ietf-emu-eap-gpsk-08 (1… Pasi.Eronen
- Re: [Emu] Review of draft-ietf-emu-eap-gpsk-08 (1… Hannes Tschofenig
- Re: [Emu] Review of draft-ietf-emu-eap-gpsk-08 (1… Pasi.Eronen
- Re: [Emu] Review of draft-ietf-emu-eap-gpsk-08 (1… Pasi.Eronen
- Re: [Emu] Review of draft-ietf-emu-eap-gpsk-08 (1… Charles Clancy
- Re: [Emu] Review of draft-ietf-emu-eap-gpsk-08 (1… Jouni Malinen
- Re: [Emu] Review of draft-ietf-emu-eap-gpsk-08 (1… Joseph Salowey (jsalowey)
- Re: [Emu] Review of draft-ietf-emu-eap-gpsk-08 (1… Jouni Malinen