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