Re: [kitten] SPAKE Preauth

[Benjamin Kaduk <[e-mail]>]

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