Re: RFC: Revised authentication protocol

[Olaf Buddenhagen]

Hi,

On Sun, Sep 04, 2016 at 10:29:54PM -1000, Brent W. Baccala wrote:

> Here's my proposal for dealing with the authentication issue.
> 
> There should be an extra send right passed from the auth server, to the
> client, that the client then passes along to the server in its
> authentication request, and that the server then passes on to the auth
> server in its auth_server_authenticate messsage.  This is distinct from the
> auth_object.  Unlike the auth_object, this right conveys no credentials and
> is used primarily to identify the auth server.  Let's call it the
> auth_identifier.
> 
> In the present scheme, you can see that the auth_identifier gets passed
> around in a big circle.  When the auth server gets the
> auth_server_authenticate message from the server, it sees that it's gotten
> its own auth_identifier back, and things proceed as they do now.
> 
> The more interesting case is when the auth_identifier differs.  That
> happens when we're dealing with two different auth servers on different
> hosts.
> 
> First, the auth_identifier allows the auth server to detect this case.
> 
> Next, it provides a means for the two auth servers to complete the
> rendezvous.  The server's auth server can pass the rendezvous right to the
> client's auth server using the auth_identifier.
> 
> There's no way for the server's auth server to fool the client's auth
> server into thinking that this is a normal server authentication request,
> because the only communication between the two is via the auth_identifier.
> The client's auth server can clearly distinguish messages coming in over
> this port from auth_server_authenticate messages, which would come directly
> from a server over a different port.
> 
> Finally, the auth servers can use the auth_identifier to speak any kind of
> inter-auth-server protocol that they wish.  At the moment, the exact
> details of that protocol are beyond the scope of this proposal.  I
> envision, perhaps, a public key exchange.  Something that would let
> mutually cooperating auth servers decide how to map UIDs/GIDs from one auth
> domain to another.  I haven't thought through the details, but I think this
> proposal is flexible enough to handle just about anything we'd want to do.

I'm a bit confused here: my understanding was that you essentially
wanted to implement a "single system instance" cluster. I would have
thought that would imply only a single instance of most servers --
including auth -- rather than separate ones for each node?...

Note that for the container solutions (lightweight virtualisation) I'm
envisioning for the Hurd -- with things like sub-users -- we are likely
to need some kind of auth delegation scheme or something like that; but
I haven't spent too much thought on this. Not sure whether it would be
relevant to your work in any way...

On Mon, Sep 05, 2016 at 02:09:56PM +0200, Richard Braun wrote:

> I'm not completely familiar with the inner workings of the auth
> server but they look easy enough to imagine. Still, an opinion
> from someone more familiar with it like Olaf would be great.

I'm not really very familiar with the details of the auth protocol. The
stuff I discussed extensively with Carl at some point (as a solution to
the infamous "firmlink issue") was more about handling of the ID sets
obtained through the auth mechanism -- I don't think it involved changes
to the auth protocol itself... Not sure though. Maybe Carl remembers
better than me?

-antrik-