Authentication Using Authenticated RPC

Note: The authenticated RPC facility may also be referred to as the protected RPC facility, as it involves services beyond authentication. Authenticated RPC may also be referred to as the protected RPC facility.

Refer to the following figure as you read the following steps.

Client Sets Authentication and Authorization Information

1. Having been authenticated and having acquired a PTGT, the user now invokes (the client side of) an application. The client side of the application calls rpc_binding_import_begin( ), rpc_binding_import_next( ), and the like. These calls specify the remote interfaces required by the client for the application.

2. The CDS returns the client binding handles to the specified interfaces. (For simplicity in this example, we consider the simple binding model in which the client consults the CDS for the server's RPC binding name.)

3. The client annotates the binding handle - that is, it sets security information for the binding handle by calling rpc_binding_set_auth_info( ). Among other parameters, this routine sets the authentication protocol, the protection level, and authorization protocol for the binding handle corresponding to the remote interface. It also sets the server's principal name, which the client must know securely (it may be the same or different than the server's RPC binding name). In this example, assume that the authentication protocol (authn_svc parameter) is DCE shared-secret authentication, the protection level (protect_level) is packet privacy (all RPC argument values are encrypted), and the authorization protocol (authz_svc) is DCE authorization. ("DCE authorization'' means that an EPAC chain, containing UUIDs representing the client's or delegation chain's privilege attributes, will be sent to the server, which will compare this information with the ACLs protecting the objects of interest in order to determine whether the principal is to be granted or denied access.)

Refer to the following figure as you read the following steps.

4. The client requests some operation (using the annotated binding handle) to be performed by the server. The client RPC runtime requests from the TGS a service ticket to the server (identified by the server principal name with which the binding handle has been annotated). To acquire the ticket, the client security runtime formulates a request to the TGS. The request includes the server's principal name, which the client security runtime encrypts under conversation key 3. Also sent along with the request is the principal's PTGT, including EPAC and seal.

Client Principal Makes Application Request

5. The TGS decrypts the PTGT (which was encrypted in the KDS's secret key), thereby recovering conversation key 5, and uses conversation key 5 to decrypt the rest of the TGS request message. The TGS then constructs a service ticket, including the EPAC chain information and conversation key 6. By default, the key that is used to encrypt the service ticket is the application server's secret key.

For server principals that must use the user-to-user authentication protocol, the service ticket granted must be encrypted using the session key obtained from the server's current TGT, which the client must pass in with the ticket request. If the client had used the server-key-based request, and the server requires user-to-user protocol, the TGS will respond with an error instructing the client-side runtime to ask the server for its current TGT and to reissue the request with the TGT.

The service ticket is returned to the client, together with conversation key 6 encrypted under conversation key 5.

6. The client's security runtime uses conversation key 5 to decrypt conversation key 6, and then uses conversation key 6 to encrypt the application-level RPC request to the server. The client's RPC runtime sends the encrypted application request to the application server, together with the service ticket.

Refer to the following figure as you read the following steps.

7. The application server's security runtime receives the client's request and decrypts the service ticket by using its secret key, or the TGT session key if user-to-user based authentication is used. In this way, the server's security runtime learns conversation key 6 and uses it to decrypt the RPC request. If the server determines from the client's authorization information (EPAC chain) that the request is granted, it performs the requested operation and prepares a response. The server's runtime encrypts the response by using the conversation key 6 and sends it back to the client.

8. The client runtime receives and decrypts the response, and returns data to the application (by returning from the RPC).

Application Server Responds to Client's Request

The preceding walkthroughs have focused on the security aspect of authenticated RPC in DCE, not on its communications aspect. The technical details of integrating security with RPC lie beyond the scope of this topic. However, the following remarks apply:

· In the CO (virtual circuit) RPC protocol, the client's security credentials (ticket with conversation key 6 and EPAC) are pushed from client to server at connection establishment time, that is, at the time of the first RPC call from client to server (and the RPC call is of course protected with conversation key 6). In the CL (datagram) RPC protocol, on the other hand, while the first RPC call from client to server is protected as previously described (with conversation key 6), the credentials themselves are not sent with the RPC call. Instead, the server itself pulls the credentials, by performing a callback, that is, a reverse (system-level) RPC back to the client, requesting the credentials. Once it receives these credentials, the server proceeds as if the credentials had been transferred with the original application-level RPC call (from client to server) itself, as in the preceding walkthroughs.

· Once the application client and server have established conversation key 6, they cache it and continue to use it for subsequent RPC calls, until it expires. All tickets and their conversation keys are accompanied by a expiration time, beyond which a new conversation key must be established (via a new service ticket, or perhaps even a new TGT if that expires, as described in the preceding walkthroughs). Thus, the security overhead of these subsequent RPC calls is minimal, namely, it is reduced merely to the overhead of encryption/decrypt

· ion processing itself, without the protocol message-passing.