Re: [kitten] Kerberos extra round trips I-D revised

[Nico Williams <[e-mail]>]

On Wed, Nov 12, 2014 at 11:35:18AM -0500, Greg Hudson wrote:
> This brings up a larger point that I previously missed: in the rcache
> avoidance flow with an odd number of tokens, there is no AP-REP token in
> the exchange.

I removed too much when I removed sname/srealm.  The intention is to use
the KRB-ERROR2 as an AP-REP in the three-token flow, which means that it
needs to have an optional sub-session key field (and which must be
present when the initiator's AP-REQ was fine but the acceptor wants that
third token).

I added this back for -04 (not yet submitted).

> So, should rcache avoidance should use a modified KRB-ERROR or a
> modified AP-REP?  I think using a modified AP-REP is more natural, but
> it does mean adding a second new message type and adding the nonce to
> both messages.

Right.  To me KRB-ERROR2 can fill both roles.

> If we do use a modified KRB-ERROR in this flow, then we need to make
> sure that we get all of the security properties we would get from the
> AP-REP.  The AP-REP provides:

Agreed.

I'll be re-adding the acceptor sub-session key, I'll add the mirrored
timestamp, and I'll add authz-data (not just typed-data) so that this
message really can serve as both, KRB-ERROR2 and AP-REP2.  (Authz-data,
for example, could be useful here in the user-to-user case, for
symmetry, but also so we don't have to define both, authz-data and
typed-data elements for things like kDH pubkeys.)

> We also need to consider how this all interacts with
> draft-vanrein-krb5-kdh.

A typed-hole in KRB-ERROR2, and the authz-data in AP-REQ, allow for
ephemeral DH keys.  We then only need to specify the relevant elements
for carrying them.

We'll also need to support acceptor key confirmation for the DH key in
the case where the initiator's optimistic DH group/curve choice fails.

The kDH flows might look like this:

 - 2-token flow (optimistic negotiation succeeds, no acceptor key
   confimation):

   C->S: AP-REQ with ad-kdh-groups, ad-kdh-pubkey (one or more even)
         (initiator is PROT_READY here)
   S->C: KRB-ERROR2 or extended AP-REP with ad-kdh-pubkey and key
         confirmation typed-data/authz-data

 - 3-token flow (optimistic negotiation succeeds, no acceptor key
   confimation, acceptor wants rcache avoidance):

   C->S: AP-REQ with ad-kdh-groups, ad-kdh-pubkey (one or more even)
         (initiator is PROT_READY here)
   S->C: KRB-ERROR2 or extended AP-REP with acceptor pubkey and key
         confirmation
   C->S: AP-REQ with challenge

 - 4-token flow (optimistic negotiation fails, acceptor key confirmation
   desired):

   C->S: AP-REQ with ad-kdh-groups, ad-kdh-pubkey (one or more even)
   S->C: KRB-ERROR2 or extended AP-REP with ad-kdh-pubkey
   C->S: AP-REQ with ad-kdh-pubkey (and with challenge if the acceptor
                                    wanted it)
         (initiator is PROT_READY here)
   S->C: AP-REP

Obviously, it'd be nice if the KDC had some idea what groups/curves the
acceptor supports, then we could more often avoid the 4-token flow.

BTW, the TLS crowd is very keen on 0-RTT, which in GSS-speak means being
prot_ready after producing the first context token^W^W handshake message.

I'm not sure that prot_ready is a such terribly good idea because in
many, many cases the very first app data either needs PFS/established
authentication state, or else the layer right above TLS/whatever doesn't
know if the app data needs that.

But, there's a reason that 0-RTT is desired, and I think it'd be worth
formalizing and modernizing the prot_ready concept.  I also think it'd
be a good idea to de-conflate (in GSS) acceptor key confirmation from
authentication of the acceptor to the initiator.

Nico
--