Difference between revisions of "Projects/Realm Crossover between KDCs"

Revision as of 05:08, 11 September 2015

Realm Crossover is the ability to connect Kerberos realms under potentially different operational control. Although Kerberos supports mechanisms for connecting realms, this is based on manual key exchange in advance. We use the term Realm Crossover here to indicate an automated process that can incorporate any remote party on the Internet. The mechanism uses DNSSEC and DANE to secure a PKINIT process between KDCs that intend to collaborate; there is no need to change client code.

External project links:

• Project working pages
• Project mailing list

We use KREALM-XOVER as a name for the protocol proposed on this page.

Mechanics of the Project

1. A client requests a sevice from its local KDC
2. The local KDC finds that it does not define the requested service
3. The local KDC extracts the server name from the request, and looks in DNS
4. Demanding DNSSEC for security, the local KDC extracts a KREALM record describing the remote realm for the server name
5. When the remote realm is already known, and its key is still valid for long enough, the local KDC skips ahead to returning a ticket referral to the client
6. Without caring for DNSSEC, the local KDC extracts the SRV records pointing to the remote KDC
7. Demanding DNSSEC for security, the local KDC extracts the TLSA records for the remote KDC
8. The local KDC initiates a PKINIT exchange with the remote KDC (using its own server certificate for PKINIT)
9. The local KDC validates the remote KDC through the TLSA record representing the remote KDC's PKINIT certificate
10. The remote KDC receives the PKINIT request with a server certificate
11. The remote KDC validates the local KDC's certificate through DNSSEC and SRV/TLSA records
12. The local KDC and remote KDC agree on a symmetric key using Diffie-Hellman cryptography; they also agree on a timeout for this key
13. The local KDC returns a ticket referral to the client, so a TGT for the remote realm; this ticket is not valid beyond the remote KDC's agreed key validity
14. The client understands the ticket referral as a hint to contact the remote realm
15. The client looks up the SRV record for the remote KDC
16. The client assumes that the KDC has established security, and therefore does not have to enforce DNSSEC validation
17. The client requests a TGS from the remote KDC, using the remote realm name obtained from the ticket referral

Note that the above process is not symmetric; the local KDC contains a client and the remote KDC contains a service. The key exchanges is only setup for that direction; the opposite will often be supported as well, but would require a separate key exchange process.

The one thing the client must permit, is accept ticket referrals. This means that it should flag being open to those through the canonicalize(15) KDCOption flag. This is not new. -- but is it available in practice?

The KDC code must implement the new flow, including strict reliance on DNSSEC without opt-out. See Insisting on DNSSEC and discussion.

The KDC admin must publish the KDC's server-side PKINIT certificate in a TLSA record before enabling this process in the KDC configuration settings.

Policy Choices for this Mechanism

• The client makes a policy decision to support ticket referral through the canonicalize(15) KDCOption.
• The KDC may require X.509 PKI infrastructure on the Kerberos certificate (for instance, to enforce a federation).
• Any KDC may support client remote operation, and connect to remote realms on behalf of a local client.
• Any KDC may support service remote operation, and welcome remote clients to connect to reach a local service.

Changes to Kerberos

KDCs must support the above procedure. They must accept servers accessing the PKINIT procedure.

Clients must send the canonicalize(15) KDCOption; which do that and which don't?

For AD/DC, a solution may be constructed with a trust relationship to an open source KDC and pointing to it with Name Suffix Routing and using wildcard realm names. (Perhaps * or otherwise *.com, *.org, ...)

Comparison to Other Work

The current Kerberos infrastructure permits KDCs to link to one another, as well as assigning a KDC as a "certificate authority". The first construct provides a manually-secured method for ad-hoc links, the second permits larger structures such as federations to form. Neither is suitable for binding together KDCs that have not been in contact before, and are therefore unsuitable to create a Kerberos facility that spans the Internet at large. The fact that the method proposed here could not be formulated before has been the lack of a reliable, as in secure, DNS infrastructure. With the advent of DNSSEC, this is now very well possible.

Another proposal named PKCROSS exists to use the PKINIT exchange across realms, where a client uses an X.509 certificate to access a remote realm. This X.509 certificate would have been previously obtained from a local realm, using the kx509 mechanism. This approach therefore moves back and forth between X.509 and Kerberos, possibly more than once. It relies on modifications in client code.

Related Projects

We propose KREALM-XOVER as a mechanism underneath TLS-KDH. Using this combination, it would be possible to have interactions with web, mail, and many other services that are protected by Kerberos at the transport layer, so without interference from the application layer (the layer that includes JavaScript, and so, adverse advertisements).

Specifications

• RFC 6806 defines cross-realm referral tickets
• draft-vanrein-dnstxt-krb1 describes the KREALM record in DNS
• draft-williams-kitten-krb5-pkcross describes the PKCROSS alternative