Internet Security Professional Reference:Kerberos

-->

Authenticators

An authenticator is a record sent using a ticket to a server to certify the client’s knowledge of the encryption key in the ticket, to help the server detect replays, and to help choose a “true session key” to use with the particular session. The encoding is encrypted in the ticket’s session key shared by the client and the server. An authenticator contains the following fields:

Authenticator = {
                 authenticator-vno[0]  INTEGER,
                 crealm[1]             Realm,
                 cname[2]              Principal Name,
                 cksum[3]              Checksum OPTIONAL,
                 cusec[4]              INTEGER,
                 ctime[5]              KerberosTime,
                 subkey[6]             EncryptionKey OPTIONAL,
                 seq-number[7]         INTEGER OPTIONAL,
                 authorization-data[8] AuthorizationData OPTIONAL
                }

Table 9.3 describes the fields in the authenticator.

**Table 9.3**
Authenticator Field Descriptions

Field	Description

authenticator-vno	Specifies the version number for the format of the authenticator.
crealm and cname	Same as described for the ticket.
cksum	Contains a checksum of the application data that accompanies the KRB_AP_REQ.
cusec	Contains the microsecond part of the client’s timestamp (its value ranges from 0 to 999999). Often appears along with ctime, because the two fields are used together to specify a reasonably accurate timestamp.
ctime	Contains the current time on the client’s host.
subkey	Contains the client’s choice for an encryption key to be used to protect this specific application session. Unless an application specifies otherwise, if this field is left out, the session key from the ticket is used.
seq-number (optional)	Includes the initial sequence number to be used by the KRB_PRIV or KRB_SAFE messages when sequence numbers are used to detect replays. (It may also be used by application-specific messages.) When included in the authenticator, this field specifies the initial sequence number for messages from the client to the server. When included in the AP-REP message, the initial sequence number is that for messages from the server to the messages. Incremented by one after each message is sent when used in KRB_PRIV or KRB_SAFE messages.
	For sequence numbers to adequately support the detection of replays, they should be nonrepeating, even across connection boundaries. The initial sequence number should be random and uniformly distributed across the full space of possible sequence numbers, so an attacker cannot guess it and successive sequence numbers do not repeat other sequences.
authorization-data	Same as described for the ticket. Optional, and appears only when additional restrictions are placed on the use of a ticket.

The Authentication Service Exchange

The Authentication Service (AS) exchange between the client and the Kerberos Authentication Server is usually initiated by a client when it wants to obtain authentication credentials for a given server but currently holds no credentials. The client’s secret key is used for encryption and decryption. This exchange typically is used at the initiation of a login session to obtain credentials for a Ticket Granting Server, which will subsequently be used to obtain credentials for other servers without requiring further use of the client’s secret key. This exchange also is used to request credentials for services that must not be mediated through the Ticket Granting Service, but rather require a principal’s secret key, such as the password-changing service. A password-changing request must not be honored unless the requester can provide the old password (the user’s current secret key). Otherwise, it would be possible for someone to walk up to an unattended session and change another user’s password. This exchange does not by itself provide any assurance of the identity of the user.

To authenticate a user logging on to a local system, the credentials obtained in the Authentication Server exchange can first be used in a Ticket Granting Server exchange to obtain credentials for a local server. Those credentials must then be verified by the local server through successful completion of the Client/Server exchange.

Note: The exchange consists of two messages: KRB_AS_REQ from the client to Kerberos, and KRB_AS_REP or KRB_ERROR in reply.

In the request, the client sends (in cleartext) its own identity and the identity of the server for which it is requesting credentials. The response, KRB_AS_REP, contains a ticket for the client to present to the server, and a session key to be shared by the client and the server. The session key and additional information are encrypted in the client’s secret key.

The KRB_AS_REP message contains information that can be used to detect replays and associate it with the message to which it replies. Various errors can occur, indicated by an error response (KRB_ERROR) rather than the KRB_AS_REP response. The error message is not encrypted. The KRB_ERROR message also contains information that can be used to associate it with the message to which it replies. The lack of encryption in the KRB_ERROR message precludes the capability to detect replays or fabrications of such messages.

Usually, the Authentication Server does not know whether the client truly is the principal named in the request. It simply sends a reply without knowing or caring whether they are the same—which is acceptable because nobody but the principal whose identity was given in the request can use the reply. Its critical information is encrypted in that principal’s key. The initial request supports an optional field that can be used to pass additional information that might be needed for the initial exchange. This field can be used for preauthentication, but the mechanism is not currently specified.

Table of Contents