idnits 2.17.1 draft-petke-mech-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. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT G Brown 2 draft-petke-mech-00.txt CompuServe 3 Expires: 15-May-97 15 November 1996 5 Remote Passphrase Authentication 6 Part Two: The Mechanism 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 two of a four part series and explains the 39 mechanism behind RPA. Part one of this series 40 (draft-petke-ext-intro-00.txt) provides an extended introduction to 41 the problems of authentication over insecure networks. Part three 42 (draft-petke-http-auth-scheme-00.txt) explains how to incorporate the 43 mechanism into HTTP. 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. TERMINOLOGY 56 3. DESIGN CRITERIA 58 4. THE MECHANISM 59 4.1 AUTHENTICATION 60 4.1.1 Values and their representation 61 4.1.2 The authentication process 62 4.2 REAUTHENTICATION 63 4.3 REAUTHENTICATION CHEATING 65 5. SECURITY CONSIDERATIONS 67 6. AUTHOR'S ADDRESS 69 1. Introduction 71 In this mechanism, we'll authenticate a user to a service and vice 72 versa. We'll use pass phrases--actually, they're 128-bit shared 73 secrets, but we'll define a way to use textual phrases--so the goal 74 is to prove to the service that you know your pass phrase, and vice 75 versa. 77 Of course, it's important not to reveal the pass phrase to an 78 eavesdropper. It is equally important not to reveal the pass phrase 79 to a spoofer. 81 Furthermore, the mechanism should work even if the service does not 82 know the user's pass phrase. In a distributed environment, with many 83 services that wish to authenticate the same set of users, it may be 84 difficult to make users' pass phrases available to all services. And 85 we might prefer not to do that, if we don't completely trust the 86 services. So, not only should the service not have to know the user's 87 pass phrase, but the service should not learn the user's pass phrase 88 during the authentication process. 90 On the other hand, the mechanism should be simple enough to apply 91 even in the traditional case where the service knows the user's pass 92 phrase; there's no need to use a different mechanism in that case. 94 Part one of this specification (draft-petke-ext-intro-00.txt) 95 contains an extended introduction that explains the problem and 96 various potential solutions and their problems, leading to this 97 mechanism. If you find yourself asking, "Why not just...," it might 98 be worth reading part one to see if that explains it. However, it 99 contains only background material, so you needn't read part one 100 before reading the rest of this specification. 102 2. Terminology 104 Throughout this specification we'll speak of a "user" communicating 105 with a "service" that wishes to learn and authenticate the user's 106 identity. Often, the user is a "client" and the service is a 107 "server," but those terms refer to an implementation. 109 The "deity" knows the users' and services' pass phrases, and the 110 service talks to the deity during the authentication process. 111 Although the term "authentication server" is more conventional, we 112 call it a deity because it's got fewer syllables and the term 113 "server" is overloaded. If the service knows the pass phrases, then 114 it acts as its own deity, simplifying the implementation but 115 otherwise having no effect on the mechanism. 117 Identities exist in some "realm," and we use that term in its usual 118 sense. We often think of a realm as being a relatively large 119 collection of users, like compuserve.com or aol.com, but it might 120 well consist of a small set of users, e.g., user names and pass 121 phrases associated with an individual Web server. We allow the 122 service to specify a set of realms, to recognize an identity in any 123 of the realms in which it participates. 125 3. Design criteria 127 This authentication mechanism is intended to meet the following 128 criteria. 130 * The service learns and authenticates the user's identity. 132 * The user learns and authenticates the service's identity. 134 * The mechanism does not use public-key technology. 136 * The mechanism does not use encryption. (By encryption, we're 137 referring to reversible encryption, the ability to encrypt 138 something and later decrypt it. By avoiding encryption, we avoid 139 restrictions on exportability.) 141 * The mechanism is based on shared secrets: "pass phrases," although 142 they can be arbitrary bit patterns rather than text. 144 * Neither the user nor the service needs to know the other's pass 145 phrase. 147 * Neither the user nor the service nor eavesdroppers will learn the 148 other's pass phrase. However, if the pass phrase is based on text, 149 it's important to choose a "good" pass phrase to avoid a dictionary 150 attack. 152 * The mechanism is reasonably easy to implement in clients and does 153 not require the client to communicate with a third party nor to a 154 possess a reliable clock. 156 * The mechanism derives a shared secret that may be used as a session 157 key for subsequent authentication. 159 * The mechanism may be incorporated into almost any protocol. In 160 other words, the mechanism is not designed around a protocol; the 161 protocol is designed around the mechanism. But the mechanism must 162 be suitable for incorporation into protocols like HTTP. 164 * The mechanism provides the ability to accept an identity in any of 165 a set of realms in which the user and service are members. 167 4. The Mechanism 169 This authentication mechanism consists of three related processes: 170 authentication, reauthentication, and reauthentication cheating. 172 Authentication is the fundamental process by which a user and a 173 service mutually authenticate one another within one of a set of 174 realms, without revealing their pass phrases to one another. 176 Reauthentication is a process by which a user and service, having 177 recently authenticated one another, may again authenticate one 178 another. They could, of course, simply repeat the authentication 179 process, but that requires interaction with an authentication deity. 180 The reauthentication process is faster, requiring no communication 181 with a third party. Reauthentication is useful when multiple 182 connections between the user and service are established, whether 183 sequential as in HTTP or simultaneous. Each connection must be 184 authenticated, but the reauthentication process provides a shortcut. 186 Reauthentication cheating is a further optimization for HTTP, a 187 protocol that is quite unfriendly to challenge-response mechanisms. 188 Reauthentication cheating can be performed in parallel with an HTTP 189 transaction. True reauthentication is just as simple, but requires 190 two sequential requests because of the characteristics of HTTP. By 191 using reauthentication cheating, we create a "one-way" handshake. 193 4.1 Authentication 195 There are three parties involved in the authentication process: 197 * the user; 199 * the service; and 201 * the authentication deity. 203 Each user has a name and a pass phrase in some realm of interest. 204 Similarly, each service has a name and a pass phrase in that realm. 205 The pass phrase isn't really text; it's a 128-bit (16-octet) string 206 of bits. 208 However, it's often useful to use pass phrases in the conventional, 209 textual sense, so we define a procedure for converting a textual 210 phrase to the 128-bit value used by the authentication mechanism. If 211 such a pass phrase is poorly chosen, it will be subject to dictionary 212 attack, and that's why we never use the word password in this 213 specification (well, except in this sentence)--use a phrase, not a 214 word. 216 The service may specify a list of realms, and the user chooses one in 217 which he has an identity. Thus, a service is not restricted to 218 authenticating identities in a single realm. The service must possess 219 a name and pass phrase in all realms it lists. 221 Each realm has an authentication deity, which knows the names and 222 pass phrases of its members. It's the service's responsibility to 223 know how to locate an authentication deity for each realm; the user 224 never communicates directly with an authentication deity. If the 225 service knows the user's pass phrase, it performs the role of the 226 authentication deity itself, but this does not affect the mechanism. 228 4.1.1 Values and their representation 230 Following is a glossary of the values involved in the authentication 231 process; we'll use these symbols in the following explanation. 233 As--Authentication deity's response to service; proves user's 234 identity 236 Au--Authentication deity's response to user; proves service's 237 identity 239 Cs--Challenge from service 241 Cu--Challenge from user 242 Kus--Session key for user and service 244 Kuss--Session key obscured so visible only to service 246 Kusu--Session key obscured so visible only to user 248 Nr--Realm name 250 Ns--Service name 252 Nu--User name 254 Ps--Service's pass phrase, a 128-bit value 256 Pu--User's pass phrase, a 128-bit value 258 Rs--Service's response to challenge (during authentication 259 process, goes to authentication deity; during 260 reauthentication, goes to user) 262 Ru--User's response to challenge (during authentication process, 263 goes via service to authentication deity; during 264 reauthentication, goes to service) 266 Ts--Service's time stamp 268 Z--Padding consisting of 48 octets (384 bits) with all bits set 269 to zero 271 +--Concatenation of octet strings 273 xor--Bitwise exclusive or 275 Bit patterns for each value must be specified. Imagine, for example, 276 that one implementation uses ASCII, another EBCDIC, and another 277 Unicode for the user name. Or one implementation converts the name to 278 lowercase, another to all caps. Each would generate a different 279 result for the same calculation, and authentication would fail. 281 Should we leave such details to the underlying protocol? We could, 282 but that would make the service-to-deity protocol dependent on the 283 user-to-service protocol, so we couldn't have a single deity for each 284 realm. If we specify the bit patterns, we can allow any mixture of 285 user-to-service and service-to-deity protocols to operate on the same 286 data. Therefore, we adopt the following conventions. 288 Text strings are represented in the Unicode character set, in 289 big-endian byte order, without a trailing null character. Note that 290 ASCII can be converted to ISO 8859-1 by prefixing a single 0 bit, and 291 ISO 8859-1 can be converted to Unicode by prefixing eight 0 bits. 293 Each 16-bit Unicode character is stored in two octets, with its 294 high-order 8 bits in the first octet. Representation of characters 295 with multiple encodings is for further study. For example, e-acute 296 has more than one representation. The form that uses combining 297 characters, in character-code order, is probably the most logical. 299 Note, by the way, that this specification refers only to values used 300 in the authentication calculations, not the underlying protocol. For 301 example, it's quite reasonable for a protocol to use ASCII for user 302 names, if that character set is adequate. Those ASCII characters must 303 be converted to Unicode before using them in authentication 304 calculations, but the protocol need not transmit Unicode characters. 306 * Names--Nr, Ns, Nu--are converted to lowercase Unicode. Note that 307 there is no trailing null character. 309 * Challenges--Cs, Cu--are arbitrary strings of octets, not text. They 310 may contain any bit patterns, including nulls, and must be at least 311 eight octets in length. 313 * The time stamp--Ts--is the ISO 646 (ASCII) textual representation 314 of the current universal time--UTC--in exactly 14 octets, using 315 24-hour time, with leading zeroes: 19950805011344. 317 * Pass phrases--Ps, Pu--are 16-octet quantities that contain 318 arbitrary bit patterns, including nulls. If the pass phrase is 319 based on a textual phrase, the textual phrase is converted to a 320 16-octet quantity by the following process. 322 * Convert the text string to a sequence of characters in either the 323 Unicode or ISO 8859-1 character sets, as appropriate for the 324 realm. 326 * Convert each character to its lowercase equivalent, or its 327 uppercase equivalent, or leave it alone, as appropriate for the 328 realm. 330 * Store the sequence of characters in an octet stream, with each 331 Unicode character in two consecutive octets in big-endian order, 332 or each ISO 8859-1 character in one octet. Do not append a 333 trailing null character. 335 * Take the MD5 digest of the resulting string of octets. The result 336 is the 128-bit value to use in the authentication calculations. 338 A realm will specify which of the preceding options--character set, 339 case conversion, and hash function--it uses for the text-to-128-bit 340 value transformation; the defaults are Unicode, convert to lowercase, 341 and MD5. More options might be added in the future. The user-service 342 protocol should be designed to convey the appropriate options for 343 each realm from the service to the user, if other than the defaults 344 are to be supported, to avoid requiring the (human) user to manually 345 configure software. 347 4.1.2 The authentication process 349 Here we describe the individual steps. Taken literally, one might 350 envision many messages between the service and deity, but an actual 351 implementation within a protocol combines steps. [Perhaps we should 352 add a "sample protocol" section showing a three-way handshake 353 version.] For example, "The user sends a random challenge" is shown 354 as a separate step for clarity, but it needn't be a separate message 355 to the service, nor must it be sent at the point shown--if it makes 356 sense in the underlying protocol, the user's challenge might be 357 included with the user's response to the service. 359 * The service supplies a sequence of realms, with the service's name 360 in each realm, to the user. For example, 362 foo@compuserve.com bar@aol.com 364 means "Please identify yourself with a CIS user ID. If you don't 365 have one, your AOL ID will do." The service indicates its realm 366 preferences in most-preferred to least-preferred order; by 367 specifying only one realm, the service requires identification in 368 that realm. 370 * The user chooses a realm, Nr, and gives it and his name in that 371 realm, Nu, to the service. That, in turn, determines Ns, the 372 service's name in that realm. Note that a protocol might allow the 373 service to include a null realm name, meaning "I'll accept you as 374 an anonymous user if you wish." The user might make this choice by 375 supplying a null name; the process stops here, and no 376 authentication is performed. 378 * The service transmits a random challenge, Cs, and a time stamp, Ts. 379 The challenges are random values that make each authentication 380 unique. The time stamp is, in effect, a third challenge, which the 381 deity will ensure is recent. The user may examine it, but most 382 users lack an accurate source of universal time, so most users will 383 treat it as an opaque value. 385 * The user sends a random challenge, Cu. 387 * The user calculates a response, Ru: 389 Ru = MD5(Pu + Z + Nu + Ns + Nr + Cu + Cs + Ts + Pu) 391 and sends it to the service. 393 Only the real user can generate the correct response, because it 394 depends on the user's pass phrase, Pu. No one can determine the 395 user's pass phrase from a captured response, because it's generated 396 by a one-way function, although there is the risk of a dictionary 397 attack if Pu is based on a poorly chosen pass phrase. 399 * The service calculates a response, Rs: 401 Rs = MD5(Ps + Z + Nu + Ns + Nr + Cu + Cs + Ts + Ru + Ps) 403 This response is not sent to the user; it would do no harm if the 404 user saw it, but the user won't need it. 406 * The service sends a request to the authentication deity for the 407 realm in question. The request contains 409 - The realm name, Nr (included so the same deity can serve more 410 than one realm) 412 - The user's name, Nu 414 - The service's name, Ns 416 - The user's challenge, Cu 418 - The service's challenge, Cs 420 - The time stamp, Ts 422 - The user's response, Ru 424 - The service's response, Rs 426 * The deity verifies the time stamp per previously agreed upon 427 criteria. In some applications, one might require it within a few 428 minutes; in others, one might want to allow 25 hours to eliminate 429 problems of misconfigured time zones. Beware of overzealousness, 430 though; this time stamp went from the service to the user, then 431 back to the service, then to the deity, perhaps with human 432 interaction--typing a pass phrase--introducing further delay. The 433 deity might implement a replay cache. 435 * The deity uses Nr, Ns, and Nu to look up the user's and service's 436 pass phrases. 438 * The deity uses the values in the request, plus the service's pass 439 phrase, Ps, to verify Rs. If it is incorrect, the deity returns a 440 negative response; this request apparently did not come from a 441 legitimate service. 443 * Having verified the requesting service's identity, the deity uses 444 the values in the request, plus the user's pass phrase, Pu, to 445 verify Ru. If it is incorrect, the deity returns a failure response 446 to the service; the user does not know the correct pass phrase. 448 [Think about the effects of replaying the authentication 449 request. I think the answer is that there's no problem 450 because it reveals no new information.] 452 * Having verified both the user's and service's identity, the deity 453 creates a random, 128-bit session key, Kus, for use by the user and 454 service. They might use it for session encryption; in addition, it 455 will be used in the reauthentication process described later. 457 * The deity generates two obscured copies of the session key: 459 - Kuss = Kus xor MD5(Ps + Z + Ns + Nu + Nr + Cs + Cu + Ts + Ps) 461 - Kusu = Kus xor MD5(Pu + Z + Ns + Nu + Nr + Cs + Cu + Ts + Pu) 463 The obscuring masks resemble Ru and Rs, but differ, of course, so 464 an eavesdropper cannot recover Kus. 466 * The deity generates a pair of authentication "proofs": 468 - Au = MD5(Pu + Z + Ns + Nu + Nr + Kusu + Cs + Cu + Ts + Kus + Pu) 470 - As = MD5(Ps + Z + Ns + Nu + Nr + Kuss + Cs + Cu + Ts + Kus + M + 471 Ps) 473 Here "M" is the message transmitted from the deity to the 474 service; it is included in the calculation to authenticate the 475 response to the service. Refer to part four of this 476 specification (draft-petke-serv-deity-protocol-00.txt) for more 477 details. 479 * The deity sends the four values Kuss, Kusu, As, and Au to the 480 service. 482 * The service extracts its copy of the session key from Kuss by 483 calculating the obscuring mask value and XORing. (The service can 484 determine the user's key-obscuring value by calculating Kus xor 485 Kusu; and if the user sees Kuss, it can do likewise. But the 486 obscuring masks reveal nothing.) 488 * The service verifies As by performing the same calculation and 489 comparing the result. If it matches, the service knows that someone 490 who knows its pass phrase--the deity--replied, having verified that 491 the user is who he claims to be. 493 * The service forwards Kusu and Au to the user. 495 * The user extracts its copy of the session key from Kusu by 496 calculating the mask value and XORing. 498 * The user verifies Au by computing it and comparing. If it matches, 499 the user knows that someone who knows his pass phrase--the 500 deity--replied, having verified that the service is who it claims 501 to be. Of course, if the service itself knows the user's pass 502 phrase, it can assert any service identity; but this is the case 503 where the service is trusted and acts as its own deity. 505 Now the user and service are confident of each others' identities, 506 and the two parties share a session key that they may use for 507 encryption, if they so choose. 509 [Perhaps we should add another value to the authentication 510 calculations, opaque to the mechanism, provided by the 511 protocol in which this mechanism is embedded. This value 512 would, of course, have to be added to the service-to-deity 513 protocol, and its generation and interpretation would be up 514 to the lower-level protocol. For example, HTTP might choose 515 to include the Web server's IP address and, perhaps, the 516 URL in the authentication calculations, making it harder to 517 do a man-in-the-middle attack. (Of course, that problem 518 cannot be completely solved without using the session key 519 to authenticate data, which is a protocol issue outside the 520 scope of this mechanism.)] 522 4.2 Reauthentication 524 Reauthentication is a process by which a user and service, having 525 recently authenticated each other, may again mutually authenticate 526 without talking to a deity. This is useful with protocols like HTTP, 527 which involve a sequence of connections that must be independently 528 authenticated. It's also useful with parallel connections--imagine a 529 scheme in which a user and service are connected, and wish to 530 establish a second connection. 532 To reauthenticate one another, the user and service prove to each 533 other that they both possess a secret 128-bit key--the session key, 534 Kus, derived during the authentication process. The reauthentication 535 process is essentially an ordinary challenge-response mechanism in 536 which the session key is used as a pass phrase. 538 * The service sends a challenge, Cs, to the user. 540 * The user sends a challenge, Cu, to the service. 542 * The user calculates 544 Ru = MD5(Kus + Z + Ns + Nu + Nr + Cs + Cu + Kus) 546 and sends it to the service. 548 * The service verifies the result. If correct, it calculates 550 Rs = MD5(Kus + Z + Nu + Ns + Nr + Cu + Cs + Kus) 552 and sends it to the user. Both responses involve the same set of 553 values, but they're used in a different order, so the responses are 554 different. 556 * The user verifies the result. 558 4.3 Reauthentication cheating 560 In HTTP, one can shortcut the reauthentication process by cheating, 561 for an increase in efficiency. 563 A naive approach allows the user to repeat its authentication data, 564 presumably in the form of an Authorization header. If the service 565 recognizes the same Authorization header, it presumes that it's 566 talking to the previously authenticated user; essentially, we pretend 567 that we reauthenticated with the same challenges. But this approach 568 is vulnerable to replay attacks during the period of time the service 569 considers the data valid. The service can check the user's IP address 570 to reduce the risk, but IP addresses mean surprisingly little. Even 571 neglecting address spoofing, multiple users share an IP address when 572 they're on the same host or routed through a proxy or SOCKS server. 574 There's a better solution. We begin by noting why it's 575 desirable--from an efficiency, not security, point of view--to allow 576 the Authorization header to be replayed. To embed a 577 challenge-response mechanism in HTTP, we require at least two HTTP 578 transactions for authentication, because we cannot send a challenge 579 and receive a response in one HTTP transaction. If we could challenge 580 the user without sending a challenge to the user, we could 581 authenticate in one HTTP transaction. And we can do exactly that by 582 treating the URI as a challenge. 584 * The first time, the user and service perform the authentication 585 process. 587 * The user and service remember the session key (Kus), challenges (Cu 588 and Cs), and timestamp (Ts). 590 * When the user generates an HTTP request, he includes an 591 Authorization header containing a response calculated as 593 MD5(Kus + Z + Ns + Nu + Nr + Cs + Cu + Ts + method + URI + Kus) 595 The method and URI are canonicalized by taking the big-endian Unicode 596 representation and converting all characters to lowercase; the URI 597 should not include the scheme://host:port. It always begins with a 598 slash; for "http://www.foo.com" the one-character string "/" would be 599 used. 601 Now the authentication response is unique for each URI, and 602 calculable only by the authenticated user, even without a unique 603 challenge. This doesn't completely eliminate the risk of replay, of 604 course, but an attacker can replay only a previously referenced URI 605 during the window in which the service considers the session key to 606 be valid. Is that acceptable? 608 Sometimes. If we're reading Web pages, and the only impact of replay 609 is that the attacker could re-read the page, it might be 610 acceptable--after all, the attacker saw the page, anyway, when he 611 captured it along with the original request. On the other hand, if 612 we're charging the user per page, or if the request "did" something, 613 replay might not be so harmless. 615 One strategy is to maintain some history. In its simplest form, the 616 service sets a flag for this session when it does something for which 617 replay would be harmful. If the user tries reauthentication cheating, 618 and the flag is set, the service forces reauthentication. Because the 619 cheating response is based on Cu and Cs, and those values change 620 during reauthentication, the correct response for a given URI changes 621 after reauthentication. Thus, reauthentication creates a boundary 622 after which previous requests cannot be replayed. 624 Or the service can maintain a history of URIs for which replay would 625 be harmful, and force reauthentication only if the user tries 626 reauthentication cheating on one of those URIs. 628 5. Security Considerations 630 This entire document is about security. 632 6. Author's Address 634 Gary S. Brown 635 CompuServe Incorporated 636 5000 Britton Rd 637 P.O. Box 5000 638 Hilliard OH 43026-5000 639 USA 641 +1 614 723 1127 642 644 This Internet-Draft expired on May 15, 1997.