Date: Sat, 14 Aug 1999 11:59:11 -0700 (PDT) From: Kris Kennaway <kris@hub.freebsd.org> To: nsayer@freebsd.org Cc: freebsd-hackers@freebsd.org Subject: Re: Whither makefiles for src/crypto/telnet/* ? Message-ID: <Pine.BSF.4.10.9908141139440.78768-100000@hub.freebsd.org> In-Reply-To: <37B5B6DD.A2A2448B@quack.kfu.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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. 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? > 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. 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). Once you have authenticated, you can use that to negotiate a session key, which can be used to encrypt the remainder of the session. 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) > 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. Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9908141139440.78768-100000>