On 2005-11-29 18:24:02 +0000, Kendrick wrote: > [EMAIL PROTECTED] 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. Richard -- http://linuxfromscratch.org/mailman/listinfo/alfs-discuss FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
