Date:	Sat, 2 Jan 1999 02:08:44 -0500
From:	Pete Gonzalez <gonz@JEFFERSON.ML.ORG>
Subject:      SRP summary + opinions
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