RE: Repost of CompuServe Position on Passphrases

see comments below
>----------
>From: 	Eric Murray[SMTP:ericm@lne.com]
>Sent: 	Wednesday, July 31, 1996 11:39 AM
>To: 	Don Schmidt
>Cc: 	Jeff Teper; Keith_Ball@novell.com; ChristopherA@consensus.com;
>ietf-tls@w3.org; jmacko@csi.compuserve.com
>Subject: 	Re: Repost of CompuServe Position on Passphrases
>
>>Don Schmidt writes:
>>> 
>>> 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.
>
>>I disagree. For the services named above, the implementer will want to
>>keep the non-TLS functionality in place for connecting to
>>non-TLS version of the service.  Hence, the existing password
>>mechanisim will remain.  If the TLS versions use TLS-password
>>authentication instead of the existing password authentication, then
>>new calls will need to be written to support the TLS passwords
>>in addition to the existing passwords.

Nothing about this proposal prevents continuation of existing
functionality.  The fact that each app protocol does password auth its
own way (and potentially to its own security db) is precisely the
argument for a single standard mechanism.

Also, remember this is being requested by consumers, not implementers.
We already have extra work to do to implemet TLS.  Furthermore, if a
standard provider I/F -- such as GSS-API, or NT's SSPI implementation of
the GSS-API -- is used, this vastly simplifies the adaption of each
protocol to a single auth mechanism.

>>Similarly, the deployment and administration will, at least in
>>the short to medium term, be more complicated, not less.  With
>>TLS-autheitication passwords there's now one more password database
>>that will need to be maintained, checked for weak passwords etc.
>>Arguably, most installations will want to support the non-TLS versions
>>of the above services, for service inside the "secure" LAN.

In the context of establishing a new IETF standard, we must consider
ourselves as service providers.  As such, it is not our place to assume
what our customers want.  We have a clear request for a single shared
secret auth mechanism.  More than one large Internet service
organization has expressed the desire to simplify administration by
migrating from multiple security dbs to a single (but distributed)
security db.  They want to support fully distributed auth -- users
anywhere on the Internet authenticating at  servers anywhere on the
Internet -- and yet administer user accounts, credentials and
authorizations in a centralized datacenter.  A single, app-independent
auth mechanism makes this much easier to implement.  
>
>>>  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?
>
>>1. they already have password based auth built into their protocols.
>>Adding TLS underneath can make the passwords "secure" without requiring
>>as much of a rewrite of the code.

Same as above.  This does not address the requirement.

>>2. not putting password auth in TLS will encourage new apps
>>to use the much superior certificate-based authentication
>>rather than allowing lazy implementers to stick with the
>>familiar old passwords.

Using an IETF standard to force impelementors (or consumers) to conform
to an opinion is not appropriate.

>-- 
>Eric Murray  ericm@lne.com  ericm@motorcycle.com  http://www.lne.com/ericm
>PGP keyid:E03F65E5 fingerprint:50 B0 A2 4C 7D 86 FC 03  92 E8 AC E6 7E 27 29
>AF
>

Received on Thursday, 1 August 1996 17:57:28 UTC