idnits 2.17.1 draft-burdis-cat-srp-sasl-07.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. 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 (August 12, 2002) is 7928 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 142 -- Looks like a reference, but probably isn't: '1' on line 142 -- Looks like a reference, but probably isn't: '2' on line 142 -- Looks like a reference, but probably isn't: '3' on line 142 == Unused Reference: 'RFC-2629' is defined on line 1223, 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. 'SASL' -- Possible downref: Non-RFC (?) normative reference: ref. 'SCAN' -- Possible downref: Non-RFC (?) normative reference: ref. 'SRP' -- Possible downref: Non-RFC (?) normative reference: ref. 'SRP-impl' -- Possible downref: Non-RFC (?) normative reference: ref. 'UMAC' -- Possible downref: Non-RFC (?) normative reference: ref. 'UNICODE-KC' Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 19 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network K. Burdis 3 Internet-Draft Rhodes University 4 Expires: February 10, 2003 R. Naffah 5 Forge Research 6 August 12, 2002 8 Secure Remote Password SASL Mechanism 9 draft-burdis-cat-srp-sasl-07 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 Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 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 http:// 27 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 February 10, 2003. 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 and 42 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 . . . . . . . . . . . 12 62 4.5 Client sends its evidence . . . . . . . . . . . . . . . . . 12 63 4.6 Server sends its evidence . . . . . . . . . . . . . . . . . 13 64 5. Security Layer . . . . . . . . . . . . . . . . . . . . . . . 15 65 5.1 Cryptographic primitives . . . . . . . . . . . . . . . . . . 17 66 5.1.1 Pseudo random number generators . . . . . . . . . . . . . . 17 67 5.1.2 Key derivation function . . . . . . . . . . . . . . . . . . 18 68 5.2 Confidentiality Protection . . . . . . . . . . . . . . . . . 19 69 5.3 Replay Detection . . . . . . . . . . . . . . . . . . . . . . 20 70 5.4 Integrity Protection . . . . . . . . . . . . . . . . . . . . 21 71 5.5 Summary of Security Layer Output . . . . . . . . . . . . . . 21 72 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 23 73 7. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 26 74 7.1 Mandatory Algorithms . . . . . . . . . . . . . . . . . . . . 26 75 7.2 Modulus and generator values . . . . . . . . . . . . . . . . 26 76 7.3 Replay detection sequence number counters . . . . . . . . . 26 77 7.4 SASL Profile Considerations . . . . . . . . . . . . . . . . 27 78 8. Security Considerations . . . . . . . . . . . . . . . . . . 29 79 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 80 References . . . . . . . . . . . . . . . . . . . . . . . . . 31 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 33 82 A. Modulus and Generator values . . . . . . . . . . . . . . . . 34 83 B. Changes since the previous draft . . . . . . . . . . . . . . 36 84 Full Copyright Statement . . . . . . . . . . . . . . . . . . 38 86 1. Introduction 88 The Secure Remote Password (SRP) is a password-based, zero-knowledge, 89 authentication and key-exchange protocol developed by Thomas Wu. It 90 has good performance, is not plaintext-equivalent and maintains 91 perfect forward secrecy. It provides authentication (optionally 92 mutual authentication) and the negotiation of a session key [SRP]. 94 The mechanism described herein is based on the optimised SRP protocol 95 described at the end of section 3 in [RFC-2945], since this reduces 96 the total number of messages exchanged by grouping together pieces of 97 information that do not depend on earlier messages. Due to the 98 design of the mechanism, mutual authentication is MANDATORY. 100 The SASL mechanism name associated with this protocol is "SRP". 102 2. Conventions Used in this Document 104 o A hex digit is an element of the set: 106 {0, 1, 2, 3, 4, 5, 6, 7, 8 , 9, A, B, C, D, E, F} 108 A hex digit is the representation of a 4-bit string. Examples: 110 7 = 0111 112 A = 1010 114 o An octet is an 8-bit string. In this document an octet may be 115 written as a pair of hex digits. Examples: 117 7A = 01111010 119 02 = 00000010 121 o All data is encoded and sent in network byte order (big-endian). 123 o The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 124 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 125 in this document are to be interpreted as described in [RFC-2119]. 127 3. Data Element Formats 129 This section describes the encoding of the data elements used by the 130 SASL mechanism described in this document. 132 3.1 Scalar numbers 134 Scalar numbers are unsigned quantities. Using b[k] to refer to the 135 k-th octet being processed, the value of a two-octet scalar is: 137 ((b[0] << 8) + b[1]), 139 where << is the bit left-shift operator. The value of a four-octet 140 scalar is: 142 ((b[0] << 24) + (b[1] << 16) + (b[2] << 8) + b[3]). 144 3.2 Multi-Precision Integers 146 Multi-Precision Integers, or MPIs, are positive integers used to hold 147 large integers used in cryptographic computations. 149 MPIs are encoded using a scheme inspired by that used by OpenPGP - 150 [RFC-2440] (section 3.2) - for encoding such entities: 152 The encoded form of an MPI SHALL consist of two pieces: a two- 153 octet scalar that represents the length of the entity, in octets, 154 followed by a sequence of octets that contain the actual 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 value 162 1, while the sequence [00 02 01 FF] encodes an MPI with the 163 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 octet 186 sequence. Furthermore, we shall use the syntax bytes(s) to denote 187 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]. All text MUST be in Unicode 204 Normalization Form KC [UNICODE-KC] without NUL characters. 206 We shall use the syntax utf8(L) to denote the string L in UTF-8 207 encoding, preceded by a two-octet scalar quantity representing the 208 count of following octets. Furthermore, we shall use the syntax 209 bytes(L) to denote the sequence of octets representing the UTF-8 210 encoding of L, in big-endian order. 212 3.6 Buffers 214 In this SASL mechanism data is exchanged between the client and 215 server using buffers. A buffer acts as an envelope for the sequence 216 of data elements sent by one end-point of the exchange, and expected 217 by the other. 219 A buffer MAY NOT contain other buffers. It may only contain zero, 220 one or more data elements. 222 A buffer shall be encoded as two fields: a four-octet scalar quantity 223 representing the count of following octets, and the concatenation of 224 the octets of the data element(s) contained in the 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 of 232 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 request 256 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 ( no confidentiality protection ) 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 authorisation 304 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 comma- 316 separated list of option strings that specify the options the server 317 supports. This options list MUST NOT contain any whitespace 318 characters and all alphabetic characters MUST be in lowercase. When 319 used in digest calculations by the client the options list MUST be 320 used as received. 322 The following option strings are defined: 324 o "mda=" indicates that the server 325 supports the designated hash function as the underlying Message 326 Digest Algorithm for the designated user to be used for all SRP 327 calculations - to compute both client-side and server-side 328 digests. The specified algorithm MUST meet the requirements 329 specified in section 3.2 of [RFC-2945]: 331 "Any hash function used with SRP should produce an output of at 332 least 16 bytes and have the property that small changes in the 333 input cause significant nonlinear changes in the output." 335 Note that in the interests of interoperability between client and 336 server implementations and with other SRP-based tools, both the 337 client and the server MUST support SHA-160 as an underlying 338 Message Digest Algorithm. While the server is not required to 339 list SHA-160 as an available underlying Message Digest Algorithm, 340 it must be able to do so. 342 o "integrity=hmac-" indicates that the server supports 343 integrity protection using the HMAC algorithm [RFC-2104] with 344 as the underlying Message Digest Algorithm. Acceptable 345 MDA names are chosen from [SCAN] under the MessageDigest section. 346 A server SHOULD send such an option string for each HMAC algorithm 347 it supports. The server MUST advertise at least one integrity 348 protection algorithm and in the interest of interoperability the 349 server SHOULD advertise support for the HMAC-SHA-160 algorithm. 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 explicitly 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 supports 360 confidentiality protection using the symmetric key block cipher 361 algorithm . The server SHOULD send such an option 362 string for each confidentiality protection algorithm it supports. 363 Note that in the interest of interoperability, if the server 364 offers confidentiality protection, it MUST send the option string 365 "confidentiality=aes" since it is then MANDATORY for it to provide 366 support for the [AES] algorithm. 368 o "mandatory=[integrity|replay_detection|confidentiality]" is an 369 option only available to the server that indicates that the 370 specified security layer option is MANDATORY and MUST be chosen by 371 the client for use in the resulting security layer. If a server 372 specifies an option as mandatory in this way, it MUST abort the 373 connection if the specified option is not chosen by the client. 374 It doesn't make sense for the client to send this option since it 375 is only able to choose options that the server advertises. The 376 client SHOULD abort the connection if the server does not offer an 377 option that it requires. If this option is not specified then 378 this implies that no options are mandatory. The server SHOULD 379 always send the "mandatory=integrity" option indicating that 380 integrity protection is required. 382 o "maxbuffersize=" indicates to the peer the 383 maximum number of raw bytes (excluding the SASL buffer 4-byte 384 length header) to be processed by the security layer at a time, if 385 one is negotiated. The value of MUST NOT exceed 386 the Buffer size limit defined in section 3.7. If this option is 387 not detected by a client or server mechanism, then it shall 388 operate its security layer on the assumption that the maximum 389 number of bytes that may be sent, to the peer server or client 390 mechanism respectively, is the Buffer data size limit indicated in 391 section 3.7. On the other hand, if a recipient detects this 392 option, it shall break any octet-sequence longer than the 393 designated limit into two or more fragments, each wrapped in a 394 SASL buffer, before sending them, in sequence, to 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- 401 md5,replay_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 specifies 410 the Message Digest Algorithm(s) available to be used for all SRP 411 calculations, the security service options the server supports, and 412 the maximum buffer size the server can handle. The client selects 413 options from this list and creates a new options list o that 414 specifies the selected Message Digest Algorithm to be used for SRP 415 calculations and the security services that will be used in the 416 security layer. At most one available Message Digest Algorithm name, 417 one available integrity protection algorithm and one available 418 confidentiality protection algorithm may be selected. In addition 419 the client may specify the maximum buffer size it can handle. The 420 client MUST include any option specified by the mandatory option. 422 The client SHOULD always select an integrity protection algorithm 423 even if the server does not make it mandatory to do so. If the 424 client selects a confidentiality protection algorithm it SHOULD then 425 also select an integrity protection algorithm. 427 This options list MUST NOT contain any whitespace characters and all 428 alphabetic characters MUST be in lowercase. When used in digest 429 calculations by the server the options list MUST be used as received. 431 The client generates its ephemeral public key A as follows: 433 a = prng(); 435 A = g**a % N; 437 where: 439 prng() is a random number generation function, 440 a is the MPI that will act as the client's private key, 442 ** is the exponentiation operator, 444 % is the modulus operator, 446 The client sends: 448 { mpi(A) | utf8(o) } 450 4.4 Server sends its ephemeral public key 452 The server reads the client's verifier v, calculates the shared 453 context key K and generates its ephemeral public key B as follows: 455 b = prng(); 457 B = (v + g**b) % N; 459 K = H2((A * v**u) ** b % N); 461 where: 463 b is the MPI that will act as the server's private key, 465 v is the stored password verifier value, 467 u is a 32-bit unsigned integer which takes its value from the 468 first 32 bits of the hash of B, MSB first, 470 H2() is the "Interleaved SHA" function, as described in [RFC- 471 2945], but generalised to any message digest algorithm, and 472 applied using the underlying Message Digest Algorithm (see Section 473 4.2). 475 The server sends: 477 { mpi(B) } 479 4.5 Client sends its evidence 481 The client calculates the shared context key K, and calculates the 482 evidence M1 that proves to the server that it knows the shared 483 context key K, including I and L as part of the calculation. 485 K, on the client's side is computed as follows: 487 x = H(s | H(U | ":" | p)); 489 K = H2((B - g**x) ** (a + u * x) % N); 491 where: 493 H() is the result of digesting the designated input/data with the 494 underlying Message Digest Algorithm function (see Section 4.2). 496 p is the password value. 498 M1 is computed as: 500 H( bytes(H( bytes(N) )) ^ bytes( H( bytes(g) )) 501 | bytes(H( bytes(U) )) 502 | bytes(s) 503 | bytes(A) 504 | bytes(B) 505 | bytes(K) 506 | bytes(H( bytes(I) ) 507 | bytes(H( bytes(L) )) 508 ) 510 where: 512 ^ is the bitwise XOR operator. 514 All parameters received from the server that are used as input to a 515 digest operation MUST be used as received. 517 The client sends: 519 { os(M1) } 521 4.6 Server sends its evidence 523 When the Confidentiality Protection service is advertised by the 524 server and chosen by the client, the server MUST NOT send M2 but 525 instead conclude the SASL exchange after receiving and verifying the 526 client's M1. Otherwise, M2 MUST be sent. 528 When the server has to send its evidence M2, which proves to the 529 client that it knows the shared context key K, as well as U, I and o, 530 it shall compute it as follows: 532 H( bytes(A) 533 | bytes(M1) 534 | bytes(K) 535 | bytes(H( bytes(U) )) 536 | bytes(H( bytes(I) )) 537 | bytes(H( bytes(o) )) 538 ) 540 All parameters received from the client that are used as input to a 541 digest operation MUST be used as received. 543 If Confidentiality Protection was not negotiated the server sends: 545 { os(M2) } 547 5. Security Layer 549 Section 3 of [RFC-2222] describes the operation of the security 550 layer: 552 "The security layer takes effect immediately following the last 553 response of the authentication exchange for data sent by the 554 client and the completion indication for data sent by the server. 555 Once the security layer is in effect, the protocol stream is 556 processed by the security layer into buffers of cipher-text. Each 557 buffer is transferred over the connection as a stream of octets 558 prepended with a four octet field in network byte order that 559 represents the length of the following buffer. The length of the 560 cipher-text buffer must be no larger than the maximum size that 561 was defined or negotiated by the other side." 563 Depending on the options offered by the server and chosen by the 564 client, the security layer may provide integrity protection, replay 565 detection, and/or confidentiality protection. 567 The security layer can be thought of as a three-stage filter through 568 which the data flows from the output of one stage to the input of the 569 following one. The first input is the original data, while the last 570 output is the data after being subject to the transformations of this 571 filter. 573 The data always passes through this three-stage filter, though any of 574 the stages may be inactive. Only when a stage is active would the 575 output be different from the input. In other words, if a stage is 576 inactive, the octet sequence at the output side is an exact duplicate 577 of the same sequence at the input side. 579 Schematically, the three-stage filter security layer appears as 580 follows: 582 +----------------------------+ 583 | | I/ p1 584 p1 --->| Confidentiality protection |---+ 585 | | | A/ c 586 +----------------------------+ | 587 | 588 +------------------------------------+ 589 | 590 | +----------------------------+ 591 | | | I/ p2 592 p2 +-->| Replay detection |---+ 593 | | | A/ p2 | q 594 +----------------------------+ | 595 | 596 +------------------------------------+ 597 | 598 | +----------------------------+ 599 | | | I/ p3 600 p3 +-->| Integrity protection |---> 601 | | A/ p3 | C 602 +----------------------------+ 604 where: 606 p1, p2 and p3 are the input octet sequences at each stage, 608 I/ denotes the output at the end of one stage if/when the stage is 609 inactive or disabled, 611 A/ denotes the output at the end of one stage if/when the stage is 612 active or enabled, 614 c is the encrypted (sender-side) or decrypted (receiver-side) 615 octet sequence. c1 shall denote the value computed by the sender, 616 while c2 shall denote the value computed by the receiver. 618 q is a four-octet scalar quantity representing a sequence number, 620 C is the Message Authentication Code. C1 shall denote the value 621 of the MAC as computed by the sender, while C2 shall denote the 622 value computed by the receiver. 624 It is worth noting here that both client and server have their own 625 distinct security contexts, including distinct encryption and 626 decryption sub-contexts. In principal, nothing in this specification 627 should prevent an implementation from supporting asynchronous 628 connections. 630 5.1 Cryptographic primitives 632 5.1.1 Pseudo random number generators 634 This mechanism requires random data to be generated for use in: 636 1. The CALG key material and the cipher initial vectors (IVs) for 637 both the client and server when the Confidentiality Protection 638 service is enabled. 640 2. The IALG key material for both the client and server when the 641 Integrity Protection service is enabled. 643 The PRNG used in this specification is based on the "UMacGenerator" 644 algorithm described in [UMAC]. It uses the [AES] algorithm, in its 645 256-bit key size variant, as the underlying symmetric key block 646 cipher for its operations. 648 A formal description of this PRNG follows: 650 o Initialisation 652 * SK: a 32-octet sequence (seeding key to AES) 654 o Input 656 * n: a positive integer 658 o Output 660 * Y: an n-octet sequence 662 o Algorithm 664 * (initialisation) 666 1. Initialise an AES instance for encryption with the first 32 667 octets of SK as its user-supplied key material. Let "aes" 668 be that instance; i.e. aes = AES(SK, ENCRYPTION); 670 2. Initialise T to be an all-zero 16-octet long sequence; 672 * (for every input) 674 1. Initialise "remaining" to n; 676 2. Initialise Y to be a 0-length octet sequence; 677 3. while (remaining > 0) do 679 1. T = aes(T); 681 2. Append m octets from T to Y, where m is the minimum of 682 16 and remaining; 684 3. Subtract 16 from remaining; 686 4. return Y; 688 In the rest of this document, "PRNG" will refer to this algorithm 689 with the initialisation parameter SK set to be the shared context key 690 K computed by the SRP calculations (see Section 4.4 and Section 4.5). 692 This algorithm MAY also be used as part of the SRP calculations to 693 generate the required "a" and "b" parameters used in creating the 694 client and server ephemeral private keys ("A" and "B"). In this case 695 the initialisation parameter SK can be any 32-octet sequence (e.g. 696 multiple representations of the time-of-day). 698 If the same PRNG instance is used for both the SRP calculations and 699 the calculations in this specification, it MUST be re-initialised 700 with the shared context key K before any of the latter calculations 701 are performed. 703 5.1.2 Key derivation function 705 During the authentication phase, both parties compute the shared 706 context key K (see Section 4.4 for the server, and Section 4.5 for 707 the client sides respectively). The length of K is 2*s bits, where 708 "s" is the output length of the underlying Message Digest Algorithm 709 used in the SRP calculations (see "mda" option in Section 4.2). 711 When Confidentiality Protection is required, and the length of K is 712 not equal to the length of the user-supplied key material needed to 713 initialise the chosen Confidentiality Algorithm (CALG), the peers 714 MUST apply the Key Derivation Function (KDF) in order to obtain 715 enough data for this purpose. 717 Similarly, when Integrity Protection is required, and the length of K 718 is not equal to the required length of the key material needed to 719 initialise the chosen Integrity Algorithm (IALG), the peers MUST 720 apply the Key Derivation Function (KDF) in order to obtain enough 721 data for this purpose too. 723 We define this KDF as: 725 Km = KDF(K, n) 727 where: 729 Km: is the required key material, 731 K: is the shared context key, and 733 n: is the required length of Km. 735 The following steps describe the KDF algorithm: 737 If length of K is greater than or equal to n, then 739 Let Km be the first n bytes of K; 741 Else 743 Let Km = PRNG(n); 745 return Km 747 5.2 Confidentiality Protection 749 The plaintext data octet sequence p1 is encrypted using the chosen 750 confidentiality algorithm (CALG) initialised for encryption with the 751 key material Km obtained by applying the KDF to K (the shared context 752 key K), and m (the key size of the chosen CALG) - see Section 5.1.2. 754 Km = KDF(K, m) 756 c1 = CALG(Km, ENCRYPTION)( bytes(p1) ) 758 On the receiving side, the ciphertext data octet sequence p1 is 759 decrypted using the chosen confidentiality algorithm (CALG) 760 initialised for decryption, with the key Km obtained by a similar 761 process. 763 Km = KDF(K, m) 765 c2 = CALG(Km, DECRYPTION)( bytes(p1) ) 767 The designated CALG block cipher MUST be used in OFB (Output Feedback 768 Block) mode in the ISO variant, as described in [HAC], algorithm 769 7.20. 771 Let k be the block size of the chosen symmetric key block cipher 772 algorithm; e.g. for AES this is 128 bits or 16 octets. The OFB mode 773 used shall have a block size of k. 775 It is recommended that Block ciphers operating in OFB mode be used 776 with an Initial Vector (the mode's IV). In such a mode of operation 777 - OFB with key re-use - the IV need not be secret. For the SASL 778 mechanism described in this document, the IVs shall be: 780 IV = PRNG(n); 782 where n is the block size of the negotiated CALG. 784 The input data to the confidentiality protection algorithm shall be a 785 multiple of the symmetric key block cipher block size k. When the 786 input length is not a multiple of k octets, the data shall be padded 787 according to the following scheme (described in [PKCS7] which itself 788 is based on [RFC-1423]): 790 Assuming the length of the input is l octets, (k - (l mod k)) 791 octets, all having the value (k - (l mod k)), shall be appended to 792 the original data. In other words, the input is padded at the 793 trailing end with one of the following sequences: 795 01 -- if l mod k = k-1 796 02 02 -- if l mod k = k-2 797 ... 798 ... 799 ... 800 k k ... k k -- if l mod k = 0 802 The padding can be removed unambiguously since all input is padded 803 and no padding sequence is a suffix of another. This padding 804 method is well-defined if and only if k < 256 octets, which is the 805 case with symmetric block ciphers today, and in the forseeable 806 future. 808 The output of this stage, when it is active, is: 810 at the sending side: CALG(Km, ENCRYPT)( bytes(p1) ) 812 at the receiving side: CALG(Km, DECRYPT)( bytes(p1) ) 814 5.3 Replay Detection 816 A sequence number q is incremented every time a message is sent to 817 the peer. 819 The output of this stage, when it is active, is: 821 p2 | q 823 At the other end, the receiver increments its instance of the 824 sequence number. This new value of the sequence number is then used 825 in the integrity protection transformation, which must also be active 826 as described in Section 4.2. See Section 7.3 for more details. 828 5.4 Integrity Protection 830 When the Integrity Protection stage is active, a message 831 authentication code C is computed using the chosen integrity 832 protection algorithm (IALG) as follows: 834 o the IALG is initialised (once) with the key material Kn obtained 835 by applying the KDF to K (the shared context key K), and n (the 836 required key size of the chosen IALG) - see Section 5.1.2; i.e. 837 Kn = KDF(K, n), 839 o the IALG is updated with every exchange of the sequence p3, 840 yielding the value C and a new IALG context for use in the 841 following exchange. 843 At the other end, the receiver computes its version of C, using the 844 same transformation, and checks that its value is equal to that 845 received. If the two values do not agree, the receiver MUST signal 846 an exception and abort. 848 The output of this stage, when it is active, is then: 850 IALG(Kn)( bytes(p3) ) 852 5.5 Summary of Security Layer Output 854 The following table shows the data exchanged by the security layer 855 peers, depending on the possible legal combinations of the three 856 security services in operation: 858 CP IP RD Peer sends/receives 860 I I I { eos(p) } 861 I A I { eos(p) | os( IALG(K)( bytes(p) ) ) } 862 I A A { eos(p) | os( IALG(K)( bytes(p) | bytes(q)) ) } 863 A I I { eos(c) } 864 A A I { eos(c) | os( IALG(K)( bytes(c) ) ) } 865 A A A { eos(c) | os( IALG(K)((bytes(c) | bytes(q)) ) } 867 where 869 CP Confidentiality protection, 871 IP Integrity protection, 873 RD Replay detection, 875 I Security service is Inactive/disabled, 877 A Security service is Active/enabled, 879 p The original plaintext, 881 q The sequence number. 883 c The enciphered input obtained by either: 885 CALG(Km, ENCRYPT)( bytes(p) ) at the sender's side, or 887 CALG(Km, DECRYPT)( bytes(p) ) at the receiver's side 889 6. Example 891 The example below uses SMTP authentication [RFC-2554]. The base64 892 encoding of challenges and responses, as well as the reply codes 893 preceding the responses are part of the SMTP authentication 894 specification, not part of this SASL mechanism itself. 896 "C:" and "S:" indicate lines sent by the client and server 897 respectively. 899 S: 220 smtp.example.com ESMTP server ready 901 C: EHLO zaau.example.com 903 S: 250-smtp.example.com 904 S: 250 AUTH SRP CRAM-MD5 DIGEST-MD5 906 C: AUTH SRP AAAADAAEdGVzdAAEdGVzdA== 908 with: 910 U = "test" 912 I = "test" 914 S: 334 AAABygEArGvbQTJKmpvxZt5eE4lYL69ytmUZh+4H/DGSlD21YFCjcynLtKCZ 915 7YGT4HV3Z6E91SMSq0sDMQ3Nf0ip2gT9UOgIOWntt2ewz2CVF5oWOrNmGgX71fqq6Ck 916 YqZYvC5O4Vfl5k+yXXuqoDXQK2/T/dHNZ0EHVwz6nHSgeRGsUdzvKl7Q6I/uAFna9IH 917 pDbGSB8dK5B4cXRhpbnTLmiPh3SFRFI7UksNV9Xqd6J3XS7PoDLPvb9S+zeGFgJ5AE5 918 Xrmr4dOcwPOUymczAQce8MI2CpWmPOo0MOCca41+Onb+7aUtcgD2J965DXeI21SX1R1 919 m2XjcvzWjvIPpxEfnkr/cwABAgqsi3AvmIqdEbREALhtZGE9U0hBLTEsbWFuZGF0b3J 920 5PXJlcGxheSBkZXRlY3Rpb24scmVwbGF5IGRldGVjdGlvbixpbnRlZ3JpdHk9aG1hYy 921 1zaGExLGludGVncml0eT1obWFjLW1kNSxjb25maWRlbnRpYWxpdHk9YWVzLGNvbmZpZ 922 GVudGlhbGl0eT1jYXN0NSxjb25maWRlbnRpYWxpdHk9Ymxvd2Zpc2gsbWF4YnVmZmVy 923 c2l6ZT0yMTQ3NDgzNjQz 925 with: 927 N = "21766174458617435773191008891802753781907668374255538511144 928 6432246898862353838409572109090130860564015713997172358072665816 929 4960647214841029141336415219736447718088739565548373811507267740 930 2235101762521901569820740293149529620419333266262073471054548368 931 7360395197024862265062488610602569718029849535611214426801576680 932 0076142998822245709041387397397017192709399211475176516806361476 933 1119615476233422096442783117971236371647333871414335895773474667 934 3089670508070055093204247996784170368679283167612722742303140675 935 4829113358247958306143957755934710196177140617368437852270348349 936 5337037655006751328447510550299250924469288819" 938 g = "2" 940 s = "814819216327401865851972" 942 L = "mda=sha-1,mandatory=replay_detection,replay_detection,integ 943 rity=hmac-sha1,integrity=hmac-md5,confidentiality=aes,confidenti 944 ality=cast5,confidentiality=blowfish,maxbuffersize=2147483643" 946 C: AAABYwEAAp5q/4zhXoTUzXBscozN97SWgfDcAImIk3lNHNvd0b+Dr7jEm6upXblZ 947 T5sL9mPgFsejlIh+B/eCu/HvzWCrXj6ylPZv8dy3LCH3LIORqQ45S7Lsbmrrg/dukDh 948 4tZCJMLD4r3evzaY8KVhtJeLMVbeXuh4JljKP42Ll59Lzwf8jfPh4+4Lae1rpWUCL9D 949 ueKcY+nN+xNHTit/ynLATxwL93P6+GoGY4TkUbUBfjiI1+rAMvyMDMw5XozGy07FOEc 950 ++U0iPeXCQP4MT5FipOUoz8CYX7J1LbaXp2WJuFHlkyVXF7oCoyHbhld/5CfR3o6q/B 951 /x9+yZRqaHH+JfllOgBfbWRhPVNIQS0xLHJlcGxheSBkZXRlY3Rpb24saW50ZWdyaXR 952 5PWhtYWMtbWQ1LGNvbmZpZGVudGlhbGl0eT1ibG93ZmlzaCxtYXhidWZmZXJzaXplPT 953 IxNDc0ODM2NDM= 955 with: 957 A = "33059541846712102497463123211304342021934496372587869281515 958 9695658237779884462777478850394977744553746930451895815615888405 959 0562780707370878253753979367019077142882237029766166623275718227 960 6555389834190840322081091599089081947324537907613924707058150037 961 7802790776231793962143786411792516760030102436603621046541729396 962 6890613394379900527412007068242559299422872893332111365840536495 963 1858834742328835373387573188369956379881606380890675411966073665 964 1106922002294035533470301541999274557200666703389531481794516625 965 4757418442215980634933876533189969562613241499465295849832999091 966 40398081321840949606581251320320995783959866" 968 o = mda=sha-1,replay_detection,integrity=hmac-md5,confidentialit 969 y=blowfish,maxbuffersize=2147483643" 971 S: 334 AAABAgEAOUKbXpnzMhziivGgMwm+FS8sKGSvjh5M3D+80RF/5z9rm0oPoi4+ 972 pF83fueWn4Hz9M+muF/22PHHZkHtlutDrtapj4OtirdxC21fS9bMtEh3F0whTX+3mPv 973 thw5sk11turandHiLvcUZOgcrAGIoDKcBPoGyBud+8bMgpkf/uGfyBM2nEX/hV+oGgg 974 X+LiHjmkxAJ3kewfQPH0eV9ffEuuyu8BUcBXkJsS6l7eWkuERSCttVOi/jS031c+CD/ 975 nuecUXYiF8IYzW03rbcwYhZzifmTi3VK9C8zG2K1WmGU+cDKlZMkyCPMmtCsxlbgE8z 976 SHCuCiOgQ35XhcA0Qa0C3Q== 978 with: 980 B: "722842847565031844205403087285424428589273458129750231766015 981 4465607827529853239240118185263492617243523916106658696965596526 982 8585300845435562962039149169549800169184521786717633959469278439 983 8771344445002432579509292115598435685062882631760796416554562980 984 8475896198325835507901319556929511421472132184990365213059654962 985 7218189966140113906545856088040473723048909402258929560823932725 986 2022154114087913895411927676707073040281136096806681758265221209 987 8822374723416364340410020172215773934302794679034424699999611678 988 9730443114919539575466941344964841591072763617954717789621871251 989 71089179399349194452686682517183909017223901" 991 C: AAAAFRTkoju6xGP+zH89iaDWIFjfIKt5Kg== 993 S: 235 Authentication successful. 995 7. Discussion 997 7.1 Mandatory Algorithms 999 The algorithms specified as mandatory were chosen for utility and 1000 availablity. We felt that a mandatory confidentiality and integrity 1001 protection algorithm for the security layer and a mandatory Message 1002 Digest Algorithm for SRP calculations should be specified to ensure 1003 interoperability between implementations of this mechanism: 1005 o The SHA-160 Message Digest Algorithm was chosen as an underlying 1006 algorithm for SRP calculations because this allows for easy 1007 interoperability with other SRP-based tools that use the SRP-SHA1 1008 protocol described in section 3 of [RFC-2945] and create their 1009 password files using this algorithm. 1011 o The HMAC algorithm was chosen as an integrity algorithm because it 1012 is faster than MAC algorithms based on secret key encryption 1013 algorithms [RFC-2847]. 1015 o AES was chosen as a cipher because it has undergone thorough 1016 scrutiny by the best cryptographers in the world. 1018 Since confidentiality protection is optional, this mechanism should 1019 be usable in countries that have strict controls on the use of 1020 cryptography. 1022 7.2 Modulus and generator values 1024 It is RECOMMENDED that the server use values for the modulus (N) and 1025 generator (g) chosen from those listed in Appendix A so that the 1026 client can avoid expensive constraint checks, since these predefined 1027 values already meet the constraints described in [RFC-2945]: 1029 "For maximum security, N should be a safe prime (i.e. a number of 1030 the form N = 2q + 1, where q is also prime). Also, g should be a 1031 generator modulo N (see [SRP] for details), which means that for 1032 any X where 0 < X < N, there exists a value x for which g**x % N 1033 == X." 1035 7.3 Replay detection sequence number counters 1037 The mechanism described in this document allows the use of a Replay 1038 Detection security service that works by including sequence number 1039 counters in the message authentication code (MAC) created by the 1040 Integrity Protection service. As noted in Section 4.2 integrity 1041 protection is always activated when the Replay Detection service is 1042 activated. 1044 Both the client and the server keep two sequence number counters. 1045 Each of these counters is a 32-bit unsigned integer initialised with 1046 a Starting Value and incremented by an Increment Value with every 1047 successful transmission of an SASL buffer through the security layer. 1048 The Sent counter is incremented for each buffer sent through the 1049 security layer. The Received counter is incremented for each buffer 1050 received through the security layer. If the value of a sequence 1051 number counter exceeds 2**32-1 it wraps around and starts from zero 1052 again. 1054 When a sender sends a buffer it includes the value of its Sent 1055 counter in the computation of the MAC accompanying each integrity 1056 protected message. When a recipient receives a buffer it uses the 1057 value of it's Received counter in its computation of the integrity 1058 protection MAC for the received message. The recipient's Received 1059 counter must be the same as the sender's Sent counter in order for 1060 the received and computed MACs to match. 1062 This specification assumes that for each sequence number counter the 1063 Starting Value is ZERO, and that the Increment Value is ONE. These 1064 values do not affect the security or the intended objective of the 1065 replay detection service, since they never travel on the wire. 1067 7.4 SASL Profile Considerations 1069 As mentioned briefly in [RFC-2222], and detailed in [SASL] a SASL 1070 specification has three layers: (a) a protocol definition using SASL 1071 known as the "Profile", (b) a SASL mechanism definition, and (c) the 1072 SASL framework. 1074 Point (3) in section 5 of [SASL] ("Protocol profile requirements") 1075 clearly states that it is the responsibility of the Profile to define 1076 "...how the challenges and responses are encoded, how the server 1077 indicates completion or failure of the exchange, how the client 1078 aborts an exchange, and how the exchange method interacts with any 1079 line length limits in the protocol." 1081 The username entity, referenced as "U" throughout this document, and 1082 used by the server to locate the password data, is assumed to travel 1083 "in the clear," meaning that no transformation is applied to its 1084 contents. This assumption was made to allow the same SRP password 1085 files to be used in this mechanism, as those used with other SRP 1086 applications and tools. 1088 A Profile may decide, for privacy or other reason, to disallow such 1089 information to travel in the clear, and instead use a hashed version 1090 of U, or more generally a transformation function applied to U; i.e. 1091 f(U). Such a Profile would require additional tools to add the 1092 required entries to the SRP password files for the new value(s) of 1093 f(U). It is worth noting too that if this is the case, and the same 1094 user shall access the server through this mechanism as well as 1095 through other SRP tools, then at least two entries, one with U and 1096 the other with f(U) need to be present in the SRP password files if 1097 those same files are to be used for both types of access. 1099 8. Security Considerations 1101 This mechanism relies on the security of SRP, which bases its 1102 security on the difficulty of solving the Diffie-Hellman problem in 1103 the multiplicative field modulo a large safe prime. See section 4 1104 "Security Considerations" of [RFC-2945] and section 4 "Security 1105 analysis" of [SRP]. 1107 B, the server's ephemeral public key, is computed as g**b + v = g**b 1108 + g**x, which is symmetric and allows two guesses per *active 1109 attack*. In practical terms, this makes no difference to the 1110 security of SRP, since the number of active attacks needed is still 1111 linearly proportional to the number of guesses needed; only the 1112 constant factor (2 vs. 1) has changed. 1114 This mechanism also relies on the security of the HMAC algorithm and 1115 the underlying hash function when integrity protection is used. 1116 Section 6 "Security" of [RFC-2104] discusses these security issues in 1117 detail. Weaknesses found in MD5 do not impact HMAC-MD5 [DOBBERTIN]. 1119 U, A, I and o, sent from the client to the server, and N, g, L, s and 1120 B, sent from the server to the client could be modified by an 1121 attacker before reaching the other party. For this reason, these 1122 values are included in the respective calculations of evidence (M1 1123 and M2) to prove that each party knows the session key K. This 1124 allows each party to verify that these values were received 1125 unmodified. 1127 The use of integrity protection is RECOMMENDED to detect message 1128 tampering and to avoid session hijacking after authentication has 1129 taken place. 1131 Replay attacks may be avoided through the use of sequence numbers, 1132 because sequence numbers make each integrity protected message 1133 exchanged during a session different, and each session uses a 1134 different key. 1136 Research [KRAWCZYK] shows that the order and way of combining message 1137 encryption (Confidentiality Protection) and message authentication 1138 (Integrity Protection) are important. This mechanism follows the EtA 1139 (encrypt-then-authenticate) method and is "generically secure." 1141 This mechanism uses a Pseudo-Random Number Generator (PRNG) for 1142 generating some of its parameters. Section 5.1.1 describes a 1143 securely seeded, cryptographically strong PRNG implementation for 1144 this purpose. 1146 9. Acknowledgements 1148 The following people provided valuable feedback in the preparation of 1149 this document: 1151 Stephen Farrell 1153 Timothy Martin 1155 Alexey Melnikov 1157 Ken Murchison 1159 Magnus Nystrom 1161 Thomas Wu 1163 References 1165 [AES] National Institute of Standards and Technology, 1166 "Rijndael: NIST's Selection for the AES", December 1167 2000, . 1170 [DOBBERTIN] Dobbertin, H., "The Status of MD5 After a Recent 1171 Attack", December 1996, . 1174 [HAC] Menezes, A., van Oorschot, P. and S. Vanstone, 1175 "Handbook of Applied Cryptography", CRC Press, Inc., 1176 ISBN 0-8493-8523-7, 1997, . 1179 [ISO-10646] "International Standard --Information technology-- 1180 Universal Multiple-Octet Coded Character Set (UCS) -- 1181 Part 1 Architecture and Basic Multilingual Plane. UTF-8 1182 is described in Annex R, adopted but not yet published. 1183 UTF-16 is described in Annex Q, adopted but not yet 1184 published.", ISO/IEC 10646-1, 1993. 1186 [KRAWCZYK] Krawczyk, H., "The order of encryption and 1187 authentication for protecting communications (Or: how 1188 secure is SSL?)", June 2001, . 1191 [PKCS7] RSA Data Security, Inc., "PKCS #7: Cryptographic 1192 Message Syntax Standard", Version 1.5, November 1993, 1193 . 1195 [RFC-1423] Balenson, D., "Privacy Enhancement for Internet 1196 Electronic Mail: Part III: Algorithms, Modes, and 1197 Identifiers", RFC 1423, February 1993, . 1200 [RFC-2104] Krawczyk, H., "HMAC: Keyed-Hashing for Message 1201 Authentication", RFC 2104, February 1997, . 1204 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 1205 Requirement Levels", BCP 0014, RFC 2119, March 1997, 1206 . 1208 [RFC-2222] Myers, J., "Simple Authentication and Security Layer 1209 (SASL)", RFC 2222, October 1997, . 1212 [RFC-2279] Yergeau, F., "UTF-8, a transformation format of Unicode 1213 and ISO 10646", RFC 2279, January 1998, . 1216 [RFC-2440] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, 1217 "OpenPGP Message Format", RFC 2440, November 1998, 1218 . 1220 [RFC-2554] Myers, J., "SMTP Service Extension for Authentication", 1221 RFC 2554, March 1999. 1223 [RFC-2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 1224 June 1999, . 1226 [RFC-2847] Eisler, M., "LIPKEY - A Low Infrastructure Public Key 1227 Mechanism Using SPKM", RFC 2847, June 2000, . 1230 [RFC-2945] Wu, T., "The SRP Authentication and Key Exchange 1231 System", RFC 2945, September 2000, . 1234 [SASL] Myers, J., "Simple Authentication and Security Layer 1235 (SASL)", April 2001, . 1238 [SCAN] Hopwood, D., "Standard Cryptographic Algorithm Naming", 1239 June 2000, . 1242 [SRP] Wu, T., "The Secure Remote Password Protocol", March 1243 1998, . 1245 [SRP-impl] Wu, T., "SRP: The Open Source Password Authentication 1246 Standard", March 1998, . 1248 [UMAC] Krovetz, T., Black, J., Halevi, S., Hevia, A., 1249 Krawczyk, H. and P. Rogaway, "UMAC: Message 1250 Authentication Code using Universal Hashing", October 1251 2000, . 1254 [UNICODE-KC] Durst, D., "Unicode Standard Annex #15: Unicode 1255 Normalization Forms.", March 2001, . 1258 Authors' Addresses 1260 Keith Burdis 1261 Rhodes University 1262 Computer Science Department 1263 Grahamstown 6139 1264 ZA 1266 EMail: keith@rucus.ru.ac.za 1268 Raif S. Naffah 1269 Forge Research Pty. Limited 1270 Suite 116, Bay 9 1271 Locomotive Workshop, 1272 Australian Technology Park 1273 Cornwallis Street 1274 Eveleigh, NSW 1430 1275 AU 1277 EMail: raif@forge.com.au 1279 Appendix A. Modulus and Generator values 1281 Modulus (N) and generator (g) values for various modulus lengths are 1282 given below. In each case the modulus is a large safe prime and the 1283 generator is a primitve root of GF(n) [RFC-2945]. These values are 1284 taken from software developed by Tom Wu and Eugene Jhong for the 1285 Stanford SRP distribution [SRP-impl]. 1287 [264 bits] 1288 Modulus (base 16) = 1289 115B8B692E0E045692CF280B436735C77A5A9E8A9E7ED56C965F87DB5B2A2 1290 ECE3 1291 Generator = 2 1293 [384 bits] 1294 Modulus (base 16) = 1295 8025363296FB943FCE54BE717E0E2958A02A9672EF561953B2BAA3BAACC3E 1296 D5754EB764C7AB7184578C57D5949CCB41B 1297 Generator = 2 1299 [512 bits] 1300 Modulus (base 16) = 1301 D4C7F8A2B32C11B8FBA9581EC4BA4F1B04215642EF7355E37C0FC0443EF75 1302 6EA2C6B8EEB755A1C723027663CAA265EF785B8FF6A9B35227A52D86633DB 1303 DFCA43 1304 Generator = 2 1306 [640 bits] 1307 Modulus (base 16) = 1308 C94D67EB5B1A2346E8AB422FC6A0EDAEDA8C7F894C9EEEC42F9ED250FD7F0 1309 046E5AF2CF73D6B2FA26BB08033DA4DE322E144E7A8E9B12A0E4637F6371F 1310 34A2071C4B3836CBEEAB15034460FAA7ADF483 1311 Generator = 2 1313 [768 bits] 1314 Modulus (base 16) = 1315 B344C7C4F8C495031BB4E04FF8F84EE95008163940B9558276744D91F7CC9 1316 F402653BE7147F00F576B93754BCDDF71B636F2099E6FFF90E79575F3D0DE 1317 694AFF737D9BE9713CEF8D837ADA6380B1093E94B6A529A8C6C2BE33E0867 1318 C60C3262B 1319 Generator = 2 1321 [1024 bits] 1322 Modulus (base 16) = 1323 EEAF0AB9ADB38DD69C33F80AFA8FC5E86072618775FF3C0B9EA2314C9C256 1324 576D674DF7496EA81D3383B4813D692C6E0E0D5D8E250B98BE48E495C1D60 1325 89DAD15DC7D7B46154D6B6CE8EF4AD69B15D4982559B297BCF1885C529F56 1326 6660E57EC68EDBC3C05726CC02FD4CBF4976EAA9AFD5138FE8376435B9FC6 1327 1D2FC0EB06E3 1328 Generator = 2 1330 [1280 bits] 1331 Modulus (base 16) = 1332 D77946826E811914B39401D56A0A7843A8E7575D738C672A090AB1187D690 1333 DC43872FC06A7B6A43F3B95BEAEC7DF04B9D242EBDC481111283216CE816E 1334 004B786C5FCE856780D41837D95AD787A50BBE90BD3A9C98AC0F5FC0DE744 1335 B1CDE1891690894BC1F65E00DE15B4B2AA6D87100C9ECC2527E45EB849DEB 1336 14BB2049B163EA04187FD27C1BD9C7958CD40CE7067A9C024F9B7C5A0B4F5 1337 003686161F0605B 1338 Generator = 2 1340 [1536 bits] 1341 Modulus (base 16) = 1342 9DEF3CAFB939277AB1F12A8617A47BBBDBA51DF499AC4C80BEEEA9614B19C 1343 C4D5F4F5F556E27CBDE51C6A94BE4607A291558903BA0D0F84380B655BB9A 1344 22E8DCDF028A7CEC67F0D08134B1C8B97989149B609E0BE3BAB63D4754838 1345 1DBC5B1FC764E3F4B53DD9DA1158BFD3E2B9C8CF56EDF019539349627DB2F 1346 D53D24B7C48665772E437D6C7F8CE442734AF7CCB7AE837C264AE3A9BEB87 1347 F8A2FE9B8B5292E5A021FFF5E91479E8CE7A28C2442C6F315180F93499A23 1348 4DCF76E3FED135F9BB 1349 Generator = 2 1351 [2048 bits] 1352 Modulus (base 16) = 1353 AC6BDB41324A9A9BF166DE5E1389582FAF72B6651987EE07FC3192943DB56 1354 050A37329CBB4A099ED8193E0757767A13DD52312AB4B03310DCD7F48A9DA 1355 04FD50E8083969EDB767B0CF6095179A163AB3661A05FBD5FAAAE82918A99 1356 62F0B93B855F97993EC975EEAA80D740ADBF4FF747359D041D5C33EA71D28 1357 1E446B14773BCA97B43A23FB801676BD207A436C6481F1D2B9078717461A5 1358 B9D32E688F87748544523B524B0D57D5EA77A2775D2ECFA032CFBDBF52FB3 1359 786160279004E57AE6AF874E7303CE53299CCC041C7BC308D82A5698F3A8D 1360 0C38271AE35F8E9DBFBB694B5C803D89F7AE435DE236D525F54759B65E372 1361 FCD68EF20FA7111F9E4AFF73 1362 Generator = 2 1364 Appendix B. Changes since the previous draft 1366 Removed the references to Rijndael since, strictly speaking it is not 1367 the AES. This should also eliminate any ambiguities as to the 1368 required block and key sizes this specification refers to when 1369 mentioning the AES. 1371 Removed the requirement for (a) an all-zero IV, and (b) a dummy first 1372 block in the operations of the Confidentiality Service filter. 1374 Included the description of a secure PRNG. 1376 Included the description of a Key Derivation Function (KDF) to ensure 1377 there will always be enough bytes to initialise both the CALG and 1378 IALG from the shared context key computed by the SRP calculations. 1380 Added a paragraph before the end of the "Security layer" section to 1381 clarify that this specification does not mandate nor imply a lockstep 1382 in operating the security services. 1384 Added a paragraph to the "Security considerations" section about the 1385 quality of the PRNG to use. 1387 Added the restriction that all text should be in Unicode 1388 Normalization form KC with NULs prohibited. 1390 Tightened up the restrictions on the options lists L and o by 1391 specifying that they must not contain any whitespace and must always 1392 be in lowercase. Changed "replay detection" to "replay_detection". 1393 This should simplify parsing of these lists. 1395 Added explicit notes that parameters received from the other party 1396 must be used as received in all digest calculations. Clearly any 1397 alteration of these input parameters (such as changing the case of 1398 text) will prevent the digest calculations on each side from 1399 producing the same result. 1401 Made it mandatory for the server to advertise at least one integrity 1402 protection algorithm and recommended that the HMAC-SHA-160 algorithm 1403 always be advertised. Recommended that the server always make 1404 integrity protection mandatory. 1406 Recommended that the client always select integrity protection, even 1407 if the server does not make it mandatory to do so. Also recommended 1408 that the client always select integrity protection when it selects 1409 confidentiality protection. 1411 Added Alexey Melnikov to Section 9. 1413 Added a quote from section 3 of [RFC-2222] to the description of the 1414 security layer in Section 8 to describe the operation of the security 1415 layer in SASL. 1417 TODO: Amend the Cryptix SASL library and re-generate the example. 1419 Full Copyright Statement 1421 Copyright (C) The Internet Society (2002). All Rights Reserved. 1423 This document and translations of it may be copied and furnished to 1424 others, and derivative works that comment on or otherwise explain it 1425 or assist in its implementation may be prepared, copied, published 1426 and distributed, in whole or in part, without restriction of any 1427 kind, provided that the above copyright notice and this paragraph are 1428 included on all such copies and derivative works. However, this 1429 document itself may not be modified in any way, such as by removing 1430 the copyright notice or references to the Internet Society or other 1431 Internet organizations, except as needed for the purpose of 1432 developing Internet standards in which case the procedures for 1433 copyrights defined in the Internet Standards process must be 1434 followed, or as required to translate it into languages other than 1435 English. 1437 The limited permissions granted above are perpetual and will not be 1438 revoked by the Internet Society or its successors or assigns. 1440 This document and the information contained herein is provided on an 1441 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1442 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1443 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1444 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1445 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1447 Acknowledgement 1449 Funding for the RFC Editor function is currently provided by the 1450 Internet Society.