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@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 ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
