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

[Benjamin Kaduk <[e-mail]>]

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.