New design, what is the Goal here?

rl at rl at
Tue Nov 29 16:53:18 PST 2005

On 2005-11-29 18:24:02 +0000, Kendrick wrote:
> rl at wrote:
> >I cannot see the advantage of creating yet another network 
> >authentication protocol.
> >
> Is openssh's key system available in source? 

openssh is open source. It uses openssl for authentication and 
encryption. Assymetric algorithms are used to exchange a secret 
that allows less computationally intensive symetric algorithms 
to transport the protocol.

The symmetric algorithms would be susceptable to plain text attack: 
Before ssh got more complicated, each time you pressed a button, 
one charater is echoed back - unless you pressed enter, in which 
case lots comes back. This told crackers which bytes in the stream 
were 'enter', so they had some knowledge of the plain text. Over 
time they could collect enough knowledge calculate the secret used 
for the seesion. Ssh now sends some random data at random times 
so crackers cannot tell when you pressed enter.

Are you begginning to see why I would have no confidence in the 
security of a home brewed protocol? Instead re-inventing ssh, or 
rippling bits of its source code into your project, just use ssh.

> the system to create
> signed email/html is that available from source? 

Signed email: gnupg
Signed html: apache/openssl (there are other combinations)

> Unless I missed
> somthing some where, I havent seen an agreement on what type or how the
> authentication will be done so this seems a bit premature IMO. 

AFAIK people have not proposed a particular type of authentication.
What has been proposed is that this authentication is built into alfs, 
and that alfs is a client/server system.

I think this adds a huge amount of pointless complexity. Imagine that 
three of the 90 machines you want to update are turned off. An email 
based system would use e-mails built-in store and foreward abilities. 
An http/cron solution would also let those machines catch up in their 
own time.

> I dont
> see why we cant use some known good system for this purpose.  I know krb
> tickets wouldent work well for home users but that was just  one of the
> suggestions.  I would suspect some sort of ssl/ssh based auth would be
> redily avalible on 99% of the systems. Afik, a method to include that in
> our project is already redily available, I dont know how hard to
> intigrate those will be.  I would suspect though that if nothing else
> somthing out there already could be redily adapted when that time comes.

Krb is fine, and has advantages on a large scale, but it is a lot of 
configuration to inflict on a home user, who has nother to gain from it.

ssh is fine on a home network. Maintaining the keys over a large 
network does not sound like fun.

By including authentication in alfs you are either adding a restriction 
like "Use kerberos", or you are adding complexity: learn how to 
configure alfs to work with PAM.

If instead, alfs is just a program for installing programs on the local 
machine, you can use ssh methods to extend it to work on a remote 
machine - and the knowledge you gain from ssh can be applied to control 
other tools with ssh. Likewise, a set of mailing-list sending signed 
scripts teaches people how to run a mailing list, how to use gpg, and 
how to deliver email to programs.

You can make alfs into an emacs/netscape product with a built-in mail 
user agent, a built-in editer, a built-in coffee maker. I think you 
would be better off using unix philosophy: a program should do one 
thing, and do it well. Make alfs an excellent tool for installing 
software on the local machine. Then you can use another tool that 
is specialised at working remotely, and another tool that is 
specialised at maintaining lists, and another tool that is specialised 
at handling store and forward and so on. That way you can pick the 
best components and glue them together to meet your needs - instead of 
having to work arround a built-in feature that is alright, but not the 
best in the field.


More information about the alfs-discuss mailing list