Re: [kitten] SPAKE Preauth

[Nathaniel McCallum <[e-mail]>]

Thanks for your feedback!

On Wed, 2015-04-29 at 11:17 -0500, Nico Williams wrote:
> 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).

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.

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

Agreed.

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

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

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

1. Use the existing system trust anchor w/ anonymous pkinit. This has
all the problems that web developers are already trying to solve. For
instance, if we trusted Verisign, someone could setup
efdoraproject.org and configure the KDC for OTP. Anyone who did "kinit
[e-mail]" by mistake would leak both the first and
second factor to a completely trusted but malicious KDC.

2. Ask volunteers to trust our KDC cert explicitly. Then have them do 
a manual anonymous pkinit. Then have them use this ccache for enabling
FAST. This is error prone and requires manual configuration. It is a
no go.

In contrast, PAKE allows a completely configless usage with no third
-party trust and no leap of faith.

Perhaps I have simply not captured this concern well in the draft. But
it is most definitely more than "we don't have FAST everywhere."

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

Nowhere did I claim that PAKE obsoletes FAST. I said: "In the past,
this problem (2FA) has been mitigated by FAST which uses a secondary
trust relationship to create a secure encryption channel within which
pre-authentication data can be sent.  However, the requirement for a
secondary trust relationship has proven to be cumbersome to deploy and
often introduces third parties into the trust chain (such as
certificate authorities)."

Both of these statements are true and represent true complexities of
FAST that do not exist with PAKE.

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

I do think this document needs to justify why we just shouldn't use
FAST like how RFC 6560 does. This draft represents a departure from
the recently established precedent of second factors. The reason why
this departure is necessary is because of the above reasons.

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

I'm not addressing all pre-auth types. I'm addressing why we should
depart from recent precedent in RFC 6560.

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

I agree. I just don't think these claims are controversial.

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

Thanks! I look forward to your feedback!

Nathaniel