On Tue, Jul 15, 2014 at 6:32 AM, Rick van Rein <r...@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.
kit...@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 -- ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
