idnits 2.17.00 (12 Aug 2021) /tmp/idnits45623/draft-perlman-strong-cred-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 418: '... recipient of this message MUST verify...' RFC 2119 keyword, line 420: '...sion" number. It MUST be zero for clie...' RFC 2119 keyword, line 421: '...the protocol. It MAY be non-zero for f...' RFC 2119 keyword, line 424: '... of the protocol MUST ignore the value...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 459 has weird spacing: '... Normal w/ H...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Jab97' is mentioned on line 97, but not defined == Missing Reference: 'Wu98' is mentioned on line 101, but not defined == Unused Reference: 'DH76' is defined on line 499, but no explicit reference was found in the text == Unused Reference: 'JAB97' is defined on line 506, but no explicit reference was found in the text == Unused Reference: 'KPS95' is defined on line 512, but no explicit reference was found in the text == Unused Reference: 'Pat97' is defined on line 516, but no explicit reference was found in the text == Unused Reference: 'WU98' is defined on line 523, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'BM92' -- Possible downref: Non-RFC (?) normative reference: ref. 'BM94' -- Possible downref: Non-RFC (?) normative reference: ref. 'DH76' -- Possible downref: Non-RFC (?) normative reference: ref. 'Jab96' -- Possible downref: Non-RFC (?) normative reference: ref. 'JAB97' -- Possible downref: Non-RFC (?) normative reference: ref. 'KPS95' -- Possible downref: Non-RFC (?) normative reference: ref. 'Pat97' -- Possible downref: Non-RFC (?) normative reference: ref. 'PK99' -- Possible downref: Non-RFC (?) normative reference: ref. 'WU98' Summary: 5 errors (**), 0 flaws (~~), 10 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Radia Perlman 2 INTERNET DRAFT Sun Microsystems 3 26 June 2000 Charlie Kaufman 4 Expires in six months Iris Associates 5 Eric Rescorla 6 RTFM, Inc. 8 Strong Password-Based Credentials Download Using Pseudorandom Moduli 9 draft-perlman-strong-cred-00.txt 11 Status of This Memo 13 This document is an individual contribution to the Internet 14 Engineering Task Force (IETF). Comments should be sent to the 15 authors Radia.Perlman@Sun.COM and CKaufman@Iris.COM. 17 Distribution of this memo is unlimited. 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. Internet-Drafts are working 21 documents of the Internet Engineering Task Force (IETF), its areas, 22 and its working groups. Note that other groups may also distribute 23 working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 In a strong password-based protocol, the only thing the client needs 39 to know is the user's password, and an eavesdropper, or someone 40 impersonating either end, cannot do off-line password-guessing 41 attacks. This sort of protocol can be used for credentials download, 42 or for mutual authentication. Although password-based mutual 43 authentication protocols can be used for credentials download, they 44 are designed with some properties (such as not storing a password- 45 equivalent at the server) that are not important in a credentials- 46 download protocol. Therefore, a protocol designed specifically for 47 credentials download can be fewer messages, higher performance at the 48 server, and allow the server to operate in a stateless manner. 49 Therefore it is possible, even likely, that different protocols might 50 be preferable in one case (credentials download) than another. This 51 document specifies a password-based protocol optimized for 52 downloading of a user's credentials, such as a private key. We claim 53 the desirable properties of such a protocol are that it be 54 unencumbered, high performance at the server, stateless at the 55 server, minimal number of messages, and acceptable performance at the 56 client. 58 Table of Contents 60 Status of This Memo . . . . . . . . . . . . . . . . . . . . . 1 62 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 64 Table of Contents . . . . . . . . . . . . . . . . . . . . . . 1 66 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 1 68 2 The Protocol . . . . . . . . . . . . . . . . . . . . . . . . 3 70 3 Generating p . . . . . . . . . . . . . . . . . . . . . . . . 4 72 4 Getting down to the bits . . . . . . . . . . . . . . . . . . 6 74 4.1 Computing p from username and password . . . . . . . . . . 6 76 4.2 Format of first message on the wire . . . . . . . . . . . 8 78 4.3 Format of second message on the wire . . . . . . . . . . . 8 80 5. Performance Note . . . . . . . . . . . . . . . . . . . . . 8 82 6. Security Considerations . . . . . . . . . . . . . . . . . . 8 84 References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 86 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . 10 88 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 10 90 1. Introduction 92 Protocols such as EKE [BM92], and SPEKE [Jab96] pioneered the notion 93 of using a weak secret such as a password to obfuscate a Diffie- 94 Hellman exchange, so that the exchange itself gives no information to 95 eavesdroppers, and at most a single on-line password guess to someone 96 impersonating either the client or the server. Later the protocols 97 were adapted [BM94], [Jab97] to incorporate the feature of not 98 storing a password-equivalent at the server, so that someone that 99 stole the server's database could not use the contents to directly 100 impersonate the user (though they could do a dictionary attack on the 101 contents to discover the user's password). SRP [Wu98] improved on 102 those protocols in performance. 104 However, for credentials download, there is no advantage of avoiding 105 a password-equivalent at the server because the purpose of the 106 protocol is to obtain the user's credentials, which are stored at the 107 server. So someone that steals the server's database already has the 108 credentials. Also in [PK99] tricks were provided for making 109 (nonextended) protocols such as EKE and SPEKE (but not the extended 110 versions) stateless at the server. A lot of the work of the mutual 111 authentication protocols such as extended EKE, extended SPEKE, and 112 SRP, are not relevant for credentials download, and they require 113 computation and state at the server that are not necessary for a 114 protocol used solely for credentials download. Therefore, the 115 preferred protocol for mutual authentication might be different from 116 the preferred protocol for credentials download. 118 Note that the credentials must be encrypted with a different hash of 119 the password than might be stored for use in EKE or SPEKE; otherwise 120 the user's credentials can be directly derived from the information 121 in the database. 123 Although a protocol based on (nonextended) EKE or SPEKE for 124 credentials download is technically acceptable, patent issues might 125 argue for a new approach, which we provide in this paper. 127 We claim the desirable properties of a credentials download protocol 128 are that it be unencumbered, secure against dictionary attacks by an 129 eavesdropper or someone impersonating either end, high performance at 130 the server, stateless at the server, minimal number of messages, and 131 acceptable performance at the client. 133 We claim the performance at the server is much more important than 134 performance at the client, because the server must simultaneously 135 serve many clients, perhaps many of whom are unauthorized and 136 contacting the server solely to require it to consume resources. We 137 claim the performance at the client is not as important because it is 138 serving only one user at a time, and the protocol is only executed 139 once (per user, per session). So the only thing that matters at the 140 client is whether performance is "good enough", whereas at the 141 server, any performance gain is important. 143 Our protocol has at least as good performance at the server as any of 144 the other schemes (and quite likely better, because the argument can 145 be made that our scheme allows for use of smaller p's). 147 In EKE g and p in the Diffie-Hellman exchange are fixed, and the 148 public number g**X mod p is encrypted with a function of the user's 149 password. In SPEKE, the base g is a function of the user's password. 151 In this paper we propose making the modulus p a function of the 152 user's password. 154 This protocol can be used to download a user's private key to a 155 workstation with appropriate software but no security information 156 configured for that user, from a public place such as a directory. 157 This can be thought of as bootstrapping the PKI. It is not possible 158 to protect the user's private key with conventional access control 159 since the user cannot authenticate until the user obtains the private 160 key. And the private key cannot be world-readable, even if encrypted 161 with the user's password, because the encrypted private key is 162 subject to off-line password-guessing. Once the user's private key is 163 recovered, any other information necessary to reconstruct the user's 164 environment on that workstation, such as the CAs that user trusts as 165 trust anchors for certificate chains, can also be retrieved from the 166 directory. Information that needs to be integrity protected is signed 167 with the user's private key. Information that needs to be secret 168 (other than the user's private key, which must be protected in a 169 different way) is encrypted with the user's public key. 171 The properties of this protocol are: 173 . a user need only know her name and password 175 . the protocol allows the server to operate in a stateless manner 177 . an eavesdropper on the authentication exchange between Alice and 178 Bob will gain no information from the exchange, no matter how 179 guessable Alice's password. 181 . Someone impersonating Bob or Alice will be able to verify only a 182 single password guess per interaction with the other side. 184 This protocol is not intended for devices such as PDAs which are 185 owned by a specific user and carried by that user. For those devices, 186 a high quality secret (such as the user's private key) would be 187 configured. This protocol is intended for workstations with 188 reasonable computational resources (say 400 MHz processors) that have 189 reasonable software, but no user-specific information configured. 191 2. The Protocol 193 The basic idea is to use the user's password as a seed for generating 194 a prime modulus, and always use 2 as the base. In order to provide 195 for salt, the seed for the pseudorandom number generator which will 196 select the prime modulus should be h("Alice", Alice's password). The 197 server Bob will store p for user Alice. Alice's workstation must 198 generate p based on Alice's name and her password when she logs in. 200 The protocol requires only 2 messages (request/response), so is 201 obviously stateless for the server. The client calculates p from the 202 user's password, chooses a random A, and sends 2**A mod p to the 203 server. The server chooses B, sends 2**B mod p to the client, and 204 sends back the credentials encrypted with 2**AB. 206 To save the server work, it loses no security to always use the same 207 B for the same user (but not for different users). If the server 208 stores, for Alice, B and 2**B mod p, then in this protocol there is 209 only a single exponentiation required at the server (to raise 2**A to 210 the power B). 212 So Bob stores, for Alice: 214 . name "Alice" 216 . p (Sophie Germain prime pseudorandomly generated from seed 217 h("Alice", password) 219 . Y=Alice's credentials encrypted with her password 221 . B 223 . 2**B mod p 225 The protocol is as follows: 227 1) User types name ("Alice") and password to the workstation. 229 2) Workstation computes h("Alice",password), and uses that to seed 230 a pseudorandom number generator to choose a Sophie Germain prime 231 p that has 2 as a generator. 233 3) Workstation chooses a random A to serve in the Diffie-Hellman 234 exchange. 236 4) Workstation sends "Alice", 2**A mod p to Bob. 238 5) Bob checks that Alice's name is exactly as stored in the 239 database, and if not, sends that version of Alice's name back. 240 If it is the same, Bob takes the B stored in the database, 241 calculates K=2**AB mod p by raising what he received from Alice 242 to the power B, and transmits 2**B mod p, and Y encrypted with K 243 to Alice. 245 6) Workstation calculates 2**AB mod p and uses it to decrypt Y. 247 3. Generating p 249 We want 2 to be a generator (with high probability). By the law of 250 quadratic reciprocity, this calls for p being 3 mod 8. So our 251 algorithm for generating p's will only test numbers that are 3 mod 8. 253 We estimate 10 seconds as a reasonable maximum amount of time for the 254 workstation to compute p. Diffie-Hellman moduli of 1000 bits are 255 considered safe. But on today's desktops, it would take too much time 256 (we estimate minutes) to generate a 1000-bit Sophie Germain prime. (A 257 "Sophie Germain prime" p is one in which (p-1)/2 is also prime.) 259 What corners can be cut to make performance tolerable at the client 260 machine? Suppose we used a smaller p, say 512 bits. It is estimated 261 that it would take 8000 MIP-years to break 512-bit Diffie-Hellman. An 262 eavesdropper on this exchange would have information sufficient to 263 test passwords, but it would require breaking 512-bit Diffie Hellman 264 for every guessed password. Another threat from using breakable 265 Diffie-Hellman is that if Bob's database were stolen, or someone 266 learned the user's password, then we would lose perfect forward 267 secrecy for the attacker's price of breaking 512-bit Diffie-Hellman. 268 If this were really considered a problem, then this entire exchange 269 could take place inside an anonymous Diffie-Hellman exchange with 270 fixed, large p. But for credentials download, (unlike mutual 271 authentication) perfect forward secrecy is not a concern. 273 Another way to make performance better for the client is not to use a 274 Sophie Germain prime, but instead use one where p-1 has at least one 275 large (160 bit) prime factor. Selection becomes more complicated 276 because determining whether 2 is a generator is probabilistic if the 277 factorization of p-1 is not known. This is probably a reasonable 278 approach; however, using a trick suggested by Jeff Schiller of having 279 the user optionally supply a hint, we think performance with Sophie 280 Germain primes can be tolerable, and the size of the Sophie Germain 281 prime generated can be increased as desktops get faster, and it is a 282 simpler solution. It is always best to start with a simple solution. 284 The way to look for a Sophie Germain prime is to start with a number 285 n, and then look for the smallest number p of the form 3 mod 8 larger 286 than n where both p and (p-1)/2 are (probably) prime. The most 287 efficient method is to first sieve to avoid numbers where either p or 288 (p-1)/2 have a small (say less than 10000) prime factor, and then 289 discard numbers unless both 2**(p-1)/2 mod p=p-1, and 2**(p-3)/2 mod 290 (p-1)/2=1. If p passes this test, there is an overwhelming 291 probability that p is a Sophie Germain prime and that 2 is a 292 generator. As a performance enhancement, we propose that for purposes 293 of interoperability that exactly those tests take place as opposed to 294 some less efficient test that determines primality with higher 295 certainty but which could introduce interoperability problems if not 296 all implementations used the same tests. 298 The user-supplied hint trick involves having the workstation give the 299 user a small value (say a single character, giving 6 bits of 300 information) that will speed up the search. For instance, it can 301 specify 6 of the bits of the p that will be chosen from the password. 302 If the user remembers the hint, then it saves computation time. If 303 the user does not furnish the hint, then authentication takes longer. 304 If the user furnishes the wrong hint, it is possible for 305 authentication to fail. 307 It is also important, in protocols of this sort, to avoid leaking 308 information that would enable an eavesdropper to eliminate passwords. 309 For instance, in the most straightforward implementation of EKE, one 310 might encrypt g**A mod p with a hash of the password. An eavesdropper 311 that observed an encrypted g**A mod p could do trial decryptions with 312 various passwords, and eliminate any passwords in which the result 313 was larger than p. 315 To avoid leaking information, we specify that candidate p's be chosen 316 from a very narrow range. So we fix the top 64 bits to be a constant. 317 For maximum performance given the size of the numbers, p should be 318 close to a power of 2. Therefore we recommend fixing the top 64 bits 319 to be 111...1. That means that the smallest possible p chosen would 320 be 64 bits of 1 followed by 0's, and the larger would be all 1's. We 321 recommend discarding A's and B's for which 2**A mod p or 2**B mod p 322 wind up larger than the maximum possible p that could be generated. 323 The probability of needing to discard an A is 1/2**64. 325 Another way in which information might be leaked is observing the 326 amount of time required to generate p. But an eavesdropper will have 327 no way of knowing how long it took to compute p, since the only thing 328 the eavesdropper sees is the client's request (which occurs after 329 computation of p). 331 Another way information could be leaked is if Alice chooses an A so 332 small that 2**A does not need to be reduced by p. In that case, she 333 has not committed to a password, and can do a dictionary attack based 334 on {Y}2**AB mod p (since she knows A), for any p. Using 2 as the 335 base has the nice property that Bob can recognize this form of 336 cheating, since 2**A mod p will have only a single "1" in the binary 337 representation. Bob must reject such values from Alice. 339 To support smooth migration to variations on this protocol in the 340 future, to allow some negotiation of parameter sizes, we specify a 341 minor version number and an alternate form of the second message in 342 which the server can specify alternate parameter sizes and/or a 343 "cookie". 345 4. Getting down to the bits 347 4.1 Computing p from username and password 349 If the password is at least three characters long, the next to last 350 character is ".", and the final character is from the set (0-9, a-z, 351 A-Z, +, =), then the final two characters of the password are left 352 out of the calculation of P below and the final character is 353 translated into an integer HINT between 0 and 63 depending on its 354 position in that set of legal characters. This will be used as a 355 performance enhancement (see below). 357 U = SHA1(Username) 359 P = SHA1(Password) 361 V = SHA1 ("Strong Password Authentication - Version 1.1 dated 362 16NOV2000") 364 Pseed = SHA1(U || P || V) 366 A = Randomly chosen 160 bit integer 368 Starting point for search for prime p is a 512 bit number with high 369 order bits 0-63 all 1's, and the remaining bits from SHA1(Pseed || 370 "1"), SHA1(Pseed || "2"), ... The chosen p will be the smallest 371 number greater than or equal to the starting point for which p = 3 372 mod 8, neither p nor (p-1)/2 has prime factors less than 10,000, and 373 for which 2**((p-1)/2 mod p = -1 and 2**((p-3)/2 mod ((p-1)/2) = 1. 374 The HINT is 6 bits of the chosen p. Since the bottom 3 bits must be 375 011 (to be 3 mod 8), the hint can be the representation of bits 376 503-508. (i.e., the low order bit of the penultimate byte and the 377 high order 5 bits of the last byte). 379 If the user does not supply a hint, the user is told that future 380 logins will run faster if the hint "x" is supplied in the future 381 (where x is replaced with the character corresponding to the 382 discovered HINT). The hint could be supplied with a separate user 383 prompt, or by appending to the password a character (such as space) 384 that would be otherwise be disallowed in the password, followed by x. 386 If there is a HINT, only candidate p's with bits 4-10 equal to the 387 hint are considered. The effect of this is that if the user provides 388 the HINT when entering the password, the computation of p will be 389 much faster but ultimately will produce the same result as the 390 calculation without the HINT. If the user specifies an incorrect 391 HINT, a different p will be calculated and it will probably take a 392 long time. The end result is that no passwords are disallowed (any 393 value entered will result in a 512 bit p), but users willing to 394 remember one more character of password will get in a lot faster. 396 Note that this is not equivalent to simply having a longer password, 397 since the hint is not user-supplied, and has no logical (from a human 398 point of view) connection with the rest of the password. 400 It would also be reasonable to allow multiple characters for the 401 hint, further speeding up processing at the client. In this case the 402 first character supplied by the user would equal bits 4-9, the next 403 10-15, etc. 405 Above, we specified that the user interface for entering the hint 406 would be that ".x" would be appended to the password. If "." is a 407 legal character in a password, and the user happened to specify a 408 password with "." as the penultimate character, then the final 409 character would be interpreted as a hint, and a prime would be found, 410 but it would be slow. 412 4.2 Format of first message on the wire: "Alice", 2**A mod p 414 The encapsulating protocol is assumed to provide the total length of 415 the message. Message is V || `\0' || 2**A mod p || Username, where V 416 has fixed length 160 bits, a single zero byte follows, 2**A mod p has 417 fixed length 512 bits, and username is variable length. 2**A mod p is 418 sent in "big endian" order. The recipient of this message MUST verify 419 that V is the expected value or terminate the protocol. The zero byte 420 is a "minor version" number. It MUST be zero for clients implementing 421 this version of the protocol. It MAY be non-zero for future clients, 422 indicating that those clients are willing to negotiate some variation 423 on this protocol. The recipient of this message implementing this 424 version of the protocol MUST ignore the value of that byte. Future 425 versions of the protocol may specify optional alternate responses if 426 the value is non-zero. 428 4.3 Format of second message on the wire: "Bob", 2**B mod p, and (Y) 429 encrypted with 2**AB 431 Bob parses the first message. He uses the user name to look up 432 account information for Alice, and checks to make sure the case, 433 accents, and punctuation of Alice's name as provided matches the 434 version in his account database. If not, or if the version is not 435 acceptable, or if 2**A mod p has only a single "1" bit in its binary 436 representation, or if Bob wants a stateless cookie before he does any 437 exponentiation, then Bob replies, with the cookie, corrected form of 438 Alice's name, required size of p (if the client sent the wrong size), 439 complaint about the format of 2**A mod p, etc. If the version, 440 Alice's name, and the prime size is acceptable, Bob then reads p, B, 441 2**B mod p, and Y from the database, raises the received 2**A mod p 442 to the power B, encrypts Y with 2**AB mod p to get ENCY, and sends V 443 || 2**B mod p || ENCY. 445 5. Performance Note 447 By far the most time consuming part of this protocol is the client's 448 generation of p from the username and password. The performance of 449 this operation is especially important because it must be performed 450 every time the client wishes to download his credentials. 452 Table 1 contains performance numbers for this operation. These 453 numbers are the mean of 20 trials with different passwords. The 454 passwords were chosen using words 20001-20020 in FreeBSD 3.4's 455 /usr/share/dict/words. The username was "Alice". All numbers are in 456 seconds. For reference, we have included numbers at a variety of key 457 sizes. 459 Key Size Normal w/ Hint 460 384 6.6 .13 (not recommended) 461 512 8.7 .15 462 768 34 .57 463 1024 * 120 2.0 464 Figure 1: Performance of prime generation 466 * Only 5 trials were run for 1024 bits due to needing to submit this 467 I-D. 469 These numbers were collected on a fairly unoptimized implementation 470 of the algorithm of Section 4.1 on a Pentium II/400 running FreeBSD 471 3.4. The bignum implementation was OpenSSL 0.9.6. 473 Note that although performance with a 1024 bit prime is quite bad, 474 with a hint it's quite acceptable. 476 6. Security Considerations 478 This protocol is intended to be a method of downloading credentials 479 which is somewhat less secure than having smart cards for each user. 480 It can bootstrap deployment of a PKI, allowing deployment before 481 users have smart cards. It is perfectly feasible for some users to 482 obtain credentials through this protocol and others to have smart 483 cards, and a user that subsequently obtains a smart card can simply 484 have their credentials information removed from the directory. This 485 protocol assumes trusted software at the client machine. 487 References 489 [BM92] S. Bellovin and M. Merritt, "Encrypted Key Exchange: 490 Password-based protocols secure against dictionary attacks", 491 Proceedings of the IEEE Symposium on Research in Security and 492 Privacy, May 1992. 494 [BM94] S. Bellovin and M. Merritt, "Augmented Encrypted Key 495 Exchange: a Password-Based Protocol Secure Against Dictionary 496 Attacks and Password File Compromise, ATT Labs Technical 497 Report, 1994. 499 [DH76] W. Diffie and M. Hellman, "New Directions in Cryptography", 500 IEEE Transactions on Information Theory, November 1976. 502 [Jab96] D. Jablon, "Strong Password-Only Authenticated Key Exchange", 503 Computer Communication Review, ACM SIGCOMM, vol. 26, no. 5, 504 pp. 5-26, October 1996. 506 [JAB97] D. Jablon, ""Extended Password Key Exchange Protocols Immune 507 to Dictionary Attacks", Proceedings of the Sixth Workshops on 508 Enabling Technologies: Infrastructure for Collaborative 509 Enterprises (WET-ICE '97), IEEE Computer Society, June 18-20, 510 1997, Cambridge, MA, pp. 248-255. 512 [KPS95] C. Kaufman, R. Perlman, and M. Speciner, "Network Security: 513 Private Communication in a Public World", Prentice Hall, 514 1995. 516 [Pat97] S. Patel, "Number Theoretic Attacks On Secure Password 517 Schemes", Proceedings of the IEEE Symposium on Security and 518 Privacy, May 1997. 520 [PK99] R. Perlman and C. Kaufman, "Secure Password-Based Protoocol 521 for Downloading a Private Key", ISOC NDSS Symposium, 1999. 523 [WU98] T. WU, "The Secure Remote Password Protocol", ISOC NDSS 524 Symposium, 1998. 526 Author's Address 528 Radia Perlman 529 Sun Microsystems 531 Phone: 532 Email: radia.perlman@sun.com 534 Charlie Kaufman 535 Iris Associates 537 Phone: 538 Email: ckaufman@iris.com 540 Eric Rescorla 541 RTFM, Inc. 543 Phone: 544 Email: ekr@rtfm.com 546 Full Copyright Statement 548 Copyright (C) The Internet Society (1999). All Rights Reserved. 550 This document and translations of it may be copied and furnished to 551 others, and derivative works that comment on or otherwise explain it 552 or assist in its implementation may be prepared, copied, published 553 and distributed, in whole or in part, without restriction of any 554 kind, provided that the above copyright notice and this paragraph 555 are included on all such copies and derivative works. However, 556 this document itself may not be modified in any way, such as by 557 removing the copyright notice or references to the Internet Society 558 or other Internet organizations, except as needed for the purpose 559 of developing Internet standards in which case the procedures 560 for copyrights defined in the Internet Standards process must be 561 followed, or as required to translate it into languages other than 562 English. 564 The limited permissions granted above are perpetual and will not be 565 revoked by the Internet Society or its successors or assigns. 567 This document and the information contained herein is provided on an 568 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 569 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 570 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 571 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRAN