RE: Repost of CompuServe Position on Passphrases

The solution suggested below 

>>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?

Don Schmidt
donsch@microsoft.com
Program Manager
Microsoft Corp.

>----------
>From: 	Christopher Allen[SMTP:ChristopherA@consensus.com]
>Sent: 	Friday, July 26, 1996 4:46 PM
>To: 	Keith Ball
>Cc: 	ietf-tls@w3.org
>Subject: 	RE: Repost of CompuServe Position on Passphrases
>
>At 3:49 PM -0700 7/26/96, Keith Ball wrote:
>>Issues:
>>Against:
>>1) scalability: the user's ability to remember a different password for
>>every
>>service and that that simply doesn't scale because a person has a finite
>>number of things that he can remember.
>>2) symmetric: both sides must know the secret.
>>3) dictionary attack possible if use human-simple passphrase (even though
>>can
>>reduce this if require multiple words and non-alpha characters, e.g.
>>1toad$frog2, and the same format is not required on all passphrases)
>
>I'd like to to the Against:
>
>You can still have password security at the application protocol level.
>Nothing in the current protocol prevents this. For instance, right now you
>can add SSL under ftp, use SSL's server-only authentication or
>diffie-helman anonymous to secure the channel, and then 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.
>
>It's not elegant, but neither is shoehorning passwords into TLS, and it has
>the advantage of working now.
>
>------------------------------------------------------------------------
>..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 Wednesday, 31 July 1996 20:46:28 UTC