Receipt of a KRB_TGS_REQ Message

The KRB_TGS_REQ message is processed in a manner similar to the KRB_AS_REQ message. However, there are many additional checks to be performed. The Kerberos server must determine the server for which the accompanying ticket is destined and select the appropriate key to decrypt it. Usually, it’s for the Ticket Granting Service and the Ticket Granting Service’s key is used. If another realm issued the Ticket Granting Ticket, then the appropriate inter-realm key must be used. If the accompanying ticket is for an application server in the current realm, and the RENEW, VALIDATE, or PROXY options are specified in the request, and the server for which a ticket is requested is the server named in the accompanying ticket, then the Key Distribution Center uses the key of the application server to decrypt the ticket in the authentication header. If no ticket can be found in the padata field, the KDC_ERR_PADATA_TYPE_NOSUPP appears.

After the accompanying ticket has been decrypted, the user-supplied checksum in the Authenticator must be verified against the contents of the request. The message is rejected if the checksums do not match (with an error code of KRB_AP_ERR_MODIFIED) or if the checksum is not keyed or not collision-proof (with an error code of KRB_AP_ERR_INAPP_CKSUM). If the checksum type is not supported, the KDC_ERR_SUMTYPE_NOSUPP error is returned. If the authorization-data are present, they are decrypted using the subsession key from the Authenticator.

If any of the decryptions indicate failed integrity checks, the KRB_AP_ERR_BAD_INTEGRITY error is returned.

Generation of a KRB_TGS_REP Message

The KRB_TGS_REP includes a ticket for the requested server. The Kerberos database is queried to retrieve the record for the requested server, including the key with which the ticket is to be encrypted. If the request is for a Ticket Granting Ticket for a remote realm, and if no key is shared with the requested realm, then the Kerberos server selects the realm closest to the requested realm with which it does share a key, and uses that realm. This is the only case in which the response from the Key Distribution Center is for a different server than that requested by the client.

By default, the address field, the client’s name and realm, the list of transited realms, the time of initial authentication, the expiration time, and the authorization data of the newly issued ticket are copied from the Ticket Granting Ticket or renewable ticket. If the transited field needs to be updated, but the transited type is not supported, the KDC_ERR_TRTYPE_NOSUPP error is returned.

If the request specifies an end time, then the end time of the new ticket is set to the minimum of the following:

•  That request.

•  The end time from the Ticket Granting Ticket.

•  The start time of the Ticket Granting Ticket plus the minimum of the maximum life for the application server and the maximum life for the local realm. The maximum life for the requesting principal was already applied when the Ticket Granting Ticket was issued.

If the new ticket is to be renewed, then the preceding end time is replaced by the minimum of the following:

•  The value of the renew_till field of the ticket

•  The start time for the new ticket plus the life (end time-start time) of the old ticket

If the FORWARDED option has been requested, then the resulting ticket contains the addresses specified by the client. This option is honored only if the FORWARDABLE flag is set in the Ticket Granting Ticket. The PROXY option is similar. The resulting ticket contains the addresses specified by the client. It is honored only if the PROXIABLE flag in the Ticket Granting Ticket is set. The PROXY option is not honored on requests for additional Ticket Granting Tickets.

If the requested start time is absent or indicates a time in the past, then the start time of the ticket is set to the authentication server’s current time. If it indicates a time in the future, but the POSTDATED option has not been specified or the MAY-POSTDATE flag is not set in the Ticket Granting Ticket, then the error KDC_ERR_CANNOT_POSTDATE is returned. Otherwise, if the Ticket Granting Ticket has the MAY-POSTDATE flag set, then the resulting ticket will be postdated and the requested start time is checked against the policy of the local realm. If acceptable, the ticket’s start time is set as requested, and the INVALID flag is set. The postdated ticket must be validated before use by presenting it to the Key Distribution Center after the start time has been reached. However, in no case may the start time, end time, or renew-till time of a newly issued postdated ticket extend beyond the renew_till time of the Ticket Granting Ticket.

If the ENC-TKT-IN-SKEY option has been specified and an additional ticket has been included in the request, the Key Distribution Center will decrypt the additional ticket using the key for the server to which the additional ticket was issued and verify that it is a Ticket Granting Ticket. If the name of the requested server is missing from the request, the name of the client in the additional ticket will be used. Otherwise the name of the requested server will be compared to the name of the client in the additional ticket and if different, the request will be rejected. If the request succeeds, the session key from the additional ticket will be used to encrypt the new ticket that is issued instead of using the key of the server for which the new ticket will be used. This enables easy implementation of user-to-user authentication, which uses Ticket Granting Ticket session keys instead of secret server keys in situations where such secret keys could be easily compromised.

If the RENEW option is requested, then the Key Distribution Center will verify that the RENEWABLE flag is set in the ticket and that the renew_till time is still in the future. If the VALIDATE option is requested, the Key Distribution Center will check that the start time has passed and the INVALID flag is set. If the PROXY option is requested, then the Key Distribution Center will check that the PROXIABLE flag is set in the ticket. If the tests succeed, the Key Distribution Center will issue the appropriate new ticket.