[36239] in Kerberos
Re: What happened to PKCROSS?
daemon@ATHENA.MIT.EDU (Rick van Rein)
Tue Jul 1 17:12:21 2014
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Rick van Rein <rick@openfortress.nl>
In-Reply-To: <CAK3OfOgWM87oA5JEeevieDKJ9=C9Uxee-xfhBGnzMx-8tzOMYA@mail.gmail.com>
Date: Tue, 1 Jul 2014 23:11:59 +0200
Message-Id: <D89A3893-24D6-4C83-9B30-CF928A404AAF@openfortress.nl>
To: Nico Williams <nico@cryptonector.com>
Cc: "kerberos@mit.edu" <kerberos@mit.edu>
Content-Type: text/plain; charset="windows-1252"
Errors-To: kerberos-bounces@mit.edu
Content-Transfer-Encoding: 8bit
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
