Kris Kennaway wrote: > > On Sat, 14 Aug 1999, Nick Sayer wrote: > > > Kris Kennaway wrote: > > > > > > On Fri, 13 Aug 1999, Dave Walton wrote: > > > > > > > If you really want to work on an encrypted telnet, check out The > > > > Stanford SRP Authentication Project (http://srp.stanford.edu/srp/). > > > > I'd love to see SRP integrated into the FreeBSD telnet/telnetd. > > > > > > I got started on this, to the extent of storing the SRP data in the passwd > > > file as an additional password crypt() method > > > > That will be incompatible with folks who, for example, use the old > > style passwords in a YP map in order to be compatible with other > > platforms > > in the same domain. > > By definition you cannot get around the need to store additional > authentication information to use SRP - it uses large integer mathematics > "along the lines of" RSA public-key cryptography to authenticate the user > securely, so it's not transparent as you correctly note. > > Using YP to share the password maps is problematic, since SRP "passwords" > have a different format than other algorithms. I don't know enough about > YP to speak on this, but if you can get away with sharing an > arbitrary-length "password hash" over YP then all SRP-capable clients can > use it. > > That's not the point, though - if you want to use legacy computer > platforms, you have to expect to use legacy passwords.
The point is that you can do so AND have an increase in security of communications. Is the result perfect? No. Is it better than sending it in the clear? Yes. Is it JUST AS EASY for everyone concerned as sending it in the clear? Yes. So it's just as easy to do a little as do nothing. Why, then, is it considered so horrible to have the option of doing a little? > I haven't looked at > the SRA algorithm, but it's not obvious to me how you can simultaneously > provide a well-encrypted (against an attacker who is watching the setup > phase) session, and at the same time only use the (traditional UNIX) > password and hash. I would be happy to answer that. You do a traditional Diffie-Hellman. You use the resulting shared secret to send the username and password from client to server, DES encrypted. The resulting shared secret can also be used as a DES (or other) key for session encryption after you're done. It is vulnerable to MiM. I have said as such a dozen times now. It should be painfully obvious that plaintext sessions are vulnerable to a hell of a lot more than just that. > At the best all you're doing is obfuscating the data > stream, which becomes dangerous if people think of it as "encrypted > telnet". Of course, I may well be wrong - do you have a pointer to a paper > describing the SRA algorithm? No, but I have the source and have made it available to anyone inside the US. I have also stated that it is available outisde the US, so anyone could use their favorite search engine and get it. > > > As long as you require a shared secret there will be either extra > > overhead > > to maintain it (in a separate password database) or an exclusion of some > > platforms because of inabilities to generate the shared secret (because > > they have different crypt()s than we do). > > > > Not requiring a shared secret allows monkey-in-the-middle. But the goal > > here is to do better than nothing at all while not adding any > > administrative > > overhead. If you add overhead, people won't use it. > > With a SRP-capable client and server, the client need know nothing other > than the password entered by the user. Agreed. > The server is configured at > passwd(8) time. This is the beauty of SRP - it IS transparent, while at > the same time being "secure" in the ways which a plaintext or CHAP > authentication is not (I don't have references to the papers which > describe the benefits of SRP handy, but I could find them if needed). I will easily conceed that SRP is more secure than SRA. But I disagree that it is as transparent as you claim. S/Key comes with FreeBSD. How many FreeBSD users use it? Never mind even that, how many people reading this e-mail use it? > Once you have authenticated, you can use that to negotiate a session key, > which can be used to encrypt the remainder of the session. Same with SRA. > If you have a non-SRP client, you can still authenticate against the > server using a plaintext password, and treating the server-side data as a > fancy password hash, but you obviously lose all the benefits (as well as > compromising your password if you use it from both types of client) There are other costs, however. Your SRP equipped host cannot participate in a heterogenous YP environment without maintaining SRP passwords separately (and killing the purpose of YP in the process). Even in a homogenous YP environment you have to synchronize valuse of N and g (according to the Stanford web site) throughout the organization. > > > SRA is a compromise > > between security and ease of use. "Compromise" is not a four letter > > word. > > Many would argue that in the language of cryptography and data > encryption, the word "compromise" has only one meaning. So you would rather that plaintext be the only available option that requires no overhead? How is anyone better served by that? Why are you so opposed to an incremental step towards better security?
smime.p7s
Description: S/MIME Cryptographic Signature
