TGS Requests
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.
Contents
Protocol structure
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.
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 and S4U_DELEGATION_INFO buffers from the header ticket.
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.
User-to-user requests
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).
S4U2Proxy (constrained delegation) requests
If the cname-in-addl-tkt option is requested, the request is for a ticket from some client (known here as the "subject") to another service. The request must contain a second ticket (known as the "subject ticket" or "evidence ticket") in the additional-tickets field to identify the subject. The subject ticket must have the forwardable flag set. The request must not contain any options or padata for other kinds of special TGS requests (ticket modification, user-to-user, or S4U2Self). S4U2Proxy operations require special privileges, which may be modeled as outgoing delegation privileges on the requesting service or incoming delegation privileges on the delegation target. When incoming delegation privileges are used, the operation is known as resource-based constrained delegation (RBCD) and the delegation target may be in a different realm from the requesting service. Otherwise, the requesting service and delegation target must be in the same realm.
There are three parties to an S4U2Proxy operation:
1. The subject, which will be the cname and crealm of the resulting ticket. This party may also be known as the "client", although that term may be confused for the requesting service. For a local-realm S4U2Proxy or initial RBCD request, this is the client of the subject ticket. For a cross-realm RBCD request, the subject is identified by the PAC in the subject ticket.
2. The requesting service, as give by the client of the header ticket. This may also be known as the impersonator.
3. The delegation target, which will be the sname and realm of the resulting ticket. This party may also be known as the "resource", the "server" (because it is given by the sname and realm of the KDC request), the "proxy target", or (particularly in Microsoft documentation) just the "proxy". Experience has shown that the term "proxy" is easily confused with the impersonator, so the MIT implementation uses this term sparingly. The delegation target must not be a TGS name.
A PAC must be present in both the header ticket and subject ticket. For a cross-realm RBCD request, the PAC must contain an S4U_DELEGATION_INFO buffer with the requesting service as the last transited_service and the delegation target as the proxy_target, and an "@REALM" suffix in the PAC_CLIENT_INFO name. For a local S4U2Proxy request, the PAC must be for the second ticket client. The PAC in the header ticket must be for the requesting service.
For a local-realm or initial RBCD request, the KDC adds S4U_DELEGATION_INFO to the PAC in the issued service ticket or referral TGT. Any transited services specified in the subject PAC's delegation info (if it had one) are copied, and the requesting service is added to the end. The proxy_target field is set to the delegation target. Final RBCD requests verify and copy delegation info from the subject PAC without modifying it.
References
RFC 4120 specifies the base Kerberos 5 protocol.
RFC 6113 specifies FAST.
RFC 6803 specifies referrals.
S4U2Self and S4U2Proxy are fully specified in [MS-SFU].
PACs are specified in [MS-PAC].
