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

[Greg Hudson <[e-mail]>]

On 08/28/2017 09:43 PM, Benjamin Kaduk wrote:
>> 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.
> 
> 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?

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.

>>> Section 1.2 should probably compare the single-round-trip nature of
>>> 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.
> 
> 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.

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.