What happened to PKCROSS?

[Rick van Rein]

Hi Nco,

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

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

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

> - 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 :’-(

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

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

IF sending along the RRSIG chain of trust THEN
	need to constantly update the DNS data known in the TLS server;
	arrival of DNS data in application software which doesn’t have a clue and doesn’t have a cache
ELSE
	still need to inquire with DNS to get the RRSIG, and that involves doing the DNS queries again
END IF

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


I’ll get back to you after reading your draft.  Thanks very much!


Cheers,

Rick van Rein
OpenFortress