W3C home > Mailing lists > Public > ietf-tls@w3.org > April to June 1996

RE: Password Authentication (was RE: Merged Transport Layer Protocol Development)

From: Dan Simon <dansimon@microsoft.com>
Date: Thu, 25 Apr 1996 13:42:41 -0700
Message-Id: <c=US%a=_%p=msft%l=RED-92-MSG-960425204241Z-30774@tide21.microsoft.com>
To: "'ietf-tls@w3.org'" <ietf-tls@w3.org>, "'Tom Weinstein'" <tomw@netscape.com>
>From: 	Tom Weinstein[SMTP:tomw@netscape.com]
>I have to agree with Mr. Kemp.  Passwords for purposes of
>do not belong in a protocol that claims to provide cryptographic
>security.  If you really want to use passwords, you can always do it in
>an application level protocol.
>What's wrong with public key cryptography?

Personally, I love public-key cryptography.  Unfortunately, many people
are not ready to convert to it yet, for at least two reasons I can think
of offhand:  there are entire infrastructures out there based on
passwords, and people are loath to abandon them for a new technology
that has had much less time to "settle"; and the technology for
transporting asymmetric private keys to arbitrary trusted machines
safely and conveniently is not yet widely available.

Now, if I believed that the force of my eloquence could quickly convince
them all to follow us cryptographers into a magnificent new era of
public-key cryptography, then I would forget about trying to stick
passwords into this working group's protocol.  But I can't.  And that
means that passwords will continue to be widely used *regardless* of
what we do.  Moreover, a large fraction of those passwords will, for
reasons we're all familiar with, be sent (or used to compute
authentication responses sent) over connections only protected by 40-bit
encryption keys.  Passwords used in that manner are subject to offline
brute-force attacks, first on the 40-bit encryption, then second (if
necessary) on the password-based response.

On the other hand, if we incorporate password authentication into the
protocol, then we can protect those passwords by basing the
challenge-response protocol on both the password and the
automatically-strong MAC key exchanged during the handshake.  This will
protect the password from offline attacks, making even a poorly chosen
password a useful security tool (assuming that it's kept secret, and
that the server doesn't permit unlimited online trial-and-error

That's still not as secure as public-key cryptography, of course.  But
it's better than what password users will have otherwise.  And the cost
to people who *don't* want to support or implement passwords is *zero*. 
No extra code, no extra administration, no extra security risk.  Only
the vague feeling of unease over somebody somewhere else getting a
chance to make a security decision that they (and I, to some extent)
disagree with.

Now, what's wrong with *allowing* password authentication into the

				Daniel Simon
				Cryptographer, Microsoft Corp.

Received on Thursday, 25 April 1996 16:44:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:17:11 UTC