Authentication and Delegation in Distributed Systems

In the last few lectures we discussed various ways of authenticating humans; we now turn our attention to the problem of authenticating machines.

We will find that authenticating machines is not an isolated problem - there is an interaction with the method we use for authorization. We will need to look again at ACLs and capabilities. We will also keep in mind the Principle of Least Privilege.

Let us first look at 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.