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.

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

We use KXOVER as a name for the Kerberos Realm Crossover protocol proposed on this page. The Dutch may pronounce KXOVER als klaar-over, after the street-crossing public service (for school children).

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 creates a (KRB5_PRIV or local & unencrypted) message with the TGS_REQ from the client and sends it to the local KXOVER deamon.
4. The KXOVER deamon extracts the server name from the request, and looks in DNS.
5. Demanding DNSSEC for security, the local KXOVER daemon extracts a _kerberos TXT record describing the remote realm for the server name
6. If the remote realm is already known, and its key is still valid for long enough, the local KXOVER deamon returns the referral TGT to the client directly (or through the KDC)
7. Demanding DNSSEC for security, the local KXOVER deamon extracts an SRV record describing the address and port of the remote KDC
8. Demanding DNSSEC for security, the local KXOVER deamon extracts the TLSA records for the remote KDC
9. The local KXOVER daemon initiates a PKINIT exchange with the remote KDC (using its own server certificate for PKINIT)
10. The local KXOVER daemon validates the remote KDC through the TLSA record representing the remote KDC's PKINIT certificate
11. The remote KDC receives the PKINIT request with a server certificate; the PKINIT received by the remote KDC contains the PA-KXOVER in its PA-DATA
12. The remote KDC sends the PKINIT request to the remote KXOVER deamon
13. The remote KXOVER deamon validates the local KDC's certificate through DNSSEC and SRV/TLSA records
14. The local and remote KXOVER deamons agree on a symmetric key using Elliptic Curve Diffie-Hellman cryptography; they also agree on a timeout for this key and store it for that period of time
15. The local KXOVER deamon returns a ticket referral to the client (directly or through the KDC) so a TGT for the remote realm; this ticket is not valid beyond the remote KDC's agreed key validity.
16. The client understands the ticket referral as a hint to contact the remote realm
17. The client looks up the SRV record for the remote KDC
18. The client assumes that the KDC has established security, and therefore does not have to enforce DNSSEC validation
19. The client requests a TGS from the remote KDC, using the remote realm name obtained from the ticket referral

The KDC code has to be modified in order to allow the redirection of cross-over requests to the KXOVER deamon, and if responses are passed back through the KDC, relay those back to the user.

The KDC admin must publish the KDC's server-side PKINIT certificate in a TLSA record before enabling this process. The KDC admin has to create a principal for the deamon in the database in order to allow secure communication between the KDC and the deamon.

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, ...)

We learnt that the AS-REP is unsuitable for communication between KDC's, and propose to use [APPLICATION 19] for it. To properly mirror the situation, as well as to get a better message routing to the backend, we propose to use [APPLICATION 18] for a message that replaces the AS-REQ between KDCs. These new messages also help us to be more to the point in the protocol specification than we could be within the PKINIT framework. (The tags were found free after looking for them in all RFCs that mention Kerberos, the free tags being 17, 18, 19, 23, 24.)

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 KXOVER 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).

Beyond Quantum Computing

Kerberos has an important advantage over public-key schemes, namely that its key exchange infrastructure will hold up against quantum computers according to our current knowledge. We do need to make our twice twice as long as the customary 128 bit on account of Grover's algorithm — but at least Shor's algorithm, which is devastating for public key crypto, has no grip on it.

Our proposal for a TLS-KDH cipher suite, combining Kerberos authentication with ECDHE key agreement already withstands Quantum Computer attacks. It is an interesting pair with KXOVER, as the two allow Kerberos for many protocols across the Internet.

KXOVER can utterly destroy the resistence to Quantum Computing for any traffic between a different client realm and server realm. This problem is the same as what HTTPS and co have to face, but again Kerberos holds better cards, mostly because KXOVER is run between servers in a mutual relationship, rather than between a client and a server.

In practice, we might assume that passive observers cannot scan all traffic that passes between all systems. Based on this, if we can get only piece of salt across without it being stored, we can base our next key agreement on that, rather than just on the ECDH primitives. There are so many fresh keys floating around in any Kerberos system that we have a lot of material of good entropy staring at us. Using this cleverly to build up entropy for a fresh exchange may be useful, especially when manual keying is at the foundation of at least one of the entropy sources.

In addition to these defenses, it is a good idea to incorporate a key exchange algorithm that withstands Quantum Computing as soon as it can be trusted. But given that such trust does not usually come overnight in crypto, it is still a good idea to work on the gathering of entropy.

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