Re: [kitten] SPAKE Preauth

[Nathaniel McCallum <[e-mail]>]

On Thu, 2015-04-30 at 11:38 -0500, Nico Williams wrote:
> 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.

Agreed. I'll de-emphasize it in the next edition.

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

Fair enough. My concern was to provide a good introduction to PAKE for
those unfamiliar with it. But if we aren't worried about such, then we
can just list the properties and move on.

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

Glad we're on the same page now. I look forward to your
comments/patches. :)

Nathaniel