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

RE: Password Authentication

From: Dan Simon <dansimon@microsoft.com>
Date: Thu, 25 Apr 1996 16:19:06 -0700
Message-Id: <c=US%a=_%p=msft%l=RED-92-MSG-960425231906Z-31676@abash1.microsoft.com>
To: "'ietf-tls@w3.org'" <ietf-tls@w3.org>, "'dpkemp@missi.ncsc.mil'" <dpkemp@missi.ncsc.mil>
>From: 	dpkemp@missi.ncsc.mil[SMTP:dpkemp@missi.ncsc.mil]
>Consider the following thought experiment:
>* PCT 2.0 protocol, using password authentication, where the password
>  can be only a 4 digit number (10,000 possibilities), and no
>  public/private key pairs at the two endpoints
>* 2 Princeton students with a copy of a PCT session sniffed off
>  the wire (no active attacks allowed)
>Can they, or can they not break the session in a minute or so by
>exhausting over the password space?
PCT 2.0 does not permit this kind of authentication.  Password-based
authentication is only permitted for either the client or the server
(*not* both), in conjunction with a public-key-based key exchange. 
Moreover, a password-based authentication response may not be sent
unless the accompanying key exchange either uses the other party's
certified public key or has already been incorporated into the other
party's (certified) digital signature-based authentication response. 
(These conditions ensure that only the correct "other party" knows the
master key used in the password-based authentication response.)  The
response is essentially a cryptographic hash of the responder's identity
and password, the challenger's (and responder's) challenge, and a (long)
shared MAC key derived from the exchanged master key in the normal way.

A typical application would be improving the security of the type of
password-based client authentication scheme in wide use today:  a server
with, say, a certified RSA public key accepting secure
server-authenticated connections from clients, then requesting a
password (or password-based challenge response) over the connection to
authenticate the client.  If instead the client authenticated based on a
shared password and the MAC key as described above, even 4-digit
passwords would be secure against offline attacks, and even in
connections using only 40-bit encryption keys (assuming that MAC keys
can be longer).  And to the best of my knowledge, there are no export
problems with such a scheme, since the keyed hash does not allow (as far
as I can tell) recovery of the input secret (password), only
verification of its correctness.  However, since this method involves
the MAC key, which should not be available to the application
(especially if the protocol implementation is supposed to be
exportable), this type of authentication must be defined at the protocol

The STLP document proposes a very similar password-based authentication
option.  I believe it would be a useful feature to have in any protocol
that emanates from this working group.

				Daniel Simon
				Cryptographer, Microsoft Corp.
Received on Thursday, 25 April 1996 19:19:10 UTC

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