Delegation Model

This section provides a discussion of four alternative solutions that could be used to implement delegation for SSL. Note that delegation is not supported natively by LDAP, and the following discussion, therefore, applies to

applications that use LDAP. An example is used to illustrate the four alternatives.

There are several requirements pertaining to the delegation for SSL. The example below that we use throughout this section depicts a typical scenario for delegation (others can be derived from this one). Four solutions are presented to solve the lack of standardized delegation in SSL.

In the example shown in Figure 24 , Mary, on a client machine, uses a Web browser to contact a middle tier server (MTS) using HTTP with SSL (https) over transaction 1 (T1). A program on MTS wants to execute a transaction (T2) on Mary's behalf on an End Tier Server (ETS). The second transaction (T2) should be authenticated as Mary rather than as MTS. On each machine, the SSL code will report to the application the name of the peer. The

reported is the name of the person using the client not the name of the server. This is not possible with current technology without an additional application code.

Figure 24. Delegation

The requirement cannot be met because the authentication for T1 and T2 is using SSL client authentication. Although client authentication has changed slightly among SSL Version 2, SSL Version 3, and TLS Version 1.0, all of these protocols have the client sign data derived from the rest of the handshake (session establishment messages). The client (Mary in the T1 transaction in the example above) executes this signature using its private key (normally an RSA key) and then sends the signature and its certificate for this key to the server (MTS for T1 above). This cannot be repeated for T2 because the private key is never permitted to leave the client; so, the MTS cannot get access to it.

This section includes four potential solutions to this problem. All of these solutions assume that a successful client-authenticated SSL or TLS session has been established between the client and the MTS.

Solution 1 - Client creates new certificate

The client extracts the server's name and server's public key from the certificate that the server sent to the client during the handshake. The client then creates a new X509 Version 3 certificate for the server using the name from the client's certificate as the issuer name. The client would normally set the certificate to expire in a very short time. Other restrictions could be added in the form of X.509v3 extensions, but certificate revocation lists (CRLs) would not be used. The client would send the new certificate to the MTS. The MTS would then start a normal SSL handshake (as a client) with the ETS. When MTS is asked for its certificates, it would send the newly created

Client Middle Tier Server End Tier Server

Runs as Mary Runs as MTS -> Mary Runs as ETS -> Mary

certificate it received from the client, and the client's original certificate. ETS would then verify the certificate by constructing a certificate chain, and the rest of the SSL connection for T2 would progress normally.

In this case, the ETS does not know that any delegation is taking place. New code is required on the client and the MTS. The certificate hierarchy for the client must have a policy that allows the client to create valid certificates (as interpreted by the ETS).

Solution 2 - Client create signed document not valid X509 certificate

The client extracts the server's name and server's public key from the certificate that it sent during the handshake as in solution 1 above. In this case, it creates a signed document including its name, the server's name, the server's public key, and any restrictions, such as the end time of the

delegated session. Notice that the certificate created in solution 1 would meet this criteria. The signed document is sent to the MTS.

The MTS starts a SSL client-authenticated session but uses its own

certificate. During the handshake, it also sends the signed document from the client along with a signal that delegation is to be used, and the ETS should assign the client's identity to this session (T2).

The ETS verifies the SSL handshake in the normal manner then processes the request by the MTS for a delegated session. If the signature on the signed document from the client is valid, the SSL session was set up by the MTS server and public key in the signed document; therefore, the SSL code on the ETS will use the client’s identity.

In this case, the ETS must have modified code and the ETS knows the MTS and client identity. The client certificate must be valid for signature or SSL use (as interpreted by the ETS), but this is a default requirement for client

certificates for SSL use.

Solution 3 - Client signs for MTS

The MTS server initiates the SSL session with the ETS and sends the client’s certificate. When the handshake progresses to the point where a signature is required, MTS sends all of the handshake data back to the client. The client (after any desired verification) makes the required signature and sends it to the MTS. The MTS then uses the signature to complete the handshake for T2 with ETS.

In this case, the ETS does not require new code. No special characteristics are required for the client certificate. This solution has the advantage that the client may approve each transaction because it has available the name and

certificate of the ETS and is called for each session set up. On the other hand, this solution has the disadvantage that each MTS/ETS transaction requires traffic between the MTS and the client.

Solution 4 - MTS signs certificate

In this case, the MTS can act as a certificate authority that is trusted (at least by the ETS). After the SSL handshake, the MTS extracts the name from the client certificate, makes up a new RSA key pair, and creates a certificate. It then uses that certificate and private key for the subsequent SSL session with the ETS. The key pair and certificate may be stored for later use.

A variation on this scheme is that the MTS can act as a registration authority for a certificate authority on another machine.

Neither the client nor the ETS need to be modified for this solution. No new SSL (or other related communications flows) are required. Neither the client nor the ETS know that delegation is being done. However, the ETS must be configured to trust either the MTS or a CA that trusts the MTS.