Re: [kitten] SPAKE Preauth

Nico Williams <nico@cryptonector.com> Sat, 02 May 2015 23:24 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 308B51A913B for <kitten@ietfa.amsl.com>; Sat, 2 May 2015 16:24:38 -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 rsZjYvN2ZUt7 for <kitten@ietfa.amsl.com>; Sat, 2 May 2015 16:24:37 -0700 (PDT)
Received: from homiemail-a106.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 75FBF1A9138 for <kitten@ietf.org>; Sat, 2 May 2015 16:24:37 -0700 (PDT)
Received: from homiemail-a106.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTP id 581802005D005; Sat, 2 May 2015 16:24:37 -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=yGAdQfTJPHqMED 0O0WMjogC9P/w=; b=QqJQlICZodS6xDIRjRi9fsDjZUgfv/8v2wh0uFwUADY/1d 0YovMKYo681TobIzlIUDwG+XA6fwslboTZUAYW3/SOzxWsAWYi1BPMHluWMH0ut7 U/FFjE2e637aoLd2i+8x6WKcOQ9F5LDZJU7jiYpMvktAjjoZsT6soj4mvehAA=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTPA id EE2AB2005D004; Sat, 2 May 2015 16:24:36 -0700 (PDT)
Date: Sat, 2 May 2015 18:24:36 -0500
From: Nico Williams <nico@cryptonector.com>
To: Benjamin Kaduk <kaduk@MIT.EDU>
Message-ID: <20150502232435.GH10065@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> <20150501212321.GC10065@localhost> <1430515623.2514.16.camel@redhat.com> <20150501213055.GD10065@localhost> <1430515954.2514.17.camel@redhat.com> <alpine.GSO.1.10.1505021412500.22210@multics.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.GSO.1.10.1505021412500.22210@multics.mit.edu>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/MEfa_Qm-puh48wdxLwV11nyPF4I>
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: Sat, 02 May 2015 23:24:38 -0000

On Sat, May 02, 2015 at 02:15:28PM -0400, Benjamin Kaduk wrote:
> On Fri, 1 May 2015, Nathaniel McCallum wrote:
> 
> > On Fri, 2015-05-01 at 16:30 -0500, Nico Williams wrote:
> > >
> > > Any OTPs that require continuation then result in this leak.  This
> > > has
> > > to be documented, since avoiding this leak is a core feature of this
> > > protocol.
> >
> > Correct. Is the current warning insufficient? It is my understanding
> > this is spelled out in the security considerations section.
> 
> I think I already mentioned this in my earlier comments, but I think that
> mentioning more prominently in the introduction the goal of not leaking
> which factor was incorrect, with the caveat about continuation messages
> losing this property, would be an improvement to just mentioning it in the
> security considerations.

Agreed, but I also wonder if there might be second factor types where
the AS->client continuations could be sent with no protection and still
be secure.  Consider an OTP resync use case where the client gets asked
to send N more OTPs.  The AS stores N (then N-1, N-2, .., N==1) in the
state cookie, while the client binds all the resync requests (and
response OTPs) into the transcript, so the AS can't be tricked into
taking more OTPs than it needs, and the resync doesn't hurst the client,
leaking nothing to the attacker.  Granted, this analysis has to be done
on a per-second factor type basis.

Perhaps we don't or shouldn't care.  But if this failure cause
indistinguishability feature is critical, then maybe we should care.

Nico
--