Realm Names

Although realm names are encoded as GeneralStrings and although a realm technically can select any name it chooses, interoperability across realm boundaries requires agreement on how realm names are to be assigned and what information they imply.

To enforce these conventions, each realm must conform to the conventions. It must require that any realms with which inter-realm keys are shared also conform to the conventions and require the same from its neighbors.

Presently, the four styles of realm names are domain, X.500, other, and reserved. Examples of each style follow:

  domain:     host.subdomain.domain
    X500:     C=US/O=OSF
   other:     NAMETYPE:rest/of.name=without-restrictions
reserved:     reserved, but will not conflict with above

The most common type of name in use is the domain name. Domain names must look like Internet domain names. They consist of components separated by periods (.) and contain neither colons (:) nor slashes (/).

Some organizations use X.500 names to remain consistent with other naming conventions in use within the organization. X.500 names contain an equal sign (=) and cannot contain a colon (:) before the equal sign. The realm names for X.500 names are string representations of the names with components separated by slashes (leading and trailing slashes not included).

In case your organization wants to use an unusual naming convention, Kerberos allows for implementation-specific naming systems. Names that fall into the other category must begin with a prefix that contains no equal sign (=) or period (.) and the prefix must be followed by a colon (:) and the rest of the name. All prefixes must be assigned before they may be used. Presently none are assigned.

Finally, a category of names is left for future use. The reserved category includes strings that do not fall into the first three categories. All names in this category are reserved. Names are unlikely to be assigned to this category unless a very strong argument exists for not using the “other” category.

These rules guarantee no conflicts between the various name styles. The following additional constraints apply to assigning realm names in the domain and X.500 categories. The name of a realm for the domain or X.500 formats must be used by organizations that own an Internet domain name or X.500 name. If no such names are registered, authority to use a realm name may be derived from the authority of the parent realm. If E40.MIT.EDU lacks a domain name, for example, the administrator of the MIT.EDU realm can authorize the creation of a realm of that name.

This is acceptable because the organization to which the parent is assigned presumably is the organization authorized to assign names to its children in the X.500 and domain name systems as well. If the parent assigns a realm name without also registering it in the domain name or X.500 hierarchy, the parent is responsible for ensuring that a name identical to the realm name of the child does not exist in the future unless assigned to the child.

Principal Names

As was the case for realm names, conventions are needed to ensure that all agree on what information is implied by a principal name. The name-type field that is part of the principal name indicates the kind of information implied by the name. The name type should be treated as a hint. Ignoring the name type, no two names can be the same. At least one of the components, or the realm, must be different. An example of a principal name is a username of JSmith. It would have a type of NT-PRINCIPAL, and the realm name of RESEARCH. ABC.COM (domain name style) would be considered to be a part of the principal name. The following name types are defined:

When a name implies no information other than its uniqueness at a particular time, the name type PRINCIPAL should be used. The principal name type should be used for users, and it also might be used for a unique server. If the name is a unique machine-generated ID guaranteed never to be reassigned, then the name type of UID should be used. Reassigning names of any type generally is a bad idea because stale entries might remain in Access Control Lists. Reassigned names could acquire rights to information that were not intended. This problem is called object reuse because the new owner of the name gets to use the information as a result of the previous owner of the name having rights to use the object.