Re: [kitten] SPAKE Preauth

[Nico Williams <[e-mail]>]

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:
> http://www.ietf.org/id/draft-mccallum-kitten-krb-spake-preauth-00.txt

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

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

Nico
--