Whenever a request is made to the Ticket Granting Server, the presented ticket(s) is checked against a hot-list of tickets that have been canceled. This hot-list might be implemented by storing a range of issue dates for “suspect tickets.” If a presented ticket had an authtime in that range, it would be rejected. In this way, a stolen Ticket Granting Ticket or renewable ticket cannot be used to gain additional tickets (renewals or otherwise) once the theft has been reported. Any normal ticket obtained before it was reported stolen will still be valid, but only until the normal expiration time.

The ciphertext part of the response in the KRB_TGS_REP message is encrypted in the sub-session key from the Authenticator, if present, or the session key from the Ticket Granting Ticket. It is not encrypted using the client’s secret key. Furthermore, the client’s key’s expiration date and the key version number fields are left out because these values are stored along with the client’s database record, and that record is not needed to satisfy a request based on a Ticket Granting Ticket.

Encoding the Transited Field

If the identity of the server in the Ticket Granting Ticket that is presented to the Key Distribution Center as part of the authentication header is that of the Ticket Granting Service, but the Ticket Granting Ticket was issued from another realm, the Key Distribution Center looks up the inter-realm key shared with that realm and uses that key to decrypt the ticket. If the ticket is valid, the Key Distribution Center honors the request, subject to the constraints outlined earlier in the section describing the Authentication Server exchange.

The realm part of the client’s identity is taken from the Ticket Granting Ticket. The name of the realm that issued the Ticket Granting Ticket is added to the transited field of the ticket to be issued. This is accomplished by reading the transited field from the Ticket Granting Ticket, adding the new realm to the set, then constructing and writing out its encoded (shorthand) form. This may involve a rearrangement of the existing encoding.

The Ticket Granting Service does not add the name of its own realm. Instead, its responsibility is to add the name of the previous realm. This prevents a malicious Kerberos server from intentionally leaving out its own name. It could, however, omit other realms’ names.

The names of neither the local realm nor the principal’s realm are included in the transited field. They appear elsewhere in the ticket and both are known to have taken part in authenticating the principal. Because the endpoints are not included, both local and single-hop inter-realm authentication result in an empty transited field.

Because the name of each realm transited is added to this field, it can become very long. To decrease the length of this field, its contents are encoded. The initially supported encoding is optimized for the normal case of inter-realm communication, a hierarchical arrangement of realms using domain or X.500 style realm names. This encoding is called DOMAIN-X500-COMPRESS.

Receipt of a KRB_TGS_REP Message

After the client receives the KRB_TGS_REP, it processes it in the same manner as the KRB_AS_REP processing described earlier. The primary difference is that the ciphertext part of the response must be decrypted using the session key from the Ticket Granting Ticket rather than the client’s secret key.

Specifications for the Authentication Server and Ticket Granting Service Exchanges

This section specifies the format of the messages used in exchange between the client and the Kerberos server.

Key Distribution Center Option Flags

Requests to the Key Distribution Center can be accompanied by a list of optional requests. These options indicate the flags that the client wants set on the tickets, as well as other information to modify the behavior of the Key Distribution Center. Options are specified in a bit field, kdc_options.

Where appropriate, the name of an option may be the same as the flag set by that option. Although the bit in the options field usually is the same as that in the flags field, this is not guaranteed. Table 9.4 describes the Key Distribution Center options.