idnits 2.17.1 draft-burdis-cat-srp-sasl-06.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 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 83 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 exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: A buffer MAY NOT contain other buffers. It may only contain zero, one or more data elements. -- 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 (January 12, 2002) is 8141 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: '0' on line 141 -- Looks like a reference, but probably isn't: '1' on line 141 -- Looks like a reference, but probably isn't: '2' on line 141 -- Looks like a reference, but probably isn't: '3' on line 141 == Unused Reference: 'RFC-2629' is defined on line 1073, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'AES' -- Possible downref: Non-RFC (?) normative reference: ref. 'DOBBERTIN' -- Possible downref: Non-RFC (?) normative reference: ref. 'HAC' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-10646' -- Possible downref: Non-RFC (?) normative reference: ref. 'KRAWCZYK' -- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS7' ** Downref: Normative reference to an Historic RFC: RFC 1423 ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Obsolete normative reference: RFC 2222 (Obsoleted by RFC 4422, RFC 4752) ** Obsolete normative reference: RFC 2279 (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2440 (Obsoleted by RFC 4880) ** Obsolete normative reference: RFC 2554 (Obsoleted by RFC 4954) ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) -- Possible downref: Non-RFC (?) normative reference: ref. 'RIJNDAEL' -- Possible downref: Non-RFC (?) normative reference: ref. 'SASL' -- Possible downref: Non-RFC (?) normative reference: ref. 'SCAN' -- Possible downref: Non-RFC (?) normative reference: ref. 'SRP' Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 17 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: July 13, 2002 R. Naffah 5 Forge Research 6 January 12, 2002 8 Secure Remote Password SASL Mechanism 9 draft-burdis-cat-srp-sasl-06 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on July 13, 2002. 34 Copyright Notice 36 Copyright (C) The Internet Society (2002). All Rights Reserved. 38 Abstract 40 This document describes a SASL mechanism based on the Secure Remote 41 Password protocol. This mechanism performs mutual authentication 42 and can provide a security layer with replay detection, integrity 43 protection and/or confidentiality protection. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Conventions Used in this Document . . . . . . . . . . . . . . 4 49 3. Data Element Formats . . . . . . . . . . . . . . . . . . . . . 5 50 3.1 Scalar numbers . . . . . . . . . . . . . . . . . . . . . . . . 5 51 3.2 Multi-Precision Integers . . . . . . . . . . . . . . . . . . . 5 52 3.3 Octet Sequences . . . . . . . . . . . . . . . . . . . . . . . 6 53 3.4 Extended Octet Sequences . . . . . . . . . . . . . . . . . . . 6 54 3.5 Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 3.6 Buffers . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 3.7 Data Element Size Limits . . . . . . . . . . . . . . . . . . . 7 57 4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 8 58 4.1 Client sends its identity . . . . . . . . . . . . . . . . . . 9 59 4.2 Server sends initial protocol elements . . . . . . . . . . . . 9 60 4.3 Client sends its ephemeral public key . . . . . . . . . . . . 11 61 4.4 Server sends its ephemeral public key . . . . . . . . . . . . 11 62 4.5 Client sends its evidence . . . . . . . . . . . . . . . . . . 12 63 4.6 Server sends its evidence . . . . . . . . . . . . . . . . . . 13 64 5. Security Layer . . . . . . . . . . . . . . . . . . . . . . . . 14 65 5.1 Confidentiality Protection . . . . . . . . . . . . . . . . . . 15 66 5.2 Replay Detection . . . . . . . . . . . . . . . . . . . . . . . 16 67 5.3 Integrity Protection . . . . . . . . . . . . . . . . . . . . . 17 68 5.4 Summary of Security Layer Output . . . . . . . . . . . . . . . 17 69 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 70 7. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 22 71 7.1 Mandatory Algorithms . . . . . . . . . . . . . . . . . . . . . 22 72 7.2 Modulus and generator values . . . . . . . . . . . . . . . . . 22 73 7.3 Replay detection sequence number counters . . . . . . . . . . 22 74 7.4 SASL Profile Considerations . . . . . . . . . . . . . . . . . 23 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 76 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 77 References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29 79 A. Modulus and Generator values . . . . . . . . . . . . . . . . . 30 80 B. Changes since the previous draft . . . . . . . . . . . . . . . 32 81 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 33 83 1. Introduction 85 The Secure Remote Password (SRP) is a password-based, 86 zero-knowledge, authentication and key-exchange protocol developed 87 by Thomas Wu. It has good performance, is not plaintext-equivalent 88 and maintains perfect forward secrecy. It provides authentication 89 (optionally mutual authentication) and the negotiation of a session 90 key [SRP]. 92 The mechanism described herein is based on the optimised SRP 93 protocol described at the end of section 3 in [RFC-2945], since this 94 reduces the total number of messages exchanged by grouping together 95 pieces of information that do not depend on earlier messages. Due 96 to the design of the mechanism, mutual authentication is MANDATORY. 98 The SASL mechanism name associated with this protocol is "SRP". 100 2. Conventions Used in this Document 102 o A hex digit is an element of the set: 104 {0, 1, 2, 3, 4, 5, 6, 7, 8 , 9, A, B, C, D, E, F} 106 A hex digit is the representation of a 4-bit string. Examples: 108 7 = 0111 110 A = 1010 112 o An octet is an 8-bit string. In this document an octet may be 113 written as a pair of hex digits. Examples: 115 7A = 01111010 117 02 = 00000010 119 o All data is encoded and sent in network byte order (big-endian). 121 o The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 122 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 123 "OPTIONAL" in this document are to be interpreted as described in 124 [RFC-2119]. 126 3. Data Element Formats 128 This section describes the encoding of the data elements used by the 129 SASL mechanism described in this document. 131 3.1 Scalar numbers 133 Scalar numbers are unsigned quantities. Using b[k] to refer to the 134 k-th octet being processed, the value of a two-octet scalar is: 136 ((b[0] << 8) + b[1]), 138 where << is the bit left-shift operator. The value of a four-octet 139 scalar is: 141 ((b[0] << 24) + (b[1] << 16) + (b[2] << 8) + b[3]). 143 3.2 Multi-Precision Integers 145 Multi-Precision Integers, or MPIs, are positive integers used to 146 hold large integers used in cryptographic computations. 148 MPIs are encoded using a scheme inspired by that used by OpenPGP - 149 [RFC-2440] (section 3.2) - for encoding such entities: 151 The encoded form of an MPI SHALL consist of two pieces: a 152 two-octet scalar that represents the length of the entity, in 153 octets, followed by a sequence of octets that contain the actual 154 integer. 156 These octets form a big-endian number; A big-endian number can be 157 encoded by prefixing it with the appropriate length. 159 Examples: (all numbers are in hexadecimal) 161 The sequence of octets [00 01 01] encodes an MPI with the 162 value 1, while the sequence [00 02 01 FF] encodes an MPI with 163 the value of 511. 165 Additional rule: 167 * The length field of an encoded MPI describes the octet count 168 starting from the MPI's first non-zero octet, containing the 169 most significant non-zero bit. Thus, the encoding [00 02 01] 170 is not formed correctly; It should be [00 01 01]. 172 We shall use the syntax mpi(A) to denote the encoded form of the 173 multi-precision integer A. Furthermore, we shall use the syntax 174 bytes(A) to denote the big-endian sequence of octets forming the 175 multi-precision integer with the most significant octet being the 176 first non-zero octet containing the most significant bit of A. 178 3.3 Octet Sequences 180 This mechanism generates, uses and exchanges sequences of octets; 181 e.g. output values of message digest algorithm functions. When such 182 entities travel on the wire, they shall be preceded by a one-octet 183 scalar quantity representing the count of following octets. 185 We shall use the syntax os(s) to denote the encoded form of the 186 octet sequence. Furthermore, we shall use the syntax bytes(s) to 187 denote the sequence of octets s, in big-endian order. 189 3.4 Extended Octet Sequences 191 Extended sequences of octets are exchanged when using the security 192 layer. When these sequences travel on the wire, they shall be 193 preceded by a four-octet scalar quantity representing the count of 194 following octets. 196 We shall use the syntax eos(s) to denote the encoded form of the 197 extended octet sequence. Furthermore, we shall use the syntax 198 bytes(s) to denote the sequence of octets s, in big-endian order. 200 3.5 Text 202 The only character set for text is the UTF-8 encoding [RFC-2279] of 203 Unicode characters [ISO-10646]. 205 We shall use the syntax utf8(L) to denote the string L in UTF-8 206 encoding, preceded by a two-octet scalar quantity representing the 207 count of following octets. Furthermore, we shall use the syntax 208 bytes(L) to denote the sequence of octets representing the UTF-8 209 encoding of L, in big-endian order. 211 3.6 Buffers 213 In this SASL mechanism data is exchanged between the client and 214 server using buffers. A buffer acts as an envelope for the sequence 215 of data elements sent by one end-point of the exchange, and expected 216 by the other. 218 A buffer MAY NOT contain other buffers. It may only contain zero, 219 one or more data elements. 221 A buffer shall be encoded as two fields: a four-octet scalar 222 quantity representing the count of following octets, and the 223 concatenation of the octets of the data element(s) contained in the 224 buffer. 226 We shall use the syntax {A|B|C} to denote a buffer containing A, B 227 and C in that order. For example: 229 { mpi(N) | mpi(g) | utf8(L) } 231 is a buffer containing, in the designated order, the encoded forms 232 of an MPI N, an MPI g and a Text L. 234 3.7 Data Element Size Limits 236 The following table details the size limit, in number of octets, for 237 each of the SASL data element encodings described earlier. 239 Data element type Header Size limit in octets 240 (octets) (excluding header) 241 ------------------------------------------------------------ 242 Octet Sequence 1 255 243 MPI 2 65,535 244 Text 2 65,535 245 Extended Octet Sequence 4 2,147,483,383 246 Buffer 4 2,147,483,643 248 An implementation MUST signal an exception if any size constraint is 249 violated. 251 4. Protocol Description 253 The following sections describe the sequence of data transmitted 254 between the client and server for the SRP SASL mechanism, as well as 255 the extra control information exchanged to enable a client to 256 request whether or not replay detection, integrity protection and/or 257 confidentiality protection should be provided by a security layer. 259 Mechanism data exchanges, during the authentication phase, are shown 260 below: 262 Client Server 264 --- { utf8(U) | utf8(I) } ------------------------> 266 <-------- { mpi(N) | mpi(g) | os(s) | utf8(L) } --- 268 --- { mpi(A) | utf8(o) } -------------------------> 270 <----------------------------------- { mpi(B) } --- 272 --- { os(M1) } -----------------------------------> 274 ( optionally ) 276 <----------------------------------- { os(M2) } --- 278 where: 280 U is the authentication identity (username), 282 I is the authorisation identity, 284 N is the safe prime modulus, 286 g is the generator, 288 s is the user's password salt, 290 L is the options list indicating available security services, 292 A is the client's ephemeral public key, 294 o is the options list indicating chosen security services, 296 B is the server's ephemeral public key, 298 M1 is the client's evidence that the shared key K is known, 299 M2 is the server's evidence that the shared key K is known. 301 4.1 Client sends its identity 303 The client determines its authentication identity U and 304 authorisation identity I, encodes them and sends them to the server. 306 The client sends: 308 { utf8(U) | utf8(I) } 310 4.2 Server sends initial protocol elements 312 The server receives U, and looks up the safe prime modulus N, the 313 generator g, and the salt s to be used for that identity. 315 The server also creates an options list L, which consists of a 316 comma-separated list of option strings that specify the options the 317 server supports. This options list MUST NOT be interpreted in a 318 case-sensitive manner, and whitespace characters MUST be ignored. 320 The following option strings are defined: 322 o "mda=" indicates that the server 323 supports the designated hash function as the underlying Message 324 Digest Algorithm for the designated user to be used for all SRP 325 calculations - to compute both client-side and server-side 326 digests. The specified algorithm MUST meet the requirements 327 specified in section 3.2 of [RFC-2945]: 329 "Any hash function used with SRP should produce an output of 330 at least 16 bytes and have the property that small changes in 331 the input cause significant nonlinear changes in the output." 333 Note that in the interests of interoperability between client and 334 server implementations and with other SRP-based tools, both the 335 client and the server MUST support SHA-160 as an underlying 336 Message Digest Algorithm. While the server is not required to 337 list SHA-160 as an available underlying Message Digest Algorithm, 338 it must be able to do so. 340 o "integrity=HMAC-" indicates that the server supports 341 integrity protection using the HMAC algorithm [RFC-2104] with 342 as the underlying Message Digest Algorithm. 343 Acceptable MDA names are chosen from [SCAN] under the 344 MessageDigest section. A server SHOULD send such an option 345 string for each HMAC algorithm it supports. Note that in the 346 interest of interoperability, if the server offers integrity 347 protection it MUST, as a minimum, send the option string 348 "integrity=HMAC-SHA-160" since support for this algorithm is then 349 MANDATORY. 351 o "replay detection" indicates that the server supports replay 352 detection using sequence numbers. Replay detection SHALL NOT be 353 activated without also activating integrity protection. If the 354 replay detection option is offered (by the server) and/or chosen 355 (by the client) without explicitely specifying an integrity 356 protection option, then the default integrity protection option 357 "integrity=HMAC-SHA-160" is implied and shall be activated. 359 o "confidentiality=" indicates that the server 360 supports confidentiality protection using the symmetric block 361 cipher algorithm . The server SHOULD send such an 362 option string for each confidentiality protection algorithm it 363 supports. Note that in the interest of interoperability, if the 364 server offers confidentiality protection, it MUST send the option 365 string "confidentiality=aes" since it is then MANDATORY for it to 366 provide support for this algorithm. (Rijndael [RIJNDAEL] is 367 synonymous with AES [AES].) 369 o "mandatory=[integrity|replay detection|confidentiality]" is an 370 option only available to the server that indicates that the 371 specified security layer option is MANDATORY and MUST be chosen 372 by the client for use in the resulting security layer. If a 373 server specifies an option as mandatory in this way, it MUST 374 abort the connection if the specified option is not chosen by the 375 client. It doesn't make sense for the client to send this option 376 since it is only able to choose options that the server 377 advertises. The client SHOULD abort the connection if the server 378 does not offer an option that it requires. If this option is not 379 specified then this implies that no options are mandatory. 381 o "maxbuffersize=" indicates to the peer the 382 maximum number of raw bytes (excluding the SASL buffer 4-byte 383 length header) to be processed by the security layer at a time, 384 if one is negotiated. The value of MUST NOT 385 exceed the Buffer size limit defined in section 3.7. If this 386 option is not detected by a client or server mechanism, then it 387 shall operate its security layer on the assumption that the 388 maximum number of bytes that may be sent, to the peer server or 389 client mechanism respectively, is the Buffer data size limit 390 indicated in section 3.7. On the other hand, if a recipient 391 detects this option, it shall break any octet-sequence longer 392 than the designated limit into two or more fragments, each 393 wrapped in a SASL buffer, before sending them, in sequence, to 394 the peer. 396 For example, if the server supports integrity protection using the 397 HMAC-SHA-160 and HMAC-MD5 algorithms, replay detection and no 398 confidentiality protection, the options list would be: 400 mda=SHA-1,integrity=HMAC-SHA-160,integrity=HMAC-MD5,replay 401 detection 403 The server sends: 405 { mpi(N) | mpi(g) | os(s) | utf8(L) } 407 4.3 Client sends its ephemeral public key 409 The client receives the options list L from the server that 410 specifies the Message Digest Algorithm(s) available to be used for 411 all SRP calculations, the security service options the server 412 supports, and the maximum buffer size the server can handle. The 413 client selects options from this list and creates a new options list 414 o that specifies the selected Message Digest Algorithm to be used 415 for SRP calculations and the security services that will be used in 416 the security layer. At most one available Message Digest Algorithm 417 name, one available integrity protection algorithm and one available 418 confidentiality protection algorithm may be selected. The client 419 MUST include any option specified by the mandatory option. 421 The client generates its ephemeral public key A as follows: 423 a = prng(); 425 A = g**a % N; 427 where: 429 prng() is a random number generation function, 431 a is the MPI that will act as the client's private key, 433 ** is the exponentiation operator, 435 % is the modulus operator, 437 The client sends: 439 { mpi(A) | utf8(o) } 441 4.4 Server sends its ephemeral public key 443 The server reads the client's verifier v, calculates the shared 444 context key K and generates its ephemeral public key B as follows: 446 b = prng(); 448 B = (v + g**b) % N; 450 K = H2((A * v**u) ** b % N); 452 where: 454 b is the MPI that will act as the server's private key, 456 v is the stored password verifier value, 458 u is a 32-bit unsigned integer which takes its value from the 459 first 32 bits of the hash of B, MSB first, 461 H2() is the "Interleaved SHA" function, as described in 462 [RFC-2945], but generalised to any message digest algorithm, and 463 applied using the underlying Message Digest Algorithm (see 464 Section 4.2). 466 The server sends: 468 { mpi(B) } 470 4.5 Client sends its evidence 472 The client calculates the shared context key K, and calculates the 473 evidence M1 that proves to the server that it knows the shared 474 context key K, including I and L as part of the calculation. K, on 475 the client's side is computed as follows: 477 x = H(s | H(U | ":" | p)); 479 K = H2((B - g**x) ** (a + u * x) % N); 481 where: 483 H() is the result of digesting the designated input/data with the 484 underlying Message Digest Algorithm function (see Section 4.2). 486 p is the password value. 488 M1 is computed as: 490 H( bytes(H( bytes(N) )) ^ bytes( H( bytes(g) )) 491 | bytes(H( bytes(U) )) 492 | bytes(s) 493 | bytes(A) 494 | bytes(B) 495 | bytes(K) 496 | bytes(H( bytes(I) ) 497 | bytes(H( bytes(L) )) 498 ) 500 where: 502 ^ is the bitwise XOR operator. 504 The client sends: 506 { os(M1) } 508 4.6 Server sends its evidence 510 When the Confidentiality Protection service is requested and 511 approved, the server MUST NOT send M2 but instead conclude the SASL 512 exchange with the reception and verification of the client's M1. 513 Otherwise, M2 MUST be sent. 515 When the server has to send its evidence M2, which proves to the 516 client that it knows the shared context key K, as well as U, I and 517 o, it shall compute it as follows: 519 H( bytes(A) 520 | bytes(M1) 521 | bytes(K) 522 | bytes(H( bytes(U) )) 523 | bytes(H( bytes(I) )) 524 | bytes(H( bytes(o) )) 525 ) 527 The server OPTIONALLY sends: 529 { os(M2) } 531 5. Security Layer 533 Depending on the options offered by the server and specified by the 534 client, the security layer may provide integrity protection, replay 535 detection, and/or confidentiality protection. 537 The security layer can be thought of as a three-stage filter through 538 which the data flows from the output of one stage to the input of 539 the following one. The first input is the original data, while the 540 last output is the data after being subject to the transformations 541 of this filter. 543 The data always passes through this three-stage filter, though any 544 of the stages may be inactive. Only when a stage is active would 545 the output be different from the input. In other words, if a stage 546 is inactive, the octet sequence at the output side is an exact 547 duplicate of the same sequence at the input side. 549 Schematically, the three-stage filter security layer appears as 550 follows: 552 +----------------------------+ 553 | | I/ p1 554 p1 --->| Confidentiality protection |---+ 555 | | | A/ c 556 +----------------------------+ | 557 | 558 +------------------------------------+ 559 | 560 | +----------------------------+ 561 | | | I/ p2 562 p2 +-->| Replay detection |---+ 563 | | | A/ p2 | q 564 +----------------------------+ | 565 | 566 +------------------------------------+ 567 | 568 | +----------------------------+ 569 | | | I/ p3 570 p3 +-->| Integrity protection |---> 571 | | A/ p3 | C 572 +----------------------------+ 574 where: 576 p1, p2 and p3 are the input octet sequences at each stage, 578 I/ denotes the output at the end of one stage if/when the stage 579 is inactive or disabled, 580 A/ denotes the output at the end of one stage if/when the stage 581 is active or enabled, 583 c is the encrypted (sender-side) or decrypted (receiver-side) 584 octet sequence. c1 shall denote the value computed by the 585 sender, while c2 shall denote the value computed by the receiver. 587 q is a four-octet scalar quantity representing a sequence number, 589 C is the Message Authentication Code. C1 shall denote the value 590 of the MAC as computed by the sender, while C2 shall denote the 591 value computed by the receiver. 593 The following paragraphs detail each of the transformations 594 mentioned above. 596 5.1 Confidentiality Protection 598 The plaintext data octet sequence p1 is encrypted using the chosen 599 confidentiality algorithm (CALG) initialised for encryption with the 600 shared context key K. 602 c1 = CALG(K, ENCRYPTION)( bytes(p1) ) 604 On the receiving side, the ciphertext data octet sequence p1 is 605 decrypted using the chosen confidentiality algorithm (CALG) 606 initialised for decryption, with the shared context key K. 608 c2 = CALG(K, DECRYPTION)( bytes(p1) ) 610 The designated CALG block cipher should be used in OFB (Output 611 Feedback Block) mode in the ISO variant, as described in [HAC], 612 algorithm 7.20. 614 Let k be the block size of the chosen symmetric cipher algorithm; 615 e.g. for AES this is 128 bits or 16 octets. The OFB mode used shall 616 be of length/size k. 618 It is recommended that Block ciphers operating in OFB mode be used 619 with an Initial Vector (the mode's IV). For the SASL mechanism 620 described in this document, the IV shall be an all-zero octet 621 sequence of size k. 623 In such a mode of operation - OFB with key re-use - the IV, which 624 need not be secret, must be changed. Otherwise an identical 625 keystream results; and, by XORing corresponding ciphertexts, an 626 adversary may reduce cryptanalysis to that of a running-key cipher 627 with one plaintext as the running key. To counter the effect of 628 fixing the IV to an all-zero octet sequence, the sender should use a 629 one k-octet sequence as the value of its first block, constructed as 630 follows: 632 o the first (most significant) (k-2) octets are random, 634 o the octets at position #k-1 and #k, assuming the first octet is 635 at position #1, are exact copies of those at positions #1 and #2 636 respectively. 638 The input data to the confidentiality protection algorithm shall be 639 a multiple of the symmetric cipher block size k. When the input 640 length is not a multiple of k octets, the data shall be padded 641 according to the following scheme (described in [PKCS7] which itself 642 is based on [RFC-1423]): 644 Assuming the length of the input is l octets, (k - (l mod k)) 645 octets, all having the value (k - (l mod k)), shall be appended 646 to the original data. In other words, the input is padded at the 647 trailing end with one of the following sequences: 649 01 -- if l mod k = k-1 650 02 02 -- if l mod k = k-2 651 ... 652 ... 653 ... 654 k k ... k k -- if l mod k = 0 656 The padding can be removed unambiguously since all input is 657 padded and no padding sequence is a suffix of another. This 658 padding method is well-defined if and only if k < 256 octets, 659 which is the case with symmetric block ciphers today, and in the 660 forseeable future. 662 The output of this stage, when it is active, is: 664 at the sending side: CALG(K, ENCRYPT)( bytes(p1) ) 666 at the receiving side: CALG(K, DECRYPT)( bytes(p1) ) 668 If the receiver, after decrypting the first block, finds that the 669 last two octets do not match the value of the first two, it MUST 670 signal an exception and abort the exchange. 672 5.2 Replay Detection 674 A sequence number q is incremented every time a message is sent to 675 the peer. 677 The output of this stage, when it is active, is: 679 p2 | q 681 At the other end, the receiver increments its copy of the sequence 682 number. This new value of the sequence number is then used in the 683 integrity protection transformation, which must also be active as 684 described in Section 4.2. See Section 7.3 for more details. 686 5.3 Integrity Protection 688 When the Integrity Protection stage is active, a message 689 authentication code C is computed using the chosen integrity 690 protection algorithm (IALG) as follows: 692 o the IALG is initialised (once) with the shared context key K, 694 o the IALG is updated with every exchange of the sequence p3, 695 yielding the value C and a new IALG context for use in the 696 following exchange. 698 At the other end, the receiver computes its version of C, using the 699 same transformation, and checks that its value is equal to that 700 received. If the two values do not agree, the receiver must signal 701 an exception and abort. 703 The output of this stage, when it is active, is then: 705 IALG(K)( bytes(p3) ) 707 5.4 Summary of Security Layer Output 709 The following table shows the data exchanged by the security layer 710 peers, depending on the possible legal combinations of the three 711 security services in operation: 713 CP IP RD Peer sends/receives 715 I I I { eos(p) } 716 I A I { eos(p) | os( IALG(K)( bytes(p) ) ) } 717 I A A { eos(p) | os( IALG(K)( bytes(p) | bytes(q)) ) } 718 A I I { eos(c) } 719 A A I { eos(c) | os( IALG(K)( bytes(c) ) ) } 720 A A A { eos(c) | os( IALG(K)((bytes(c) | bytes(q)) ) } 722 where 724 CP Confidentiality protection, 726 IP Integrity protection, 727 RD Replay detection, 729 I Security service is Inactive/disabled, 731 A Security service is Active/enabled, 733 p The original plaintext, 735 q The sequence number. 737 c The enciphered input obtained by either: 739 CALG(K, ENCRYPT)( bytes(p) ) at the sender's side, or 741 CALG(K, DECRYPT)( bytes(p) ) at the receiver's side 743 6. Example 745 The example below uses SMTP authentication [RFC-2554]. The base64 746 encoding of challenges and responses, as well as the reply codes 747 preceding the responses are part of the SMTP authentication 748 specification, not part of this SASL mechanism itself. 750 "C:" and "S:" indicate lines sent by the client and server 751 respectively. 753 S: 220 smtp.example.com ESMTP server ready 755 C: EHLO zaau.example.com 757 S: 250-smtp.example.com 758 S: 250 AUTH SRP CRAM-MD5 DIGEST-MD5 760 C: AUTH SRP AAAADAAEdGVzdAAEdGVzdA== 762 with: 764 U = "test" 766 I = "test" 768 S: 334 AAABygEArGvbQTJKmpvxZt5eE4lYL69ytmUZh+4H/DGSlD21YFCjcynLtKCZ7Y 769 GT4HV3Z6E91SMSq0sDMQ3Nf0ip2gT9UOgIOWntt2ewz2CVF5oWOrNmGgX71fqq6CkYqZY 770 vC5O4Vfl5k+yXXuqoDXQK2/T/dHNZ0EHVwz6nHSgeRGsUdzvKl7Q6I/uAFna9IHpDbGSB 771 8dK5B4cXRhpbnTLmiPh3SFRFI7UksNV9Xqd6J3XS7PoDLPvb9S+zeGFgJ5AE5Xrmr4dOc 772 wPOUymczAQce8MI2CpWmPOo0MOCca41+Onb+7aUtcgD2J965DXeI21SX1R1m2XjcvzWjv 773 IPpxEfnkr/cwABAgqsi3AvmIqdEbREALhtZGE9U0hBLTEsbWFuZGF0b3J5PXJlcGxheSB 774 kZXRlY3Rpb24scmVwbGF5IGRldGVjdGlvbixpbnRlZ3JpdHk9aG1hYy1zaGExLGludGVn 775 cml0eT1obWFjLW1kNSxjb25maWRlbnRpYWxpdHk9YWVzLGNvbmZpZGVudGlhbGl0eT1jY 776 XN0NSxjb25maWRlbnRpYWxpdHk9Ymxvd2Zpc2gsbWF4YnVmZmVyc2l6ZT0yMTQ3NDgzNj 777 Qz 779 with: 781 N = "2176617445861743577319100889180275378190766837425553851114464 782 322468988623538384095721090901308605640157139971723580726658164960 783 647214841029141336415219736447718088739565548373811507267740223510 784 176252190156982074029314952962041933326626207347105454836873603951 785 970248622650624886106025697180298495356112144268015766800076142998 786 822245709041387397397017192709399211475176516806361476111961547623 787 342209644278311797123637164733387141433589577347466730896705080700 788 550932042479967841703686792831676127227423031406754829113358247958 789 306143957755934710196177140617368437852270348349533703765500675132 790 8447510550299250924469288819" 791 g = "2" 793 s = "814819216327401865851972" 795 L = "mda=SHA-1,mandatory=replay detection,replay detection,integri 796 ty=hmac-sha1,integrity=hmac-md5,confidentiality=aes,confidentialit 797 y=cast5,confidentiality=blowfish,maxbuffersize=2147483643" 799 C: AAABYwEAAp5q/4zhXoTUzXBscozN97SWgfDcAImIk3lNHNvd0b+Dr7jEm6upXblZT5 800 sL9mPgFsejlIh+B/eCu/HvzWCrXj6ylPZv8dy3LCH3LIORqQ45S7Lsbmrrg/dukDh4tZC 801 JMLD4r3evzaY8KVhtJeLMVbeXuh4JljKP42Ll59Lzwf8jfPh4+4Lae1rpWUCL9DueKcY+ 802 nN+xNHTit/ynLATxwL93P6+GoGY4TkUbUBfjiI1+rAMvyMDMw5XozGy07FOEc++U0iPeX 803 CQP4MT5FipOUoz8CYX7J1LbaXp2WJuFHlkyVXF7oCoyHbhld/5CfR3o6q/B/x9+yZRqaH 804 H+JfllOgBfbWRhPVNIQS0xLHJlcGxheSBkZXRlY3Rpb24saW50ZWdyaXR5PWhtYWMtbWQ 805 1LGNvbmZpZGVudGlhbGl0eT1ibG93ZmlzaCxtYXhidWZmZXJzaXplPTIxNDc0ODM2NDM= 807 with: 809 A = "3305954184671210249746312321130434202193449637258786928151596 810 956582377798844627774788503949777445537469304518958156158884050562 811 780707370878253753979367019077142882237029766166623275718227655538 812 983419084032208109159908908194732453790761392470705815003778027907 813 762317939621437864117925167600301024366036210465417293966890613394 814 379900527412007068242559299422872893332111365840536495185883474232 815 883537338757318836995637988160638089067541196607366511069220022940 816 355334703015419992745572006667033895314817945166254757418442215980 817 634933876533189969562613241499465295849832999091403980813218409496 818 06581251320320995783959866" 820 o = mda=SHA-1,replay detection,integrity=hmac-md5,confidentiality= 821 blowfish,maxbuffersize=2147483643" 823 S: 334 AAABAgEAOUKbXpnzMhziivGgMwm+FS8sKGSvjh5M3D+80RF/5z9rm0oPoi4+pF 824 83fueWn4Hz9M+muF/22PHHZkHtlutDrtapj4OtirdxC21fS9bMtEh3F0whTX+3mPvthw5 825 sk11turandHiLvcUZOgcrAGIoDKcBPoGyBud+8bMgpkf/uGfyBM2nEX/hV+oGggX+LiHj 826 mkxAJ3kewfQPH0eV9ffEuuyu8BUcBXkJsS6l7eWkuERSCttVOi/jS031c+CD/nuecUXYi 827 F8IYzW03rbcwYhZzifmTi3VK9C8zG2K1WmGU+cDKlZMkyCPMmtCsxlbgE8zSHCuCiOgQ3 828 5XhcA0Qa0C3Q== 830 with: 832 B: "72284284756503184420540308728542442858927345812975023176601544 833 656078275298532392401181852634926172435239161066586969655965268585 834 300845435562962039149169549800169184521786717633959469278439877134 835 444500243257950929211559843568506288263176079641655456298084758961 836 983258355079013195569295114214721321849903652130596549627218189966 837 140113906545856088040473723048909402258929560823932725202215411408 838 791389541192767670707304028113609680668175826522120988223747234163 839 643404100201722157739343027946790344246999996116789730443114919539 840 575466941344964841591072763617954717789621871251710891793993491944 841 52686682517183909017223901" 843 C: AAAAFRTkoju6xGP+zH89iaDWIFjfIKt5Kg== 845 S: 235 Authentication successful. 847 7. Discussion 849 7.1 Mandatory Algorithms 851 The algorithms specified as mandatory were chosen for utility and 852 availablity. We felt that a mandatory confidentiality and integrity 853 protection algorithm for the security layer and a mandatory Message 854 Digest Algorithm for SRP calculations should be specified to ensure 855 interoperability between implementations of this mechanism: 857 o The SHA-160 Message Digest Algorithm was chosen as an underlying 858 algorithm for SRP calculations because this allows for easy 859 interoperability with other SRP-based tools that use the SRP-SHA1 860 protocol described in section 3 of [RFC-2945] and create their 861 password files using this algorithm. 863 o The HMAC algorithm was chosen as an integrity algorithm because 864 it is faster than MAC algorithms based on secret key encryption 865 algorithms [RFC-2847]. 867 o Rijndael was chosen as a cipher because it has undergone thorough 868 scrutiny by the best cryptographers in the world and was chosen 869 ahead of many other algorithms as the Advanced Encryption 870 Standard. 872 Since confidentiality protection is optional, this mechanism should 873 be usable in countries that have strict controls on the use of 874 cryptography. 876 7.2 Modulus and generator values 878 It is RECOMMENDED that the server use values for the modulus (N) and 879 generator (g) chosen from those listed in Appendix A so that the 880 client can avoid expensive constraint checks, since these predefined 881 values already meet the constraints described in [RFC-2945]: 883 "For maximum security, N should be a safe prime (i.e. a number of 884 the form N = 2q + 1, where q is also prime). Also, g should be a 885 generator modulo N (see [SRP] for details), which means that for 886 any X where 0 < X < N, there exists a value x for which g**x % N 887 == X." 889 7.3 Replay detection sequence number counters 891 The mechanism described in this document allows the use of a Replay 892 Detection security service that works by including sequence number 893 counters in the message authentication code (MAC) created by the 894 Integrity Protection service. As noted in Section 4.2 integrity 895 protection is always activated when the Replay Detection service is 896 activated. 898 Both the client and the server keep two sequence number counters. 899 Each of these counters is a 32-bit unsigned integer initialised with 900 a Starting Value and incremented by an Increment Value with every 901 successful transmission of an SASL buffer through the security 902 layer. The Sent counter is incremented for each buffer sent through 903 the security layer. The Received counter is incremented for each 904 buffer received through the security layer. If the value of a 905 sequence number counter exceeds 2**32 it wraps around and starts 906 from zero again. 908 When a sender sends a buffer it includes the value of its Sent 909 counter in the computation of the MAC accompanying each integrity 910 protected message. When a recipient receives a buffer it uses the 911 value of it's Received counter in its computation of the integrity 912 protection MAC for the received message. The recipient's Received 913 counter must be the same as the sender's Sent counter in order for 914 the received and computed MACs to match. 916 This specification assumes that for each sequence number counter the 917 Starting Value is ZERO, and that the Increment Value is ONE. These 918 values do not affect the security or the intended objective of the 919 replay detection service, since they never travel on the wire. 921 7.4 SASL Profile Considerations 923 As mentioned briefly in [RFC-2222], and detailed in [SASL] a SASL 924 specification has three layers: (a) a protocol definition using SASL 925 known as the "Profile", (b) a SASL mechanism definition, and (c) the 926 SASL framework. 928 Point (3) in section 5 of [SASL] ("Protocol profile requirements") 929 clearly states that it is the responsibility of the Profile to 930 define "...how the challenges and responses are encoded, how the 931 server indicates completion or failure of the exchange, how the 932 client aborts an exchange, and how the exchange method interacts 933 with any line length limits in the protocol." 935 The username entity, referenced as "U" throughout this document, and 936 used by the server to locate the password data, is assumed to travel 937 "in the clear," meaning that no transformation is applied to its 938 contents. This assumption was made to allow the same SRP password 939 files to be used in this mechanism, as those used with other SRP 940 applications and tools. 942 A Profile may decide, for privacy or other reason, to disallow such 943 information to travel in the clear, and instead use a hashed version 944 of U, or more generally a transformation function applied to U; i.e. 946 f(U). Such a Profile would require additional tools to add the 947 required entries to the SRP password files for the new value(s) of 948 f(U). It is worth noting too that if this is the case, and the same 949 user shall access the server through this mechanism as well as 950 through other SRP tools, then at least two entries, one with U and 951 the other with f(U) need to be present in the SRP password files if 952 those same files are to be used for both types of access. 954 8. Security Considerations 956 This mechanism relies on the security of SRP, which bases its 957 security on the difficulty of solving the Diffie-Hellman problem in 958 the multiplicative field modulo a large safe prime. See section 4 959 "Security Considerations" of [RFC-2945] and section 4 "Security 960 analysis" of [SRP]. 962 B, the server's ephemeral public key, is computed as g**b + v = g**b 963 + g**x, which is symmetric and allows two guesses per *active 964 attack*. In practical terms, this makes no difference to the 965 security of SRP, since the number of active attacks needed is still 966 linearly proportional to the number of guesses needed; only the 967 constant factor (2 vs. 1) has changed. 969 This mechanism also relies on the security of the HMAC algorithm and 970 the underlying hash function when integrity protection is used. 971 Section 6 "Security" of [RFC-2104] discusses these security issues 972 in detail. Weaknesses found in MD5 do not impact HMAC-MD5 973 [DOBBERTIN]. 975 U, A, I and o, sent from the client to the server, and N, g, L, s 976 and B, sent from the server to the client could be modified by an 977 attacker before reaching the other party. For this reason, these 978 values are included in the respective calculations of evidence (M1 979 and M2) to prove that each party knows the session key K. This 980 allows each party to verify that these values were received 981 unmodified. 983 The use of integrity protection is RECOMMENDED to detect message 984 tampering and to avoid session hijacking after authentication has 985 taken place. 987 Replay attacks may be avoided through the use of sequence numbers, 988 because sequence numbers make each integrity protected message 989 exchanged during a session different, and each session uses a 990 different key. 992 Research [KRAWCZYK] shows that the order and way of combining 993 message encryption (Confidentiality Protection) and message 994 authentication (Integrity Protection) are important. This mechanism 995 follows the EtA (encrypt-then-authenticate) method and is 996 "generically secure." 998 9. Acknowledgements 1000 The following people provided valuable feedback in the preparation 1001 of this document: 1003 Stephen Farrell 1005 Timothy Martin 1007 Ken Murchison 1009 Magnus Nystrom 1011 Thomas Wu 1013 References 1015 [AES] National Institute of Standards and Technology, 1016 "Rijndael: NIST's Selection for the AES", December 1017 2000, 1018 . 1021 [DOBBERTIN] Dobbertin, H., "The Status of MD5 After a Recent 1022 Attack", December 1996, 1023 . 1026 [HAC] Menezes, A.J., van Oorschot, P.C. and S.A. Vanstone, 1027 "Handbook of Applied Cryptography", CRC Press, Inc., 1028 ISBN 0-8493-8523-7, 1997, 1029 . 1031 [ISO-10646] "International Standard --Information technology-- 1032 Universal Multiple-Octet Coded Character Set (UCS) -- 1033 Part 1 Architecture and Basic Multilingual Plane", 1034 ISO/IEC 10646-1, 1993. 1036 [KRAWCZYK] Krawczyk, H., "The order of encryption and 1037 authentication for protecting communications (Or: how 1038 secure is SSL?)", June 2001, 1039 . 1041 [PKCS7] RSA Data Security, Inc., "PKCS #7: Cryptographic 1042 Message Syntax Standard", Version 1.5, November 1993, 1043 . 1045 [RFC-1423] Balenson, D., "Privacy Enhancement for Internet 1046 Electronic Mail: Part III: Algorithms, Modes, and 1047 Identifiers", RFC 1423, February 1993, 1048 . 1050 [RFC-2104] Krawczyk, H. et al, "HMAC: Keyed-Hashing for Message 1051 Authentication", RFC 2104, February 1997, 1052 . 1054 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 1055 Requirement Levels", BCP 0014, RFC 2119, March 1997, 1056 . 1058 [RFC-2222] Myers, J.G., "Simple Authentication and Security Layer 1059 (SASL)", RFC 2222, October 1997, 1060 . 1062 [RFC-2279] Yergeau, F., "UTF-8, a transformation format of Unicode 1063 and ISO 10646", RFC 2279, January 1998, 1064 . 1066 [RFC-2440] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, 1067 "OpenPGP Message Format", RFC 2440, November 1998, 1068 . 1070 [RFC-2554] Myers, J.G., "SMTP Service Extension for 1071 Authentication", RFC 2554, March 1999. 1073 [RFC-2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 1074 June 1999, 1075 . 1077 [RFC-2847] Eisler, M., "LIPKEY - A Low Infrastructure Public Key 1078 Mechanism Using SPKM", RFC 2847, June 2000, 1079 . 1081 [RFC-2945] Wu, T., "The SRP Authentication and Key Exchange 1082 System", RFC 2945, September 2000, 1083 . 1085 [RIJNDAEL] Daemen, Joan and Vincent Rijmen, "AES Proposal: 1086 Rijndael", September 1999, 1087 . 1089 [SASL] Myers, J.G., "Simple Authentication and Security Layer 1090 (SASL)", April 2001, 1091 . 1094 [SCAN] Hopwood, D., "Standard Cryptographic Algorithm Naming", 1095 June 2000, 1096 . 1098 [SRP] Wu, T., "The Secure Remote Password Protocol", March 1099 1998, 1100 . 1102 [SRP'] Wu, T., "SRP: The Open Source Password Authentication 1103 Standard", March 1998, 1104 . 1106 Authors' Addresses 1108 Keith Burdis 1109 Rhodes University 1110 Computer Science Department 1111 Grahamstown 6139 1112 ZA 1114 EMail: keith@rucus.ru.ac.za 1116 Raif S. Naffah 1117 Forge Research Pty. Limited 1118 Suite 116, Bay 9 1119 Locomotive Workshop, 1120 Australian Technology Park 1121 Cornwallis Street 1122 Eveleigh, NSW 1430 1123 AU 1125 EMail: raif@forge.com.au 1127 Appendix A. Modulus and Generator values 1129 Modulus (N) and generator (g) values for various modulus lengths are 1130 given below. In each case the modulus is a large safe prime and the 1131 generator is a primitve root of GF(n) [RFC-2945]. These values are 1132 taken from software developed by Tom Wu and Eugene Jhong for the 1133 Stanford SRP distribution [SRP']. 1135 [264 bits] 1136 Modulus (base 16) = 1137 115B8B692E0E045692CF280B436735C77A5A9E8A9E7ED56C965F87DB5B2A2ECE 1138 3 1139 Generator = 2 1141 [384 bits] 1142 Modulus (base 16) = 1143 8025363296FB943FCE54BE717E0E2958A02A9672EF561953B2BAA3BAACC3ED57 1144 54EB764C7AB7184578C57D5949CCB41B 1145 Generator = 2 1147 [512 bits] 1148 Modulus (base 16) = 1149 D4C7F8A2B32C11B8FBA9581EC4BA4F1B04215642EF7355E37C0FC0443EF756EA 1150 2C6B8EEB755A1C723027663CAA265EF785B8FF6A9B35227A52D86633DBDFCA43 1151 Generator = 2 1153 [640 bits] 1154 Modulus (base 16) = 1155 C94D67EB5B1A2346E8AB422FC6A0EDAEDA8C7F894C9EEEC42F9ED250FD7F0046 1156 E5AF2CF73D6B2FA26BB08033DA4DE322E144E7A8E9B12A0E4637F6371F34A207 1157 1C4B3836CBEEAB15034460FAA7ADF483 1158 Generator = 2 1160 [768 bits] 1161 Modulus (base 16) = 1162 B344C7C4F8C495031BB4E04FF8F84EE95008163940B9558276744D91F7CC9F40 1163 2653BE7147F00F576B93754BCDDF71B636F2099E6FFF90E79575F3D0DE694AFF 1164 737D9BE9713CEF8D837ADA6380B1093E94B6A529A8C6C2BE33E0867C60C3262B 1165 Generator = 2 1167 [1024 bits] 1168 Modulus (base 16) = 1169 EEAF0AB9ADB38DD69C33F80AFA8FC5E86072618775FF3C0B9EA2314C9C256576 1170 D674DF7496EA81D3383B4813D692C6E0E0D5D8E250B98BE48E495C1D6089DAD1 1171 5DC7D7B46154D6B6CE8EF4AD69B15D4982559B297BCF1885C529F566660E57EC 1172 68EDBC3C05726CC02FD4CBF4976EAA9AFD5138FE8376435B9FC61D2FC0EB06E3 1173 Generator = 2 1175 [1280 bits] 1176 Modulus (base 16) = 1177 D77946826E811914B39401D56A0A7843A8E7575D738C672A090AB1187D690DC4 1178 3872FC06A7B6A43F3B95BEAEC7DF04B9D242EBDC481111283216CE816E004B78 1179 6C5FCE856780D41837D95AD787A50BBE90BD3A9C98AC0F5FC0DE744B1CDE1891 1180 690894BC1F65E00DE15B4B2AA6D87100C9ECC2527E45EB849DEB14BB2049B163 1181 EA04187FD27C1BD9C7958CD40CE7067A9C024F9B7C5A0B4F5003686161F0605B 1182 Generator = 2 1184 [1536 bits] 1185 Modulus (base 16) = 1186 9DEF3CAFB939277AB1F12A8617A47BBBDBA51DF499AC4C80BEEEA9614B19CC4D 1187 5F4F5F556E27CBDE51C6A94BE4607A291558903BA0D0F84380B655BB9A22E8DC 1188 DF028A7CEC67F0D08134B1C8B97989149B609E0BE3BAB63D47548381DBC5B1FC 1189 764E3F4B53DD9DA1158BFD3E2B9C8CF56EDF019539349627DB2FD53D24B7C486 1190 65772E437D6C7F8CE442734AF7CCB7AE837C264AE3A9BEB87F8A2FE9B8B5292E 1191 5A021FFF5E91479E8CE7A28C2442C6F315180F93499A234DCF76E3FED135F9BB 1192 Generator = 2 1194 [2048 bits] 1195 Modulus (base 16) = 1196 AC6BDB41324A9A9BF166DE5E1389582FAF72B6651987EE07FC3192943DB56050 1197 A37329CBB4A099ED8193E0757767A13DD52312AB4B03310DCD7F48A9DA04FD50 1198 E8083969EDB767B0CF6095179A163AB3661A05FBD5FAAAE82918A9962F0B93B8 1199 55F97993EC975EEAA80D740ADBF4FF747359D041D5C33EA71D281E446B14773B 1200 CA97B43A23FB801676BD207A436C6481F1D2B9078717461A5B9D32E688F87748 1201 544523B524B0D57D5EA77A2775D2ECFA032CFBDBF52FB3786160279004E57AE6 1202 AF874E7303CE53299CCC041C7BC308D82A5698F3A8D0C38271AE35F8E9DBFBB6 1203 94B5C803D89F7AE435DE236D525F54759B65E372FCD68EF20FA7111F9E4AFF73 1204 Generator = 2 1206 Appendix B. Changes since the previous draft 1208 The underlying message digest algorithm for SRP calculations is now 1209 selected during an exchange between the server and client. Section 1210 4.2 and Section 4.3 have been amended to reflect this change. 1212 Changed "mechanisms" to "mechanism" in various places and fixed the 1213 mechanism name to "SRP." 1215 Removed "Mechanism Names" section, since it is no longer needed, and 1216 replaced with "Introduction." 1218 Changed the mechanism data exchanges in Section 4 so that the 1219 authorisation identity (I) is sent with the authentication identity 1220 (U). 1222 Added a new bullet point to Section 7.1 justifying the selection of 1223 SHA-160 as the MANDATORY Message Digest Algorithm for SRP 1224 calculations. 1226 Added a new paragraph to Section 8 giving Tom Wu's response to the 1227 SRP password-guessing attack pointed out by Robert Moskowitz. 1229 Added Ken Murchison to Section 9. 1231 Used "**" consistently as the symbol for the exponentiation operator. 1233 Re-ordered the references alphabetically. 1235 Full Copyright Statement 1237 Copyright (C) The Internet Society (2002). All Rights Reserved. 1239 This document and translations of it may be copied and furnished to 1240 others, and derivative works that comment on or otherwise explain it 1241 or assist in its implementation may be prepared, copied, published 1242 and distributed, in whole or in part, without restriction of any 1243 kind, provided that the above copyright notice and this paragraph 1244 are included on all such copies and derivative works. However, this 1245 document itself may not be modified in any way, such as by removing 1246 the copyright notice or references to the Internet Society or other 1247 Internet organizations, except as needed for the purpose of 1248 developing Internet standards in which case the procedures for 1249 copyrights defined in the Internet Standards process must be 1250 followed, or as required to translate it into languages other than 1251 English. 1253 The limited permissions granted above are perpetual and will not be 1254 revoked by the Internet Society or its successors or assigns. 1256 This document and the information contained herein is provided on an 1257 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1258 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1259 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1260 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1261 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1263 Acknowledgement 1265 Funding for the RFC editor function is currently provided by the 1266 Internet Society.