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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
