New design, what is the Goal here?
rl at nezumi.plus.com
rl at nezumi.plus.com
Tue Nov 29 16:53:18 PST 2005
On 2005-11-29 18:24:02 +0000, Kendrick wrote:
> rl at nezumi.plus.com 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
> 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