If the first component of a name identifies a service and the remaining components identify an instance of the service in a server-specified manner, then the name type of SRV-INST should be used. An example of this name type is the Kerberos Ticket Granting Ticket that has a first component of krbtgt and a second component that identifies the realm for which the ticket is valid.

If an instance is a single component following the service name and the instance identifies the host on which the server is running, then the name type SRV-HST should be used. This type typically is used for Internet services such as Telnet and the Berkeley R commands. If the separate components of the host name appear as successive components following the name of the service, then the name type SRVXHST should be used. This type might be used to identify servers on hosts with X.500 names where the slash (/) might otherwise be ambiguous.

A name type of UNKNOWN should be used when the form of the name is not known. When comparing names, a name type of UNKNOWN matches principals authenticated with names of any type. A principal authenticated with a name type of UNKNOWN, however, matches only other name types of UNKNOWN.

Name of Server Principals

The principal identifier for a server on a host generally is composed of the following two parts:

•  The realm of the Key Distribution Center with which the server is registered

•  A two-component name of type NT-SRV-HST if the host name is an Internet domain name, or a multicomponent name of type NT-SRV-XHST if the name of the host is of a form that permits slash (/) separators, such as X.500

The first component of the multicomponent name identifies the service and the latter components identify the host. Where the name of the host is not case-sensitive (for example, with Internet domain names), the name of the host must be lowercase. For services such as Telnet and the Berkeley R commands that run with system privileges, the first component is the string “host” rather than a service-specific identifier.

Cross-Realm Operation

The Kerberos protocol is designed to operate across organizational boundaries. A client in one organization can be authenticated to a server in another. Each organization that wants to run a Kerberos server establishes its own realm. The name of the realm in which a client is registered is part of the client’s name, and can be used by the end-service to decide whether to honor a request.

By establishing inter-realm keys, the administrators of two realms can enable a client authenticated in the local realm to use its authentication remotely. With appropriate permission, the client could arrange registration of a separately named principal in a remote realm and engage in normal exchanges with that realm’s services. For even small numbers of clients, however, this becomes cumbersome, and more automatic methods are necessary. The exchange of inter-realm keys (a separate key may be used for each direction) registers the Ticket Granting Service of each realm as a principal in the other realm. A client then can obtain a Ticket Granting Ticket for the remote realm’s Ticket Granting Service from its local realm. When that Ticket Granting Ticket is used, the remote Ticket Granting Service uses the inter-realm key, which usually differs from its own normal Ticket Granting Server key, to decrypt the Ticket Granting Ticket. It thereby can be certain that it was issued by the client’s own Ticket Granting Server. Tickets issued by the remote Ticket Granting Service let the end-service know that the client was authenticated from another realm.

A realm is said to communicate with another realm if the two realms share an inter-realm key or if the local realm shares an inter-realm key with an intermediate realm that communicates with the remote realm. An authentication path is the sequence of intermediate realms transited in communicating from one realm to another.

Realms typically are organized hierarchically. Each realm shares a key with its parent and a different key with each child. If an inter-realm key is not directly shared by two realms, the hierarchical organization permits an authentication path to be constructed. If a hierarchical organization is not used, it might be necessary to consult some databases before constructing an authentication path between realms is possible. If there is regular communication between two realms that are not directly connected in the hierarchy, they can set up a direct key between the two realms. Figure 9.3 shows a corporate hierarchy with the links between systems representing a connection with a shared key. Note that there is a direct connection between ProjectW.RESEARCH.ABC.COM and ProjectW.PAYROLL.ABC.COM. Any time a connection will see significant data flows, an inter-realm key can be created and shared between the servers.

Figure 9.3  A corporate hierarchy with shared key.

Although realms typically are hierarchical, intermediate realms can be bypassed to achieve cross-realm authentication through alternative authentication paths. These might be established to make communication between two realms more efficient. The end-service needs to know which realms were transited when deciding how much faith to place in the authentication process. To facilitate this decision, a field in each ticket contains the names of the realms involved in authenticating the client.