idnits 2.17.1 draft-petke-http-auth-scheme-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-04-25) 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 10023 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. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT G Brown 3 draft-petke-http-auth-scheme-00.txt CompuServe 4 Expires: 15-May-97 15 November 1996 6 Remote Passphrase Authentication 7 Part Three: HTTP Authentication Scheme 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its 13 areas, and its working groups. Note that other groups may also 14 distribute working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet- 19 Drafts as reference material or to cite them other than as 20 "work in progress." 22 To learn the current status of any Internet-Draft, please check 23 the "1id-abstracts.txt" listing contained in the Internet- 24 Drafts Shadow Directories on ftp.is.co.za (Africa), 25 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), 26 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 28 Abstract 30 Remote Passphrase Authentication provides a way to authenticate a 31 user to a service by using a pass phrase over an insecure network, 32 without revealing the pass phrase to eavesdroppers. In addition, the 33 service need not know and does not learn the user's pass phrase, 34 making this scheme useful in distributed environments where it would 35 be difficult or inappropriate to trust a service with a pass phrase 36 database or to allow the server to learn enough to masquerade as the 37 user in a future authentication attempt. 39 This draft is part three of a four part series and explains how to 40 incorporate the RPA mechanism into HTTP. Part one of this series 41 (draft-petke-ext-intro-00.txt) provides an extended introduction to 42 the problems of authentication over insecure networks. Part two 43 (draft-petke-mech-00.txt) explains the RPA mechanism. Part four 44 (draft-petke-serv-deity-protocol-00.txt) explains the protocol 45 between the service and deity. 47 This scheme was inspired by Dave Raggett's Mediated Digest 48 Authentication paper. 50 Table of Contents 52 1. INTRODUCTION 54 2. USING THIS AUTHENTICATION MECHANISM IN HTTP 55 2.1 AUTHENTICATION 56 2.2 REAUTHENTICATION CHEATING 57 2.3 REAUTHENTICATION 59 3. SECURITY CONSIDERATIONS 61 4. AUTHOR'S ADDRESS 63 1. Introduction 65 See part two of this series (draft-petke-mech-00.txt) for an 66 explanation of the mechanism, its motivation, and its 67 specification. This part describes only the HTTP encapsulation of the 68 mechanism. 70 2. Using this authentication mechanism in HTTP 72 The HTTP client may indicate that it supports this authentication 73 mechanism by whatever technique is appropriate. 75 [For example, a header like "Extension: 76 Security/Remote-Passphrase" might be appropriate, if that 77 extension mechanism is adopted. The extension mechanism is, 78 of course, independent of authentication, but we mention it 79 here to point out the issue. Theoretically, the server does 80 not need to know ahead of time whether the client supports 81 a particular authentication scheme.] 83 We begin by defining a security context, which represents a logical 84 connection between a user and Web server. Because the context spans 85 HTTP connections, the server assigns a security context identifier, 86 an opaque string, when it creates a context, and it informs the 87 client of its value in the Security-Context attribute of the 88 WWW-Authenticate header. The client includes the identifier in the 89 Authorization header of subsequent requests that refer to the same 90 context. 92 From the client's point of view, the pair (server IP address, 93 security context identifier) uniquely identifies a context; the same 94 is essentially true for the server, although a server can make its 95 security context identifiers unique, rather than (client IP address, 96 identifier) pairs. 98 Note that a client might refer to the same security context from 99 different IP addresses, if he switches proxies (is that possible?). 100 Note also that the client IP address alone is not adequate to 101 identify the security context. A multiple-user host, an HTTP proxy, 102 and a SOCKS server are examples of situations in which the same IP 103 address may be involved in many security contexts. And even an 104 individual PC running two browsers falls into this category--if I 105 connect to you from both browsers, I'll establish two security 106 contexts, which might or might not refer to the same user identity. 108 The server should assign security context identifiers that are unique 109 over time. If the client refers to an old context identifier--the 110 user returns to his PC tomorrow morning and clicks a link that was 111 displayed yesterday--it will do no harm if that identifier had been 112 reused, but the server won't be able to recognize it as such. 114 The security context "contains" information appropriate to the 115 context, such as the realm name, user and service names, session key, 116 challenges, state, etc. We'll gloss over the details in this 117 explanation. Note that a session using this mechanism is secure; 118 unlike other "cookie"-type mechanisms, we do not depend on the 119 secrecy of the context identifier. However, the content of requests 120 and responses is not authenticated, in this version of the protocol. 122 We define the authentication scheme name "Remote-Passphrase", used as 123 described below. The client begins by making a request for which the 124 server requires identification and authentication; because there is 125 no Authorization header in the request, the server will demand 126 authentication. 128 All WWW-Authenticate and Authorization headers used with this scheme 129 may include a Version attribute. When omitted, as in the examples 130 below, Version="1" is implied, for this version of the protocol. 132 2.1 Authentication 134 The server creates a new security context, assigns it an identifier, 135 and responds 401 Unauthorized and includes the header 137 WWW-Authenticate: 138 Remote-Passphrase 139 Realm="compuserve.com", 140 State="Initial", 141 Realms="foo@compuserve.com 142 bar@aol.com:iso-8859-1,lc,md5", 143 Challenge="base64 encoding of service challenge", 144 Timestamp="19950808132430", 145 Security-Context="opaque" 147 The first token specifies the authentication scheme, 148 Remote-Passphrase. That's followed by a comma-separated list of 149 attribute-value pairs. HTTP requires the first attribute to be called 150 "Realm" and specify the realm in which the user must indicate his 151 identity, but we support multiple realms, so this is merely one realm 152 acceptable to the server, perhaps its preferred realm. 154 The State attribute distinguishes this as the initial request for 155 authentication. 157 The Realms attribute provides a list of realms in the order preferred 158 by the server, with the server's name in each realm. Each may be 159 followed by a colon and a list of parameters separated by commas, to 160 drive the transformation from pass phrase to 128-bit shared secret 161 for that particular realm. Refer to part two of this specification 162 (draft-petke-mech-00.txt) for more information about the 163 transformation. 165 The default transformation, if the colon and parameters are omitted, 166 is specified in part two of this specification 167 (draft-petke-mech-00.txt), the Unicode character set in 168 big-endian ("network") byte order, with all characters converted to 169 lowercase, and the MD5 hash algorithm. 171 Otherwise, a single parameter, "none", implies that the client must 172 already possess a 128-bit value, and no transformation from a textual 173 pass phrase is defined. 175 Otherwise, three parameters control the transformation from a textual 176 pass phrase to the 128-bit shared secret used by the authentication 177 mechanism, if such a transformation takes place (it might not, if the 178 client believes it already knows a 128-bit value for this user). The 179 three parameters specify the character set: Unicode 1.1 180 ("unicode-1-1") or ISO 8859-1 ("iso-8859-1"); case conversion: 181 convert to all caps ("uc"), all lowercase ("lc"), or as-is with no 182 case conversion ("nc"); and hash function: MD5 ("md5"). Omitting the 183 colon and parameters is equivalent to specifying 184 "unicode-1-1,lc,md5". 186 [There's no need for US-ASCII as a character set, because 187 ISO 8859-1 will give the same results. Note that these 188 parameters are part of the base authentication mechanism 189 specification; only the means of conveying them, and the 190 textual names shown above, are specific to this HTTP 191 authentication scheme. Other variations can be added, but 192 they must be added to the authentication mechanism defined 193 by part two of this specification 194 (draft-petke-mech-00.txt) as well as here in part three.] 196 We convey this information to the client because there's no reason 197 the client would otherwise know whether a particular realm's pass 198 phrases are case sensitive, etc. The server, on the other hand, 199 simply must "know" how its particular realm uses pass phrases; these 200 characteristics are a part of server's configuration along with its 201 name in the realm, deity addresses, etc. 203 The Challenge attribute specifies the service's challenge. It is an 204 arbitrarily long sequence of octets containing arbitrary bit 205 patterns, represented in base64. The client must decode it before 206 using it in the authentication calculations; it might contain nulls 207 or any other bit patterns. The client may decline to trust the server 208 and abort at this point, if it deems the challenge to be too short. 210 The Timestamp attribute specifies the server's timestamp. This is a 211 UTC date and time in the format specified by the authentication 212 standard. It may be treated as an opaque string by the client, unless 213 the client chooses to interpret it to make a judgment about its 214 reality; but beware that you probably don't have a reliable source of 215 universal time. 217 The Security-Context attribute contains the server-assigned security 218 context identifier, an opaque string. 220 The client creates its security context and repeats the request with 221 an Authorization header: 223 Authorization: 224 Remote-Passphrase 225 State="Initial", 226 Security-Context="opaque", 227 Realm="compuserve.com", 228 Username="70003.1215", 229 Challenge="base64 encoding of user challenge", 230 Response="base64 encoding of response" 232 The first token specifies the authorization scheme. That's followed 233 by the state, "Initial" for the initial authentication; the security 234 context identifier; the realm chosen by the user; the user's identity 235 in that realm; the user's challenge; and the user's response. 237 The service looks up the security context. If the security context 238 identifier refers to no context or refers to a context that is 239 already established, the server creates a new security context with a 240 new identifier, then responds 401 Unauthorized and includes a fresh 241 WWW-Authenticate header as shown above, with which the client can 242 repeat the request with correct authentication information. 244 [Or does this risk a loop? We could just respond with an 245 error.] 247 Any existing security context is unaffected; if I send you a request 248 that specifies someone else's security context, you should not delete 249 his context. 251 Otherwise--the context identifier is recognized and that context is 252 in the awaiting authentication state--the server performs the 253 authentication process. 255 The server may verify that the client's IP address matches that in 256 the previous request that created the "pending" context. The only 257 risk is that someone might change proxies at whim, which seems 258 unlikely. 260 If the authentication process fails, the server refuses to process 261 the request, but does not delete the "pending" security context. It 262 generates a 401 Unauthorized response with a WWW-Authenticate header 263 that indicates failure: 265 WWW-Authenticate: 266 Remote-Passphrase 267 Realm="nonsense", 268 State="Failed" 270 It is up to the client to try the request again (without an 271 Authorization header), restarting the entire process, if it believes 272 that it was using the wrong pass phrase but it now has the right pass 273 phrase. 275 [Sending another "Initial" WWW-Authenticate header would 276 provoke a loop: the browser would calculate a new response 277 and retry the request, which is pointless if the browser's 278 idea of the pass phrase is wrong, so we indicate the 279 failure.] 281 [One could argue that the browser should forget whichever 282 cached pass phrase it used, in order to prompt for it again 283 if the user tries to next time. But the pass phrase might 284 have been correct, depending on what exactly went wrong at 285 the server.] 287 Otherwise, having successfully authenticated the user, the server 288 processes the client's request and returns an appropriate response, 289 including in its reply: 291 WWW-Authenticate: 292 Remote-Passphrase 293 Realm="realm in use", 294 State="Authenticated", 295 Session-Key="base64 encoding of session key", 296 Response="base64 encoding of response" 298 The "Authenticated" state indicates that the user was successfully 299 authenticated, and includes the session key, masked so only the user 300 can extract it (Kusu), and the authentication deity's proof of the 301 service's identity (Au, not Rs). The realm is ignorable, but should 302 indicate the realm in which the identity was authenticated. 304 2.2 Reauthentication cheating 306 In subsequent requests, the client tries to cheat by including an 307 Authorization header in its request: 309 Authorization: 310 Remote-Passphrase 311 State="Cheating", 312 Security-Context="opaque", 313 Response="base64 encoding of response" 315 where the response is calculated based on the previously agreed-upon 316 values plus the canonicalized method and URI of this request as 317 explained in part two of this specification 318 (draft-petke-mech-00.txt). 320 [The HTTP specification suggests that clients be allowed to 321 replay the previous Authorization header, but it includes 322 an escape clause--"for a period of time determined by the 323 authentication scheme"--so we simply declare that period of 324 time to be zero.] 326 If the server is willing to accept the use of reauthentication 327 cheating, and the response is correct, the server processes the 328 request without comment. If it recognizes the security context but is 329 not willing to cheat--e.g., it recognizes a replay--the server 330 demands reauthentication. If it does not recognize the security 331 context or if it recognizes the context but the client's response is 332 incorrect, the server demands authentication but does not delete the 333 existing security context. 335 [Perhaps the user is referring to a security context that 336 has expired because it's been a long time since the user 337 last referred to it. And this can happen legitimately, if 338 the user refers to an expired security context and the 339 server reuses context identifiers. We do not delete an 340 existing context because that would provide a way for an 341 attacker to delete security contexts.] 343 In either of these cases, the server responds 401 Unauthorized and 344 includes the appropriate WWW-Authenticate header. To require 345 authentication, refer to the preceding section; to require 346 reauthentication, refer to the next section. 348 2.3 Reauthentication 350 If the server chooses to require reauthentication, it replies 401 351 Unauthorized and includes the header 353 WWW-Authenticate: 354 Remote-Passphrase 355 Realm="realm in use", 356 State="Reauthenticate", 357 Challenge="base64 encoding of service challenge" 359 The client retries the request with an Authorization field: 361 Authorization: 362 Remote-Passphrase 363 State="Reauthenticate", 364 Security-Context="opaque", 365 Challenge="base64 encoding of user challenge", 366 Response="base64 encoding of response" 368 If the response is correct--the user has proven his knowledge of the 369 previously generated Kus for this context--the server processes the 370 request and includes in its reply: 372 WWW-Authenticate: 373 Remote-Passphrase 374 Realm="realm in use", 375 State="Reauthenticated", 376 Response="base64 encoding of response" 378 The past-tense state indicates successful reauthentication, and 379 includes the server's response; this response is of debatable 380 relevance to HTTP, of course, given that the client's use of 381 reauthentication cheating implies its willingness to trust that the 382 server's identity has not changed. 384 If the client's response is incorrect, the server does not process 385 the request. However, there's a possibility that the client attempted 386 to do reauthentication with an old security context identifier that 387 has been reused by the server. Although the server should avoid 388 reusing security context identifiers, it can attempt to avert the 389 problem by forcing authentication by responding 401 Unauthorized and 390 including the header described above under Authentication. 392 3. Security Considerations 394 This entire document is about security. 396 4. Author's Address 398 Gary S. Brown 399 CompuServe Incorporated 400 5000 Britton Rd 401 P.O. Box 5000 402 Hilliard OH 43026-5000 403 USA 405 +1 614 723 1127 406