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

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

From: Dan Simon <dansimon@microsoft.com>
Date: Wed, 24 Apr 1996 10:51:01 -0700
Message-Id: <c=US%a=_%p=msft%l=RED-92-MSG-960424175101Z-26078@tide21.microsoft.com>
To: "'ietf-tls@w3.org'" <ietf-tls@w3.org>

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 to
other practical priorities.

				Daniel Simon
				Cryptographer, Microsoft Corp.
Received on Wednesday, 24 April 1996 13:51:15 UTC

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