Re: auth handshake and rendevouz objects

[Neal H. Walfield]

Here is my vision of how an authentication request would work on L4:

 * Client contacts Auth and establishes a rendez-vous object
 * Auth returns a handle (i.e. the rendez-vous object) to Client
 * Client asks Auth to give Server access to the handle
 * Auth returns the handle id for Server to Client
 * Client gives handle id to Server
 * Client contacts Auth for auth_client_authenticate and provides handle
 * Server contacts Auth for auth_server_authenticate and provides handle

What you seem to be suggesting:

 * Client creates a handle for Server
 * Client passes handle to Server
 * Server asks Client to give Auth access to the handle
 * Client returns a handle id for Auth to Server 
 * Server contacts Auth for auth_server_authenticate and provides
   handle
 * Auth contacts Client for auth_reverse_client_authenticate

You are arguing that this method is better because Client and Server
do not have to negotiate which auth server to use.  Instead, the
server chooses and if the client does not like that particular auth
server, it can reject the request (either during the transfer handle
or at auth_reverse_client_authenticate).

I am not sure that it helps anything.  What if the server chooses the
wrong authentication server?  That is, the server trusts Auth server A
and Auth server B and the client trusts Auth server B and Auth server
C and the server chooses to use auth server A.  Thus, we are back to
negotiation of the trusted auth server up front.

Now consider: the client only trusts Auth server A, a proxy auth
server to the system auth server.  The client creates a handle for the
server and starts the authentication request.  The server then
contacts the system auth server and the system auth server tries to
upcall to the client.  The client, however, does not trust the system
auth server, it only trusts Auth server A.  The system auth server
knows nothing about the proxy auth server B, the client does not know
that it is using a proxy auth server nor does the server know about
the proxy auth server.

In my model, this would work.  The client contacts the proxy auth
server.  The proxy auth server would do a mutation, i.e. create a
handle on the real auth server, and return that to the client.  The
client would then pass that to the server, the server would contact
the system auth server and the system auth server would do the
authentication using the proxy auth server's handle which is what we
want.