Subject: [kitten] review of draft-ietf-kitten-krb-spake-preauth-00

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 18 Aug 2017 13:10:43 -0500

Hi all,

With no hats.

Big-picture questions:

Our transcript hash covers just the SPAKE negotiation messages (and
excludes the rest of the AS-REQ/AS-REP bodies, even the SPAKE second
factor messages as well?!), though the final KDC-REQ-BODY does get
included in the key derivation.  I haven't thought too hard about
whether this is potentially problematic, but are there reasons why
it would be difficult to hash everything for the transcript?
Oh, or is the claim that since the KDC-REQ-BODY goes into the K'
calculation that we get confirmation of "everything" anyway?

We do reply key strengthening with K'[0] at present.  It seems like
using K'[last-n-of-proper-parity] would include more transcript
checksum and thus nominally be "better"; is that flawed reasoning?

We should have test vectors before final publication.

I'm not sure that the registry policies make sense, most notably
with respect to marking things as Required (to implement).  That
would seem to be effectively updating this document, and as such
require standards action.  In a weaker sense, anything adding values
in these registries could be seen as adding to the ASN.1 module, but
since it does so in a way that is clearly intended to be extensible
this seems less problematic to me.

Do we want to add padding to any of the ASN.1 structures to provide
a way to limit side channels, or leave that to the specifications of
individual factors?

General review comments:

In section 1.1, item (4) (either side can store password or equivalent)
makes it sound like only one side needs to store anything.  Maybe it's
supposed to say that "Each side has freedom to pick whether to store
a password or password-equivalent"?

I'll also note that OpenSSL has recently changed its documentation to
refer to the more-vague "randomness" since it can be hard to use "entropy"
in a technically correct way.  But that decision seems to fall squarely
within editorial discretion, even if I had a strong opinion about it
(which I don't).

I wonder to some extent whether all of section 1.2 is needed for a final
document.  Perhaps a shorter statement noting that there are multiple
different PAKEs available, DH-EKE's requirement for indistinguishable-from-random
keys makes it unsuitable, and JPAKE is less preferred due to the extra
round trip and server computation would suffice, before launching into
the description of the actual PAKE being used.

Section 1.2 should probably compare the single-round-trip nature of
SPAKE against the round-trip count of ENC_TIMESTAMP.

Section 1.3 notes that we allow secure transfer of material from client
to KDC for verification; while reviewing I noted that (the initial
challenge) from KDC to client remains unauthenticated; do we want to
mention that limitation explicitly here?

The last paragraph of section 1.4 left me a little puzzled, possibly
just because of the word "also".  It seems like we're mostly just
justifying the scheme here, using a parallel to the normal RFC3961
key derivation, as well as a (not-very-clear) reference to the key
derivation scheme used in the original SPAKE2 draft which is where
the term "K'" originates.  So, I think this could be reworded some,
assuming I am understanding it properly.
(We could also call out that this derivation is step (3) of the list.)

In section 3.1, should we give a RFC+section reference for the
"initail KDC preauthentication state" we are relying on?

I thought a little bit about proposing to exclude the ASN.1 extension
marker from PA-SPAKE, but the argument for doing so is fairly weak
and it doesn't really have a downside, so I guess it should stay.
(We could perhaps be clear that an "empty" value is a zero-length
OCTET STRING.)

Section 4.1 seems like it could be read as saying that the client
should send an AS-REQ with no PA-DATA, and then the KDC responds with
a KRB-ERROR and only the PA-SPAKE METHOD-DATA (and no others), so that
a clilent that doesn't support SPAKE is stuck.  We should probably
clarify that METHOD-DATA is expected to contain other things, too.
We could also justify the SHOULD with a claim that this preauth
scheme is currently believed to be the best/strongest one that is
possible when passwords are used.  (PKINIT could be argued to be stronger;
is there anything else for which we could make that claim?)

Section 4.2 lets ("MAY") the KDC pick a group not listed by the client;
do we ever expect this to result in a working connection?

In section 4.6, a forward reference to section 6 when mentioning the
transcript hash could be helpful.

At the end of section 5 we prevent certain reuse of x and y values;
it might be nice if the security considerations were subsectioned
so that this could have a forward reference to the justification for
this restriction.

I would consider moving the note that the PRF+ used here is the
RFC6113 one earlier, perhaps even to the introduction if not the
start of section 7 where we talk about "PRF+ input".

Should section 8 note that the value 0 is reserved?

Section 9 fourth paragraph could perhaps say a bit more about why
the client cannot be a signing oracle.

Also in section 9, now on page 14, second paragraph, I'm not
entirely sure what is at risk of compromise, which also leaves me
confused as to whether the "non-" part of "non-negligible" is
correct.

Just below, for the paragraph after the list of forbidden checksum
types, we talk of the EncryptedData messages having potential side
channels.  It seems that this may apply to both the encdata arm of
the PA-SPAKE CHOICE and the SpakeResponse factor; should we make
this more explicti?

The next paragraph talks of an attacker being able to replay the
final message to any of the realm's KDCs, but does not comment
on whether multiple replays are possible at a given KDC.  (As I
understand it, MIT's lookaside cache would be expected to trigger
and not incur additional authentication being logged, but I don't
know that that's universal.)

In section 11, I think you're not supposed to mention a list that
doesn't exist yet, at least without asking for a list to be created
and suggesting a name.  While here, "end of the review" could get
"period" after it, and "the list" could be expanded out as to the
review list or kitten or other, as well as clarifying the expected
membership of the review list (i.e., public or just the experts).
Also, the URI or unique identifier should probably specifically be
stable as well.

The ASN.1 module includes an OID for spake; is that officially
assigned?

Some nits appear below.

Thanks,

Ben

Nits:

In the abstract, "secure second factor" is really vague about what the
"secure" means.  Perhaps it's best to just drop it, or otherwise clarify.

The wording of Section 1 could probably be tightened up some -- "this
method" (PA-ENC-TIMESTAMP) is not the only thing vulnerable to passive
brute-forcing, what the passive attacker needs to see can be clarified, and
we could emphasize that the offline attacks require comparatively modest
effort (in the face of weak passwords):

When a client uses PA-ENC-TIMESTAMP (or similar schemes, or the KDC
does not require preauthentication), a passive attacker that observes
either the AS-REQ or AS-REP can perform an offline brute-force attack
against the transferred ciphertext.  When the client principal's long-term
key is based on a password, especially a weak password, offline dictionary
attacks can successfuly recover the key, with only modest effort needed
in the case of a weak password.

In section 1.2, we say "markedly smaller key sizes with equiavlent security
to a finite-field Diffie-Hellman key exchange", which is somewhat awkward.
It might be better to say something like ", which is believed to provide
equivalent security levels as finite-field DH key exchange at much smaller
key sizes".

In section 1.3, first sentence, we talk about being "coupled with" 2FA.
But PAKE is one of the two factors, so it's probably better to say
"part of 2FA" or "along with additional authentication factor(s).

Section 1.3, second paragraph says that protectiong the OTP ("second")
factor "has been mitigated" via FAST; I might consider using a less
complex verb tense like "is" or "was".  Later in the same paragraph, maybe
s/instead/in contrast/, and specify that the key exchange is an
asymmetric one, since we do a lot of symmetric key exchange in Kerberos.

In section 2, when mentioning ASN.1 and DER, please add ", respectively"
to bind the term to the document in question.

In section 4, first pargaraph, please note that the indicated facilities
are FAST facilities.

The first paragraph/sentence of section 5 is rather ungainly; could
it be reworded and/or split in twain?

Also in section 5, I'd consider adding an "as" before "defined" in
item 1 and before "a big-endian" in item 2.  Item 2 should probably
also clarify that there is no trailing 0 included.

The phrase "registry created by this document" could change to
"registry (created by this document)" in multiple places.  But maybe
we should just leave that to the RFC Editor's stylebook.

In section 6, the initial transcript checksum is said to contain
"all zero values"; would something like "the initial value consists
of of all bits set to zero" be better?

Page 15, second-to-last paragraph, "is weaker than the secret key"
could include a secret key derived from a weak password, whose
brute-force resistance is quite low (and part of the justification
for this behavior).  It's probably better to talk about the key size
of the secret key and the strength attributed to keys of that size,
than just the strength of the key itself.

---

From: Greg Hudson <[email-masked]>
Date: Sat, 19 Aug 2017 14:17:44 -0400

> calculation that we get confirmation of "everything" anyway?

The transcript checksum is a vehicle for key derivation.  The primary
requirement for key derivation (from the SPAKE2 algorithm) is that it
must take into account the identities of both parties, both public
values, the initial secret, and the computed shared group element.  The
final KDC-REQ-BODY gives us the party identities (with the ancillary
bonus of including other request parameters), and the transcript
checksum includes the public values (with the ancillary bonus of
including the advertised group numbers from the client if a SPAKESupport
message was part of the exchange, in case there was a downgrade attack).

Things we could include in the transcript checksum but currently do not
include:

* Other pa-data values in the request.  Including these would be
difficult to implement, and would present a chicken-and-egg problem if
other pa-data types want to do the same thing.

* KDC-REQ-BODY encodings other than the final one.  I don't see a
problem with including these in the transcript hash, but I don't see an
advantage either.

* More parts of intermediate KRB-ERRORs than the SPAKE pa-data.  The
only part of an intermediate KRB-ERROR used by the client is the error
code (PREAUTH_REQUIRED or MORE_PREAUTH_DATA_REQUIRED), and I don't see
any wiggle room for the attacker in manipulating that.

* Second-factor messages.  In the current design, the same transcript
checksum is used for all K'[n] derivations, and the first derivation is
used to encrypt the first SPAKESecondFactor, before any other
second-factor messages are created.  Changing the design to include a
variable transcript hash would, I think, make the standard harder to
understand and implement.

* Parts of the AS-REP.  No SPAKE message accompanies the AS-REP, so this
could only be used for the derivation of the final reply key used to
encrypt the enc-part.  As for the previous bullet, including any part of
the AS-REP would require changing the transcript checksum for different
key derivations.  Most of the AS-REP contents (everything but the
ticket) are redundant or couldn't be included in the derivation for one
reason or another anyway.

> checksum and thus nominally be "better"; is that flawed reasoning?

As noted above, the transcript checksum does not depend on n.  n is just
a numeric parameter that feeds into the key derivation function.

Obviously this aspect of the design needs to be more explicit.  I
propose to add this sentence to section 6 after the sentence beginning
"It therefore incorporates...":

    Once the transcript checksum is finalized, it is used without
    change for all key derivations (section 7).

> We should have test vectors before final publication.

Agreed.  I have the ability to generate test vectors (using a separate
Python implementation, not the C implementation for MIT krb5), but they
will change when key usage values are assigned, so I haven't included
any in the draft yet.

> with respect to marking things as Required (to implement).

I tend to agree that any mandatory-to-implement policy should be written
into this draft, and not be part of the registry.

> In a weaker sense, anything adding values
> in these registries could be seen as adding to the ASN.1 module

To my mind, the ASN.1 module only defines the wire encoding of
particular data inputs.  That encoding does not change when new groups
are added.

> a way to limit side channels, or leave that to the specifications of

The latter, I think.

> a password or password-equivalent"?

I am not personally sure what this bullet point means; I will make a
note to discuss it.

> within editorial discretion, even if I had a strong opinion about it

I have seen people quibble with using "entropy" the way that some
cryptographic documents do (very roughly, to mean the number of equally
likely values a state variable could have given all of the information
available to an attacker), but I never saw how "randomness" was better.

> document.

This section hasn't necessarily aged well, as there are other PAKE
algorithms not described within.  I would be okay with shortening it,
perhaps not to name any specific alternatives.

> SPAKE against the round-trip count of ENC_TIMESTAMP.

I am not sure there's any concise comparison to be made for this
section.  The way we are using SPAKE (with the KDC presenting the
initial public value) means we might use one more round trip than
encrypted timestamp, or we might use the same number if one of the
described optimizations is used.

> mention that limitation explicitly here?

It is pointed out in the security considerations.  I can see how section
1.3 as currently written could be a little deceptive; however, at this
point the text is speaking generally about how a PAKE can be used in the
design of Kerberos two-factor authentication.  As we haven't even
started talking concretely about the SPAKE preauth mech, I'm not
comfortable adding that caveat here.

> just because of the word "also".

I will take it out.

> It seems like we're mostly just justifying the scheme here

We currently refer normatively to the CFRG SPAKE2 document.  Someone who
has read that document needs to know how this protocol relates to it.
Here we are saying that we use a custom key derivation function, as
allowed by that draft.

(As the CFRG draft hasn't advanced for many months, Nathaniel and I have
discussed the possibility of not using it normatively, and describing
the algorithm in this document instead.  But that's a wider topic.)

> "initail KDC preauthentication state" we are relying on?

It would just be another reference to RFC 6113 section 2.1.

> (We could perhaps be clear that an "empty" value is a zero-length

I'm a bit paranoid about tricking implementors into putting 04 00 into
the padata-value, rather than using 04 00 as the padata-value.  In my
mental model, RFC 4120 already specifies that padata-value is a
non-optional OCTET STRING, and that's not really within the purview of
this document.  I know that other people have their own models, but I am
not really worried about an implementor leaving out the padata-value
entirely as that would quickly be discovered in interop testing.

> a KRB-ERROR and only the PA-SPAKE METHOD-DATA (and no others)

I will add a parenthetical "(possibly in addition to other PA-DATA
elements)".

> do we ever expect this to result in a working connection?

I can bring that up again for discussion; I know I've talked about it
with Nathaniel before, but I can't remember the details.  One possible
use is to communicate to the client what it would have to
implement/enable to interop with the KDC, even if we don't expect it to
work for this particular exchange.

> transcript hash could be helpful.

We have a forward reference in the first use of "transcript checksum" in
section 4.2, and not for the second use in section 4.2 or the use in
section 4.3.  As section 4.6 describes a modification of 4.1/4.2/4.3,
I'm not sure we need another forward reference.

I did note that we inconsistently use "transcript hash" and "transcript
checksum".  I will standardize on "transcript checksum".

> so that this could have a forward reference to the justification for

Agreed, but breaking down the security considerations into units
requires some thought.  I might or might not do this.

> start of section 7 where we talk about "PRF+ input".

We use PRF+ in two places (section 5 and section 7).  In both places, we
refer to RFC 6113 right after we use the function.  It is true that  in
section 7 we talk at some length about the PRF+ input string before
actually invoking PRF+ and including the reference, but I don't see that
as a problem--it would be pretty hard for an implementor to miss the
reference and use the wrong PRF+.  I would be okay with just defining
the "input string" without referencing PRF+ until afterwards, if that
would be clearer.

> Should section 8 note that the value 0 is reserved?

It is reserved in section 11.1.  I don't see a need to echo that in
section 8.

> the client cannot be a signing oracle.

Can you be more specific or propose text?  I don't know how to act on
this feedback item.

> confused as to whether the "non-" part of "non-negligible" is

That paragraph seems vague and could possibly be removed.  If an
implementation doesn't derive the right encryption keys, it won't
interop or match the (forthcoming) test vectors anyway.

> the PA-SPAKE CHOICE and the SpakeResponse factor; should we make

Both of those use EncryptedData (and are the only uses of EncryptedData
in the spec), so yes, it's intended to apply to both.  I'll propose this
text:

    Both the size of the EncryptedData and the number of
    EncryptedData messages used for second-factor data (including the
    factor field of the SPAKEResponse message and messages using the
    encdata PA-SPAKE choice) may reveal information about the second
    factor used in an authentication.

> know that that's universal.)

I think this was my text, and my intent was to include both the same KDC
and other KDCs.  I wouldn't expect the lookaside cache to be much
protection, as the attacker could probably make small manipulations to
the request so that it doesn't match byte-for-byte.  I'm not sure the
text needs to make that any more explicit.

> The ASN.1 module includes an OID for spake; is that officially

Yes.

> "secure" means.  Perhaps it's best to just drop it, or otherwise clarify.

I will drop the word "secure" (and also fix the typo for "achieved" nearby).

[Proposed wording:]
> in the case of a weak password.

Accepted, with "especially a weak password" removed and with "if the
password is weak" at the end.

> equivalent security levels as finite-field DH key exchange at much smaller

Accepted, with "equivalent... as" changed to "equivalent... to".

> "part of 2FA" or "along with additional authentication factor(s).

I will change this to "when used as a component of two-factor
authentication".

> complex verb tense like "is" or "was".

I will use "is".

> Later in the same paragraph, maybe

I will use "in contrast", but I'm not sure it would add clarity to say
that the SPAKE key exchange is asymmetric--it does, after all, result in
a symmetric key.

> to bind the term to the document in question.

Accepted.

> In section 4, first pargaraph, please note that the indicated facilities

I will add a reference to RFC 6113 section 3.

> it be reworded and/or split in twain?

I will just remove the middle part, so that it says:

    Group elements are converted to octet strings using the
    serialization method defined in the IANA "Kerberos SPAKE Groups"
    registry created by this document.

> item 1 and before "a big-endian" in item 2.

Accepted.

> Item 2 should probably also clarify that there is no trailing 0 included.

Disagree.  It would be very noisy to explicitly disclaim trailing 0
bytes every time IETF standards talk about strings.

> of of all bits set to zero" be better?

Accepted.

> than just the strength of the key itself.

I propose:

    The selected group's resistance to offline brute-force attacks
    may not correspond to the size of the reply key. For performance
    reasons, a KDC MAY select a group whose brute-force work factor is
    less than the reply key length. [...]

---

From: Robbie Harwood <[email-masked]>
Date: Tue, 22 Aug 2017 18:30:54 -0400

Greg Hudson <[email-masked]> writes:

>> I'm not sure that the registry policies make sense, most notably with
>> respect to marking things as Required (to implement).

Sure, I'm happy to discuss the registry policy.

To be clear: are you suggesting that the "Required" should disappear as
an option, or that the whole "Implementation Requirements" section
should disappear?

(And is this for both registries, or just one of them?)

> I tend to agree that any mandatory-to-implement policy should be
> written into this draft, and not be part of the registry.

The disadvantage of having mandatory-to-implement items defined but not
in the registry is that it fragments the numbering.  For example, in our
Kerberos SPAKE Groups registry, currently P-256 is required, and
assigned ID Number: 1.  If we remove it from the registry, it won't have
an ID Number.  (Unless we give it one a different way.)

Thanks,
--Robbie

---

From: Greg Hudson <[email-masked]>
Date: Tue, 22 Aug 2017 18:49:58 -0400

> an ID Number.  (Unless we give it one a different way.)

I think I miscommunicated.  P-256 should be in the registry, but if we
want to specify that it is mandatory-to-implement, I believe we should
say that in the RFC outside of the IANA registry.

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 28 Aug 2017 20:23:38 -0500

Sorry for the slow reply; I was on vacation last week.

> say that in the RFC outside of the IANA registry.

That's my understanding as well -- the MTI items should still be in
the registry, but the registry is not the best place to specify the
MTI nature.  Making something MTI for a standards-track document
"should" require standards-action, so there's not much value in having
a field in the registry when there will have to be a new document
for such things anyway.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 28 Aug 2017 20:43:03 -0500

Thanks for the detailed reply.  I'll try to trim some uncontroversial
bits.

> message was part of the exchange, in case there was a downgrade attack).

Ah, yes, I was making assumptions that the checksum would keep going,
but I now see that it's supposed to stop after a fixed number of
inputs (some of which are skipped depending on which optimizations are
in use).

> reason or another anyway.

Thanks for listing these out; I'm now convinced that I agree with your
analysis, and we don't gain much by expanding the scope of the transcript.

>     change for all key derivations (section 7).

That would probably help, thanks.

> will change when key usage values are assigned, so I haven't included

It seems likely that this document will advance before
draft-ietf-kitten-kerberos-iana-registries.  Do I understand correctly
that the Kerberos Registrar role has been transferred to you?  Any
comment on when you would feel comfortable making an official assignment?

> particular data inputs.  That encoding does not change when new groups

That's the interpretation I'm inclined to use; I just mentioned the other
for discussion.

> I am not personally sure what this bullet point means; I will make a

Thanks.

> available to an attacker), but I never saw how "randomness" was better.

It's definitely not clear-cut; leaving "entropy" seems fine to me.

> perhaps not to name any specific alternatives.

Not naming any specific alternatives is probably the right thing to
do, given the advances you mention.

> described optimizations is used.

I was imagining something like:

[... single round trip, allowing SPAKE preauthentication to occur in
the same number of round trips as encrypted timestamp, if either
optimization from section 4.6 is used.  If neither optimization is used,
an additional round trip is incurred, but in consideration of all the
above properties, SPAKE remains an ideal PAKE for use in Kerberos
pre-authentication.

> comfortable adding that caveat here.

Okay.

> Here we are saying that we use a custom key derivation function, as

That seems clear to me now; maybe it was just the "also" that got me
confused.

> the algorithm in this document instead.  But that's a wider topic.)

I can put my chair hat on an ask the CFRG chairs for a status update.

> entirely as that would quickly be discovered in interop testing.

Seems reasonable enough to me.

> I will add a parenthetical "(possibly in addition to other PA-DATA

Thanks.

> work for this particular exchange.

Okay.  I don't object to keeping the current text.

> I'm not sure we need another forward reference.

Okay.

> checksum".  I will standardize on "transcript checksum".

Thanks!

> the "input string" without referencing PRF+ until afterwards, if that

I think that would alleviate my concern, yes.

> Can you be more specific or propose text?  I don't know how to act on

Well, I'm not sure I completely understand it myself, so it's hard to
propose text.  Namely, the client is a "signing oracle" in that it
will happily sign whatever is put in front of it ... but this is
believed to not be a problem, because the key used for the signing
depends on the message being signed in a way that is (hoped to be)
specific to this protocol and would not be usable in a different
context.  If that's correct, it's probably worth calling out the
message-dependence of the signing key and consequent non-transferrability
of the signature.

> interop or match the (forthcoming) test vectors anyway.

I think it is probably safe to remove.

>     factor used in an authentication.

Sounds good.

> text needs to make that any more explicit.

Okay.  (I do agree that the current text does apply to the same KDC
as well as other KDCs.)

> that the SPAKE key exchange is asymmetric--it does, after all, result in

Fair enough.

>     registry created by this document.

That works for me!

> bytes every time IETF standards talk about strings.

This is true, though I seem to see it fairly often.

>     less than the reply key length. [...]

That addresses my concern, thanks.

Is there anything else we need to discuss before an -01 can be issued?

Thanks again,

Ben

---

From: Nathaniel McCallum <[email-masked]>
Date: Tue, 29 Aug 2017 09:41:16 -0400

> I can put my chair hat on an ask the CFRG chairs for a status update.

Please do. That would help.

> message-dependence of the signing key and consequent non-transferrability

An attacker who wished to use the client as an encryption/signing
oracle would have to already know the LTK. Without this, the client
produces an invalid signature. And since the LTK is the target of the
attack, this is logically precluded.

---

From: Greg Hudson <[email-masked]>
Date: Tue, 29 Aug 2017 11:28:28 -0400

> comment on when you would feel comfortable making an official assignment?

I would like a sense of consensus on the material aspects of the
protocol (as opposed to its presentation), to avoid having to reassign
the numbers and deprecate the old ones.  Having reviews from you and
Hank that don't propose material changes (now that the transcript
checksum issue is resolved) is helpful there.

I would also like to propose adding an ed25519 group (as I have put
together a decent implementation of one by borrowing code from
BoringSSL) and perhaps making it the only mandatory-to-implement group;
that should probably happen before assigning numbers.  That should of
course be discussed in a separate thread.

> above properties, SPAKE remains an ideal PAKE for use in Kerberos

As this section is still just talking about general PAKE algorithms, I
think it would be confusing to start diving into the weeds of the
specific protocol this early.

---

From: Robbie Harwood <[email-masked]>
Date: Tue, 29 Aug 2017 14:09:26 -0400

> a field in the registry when there will have to be a new document

Thanks for clarifying.  Language changes have been proposed.

--Robbie