What happened to PKCROSS?

[Nico Williams]

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
--