Re: [kitten] SPAKE Preauth

Nico Williams <nico@cryptonector.com> Fri, 01 May 2015 21:23 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6F021B2E58 for <kitten@ietfa.amsl.com>; Fri, 1 May 2015 14:23:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Level:
X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ou2MAdrFD6a4 for <kitten@ietfa.amsl.com>; Fri, 1 May 2015 14:23:23 -0700 (PDT)
Received: from homiemail-a55.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id EB9DB1A01F0 for <kitten@ietf.org>; Fri, 1 May 2015 14:23:22 -0700 (PDT)
Received: from homiemail-a55.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTP id C808B1636; Fri, 1 May 2015 14:23:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=bN0OAoOaCjTaGg I189CLM51d6J4=; b=N38EOvzw+43oKXOzoTUO6zH81h1duNLWnjJJtJiRoWUYO4 q2hjTilRhKprL/yElTEZxa+JWzXKtyWTWunTN7sKHecxroGaV9w6DueP7xPd/hnB YMYLz8RUmkQWa2W+K8AyM4QkVbeI81UZDURI2VIei8N8Bhw68+Bb2XDlPM92g=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTPA id 6CCAF1612; Fri, 1 May 2015 14:23:22 -0700 (PDT)
Date: Fri, 1 May 2015 16:23:21 -0500
From: Nico Williams <nico@cryptonector.com>
To: Nathaniel McCallum <npmccallum@redhat.com>
Message-ID: <20150501212321.GC10065@localhost>
References: <1430138754.2682.10.camel@redhat.com> <553FA2B3.8030301@mit.edu> <alpine.GSO.1.10.1504281531500.22210@multics.mit.edu> <20150501211503.GA10065@localhost> <1430515138.2514.10.camel@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1430515138.2514.10.camel@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/-mO-q9-hZ3nfGXlRfPE_XnTHIBg>
Cc: "kitten@ietf.org" <kitten@ietf.org>
Subject: Re: [kitten] SPAKE Preauth
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 May 2015 21:23:23 -0000

On Fri, May 01, 2015 at 05:18:58PM -0400, Nathaniel McCallum wrote:
> On Fri, 2015-05-01 at 16:15 -0500, Nico Williams wrote:
> > Yes.  And 4.4 makes it worse because continued 2nd factor exchanges
> > use EncryptedData, including from the AS to the client (which can
> > then confirm that its choice of password guess was incorrect).
> > 
> > The fix for this is to send AS->client 2nd factor continuations in
> > the clear if at all possible.  Which means that in the AS->client
> > 3rd and subsequent passes we need a CHOICE of OCTET STRING or
> > EncryptedData, or perhaps allow the use of the null enctype in the
> > AS->client 2nd factor EncryptedData.
> > 
> > The AS will know as soon as it tries to decrypt the client's 2nd
> > factor (whose EncryptedData functions as a proof of possession) that
> > the client doesn't know the password.  In this case the AS should
> > continue and process _a_ 2nd factor as much as possible as if the
> > password was right.  The AS could do this by arranging to have a
> > special user account (so as not to lock out the real user) for
> > testing bogus second factors, and using a random or constant 2nd
> > factor for this.
> 
> I think this is overkill. Most continuations will have already
> validated some aspect of the second factor. For instance, in HOTP/TOTP
> continuations are used for synchronization of the token after the
> validation of the initial token code.

It doesn't seem like overkill to me.  Unless the property that an
attacker can't distinguish which factor was wrong is not that important.

Note that AS implementations could just always send continuations as
EncryptedData, leaking that way.  What I want is for it to be possible
to implement an AS that doesn't leak.

Nico
--