Repost of CompuServe Position on Passphrases

Due to some nuances with the TLS list server, some folks didn't recieve
the following message the first time. Therefore we are reposting. Sorry   
for the
duplication of you have seen it.
******************************************

WHY SUPPORT PASS-PHRASE AUTHENTICATION?

In the proposed work plan for developing a draft of the TLS 1.0/SSL 3.x
protocol, Win Treese wrote:

        7/30/96 All issues on the table, with justifications why they
               are important. On or about 8/2/96, I will post a
               summary of where we are. Some issues may be
               accepted or rejected in ensuing discussion during July.

Since CompuServe intends to support pass phrases for authentication for   
the
foreseeable future, we would like to see an application-
independent authentication protocol that supports pass phrases.
To make sure all issues are discussed regarding the inclusion of
pass phrase based authentication in the TLS protocol we submit the   
following.
Some are reasons to support pass phrases; some items debunk myths that
sometimes become arguments for forbidding pass phrases.

In this paper, the term "credentials" refers to whatever the user must
possess, such as a name and a private key or secret key, to complete the
authentication process.

PASS PHRASES ARE INSECURE--One sometimes hears the argument that pass
phrases are inherently insecure. Generally, there are three such
arguments, all false.

First, the argument goes, pass phrases are insecure because someone who
intercepts network traffic between the user and service learns the pass
phrase. Such an argument is predicated on the concept of transmitting
pass phrases in the clear. Anyone who transmits pass phrases in the
clear should be shot. This is not an argument against pass phrases, but
an argument against a particular implementation of pass phrases.

(The public-key equivalent false argument: To prove that I know the
private key that corresponds to the public key in the certificate I sent
you, I will transmit my private key in the clear, and you may use it to
verify that it corresponds to the public key. But anyone watching learns
my private key. Therefore, public keys are insecure technology. QED.)

There are simple, secure challenge-response mechanisms that prevent an
eavesdropper from learning the pass phrase. These mechanisms are, in
fact, identical in concept to mechanisms used with public keys--we
generate challenges, you sign it, and I check the result--although
they're quite a bit faster than the public key algorithms.

Next, the argument goes, pass phrases are insecure because an
eavesdropper can discover your pass phrase by using a dictionary attack.
The old, Unix-style, across-the-board dictionary attack is not
applicable, but one could attack an individual challenge-response pair.

That is certainly a valid concern. But we call them pass phrases for a
reason: most implementations encourage, or even require, the use of a
very short "password," and that's wrong. You can avoid a dictionary
attack simply by using a pass phrase that won't be discovered by a
dictionary attack. Furthermore, the underlying mechanism is based on a
binary string of bits. If you don't mind giving up the ability to type
your pass phrase, your pass phrase can be a random binary number, which
is not at all subject to dictionary attack.

Finally, the argument goes, pass phrases are insecure because the
service must know your pass phrase to verify that you used the right
one. But the service needn't know your pass phrase; many schemes, such
as Kerberos, KryptoKnight, RPA, and even the typical, if not terribly
general purpose, RADIUS scheme used by PPP servers to support CHAP,
accomplish pass-phrase authentication without requiring the service to
know, nor allowing the service to learn, the pass phrase.


YOU DON'T HAVE TO USE THEM--If you don't want to use pass phrases for
authentication, you don't have to use pass phrases for authentication.
The argument that pass phrases should be forbidden in a protocol because
you wouldn't use them in your application, is unfounded.


THE VALUE OF WHAT'S BEING PROTECTED--If you're protecting something for
which you believe that a simple pass phrase is inadequate, you can
require better pass phrases. And if you believe that any textual pass
phrase is inadequate, you can use a random binary shared secret. And if
you believe that a random binary shared secret is inadequate, you can
use some other mechanism. Again, the argument against the ability to use
a mechanism because you wouldn't use it to protect the Space Shuttle's
self-destruct mechanism, is unfounded.

(People's checking and savings accounts are protected by a four-digit
number. People clearly go overboard in both directions--ridiculously
weak and ridiculously strong--when designing security mechanisms.)


CUSTOMER SERVICE--If a user loses his credentials, either in the sense
of their being compromised or they're no longer existing, it should be
easy to fix. With pass phrases, a customer service representative may
easily change the user's pass phrase and tell the user the new one,
during the customer's telephone call. The customer may immediately use
that pass phrase to authenticate himself. (Obviously, he may immediately
change it afterward.) With public key authentication, the problem can't
be solved in one telephone call. Similar issues arise for a newly
signed up user.


MULTIPLE SERVICES--Many service providers want to provide multiple
services to a user, without requiring that user to possess multiple
accounts or identities or credentials. Consider, for example, an
Internet service provider that wishes to provide IP connectivity via
PPP, and additional services. With current technology, one must use a
pass phrase for PPP authentication (preferably with CHAP, but that's not
the issue at hand). Ideally, the same identity and pass phrase should be
useful for other services provided by that service provider, impossible
if pass phrases are required for PPP but forbidden for other services.


MULTIPLE MACHINES--Many users use more than one machine; two machines at
home, one at the office, a notebook, etc. Such situations are no problem
for pass phrases, but are more problemmatic for other technologies. Some
day, every machine will have a smartcard reader, but that day isn't here
yet. In the mean time, there are proposals for ways to export, transfer,
and import the contents of a "wallet," but those are too awkward for
ordinary users.


There are suggested schemes for generating private keys from a pass
phrase. There's a clever idea, but it might be considered more an
argument for than against pass phrases. Some suggest deriving the
private key from a pass phrase, then storing the private key in a
wallet, requiring a pass phrase again only when you wish to import the
key into another wallet. That's useful in some applications, but most
users would have forgotten the pass phrase by the time he needs it.


NOT STORING ON MACHINE--A closely related question is that of using your
identity without storing your credentials on the machine. There are
primarily two reasons you might want to do that.

First, you might simply prefer to carry your credentials with you--I   
don't
want to store them on my machine because I don't want someone to be able
to use my account.Second, it might not be your machine--I want to check
my email from the machine in a conference room, or, would you mind if
I check my email from your machine?

For such purposes, pass phrases work well. Another approach is to carry
a diskette, and import the credentials into a wallet on the temporary
machine, use them, then remember to delete them, but that can be
awkward. Of course, there are obvious trust issues; even to use it only
temporarily, you must trust the software on that machine. But those
issues arise no matter what technology you use--with public keys, you
must trust the machine when you import the copy of your private key, and
with smartcards, you must trust the machine not to ask your smartcard to
sign anything other than what you intended to sign--so those "trust"
issues are irrelevant to the "pass phrases or not" argument.


EXISTING USER BASE--If you already have a set of users who use pass
phrases for authentication, you do not want to migrate to a new protocol   
that
won't be capable of authenticating them, so you won't migrate to the new
protocol.


PASSPHRASES AS A SEPARATE LAYER--There are two good reasons for including   

passphrase-based authentication directly into the protocol, rather than
layering it on top, as must be done with currently available protocols.
One reason has to do with the messy details of export controls:
if incorporated into the protocol, an authentication response can
be protected by a stronger key than is permitted for exportable
encryption of generic bulk data.  The other reason has to do with
interoperability; if a single, well-designed passphrase-based   
authentication
protocol can be selected as the standard for use in conjunction with TLS,   

then those who choose to use it (and only those who do) need not worry
about designing and implementing such a protocol from scratch, and
ensuring that all clients and servers are supplied with the same
implementation.


PASS PHRASES WILL DELAY THE TRANSITION TO PUBLIC KEYS--If you believe
that public keys are such a bad solution that people won't use them
unless they're forced to use them, then they ARE a bad solution and we
should delay the transition to public keys. Conversely, if public keys
are the right solution, the marketplace will embrace them, and systems
using other authentication mechanisms will disappear.


PRIVATE KEYS CAN BE STORED SECURELY; PASS PHRASES CANNOT--
One sometimes
hears the argument that private keys are secure because the "wallet"
(credential storage facility) on the PC can prevent anyone from seeing
them, while pass phrases are insecure because the API must include a
function that returns a copy of the pass phrase. This turns out to be a
meaningless argument that neither private keys nor pass phrases win.

First, it's not necessarily true that the "wallet" must reveal a pass
phrase. Just as the wallet knows about various public-key authentication
schemes, it can know about various secret-key authentication schemes.
Using exactly the same techniques, its API can protect the shared secret
by providing only a "you give me the challenge and I'll give you the
response" function.

On the other hand, if one wants to be able to use a particular pass
phrase with plaintext authentication schemes, then there indeed must be
a function to return that pass phrase. So, one might argue, pass phrases
are indeed weaker.

But, on the third hand, it's easy to forget that a function that returns
a response given a challenge--in PK terms, a function that signs the
specified input--is almost as good as revealing the secret. (Naively
designed, it's literally as good, but we presume here that the designers
understand that the function must do PKCS-1 formatting, etc.) That is,
"making sure you can't _see_ the secret" is only one aspect of the
problem, albeit an important one. "Making sure you can't _use_ the
secret" can be nearly as important, because I, as a rogue program, can
do interesting things even if I can't see your secrets, yet that's
almost impossible to protect against.

And on the fourth hand, one must consider that the wallet provides an
"export" function that indeed reveals all secrets, including private
keys, in a (necessarily) well-defined format that I, the program
requesting the exported copy, can decrypt and read. (This is probably an
argument for adding some otherwise gratuitous UI to the low-level wallet
export function.)


STATE OF THE TECHNOLOGY--So far, no one has deployed public keys for
authentication in an environment involving real users. And we know of no
one who has yet determined the costs to implement a large-scale
certificate signing operation, in terms of manpower, security, hardware,
licensing, etc. Almost all currently envisioned PK-based operations are
relatively small, "intranet" environments. And even those are only
envisioned; this is untried technology.

CompuServe Incorporated

Received on Monday, 22 July 1996 14:33:00 UTC