Re: [kitten] SPAKE Preauth

Nico Williams <> Wed, 29 April 2015 16:17 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7D9871A6FCB for <>; Wed, 29 Apr 2015 09:17:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.233
X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4nSElmCDGv6z for <>; Wed, 29 Apr 2015 09:17:23 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 34DB61A1BCF for <>; Wed, 29 Apr 2015 09:17:23 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id C26F8286080; Wed, 29 Apr 2015 09:17:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to;; bh=gs4pETf6kiGrF5 C6W0CDM7SWK1c=; b=OOkYVZIp7G9oU25jaz4qqZ2/sQwJ6Ag1et9QzFTVuHU098 UVNSxcWPn03WWJPMYHgmBD74Rd26S1IQT6C0C8WyrfF4K7zFHZmg9DrqCghuVLl8 XFaUgsTlc/EKjoD2xO6lZDYjGCyQyNYI0y2tLYXTwIKNw6vvF4B5Z6xpXJ44E=
Received: from localhost ( []) (Authenticated sender: by (Postfix) with ESMTPA id B7EFF286055; Wed, 29 Apr 2015 09:17:21 -0700 (PDT)
Date: Wed, 29 Apr 2015 11:17:19 -0500
From: Nico Williams <>
To: Nathaniel McCallum <>
Message-ID: <20150429161716.GH6026@localhost>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <>
Cc: "" <>
Subject: Re: [kitten] SPAKE Preauth
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 29 Apr 2015 16:17:24 -0000

On Mon, Apr 27, 2015 at 08:45:54AM -0400, Nathaniel McCallum wrote:
> I have finally finished the first edition of SPAKE Preauth. You can
> read it at this link:

I'm in favor of the WG adopting this as a WG work item.

I have some comments:

 - Kerberos doesn't really depend on synchronization of client clocks
   for any of the KDC exchanges (AS, TGS): because they are stateless
   and retriable, and the client learns the KDC's time in KRB-ERROR

   Pre-auth methods that don't depend on the client's clock are mostly
   an optimization.  They are less of an optimization when failures
   count towards locking a principal, but still an optimization (since
   one can account for clock skew by adding one to N-strikes-you're- 
   locked policies).

   Time synchronization across services in a realm is not something that
   is being fixed here either.

   IMO the time sync aspects of this are a bit overdone :)

 - 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.

 - 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).

   Either elaborate this claim, or leave it at "it's difficult to
   deploy".  This claim just isn't all that important to this work:
   after all, the key is the ability to combine a PAKE and a second
   factor in a way that leaks no information about which factor was
   incorrect when either (or both) were.  FAST doesn't help with that.
   Even more interesting properties can be dreamed up that FAST simply
   can't help with either.

   On the other hand, FAST is still relevant: for providing
   confidentiality protection of the client's principal name.

   There's just no need to justify this or any other pre-auth method
   based on FAST's real or perceived failure.

   Indeed, all new pre-auth methods might well (will!) suffer from some
   of the same barriers to adoption that I think FAST suffers from, and
   then what?  Should we stop designing new pre-auth methods?  No.

Controversial claims that are not core to the document should just go.

That's as far as I got reading the I-D so far.  I've reviewed the design
before and I approve, and I'll complete my review of the I-D at some