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

Password authentication

From: Tim Dierks <timd@consensus.com>
Date: Thu, 25 Apr 1996 19:51:51 -0700
Message-Id: <v02140b0aada5e7a48c3a@[205.149.165.24]>
To: ietf-tls (Transport Layer Security WG) <ietf-tls@w3.org>
In the recent discussion of the STLP "strawman", several issues have come
up; here are my thoughts on a few. For what it's worth, I'm in the middle
of implementing SSL 3.0 right now.

- Password authentication: I think password authentication of clients may
be an acceptable part of the standard. If the market wants to use passwords
instead of certificates, they're going to do so. The alternatives appear to
be either negotiating an unauthenticated session and having the application
layer do the password authentication or allowing the transport layer to
deliver the password as a part of the negotiation. I think that allowing
the latter is acceptable for the following reasons:
 1) It allows a standardized method of communicating passwords; this moves
widely divergant code out of a variety of dependant protocols and
centralizes it.
 2) It allows applications which use the secure transport layer to
generalize their authentication; they don't need to special case password
authorization on top of an unauthenticated session.
 3) It allows us to standardize a more secure method of password
communication; this will avoid applications creating methods which require
the password to be sent over the wire and stored in RAM (even if it is sent
over a secure link, it will be delivered into the application layer in
plaintext).
 4) It need not impact security. A password-authenticated session can still
be completely private (a network snooper or a man in the middle should have
no more, and possibly less, chance of access to the contents of a
password-authenticated session when compared to an unauthenticated
session).
However, I think password authentication should be an option only available
to the client side of the session. (If the end result protocol is as
asymmetric as current ones are.)

Just to be clear, I'm discussing password authentication; I do not
recommend using the password as a part of the negotiation of the encryption
keys or IVs. Furthermore, the password should be protected by a salt and
transmitted after the transport security has become active (after a
change_cipher_spec message in SSL.) One possible solution would be to
append two fields to SSL's finished message when sent from a client to a
server: the user name and a password field, where the password field is a
MAC of the actual password:

hash(MAC_write_secret + pad_2 +
  hash(MAC_write_secret + pad_1 +
    hash(user name + password)))

The server would store <user name, hash(user name + password)> pairs; this
provides for a salt against the password storage on the server. The server
can calculate the same MAC on its side and compare them.

This would
 - Provide a password in a standard fashion
 - Protect the password with a secure transport
 - Protect the password by only supplying a MAC of the attempted password
 - Not add another round-trip to the negotiation

 - Tim Dierks

Tim Dierks - Software Haruspex - tim@dierks.org
Hastening the heat-death of the universe since 1968.
Received on Thursday, 25 April 1996 22:50:21 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:34:48 EDT