Re: [kitten] SPAKE Preauth

Nico Williams <nico@cryptonector.com> Thu, 30 April 2015 16:38 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 70F221AC3FC for <kitten@ietfa.amsl.com>; Thu, 30 Apr 2015 09:38:25 -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 N5dJQFCT8OQO for <kitten@ietfa.amsl.com>; Thu, 30 Apr 2015 09:38:24 -0700 (PDT)
Received: from homiemail-a77.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 76C1A1AC3F8 for <kitten@ietf.org>; Thu, 30 Apr 2015 09:38:24 -0700 (PDT)
Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id A5DA994079; Thu, 30 Apr 2015 09:38:23 -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=bVP4fQy5Pebs5s akDu+MCo/agHY=; b=r5VCOO8QFrqWUnyCFCmceqlbRrZqw2VwvBWwnF35kMTPTv 1P261PnY77ND3n7nktx1Ec62RG3ph4vy3sNkvoOFRXE73Ktf+Z0VRi0uQwQJRaHo TJbBr6p9JXac0H8hAuqJ2RAGVgGhEswSjvYpms3+ptG5vc8e0bLF89Eoi0Lfo=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPA id 52A189406D; Thu, 30 Apr 2015 09:38:21 -0700 (PDT)
Date: Thu, 30 Apr 2015 11:38:19 -0500
From: Nico Williams <nico@cryptonector.com>
To: Nathaniel McCallum <npmccallum@redhat.com>
Message-ID: <20150430163818.GB6026@localhost>
References: <1430138754.2682.10.camel@redhat.com> <20150429161716.GH6026@localhost> <1430401789.5004.21.camel@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1430401789.5004.21.camel@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/EiaHfignEpuB8s4acr9c7Vd-vkA>
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: Thu, 30 Apr 2015 16:38:25 -0000

On Thu, Apr 30, 2015 at 09:49:49AM -0400, Nathaniel McCallum wrote:
> On Wed, 2015-04-29 at 11:17 -0500, Nico Williams wrote:
> 
> As I stated in the draft: "where a timestamp is used, time
> synchronization between the client and KDC becomes a point of
> fragility." I think your paragraph here proves this point. Where
> synchronization is off, extra messages are sent. I think this
> qualifies as fragility.

Extra round trips != fragility.  Fragility -> sometimes clients fail.

In this case the extra round trips are merely sub-optimal behavior that
users mostly don't notice, and which is greatly amortized anyways.

Clients can sometimes fail, but only if they don't implement clock skew
correction based on the timestamps in KRB-ERROR PDUs.  Implementation
issues don't really count for this argument unless implementation is
particularly difficult, which it's not.

> >    IMO the time sync aspects of this are a bit overdone :)
> 
> Maybe. I'll see if I can come up with wording you like better. I still
> think it is worth mentioning however.

But it's not really a motivating factor for this work, is it?  It's just
icing on the cake.

> >  - Section 1.1 is a bit weak.  I don't think it's even necessary to
> >    explain PAKE in terms of DH key agreement either.
> > 
> >    The properties of a PAKE are:
> > 
> >     - provides authenticated key agreement with both parties
> >       contributing entropy to the shared secret;
> > 
> >       (And each exchange yields a different shared secret.)
> > 
> >     - is resistant to off-line dictionary attacks by eavesdroppers, 
> > even
> >       for small, simple passwordsj
> > 
> >     - "servers" store password equivalents;
> > 
> >       (In an augmented PAKE the server stores a verifier, but you're 
> > not
> >       proposing the use of an augmented PAKE.)
> > 
> >     - users "store" passwords.
> 
> The intent of this section is to explain PAKE to those unfamiliar with
> it. If such is not needed in this document, I can remove it.

To me it reads like an explanation by the author to a younger version of
the author :)  Especially given the focus on DH.  One can construct key
agreement protocols with PFS using RSA instead of DH, so the focus on DH
strikes me as accidental rather than fundamental.  (Heck, I think I can
construct EKE-like ZKPPs out of RSA as well.)

I'd rather that the properties of a PAKE be listed and references to DH
be left out in this section.

> >  - Section 1.2, the claim about why FAST is difficult to deploy 
> > requires
> >    more evidence, and I believe it's wrong.  The problem with FAST is
> >    that it's difficult to make it a requirement for PA-ENC-TIMESTAMP
> >    because FAST is not universally available yet -- the tragedy of
> >    legacy forever.  Sure, one has to deploy trust anchors, but then
> >    again, one doesn't have to (leap of faith), and one can (for 
> > machines
> >    that have "joined" a realm or hierarchy of realms).
> 
> Well, that is not Red Hat's experience. We have FAST everywhere, but
> we have people who don't want us to configure their client. This is
> most especially true in open communities like Fedora where we are
> working with volunteers.
> 
> In these cases we have two options:
> [...]
> In contrast, PAKE allows a completely configless usage with no third
> -party trust and no leap of faith.

OK, this is what I was looking for, thanks.

Nico
--