- From: Dan Simon <dansimon@microsoft.com>
- Date: Thu, 25 Apr 1996 16:19:06 -0700
- 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 level. 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. dansimon@microsoft.com
Received on Thursday, 25 April 1996 19:19:10 UTC