home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
drafts
/
draft_n_r
/
draft-petke-ext-intro-00.txt
< prev
next >
Wrap
Text File
|
1996-11-16
|
13KB
|
345 lines
INTERNET-DRAFT G Brown
draft-petke-ext-intro-00.txt CompuServe
Expires: 15-May-97 15 November 1996
Remote Passphrase Authentication
Part One: Extended Introduction
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
"work in progress."
To learn the current status of any Internet-Draft, please check
the "1id-abstracts.txt" listing contained in the Internet-
Drafts Shadow Directories on ftp.is.co.za (Africa),
nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
Abstract
Remote Passphrase Authentication provides a way to authenticate a
user to a service by using a pass phrase over an insecure network,
without revealing the pass phrase to eavesdroppers. In addition, the
service need not know and does not learn the user's pass phrase,
making this scheme useful in distributed environments where it would
be difficult or inappropriate to trust a service with a pass phrase
database or to allow the server to learn enough to masquerade as the
user in a future authentication attempt.
This draft is part one of a four part series and contains an extended
introduction to the problem and potential solutions to the problem.
It is optional reading for those already familiar with the general
issues of authentication over insecure networks. Part two
(draft-petke-mech-00.txt) explains the RPA mechanism. Part three
(draft-petke-http-auth-scheme-00.txt) explains how to incorporate the
mechanism into HTTP. Part four
(draft-petke-serv-deity-protocol-00.txt) explains the protocol
between the service and deity.
This scheme was inspired by Dave Raggett's Mediated Digest
Authentication paper.
G Brown [Page 1]
INTERNET-DRAFT RPA - Part One 15 November 1996
Table of Contents
1. INTRODUCTION
1.1 IDENTIFICATION
1.2 AUTHENTICATION
1.3 AUTHORIZATION
2. THE PROBLEM AND HOW NOT TO SOLVE IT
2.1 ENCRYPT THE PASS PHRASE?
2.2 A CHALLENGE-RESPONSE MECHANISM?
2.3 WHAT IF I DON'T KNOW YOUR PASS PHRASE?
2.4 TWO MORE WAYS NOT TO SOLVE THE PROBLEM
3. SECURITY CONSIDERATIONS
4. AUTHOR'S ADDRESS
1. Introduction
In this introduction we'll explain the problem--fundamentally, how to
authenticate a user to a service without revealing a pass phrase, and
without requiring the service to know the user's pass phrase--and
consider several alternatives and their flaws, leading to the reasons
for developing this authentication mechanism. If you're already
familiar with the concept of authentication and the surrounding
issues, you might prefer to skip to Part two of the specification,
(draft-petke-mech-00.txt), returning to this part only if you
want more information about the motivation for the mechanism.
We'll speak of an environment in which a user communicates with a
service that wishes to learn and authenticate the user's identity and
vice versa. You may, of course, think in terms of client and server,
but those terms generally refer to an implementation. We're speaking
at a higher level where there's no direct correspondence between
server and service nor user and client.
We'll use CompuServe and America Online as concrete examples of
services, but the same concepts apply even to a single Web server or
BBS that wants to authenticate users. There are three aspects of this
environment of interest:
Identification--the way in which we refer to a user.
Authentication--the way in which a user may prove his or her
identity.
Authorization--the way in which we determine what a given user may
do.
The same aspects apply to services as well as users.
G Brown [Page 2]
INTERNET-DRAFT RPA - Part One 15 November 1996
1.1 Identification
A user's identity consists of a user name and a realm name. A realm
is a universe of identities; CompuServe Information Service user IDs
and America Online screen names are two examples of realms. The
combination of username and realm--typically shown as
name@realm--identifies a user. Any given service will recognize some
particular set of identities. A realm doesn't have to be large,
though, either in number of users or size of service. For example, a
single Web server might have its own realm of users.
Often, a service recognizes only one realm: CIS recognizes only
identities within the CIS realm, and AOL recognizes only identities
within the AOL realm. But one can imagine a service that has
agreements with both CIS and AOL. The service gives the user a choice
of realms--"Please supply a CIS or AOL identity, and prove it"--and
the user chooses a realm in which he has an identity.
1.2 Authentication
Identification provides the ability to identify, or refer to, a user.
Authentication provides the ability to prove identity. When you ask
to do something for which your identity matters, we ask for your
identity--your username and realm--and we make you prove that you are
who you say you are.
To accomplish this, we'll use a secret that we call a pass phrase,
although it's not necessarily derived from text. Such a secret is
sometimes called a secret key, but we won't be using it for
encryption.
The fundamental problem to be solved is, How can you prove to me that
you know your pass phrase without revealing the pass phrase in the
process? We'll explore this problem in more detail momentarily.
1.3 Authorization
Authorization refers to the process of determining whether a given
user is allowed to do something. For example, may he post a message?
May he use a surcharged service? We won't say much about this topic,
but it's important to realize that authentication and authorization
are distinct processes, one related to proving an identity, and the
other related to the properties of an identity.
Our mechanism has nothing to do with authorization, but it is
designed to co-exist with authorization mechanisms.
G Brown [Page 3]
INTERNET-DRAFT RPA - Part One 15 November 1996
2. The problem and how not to solve it
Imagine that I'm a service who wishes to authenticate you, a user.
You must identify yourself and prove to me that you know your pass
phrase. That's easy: I'll prompt you for your pass phrase.
But that doesn't work. We learned long ago that plaintext pass
phrases cannot be transmitted through a network. X.25 networks have
been compromised, and LANs, modem pools, and "The Internet" likewise
are not suitable for plaintext pass phrases. Prompting for the pass
phrase is not the answer.
2.1 Encrypt the pass phrase?
How about encrypting the pass phrase? Sounds good. You encrypt your
pass phrase, send me the result, and I'll decrypt it. Techniques like
Diffie-Hellman can create a one-time key that prevents an
eavesdropper from decrypting your pass phrase.
But that doesn't work, either. What if somebody else--a
spoofer--pretends to be the service? He'll decrypt the result,
learning your pass phrase and gaining the ability to masquerade as
you. Perhaps that sounds unlikely, but it's not; even in dial-up
modem days, people have spoofed services--"Here's a new telephone
number they left out of their directory. It's much faster than the
listed numbers!"
We need a mechanism that won't reveal your pass phrase to anyone,
even if you're not talking to whom you think you're talking.
2.2 A challenge-response mechanism?
How about a challenge-response mechanism? Now we're on the right
track. I send you a challenge, which is a random number, and you use
a one-way function to calculate a result that depends on the
challenge and your pass phrase. You send me the result, and I perform
the same calculation and see if my result matches yours. Done
correctly, this reveals no information to eavesdroppers, nor does it
allow a spoofer to acquire your pass phrase--if someone pretends to
be me, they learn only your result for a particular challenge, which
is of no value.
Although such a mechanism works, it doesn't quite solve our problem.
If I'm the service, I must know your pass phrase in order to
reproduce your calculation and verify your response to my challenge.
But what if I don't know your pass phrase?
G Brown [Page 4]
INTERNET-DRAFT RPA - Part One 15 November 1996
2.3 What if I don't know your pass phrase?
Why might I, the service, not know your pass phrase? Consider a set
of services that share a set of users' identities. For example,
imagine a collection of Web servers, scattered throughout the world,
all of which are a part of Gary's Information Service; you may use
your GIS name and pass phrase to identify yourself to any GIS
service.
The obvious implementation--each physical server has a copy of all
pass phrases or access to a master database--is awkward at best,
especially if some are third-party servers, not directly under the
control of our imaginary GIS.
Or consider a service that accepts identities in multiple realms.
Imagine a service that has agreements with both CIS and AOL. The
service gives the user a choice of realms--"Please supply a CIS or
AOL identity, and prove it"--and the user chooses a realm in which he
has an identity. It's unlikely that CIS and AOL will entrust a copy
of their pass phrase databases to a third-party service--or to each
other.
So, if I don't know your pass phrase, how can you prove to me that
you do know it? And that's the fundamental question addressed by this
mechanism. We'll begin by pointing out a couple of solutions that
don't work.
2.4 Two more ways not to solve the problem
Wrong answer #1--I'll prompt you for your pass phase. Let's make this
example more concrete: I'll display an HTML form with a box that asks
for your name and a box for your pass phrase. We'll use SSL or SHTTP
so an eavesdropper can't see it. When I get your reply, I can use a
challenge-response mechanism to verify your pass phrase with a server
that knows the pass phrases.
But that won't work. It's important to teach users not to type their
pass phrases just because somebody asks for it--that's a standard
technique for cracking others' accounts. Teaching users to provide
their pass phrases in an HTML form is a bad idea.
And I'll see your pass phrase, which is precisely what we want to
avoid, especially if I'm a spoofer.
Wrong answer #2--We'll create a pass-phrase database server. I'll ask
it for a copy of your pass phrase. Now that I know it, we can use an
ordinary challenge-response mechanism.
G Brown [Page 5]
INTERNET-DRAFT RPA - Part One 15 November 1996
That won't work. We'd need a way to get the pass phrase from that
database to me, safely. And if I can look up your pass phrase, what's
to stop somebody else from doing the same? (Don't say "a firewall."
Services that need to verify your identity exist outside firewalls,
too.)
If anything, this is even worse--I could dump the entire pass-phrase
database--and, again, I should never see your pass phrase.
But there is a solution, which we'll cover in Part two of this
specification (draft-petke-mech-00.txt).
3. Security Considerations
This entire document is about security.
4. Author's Address
Gary S. Brown
CompuServe Incorporated
5000 Britton Rd
P.O. Box 5000
Hilliard OH 43026-5000
USA
+1 614 723 1127
<gsb@csi.compuserve.com>
This Internet-Draft expires on May 15, 1997.
G Brown [Page 6]