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
