8.1 Cross-Realm Authentication

All of the Kerberos discussion so far has assumed that all users and resources on your network are located in a single Kerberos realm. However, what if there are several departments, locations, or other divisions that are under different administrative control, each with their own Kerberos realm? These users want to access not only resources in their local Kerberos realm, but also resources in the other realms as well, with a minimum of hassle. Kerberos cross-realm authentication can solve this problem.

In Kerberos, cross-realm is implemented by sharing an encryption key between two realms. The key that is shared is the Ticket Granting Service principal's key. A typical Ticket Granting Service principal for a single realm looks like:

krbtgt/WEDGIE.ORG@WEDGIE.ORG

Note that the instance is the same as the realm name. In cross-realm, two principals are created on each participating realm. For two realms, ONE.COM and TWO.COM, these principals would be:

krbtgt/TWO.COM@ONE.COM
krbtgt/ONE.COM@TWO.COM

These principals have to be created on both realms, and are known as remote Ticket Granting Server principals. The Kerberos trust can be one way or both ways; since there are two separate, shared keys involved, one realm can choose to trust the other realm's tickets, but not the other way around.

When a user who is in the ONE.COM realm wishes to communicate with a Kerberized service in TWO.COM, the client program first requests a ticket for the remote realm's Ticket Granting Server, the krbtgt/TWO.COM@ONE.COM principal above. Using that intermediate Ticket Granting Ticket, the client is then able to acquire a service ticket directly for the requested service in the TWO.COM realm. This is called direct cross-realm trust, and is the only type of cross-realm trust supported in the older Kerberos 4 protocol. In direct cross-realm trust, every two realms that wish to communicate must share a separate set of keys. Of course, this can get rather unwieldy as the number of shared keys grows exponentially with the increasing number of realms. This can be managed somewhat by building a certification path between several realms, a feature introduced with the Kerberos 5 protocol. A certification path defines realms that may be used as intermediaries when acquiring service tickets in foreign realms. Direct cross-realm requires every foreign realm be directly connected, through a shared key, to the local realm, creating a full mesh configuration between the realms. Certification paths allow multiple realms to use another realm as an intermediary, creating hub-and-spoke systems in which multiple realms share a key with a single intermediary realm.

Let's take an example. There are several universities collaborating on a project to produce workable cold fusion together with a fictitious government agency, the National Energy Research Directive (NERD). Obviously, these organizations want to utilize each other's resources, and researchers don't like to memorize numerous logins and passwords, so cross-realm Kerberos is proposed as a solution to the authentication needs of all the organizations involved. However, direct cross-realm between all of these organizations would require approximately n2 different keys, where n is the number of participating Kerberos realms. This is a management nightmare, especially if, in this example, more universities are added to the project as time goes on. A diagram of these cross-realm relationships in a full mesh configuration is shown in Figure 8-1.

Figure 8-1. Full mesh cross-realm configuration

To solve this problem, each university decides to share a set of cross-realm keys with one organization, namely the NERD government agency. Then, if a set of Kerberos clients and servers wish to communicate between two different universities, NERD can be used as an intermediary realm.

The certification path must be encoded into each client and server's Kerberos configuration in each participating realm. Clients and servers use this information somewhat differently. Clients use the certification path to determine what KDCs to communicate with in order to reach one realm from another. Servers use the certification path to validate that incoming tickets presented for authentication have passed through a satisfactory path, and no untrusted intermediary realms were used to obtain the service ticket. This information is included in the capaths stanza of the /etc/krb5.conf file. As an example, the above trust relationship would be represented in an MIT-style /etc/krb5.conf file installed on hosts in the PRINCETON.EDU realm, as follows:

[capaths]
        PRINCETON.EDU = {
                CALTECH.EDU = NERD.GOV
                UMD.EDU = NERD.GOV
                NERD.GOV = .
        }

        CALTECH.EDU = {
                PRINCETON.EDU = NERD.GOV
        }
        UMD.EDU = {
                PRINCETON.EDU = NERD.GOV
        }
        NERD.GOV  = {
                PRINCETON.EDU = .
        }

The capaths stanza defines the trust relationships necessary to reach every connected Kerberos realm. Inside of the capaths stanza, a key-value pair exists for every participating realm, and the value is an array of more key-value pairs, defining a link in the certification chain.

Each innermost key-value pair defines two realms that are related as a link in a cross-realm trust. The key defines a destination realm in the realm certification path, and the value is either another realm, which is used as an intermediary, or a period (.) that indicates the a cross-realm key is directly shared between the realms defined by the inner key and the outer key.

Figure 8-2 depicts the cross-realm relationship described by the above krb5.conf capaths stanza, and shows the certification path that a cross-realm request would take between Princeton and Caltech. Note that since no cross-realm key is directly shared between Princeton and Caltech, the request is routed through the intermediary NERD.GOV realm.

Figure 8-2. Sample cross-realm relationship; the dotted line shows the path a request from Princeton to Caltech would take

However, this certification path method has its own downside: the distribution of a large amount of configuration information to all machines on all participating realms (not to mention the trouble involved in creating this configuration information in the first place). Therefore, Kerberos 5 also supports hierarchical trust.

With hierarchical trust, all participating realms in the cross-realm trust are subdomains of a larger realm. For example, a company has a Kerberos realm named COMPANY.COM. The company has several offices with their own Kerberos realms, named NEWYORK.COMPANY.COM, PARIS.COMPANY.COM, etc. Each of these realms shares a key with the "parent" realm, COMPANY.COM.

Since NEWYORK.COMPANY.COM trusts the parent, COMPANY.COM (they share a key between them), then NEWYORK.COMPANY.COM implicitly trusts PARIS.COMPANY.COM as well, even though no explicit key is shared between the New York and Paris realms. This is simply a special case of the certification path described above; the common DNS suffix between the two Kerberos realms creates an implicit certification path between all subordinate realms and the parent realm.

8.1.1 Implementing Cross-Realm Relationships

Establishing a cross-realm trust between two Kerberos realms is rather easy. Microsoft's Active Directory will automatically create implicit trusts between member domains in a forest, so no manual configuration is needed. Those administering MIT- or Heimdal-based Kerberos realms will need to manually create the appropriate Ticket Granting Server principals to create the cross-realm trust, and if the trust is not a cross-realm or hierarchical trust, a certification path will need to be defined in each client's /etc/krb5.conf, as described above.

Each of the two shared keys involved in the cross-realm trust can have a separate secret key associated with it. Currently, the only way to enter a shared key across two MIT or Heimdal Kerberos realms is to use a password, by using the same password for one of the cross-realm principals on both realms. Since these passwords will never have to be used by a human, and the security of the trust depends on the passwords, choose highly secure passwords of at least 16 characters in length that use a combination of printable characters, generated by a good, random password-generator. As an example, let's establish a two-way cross-realm relationship between SAMPLE.COM and EXAMPLE.COM, using MIT Kerberos. First, we must create two secure random passwords—one will be used for the krbtgt/SAMPLE.COM@EXAMPLE.COM principal and the other for the krbtgt/EXAMPLE.COM@SAMPLE.COM principal. Now we can log into each realm through kadmin and create the principals with the passwords:

host.sample.com% kadmin
Authenticating as principal jgarman/admin@SAMPLE.COM with password.
Enter password:
kadmin:  addprinc krbtgt/SAMPLE.COM@EXAMPLE.COM
WARNING: no policy specified for krbtgt/SAMPLE.COM@EXAMPLE.COM; defaulting to no policy
Enter password for principal "krbtgt/SAMPLE.COM@EXAMPLE.COM": abcd
Re-enter password for principal "krbtgt/SAMPLE.COM@EXAMPLE.COM": abcd
Principal "krbtgt/SAMPLE.COM@EXAMPLE.COM" created.
kadmin:  addprinc krbtgt/EXAMPLE.COM@SAMPLE.COM
WARNING: no policy specified for krbtgt/EXAMPLE.COM@SAMPLE.COM; defaulting to no policy
Enter password for principal "krbtgt/EXAMPLE.COM@SAMPLE.COM": defg
Re-enter password for principal "krbtgt/EXAMPLE.COM@SAMPLE.COM": defg
Principal "krbtgt/EXAMPLE.COM@SAMPLE.COM" created.

host.example.com% kadmin
Authenticating as principal jgarman/admin@EXAMPLE.COM with password.
Enter password:
kadmin:  addprinc krbtgt/SAMPLE.COM@EXAMPLE.COM
WARNING: no policy specified for krbtgt/SAMPLE.COM@EXAMPLE.COM; defaulting to no policy
Enter password for principal "krbtgt/SAMPLE.COM@EXAMPLE.COM": abcd
Re-enter password for principal "krbtgt/SAMPLE.COM@EXAMPLE.COM": abcd
Principal "krbtgt/SAMPLE.COM@EXAMPLE.COM" created.
kadmin:  addprinc krbtgt/EXAMPLE.COM@SAMPLE.COM
WARNING: no policy specified for krbtgt/EXAMPLE.COM@SAMPLE.COM; defaulting to no policy
Enter password for principal "krbtgt/EXAMPLE.COM@SAMPLE.COM": defg
Re-enter password for principal "krbtgt/EXAMPLE.COM@SAMPLE.COM": defg
Principal "krbtgt/EXAMPLE.COM@SAMPLE.COM" created.

Remember that Access Control Lists will need to be updated so that users from one realm will be able to access resources in the other.