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: Wed, 24 Apr 1996 12:50:49 -0700
Message-Id: <c=US%a=_%p=msft%l=RED-92-MSG-960424195049Z-26739@tide19.microsoft.com>
To: "'ietf-tls@w3.org'" <ietf-tls@w3.org>
I am resending this email with apologies, and ">" attributions
>I am responding to David Kemp's comments about password authentication
>separately, because I believe the topic is important enough to deserve
>separate treatment.
>>(From dpkemp@missi.ncsc.mil[SMTP:dpkemp@missi.ncsc.mil]:)
>>> (6) Password authentication (particularly for clients) is extremely
>>> desirable.  Right now, it has to be done at an application protocol
>>> level (and differently for every protocol).  Having part of
>> authentication occur at the SSL level and part at the application 
>>> protocol level is not desirable.
>>No.  Password "authentication" is not an acceptable means of
>>a secure connection.  It may be acceptable at the application layer,
>>for example to control access to particular portions of a html document
>>tree.  In that case, the basic authentication or digest authentication
>>occur at the application layer, independently of whether transport
>>security is being used.  I don't agree that that layering scheme is
>>"not desirable".
>>Normally, protocol definitions should provide mechanisms, and
>>options should be the means of enforcing policy.  However if the STLP
>>is defined in such a way as to allow weak authentication, it will not
>>be meeting it's goals.  As stated in the SSL spec, goal number 1 is
>>cryptographic security.  I hope most TLS working group members agree
>>with that.
>>I strongly recommend that STLP contain no provisions for password
>To me, the issue is not whether password authentication is weaker than
>authentication by certified asymmetric key; most everyone would agree
>that this is the case.  Unfortunately, for reasons ranging from
>established practice to portability issues to plain ignorance, many
>people will likely continue to use passwords for authentication for
>some time to come, whether protocol authors want them to or not.  The
>issue at hand is therefore whether password-based authentication must
>continue to be as weak as the encryption available (which is often, as
>we all know, woefully weak), or whether, by our protocol design
>choices, we can make the security of password authentication as strong
>as it can possibly be.
>Nobody advocates forcing people to use passwords (even if it were
>possible to do so).  The question is whether we can force them not to,
>and what to do given that we can't.  Anyone who doesn't trust
>password-based security is always free not to support it; in fact, it
>takes an explicit decision by both parties to share a password before
>password authentication even becomes possible.  People who make that
>decision are, in my view, no different from those who accept 40-bit
>encryption, or proprietary, relatively unstudied RC4 over
>heavily-analyzed (triple-)DES; we cryptographers might prefer that they
>choose otherwise, but we recognize that security must sometimes yield
>other practical priorities.
>				Daniel Simon
>				Cryptographer, Microsoft Corp.
>				dansimon@microsoft.com
Received on Wednesday, 24 April 1996 15:51:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:01:58 UTC