Re: [kitten] Kerberos preauth negotiation techniques

[Benjamin Kaduk <[e-mail]>]

On Wed, 11 Feb 2015, Greg Hudson wrote:

> 1. Add a third round trip.  The exchange could look like this:
>
>     C: unauthenticated AS-REQ
>     K: PREAUTH_REQUIRED (empty hint)
>     C: AS-REQ (client sub-negotiation parameters)
>     K: MORE_PREAUTH_DATA_REQUIRED (KDC parameter choice, KDC public value)
>     C: AS-REQ (client public value, key confirmation, second factor)
>     K: ticket or error
>
> 2. Use pseudo-enctypes:
>
>     C: unauthenticated AS-REQ (pseudo-enctypes in etype field)
>     K: PREAUTH_REQUIRED (KDC public value in hint)
>     C: AS-REQ (client public value, key confirmation, second factor)
>     K: ticket or error
>
> 3. Use client preauth hints:
>
>     C: unauthenticate AS-REQ (padata containing sub-negotiation params)
>     K: PREAUTH_REQUIRED (KDC public value in hint)
>     C: AS-REQ (client public value, key confirmation, second factor)
>     K: ticket or error
>
> ---
>
> As I write this, I am leaning towards option 1.  My only reservation is
> that I would like this mechanism to eventually displace encrypted
> timestamp in the Kerberos ecosystem, and it might be a shame to make
> essentially all password-based initial Kerberos authentications take
> three round trips.  What are other people's thoughts?

I agree that (1) is the cleanest in terms of fitting into the existing
structures.  But, practical considerations of reducing the round-trip
count may end up causing us to go with (3), which is also fairly elegant
but has the wart of needing to update RFC 6113.  I generally like to avoid
changing existing specs that had a lot of thought go into them, but
perhaps this is a minor enough change that it would be acceptable.  Do you
want to write a little bit about the existing pa-hint and how this new
usage would differ from the current standardized usage?

-Ben