W3C home > Mailing lists > Public > ietf-tls@w3.org > July to September 1996

RE: Repost of CompuServe Position on Passphrases

From: Don Schmidt <donsch@microsoft.com>
Date: Thu, 1 Aug 1996 12:44:33 -0700
Message-ID: <c=US%a=_%p=msft%l=RED-86-MSG-960801194433Z-29607@abash1.microsoft.com>
To: "'ietf-tls@w3.org'" <ietf-tls@w3.org>, "'Christopher Allen'" <ChristopherA@consensus.com>
Cc: Jeff Teper <jeffte@microsoft.com>, "'jmacko'" <jmacko@csi.compuserve.com>
I agree in spirit.  However - certs are not yet ubiquitous; the
portability problems of certs & private keys vs passwords are not
completely solved; PK infrastructure and trust relationships are still
being worked out; and so on.  If all these problems were completely
resolved we would not be having this discussion.

I personally prefer PK-based authentication & authorization mechanisms.
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.  Dan Simon has described the export concerns
which favor adding shared secret support to TLS so that they can be
protected by the strongest possible crypto.

With this in mind -- and since this has been proposed as an optional,
not a mandatory auth mechanism -- can we please apply the incredible
brain trust on this thread to providing a solution instead of debating
the need?

Don Schmidt
donsch@microsoft.com
Program Manager
Microsoft Corp


>----------
>From: 	Christopher Allen[SMTP:ChristopherA@consensus.com]
>Sent: 	Wednesday, July 31, 1996 6:22 PM
>To: 	ietf-tls@w3.org
>Subject: 	RE: Repost of CompuServe Position on Passphrases
>
>At 5:46 PM -0700 7/31/96, Don Schmidt wrote:
>>>>use use FTP's current password methods to authenticate the client.
>>>>Same can be done with HTTP using it's current auth structure,
>>>and most every other protocol over SSL.
>>
>>is precisely one of the problems that including a standard shared-secret
>>auth mechanism in TLS is designed to solve.  Each one of these protocols
>>does password auth in an app specific manner.  It would greatly simplify
>>the development, deployment and administration of secured apps if there
>>is was one system-level protocol and I/F for security.  This is a
>>benefit of TLS for certificate-based auth.  When it is within our grasp,
>>who are we to deny the same benefit to  applications or service
>>providers that have reasons to continue to use shared-secret based auth?
>
>But if you are going to do that much engineering to change software to "one
>system-level protocol", then it should be a small step to using
>certificates correctly. If legacy is important, they use the application
>level AUTH commands over SSL. If you are doing something new, use
>certificates.
>
>------------------------------------------------------------------------
>..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 17:55:33 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:34:50 EDT