RE: Repost of CompuServe Position on Passphrases

At 12:44 PM -0700 8/1/96, Don Schmidt wrote:
>However, CompuServe and others have stated their business requirements
>to continue support for shared secrets.  There are obvious security and
>interoperability advantages to support them in a single, robust,
>widely-adopted protocol.

I still don't grok the requirement -- nothing in TLS prevents them from
continuing "support for shared secrets".

I don't see how not having this feature prevents CompuServe from creating a
secure, server authenticated channel, then using their existing password
infrastructure to then authenticate the client. I can do this today with
SSL under FTP, NNTP and without certificate-based client authentication. In
fact, many of our prospective licensees of the SSL Plus toolkit plan on
doing just that.

Tell me something that CompuServe can't do without this feature, and I
might be more in favor of it. But adding a password feature to a
certificate based protocol where it doesn't fit invites security holes and
poor implementations.

BTW, I don't buy the reasoning "but now shared secrets will be done in a
standard way under TLS". If everyone is going have to change things so that
it is done in a "standard way" to support passwords under TLS, they might
as well change it so that they use certs.

------------------------------------------------------------------------
..Christopher Allen                  Consensus Development Corporation..
..<ChristopherA@consensus.com>                 1563 Solano Avenue #355..
..                                             Berkeley, CA 94707-2116..
..Home of "SSL Plus:                      o510/559-1500  f510/559-1505..
..  Security Integration Suite(tm)" <http://www.consensus.com/SSLPlus>..

Received on Thursday, 1 August 1996 19:08:49 UTC