alfs authentication protocol: requirements

pak_lfs at pak_lfs at
Mon Nov 28 07:33:02 PST 2005

Bruce Dubbs wrote:
> pak_lfs at wrote:
> > 3. For this protocol to be convenient enough for its typical use case
> > (one client multiple servers), there must be a *single* authentication
> > token authenticating the client to all servers. 
> I don't think this is a wise way to go.  The client can hold multiple
> tokens encrypted by a master token that never leaves the client.
> Perhaps a ticket mechanism, like kerberos, would be the way to go.

Could you please ellaborate why this would be unwise, if that token is not
a password? If you have some extra time, could you  read

first? (It has some nice notes on how to design a new authentication protocol.
I based my requirements on this).

I was thinking that this token could be a private/public key combination where
the private key stays (of course) always in the client and is encrypted with
a password. When you start your client, you supply the password and the
client uses it to decrypt the private key. 

This is then used for user authentication with all servers, in a ssh-rsa-like 
way. So, every server just has a copy of the same client public key, placed
there out of band (when you installed the server).

Now let's see some what-ifs:

     If the client computer is stolen, the bad person still has to decrypt the 
private key to authenticate with *any* server. If they know/find out the
password, then all your servers are owned whether you have one private
key or several.

     If they don't know/find out the password, then again all your servers are
safe and it doesn't matter if you have one or several private keys.

So, in all cases the weak part is the single password, but most linux/unix 
users that have the abilities/need to maintain several remote machines, 
(should) know how to construct a pretty unpredictable long password, so I
guess it will be ok. 

The alternative would be to have one password/server which is not neccessarily
more secure (If the servers trust each other for other jobs, they will sooner
or later be owned anyway) and even in my case (~100 machines) it is 

The main benefit of a single private key is conceptual simplicity and perhaps
it is also easier to update.

In any case, I 'm nowhere near a security expert so if the above
are mistaken, I 'll be happy if someone corrects me where I 'm wrong.

Thanks :)

____________________________________________________________________ - äùñåÜí õðçñåóßá çëåêôñïíéêïý ôá÷õäñïìåßïõ. - free email service for the Greek-speaking.

More information about the alfs-discuss mailing list