On Mon, Oct 20, 2014 at 09:04:18AM +0200, Rick van Rein wrote: > Hello Nico, > > Are you still working on your neo-PKCROSS draft? I’d love to see it
I'll update the I-D soon, but I still don't have cycles for implementing. > move forward! Me too. > You may have seen draft-vanrein-dnstxt-krb1 pop up; it arranges that a No, I hadn't. > client (or its KDC) can figure out under what realm to address for a > given hostname. This is based on DNS TXT RR + DNSSEC. This will > cause realm crossover inquiries, even for hitherto unknown realms. To > enable the KDC to resolve such inquiries, we’ll need some form of > PKCROSS based on “remote KDC credentials in DNSSEC”. Well, I envision two options: - client-driven PKCROSS (as described earlier) - TGS-driven PKCROSS, which would work for existing, unmodified clients, and which would not create persistent, long-term symmetric cross-realm trust principals. Here the TGS would use the client-drivern PKCROSS protocol as a client, but would obtain a cacheable, short-lived cross-realm credential that can be used to issue cross-realm TGTs for the given x-realm TGS principal name. In both cases using DANE as much as possible, with stapled DANE as Google wanted to do for HTTPS (though they've backed off for now). > My thoughts were: > * KDC’s peer to cross realms > * publish the KDC server key using DANE > * employ PKINIT with DH to establish a one-sided krbtgt Yes. > Your thoughts were (AFAIK): > * clients hold a certificate (possibly from their local KX509 service) > * clients connect to remote KDC’s > * publish CA certs for clients using DANE > > The first is tighter on security, the second supports more flows. The first can be implemented on the basis of the second: the TGS uses PKINIT at the remote realm to acquire a special (because of the TGS' client principal name in its PKINIT certificate) cross-realm TGT whose purpose is to enable the client TGS to issue x-realm TGTs for that one x-realm. > Mixing the two will probably lead to mutual weakening, so I am > thinking that it might be useful to split the two, but ensuring that > they remain as compatible as can be. Does that sound wise to you? I don't agree. A client-driven PKCROSS is feasible now. In fact, I heard earlier this week of a couple of environments where it actually *is* used in practice. (The user has a TGT in a given realm, uses kx509/kca to get a certificate, then PKINIT to get a TGT at the remote realm.) I don't have specifics, and I gather that the AS at the remote realm had to have local enhancements added to make this possible. A client-driven PKCROSS is deployable even if you use a KDC whose vendor isn't likely to add KDC-driven PKCROSS any time soon. That's convenient! A client-driven PKCROSS protects the client's privacy relative to its home KDC. A client-driven PKCROSS is sub-optimal though: a TGS-driven PKCROSS can significantly reduce the number of PK operations needed, compared to a client-driven PKCROSS. The TGS-driven PKCROSS can be substantially similar to the client-driven one, with the TGS being the client. Nico -- ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
