The Client/Server Authentication Exchange

Network applications use the client/server (CS) authentication exchange to authenticate the client to the server and vice versa. The client must already have acquired credentials for the server using the Authentication Server or Ticket Granting Server exchange.

---

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

---

The KRB_AP_REQ Message

The KRB_AP_REQ contains authentication information that should be part of the first message in an authenticated transaction. It contains a ticket, an authenticator, and some additional bookkeeping information. The ticket by itself is insufficient to authenticate a client, because tickets are passed across the network in cleartext. Tickets contain an encrypted and an unencrypted portion, so cleartext here refers to the entire unit. Tickets can be copied from one message and replayed in another without any cryptographic skill. The Authenticator is used to prevent invalid replay of tickets by proving to the server that the client knows the session key of the ticket and thus is entitled to use it. The KRB_AP_REQ message is referred to elsewhere as the “authentication header.”

Generation of a KRB_AP_REQ Message

When a client wants to initiate authentication to a server, it obtains a ticket and session key for the desired service. The client can reuse any tickets it holds until they expire. The client then constructs a new Authenticator from the system time, its name, optionally, an application-specific checksum, an initial sequence number to be used in KRB_SAFE or KRB_PRIV messages, and/or a session subkey to be used in negotiations for a session key unique to this particular session.

Authenticators may not be reused and are rejected if replayed to a server. This can make applications based on unreliable transports, such as UDP, difficult to code correctly. In such cases, a new Authenticator must be generated for each retry. If a sequence number is to be included, it should be chosen randomly so that even after many messages have been exchanged, collision with other sequence numbers in use is not likely.

The client can indicate a requirement of mutual authentication or the use of a session-key based ticket by setting the appropriate flag(s) in the ap-options field of the message.

The Authenticator is encrypted in the session key and combined with the ticket to form the KRB_AP_REQ message that is then sent to the end server along with any additional application-specific information.

Receipt of a KRB_AP_REQ Message

Authentication is based on the server’s current time of day (clocks must be loosely synchronized), the Authenticator, and the ticket. If an error occurs, the server is expected to reply to the client with a KRB_ERROR message. This message can be encapsulated in the application protocol if its “raw” form is not acceptable to the protocol.

There are several checks the server makes to verify the authentication. If the message type is not KRB_AP_REQ, the server returns the KRB_AP_ERR_MSG_TYPE error. If the key version indicated by the ticket in the KRB_AP_REQ is not one the server can use, the KRB_AP_ERR_BADKEYVER error is returned. If the USE-SESSION-KEY flag is set in the ap-options field, it indicates to the server that the ticket is encrypted in the session key from the server’s Ticket Granting Ticket rather than its secret key. Because it is possible for the server to be registered in multiple realms, with different keys in each, the srealm field in the unencrypted portion of the ticket in the KRB_AP_REQ is used to specify which secret key the server should use to decrypt that ticket. The KRB_AP_ERR_NOKEY error code is returned if the server doesn’t have the proper key to decipher the ticket.

The ticket is decrypted using the version of the server’s key specified by the ticket. If the decryption routines detect a modification of the ticket, the KRB_AP_ERR_BAD_INTEGRITY error is returned. In this case, chances are good that different keys were used to encrypt and decrypt.

The authenticator is decrypted using the session key extracted from the decrypted ticket. If decryption shows it to have been modified, the KRB_AP_ERR_BAD_INTEGRITY error is returned. The name and realm of the client from the ticket are compared against the same fields in the Authenticator.

If, on the other hand, they don’t match, the KRB_AP_ERR_BADMATCH error is returned. They might not match, for example, if the wrong session key was used to encrypt the Authenticator. The addresses in the ticket (if any) are then searched for an address that matches the operating–system-reported address of the client. If no match is found or the server insists on ticket addresses when none are present in the ticket, the KRB_AP_ERR_BADADDR error is returned.

If the server time and the client time in the authenticator differ by more than the allowable clock skew (5 minutes), the KRB_AP_ERR_SKEW error is returned. If the server name along with the client name, time, and microsecond fields from the Authenticator match any recently seen such tuples, the KRB_AP_ERR_REPEAT error is returned.

The rejection here is restricted to Authenticators from the same principal to the same server. Other client principals communicating with the same server principal should not have their Authenticators rejected if the time and microsecond fields happen to match some other client’s authenticator.

The server must remember any authenticator presented within the allowable clock skew, so that a replay attempt is guaranteed to fail. If a server loses track of any authenticator presented within the allowable clock skew, it will reject all requests until the clock skew interval has passed. This assures that any lost or replayed authenticators will fall outside the allowable clock skew and can no longer be successfully replayed. If this is not done, an attacker could conceivably record the ticket and authenticator sent over the network to a server.

It could then disable the client’s host, pose as the disabled host, and replay the ticket and authenticator to subvert the authentication. If a sequence number is provided in the Authenticator, the server saves it for later use in processing KRB_SAFE and/or KRB_PRIV messages. If a subkey is present, the server saves it for later use or uses it to help generate its own choice for a subkey to be returned in a KRB_AP_REP message.