Credential delegation and single sign-on are one of the most interesting features of GSI, and are possible thanks to something called proxy certificates. Before looking into these concepts in detail, let's first take a look at the problem they solve.
When introducing GSI, an interesting scenario was described, as shown in Figure 10.3, “A scenario where delegation is necessary”
AliceOrg asks BobOrg to perform a task. Since BobOrg trusts AliceOrg, it accepts to perform the task. But let's suppose that task Z is very complex, and that one of its subtasks (Y) must be performed by a third organization: CharlieOrg. In this case, BobOrg will ask CharlieOrg to perform subtask Y but, alas!, CharlieOrg only trusts AliceOrg. What should CharlieOrg do? It has two options:
Turn down BobOrg's request. CharlieOrg doesn't trust BobOrg, and that's that.
Accept BobOrg's request. The 'original' requester is AliceOrg so, although CharlieOrg is answering a request from BobOrg, it will actually be carrying out a job for AliceOrg.
In this situation, it seems logical that CharlieOrg should accept BobOrg's request. However, CharlieOrg has to know that BobOrg's request is performed on behalf of AliceOrg, as shown in Figure 10.4, “Delegation”.
Of course, this is not a very secure solution, since anyone could claim to be acting on AliceOrg's behalf! One possible solution would be for CharlieOrg to contact AliceOrg every time it receives a request on AliceOrg's behalf. However, this could be a bit of a nuisance. Imagine that task Z is composed of 20 different subtasks, and that each subtask is dispatched to a different organization by BobOrg. AliceOrg would be flooded with messages saying "BobOrg just asked me to perform a task on your behalf... can you confirm that this is correct?". In response, AliceOrg would have to authenticate itself with all those organizations and give a confirmation.
A more elegant solution would be to somehow make CharlieOrg believe that BobOrg is AliceOrg. In other words, it would interesting to find a legitimate way for BobOrg to demonstrate that it is, in fact, acting on AliceOrg's behalf. One way of doing this would be for AliceOrg to 'lend' its public and private key pair to BobOrg. However, this is absolutely out of the question. Remember, the private key has to remain secret, and sending it to another organization (no matter how much you trust them) is a big breach in security. What we really need is a special type of certificate like the one shown in Figure 10.5, “A proxy certificate”.
The certificate shown in Figure 10.5, “A proxy certificate” is a proxy certificate. Webster's Dictionary defines 'proxy' as "The instrument by which a person is empowered to transact the affairs of another". As you can see in the picture, the proxy certificate allows the holder of the certificate to act on A's behalf. In fact, it's very similar to the X.509 digital certificates seen in Section 9.4, “Certificates and certificate authorities”, except that it's not signed by a Certificate Authority; it's signed by an end user. We can be sure that the certificate is authentic by checking its signature (Organization A digitally signs the certificate, as described in Section 9.3, “Public key cryptography”).
But, what about the proxy certificate's public key? Whose public key is it? Organization A's? Organization B'? The answer is 'neither'. A proxy certificate has a private-public key pair generated specifically for the proxy certificate. This private-public key pair is mutually agreed upon by both parties (in this case, A and B), and Organization A will only allow the holder of that private-public key pair to act on its behalf (in this case, B). The exact mechanism by which the proxy certificate is generated by A and B will be explained later on.
There is, however, something missing from the picture. Allowing someone to act unconditionally on your behalf is a risky affair. Sure, you might trust them now, for the particular task you want to do, but someone from Organization B might use the proxy certificate in the future to carry out some mischievous deeds on your behalf. Therefore, the lifetime of the certificate is usually very limited (for example, to 12 hours). This means that, if the proxy certificate is compromised, the attacker won't be able to make much use of it. Furthermore, proxy certificates extend ordinary X.509 certificates with extra security features to limit their functionality even more (for example, by specifying that a proxy certificate can only be used for certain tasks). Summing up, a more correct representation of a proxy certificate would be the one shown in Figure 10.6, “A proxy certificate with a limited lifetime”.
A proxy certificate allows a user to act on another user's behalf. This is more properly called credential delegation, since proxy certificates allow a user to effectively delegate a set of credentials (the user's identity) to another user. This solves the problem originally posed, since B could use a proxy certificate (signed by A, of course) to prove that it is acting on A's behalf. Organization C would then accept B's request.
By using proxy certificates we also get another desirable feature: single sign-on. Without proxy certificates, Organization A would have to authenticate itself with all the organizations that receive requests 'on behalf of A'. In practice, this mean that the user in Organization A with permission to read the private key would have to access the key each time a mutual authentication is needed. Since private keys are usually protected by a password, this means that the user would have to sign on (provide the password) to access the key and perform authentication. Using proxy certificates, the user only has to sign in once to create the proxy certificate. The proxy certificate is then used for all subsequent authentications.
Finally, although we've centered on the advantages of proxy certificates for delegation, these certificates have other features that make them interesting for other purposes. For example, they can be used locally: generating a proxy certificate that authorizes myself to act on my behalf. This might sound silly, but is actually very useful since I can use the proxy certificate for all my secure conversations, instead of using my public-private key pair directly. This reduces the risk of having my conversations compromised because an attacker would only have a chance to crack the proxy's key pair, and not my personal one (which would only be used to generate the proxy certificate).
At this point, you might be truly impressed at how masterfully proxy certificates allow us to delegate credentials in a completely secure manner. Then again, maybe not :-) If you are not willing to take a leap of faith when we say "Proxy certificates are really nifty!", and are not totally convinced that they are secure, this section gives a much more detailed look at the process of creation and validation of a proxy certificate. You can safely skip it unless you really really really need a more detailed explanation.
We've said that a proxy certificate can be used to delegate a user's credentials to another, different user. How is this achieved in a secure manner? For example, let's suppose that (as shown in Figure 10.3, “A scenario where delegation is necessary”) B needs A's credentials so it can make a request to C. B, therefore, needs a proxy certificate signed by A. Let's take a close look at the process used to generate that certificate.
B generates a public/private key pair for the proxy certificate.
B uses the key pair to generate a certificate request, which will be sent to A using a secure channel. This certificate request includes the proxy's public key, but not the private key.
Supposing A agrees to delegate its credentials to B, Organization A will use its private key to digitally sign the certificate request.
A sends the signed certificate back to B using a secure channel.
B can now use the proxy certificate to act on A's behalf.
Notice how the proxy's private key is never transmitted between A and B. This is also true of A's private key.
Now let's take a look at C. When B sends a request 'on behalf of A', and sends C the proxy certificate, how can C validate the proxy certificate? In other words, how can C be absolutely sure that B is acting on A's behalf?
The process of validating a proxy certificate is practically identical to the process of validating an ordinary certificate, as described in Section 9.4, “Certificates and certificate authorities”. The main difference is that the proxy certificate is not signed by a Certificate Authority, it's signed by a user. In our example, the proxy certificate is signed by A, which means that we need A's public key to test its authenticity. Since C is unlikely to have A's certificate, a request that uses a proxy certificate generally also sends the delegator's certificate, so the proxy certificate can be validated. Since the delegator's certificate will be signed by a Certificate Authority, the only step left is to validate the Certificate Authority's signature. Figure 10.7, “Validation of a proxy certificate” shows the chain of signatures that we could find in a proxy certificate.
There's a lot more to proxy certificates than what has been explained in this chapter. For example, you can use proxy certificates to sign other proxy certificates. However, for the purposes of this tutorial , the material covered here should be enough. If you want to take a closer look at proxy certificates, and everything that can be done with them, we highly recommend reading RFC 3820, Internet X.509 Public Key Infrastructure Proxy Certificate Profile, available at http://www.ietf.org/rfc/rfc3820.txt.