idnits 2.17.1 draft-petke-ext-intro-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-28) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (15 November 1996) is 9995 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 6 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT G Brown 2 draft-petke-ext-intro-00.txt CompuServe 3 Expires: 15-May-97 15 November 1996 5 Remote Passphrase Authentication 6 Part One: Extended Introduction 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its 12 areas, and its working groups. Note that other groups may also 13 distribute working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other 17 documents at any time. It is inappropriate to use Internet- 18 Drafts as reference material or to cite them other than as 19 "work in progress." 21 To learn the current status of any Internet-Draft, please check 22 the "1id-abstracts.txt" listing contained in the Internet- 23 Drafts Shadow Directories on ftp.is.co.za (Africa), 24 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), 25 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 27 Abstract 29 Remote Passphrase Authentication provides a way to authenticate a 30 user to a service by using a pass phrase over an insecure network, 31 without revealing the pass phrase to eavesdroppers. In addition, the 32 service need not know and does not learn the user's pass phrase, 33 making this scheme useful in distributed environments where it would 34 be difficult or inappropriate to trust a service with a pass phrase 35 database or to allow the server to learn enough to masquerade as the 36 user in a future authentication attempt. 38 This draft is part one of a four part series and contains an extended 39 introduction to the problem and potential solutions to the problem. 40 It is optional reading for those already familiar with the general 41 issues of authentication over insecure networks. Part two 42 (draft-petke-mech-00.txt) explains the RPA mechanism. Part three 43 (draft-petke-http-auth-scheme-00.txt) explains how to incorporate the 44 mechanism into HTTP. Part four 45 (draft-petke-serv-deity-protocol-00.txt) explains the protocol 46 between the service and deity. 48 This scheme was inspired by Dave Raggett's Mediated Digest 49 Authentication paper. 51 Table of Contents 53 1. INTRODUCTION 54 1.1 IDENTIFICATION 55 1.2 AUTHENTICATION 56 1.3 AUTHORIZATION 58 2. THE PROBLEM AND HOW NOT TO SOLVE IT 59 2.1 ENCRYPT THE PASS PHRASE? 60 2.2 A CHALLENGE-RESPONSE MECHANISM? 61 2.3 WHAT IF I DON'T KNOW YOUR PASS PHRASE? 62 2.4 TWO MORE WAYS NOT TO SOLVE THE PROBLEM 64 3. SECURITY CONSIDERATIONS 66 4. AUTHOR'S ADDRESS 68 1. Introduction 70 In this introduction we'll explain the problem--fundamentally, how to 71 authenticate a user to a service without revealing a pass phrase, and 72 without requiring the service to know the user's pass phrase--and 73 consider several alternatives and their flaws, leading to the reasons 74 for developing this authentication mechanism. If you're already 75 familiar with the concept of authentication and the surrounding 76 issues, you might prefer to skip to Part two of the specification, 77 (draft-petke-mech-00.txt), returning to this part only if you 78 want more information about the motivation for the mechanism. 80 We'll speak of an environment in which a user communicates with a 81 service that wishes to learn and authenticate the user's identity and 82 vice versa. You may, of course, think in terms of client and server, 83 but those terms generally refer to an implementation. We're speaking 84 at a higher level where there's no direct correspondence between 85 server and service nor user and client. 87 We'll use CompuServe and America Online as concrete examples of 88 services, but the same concepts apply even to a single Web server or 89 BBS that wants to authenticate users. There are three aspects of this 90 environment of interest: 92 Identification--the way in which we refer to a user. 94 Authentication--the way in which a user may prove his or her 95 identity. 97 Authorization--the way in which we determine what a given user may 98 do. 100 The same aspects apply to services as well as users. 102 1.1 Identification 104 A user's identity consists of a user name and a realm name. A realm 105 is a universe of identities; CompuServe Information Service user IDs 106 and America Online screen names are two examples of realms. The 107 combination of username and realm--typically shown as 108 name@realm--identifies a user. Any given service will recognize some 109 particular set of identities. A realm doesn't have to be large, 110 though, either in number of users or size of service. For example, a 111 single Web server might have its own realm of users. 113 Often, a service recognizes only one realm: CIS recognizes only 114 identities within the CIS realm, and AOL recognizes only identities 115 within the AOL realm. But one can imagine a service that has 116 agreements with both CIS and AOL. The service gives the user a choice 117 of realms--"Please supply a CIS or AOL identity, and prove it"--and 118 the user chooses a realm in which he has an identity. 120 1.2 Authentication 122 Identification provides the ability to identify, or refer to, a user. 123 Authentication provides the ability to prove identity. When you ask 124 to do something for which your identity matters, we ask for your 125 identity--your username and realm--and we make you prove that you are 126 who you say you are. 128 To accomplish this, we'll use a secret that we call a pass phrase, 129 although it's not necessarily derived from text. Such a secret is 130 sometimes called a secret key, but we won't be using it for 131 encryption. 133 The fundamental problem to be solved is, How can you prove to me that 134 you know your pass phrase without revealing the pass phrase in the 135 process? We'll explore this problem in more detail momentarily. 137 1.3 Authorization 139 Authorization refers to the process of determining whether a given 140 user is allowed to do something. For example, may he post a message? 141 May he use a surcharged service? We won't say much about this topic, 142 but it's important to realize that authentication and authorization 143 are distinct processes, one related to proving an identity, and the 144 other related to the properties of an identity. 146 Our mechanism has nothing to do with authorization, but it is 147 designed to co-exist with authorization mechanisms. 149 2. The problem and how not to solve it 151 Imagine that I'm a service who wishes to authenticate you, a user. 152 You must identify yourself and prove to me that you know your pass 153 phrase. That's easy: I'll prompt you for your pass phrase. 155 But that doesn't work. We learned long ago that plaintext pass 156 phrases cannot be transmitted through a network. X.25 networks have 157 been compromised, and LANs, modem pools, and "The Internet" likewise 158 are not suitable for plaintext pass phrases. Prompting for the pass 159 phrase is not the answer. 161 2.1 Encrypt the pass phrase? 163 How about encrypting the pass phrase? Sounds good. You encrypt your 164 pass phrase, send me the result, and I'll decrypt it. Techniques like 165 Diffie-Hellman can create a one-time key that prevents an 166 eavesdropper from decrypting your pass phrase. 168 But that doesn't work, either. What if somebody else--a 169 spoofer--pretends to be the service? He'll decrypt the result, 170 learning your pass phrase and gaining the ability to masquerade as 171 you. Perhaps that sounds unlikely, but it's not; even in dial-up 172 modem days, people have spoofed services--"Here's a new telephone 173 number they left out of their directory. It's much faster than the 174 listed numbers!" 176 We need a mechanism that won't reveal your pass phrase to anyone, 177 even if you're not talking to whom you think you're talking. 179 2.2 A challenge-response mechanism? 181 How about a challenge-response mechanism? Now we're on the right 182 track. I send you a challenge, which is a random number, and you use 183 a one-way function to calculate a result that depends on the 184 challenge and your pass phrase. You send me the result, and I perform 185 the same calculation and see if my result matches yours. Done 186 correctly, this reveals no information to eavesdroppers, nor does it 187 allow a spoofer to acquire your pass phrase--if someone pretends to 188 be me, they learn only your result for a particular challenge, which 189 is of no value. 191 Although such a mechanism works, it doesn't quite solve our problem. 192 If I'm the service, I must know your pass phrase in order to 193 reproduce your calculation and verify your response to my challenge. 194 But what if I don't know your pass phrase? 196 2.3 What if I don't know your pass phrase? 198 Why might I, the service, not know your pass phrase? Consider a set 199 of services that share a set of users' identities. For example, 200 imagine a collection of Web servers, scattered throughout the world, 201 all of which are a part of Gary's Information Service; you may use 202 your GIS name and pass phrase to identify yourself to any GIS 203 service. 205 The obvious implementation--each physical server has a copy of all 206 pass phrases or access to a master database--is awkward at best, 207 especially if some are third-party servers, not directly under the 208 control of our imaginary GIS. 210 Or consider a service that accepts identities in multiple realms. 211 Imagine a service that has agreements with both CIS and AOL. The 212 service gives the user a choice of realms--"Please supply a CIS or 213 AOL identity, and prove it"--and the user chooses a realm in which he 214 has an identity. It's unlikely that CIS and AOL will entrust a copy 215 of their pass phrase databases to a third-party service--or to each 216 other. 218 So, if I don't know your pass phrase, how can you prove to me that 219 you do know it? And that's the fundamental question addressed by this 220 mechanism. We'll begin by pointing out a couple of solutions that 221 don't work. 223 2.4 Two more ways not to solve the problem 225 Wrong answer #1--I'll prompt you for your pass phase. Let's make this 226 example more concrete: I'll display an HTML form with a box that asks 227 for your name and a box for your pass phrase. We'll use SSL or SHTTP 228 so an eavesdropper can't see it. When I get your reply, I can use a 229 challenge-response mechanism to verify your pass phrase with a server 230 that knows the pass phrases. 232 But that won't work. It's important to teach users not to type their 233 pass phrases just because somebody asks for it--that's a standard 234 technique for cracking others' accounts. Teaching users to provide 235 their pass phrases in an HTML form is a bad idea. 237 And I'll see your pass phrase, which is precisely what we want to 238 avoid, especially if I'm a spoofer. 240 Wrong answer #2--We'll create a pass-phrase database server. I'll ask 241 it for a copy of your pass phrase. Now that I know it, we can use an 242 ordinary challenge-response mechanism. 244 That won't work. We'd need a way to get the pass phrase from that 245 database to me, safely. And if I can look up your pass phrase, what's 246 to stop somebody else from doing the same? (Don't say "a firewall." 247 Services that need to verify your identity exist outside firewalls, 248 too.) 250 If anything, this is even worse--I could dump the entire pass-phrase 251 database--and, again, I should never see your pass phrase. 253 But there is a solution, which we'll cover in Part two of this 254 specification (draft-petke-mech-00.txt). 256 3. Security Considerations 258 This entire document is about security. 260 4. Author's Address 262 Gary S. Brown 263 CompuServe Incorporated 264 5000 Britton Rd 265 P.O. Box 5000 266 Hilliard OH 43026-5000 267 USA 268 +1 614 723 1127 269 271 This Internet-Draft expires on May 15, 1997.