Re: [kitten] Kerberos preauth negotiation techniques

[Benjamin Kaduk <[e-mail]>]

On Tue, 17 Feb 2015, Nathaniel McCallum wrote:

> So a KDC can actually implement both 1 and 3 simultaneously. If the
> KDC does not receive the padata in the first step (option 3), it
> generates the empty hint (option 1). Otherwise, 1 and 3 are identical.
> Only one thing differs: PREAUTH_REQUIRED or
> MORE_PREAUTH_DATA_REQUIRED. Can we just always use the latter error?

It is safe to use MORE_PREAUTH_DATA_REQUIRED since we can document that
support for that error is a requirement of the new preauth mechanism.

Determining whether it is acceptable to ask for MORE_PREAUTH in response
to the initial AS-REQ (including the hints which we are calling optimistic
preauth here), as opposed to just PREAUTH_REQUIRED, will probably require
a close reading of the relevant RFCs.

> After thinking about this (and implementing it), I think the best way
> forward is 1 with 3 as an optional optimization. The KDC should always
> support both 1 and 3; adding support for (optional) 3 should be
> trivial. Clients should choose whether or not to support 3 based on
> complexity of implementation; 3 can always be added later as an
> optimization.

That does seem like the best way forward, as the rest of the thread is
concluding.

-Ben