- From: Dan Simon <dansimon@microsoft.com>
- Date: Wed, 24 Apr 1996 12:50:49 -0700
- To: "'ietf-tls@w3.org'" <ietf-tls@w3.org>
I am resending this email with apologies, and ">" attributions corrected.... ------------ >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 15:51:14 UTC