Internet Security Professional Reference:Kerberos

-->

Names

Kerberos realms are encoded as GeneralString. Realms cannot contain a character that has the code 0 (the ASCII NULL). Most realms consist of several components separated by periods (.) in the style of Internet domain names or separated by slashes (/) in the style of X.500 names. A PrincipalName is a sequence of components consisting of the following subfields:

Realm =           GeneralString

PrincipalName =   {
             name-type[0]    INTEGER,
             name-string[1]  GeneralString
                  }

The principal name encoding consists of the following two fields:

• name-type. Specifies the type of name that follows.

• name-string. Encodes a sequence of components that form a name. Each component is encoded as a GeneralString. Taken together, a PrincipalName and a Realm form a principal identifier. Most PrincipalNames will have only a few components, typically one or two. No two names can be the same. At least one of the components, or the realm, must be different.

Time

The timestamps used in Kerberos are encoded as GeneralizedTime. An encoding specifies the UTC time zone (Z) and cannot include any fractional portions of the seconds. It further cannot include any separators. Example: The only valid format for UTC time 6 minutes, 27 seconds after 9 PM on 6 November 1985 is 19851106210627Z.

Host Addresses

Kerberos messages usually contain a reference to a specific host, or a list of hosts. That reference is stored as a host address. A host address is a sequence of components consisting of the following subfields:

HostAddress =  {
             addr-type[0]    INTEGER,
             address[1]      BYTE STRING
               }

HostAddresses = {
             addr-type[0]    INTEGER,
             address[1]      BYTE STRING
                }

The host address encoding consists of the following two fields:

• addr-type. Specifies the type of address that follows.

• address. Encodes a single address of type addr-type.

The two forms differ slightly. HostAddress contains exactly one address. HostAddresses contains a sequence of many possible addresses.

Authorization Data

Kerberos messages contain authorization data, which is a sequence of components consisting of the following subfields:

AuthorizationData =  {
             ad-type[0]    INTEGER,
             ad-data[1]    BYTE STRING
                     }

The authorization data encoding consists of the following two fields:

• ad-type. Specifies the format for the ad-data subfield. All negative values are reserved for local use. Non-negative values are reserved for registered use.

• ad-data. Contains authorization data to be interpreted according to the value of the corresponding ad-type field.

Last Request Data

As a part of the Authentication Server transaction, a last request field is returned. The contents of this field should be displayed to users to enable them to detect unauthorized use of their account. The last request is a sequence of components consisting of the following subfields:

LastReq = {
             lr-type[0]               INTEGER,
             lr-value[1]              KerberosTime
            }

Table 9.12 describes the fields in this message.

**Table 9.12**
Last Request Fields

Field	Description

lr-type	Indicates how the following lr-value field is to be interpreted. Negative values indicate that the information pertains only to the responding server. Non-negative values pertain to all servers for the realm.
	0	No information conveyed by lr-value subfield.
	1	Time of last initial request for a Ticket Granting Ticket.
	2	Time of last initial request.
	3	Time of issue for newest Ticket Granting Ticket used.
	4	Time of last renewal.
	5	Time of last request of any type.
lr-value	Contains the time of the last request. The time must be interpreted according to the contents of the accompanying lr-type subfield.

Error Message Specification

This section specifies the format for the KRB_ERROR message. The fields included in the message are intended to return as much information as possible about an error. Don’t expect all the information required by the fields to be available for all types of errors. If the appropriate information is not available during composition of the message, the corresponding field is left out of the message.

Because the KRB_ERROR message is not protected by any encryption, an intruder could synthesize or modify such a message. In particular, this means that the client should not use any fields in this message for security-critical purposes, such as setting a system clock or generating a fresh Authenticator. The message can be useful, however, for advising a user on the reason for some failure.

Table of Contents