What happened to PKCROSS?

[Nico Williams]

On Tue, Jul 15, 2014 at 6:32 AM, Rick van Rein <rick at openfortress.nl> wrote:
> (*)  List, if this discussion should (or should not) take place here, let me/us know.  I’m not sure what is desired.

kitten at ietf.org is the right place to discuss this.

> ## Summary and positioning
>
> • Looks like your new draft is the “client empowering” variation, which should work regardless of support by the KDC (well, assuming kx509 of course); this is useful in the interest of individual clients and in situations where the client’s software can be influenced;

Well, ASes need some changes.

> • Although the krb5 -> x509 -> krb5 path could emulate an infrastructural mode inside a user’s KDC, I think it would not be as scalable as it could/should be; it requires a public key exchange per user principal, so it scales less well than a direct PKINIT to crossover between KDCs; also, there will be more delay times;

No, this proposal scales.  The only problem is that it doesn't
optimize away PK as much as possible.  I've an update where TGSes
noting requests from x-realm TGTs for non-existing krbtgt principals
will initiate a PKCROSS exchange to obtain a non-persistent, cacheable
trust relation that doesn't require replication.

> • I therefore think that PKCROSS needs to describe two approaches; one is “client empowering” and the other is “infrastructural” in style.

Only the first is really needed.  The latter is an optimization -- a
very worthwhile one, so we should add it.

On a related note I think we need a KRB-ERROR response that can tell a
client to retry the request in N milliseconds -- i.e., give an ETA.
This is important for QoS purposes: we should want ASes to get less
CPU than TGSes, but it's not easy to separate the two services by port
number, so we have to resort to something akin to task queues in the
AS.

Nico
--