Difference between revisions of "TGS Requests"

Revision as of 01:01, 2 September 2019

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.

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.

Types of TGS requests

• Normal: the header ticket is a local TGT (its server is krbtgt/THIS.REALM@THIS.REALM) and the requested server is some other principal. The KDC normally issues a ticket from the header ticket client to the requested server. If the requested server is an outgoing cross-TGS principal (krbtgt/OTHER.REALM), the KDC may issue a ticket to an alternative outgoing TGS principal 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".

• Cross-realm: the header ticket server may be krbtgt/THIS.REALM@OTHER.REALM. Ordinarily the header ticket client must also be from another realm (the "lineage check") but there is an exception for S4U2Self requests. The same rules as normal TGS requests apply, but KDB modules which interpret KDC-signed authdata in the ticket must apply policy to determine what authdata may propagate to the issued ticket. 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.

• Ticket modification: if the RENEW, VALIDATE, or PROXY option is requested, the header ticket server need not be a TGT (and must not be a TGT for PROXY), but the requested server must match the header ticket server. The RENEW option is frequently used in practice, while the VALIDATE and PROXY options are not.

• User-to-user: if the ENC-TKT-IN-SKEY option is requested, the request body must contain an additional ticket, whose client must match the requested server and whose server must be the local TGS (krbtgt/THIS.REALM@THIS.REALM). The issued ticket will be encrypted in the session key of the second ticket, not in the long-term key of the service principal.

• S4U2Self (aka "protocol transition"): 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 to the requesting service. S4U2Self is specified in [MS-SFU].

• 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.