New auth protocol

[Marcus Brinkmann]

Hi,

Thomas, I don't know if you read l4-hurd.  I wonder if you considered the
below auth protocol and rejected it (and if yes, for what reasons).

I have a new idea for the auth protocol.  This was spurred by Moritz comment
that the auth protocol would be unnecessary on L4 because you can identify
the sender of a message (ie the sender thread id).  I don't know if he had a
particular protocol on mind or if it was just excellent intuition, but with
an extra allowance we currently don't make it's indeed possible.

The current protocol is well understood and documented, see our web site if
you need to have a refresh on this.  It has the following, non-severe
issues:

* A user can keep a server thread blocked by not sending the
auth_user_authenticate call to the auth server.  This is not serious, as the
server will notice the death of the reply port and cancel the request when
the client dies, but it's not as good as a non-blocking call.

* The server port goes through the auth server and not to the user directly. 
The auth server is trusted by the server, so it is not serious, but it is
still not as good as if the server port would not need to go through auth.

* The protocol does not lead itself to an optimization on systems where the
sender of a message is available.  Because the rendezvous port must go to
the server, and the server port is passed through the auth server, all RPCs
in the protocol are necessary to do the job.  Additional information can not
be used to eliminate any of the necessary steps.

My proposed protocol does not have any of these flaws, and can be more
efficient on L4 even if the particular optimization I mentioned is not
implemented.  I will first give the generic protocol that is also possible
in Mach, then I will give the extra allowance necessary to make a special
optimization on L4 and similar systems.

New protocol:
* The auth server creates an ID port for each AUTH port that can be used to
  query the IDs described by the AUTH port.  Direct operations on this
  object are not supported, though.
* The user requests the ID port from the AUTH port it wants to use for
  authentication.  This could also be done once for every AUTH port instead
  for each authentication.  (It is always the same port).
* The user sends the ID port to the server in a reauthentication request.
  This request is a reply message.
* The server sends a special get_ids variant to the auth server, passing the
  ID port (but not using it to send the message, instead it sends the message
  to its auth port of the trusted auth server).
* The auth server validates the ID port, and returns the IDs associated with
  the AUTH port that this ID port belongs to.  If it does not know about the
  ID port, it gives an error.  Note that this is a nonblocking operation.
* The server can now either fail if auth rejected the ID port, or accept and
  reply to the reauthentication request with the server port.

The result is:
* There is no blocking operation, no synchronization between server and
  client in the auth server is required.  The server can decide quickly if
  the user is authenticated or not.  The user can not keep the server thread
  waiting for a long time.
* The server port is returned directly to the client.  The auth server does
  not gain any information or privilege from this protocol.

Remark: The ID port is destroyed when the AUTH port is.  This ensures that a
server can not keep objects alife in the auth server it shouldn't be able
to keep alife.  The server should thus establish the identity before
returning to the user, and the user must keep the auth object alive for the
whole operation.

Now, this is the protocol so far.  It requires less port name handles (thus,
less IPC space management in Mach or object handle passing operations in
L4), and less RPCs (if the ID port is cached).  Thus it is more efficient.

Both protocols, the original one and this one, have this feature: Only those
tasks that are allowed to by the user can get the user's IDs on the auth
port of the user.  This property hides the information about IDs of each
user.  However, we might decide that this is not a requirement, because we
don't care about this information being hidden.  There is no direct security
leak by providing this information to everyone who asks, although if you are
paranoid, you might want other's not to know about some user's ownership to
special groups.  Usually however the information is already available in
/etc/passwd.  Thus, I make this extra allowance:

Allowance:  Anybody can retrieve the IDs on an user's auth port if he can
guess the user's PID and auth's object ID (in Mach speech, this would
be the IPC space ID of the user - which is not available in Mach - and the
portname of the auth port in the auth server.  Because the ipc space, ie,
the identifier of a sender, is not available in Mach, this rule is
meaningless in Mach, but not in L4.  This means the optimization below is
not available in Mach).

Optimization: If you can identify a sender securely and you make the
allowance above, the following optimization is possible:

* Auth does not create ID ports.
* The user does not get ID ports from auth.
* The user passes in a reauthentication request the object ID of the auth
  port it has.
* The server sends a message to the auth server, passing the user's PID
  and the auth object id provided by the user.
* The auth port checks if the user with that PID "owns" the object with that
  ID provided by the server.  If yes, it returns these IDs, otherwise it
  rejects the request.
* If IDs have been returned, the server replies with the server port.

Now, this eliminates the ID port entirely.  Thus, even less object handles
have to be moved (the object ID is just a number).  Instead, the sender's
PID (which we encode in the thread id swhich is provided by the L4 kernel
securely) is used to establish the user's permission in the auth server.
This eliminates 6 to 8 RPCs or more!

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/