Re: Anyone has read the FSF Usenix speech ?

[Niels Möller]

[ This is a late reply, I've been on vacation for a few weeks, and
  then I've been quite busy moving ]

Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> writes:

> On Wed, Jul 11, 2001 at 07:18:53PM +0200, Robert Bihlmeyer wrote:
> > Most people would simply shurg if I tell them that you can have a
> > directory hierarchy a million levels deep. But showing them, say, a
> > lsh daemon that runs without uids (and gets them when needed via the
> > passwd server, or a yet-to-be-written pubkey server) would certainly
> > raise a few eyebrows.
> 
> Neal and me had a few ideas in the train back from Bordeaux to Paris[1] about
> what is needed to make this "run-daemon-without-ids" idea working out better.

To me, it seems that this would mean running several servers analogous
to the standard passwd server (i.e. handing out ports to the
authentication server in exchange for some external credentials like a
password), but using something more fancy than passwords. That's cool.

The simplest example is perhaps the pubkey-server. You probably can't
have it accept any random message and a signature as valid
credentials, instead, there must be some challenge-response thing that
let's the server influence the message being signed. And on the other
hand, the message that is to be signed is a result of SSH protocol
exchanges between the lshd daemon and the client.

You need a protocol with three parties,

  CLIENT <-> LSHD DAEMON <-> PUBKEY-SERVER

The lshd running with no ids, and acting as an intermediary (for the
userauth components of the protocol).

The pubkey server that has to be trusted (by the authentication
server) in some way, but it doesn't trust lshd. From its point of
view, lshd is a random process with no ids.

Furthermore, there may be information that client and lshd needs to
share, which should not leak to the pubkey server (e.g session keys),
and other information shared between the pubkey server and the client,
which shouldn't be leaked to lshd...

Bottom line: It's cool, but probably non-trivial to get Right. I'd be
very interested to hear what you're doing.

Regards,
/Niels