Kerberos Ticket Granting Service (TGS) requests are one of the most complicated areas of processing in MIT krb5, in both the client and the KDC. Here are some notes on the different kind of TGS requests and what considerations must be made when processing them.
Like an AS request, a TGS request contains a KDC-REQ-BODY sequence and a sequence of PA-DATA. One of the pa-data elements will have type PA-TGS-REQ; its value will contain an AP-REQ, the same protocol structure a client would use to authenticate to an application server. The ticket in the AP-REQ is called the "header ticket" within the MIT KDC source code, because RFC 4120 uses the term "authentication header" to refer to the AP-REQ.
The authenticator in the AP-REQ contains a checksum over the encoding of the body. This checksum need not be keyed, as it is contained within an encrypted payload, but with modern encryption types it is usually a keyed checksum anyway. There is no intrinsic cryptographic binding between other padata elements and the PA-TGS-REQ or the body.
The authenticator in the AP-REQ may contain a subkey, in which case the TGS response should be encrypted in the subkey. Otherwise it should be encrypted in the session key of the header ticket. There are four historical interoperability bugs affecting the use of subkeys in TGS requests, as described here:
https://mailarchive.ietf.org/arch/msg/krb-wg/DD8CFMuWiHJhkkoHGbjx0Z1dpKo https://mailarchive.ietf.org/arch/msg/krb-wg/4qhYxn7iovCnfsHL8wmim7-8Tq0 https://mailarchive.ietf.org/arch/msg/krb-wg/hl6PvUz94IQMFadSybnjGYeBCCE
TGS requests may use FAST implicit armor (RFC 6113 section 5.4). In this case one of the pa-data elements will have type PA-FX-FAST and its value will contain a second copy of the TGS request encrypted in a key derived from the subkey (which must be present) and the ticket session key.
Types of TGS requests
- Ticket modification
- S4U2Self (aka "protocol transition")
- S4U2Proxy (aka "constrained delegation"): if the CNAME-IN-ADDL-TICKET option is requested, the request body must contain an additional ticket (called the "evidence ticket") from a user to the requesting service--or, for a cross-realm request, a cross-TGT containing a PAC or equivalent authorization data for a user. If delegation is allowed to the requested server, the KDC issues a ticket from the evidence ticket client (or the client named in the PAC) to the requested server. S4U2Proxy is specified in the same document as S4U2Self.
Normal TGS requests
For the purposes of this article, a TGS request is considered "normal" if it:
- does not have any of the forwarded, proxy, renew, validate, enc-tkt-in-skey, or cname-in-addl-tkt options
- does not contain PA-FOR-USER or PA_S4U_X509_USER pa-data.
The header ticket for a normal TGS request server have an sname field of krbtgt/THIS.REALM, where THIS.REALM must match the realm field of the TGS request. If the header ticket is a cross-realm TGT (the ticket's srealm field is some OTHER.REALM different from THIS.REALM), the ticket's crealm must also be different from THIS.REALM; this is called the "lineage check", and ensures that foreign realms cannot issue tickets for local users. The KDC also (unless requested not to) checks the transited list in the ticket to ensure that OTHER.REALM has the authority to issue tickets for the realm of the header ticket client, and adds OTHER.REALM to the transited list of the issued ticket if it does not match the realm of the header ticket client.
If the requested server is a TGS principal for a different realm, the KDC may issue a ticket to an alternative TGS principal for an intermediate realm instead. If the requested server is not a TGS server but the request has the "canonicalize" KDC option set (RFC 6803 section 3), the KDC may issue a ticket to an outgoing TGS principal; this is called a "referral".
For local clients, some KDC implementations look up the client DB entry and apply the entry's policy in case it has changed (e.g. the account has been revoked). The MIT krb5 KDC does not currently do this.
It is possible for an otherwise normal TGS request to be part of a cross-realm Resource-Based Constrained Delegation (RBCD) operation transiting through this realm. In this case, the header ticket will be a cross-realm TGT, the request server will be a cross-realm TGS, the header ticket PAC will contain an S4U_DELEGATION_INFO buffer giving the ticket client as the last transited service, and the PAC_CLIENT_INFO buffer will contain a realm part in the name. These requests can be processed the same way as a normal TGS request, but when issuing a PAC for the resulting ticket the KDC must copy the PAC_CLIENT_INFO buffer from the header ticket rather than creating one for the ticket client.
Ticket modification requests
A ticket modification request has the forwarded, proxy, renew, or validate option. The header ticket is not required to be a TGT, and must not be a TGT if the proxy option is requested. The request sname must match the ticket sname, and the KDC must not be issuing a referral. The header ticket must have a flag corresponding to the requested option (forwardable for forwarded, etc.) The issued ticket will be similar in most respects to the header ticket, except for the addresses, validity times, and invalid flag as indicated by the request option.
If the enc-tkt-in-skey option is requested, the request must contain a second ticket in the additional-tickets field. The second ticket must be a local-realm TGT for the server realm (krbtgt/THIS.REALM@THIS.REALM), and the second ticket cname and crealm must match the request sname and realm. The request is processed similarly to a normal request, but the resulting ticket will be encrypted in the session key of the second ticket, and will have a session key of the same type as the second ticket's. User-to-user requests cannot generate referrals.
S4U2Self (protocol transition) requests
If the request pa-data contains an element of type PA-FOR-USER or PA_S4U_X509_USER or both, it is a request to issue a ticket from a named user (known as the "subject") to the requesting service. The subject may be identified by principal or by X.509 certificate. S4U2Self requests do not require special privileges, although in some cases the forwardable flag will be cleared on the resulting ticket. S4U2Self requests must not contain any options for other kinds of special TGS requests (ticket modification, user-to-user, and S4U2Proxy).
For a local-realm S4U2Self requests, the request server must match the header ticket client, although they may use different aliases for the same principal. A PAC must be present in the header ticket, although it is not used as a basis for the PAC in the issued ticket. The subject is looked up in the database, checked for policy constraints, and a PAC is issued for it as it would be for an AS request. Authentication indicators are not copied from the header ticket, as there was no actual authentication of the subject.
For cross-realm S4U2Self scenarios, there are four different kinds of requests:
1. Zero or more AS requests to determine the subject realm, if it is not already known. These may be ordinary AS requests, but they may also contain PA_S4U_X509_USER if the user is identified by a certificate. The requesting service begins at the service realm and follows the chain of KDC_ERR_WRONG_REALM errors until a KDC_ERR_PREAUTH_REQUIRED error is received or a ticket is issued, indicating that the subject realm is known. The requesting server then obtains a cross-realm TGT to the subject realm using ordinary TGS requests.
2. A cross-realm S4U2Self request to the subject realm. Since the requesting service does not live in this realm, the request server will contain the representation of a requesting service as an enterprise principal. As for a local S4U2Self request, the subject realm KDC looks up the subject in the database, checks it for policy constraints, and constructs a PAC for the subject. Unlike a local request, the PAC_CLIENT_INFO name in the PAC will contain an "@REALM" suffix identifying the subject realm, and the KDC issues a referral TGT back towards the service realm. The reply includes PA_S4U_X509_USER naming the subject principal, in case a certificate was used to identify it.
3. Zero or more cross-realm S4U2Self requests to intermediate realms along the path back to the service realm, each resulting in a referral TGT. The S4U2Self padata in these requests must contain the subject principal name; the subject can no longer be identified by certificate at this step. As in step 2, the PAC in the issued referral TGTs must be for the subject and must contain an "@REALM" suffix in the PAC_CLIENT_INFO name.
4. A cross-realm S4U2Self request to the service realm. This type of request would ordinarily fail the lineage check (as the client is in the local realm and the TGT was issued by another realm), so S4U2Self requests are excepted from this check. The service realm KDC issues a ticket from the subject to the requesting service, using the PAC in the the referral ticket as a basis. However, the PAC_CLIENT_INFO name for the PAC does not contain the "@REALM" suffix.
S4U2Self requests override the no_authdata_required flag on the requesting service principal. Although the service may not require authorization data for tickets received from clients, its use of S4U2Self strongly suggests the need for a PAC--either the service plans to make an S4U2Proxy request, or it has a special need to inspect the PAC for a subject.
If the requesting service has any outgoing constrained delegation privileges, but does not have the ok_to_auth_as_delegate principal flag, then the forwardable ticket flag will be suppressed on tickets issued to it via S4U2Self. The intent is to prevent the use of S4U2Self-issued tickets as S4U2Proxy evidence tickets without this extra privilege when outgoing authorizations are used (but not when the delegation is allowed by an incoming authorization on the delegation target).
S4U2Self is fully specified in [MS-SFU].