Delegation in Distributed Systems

Gasser, Morrie and Ellen McDermott. An architecture for practical delegation in a distributed system. Proceedings of the 1990 IEEE Symposium on Security and Privacy (Oakland, CA., May 1990) pp. 20-30.

Consider a stand-alone system. The typical scenario is:

• Users authenticate themselves through a trusted path to a reference monitor;
• The reference monitor starts a process running on behalf of the user;
• The reference monitor treats requests coming from that process as if they come from the user.

We now consider the case of distributed systems. A reference monitor running on some server machine S receives a request made by some local process. The local process received the request from a workstation W.

What identity should the reference monitor attach to that request for determining authorization? Let us first consider some bad answers to that question:

1. The reference monitor asks W to supply the identity of user originating the request. This solution would mean that the reference monitor trusts the remote system to properly authenticate the user -- a bad idea! The remote system may be just a PC pretending to be W.
2. The reference monitor asks W to supply the user's password. However the user has no reason to trust the remote system S or the channel between W and S with his/her password.
3. Create a secure channel from the user's smart card to the reference monitor and use one of the authentication schemes we discussed earlier. The drawback of this approach is that it only works while the user is logged in. The user is prevented from running background jobs when not physically present at the terminal. A better solution is obtained by postulating the following model: principals are both users and workstations and each has a global name. Each principal also has a well-known public key and a corresponding secret private key. Principals generate and respond to requests. Each host has a reference monitor (assume ACLs, although capabilities also enter the picture, in a way).

   Consider the following scenario:

   

   The user P with smart card SC makes a request "print A" to W₁. Before W₁ can complete the request it needs to read the object A, so W₁ issues a request "read A" to the server W_S. The request is processed by the reference monitor at the server (assume it contains an ACL that allows P to read A). Should the reference monitor approve the request from W₁?

   It is time to put on our "paranoid" hats. We want to know whether the request is really made on behalf of P. We ensure this in the following way: we create a delegation certificate D₁:[W₁ for P]_SC. This is certificate is just the bit string W₁ for P which is prepared by W₁ at login time and sent to the user who signs it with the smart card SC and returns it back to W₁. The meaning of the certificate is that W₁ can now make requests on behalf of P, or "speak for P".

   We use the certificate as follows:

   

   The user makes a request "print A" to W₁ as before. When W₁ makes its request to W_S, D₁ is forwarded along with the request. Now the reference monitor can verify the authenticity of the certificate using the user's well-known public key and approve the request. Note that:

   • We require that the ACL for A contains an entry "W₁: delegate read". This is in accordance with the principle of least privilege: only some workstations are allowed to speak for P so we explicitly check for that right.
   • The channel between W₁ and W_S needs to be integrity-protected, otherwise an attacker can alter the read request, which might still be approved (since it is accompanied by the delegation certificate D₁).
   • If W₁ is subverted, then the security of the system is compromised. If the user P does not trust W₁ to be secure then P should not give a delegation certificate to W₁.
   We can now extend this system with one more workstation W₂:

   

   This leads to the need for the delegation certificate D₂. It is just a bit string that W₂ sends to W₁ who signs it with its private key and sends it back to W₂; W₂ can then forward it along with the request. The reference monitor reasons as follows: a request is coming from W₂ with a certificate D₂:[W₂ for P]_W1 , signed by W₁. The reference monitor honors this certificate if and only if W₂ has the "delegate read" right and we can make sure that W₁ speaks for P. The reference monitor then looks at D₁ and since D₁ is signed by the smart card and W₁ has the "delegate read" right, it is satisfied that the request is legitimately coming from P. Since P has the "read" right, the request is approved.

   Note that instead of D₂ we could have used D₂´:[W₂ for W₁]_W1. However, such a certificate is much less restrictive and therefore not a good idea.

   Typically, each workstation involved in implementing a service will keep cached copies of all delegation certificates for client systems, so it can forward these copies along with requests to any servers that it must contact in order to satisfy a request for service.

   When a delegation certificate is no longer needed (e.g. the user logs out), the system should no longer have the right to represent the user. But how do we revoke these certificates?

   Let us start with some simple (almost) solutions:

   1. Include timeouts in certificates. There is a trade-off here. If we set the timeout too high, then there is a chance that an attacker might be able to make use of the certificate after the user logs out but before it expires. If we set the timeout too low, then the certificate might expire during an interactive session, forcing the user to create a new certificate (i.e. inconvenience). There is no general solution to this problem.

   2. Deletion. Upon logout, the user can instruct all workstation that might have cached certificates to delete them. But how does the user know that they are really deleted? The certificates might have been intercepted by an attacker who can store them indefinitely.
   We now consider a solution using delation keys, private/public key pairs. The public key will appear in the delegation certificate, the private key is held by the system. When a workstation wants to verify the validity of a certificate it challenges the owner of the private key to prove that it holds it. This is easily achievable without disclosing the private key (by employing a challenge-response protocol). To revoke a certificate, a system simply forget its private key.

   More concretely, in our example, the scheme changes as follows:

   • W₁ generates a (private, public) key pair (k, K);
   • the certificate D₁ becomes [K, W₁ for P]_SC;
   • when challenged to prove that it holds the private key for the public key K, W₁ can do that;
   • to revoke D₁, W₁ forgets the private key k -- D₁ no longer works since nobody else has k.
   How can P know that W₁ will forget k when instructed to do so? As before, if P does not trust W₁ to do that, then P should not have given D₁ to W₁ in the first place.