[kitten] SPAKE Preauth

classic Classic list List threaded Threaded
37 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[kitten] SPAKE Preauth

Nathaniel McCallum-5
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

Comments welcome!

Nathaniel

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] SPAKE Preauth

Greg Hudson
On 04/27/2015 08:45 AM, 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 think this mechanism has a lot of potential, and I hope the kitten
working group will adopt this document.  There is a lot of work to be
done at the detail level, but I think the general shape of the mechanism
is about right.

I think this mechanism addresses three under-served scenarios:

1. A realm administrators are concerned (or ought to be concerned) about
the potential for offline dictionary attacks conducted by an adversary
using passive network surveillance.  The realm is using only passwords
for user authentication and does not have the resources to deploy a
second factor.  Encrypted timestamps are in use but do not protect
against a network listener.

There are several other ways to address this use case, including FAST.
But SPAKE preauth can be deployed more easily than FAST--perhaps even
turned on by default--and does not require as many changes to other
layers to make deployment easier.

2. A realm is using passwords for user authentication, and the
administrators want to add a traditional OTP second factor (like Yubikey
or RSA tokens) for some or all principals.  FAST-OTP is designed to
replace, rather than augment, the use of Kerberos long-term keys, and is
therefore not easy to apply to this situation.

In this use case, SPAKE preauth is used with a second-factor challenge
in the second pass, and the token value is transmitted inside the key
confirmation.  The KDC issues a ticket if key agreement succeeded and
the token value is valid, and responds with an error if either is wrong.
 If there are no side channels, an attacker can't tell which factor was
guessed incorrectly.

3. Same as (2), but the realm administrators want to add a Duo-style
second factor.  In this style, the password needs to be validated first,
and then the user is presented with a choice of options for the second
factor.  Depending on the choice, there may or may not be an OTP value
presented to the KDC for validation.

In this use case, SPAKE preauth is used without a second-factor
challenge in the second pass, but additional challenge/responses occur
after key agreement.  An attacker does get to make on-line guesses at
the password separately from the second factor, but is unable to cause
nuisance second-factor challenges (such as pushes to the user's mobile
device) without knowledge of the password.

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] SPAKE Preauth

Benjamin Kaduk-2
On Tue, 28 Apr 2015, Greg Hudson wrote:

> On 04/27/2015 08:45 AM, 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 think this mechanism has a lot of potential, and I hope the kitten
> working group will adopt this document.  There is a lot of work to be
> done at the detail level, but I think the general shape of the mechanism
> is about right.

I agree with this assessment, and hope that the document will move forward
through the working group.

> I think this mechanism addresses three under-served scenarios:
>
> 1. A realm administrators are concerned (or ought to be concerned) about
> the potential for offline dictionary attacks conducted by an adversary
> using passive network surveillance.  The realm is using only passwords
> for user authentication and does not have the resources to deploy a
> second factor.  Encrypted timestamps are in use but do not protect
> against a network listener.

I think this point could be emphasized in section 1 -- the current text is
only "offline brute-force attack against the transferred packet", saying
nothing about passwords, let alone weak passwords.

> 2. A realm is using passwords for user authentication, and the
> administrators want to add a traditional OTP second factor (like Yubikey
> or RSA tokens) for some or all principals.  FAST-OTP is designed to
> replace, rather than augment, the use of Kerberos long-term keys, and is
> therefore not easy to apply to this situation.
>
> In this use case, SPAKE preauth is used with a second-factor challenge
> in the second pass, and the token value is transmitted inside the key
> confirmation.  The KDC issues a ticket if key agreement succeeded and
> the token value is valid, and responds with an error if either is wrong.
>  If there are no side channels, an attacker can't tell which factor was
> guessed incorrectly.

"can't tell which factor was guessed incorrectly" seems like a pretty
important property (I would be really excited to see a scheme with this
property get deployed!), but it does not seem to be mentioned in the
current section 1.2 text.  (It does talk about avoiding
ciphertexts^Wpackets which are vulnerable to offline brute-force attack,
but I don't see anything mentioning the online attack as well.)  Hmm, this
is mentioned in the security considerations, at least.  I think it should
be more prominent earlier in the document.

However, it seems like the text at the end of section 4.3 wherein "[i]f
validation of the second factor requires furthe round-trips, the KDC MUST
reply to the client with KDC_ERR_MORE_PREAUTH_DATA_REQUIRED [...]" loses
the indistinguishability property, as the encrypted SPAKESecondFactor
would not be generated if the long-term key (password) was incorrect.
This seems inherent to second factors which require multiple round trips
to validate, though, so maybe we have to make a choice of the tradeoff.

[case 3 trimmed]

Some additional comments:

The current version of 4.3 only allows for one second factor to be used.
Do we want to consider a design which permits multiple additional factors
to be used (maybe, phone and hardware token, or something like that)?

We talked about SPAKE on the MIT kerberos dev call today, and one of the
things mentioned is that the M and N values are specified per group in
draft-irtf-cfrg-spake2 (along with a procedure for selecting them for new
groups); we should explicitly note that their selection (and encoding?) is
delegated to the IRTF document.

Also covered on the MIT dev call, we should go into more detail about the
transcript hash (in a separate subsection?).  Apparently there is also a
discussion to have about the way the transcript includes the full exchange
of messages, i.e., whether it is okay to chain hashes or the full history
must be buffered.

With respect to the recommended groups in section 7, I believe that
interoperability concerns should drive us to pick at least one mandatory
to implement group.  The state of things elsewhere in the IETF and IRTF
seem to be leaning towards non-NIST curves as well; we should probably
consider if the CFRG curve recommendations to the TLS working group are
relevant for this case.

The IANA considerations are not considered complete by current standards;
see BCP 26 (i.e., RFC 5226 at present).  In particular, section 4.2
contains the list of what needs to be in a document which creates a
registry.



Nits:

In 1.2, "attempting to encrypt this data using the long-term password"
implicitly assumes "using authenticated encryption (such as RFC 3961
crypto)", as I understand it.

1.2, second paragraph, first line, comma after "FAST".

Still 1.2, it's "certification authority", not "certificate authority".

Last sentence of 1.2, is "leveraged into" really correct?  I thought that
the long-term key and the 2FA data were mixed into the DHE in the same
way.

In 1.3, first paragraph, penultemate sentence, "indistinguishable from
random" seems like an incomplete clause; maybe "random data" or "random
bits"?

1.3, second paragraph, antepenultimate sentence, in "equivalent security",
as a reader I expect to see what it is equivalent to, i.e., "equivalent
security using standard DH-KE".

In 3.1, I think the text would read more naturally if consolidated into a
single sentence, viz. "a PA-ETYPE-INFO2 element with a single
ETYPE-INFO2-ENTRY containing the etype [...]".

Perhaps 3.3 should cite RFC 6113 for KDC_ERR_MORE_PREAUTH_DATA_REQUIRED.

There are several places where the document indicates only the fields in
KDC-RE{Q,P}s which are specific to SPAKE, with no reference to the other
fields which will be included indicating support for other preauth
schemes, etc..  While this can be a valid style to use, I wonder if some
consideration should be given to some additional text about "in the set of
pre-authentication data in the KRB_ERROR message" for section 4.1, and
similarly elsewhere in the document.

Section 4.3 should forward-reference section 5.1 for key derivation.

In section 4.3, second paragraph, us a comma instead of a semicolon to
prefix "possibly using the challenge data for this second factor type",
since that is a dependent clause.

We should probably be a little more explicit about what key, usage, etc.
are going on for the EncryptedData encrypted/checksummed with the session
key derived from the SPAKE key; we covered this a little bit on the MIT
dev call today as well.

In 4.4, "second factor type specific" is a bit awkward; maybe "specific to
each type of second factor"?

In section 8, the integrity confirmation of the transcript messages occurs
when the SPAKEResponse is processed and validated, not when it is
transmitted, I think -- the KDC is the second party to compute the
transcript/key derivation, and the verification that the two parties'
transcripts agree occurs when the KDC compares its local copy to the one
it got from the network.


-Ben

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] SPAKE Preauth

Nico Williams
In reply to this post by Nathaniel McCallum-5
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
--

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] SPAKE Preauth

Nathaniel McCallum-5
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
[hidden email]" 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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] SPAKE Preauth

Greg Hudson
On 04/30/2015 09:49 AM, Nathaniel McCallum wrote:

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

Hm, I would give a more nuanced description:

In a normal scenario, the client can get the KDC's timestamp from the
PREAUTH_REQUIRED error.  This timestamp is unauthenticated, so using it
pretty much defeats any freshness value the timestamp might add to the
preauthentication protocol.  Since there isn't much freshness value in
that timestamp (an active or passive attacker immediately gets a
ciphertext with which to conduct offline password dictionary attacks,
rendering password lockout moot), the MIT krb5 client does use that
timestamp for encrypted preauth, and no extra messages are sent even if
the client's clock is off.

When authenticating with a keytab, a client might choose to use
optimistic encrypted timestamp preauth to indicate which key the client
possesses.  (The MIT krb5 client does not do this, and the MIT krb5 KDC
does not use the result for key selection.  The latter should definitely
change and the former might change.)  If this is done, clock skew could
force a second exchange.

I also thought it was weird to lead with timestamp issues in the draft.
 I'm not sure I would mention them all in section 1.

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

This is partly true.  Unauthenticated anonymous PKINIT plus encrypted
challenge would carry some of the advantages of SPAKE preauth.  But
there are a lot of missing pieces for clients without keytabs:

* The MIT krb5 client only supports KDC-authenticated anonymous PKINIT
at this time.  That could change, but it would carry risks by
complicating the client security model (e.g. we need to make sure not to
do FAST OTP over the resulting channel).

* The get_in_tkt stack would need to be augmented to try anonymous
PKINIT FAST automatically.  At the moment the user (or other external
machinery) has to manually obtain anonymous tickets and then use those
as armor.

* Administrators have to turn on anonymous PKINIT; it's not on by
default.  To turn it on you have to generate a KDC certificate, even if
the client won't verify it.

* Anonymous PKINIT in MIT krb5 is slow right now because it only
supports integer DH.  It also increases the attack surface on the KDC
significantly, because PKINIT is so complicated.

Other implementations are in different states (e.g. Heimdal has
supported ECDH PKINIT for many years), but I think have most of the same
those missing pieces and some additional ones as well.

SPAKE preauth doesn't currently exist, which is also a big missing
piece.  The advantages are that:

1. It's just a preauth mech.  It provides all of its advantages without
requiring any difficult changes to other parts of the stack.  (It does
require some non-difficult changes discussed in RFC 6113: supplying a
single ETYPE-INFO2 value, cookie support within the KDC preauth
framework, and MORE_PREAUTH_DATA_NEEDED support in the client and KDC.)
 If it performs well enough, it could become available and used by
default, supplanting encrypted timestamp.

2. It supports second factor features which aren't currently supported
by any standard.

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

Agreed.  RFC 6113 states that "Mechanism designers should design FAST
factors, instead of new pre-authentication mechanisms outside of FAST."
 We are going against that advice, and need to justify why.

(Of course nothing prevents SPAKE from being used as a FAST factor, and
it builds on RFC 6113 features.)

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] SPAKE Preauth

Nathaniel McCallum-5
In reply to this post by Nathaniel McCallum-5
On Mon, 2015-04-27 at 08:45 -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
>
> Comments welcome!

After getting many great comments from everyone, I decided to setup a
git repo to track my changes. Pull requests are welcome!

https://github.com/npmccallum/ietf

Nathaniel

PS - This also include the other drafts I have recently published.
Pull requests are welcome on these as well.

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] SPAKE Preauth

Nico Williams
In reply to this post by Nathaniel McCallum-5
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
--

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] SPAKE Preauth

Nathaniel McCallum-5
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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] SPAKE Preauth

Nico Williams
In reply to this post by Benjamin Kaduk-2
On Tue, Apr 28, 2015 at 05:53:01PM -0400, Benjamin Kaduk wrote:

> "can't tell which factor was guessed incorrectly" seems like a pretty
> important property (I would be really excited to see a scheme with this
> property get deployed!), but it does not seem to be mentioned in the
> current section 1.2 text.  (It does talk about avoiding
> ciphertexts^Wpackets which are vulnerable to offline brute-force attack,
> but I don't see anything mentioning the online attack as well.)  Hmm, this
> is mentioned in the security considerations, at least.  I think it should
> be more prominent earlier in the document.
>
> However, it seems like the text at the end of section 4.3 wherein "[i]f
> validation of the second factor requires furthe round-trips, the KDC MUST
> reply to the client with KDC_ERR_MORE_PREAUTH_DATA_REQUIRED [...]" loses
> the indistinguishability property, as the encrypted SPAKESecondFactor
> would not be generated if the long-term key (password) was incorrect.
> This seems inherent to second factors which require multiple round trips
> to validate, though, so maybe we have to make a choice of the tradeoff.

Yes.  And 4.4 makes it worse because continued 2nd factor exchanges use
EncryptedData, including from the AS to the client (which can then
confirm that its choice of password guess was incorrect).

The fix for this is to send AS->client 2nd factor continuations in the
clear if at all possible.  Which means that in the AS->client 3rd and
subsequent passes we need a CHOICE of OCTET STRING or EncryptedData, or
perhaps allow the use of the null enctype in the AS->client 2nd factor
EncryptedData.

The AS will know as soon as it tries to decrypt the client's 2nd factor
(whose EncryptedData functions as a proof of possession) that the client
doesn't know the password.  In this case the AS should continue and
process _a_ 2nd factor as much as possible as if the password was right.
The AS could do this by arranging to have a special user account (so as
not to lock out the real user) for testing bogus second factors, and
using a random or constant 2nd factor for this.

Nico
--

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] SPAKE Preauth

Nathaniel McCallum-5
On Fri, 2015-05-01 at 16:15 -0500, Nico Williams wrote:

> On Tue, Apr 28, 2015 at 05:53:01PM -0400, Benjamin Kaduk wrote:
> > "can't tell which factor was guessed incorrectly" seems like a
> > pretty
> > important property (I would be really excited to see a scheme with
> > this
> > property get deployed!), but it does not seem to be mentioned in
> > the
> > current section 1.2 text.  (It does talk about avoiding
> > ciphertexts^Wpackets which are vulnerable to offline brute-force
> > attack,
> > but I don't see anything mentioning the online attack as well.)
> >  Hmm, this
> > is mentioned in the security considerations, at least.  I think it
> > should
> > be more prominent earlier in the document.
> >
> > However, it seems like the text at the end of section 4.3 wherein
> > "[i]f
> > validation of the second factor requires furthe round-trips, the
> > KDC MUST
> > reply to the client with KDC_ERR_MORE_PREAUTH_DATA_REQUIRED [...]"
> > loses
> > the indistinguishability property, as the encrypted
> > SPAKESecondFactor
> > would not be generated if the long-term key (password) was
> > incorrect.
> > This seems inherent to second factors which require multiple round
> > trips
> > to validate, though, so maybe we have to make a choice of the
> > tradeoff.
>
> Yes.  And 4.4 makes it worse because continued 2nd factor exchanges
> use
> EncryptedData, including from the AS to the client (which can then
> confirm that its choice of password guess was incorrect).
>
> The fix for this is to send AS->client 2nd factor continuations in
> the
> clear if at all possible.  Which means that in the AS->client 3rd and
> subsequent passes we need a CHOICE of OCTET STRING or EncryptedData,
> or
> perhaps allow the use of the null enctype in the AS->client 2nd
> factor
> EncryptedData.
>
> The AS will know as soon as it tries to decrypt the client's 2nd
> factor
> (whose EncryptedData functions as a proof of possession) that the
> client
> doesn't know the password.  In this case the AS should continue and
> process _a_ 2nd factor as much as possible as if the password was
> right.
> The AS could do this by arranging to have a special user account (so
> as
> not to lock out the real user) for testing bogus second factors, and
> using a random or constant 2nd factor for this.

I think this is overkill. Most continuations will have already
validated some aspect of the second factor. For instance, in HOTP/TOTP
continuations are used for synchronization of the token after the
validation of the initial token code.

Nathaniel

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] SPAKE Preauth

Nico Williams
In reply to this post by Nathaniel McCallum-5

There should be a generic OTP 2nd factor type for user-input OTPs.

There should also be a generic OTP 2nd factor for plug-in/NFC-type OTPs.

For a generic OTP 2nd factor for user-input OTPs the 'data' in the
AS->client second pass should be a UTF8String, or just UTF-8.

It's important to define such generic OTP 2nd factors because they are
quite popular.

Nico
--

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] SPAKE Preauth

Nico Williams
In reply to this post by Nathaniel McCallum-5
On Fri, May 01, 2015 at 05:18:58PM -0400, Nathaniel McCallum wrote:

> On Fri, 2015-05-01 at 16:15 -0500, Nico Williams wrote:
> > Yes.  And 4.4 makes it worse because continued 2nd factor exchanges
> > use EncryptedData, including from the AS to the client (which can
> > then confirm that its choice of password guess was incorrect).
> >
> > The fix for this is to send AS->client 2nd factor continuations in
> > the clear if at all possible.  Which means that in the AS->client
> > 3rd and subsequent passes we need a CHOICE of OCTET STRING or
> > EncryptedData, or perhaps allow the use of the null enctype in the
> > AS->client 2nd factor EncryptedData.
> >
> > The AS will know as soon as it tries to decrypt the client's 2nd
> > factor (whose EncryptedData functions as a proof of possession) that
> > the client doesn't know the password.  In this case the AS should
> > continue and process _a_ 2nd factor as much as possible as if the
> > password was right.  The AS could do this by arranging to have a
> > special user account (so as not to lock out the real user) for
> > testing bogus second factors, and using a random or constant 2nd
> > factor for this.
>
> I think this is overkill. Most continuations will have already
> validated some aspect of the second factor. For instance, in HOTP/TOTP
> continuations are used for synchronization of the token after the
> validation of the initial token code.

It doesn't seem like overkill to me.  Unless the property that an
attacker can't distinguish which factor was wrong is not that important.

Note that AS implementations could just always send continuations as
EncryptedData, leaking that way.  What I want is for it to be possible
to implement an AS that doesn't leak.

Nico
--

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] SPAKE Preauth

Nathaniel McCallum-5
In reply to this post by Nico Williams
On Fri, 2015-05-01 at 16:20 -0500, Nico Williams wrote:

> There should be a generic OTP 2nd factor type for user-input OTPs.
>
> There should also be a generic OTP 2nd factor for plug-in/NFC-type
> OTPs.
>
> For a generic OTP 2nd factor for user-input OTPs the 'data' in the
> AS->client second pass should be a UTF8String, or just UTF-8.
>
> It's important to define such generic OTP 2nd factors because they
> are
> quite popular.

I plan to create separate standards for OATH and U2F.

Nathaniel

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] SPAKE Preauth

Nathaniel McCallum-5
In reply to this post by Nico Williams
On Fri, 2015-05-01 at 16:23 -0500, Nico Williams wrote:

> On Fri, May 01, 2015 at 05:18:58PM -0400, Nathaniel McCallum wrote:
> > On Fri, 2015-05-01 at 16:15 -0500, Nico Williams wrote:
> > > Yes.  And 4.4 makes it worse because continued 2nd factor
> > > exchanges
> > > use EncryptedData, including from the AS to the client (which can
> > > then confirm that its choice of password guess was incorrect).
> > >
> > > The fix for this is to send AS->client 2nd factor continuations
> > > in
> > > the clear if at all possible.  Which means that in the AS->client
> > > 3rd and subsequent passes we need a CHOICE of OCTET STRING or
> > > EncryptedData, or perhaps allow the use of the null enctype in
> > > the
> > > AS->client 2nd factor EncryptedData.
> > >
> > > The AS will know as soon as it tries to decrypt the client's 2nd
> > > factor (whose EncryptedData functions as a proof of possession)
> > > that
> > > the client doesn't know the password.  In this case the AS should
> > > continue and process _a_ 2nd factor as much as possible as if the
> > > password was right.  The AS could do this by arranging to have a
> > > special user account (so as not to lock out the real user) for
> > > testing bogus second factors, and using a random or constant 2nd
> > > factor for this.
> >
> > I think this is overkill. Most continuations will have already
> > validated some aspect of the second factor. For instance, in
> > HOTP/TOTP
> > continuations are used for synchronization of the token after the
> > validation of the initial token code.
>
> It doesn't seem like overkill to me.  Unless the property that an
> attacker can't distinguish which factor was wrong is not that
> important.
>
> Note that AS implementations could just always send continuations as
> EncryptedData, leaking that way.  What I want is for it to be
> possible
> to implement an AS that doesn't leak.

I don't think that is possible. The cost for sending data in the clear
to avoid leaking EncryptedData is the loss of integrity protection.

Nathaniel

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] SPAKE Preauth

Nico Williams
On Fri, May 01, 2015 at 05:27:03PM -0400, Nathaniel McCallum wrote:

> On Fri, 2015-05-01 at 16:23 -0500, Nico Williams wrote:
> > It doesn't seem like overkill to me.  Unless the property that an
> > attacker can't distinguish which factor was wrong is not that
> > important.
> >
> > Note that AS implementations could just always send continuations as
> > EncryptedData, leaking that way.  What I want is for it to be
> > possible to implement an AS that doesn't leak.
>
> I don't think that is possible. The cost for sending data in the clear
> to avoid leaking EncryptedData is the loss of integrity protection.

Any OTPs that require continuation then result in this leak.  This has
to be documented, since avoiding this leak is a core feature of this
protocol.

Nico
--

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] SPAKE Preauth

Nathaniel McCallum-5
On Fri, 2015-05-01 at 16:30 -0500, Nico Williams wrote:

> On Fri, May 01, 2015 at 05:27:03PM -0400, Nathaniel McCallum wrote:
> > On Fri, 2015-05-01 at 16:23 -0500, Nico Williams wrote:
> > > It doesn't seem like overkill to me.  Unless the property that an
> > > attacker can't distinguish which factor was wrong is not that
> > > important.
> > >
> > > Note that AS implementations could just always send
> > > continuations as
> > > EncryptedData, leaking that way.  What I want is for it to be
> > > possible to implement an AS that doesn't leak.
> >
> > I don't think that is possible. The cost for sending data in the
> > clear
> > to avoid leaking EncryptedData is the loss of integrity protection.
>
> Any OTPs that require continuation then result in this leak.  This
> has
> to be documented, since avoiding this leak is a core feature of this
> protocol.

Correct. Is the current warning insufficient? It is my understanding
this is spelled out in the security considerations section.

Nathaniel

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] SPAKE Preauth

Nico Williams
In reply to this post by Nathaniel McCallum-5
On Fri, May 01, 2015 at 05:24:04PM -0400, Nathaniel McCallum wrote:

> On Fri, 2015-05-01 at 16:20 -0500, Nico Williams wrote:
> > There should be a generic OTP 2nd factor type for user-input OTPs.
> >
> > There should also be a generic OTP 2nd factor for plug-in/NFC-type
> > OTPs.
> >
> > For a generic OTP 2nd factor for user-input OTPs the 'data' in the
> > AS->client second pass should be a UTF8String, or just UTF-8.
> >
> > It's important to define such generic OTP 2nd factors because they
> > are
> > quite popular.
>
> I plan to create separate standards for OATH and U2F.

Is there any reason that a generic one couldn't be specified here?

Nico
--

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] SPAKE Preauth

Nathaniel McCallum-5
On Fri, 2015-05-01 at 17:22 -0500, Nico Williams wrote:

> On Fri, May 01, 2015 at 05:24:04PM -0400, Nathaniel McCallum wrote:
> > On Fri, 2015-05-01 at 16:20 -0500, Nico Williams wrote:
> > > There should be a generic OTP 2nd factor type for user-input
> > > OTPs.
> > >
> > > There should also be a generic OTP 2nd factor for plug-in/NFC
> > > -type
> > > OTPs.
> > >
> > > For a generic OTP 2nd factor for user-input OTPs the 'data' in
> > > the
> > > AS->client second pass should be a UTF8String, or just UTF-8.
> > >
> > > It's important to define such generic OTP 2nd factors because
> > > they
> > > are
> > > quite popular.
> >
> > I plan to create separate standards for OATH and U2F.
>
> Is there any reason that a generic one couldn't be specified here?

Speaking for myself, I want to create a high-quality integrated
experience, not a generic one. I would prefer picking one open
standard (such as OATH) and getting the details right. This is
somewhat hard for me to quantify, but it arises from my experience
implementing RFC 6560.

Nathaniel

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] SPAKE Preauth

Ken Hornstein-2
>Speaking for myself, I want to create a high-quality integrated
>experience, not a generic one. I would prefer picking one open
>standard (such as OATH) and getting the details right. This is
>somewhat hard for me to quantify, but it arises from my experience
>implementing RFC 6560.

So ... I hate to ask this, but does this mean KITTEN is coming around
to officially deciding that OTP in Kerberos should _not_ use FAST?  I
will fully admit that I've been out of the Kerberos game for a while,
but seeing Nathan's description of the challenges with deploying FAST
makes me realize that I'd run into the exact same problems ... and that
makes me think that a FAST-based OTP would probably be very challenging
if you had a diverse Kerberos deployment.  And I simply wouldn't bother
deploying both FAST and SPAKE; I'd just pick one to make things easier.

--Ken

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
12