idnits 2.17.1 draft-burdis-cat-srp-sasl-03.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: ---------------------------------------------------------------------------- == 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 Introduction section. ** 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. ** There are 19 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (September 12, 2000) is 8620 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) -- Looks like a reference, but probably isn't: 'SRP' on line 524 == Unused Reference: '7' is defined on line 590, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 593, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '5') ** Obsolete normative reference: RFC 2554 (ref. '6') (Obsoleted by RFC 4954) ** Obsolete normative reference: RFC 2222 (ref. '7') (Obsoleted by RFC 4422, RFC 4752) ** Obsolete normative reference: RFC 2629 (ref. '8') (Obsoleted by RFC 7749) -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K.R. Burdis 3 Internet-Draft Rhodes University 4 Expires: March 13, 2001 September 12, 2000 6 Secure Remote Password SASL Mechanism 7 draft-burdis-cat-srp-sasl-03 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on March 13, 2001. 32 Copyright Notice 34 Copyright (C) The Internet Society (2000). All Rights Reserved. 36 Abstract 38 This document describes an SASL mechanism based on the Secure Remote 39 Password protocol. The mechanism includes mutual authentication and 40 can provide a security layer with replay detection, integrity 41 protection and/or confidentiality protection. 43 Table of Contents 45 1. Conventions Used in this Document . . . . . . . . . . . . . 3 46 2. Netstrings . . . . . . . . . . . . . . . . . . . . . . . . . 4 47 3. Protocol Description . . . . . . . . . . . . . . . . . . . . 5 48 3.1 Server sends N, g and L . . . . . . . . . . . . . . . . . . 6 49 3.2 Client sends request . . . . . . . . . . . . . . . . . . . . 9 50 3.3 Server sends response . . . . . . . . . . . . . . . . . . . 10 51 3.4 Client sends evidence . . . . . . . . . . . . . . . . . . . 10 52 3.5 Server sends evidence . . . . . . . . . . . . . . . . . . . 10 53 4. Security Layer . . . . . . . . . . . . . . . . . . . . . . . 11 54 4.1 Integrity Protection . . . . . . . . . . . . . . . . . . . . 11 55 4.1.1 Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 11 56 4.1.2 Decoding . . . . . . . . . . . . . . . . . . . . . . . . . . 12 57 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 13 58 6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 14 59 7. Security Considerations . . . . . . . . . . . . . . . . . . 15 60 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 61 References . . . . . . . . . . . . . . . . . . . . . . . . . 17 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . 17 63 A. Modulus and Generator values . . . . . . . . . . . . . . . . 19 64 Full Copyright Statement . . . . . . . . . . . . . . . . . . 21 66 1. Conventions Used in this Document 68 In this document, a string of 8-bit bytes may be written in two 69 different forms: as a series of hexadecimal numbers between angle 70 brackets, or as a sequence of ASCII characters between double 71 quotes. For example, <68 65 6c 6c 6f 20 77 6f 72 6c 64 21> is a 72 string of length 12; it is the same as the string "hello world!" 73 [1]. All data is encoded and sent in network byte order 74 (big-endian). 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 78 this document are to be interpreted as described in RFC 2119[2]. 80 2. Netstrings 82 This mechanism makes extensive use of netstrings, which are 83 described in more detail in [1]: 85 A netstring is a self-delimiting encoding of a string. Netstrings 86 are very easy to generate and to parse. Any string may be encoded 87 as a netstring; there are no restrictions on length or on allowed 88 bytes. Another virtue of a netstring is that it declares the 89 string size up front. Thus an application can check in advance 90 whether it has enough space to store the entire string. 92 Any string of 8-bit bytes may be encoded as {len}":"{string}",". 93 Here {string} is the string and {len} is a nonempty sequence of 94 ASCII digits giving the length of {string} in decimal. The ASCII 95 digits are <30> for 0, <31> for 1, and so on up through <39> for 96 9. Extra zeros at the front of {len} are prohibited: {len} begins 97 with <30> exactly when {string} is empty. 99 For example, the string "hello world!" is encoded as <31 32 3a 68 100 65 6c 6c 6f 20 77 6f 72 6c 64 21 2c>, i.e., "12:hello world!,". 101 The empty string is encoded as "0:,". 103 {len}":"{string}"," is called a netstring. {string} is called the 104 interpretation of the netstring. 106 Note that {string} may itself be a netstring. 108 3. Protocol Description 110 The SASL mechanism name associated with this protocol is "SRP". 112 SRP is a password-based zero-knowledge authentication and 113 key-exchange protocol developed by Thomas Wu. It has good 114 performance, is not plaintext-equivalent and maintains perfect 115 forward secrecy. It provides authentication (optionally mutual 116 authentication) and the negotiation of a session key [11]. 118 This mechanism is based on the optimised SRP-SHA1 protocol described 119 at the end of section 3 in [10], since this reduces the total number 120 of messages exchanged by grouping together pieces of information 121 that do not depend on earlier messages. Due to the design of the 122 mechanism, mutual authentication is MANDATORY. 124 This document describes how the SRP-SHA1 data is encoded for 125 transmission between the client and server, and it adds extra 126 control information to enable the client to request whether or not 127 replay detection, integrity protection and/or confidentiality 128 protection should be provided by a security layer. 130 Mechanism data exchanges are shown below: 132 Client Server 134 <-- N,g,L -- 136 -- U,I,A,o --> 138 <-- s,B -- 140 -- M1 --> 142 M1 = H(H(N) XOR H(g) | H(U) | s | H(L) | A | B | K) 144 <-- M2 -- 146 M2 = H(A | H(U) | H(I) | H(o) | M1 | K) 148 where: 150 | is the concatenation operator 152 H is the SHA-1 one-way function 154 N is the prime modulus 155 g is the generator 157 L is the options list indicating available security services 159 U is the client's username (authentication identity) 161 I is the client's authorisation identity 163 A is the client's ephemeral public key 165 o is the options list indicating requested security services 167 s is the client's password salt 169 B is the server's ephemeral public key 171 M1 is the client's evidence that the shared key is known 173 M2 is the server's evidence that the shared key is known 175 3.1 Server sends N, g and L 177 The prime modulus (N) is encoded as a netstring (ns1). The generator 178 (g) is encoded as a netstring (ns2). 180 The server creates an options list (L), which consists of a 181 comma-separated list of option strings that specify the security 182 service options the server supports. The following option strings 183 are defined: 185 o "integrity=HMAC-MD5" indicates that the server supports integrity 186 protection using the HMAC-MD5 algorithm [5]. This option string 187 MUST always be sent, since support for this algorithm is 188 MANDATORY. 190 o "replay detection" indicates that the server supports replay 191 detection using sequence numbers. 193 o "confidentiality=BLOWFISH-CBC" indicates that the server supports 194 confidentiality protection using the Blowfish cipher in CBC mode 195 [9]. If the server supports confidentiality protection, it MUST 196 send this option string, since it is then MANDATORY for it to 197 provide support for this algorithm. 199 Other option strings MAY be sent. The options list SHOULD NOT be 200 interpreted in a case-sensitive manner. 202 For example, if the server supports integrity protection, replay 203 detection and no confidentiality protection, the options list would 204 be: 206 integrity=HMAC-MD5,replay detection 208 This options list (L) is encoded as a netstring (ns3). 210 These three netstrings (ns1, ns2 and ns3) are concatenated and this 211 string is encoded as a netstring (ns4). The resulting string (ns4) 212 is sent to the client. 214 For example if: 216 N = 225 and: 227 g = <02> 229 and: 231 L = "integrity=hmac-md5,replay detection, 232 confidentiality=blowfish-cbc" 234 or 236 L = <69 6E 74 65 67 72 69 74 79 3D 68 6D 61 63 2D 6D 237 64 35 2C 72 65 70 6C 61 79 20 64 65 74 65 63 74 238 69 6F 6E 2C 63 6F 6E 66 69 64 65 6E 74 69 61 6C 239 69 74 79 3D 62 6C 6F 77 66 69 73 68 2D 63 62 63> 241 N encoded as a netstring is: 243 <31 32 38 3A EE AF 0A B9 AD B3 8D D6 9C 33 F8 0A FA 8F 244 C5 E8 60 72 61 87 75 FF 3C 0B 9E A2 31 4C 9C 25 65 76 245 D6 74 DF 74 96 EA 81 D3 38 3B 48 13 D6 92 C6 E0 E0 D5 246 D8 E2 50 B9 8B E4 8E 49 5C 1D 60 89 DA D1 5D C7 D7 B4 247 61 54 D6 B6 CE 8E F4 AD 69 B1 5D 49 82 55 9B 29 7B CF 248 18 85 C5 29 F5 66 66 0E 57 EC 68 ED BC 3C 05 72 6C C0 249 2F D4 CB F4 97 6E AA 9A FD 51 38 FE 83 76 43 5B 9F C6 250 1D 2F C0 EB 06 E3 2C> 252 g encoded as a netstring is: 254 "1:" <02> "," 256 or 258 <31 3A 02 2C> 260 L encoded as a netstring is: 262 "64:integrity=hmac-md5,replay detection, 263 confidentiality=blowfish-cbc," 265 or 267 <36 34 3A 69 6E 74 65 67 72 69 74 79 3D 68 6D 61 63 2D 268 6D 64 35 2C 72 65 70 6C 61 79 20 64 65 74 65 63 74 69 269 6F 6E 2C 63 6F 6E 66 69 64 65 6E 74 69 61 6C 69 74 79 270 3D 62 6C 6F 77 66 69 73 68 2D 63 62 63 2C> 272 The final string is: 274 "205:128:" ",1:" <2> ",64:" <69 6E 74 65 67 282 72 69 74 79 3D 68 6D 61 63 2D 6D 64 35 2C 72 65 70 6C 283 61 79 20 64 65 74 65 63 74 69 6F 6E 2C 63 6F 6E 66 69 284 64 65 6E 74 69 61 6C 69 74 79 3D 62 6C 6F 77 66 69 73 285 68 2D 63 62 63> ",," 287 or 289 <32 30 35 3A 31 32 38 3A EE AF 0A B9 AD B3 8D D6 9C 33 290 F8 0A FA 8F C5 E8 60 72 61 87 75 FF 3C 0B 9E A2 31 4C 291 9C 25 65 76 D6 74 DF 74 96 EA 81 D3 38 3B 48 13 D6 92 292 C6 E0 E0 D5 D8 E2 50 B9 8B E4 8E 49 5C 1D 60 89 DA D1 293 5D C7 D7 B4 61 54 D6 B6 CE 8E F4 AD 69 B1 5D 49 82 55 294 9B 29 7B CF 18 85 C5 29 F5 66 66 0E 57 EC 68 ED BC 3C 295 05 72 6C C0 2F D4 CB F4 97 6E AA 9A FD 51 38 FE 83 76 296 43 5B 9F C6 1D 2F C0 EB 06 E3 2C 31 3A 02 2C 36 34 3A 297 69 6E 74 65 67 72 69 74 79 3D 68 6D 61 63 2D 6D 64 35 298 2C 72 65 70 6C 61 79 20 64 65 74 65 63 74 69 6F 6E 2C 299 63 6F 6E 66 69 64 65 6E 74 69 61 6C 69 74 79 3D 62 6C 300 6F 77 66 69 73 68 2D 63 62 63 2C 2C> 302 3.2 Client sends request 304 The client's username (U) is encoded as a netstring (ns1). The 305 client's authorisation identity (I) is encoded as a netstring (ns2). 306 The client generates its ephemeral public key (A) and this is 307 encoded as a netstring (ns3). 309 The client creates a comma-separated options list (o) that specifies 310 the security service options that it requests. (The client can only 311 select security services that the server has indicated it can 312 provide). The defined options are: 314 o "integrity=HMAC-MD5": the client requests integrity protection 315 using the HMAC-MD5 algorithm [5]. 317 o "replay detection": the client requests replay detection using 318 sequence numbers. (Note that an integrity protection algorithm 319 MUST be specified if this option is chosen). 321 o "confidentiality=BLOWFISH-CBC": the client requests 322 confidentiality protection using the Blowfish cipher in CBC mode 323 [9]. 325 Other options MAY be available. 327 This options list (o) is encoded as a netstring (ns4). 329 These four netstrings (ns1, ns2, ns3 and ns4) are concatenated and 330 this string is encoded as a netstring (ns5). The resulting string 331 (ns5) is sent to the server. 333 3.3 Server sends response 335 The server calculates the shared context key (K). 337 The client's salt (s) is encoded as a netstring (ns1). The server 338 generates its ephemeral public key (B) and this is encoded as a 339 netstring (ns2). 341 These two netstrings (ns1 and ns2) are concatenated and this string 342 is encoded as a netstring (ns3). The resulting string (ns3) is sent 343 to the server. 345 3.4 Client sends evidence 347 The client calculates the shared context key (K). 349 The client calculates the evidence (M1) that proves to the server 350 that it knows the shared context key (K), including L as part of the 351 calculation. 353 M1 = H(H(N) XOR H(g) | H(U) | s | H(L) | A | B | K) 355 This evidence (M1) is encoded as a netstring (ns1) and sent to the 356 server. 358 3.5 Server sends evidence 360 The server calculates the evidence (M2) that proves to the client 361 that it knows the shared context key (K), including U, I, and o as 362 part of the calculation. 364 M2 = H(A | H(U) | H(I) | H(o) | M1 | K) 366 This evidence (M2) is encoded as a netstring (ns1) and sent to the 367 client. 369 4. Security Layer 371 Depending on the options specified by the initiator, the security 372 layer may provide integrity protection, replay detection, and/or 373 confidentiality protection. Messages are encoded as follows: 375 o If neither integrity nor confidentiality protection is requested 376 then the message is sent unchanged to the other party. 378 o If just confidentiality protection is requested then the message 379 data is encrypted using the chosen confidentiality algorithm (eg. 380 Blowfish). The encrypted message is encoded as a netstring and 381 sent to the other party. 383 o If just integrity protection is requested then the integrity 384 checksum is calculated on the message data as described in 385 Section 4.1. 387 o If both integrity protection and confidentiality protection are 388 requested then the message data is first encrypted using the 389 chosen confidentiality algorithm (eg. Blowfish). Thereafter the 390 integrity checksum is calculated on the encrypted message data as 391 described in Section 4.1. 393 o If replay detection is requested then the sequence number 394 included in the integrity checksum is incremented after each 395 message is sent, starting at zero, otherwise the sequence number 396 is always zero. 398 4.1 Integrity Protection 400 Integrity protection is provided using the chosen integrity 401 protection algorithm (usually the HMAC-MD5 [5] algorithm), with the 402 shared context key (K) used as the input key. The encoding and 403 decoding of message data is described below. 405 4.1.1 Encoding 407 The (possibly encrypted) message data is encoded as a netstring 408 (ns1). The (incremented) sequence number is encoded as a netstring 409 (ns2). These two netstrings (ns1 and ns2) are concatenated and 410 encoded as a netstring (ns3). A MAC is computed using the chosen 411 integrity protection algorithm, the shared context key and ns3. The 412 MAC is then encoded as a netstring (ns4). 414 ns3 and ns4 are concatenated and this string is encoded as a 415 netstring (ns5). ns5 is sent to the other party. 417 4.1.2 Decoding 419 The received data is interpreted as a netstring. This string is the 420 concatenation of two netstrings (ns3 and ns4). ns3 contains the 421 concatenation of the (possibly encrypted) message data netstring 422 (ns1) and the sequence number netstring (ns2). The interpretation of 423 ns4 is the received message authentication code (MAC). 425 The receiver computes a message authentication code using the chosen 426 integrity protection algorithm (eg. HMAC-MD5), the shared context 427 key and ns3. This computed MAC is compared with the received MAC. If 428 the MACs do not match then that indicates that the message has been 429 tampered with and the message SHOULD be rejected. 431 If replay detection was requested then the receiver interprets ns2, 432 checks that the sequence number is what it expects it to be, and 433 rejects the message if it is not. 435 The interpretation of ns3 is the (possibly encrypted) original 436 message. If the message is encrypted it should be decrypted using 437 the chosen confidentiality algorithm (eg. Blowfish) and the session 438 key (K). 440 5. Example 442 The example below uses SMTP authentication [6]. The base64 encoding 443 of challenges and responses, as well as the reply codes preceding 444 the responses are part of the SMTP authentication[6] specification, 445 not part of this SASL mechanism itself. 447 "C:" and "S:" indicate lines sent by the client and server 448 respectively. 450 S: 220 smtp.example.com ESMTP server ready 452 C: EHLO krb.example.com 454 S: 250-smtp.example.com 455 S: 250 AUTH SRP CRAM-MD5 DIGEST-MD5 457 C: AUTH SRP 459 S: 334 MjA1OjEyODrurwq5rbON1pwz+Ar6j8XoYHJhh3X/PAueojFMnCVldtZ033S 460 W6oHTODtIE9aSxuDg1djiULmL5I5JXB1gidrRXcfXtGFU1rbOjvStabFdSYJVmyl7z 461 xiFxSn1ZmYOV+xo7bw8BXJswC/Uy/SXbqqa/VE4/oN2Q1ufxh0vwOsG4ywxOgIsNjQ 462 6aW50ZWdyaXR5PWhtYWMtbWQ1LHJlcGxheSBkZXRlY3Rpb24sY29uZmlkZW50aWFsa 463 XR5PWJsb3dmaXNoLWNiYyws 465 C: MjE3OjU6a2VpdGgsNTprZWl0aCwxMjg6iNsL3XSGLjrCf/ecuOzQP0FyYI0WPJ6 466 DFwlUKrnnsVTAo0mEWz03KcS4Q78BqTIQGpFny7W0KqP8WRX119ey5mcu4yh7M2qoS 467 E51g/4baqVuCvPtrrodPExHIM1I+nIU/XlFMNjrC3WSuO/2P/jOQrHvflnOqoNltl0 468 tpTW1F6IsNjQ6aW50ZWdyaXR5PWhtYWMtbWQ1LHJlcGxheSBkZXRlY3Rpb24sY29uZ 469 mlkZW50aWFsaXR5PWJsb3dmaXNoLWNiYyws 471 S: MTQ3OjEwOhUpUDmvEIlfBRAsMTI4OsSBV0SYkU6GiUISs1IIJgMbMJNMnSI+XSC 472 aeoON4fPr1GrhE2k8YBvTx/gfNXg64Up7UwzxzrFO8CiizXc5By1vr0GPgjrlCA5t0 473 zB9srXSN0rASwfVW4CJ9z3NZgnVEnEkHC31uk/pYMvepMDbHgyVzBVse4MmZEthOEJ 474 An4/vLCw= 476 C: MjA6+ebL5YgK6sztDcP1PZCrnMKIjFgs 478 S: MjA6sE5gGxTxvc+yFPgygRuVvze9m6Ys 480 C: 482 S: 235 Authentication successful. 484 6. Discussion 486 Although the MD5 and SHA-1 hash functions are used in this 487 mechanism, they could be replaced with any iterative cryptographic 488 hash function [5]. 490 The specified algorithms were chosen for utility and availablity. It 491 was also felt that a mandatory confidentiality and integrity 492 protection algorithm should be specified to ensure interoperability 493 between implementations of this mechanism. 495 The HMAC-MD5 algorithm was chosen as an integrity algorithm because 496 it is faster than both HMAC-SHA1 and MAC algorithms based on secret 497 key encryption algorithms [4]. 499 Blowfish was chosen as a cipher because [9]: 501 o it is free from intellectual property constraints 503 o it is fast 505 o it has withstood cryptanalysis since 1993 507 o a number of implementations in various programming languages are 508 freely available 510 Other algorithms that are identified as useful may be specified at a 511 later stage. 513 Since confidentiality protection is optional this mechanism should 514 be usable in countries that have strict controls on the use of 515 cryptography. 517 It is RECOMMENDED that the server use values for the modulus (n) and 518 generator (g) chosen from those listed in Appendix A so that the 519 client can avoid expensive constraint checks, since these predefined 520 values already meet the constraints described in [10]: 522 "For maximum security, N should be a safe prime (i.e. a number of 523 the form N = 2q + 1, where q is also prime). Also, g should be a 524 generator modulo N (see [SRP] for details), which means that for 525 any X where 0 < X < N, there exists a value x for which g^x % N 526 == X." 528 7. Security Considerations 530 This mechanism relies on the security of SRP, which bases its 531 security on the difficulty of solving the Diffie-Hellman problem in 532 the multiplicative field modulo a large safe prime. See section 4 533 "Security Considerations" of [10] and section 4 "Security analysis" 534 of [11]. 536 This mechanism also relies on the security of the HMAC algorithm and 537 the underlying hash function. Section 6 "Security" of [5] discusses 538 these security issues in detail. Weaknesses found in MD5 do not 539 impact HMAC-MD5 [3]. 541 The Blowfish cipher has undergone cryptanalysis for a long period of 542 time and no weaknesses have been found [9]. 544 U, I, A and o sent from the client to the server, and N, g, L, s and 545 B sent from the server to the client could be modified by an 546 attacker before reaching the other party. For this reason, these 547 values are included in the respective calculations of evidence to 548 prove that each party knows the session key. This allows each party 549 to verify that these values were received unmodified. 551 The use of integrity protection is RECOMMENDED to detect message 552 tampering and to avoid session hijacking after authentication has 553 taken place. 555 Replay attacks may be avoided through the use of sequence numbers, 556 because sequence numbers make each integrity protected message 557 exchanged during a session different, and each session uses a 558 different key. 560 8. Acknowledgements 562 The following people provided valuable feedback in the preparation 563 of this document: 565 Timothy Martin 567 Raif S. Naffah 569 References 571 [1] Bernstein, D.J., "Netstrings", February 1997, 572 . 574 [2] Bradner, S., "Key words for use in RFCs to Indicate 575 Requirement Levels", BCP 0014, RFC 2119, March 1997. 577 [3] Dobbertin, H., "The Status of MD5 After a Recent Attack", 578 December 1996, 579 . 581 [4] Eisler, M., "LIPKEY - A Low Infrastructure Public Key 582 Mechanism Using SPKM", RFC 2847, June 2000. 584 [5] Krawczyk, H. et al, "HMAC: Keyed-Hashing for Message 585 Authentication", RFC 2104, February 1997. 587 [6] Myers, J.G., "SMTP Service Extension for Authentication", RFC 588 2554, March 1999. 590 [7] Myers, J.G., "Simple Authentication and Security Layer 591 (SASL)", RFC 2222, October 1997. 593 [8] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 594 1999. 596 [9] Schneier, B., "The Blowfish Encryption Algorithm", March 1993, 597 . 599 [10] Wu, T., "Internet Draft: The SRP Authentication and Key 600 Exchange System", July 1999, . 602 [11] Wu, T., "The Secure Remote Password Protocol", March 1998, 603 . 605 [12] Wu, T., "SRP: The Open Source Password Authentication 606 Standard", March 1998, . 608 Author's Address 610 K.R. Burdis 611 Rhodes University 612 Computer Science Department 613 Grahamstown 6139 614 ZA 616 EMail: keith@rucus.ru.ac.za 617 URI: http://www.cryptix.org/~keith/ 619 Appendix A. Modulus and Generator values 621 Modulus (n) and generator (g) values for various modulus lengths are 622 given below. In each case the modulus is a large safe prime and the 623 generator is a primitve root of GF(n) [11]. These values are taken 624 from software developed by Tom Wu and Eugene Jhong for the Stanford 625 SRP distribution [12]. The modulus values are base64 encoded. 627 [264 bits] 628 Modulus = 629 HMujfBWu4LfBFA0j3PpN7UbgUYfv.rMoMNuVRMoekpZ 630 Generator = 2 632 [384 bits] 633 Modulus = 634 W2KsCfRxb3/ELBvnVWufMA0gbdBlLXbJihgZkgp3xLTKwtPCUhSOHNZ5VLb9pBGR 635 Generator = 2 637 [512 bits] 638 Modulus = 639 3Kn/YYiomHkFkfM1x4kayR125MGkzpLUDy3y14FlTMwYnhZkjrMXnoC2TcFAecNl 640 U5kFzgcpKYUbBOPZFRtyf3 641 Generator = 2 643 [640 bits] 644 Modulus = 645 CbDP.jR6YD6wAj2ByQWxQxQZ7.9J9xkn2.Uqb3zVm16vQyizprhBw9hi80psatZ8 646 k54vwZfiIeEHZVsDnyqeWSSIpWso.wh5GD4OFgdhVI3 647 Generator = 2 649 [768 bits] 650 Modulus = 651 iqJ7nFZ4bGCRjE1F.FXEwL085Zb0kLM2TdHDaVVCdq0cKxvnH/0FLskJTKlDtt6s 652 Dl89dc//aEULTVFGtcbA/tDzc.bnFE.DWthQOu2n2JwKjgKfgCR2lZFWXdnWmoOh 653 Generator = 2 655 [1024 bits] 656 Modulus = 657 Ewl2hcjiutMd3Fu2lgFnUXWSc67TVyy2vwYCKoS9MLsrdJVT9RgWTCuEqWJrfB6u 658 E3LsE9GkOlaZabS7M29sj5TnzUqOLJMjiwEzArfiLr9WbMRANlF68N5AVLcPWvNx 659 6Zjl3m5Scp0BzJBz9TkgfhzKJZ.WtP3Mv/67I/0wmRZ 660 Generator = 2 662 [1280 bits] 663 Modulus = 664 3NUKQ2Re4P5BEK0TLg2dX3gETNNNECPoe92h4OVMaDn3Xo/0QdjgG/EvM.hiVV1B 665 dIGklSI14HA38Mpe5k04juR5/EXMU0r1WtsLhNXwKBlf2zEfoOh0zVmDvqInpU69 666 5f29Iy7sNW3U5RIogcs740oUp2Kdv5wuITwnIx84cnO.e467/IV1lPnvMCr0pd1d 667 gS0a.RV5eBJr03Q65Xy61R 668 Generator = 2 670 [1536 bits] 671 Modulus = 672 dUyyhxav9tgnyIg65wHxkzkb7VIPh4o0lkwfOKiPp4rVJrzLRYVBtb76gKlaO7ef 673 5LYGEw3G.4E0jbMxcYBetDy2YdpiP/3GWJInoBbvYHIRO9uBuxgsFKTKWu7RnR7y 674 Tau/IrFTdQ4LY/q.AvoCzMxV0PKvD9Odso/LFIItn8PbTov3VMn/ZEH2SqhtpBUk 675 WtmcIkEflhX/YY/fkBKfBbe27/zUaKUUZEUYZ2H2nlCL60.JIPeZJSzsu/xHDVcx 676 Generator = 2 678 [2048 bits] 679 Modulus = 680 2iQzj1CagQc/5ctbuJYLWlhtAsPHc7xWVyCPAKFRLWKADpASkqe9djWPFWTNTdeJ 681 tL8nAhImCn3Sr/IAdQ1FrGw0WvQUstPx3FO9KNcXOwisOQ1VlL.gheAHYfbYyBax 682 XL.NcJx9TUwgWDT0hRzFzqSrdGGTN3FgSTA1v4QnHtEygNj3eZ.u0MThqWUaDiP8 683 7nqha7XnT66bkTCkQ8.7T8L4KZjIImrNrUftedTTBi.WCi.zlrBxDuOM0da0JbUk 684 QlXqvp0yvJAPpC11nxmmZOAbQOywZGmu9nhZNuwTlxjfIro0FOdthaDTuZRL9VL7 685 MRPUDo/DQEyW.d4H.UIlzp 686 Generator = 2 688 Full Copyright Statement 690 Copyright (C) The Internet Society (2000). All Rights Reserved. 692 This document and translations of it may be copied and furnished to 693 others, and derivative works that comment on or otherwise explain it 694 or assist in its implementation may be prepared, copied, published 695 and distributed, in whole or in part, without restriction of any 696 kind, provided that the above copyright notice and this paragraph 697 are included on all such copies and derivative works. However, this 698 document itself may not be modified in any way, such as by removing 699 the copyright notice or references to the Internet Society or other 700 Internet organizations, except as needed for the purpose of 701 developing Internet standards in which case the procedures for 702 copyrights defined in the Internet Standards process must be 703 followed, or as required to translate it into languages other than 704 English. 706 The limited permissions granted above are perpetual and will not be 707 revoked by the Internet Society or its successors or assigns. 709 This document and the information contained herein is provided on an 710 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 711 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 712 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 713 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 714 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 716 Acknowledgement 718 Funding for the RFC editor function is currently provided by the 719 Internet Society.