1.3.3 Protocol Overview
The following figure shows the message sequence for Kerberos delegation with a forwarded ticket-granting ticket (TGT). This is background information designed to show the workings of Kerberos delegation, as specified in [RFC4120] section 2.8. This mechanism is then compared to the Service for User (S4U) extensions.
Figure 1: Kerberos Delegation with Forwarded TGT
The preceding figure depicts the following protocol steps:
The user authenticates to the Key Distribution Center (KDC) by sending a KRB_AS_REQ message, the request message in an Authentication Service (AS) exchange, and requests a forwardable TGT.
The KDC returns a forwardable TGT in the KRB_AS_REP message, the response message in an AS exchange.
The user requests a forwarded TGT based on the forwardable TGT from step 2. This is done by the KRB_TGS_REQ message.
The KDC returns a forwarded TGT for the user in the KRB_TGS_REP message.
The user makes a request for a service ticket to Service 1 using the TGT returned in step 2. This is done by the KRB_TGS_REQ message.
The ticket-granting service (TGS) returns the service ticket in a KRB_TGS_REP.
The user makes a request to Service 1 by sending a KRB_AP_REQ message, presenting the service ticket, the forwarded TGT, and the session key for the forwarded TGT.
Note: The KRB_AP_REQ message is the request message in the Authentication Protocol (AP) exchange.
To fulfill the user's request, Service 1 needs Service 2 to perform some action on behalf of the user. Service 1 uses the forwarded TGT of the user and sends that in a KRB_TGS_REQ to the KDC, asking for a ticket for Service 2 in the name of the user.
The KDC returns a ticket for Service 2 to Service 1 in a KRB_TGS_REP message, along with a session key that Service 1 can use. The ticket identifies the client as the user, not as Service 1.
Service 1 makes a request to Service 2 by a KRB_AP_REQ, acting as the user.
Service 2 responds.
With that response, Service 1 can now respond to the user's request in step 7.
The TGT forwarding delegation mechanism as described here does not constrain Service 1's use of the forwarded TGT. Service 1 can ask the KDC for a ticket for any other service in the name of the user.
The KDC will return the requested ticket.
Service 1 can then continue to impersonate the user with Service N. This can pose a risk if, for example, Service 1 is compromised. Service 1 can continue to masquerade as a legitimate user to other services.
Service N will respond to Service 1 as if it was the user's process.
The Server-for-User-to-Self (S4U2self) extension is intended to be used when the user authenticates to the service in some way other than by using Kerberos. For example, a user could authenticate to a web server by some means private to the web server. The web server could then use S4U2self to get a ticket, with authorization data, just as if the user had used Kerberos originally. This simplifies the server's authorization decision by making all decision paths behave as though Kerberos was used. S4U2self primarily uses the KDC to get information about the user for the caller's own benefit. The Service for User to Proxy (S4U2proxy) extension allows the caller to contact some other service, acting on behalf of the user. The detailed overview is given in the following figure.
Figure 2: S4U2self and S4U2proxy
S4U2self is described in the top half of the preceding figure. Using this extension, the service receives a service ticket to the service itself (a ticket that cannot be used elsewhere).
The preceding figure depicts the following protocol steps:
The user's machine makes a request to Service 1. The user is authenticated, but Service 1 does not have the user's authorization data. Typically this is due to the authentication being performed by some means other than Kerberos.
Service 1, which has already authenticated with the KDC and has obtained its TGT, asks for a service ticket to itself on behalf of the named user by the S4U2self extension. The user is identified by the user name and the user's realm name in the S4U2self data (as specified in section 2.2.1). Alternatively, if Service 1 is in possession of the user's certificate, it can use the certificate to identify the user to the KDC using the PA-S4U-X509-USER structure.
The KDC returns a service ticket addressed to Service 1 as if it had been requested from the user with the user's own TGT. The service ticket might contain the authorization data of the user.
Service 1 can use the authorization data from the service ticket to fulfill the user's request. The service then responds to the user.
Although S4U2self provides information about the user to Service 1, this extension does not allow Service 1 to make requests of other services on the user's behalf. That is the role of S4U2proxy. S4U2proxy is described in the bottom half of the preceding figure.
The user's machine makes a request to Service 1. Service 1 needs to access resources on Service 2 as the user. However, Service 1 does not have a forwarded TGT from the user to perform delegation by a forwarded TGT, as described in the figure specifying Kerberos delegation with forwarded TGT. Two preconditions apply to this step. First, Service 1 has already authenticated with the KDC and has a valid TGT. Second, Service 1 has a forwardable service ticket from the user to Service 1. This forwardable service ticket might have been obtained by a KRB_AP_REQ message, as specified in [RFC4120] section 3.2 or by an S4U2self request.
Service 1 requests a service ticket to Service 2 on behalf of the named user. The user is identified by the client name and the client realm in the service ticket for Service 1. The authorization data in the ticket to be returned is also copied from the service ticket.<1>
If a privilege attribute certificate (PAC) is in the request, the KDC validates the PAC by checking the signature data of the PAC structure, as specified in [MS-PAC] section 2.8. If the PAC is valid, or not present, the KDC returns a service ticket for Service 2, but the client identity stored in the cname and crealm fields of the service ticket are that of the user, not Service 1.
Service 1 uses the service ticket to make a request to Service 2. Service 2 treats this request as coming from the user and assumes that the user was authenticated by the KDC.
Service 2 responds to the request.
Service 1 responds to the user's request of message 5.