What happened to PKCROSS?

Nico Williams nico at cryptonector.com
Tue Jul 1 18:05:19 EDT 2014


On Tue, Jul 1, 2014 at 4:11 PM, Rick van Rein <rick at openfortress.nl> wrote:
>> I've an Internet-Draft on the subject.  I intend to update it soon.
>
> Excellent!  Bookmarked it on http://realm-xover.arpa2.net/kerberos.html
> and am printing it for review.

Great!  That'd be very welcome.

>> If all goes well I might find myself implementing a
>> few months from now, or if not maybe we can con someone else into
>> doing it.
>
> Hero!

Let's not count my (or anyone's) chickens before they hatch.  I have a
ton of things to do.  What I like about this one is that most of the
pieces exist, so it might be easy and have a decent payoff.

>> - kx509 (local realm) -> PKINIT at remote realm to get a TGT for
>> krbtgt/REMOTE at REMOTE
>
> Oh, that’s an interesting angle!  So, unlike earlier PKCROSS proposals you intend
> to change the client code.

That's one option.  The client might be a KDC doing it on behalf of its clients.

However, letting the client do this has the benefit that the client's
realm then need not see where the client is transiting to (privacy
protection).

But mainly the appeal of this approach is that the pieces needed all exist.

>> - add an ephemeral, cacheable mechanism by which KDCs can bootstrap a
>> symmetric x-realm principal key
>
> I’m exploring a similar thing (that I was hoping to present a bit later, it’s still shaky)
> namely Kerberos + Diffie-Hellman for AP_REQ / AP_REP, which may turn out to be
> fairly simple to add through the “subkey” mechanism, http://tls-kdh.arpa2.net/conceptual.html
> but that doesn’t hold for AS_REQ / AS_REP as far as I can tell.  What a pitty :’-(

Look at https://github.com/elric/krb5_admin .  It has support for
setting keys via a multi-party DH exchange, and gets cluster key
update atomicity right.

>> - use DANE for realm public key authentication
>
> Mind you, DANE is a bit of a beast to operate, due to the same-time changes in
> DNS and the server at hand.  That’s something we’re working on at SURFnet.

It needn't be though, and anyways, I'm making that someone else's
problem :)  (one that people are committing to take on; passing this
buck is realistic).

>> - use DANE stapling to avoid the need for slow I/O in KDCs
>>
>> The only part of this that's difficult at all is the DANE stapling part.
>
> If I understand it correctly, it’s passing DNS data through a TLS pipe…

It's gathering all the responses to all the queries that the peer
would have to make, then sending them to them (in ticket authorization
data) so that they can validate them without having to do any DNS
queries.

The main problems here: a) the need to gather and keep up to date all
those responses, b) how to encode the set of them, c) how to validate
them.  Because existing DNSSEC libraries I've looked at don't support
this.  However, Google did try DANE stapling for DNS (which is why you
thought TLS was part of it, no doubt), so code must exist, and the
feasibility is established (even though it turned out not to work well
for TLS for reasons that I think won't apply here).

> IF sending along the RRSIG chain of trust THEN
>         need to constantly update the DNS data known in the TLS server;

Yep, that's a local service daemon.

>         arrival of DNS data in application software which doesn’t have a clue and doesn’t have a cache

Nor could it safely seed its cache with that data.

> ELSE
>         still need to inquire with DNS to get the RRSIG, and that involves doing the DNS queries again
> END IF

Right.

It seems that if you're going to staple DANE (or OCSP) you have to do
it from day one otherwise it doesn't happen.

The alternative here would be to make KDCs able to task-queue dispatch
handling of AS-REQs, and make them be able to handle them in an more
async manner.  That's desirable anyways given how asymmetric the costs
of PKINIT vs. not-PKINIT are.

Maybe I should punt on DANE stapling and stick to DANE -- it'd be
easier to implement with just DANE.  And we can add class of service
support to the KDC instead.

> I hardly think a mere optimisation could be worth the conceptual mayhem that it provokes…

Maybe.  But Stapling is in many ways the best approach.

Nico
--



More information about the Kerberos mailing list