[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

auth handshake and rendevouz objects

From: Marcus Brinkmann
Subject: auth handshake and rendevouz objects
Date: Wed, 16 Oct 2002 18:39:00 +0200
User-agent: Mutt/1.4i


darn, just wrote a nice long mail, and then deleted it.  Now you have to
live with the terse version :)

We talked about auth and rendevouz objects before, and I think we concluded
that the rendevouz object should be managed by auth (at least that's how I
recall it).

I just thought about it, and I think it should stay with the user.  This is
more flexible, and nonetheless secure.  The only task of the rendevouz object
is to establish validity and identity of the server provided rendevouz object
handle.  The client is free to say yes or no on that issue as he wants, as
the client is initiating and passing on the handle to the server in the
first place.  auth can just trust the client's opinion on this.

Of course, auth needs to be paranoid about sending messages to the client
(zero timeout, etc), but that's not a huge problem.  For moving handles,
this has to be done anyway, everywhere.  For the inquiry about the server
side validity of the handle, it's a requirement the client should be able to
fulfill easily.

Why am I raising this?  Because it makes a difference.  If auth provides the
rendevouz object, then auth defines the policy to whom the server might pass
on the handle (to everyone of course, as it is necessary for proxy servers
like fakeauth).  But then we deny the user of the option to refuse passing
on the server side handle if it wants to be extra paranoid.  As the grand
theme in our design is not to deny the user of options, we should not do
that here.

Mmh.  Didn't come out that much shorter, but hopefully a bit clearer than
the first version.  Have fun!


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]