The KRB_TGS_REP message shares its format with the KRB_AS_REP
(KRB_KDC_REP), but with its type field set to KRB_TGS_REP. The
detailed specification is in section 5.4.2.
The response will include 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 will 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 will select the realm "closest" to the requested realm with
which it does share a key, and use that realm instead. This is the
only case where the response from the KDC will be 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 will be copied from the ticket-granting ticket (TGT) 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 endtime, then the endtime of the new
ticket is set to the minimum of (a) that request, (b) the endtime
from the TGT, and (c) the starttime of the TGT 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 TGT was issued). If the new ticket is to be
a renewal, then the endtime above is replaced by the minimum of (a)
the value of the renew_till field of the ticket and (b) the starttime
for the new ticket plus the life (endtimestarttime) of the old
ticket.
If the FORWARDED option has been requested, then the resulting ticket
will contain the addresses specified by the client. This option will
only be honored if the FORWARDABLE flag is set in the TGT. The PROXY
option is similar; the resulting ticket will contain the addresses
specified by the client. It will be honored only if the PROXIABLE
flag in the TGT is set. The PROXY option will not be 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 TGT, then the error KDC_ERR_CANNOT_POSTDATE is
returned. Otherwise, if the ticket-granting ticket has the
MAYPOSTDATE flag set, then the resulting ticket will be postdated and
the requested starttime 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 KDC after the starttime has been
reached. However, in no case may the starttime, endtime, 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 KDC 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 allows easy implementation of user-to-
user authentication [6], which uses ticket-granting ticket session
keys in lieu of secret server keys in situations where such secret
keys could be easily compromised.).
If the name of the server in the ticket that is presented to the KDC
as part of the authentication header is not that of the ticket-
granting server itself, and the server is registered in the realm of
the KDC, If the RENEW option is requested, then the KDC 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 rqeuested,
the KDC will check that the starttime has passed and the INVALID flag
is set. If the PROXY option is requested, then the KDC will check
that the PROXIABLE flag is set in the ticket. If the tests succeed,
the KDC will issue the appropriate new ticket.
Whenever a request is made to the ticket-granting server, the
presented ticket(s) is(are) checked against a hot-list of tickets
which 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 (because they require no
interaction with the KDC), but only until their 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 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
since 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. See section A.6 for pseudocode.
