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.
In the previous page, an interesting scenario was described:
Organization A asks Organization B to perform a task. Since B trusts A, 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: Organization C. In this case, B will ask C to perform subtask Y but, alas!, C only trusts A. What should C do? It has two options:
Turn down B's request . C doesn't trust B, and that's that.
Accept B's request . The 'original' requestor is A so, although C is answering a request from B, it will actually be carrying out a job for A.
In this situation, it seems logical that C should accept B's request. However, C has to know that B's request is performed on behalf of A:
Of course, this is not a very secure solution, since anyone could claim to be acting on A's behalf! One possible solution would be for C to contact A every time it receives a request on A'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 B. Organization A would be flooded with messages saying "B just asked me to perform a task on your behalf... can you confirm that this is correct?". In response, A would have to mutually authenticate itself with all those organizations and give a confirmation.
A more elegant solution would be to somehow make Organization C believe that Organization B is Organization A. In other words, it would interesting to find a legitimate way for B to demonstrate that it is, in fact, acting on A's behalf. One way of doing this would be for A to 'lend' its public and private key pair to B. 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 something like this:
The certificate pictured above 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 the previous chapter, 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 the previous chapter).
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 described shortly.
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 24 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 following:
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 mutually 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 mutual 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). We're not going to discuss all the added benefits of proxy certificates, since in a Grid Services-based application we will be mainly concerned with delegation and single sign-on. However, a link is provided at the end of this page if you are interested in reading more about proxy certificates.
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 I say "Proxy certificates are really nifty!", and are not totally convinced that they are secure, the following paragraphs give a much more detailed look at the process of creation and validation of a proxy certificate. However, the rest of this page can be safely skipped 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 the first picture) 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 the previous chapter. 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.
The following illustration 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 page. For example, you can use proxy certificates to sign other proxy certificates. However, for the tutorial, the material covered in this page should be enough. If you want to take a closer look at proxy certificates, and everything that can be done with them, I highly recommend reading the following Internet Draft: Internet X.509 Public Key Infrastructure Proxy Certificate Profile.