Projects/Realm Crossover between KDCs

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.

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

This is an early stage project for MIT Kerberos. It is being fleshed out by its proponents. Feel free to help flesh out the details of this project. After the project is ready, it will be presented for review and approval.

External project links:

• Project working pages
• Project mailing list

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 still valid for long enough, the local KDC skips ahead to returning a ticket referral to the client
6. Demanding DNSSEC for security, 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 remote KDC receives the PKINIT request with a server certificate
10. The remote KDC validates the requesting certificate through DNSSEC and SRV/TLSA records
11. The local KDC and remote KDC agree on a symmetric key using Diffie-Hellman cryptography; they also agree on a timeout for this key
12. The local KDC returns a ticket referral to the client, so a TGT for the remote realm
13. The client understands the ticket referral as a hint to contact the remote realm
14. The client looks up the SRV record for the remote KDC
15. The client assumes that the KDC has established security, and therefore does not have to enforce DNSSEC validation
16. 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

TODO: KDC changes

TODO: Client changes, any???

TODO: Include AD fallback to an external resolving component

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