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

Re: Repost of CompuServe Position on Passphrases

From: Eric Murray <ericm@lne.com>
Date: Wed, 31 Jul 1996 18:39:34 +1700 (PDT)
Message-Id: <199608010139.SAA32135@slack.lne.com>
To: donsch@microsoft.com (Don Schmidt)
Cc: Keith_Ball@novell.com, ChristopherA@consensus.com, ietf-tls@w3.org, jeffte@microsoft.com, jmacko@csi.compuserve.com
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.

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.

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

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.


-- 
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 Wednesday, 31 July 1996 22:03:33 EDT

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