Re: auth handshake and rendevouz objects

[Marcus Brinkmann]

On Mon, Nov 04, 2002 at 03:59:28PM +0100, Bram Meersman wrote:
> Can I find an explanation about handle passing in Hurd/L4 somewhere on 
> the web ?

Nope.  I remember I worked out two possible designs with different drawbacks
(the question was just how to order the communication), and we wrote them on
a piece of paper.  Neal, do you still have this paper?  I would like to see
the two variations and what we decided again, as I forgot most of it.

> Following scenario is possible in Hurd/Mach :
> There are 4 processes involved in this scenario: Client, Server, Auth 
> (an authentication server only trusted by Client and Server), and Proxy 
> ( a proxy server ).

One critical piece I was missing is to which the proxy was a proxy.  You
mean a proxy server for the server that wants to authenticate.

> (1) Client wants to open a file
> (2) Client creates a pair of rendezvous ports
> (3) Client sends one rendezvous port to Auth (calls 
> auth_user_authenticate )and another to Proxy
> (4) Proxy sends the port it received from Client to Server
> (5) Server sends the port it received from Proxy to Auth, together with 
> a server port (calls auth_server_authenticate)
> (6) Auth matches the two rendezvous ports, sends server port to Client 
> and Client_UID to Server

Yes.  Well, port -> object handle (even in Mach we don't send ports but port
send rights).  And in step 2 it should be: client creats a rendezvous
object (port).  It doesn't create two of them, it only creates handles (send
rights).
 
> Proxy just passes around port rights, he doesn't know the identity of 
> Client. He also has to trust neither Client or Server.
> Proxy doesn't even need an auth port.
> 
> imho such a proxy server should be possible in Hurd/L4 too.

Sure, it is.

> However, both of the proposed protocols would require Proxy to RPC to 
> either Client or Auth (for sending the object handles).
> Proxy would block waiting for Client or Auth, both cannot be trusted.

I see what you are getting at now.

Note that the auth server will have to send an RPC to whoever provides the
object, too, to verify the identity.  And, to make the picture complete,
moving an object handle of an object provided by S from A to B requires RPCs
from A to B and A to S and B to S (at least, I am not sure if there wasn't
also an RPC from B back to A).  I now I am sketchy, I hope Neal will remind
me of the details, or I will work them out from scratch again later.

The way to avoid blocking is just to have a small timeout.  But I definitely
see your point.
 
> I don't like the proxy server blocking on the client.
> I don't like the proxy server blocking on the auth server, since the 
> auth sever can be chosen by the client.

In fact the auth server to be used is chosen by the server.  If the
client doesn't use the same auth server, the server authentication request
blocks until the rendezvous object is destroyed.  I am sure there are lots
of little races to be worried about in L4 (requesting task death
notifications too late etc), but this is a generic feature we will want.
 
> I 've come up with a protocol which allows the scenario I described (I 
> think).
> I 'll post it later on.

Ok.  The only other option I see right now is to have the rendezvous object
created and managed by the server, rather than auth or user.  I have not
thought about the semantic implication (eg the answer to the question: Who
controls what?), so I am undecided if it is feasible.  I think we should
consider all three cases (four if you include Mach/central object server)
and write down their semantic meaning and then go from there.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    address@hidden
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
address@hidden
http://www.marcus-brinkmann.de/