This topic describes the acquisition, by the client's security runtime, of the user's PTGT. Acquisition of the user's PTGT is the second of the two parts of DCE user authentication.
From this point on, the client principal uses four different conversation keys to talk with other principals. Use of multiple short-lived keys makes an attacker's task far more difficult, since there are more encryption keys to discover and less encrypted material and time with which to crack them.
Refer to the following figure as you read the following steps.
1. When the client's security runtime has succeeded in decrypting conversation key 3, it next wants to acquire a PTGT from the privilege service. Before a request for a PTGT can even be formulated, however, a service ticket to the privilege service must be acquired. The client's security runtime therefore begins by requesting such a service ticket from the TGS. The security runtime encrypts this request by using the conversation key 3 (which is also sealed in the client's TGT); it also sends along the client's TGT.
2. The TGS decrypts the TGT (which was encrypted in the KDS's secret key), learning conversation key 3, and verifies that the request was properly encrypted by using conversation key 3. This convinces the TGS that the identity of the requesting client is authentic; that is, no other principal could have sent a message so encrypted because no other principal knows conversation key 3. (The reader should review the preceding steps if necessary to be convinced that this is true.) Since the user has demonstrated to the TGS knowledge of the key, the TGS allows the user to talk to the privilege service, and so prepares a service ticket to that service. This ticket contains the identity of the user (and a conversation key 4), encrypted under the secret key of the privilege service (which the TGS retrieves from the registry service). The TGS separately encrypts conversation key 4 under conversation key 3, and returns this data to the client.
Note: Beginning with the following figure, the illustrations do not emphasize all the TGS encryption and decryption activities (such emphasis would be redundant since the TGS knows all of the keys).
3. Upon receipt of this data, the client's security runtime uses conversation key 3 to decrypt conversation key 4. The client then formulates a request for a PTGT, encrypting it with conversation key 4, and sends this together with the service ticket it just received from the TGS, to the privilege service.
4. The privilege service decrypts the service ticket sent to it (using its secret key), thereby learning the identity of the client and the conversation key 4 it will use to decrypt the request and to encrypt its response. The privilege service is convinced of the authenticity of this request because the information was encrypted under its own secret key, and no principal other than the KDS (acting as the TGS) could have encrypted the information by using this secret key. Because the privilege service believes the authenticity of the client's identity, it prepares an extended privilege attribute certificate (EPAC) to issue to the client. (Actually, in the pure DCE Version 1.0 protocol this would be a PAC, not an EPAC, but since this is a high-level description intended for both releases we'll just talk about EPACs without fear of confusion. So what we're really describing here is an extended privilege TGT, or EPTGT, though we'll continue to call it a PTGT.)
The EPAC describes the user's privilege attributes (identity information and group membership) and any extended attributes that are associated with the user - all represented as UUIDs (not strings). The EPAC (or EPAC chain, in case of a delegated operation) is sealed with an MD5 checksum. (Delegation is described in The Extended Privilege Attribute API .) The privilege service constructs a PTGT, which is a ticket that contains the EPAC, the EPAC seal, another copy of the EPAC seal encrypted in the secret key of the privilege service (this is called a delegation token), and a conversation key 5 (which is actually generated by the KDS, though the illustration doesn't show this detail). All this information except for the EPAC itself is encrypted in the secret key of the KDS (thus, the delegation token is doubly encrypted). (The KDS and privilege service cooperate to prepare the PTGT, although the illustration only shows the privilege service preparing it.) The EPAC seal inside the PTGT binds the EPAC to the PTGT, guaranteeing its integrity even though it is not encrypted. The conversation key 5 is encrypted in conversation key 4, and all this data is returned to the client.
Client Acquires PTGT
5. The client's security runtime uses conversation key 4 to decrypt conversation key 5. It cannot decrypt the PTGT itself, since the PTGT is encrypted under the secret key of the KDS.