[36562] in Kerberos
Re: What happened to PKCROSS?
daemon@ATHENA.MIT.EDU (Rick van Rein)
Mon Oct 20 03:04:39 2014
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Rick van Rein <rick@openfortress.nl>
In-Reply-To: <CAK3OfOjirYLx56OuOWXtUcpKDiXs=P1CeyXQ+0hskxywGnit6w@mail.gmail.com>
Date: Mon, 20 Oct 2014 09:04:18 +0200
Message-Id: <FF8B28F1-B073-4F08-95B8-56C67D1774AD@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
Hello Nico,
Are you still working on your neo-PKCROSS draft? I’d love to see it move forward!
You may have seen draft-vanrein-dnstxt-krb1 pop up; it arranges that a 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”.
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
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. 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?
Cheers,
Rick van Rein
OpenFortress.nl / ARPA2.net
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
