The server computes the age of the ticket: server time minus the start time inside the Ticket. If the start time is later than the current time by more than the allowable clock skew or if the INVALID flag is set in the ticket, the KRB_AP_ERR_TKT_NYV error is returned. Otherwise, if the current time is later than the end time by more than the allowable clock skew, the KRB_AP_ERR_TKT_EXPIRED error is returned.

If all these checks succeed without an error, the server is assured that the client possesses the credentials of the principal named in the ticket and thus, the client has been authenticated to the server.

Generation of a KRB_AP_REP Message

Typically, a client’s request includes both the authentication information and its initial request in the same message. The server need not explicitly reply to the KRB_AP_REQ. If mutual authentication is being performed, however, the KRB_AP_REQ message will have MUTUAL-REQUIRED set in its ap-options field. Then a KRB_AP_REP message is required in response. As with the error message, this message can be encapsulated in the application protocol if its raw form is unacceptable to the application’s protocol. The timestamp and microsecond field used in the reply must be the client’s timestamp and microsecond field, as provided in the Authenticator. If a sequence number is to be included, it should be chosen randomly, as described earlier for the Authenticator. A subkey can be included if the server desires to negotiate a different subkey. The KRB_AP_REP message is encrypted in the session key extracted from the ticket.

Receipt of a KRB_AP_REP Message

If a KRB_AP_REP message is returned, the client uses the session key from the credentials obtained for the server to decrypt the message, and then verifies that the timestamp and microsecond fields match those in the Authenticator it sent to the server. If they match, the client is assured that the server is genuine. The sequence number and subkey, if present, are retained for later use.

Using the Encryption Key

After the KRB_AP_REQ/KRB_AP_REP exchange has occurred, the client and server share an encryption key that can be used by the application. The “true session key” to be used for KRB_PRIV, KRB_SAFE, or other application-specific purposes can be chosen by the application based on the subkeys in the KRB_AP_REP message and the Authenticator. In some cases, the use of this session key is implicit in the protocol. In other cases, the method of use must be chosen from several alternatives.

With both the one-way and mutual authentication exchanges, the peers should take care not to send sensitive information to each other without proper assurances. In particular, applications that require privacy or integrity should use the KRB_AP_REP or KRB_ERROR responses from the server to client to assure both client and server of their peer’s identity. If an application protocol requires privacy of its messages, it can use the KRB_PRIV message. The KRB_SAFE message can be used to assure integrity.

Client/Server (CS) Message Specifications

This section specifies the format of the messages used for the authentication of the client to the application server.

KRB_AP_REQ Definition

The KRB_AP_REQ message contains the Kerberos protocol version number, the message type KRB_AP_REQ, an options field to indicate any options in use, and the ticket and authenticator themselves. The KRB_AP_REQ message is often referred to as the authentication header.

   AP-REQ = {
               pvno[0]                       INTEGER,
               msg-type[1]                   INTEGER,
               ap-options[2]                 APOptions,
               ticket[3]                     Ticket,
               authenticator[4]              EncryptedData
            }

   APOptions = BIT STRING {
               reserved(0),
               use-session-key(1),
               mutual-required(2),
               reserved(3-31)
                          }

Table 9.7 describes the fields in this message.