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

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
>establishing
>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
>layer
>security is being used.  I don't agree that that layering scheme is
>"not desirable".

>Normally, protocol definitions should provide mechanisms, and
>configuration
>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
>authentication.

>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.
				dansimon@microsoft.com

Received on Wednesday, 24 April 1996 13:51:15 UTC