Crossover Design

Crossover is setup explicitly as a form of (mutual) trust between realms, and to implement it operators exchange keys that bind their KDCs. This constructs fixed bindings, and even though a "certification authority" mechanism exists, it is not used to bind arbitrary parties, AFAIK.

It is worth noting that Kerberos can search the DNS for a party, and may benefit directly from the security of DNSSEC in this respect; but in doing so, it searches for domains going up in the DNS tree, and then down. Intermediate domains are supposed to have a KDC. This means that the ultimate structure that permits all parties to be bound together, would include a KDC for the DNS root zone -- an unacceptable design because it centers all security for the entire Internet in a central service.

Moreover, the trust connections between realms are founded on symmetric keys and not on public-key crypto; so all intermediate KDCs transport these keys and are therefore empowered to decrypt anything that is communicated between the KDCs, and due to the design of Kerberos, anything that continues between end points (except when KDH is used).

Compatibility of Implementations

In practice, crossover is also hampered by limitations of the implementations, and their inability to process each others' messages. Mick Pouw and Esan Wit have conducted experiments to establish the possibilities and limitations, and published their final project report entitled Cross-realm Kerberos Implementations

As a bit of a spoiler, we include the main tables from the research project below.

Active Directory can only work as a principal on an Active Directory KDC; Shishi 1.0.2 can only register client (or user) principals; the other implementations are suitable to fulfil both principal roles relative to any KDC.

Note that no Windows implementation was tested since there are several, including the Kerberos for Windows releases from MIT. Normal Windows clients have no kinit program, it would need to be installed. In light of these compatibility issues, it would be advisable to install MIT or Heimdal code on Windows workstations.

The AES128-SHA1 and AES256-SHA1 ciphers have been established, and are advised because the other widely established cipher is RC4-HMAC, which relies on RC4 encryption and is not advised for new implementations.

Shishi 1.0.2 is the only one that does not implement realm crossover yet; the other implementations are suited to this.

Room to grow

Kerberos might be used to implement realm crossover, assuming that its implementation compatibility issues are overcome, when the following is done:

• The certificate authority feature or a hierarchical root realm entry points to an Outward KDC for fallback resolution;
• This Outward KDC looks up realm public keys in DNS, insisting on DNSSEC and locating an Inward KDC;
• The Outward and Inward KDC are two roles of one piece of software; it mutually authenticates Internet domains as Kerberos realms.
• The Outward and Inward KDC agree on a temporary key between the realms, exchanged in a pubkey-signed DH Key Exchange;
• Using pre-authentication mechanisms, the special KDCs exchange a shared ticket;
• Through the temporary realm crossover, the Outward and Inward KDCs can now exchange cross-realm identities as they normally would, based solely on symmetric keys.

Related: There has been some work on PKCROSS in the past, but it did not make it to an RFC; implementation status is uncertain, but people worked on it before and it is being looked into for FreeIPA and actively drafted. The new draft proposes to connect through user certificates obtained with kx509 from the user's realm, and using those to engage in PKINIT with the service's realm. Note that this is per-user realm crossing, unlike the "normal" mode of realm crossing in Kerberos, which uses key exchange per realm combination.