Re: [kitten] Kerberos preauth negotiation techniques

[Greg Hudson <[e-mail]>]

I wrote (in summary):
>> I think there are basically three options:
>> 1. Add a third round trip
>> 2. Use pseudo-enctypes
>> 3. Use client preauth hints

On 02/17/2015 11:14 AM, Nathaniel McCallum wrote:
> 1 and 3 are also compatible workflows. In 3, the first AS-REQ is 
> exactly the same padata as the second AS-REQ in 1. That is to say, 3 
> is an optimization of 1 where the first round-trip of 1, which 
> includes no meaningful data, is simply not used. Put another way, 3 is 
> just 1 with optimistic preauth.

That's an interesting way of looking at things.  It means we wouldn't
have to amend RFC 6113, although we might be bending it a bit.  Here are
some considerations, which all seem manageable:

* Traditionally, optimistic preauth is only done with some prior
knowledge of what the KDC wants (see RFC 6113 section 2.3 paragraph 1).
 To get down to two round trips in the common case, an AS client  needs
to do optimistic PA-PAKE by default.

* Of course PA-PAKE would need to be specified such that the first
client message requires no knowledge from the KDC.  This is pretty
simple; the first client message can be defined to contain only
sub-negotiation parameters.

* Most KDC implementations will ignore the client's PA-PAKE padata if
they don't implement it, and respond with PREAUTH_REQUIRED with
METHOD-DATA.  Some older KDCs (like MIT krb5 pre-1.7) will instead
respond with PREAUTH_FAILED.  Clients already need to deal with this
behavior if they implement RFC 6112 encrypted padata negotiation or any
similar extension, so this is not really a concern.

* An optimistic PA-PAKE message should be cheap to compute (it's just
parameters), but is still wasted bytes if the exchange winds up settling
on a different mechanism or not using preauth at all.  The more
compactly we can represent client parameters, the less bandwidth we will
waste and the fewer problems we will have with AS-REQs exceeding UDP
limitations.

* Can a client optimistically preauthenticate with multiple mechanisms?
 RFC 6113 doesn't really say either way.  Without going into detail on
the arguments pro and con:

  - If we assume no, then a client which does optimistic PA-PAKE by
default can't do the same thing with any other mechanism.  This could be
a reasonable choice; the client implementation could always choose to
drop back to three round trips for PA-PAKE if it wants to do optimistic
PA-FUTURE-AWESOME by default in the future.

  - If we assume yes, then a client which does optimistic PA-PAKE is
still privileging that mechanism by choosing to spend bandwith on it
before it is negotiated.  But it wouldn't necessarily have to exclude
other mechanisms from doing the same thing.