[8898] in bugtraq
SRP summary + opinions
daemon@ATHENA.MIT.EDU (Pete Gonzalez)
Sun Jan 3 14:38:30 1999
Date: Sat, 2 Jan 1999 02:08:44 -0500
Reply-To: Pete Gonzalez <gonz@JEFFERSON.ML.ORG>
From: Pete Gonzalez <gonz@JEFFERSON.ML.ORG>
To: BUGTRAQ@NETSPACE.ORG
I'd like to thank the many people who responded to my previous posting
regarding SRP; there were too many messages for me to reply personally
to everyone. I've compiled a brief digest of the messages I received,
and I'll make it available to anyone who asks. If someone doesn't
want their message included the digest, please let me know.
Here's an anonymous synopsis of the replies I received:
- There is an SRP mailing list, and someone who uses SRP said the
Stanford people have been very responsive and helpful. Also, there's
lots of info here: http://jafar.stanford.edu/srp/doc.html
- Although Stanford's implementation only speaks about being free for
"non-commercial use", their web page says the SRP technology "is based
entirely on arithmetic and hashing, both of which can be done with
freely-available code and algorithms. Thus, entirely free
implementations of SRP can and have been written."
- Someone said he was unable to find a BSD version. Someone else said
he got it working on BSD, but with a minor "protocol problem".
- Someone said work is being done on SRP-secured IMAP/POP implmentations.
- Several people said that although the password exchange is secure, the
actual sessions are unencrypted. If this is true, it's a serious
deficiency of the protocols. However, the Stanford web page says:
"SRP exchanges a session key in the process of authentication. This
key can be used to encrypt the user's login session and protect it
from both snooping and malicious active attack."
- And, lastly, although the responses were generally enthusiastic, one
person made this troublesome statement: "The Stanford campus as a
whole does not use SRP. It has been considered and rejected as being
largely untried (particularly within the crypto community) and having
no obvious advantages over modern Kerberos in our environment. The
security claims made by the grad students who invented the protocol
have come under considerable fire by the sci.crypt community, and the
methods by which they have attempted to prove the superiority of their
solution have left something to be desired."
And now for my personal opinions... :-)
I've heard many people make statements which basically say "the general
internet community is stupid and lazy for not adopting secure protocols,
since many options exist and crypto technology is a tried&true theory."
I'll state up front that I'm a novice when it comes to security, but
it seems that none of the existing secure protocols is suitable as a
"standard" for general acceptance. Each fails to meet one of the
following apparently obvious basic requirements:
- The technology should be freely available, both for commercial use
and for GPL products. Preferably, not subject to US export
regulations (e.g. it's developed outside of the US).
- The protocols should provide secure client authentication, and
optional server authentication, but without cumbersome keys or
ticket servers to coordinate: A user should be able to walk into
an an aribtrary computer lab and login with a username and
password. Smartcards or floppy disks with key files should be
strictly optional. :-)
- The system should support all the basic modern advances in
cryptography; it should be safe against packet sniffing,
man-in-the-middle attacks, replay attacks, dictionary attacks, etc.
The server should never get enough information from the user to
reconstruct the user's password.
- It should be easy to retrofit existing protocols. At the very
least, there should be a standard implementation in
portable library form. Converting a TCP service should be
possible with a simple wrapper (like what sslwrap does).
It seems like all the technology is there, but it's just a matter
of someone putting the pieces together, drafting some RFC's, and
releasing a library. SRP seems to come really close, and might
actually be the sought solution if the claims on their web pages
are true. Unfortunately, that last person's statement casts
some doubt on this.
Perhaps there already exists some ideal solution, and I've just
overlooked it? If so, I would happily adopt it on my network and
volunteer to help with retrofitting support for mail/www/telnet/ftp
applications. :-)
Pete Gonzalez
Jefferson Systems
gonz@jefferson.ml.org
