### The Authenticated RPC Call

Once an application has either inherited or established a validated authentication context, it establishes authentication for RPCs by annotating the binding handles on which those calls are made. Clients do this by calling rpc_binding_set_auth_info( ). No further action is required of the application: when an RPC is made on such a binding handle, all further authentication is carried out silently by the RPC runtime.

The call to rpc_binding_set_auth_info( ) requires three pieces of authentication-related state:

1. The authentication service to use: either DCE secret key or none.

2. The login context to use. Most applications will specify the default login context (by setting the auth_identity parameter to NULL).

3. A principal name for the server being called.

Note that applications may need to establish a default login context even if they do not explicitly call rpc_binding_set_auth_info( ) to set this context for a specific binding handle. In particular, access to name and other services involves authenticated RPC calls made by the runtime on the application's behalf. In these cases, the application does not have a chance to call rpc_binding_set_auth_info( ) explicitly. These implicit calls therefore use the default identity for authentication purposes. It is mainly for this reason that servers need to establish a validated authentication identity for the principal under which they run and make this the default login context.

The principal name specified to rpc_binding_set_auth_info( ) establishes the principal for which Kerberos service tickets will be requested for RPCs on the binding handle. An application making RPC calls may or may not care about who the server principal is. The client may be satisfied to call any server that provides the service it wants, or the client may need to trust the server and thus require a trusted server principal identity.

Typically, a client learns the principal identity of a server by calling rpc_mgmt_inq_server_princ_name( ). If the client is willing to call any server, the returned principal name may be passed to rpc_binding_set_auth_info( ) without further checks. If the client must trust the server, then the client needs to check the returned principal identity against a list of (one of more) acceptable values. The client needs to obtain this list by some application-specific means.

Note that it is not the call to rpc_mgmt_inq_server_princ_name( ) or any subsequent checks on the returned name that actually authenticates the server to the client. A malicious server could certainly arrange to return a false principal name. However, a false name would be useless for authentication since the false server would not have access to the secrets (keys) of this identity. However, the client does need to protect its list of acceptable server identities to prevent a malicious server from modifying the list to include its own identity.

###