Network Working Group K. Burdis Internet-Draft Rhodes University Expires: May 5, 2002 R. Naffah Forge Research November 4, 2001 Secure Remote Password SASL Mechanism draft-burdis-cat-srp-sasl-05 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 5, 2002. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This document describes a family of SASL mechanisms based on the Secure Remote Password protocol. These mechanisms perform mutual authentication and can provide a security layer with replay detection, integrity protection and/or confidentiality protection. Burdis & Naffah Expires May 5, 2002 [Page 1] Internet-Draft SRP SASL Mechanism November 2001 Table of Contents 1. Mechanism Names . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions Used in this Document . . . . . . . . . . . . . . 4 3. Data Element Formats . . . . . . . . . . . . . . . . . . . . . 5 3.1 Scalar numbers . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2 Multi-Precision Integers . . . . . . . . . . . . . . . . . . . 5 3.3 Octet Sequences . . . . . . . . . . . . . . . . . . . . . . . 6 3.4 Extended Octet Sequences . . . . . . . . . . . . . . . . . . . 6 3.5 Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.6 Buffers . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.7 Data Element Size Limits . . . . . . . . . . . . . . . . . . . 7 4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 8 4.1 Client sends its authentication identity . . . . . . . . . . . 9 4.2 Server sends initial protocol elements . . . . . . . . . . . . 9 4.3 Client sends its ephemeral public key . . . . . . . . . . . . 11 4.4 Server sends its ephemeral public key . . . . . . . . . . . . 11 4.5 Client sends its evidence . . . . . . . . . . . . . . . . . . 12 4.6 Server sends its evidence . . . . . . . . . . . . . . . . . . 13 5. Security Layer . . . . . . . . . . . . . . . . . . . . . . . . 14 5.1 Confidentiality Protection . . . . . . . . . . . . . . . . . . 15 5.2 Replay Detection . . . . . . . . . . . . . . . . . . . . . . . 17 5.3 Integrity Protection . . . . . . . . . . . . . . . . . . . . . 17 5.4 Summary of Security Layer Output . . . . . . . . . . . . . . . 17 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 22 7.1 Mandatory Algorithms . . . . . . . . . . . . . . . . . . . . . 22 7.2 Modulus and generator values . . . . . . . . . . . . . . . . . 22 7.3 Replay detection sequence number counters . . . . . . . . . . 22 7.4 SASL Profile Considerations . . . . . . . . . . . . . . . . . 23 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29 A. Modulus and Generator values . . . . . . . . . . . . . . . . . 30 B. Changes since last draft . . . . . . . . . . . . . . . . . . . 32 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 33 Burdis & Naffah Expires May 5, 2002 [Page 2] Internet-Draft SRP SASL Mechanism November 2001 1. Mechanism Names The family of SASL mechanisms associated with the protocol described in this document are named "SRP-" where is the canonical name of a Message Digest Algorithm. For example, "SRP-SHA-160" shall denote the SASL mechanism using the protocol described in this document with SHA-1 (20-octet output length, or 160 bits) being used to compute both client-side and server-side digests. Similarly, "SRP-RIPEMD-160" shall denote the SASL mechanism using the protocol described in this document with RIPEMD-160 as the underlying Message Digest Algorithm. Burdis & Naffah Expires May 5, 2002 [Page 3] Internet-Draft SRP SASL Mechanism November 2001 2. Conventions Used in this Document o A hex digit is an element of the set: {0, 1, 2, 3, 4, 5, 6, 7, 8 , 9, A, B, C, D, E, F} A hex digit is the representation of a 4-bit string. Examples: 7 = 0111 A = 1010 o An octet is an 8-bit string. In this document an octet may be written as a pair of hex digits. Examples: 7A = 01111010 02 = 00000010 o All data is encoded and sent in network byte order (big-endian). o The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119]. Burdis & Naffah Expires May 5, 2002 [Page 4] Internet-Draft SRP SASL Mechanism November 2001 3. Data Element Formats This section describes the encoding of the data elements used by the SASL mechanisms described in this document. 3.1 Scalar numbers Scalar numbers are unsigned quantities. Using b[k] to refer to the k-th octet being processed, the value of a two-octet scalar is: ((b[0] << 8) + b[1]), where << is the bit left-shift operator. The value of a four-octet scalar is: ((b[0] << 24) + (b[1] << 16) + (b[2] << 8) + b[3]). 3.2 Multi-Precision Integers Multi-Precision Integers, or MPIs, are positive integers used to hold large integers used in cryptographic computations. MPIs are encoded using a scheme inspired by that used by OpenPGP - [RFC-2440] (section 3.2) - for encoding such entities: The encoded form of an MPI SHALL consist of two pieces: a two- octet scalar that represents the length of the entity, in octets, followed by a sequence of octets that contain the actual integer. These octets form a big-endian number; A big-endian number can be encoded by prefixing it with the appropriate length. Examples: (all numbers are in hexadecimal) The sequence of octets [00 01 01] encodes an MPI with the value 1, while the sequence [00 02 01 FF] encodes an MPI with the value of 511. Additional rule: * The length field of an encoded MPI describes the octet count starting from the MPI's first non-zero octet, containing the most significant non-zero bit. Thus, the encoding [00 02 01] is not formed correctly; It should be [00 01 01]. We shall use the syntax mpi(A) to denote the encoded form of the multi-precision integer A. Furthermore, we shall use the syntax Burdis & Naffah Expires May 5, 2002 [Page 5] Internet-Draft SRP SASL Mechanism November 2001 bytes(A) to denote the big-endian sequence of octets forming the multi-precision integer with the most significant octet being the first non-zero octet containing the most significant bit of A. 3.3 Octet Sequences These mechanisms generate, use and exchange sequences of octets; e.g. output values of message digest algorithm functions. When such entities travel on the wire, they shall be preceded by a one-octet scalar quantity representing the count of following octets. We shall use the syntax os(s) to denote the encoded form of the octet sequence. Furthermore, we shall use the syntax bytes(s) to denote the sequence of octets s, in big-endian order. 3.4 Extended Octet Sequences Extended sequences of octets are exchanged when using the security layer. When these sequences travel on the wire, they shall be preceded by a four-octet scalar quantity representing the count of following octets. We shall use the syntax eos(s) to denote the encoded form of the extended octet sequence. Furthermore, we shall use the syntax bytes(s) to denote the sequence of octets s, in big-endian order. 3.5 Text The only character set for text is the UTF-8 encoding [RFC-2279] of Unicode characters [ISO-10646]. We shall use the syntax utf8(L) to denote the string L in UTF-8 encoding, preceded by a two-octet scalar quantity representing the count of following octets. Furthermore, we shall use the syntax bytes(L) to denote the sequence of octets representing the UTF-8 encoding of L, in big-endian order. 3.6 Buffers In these SASL mechanisms data is exchanged between the client and server using buffers. A buffer acts as an envelope for the sequence of data elements sent by one end-point of the exchange, and expected by the other. A buffer MAY NOT contain other buffers. It may only contain zero, one or more data elements. A buffer shall be encoded as two fields: a four-octet scalar quantity Burdis & Naffah Expires May 5, 2002 [Page 6] Internet-Draft SRP SASL Mechanism November 2001 representing the count of following octets, and the concatenation of the octets of the data element(s) contained in the buffer. We shall use the syntax {A|B|C} to denote a buffer containing A, B and C in that order. For example: { mpi(N) | mpi(g) | utf8(L) } is a buffer containing, in the designated order, the encoded forms of an MPI N, an MPI g and a Text L. 3.7 Data Element Size Limits The following table details the size limit, in number of octets, for each of the SASL data element encodings described earlier. Data element type Header Size limit in octets (octets) (excluding header) ------------------------------------------------------------ Octet Sequence 1 255 MPI 2 65,535 Text 2 65,535 Extended Octet Sequence 4 2,147,483,383 Buffer 4 2,147,483,643 An implementation MUST signal an exception if any size constraint is violated. Burdis & Naffah Expires May 5, 2002 [Page 7] Internet-Draft SRP SASL Mechanism November 2001 4. Protocol Description SRP is a password-based, zero-knowledge, authentication and key- exchange protocol developed by Thomas Wu. It has good performance, is not plaintext-equivalent and maintains perfect forward secrecy. It provides authentication (optionally mutual authentication) and the negotiation of a session key [SRP]. The mechanisms described herein are based on the optimised SRP protocol described at the end of section 3 in [RFC-2945], since this reduces the total number of messages exchanged by grouping together pieces of information that do not depend on earlier messages. Due to the design of the mechanisms, mutual authentication is MANDATORY. This document describes the sequence of data transmitted between the client and server, and it adds extra control information to enable the client to request whether or not replay detection, integrity protection and/or confidentiality protection should be provided by a security layer. Mechanism data exchanges, during the authentication phase, are shown below: Client Server --- { utf8(U) } ----------------------------------> <-------- { mpi(N) | mpi(g) | os(s) | utf8(L) } --- --- { mpi(A) | utf8(I) | utf8(o) } ---------------> <----------------------------------- { mpi(B) } --- --- { os(M1) } -----------------------------------> ( optionally ) <----------------------------------- { os(M2) } --- where: U is the authentication identity (username), N is the safe prime modulus, g is the generator, s is the user's password salt, Burdis & Naffah Expires May 5, 2002 [Page 8] Internet-Draft SRP SASL Mechanism November 2001 L is the options list indicating available security services, A is the client's ephemeral public key, I is the authorisation identity, o is the options list indicating chosen security services, B is the server's ephemeral public key, M1 is the client's evidence that the shared key K is known, M2 is the server's evidence that the shared key K is known. 4.1 Client sends its authentication identity The client determines its authentication identity U, encodes it and sends it to the server. The client sends: { utf8(U) } 4.2 Server sends initial protocol elements The server receives U, and looks up the safe prime modulus N, the generator g, and the salt s to be used for that identity. The server also creates an options list L, which consists of a comma- separated list of option strings that specify the options the server supports. This options list MUST NOT be interpreted in a case- sensitive manner, and whitespace characters MUST be ignored. The following option strings are defined: o "integrity=HMAC-" indicates that the server supports integrity protection using the HMAC algorithm [RFC-2104] with as the underlying Message Digest Algorithm. Acceptable MDA names are chosen from [SCAN] under the MessageDigest section. A server SHOULD send such an option string for each HMAC algorithm it supports. Note that in the interest of interoperability, if the server offers integrity protection it MUST, as a minimum, send the option string "integrity=HMAC-SHA-160" since support for this algorithm is then MANDATORY. o "replay detection" indicates that the server supports replay Burdis & Naffah Expires May 5, 2002 [Page 9] Internet-Draft SRP SASL Mechanism November 2001 detection using sequence numbers. Replay detection SHALL NOT be activated without also activating integrity protection. If the replay detection option is offered (by the server) and/or chosen (by the client) without explicitely specifying an integrity protection option, then the default integrity protection option "integrity=HMAC-SHA-160" is implied and shall be activated. o "confidentiality=" indicates that the server supports confidentiality protection using the symmetric block cipher algorithm . The server SHOULD send such an option string for each confidentiality protection algorithm it supports. Note that in the interest of interoperability, if the server offers confidentiality protection, it MUST send the option string "confidentiality=aes" since it is then MANDATORY for it to provide support for this algorithm. (Rijndael [RIJNDAEL] is synonymous with AES [AES].) o "mandatory=[integrity|replay detection|confidentiality]" is an option only available to the server that indicates that the specified security layer option is MANDATORY and MUST be chosen by the client for use in the resulting security layer. If a server specifies an option as mandatory in this way, it MUST abort the connection if the specified option is not chosen by the client. It doesn't make sense for the client to send this option since it is only able to choose options that the server advertises. The client SHOULD abort the connection if the server does not offer an option that it requires. If this option is not specified then this implies that no options are mandatory. o "maxbuffersize=" indicates to the peer the maximum number of raw bytes (excluding the SASL buffer 4-byte length header) to be processed by the security layer at a time, if one is negotiated. The value of MUST NOT exceed the Buffer size limit defined in section 3.7. If this option is not detected by a client or server mechanism, then it shall operate its security layer on the assumption that the maximum number of bytes that may be sent, to the peer server or client mechanism respectively, is the Buffer data size limit indicated in section 3.7. On the other hand, if a recipient detects this option, it shall break any octet-sequence longer than the designated limit into two or more fragments, each wrapped in a SASL buffer, before sending them, in sequence, to the peer. For example, if the server supports integrity protection using the HMAC-SHA-160 and HMAC-MD5 algorithms, replay detection and no confidentiality protection, the options list would be: integrity=HMAC-SHA-160,integrity=HMAC-MD5,replay detection Burdis & Naffah Expires May 5, 2002 [Page 10] Internet-Draft SRP SASL Mechanism November 2001 The server sends: { mpi(N) | mpi(g) | os(s) | utf8(L) } 4.3 Client sends its ephemeral public key The client receives the options list L from the server that specifies the security service options the server supports and the maximum buffer size the server can handle. The client selects options from this list and creates a new options list o that specifies the security services that will be used in the security layer. At most one available integrity protection algorithm and one available confidentiality protection algorithm may be selected. The client MUST include any option specified by the mandatory option. The client determines its authorisation identity I, and generates its ephemeral public key A as follows: a = prng(); A = g**a % N; where: prng() is a random number generation function, a is the MPI that will act as the client's private key, ** is the exponentiation operator, % is the modulus operator, The client sends: { mpi(A) | utf8(I) | utf8(o) } 4.4 Server sends its ephemeral public key The server reads the client's verifier v, calculates the shared context key K and generates its ephemeral public key B as follows: b = prng(); B = (v + g**b) % N; K = H2((A * v**u) ** b % N); Burdis & Naffah Expires May 5, 2002 [Page 11] Internet-Draft SRP SASL Mechanism November 2001 where: b is the MPI that will act as the server's private key, v is the stored password verifier value, u is a 32-bit unsigned integer which takes its value from the first 32 bits of the hash of B, MSB first, H2() is the "Interleaved SHA" function, as described in [RFC- 2945], but generalised to any message digest algorithm, and applied using the underlying Message Digest Algorithm (see Section 1). The server sends: { mpi(B) } 4.5 Client sends its evidence The client calculates the shared context key K, and calculates the evidence M1 that proves to the server that it knows the shared context key K, including L as part of the calculation. K, on the client's side is computed as follows: x = H(s | H(U | ":" | p)); K = H2((B - g**x) ** (a + u * x) % N); where: H() is the result of digesting the designated input/data with the underlying Message Digest Algorithm function (see Section 1). p is the password value. M1 is computed as: H( bytes(H( bytes(N) )) ^ bytes( H( bytes(g) )) | bytes(H( bytes(U) )) | bytes(s) | bytes(A) | bytes(B) | bytes(K) | bytes(H( bytes(L) )) ) Burdis & Naffah Expires May 5, 2002 [Page 12] Internet-Draft SRP SASL Mechanism November 2001 where: ^ is the bitwise XOR operator. The client sends: { os(M1) } 4.6 Server sends its evidence When the Confidentiality Protection service is requested and approved, the server MUST NOT send M2 but instead conclude the SASL exchange with the reception and verification of the client's M1. Otherwise, M2 MUST be sent. When the server has to send its evidence M2, which proves to the client that it knows the shared context key K, as well as U, I, and o, it shall compute it as follows: H( bytes(A) | bytes(M1) | bytes(K) | bytes(H( bytes(U) )) | bytes(H( bytes(I) )) | bytes(H( bytes(o) )) ) The server OPTIONALLY sends: { os(M2) } Burdis & Naffah Expires May 5, 2002 [Page 13] Internet-Draft SRP SASL Mechanism November 2001 5. Security Layer Depending on the options offered by the server and specified by the client, the security layer may provide integrity protection, replay detection, and/or confidentiality protection. The security layer can be thought of as a three-stage filter through which the data flows from the output of one stage to the input of the following one. The first input is the original data, while the last output is the data after being subject to the transformations of this filter. The data always passes through this three-stage filter, though any of the stages may be inactive. Only when a stage is active would the output be different from the input. In other words, if a stage is inactive, the octet sequence at the output side is an exact duplicate of the same sequence at the input side. Schematically, the three-stage filter security layer appears as follows: +----------------------------+ | | I/ p1 p1 --->| Confidentiality protection |---+ | | | A/ c +----------------------------+ | | +------------------------------------+ | | +----------------------------+ | | | I/ p2 p2 +-->| Replay detection |---+ | | | A/ p2 | q +----------------------------+ | | +------------------------------------+ | | +----------------------------+ | | | I/ p3 p3 +-->| Integrity protection |---> | | A/ p3 | C +----------------------------+ where: p1, p2 and p3 are the input octet sequences at each stage, I/ denotes the output at the end of one stage if/when the stage is Burdis & Naffah Expires May 5, 2002 [Page 14] Internet-Draft SRP SASL Mechanism November 2001 inactive or disabled, A/ denotes the output at the end of one stage if/when the stage is active or enabled, c is the encrypted (sender-side) or decrypted (receiver-side) octet sequence. c1 shall denote the value computed by the sender, while c2 shall denote the value computed by the receiver. q is a four-octet scalar quantity representing a sequence number, C is the Message Authentication Code. C1 shall denote the value of the MAC as computed by the sender, while C2 shall denote the value computed by the receiver. The following paragraphs detail each of the transformations mentioned above. 5.1 Confidentiality Protection The plaintext data octet sequence p1 is encrypted using the chosen confidentiality algorithm (CALG) initialised for encryption with the shared context key K. c1 = CALG(K, ENCRYPTION)( bytes(p1) ) On the receiving side, the ciphertext data octet sequence p1 is decrypted using the chosen confidentiality algorithm (CALG) initialised for decryption, with the shared context key K. c2 = CALG(K, DECRYPTION)( bytes(p1) ) The designated CALG block cipher should be used in OFB (Output Feedback Block) mode in the ISO variant, as described in [HAC], algorithm 7.20. Let k be the block size of the chosen symmetric cipher algorithm; e.g. for AES this is 128 bits or 16 octets. The OFB mode used shall be of length/size k. It is recommended that Block ciphers operating in OFB mode be used with an Initial Vector (the mode's IV). For the SASL mechanisms described in this document, the IV shall be an all-zero octet sequence of size k. In such a mode of operation - OFB with key re-use - the IV, which need not be secret, must be changed. Otherwise an identical keystream results; and, by XORing corresponding ciphertexts, an Burdis & Naffah Expires May 5, 2002 [Page 15] Internet-Draft SRP SASL Mechanism November 2001 adversary may reduce cryptanalysis to that of a running-key cipher with one plaintext as the running key. To counter the effect of fixing the IV to an all-zero octet sequence, the sender should use a one k-octet sequence as the value of its first block, constructed as follows: o the first (most significant) (k-2) octets are random, o the octets at position #k-1 and #k, assuming the first octet is at position #1, are exact copies of those at positions #1 and #2 respectively. The input data to the confidentiality protection algorithm shall be a multiple of the symmetric cipher block size k. When the input length is not a multiple of k octets, the data shall be padded according to the following scheme (described in [PKCS7] which itself is based on [RFC-1423]): Assuming the length of the input is l octets, (k - (l mod k)) octets, all having the value (k - (l mod k)), shall be appended to the original data. In other words, the input is padded at the trailing end with one of the following sequences: 01 -- if l mod k = k-1 02 02 -- if l mod k = k-2 ... ... ... k k ... k k -- if l mod k = 0 The padding can be removed unambiguously since all input is padded and no padding sequence is a suffix of another. This padding method is well-defined if and only if k < 256 octets, which is the case with symmetric block ciphers today, and in the forseeable future. The output of this stage, when it is active, is: at the sending side: CALG(K, ENCRYPT)( bytes(p1) ) at the receiving side: CALG(K, DECRYPT)( bytes(p1) ) If the receiver, after decrypting the first block, finds that the last two octets do not match the value of the first two, it MUST signal an exception and abort the exchange. Burdis & Naffah Expires May 5, 2002 [Page 16] Internet-Draft SRP SASL Mechanism November 2001 5.2 Replay Detection A sequence number q is incremented every time a message is sent to the peer. The output of this stage, when it is active, is: p2 | q At the other end, the receiver increments its copy of the sequence number. This new value of the sequence number is then used in the integrity protection transformation, which must also be active as described in Section 4.2. See Section 7.3 for more details. 5.3 Integrity Protection When the Integrity Protection stage is active, a message authentication code C is computed using the chosen integrity protection algorithm (IALG) as follows: o the IALG is initialised (once) with the shared context key K, o the IALG is updated with every exchange of the sequence p3, yielding the value C and a new IALG context for use in the following exchange. At the other end, the receiver computes its version of C, using the same transformation, and checks that its value is equal to that received. If the two values do not agree, the receiver must signal an exception and abort. The output of this stage, when it is active, is then: IALG(K)( bytes(p3) ) 5.4 Summary of Security Layer Output The following table shows the data exchanged by the security layer peers, depending on the possible legal combinations of the three security services in operation: Burdis & Naffah Expires May 5, 2002 [Page 17] Internet-Draft SRP SASL Mechanism November 2001 CP IP RD Peer sends/receives I I I { eos(p) } I A I { eos(p) | os( IALG(K)( bytes(p) ) ) } I A A { eos(p) | os( IALG(K)( bytes(p) | bytes(q)) ) } A I I { eos(c) } A A I { eos(c) | os( IALG(K)( bytes(c) ) ) } A A A { eos(c) | os( IALG(K)((bytes(c) | bytes(q)) ) } where CP Confidentiality protection, IP Integrity protection, RD Replay detection, I Security service is Inactive/disabled, A Security service is Active/enabled, p The original plaintext, q The sequence number. c The enciphered input obtained by either: CALG(K, ENCRYPT)( bytes(p) ) at the sender's side, or CALG(K, DECRYPT)( bytes(p) ) at the receiver's side Burdis & Naffah Expires May 5, 2002 [Page 18] Internet-Draft SRP SASL Mechanism November 2001 6. Example The example below uses SMTP authentication [RFC-2554]. The base64 encoding of challenges and responses, as well as the reply codes preceding the responses are part of the SMTP authentication specification, not part of this SASL mechanism itself. "C:" and "S:" indicate lines sent by the client and server respectively. S: 220 smtp.example.com ESMTP server ready C: EHLO zaau.example.com S: 250-smtp.example.com S: 250 AUTH SRP-SHA-1 CRAM-MD5 DIGEST-MD5 C: AUTH SRP-SHA-1 600HqPNDq with: U = "test" S: S010Anhsq4oIfgRyMRUNXE9M2.lShPb6OVk1/mnafGzjM1GetCfoxIWcUs1a.1rTsU XFTKZ4gjB0p4DpNz8gTe4/L3e23bfxRTdiCzWbHUQ5ZgpPXe5.zNwgkWf6AcMBmkJk5Nv UPFibrxgg0rq2jlq/tHpMT11rSC.fnqe7aHh57SxofUqEYFxW1PslI1wGsnaWV7IkGU75 qOQMvqoveZuTqXKHIEr9B3LVLwdUYTrqkpw0opxs/KlitXXO2UG1ELwvg.7JdC3pbCfdC m477l32DWgLfZpgD33Wd6kDVZfs/ksbBN80zYVUkGrtYDjKbzKTPjbutByrexo3wSH7vv A/tC00G8A7MFEPSXzBIn8fW2kRM5kP65qRt9vFN9bS6nXUI1aPNHbOtHfRsuiScLmR65v 86HbT6LZT6blRYnfRdHbPt9fT7azQ6rXOorpQ64nB6bkT6LdScbqUJreRM5ZBMraDInZR svcQMHbRdHfOMnfT7azOMLpB6DlRcPfP6LkT6bXR6bqUJrZONDqDInZRsvcQMHbRdHfOM nfT7azOcnlTsPfSsWiRM5uOdLcPcLoSsbwPJqoCJGtD3WpDZGp with: N = "2176617445861743577319100889180275378190766837425553851114464 322468988623538384095721090901308605640157139971723580726658164960 647214841029141336415219736447718088739565548373811507267740223510 176252190156982074029314952962041933326626207347105454836873603951 970248622650624886106025697180298495356112144268015766800076142998 822245709041387397397017192709399211475176516806361476111961547623 342209644278311797123637164733387141433589577347466730896705080700 550932042479967841703686792831676127227423031406754829113358247958 306143957755934710196177140617368437852270348349533703765500675132 8447510550299250924469288819" g = "2" Burdis & Naffah Expires May 5, 2002 [Page 19] Internet-Draft SRP SASL Mechanism November 2001 s = "138789728180301372082342" L = "mandatory=replay detection,replay detection,integrity=hmac-sh a1,integrity=hmac-md5,confidentiality=aes,confidentiality=cast5,co nfidentiality=blowfish,maxbuffersize=2147483643" C: 5V0G1w3jr4GvQN9j8rfg5eqaqOJzBCtFl2nWpvlb7uIBXZ/KzuHiQ/Bv8LfgG0zANi Nk3QUSSv5EpflNw7R.oLjFtg9nQiIPFdpCa5PB.Er3fmU3zIjMVQi9QJKo9mI6RKqeIlR QcG56d.s8zmJr/GSGF.HfPylv0o4YonxH4Q7UD8HL0oskwSjjExxRiaXik51Qjv4DlasS UIi6aWn7XhLcdPkuCDxWRelURWp3jjknuK8sOb25Oh5vtXqM81iGSZO2UGmDEjAY2roJ6 oJLEIiTKnOAF6TgJ8XaIB05lfLU6geAy6m81WX8zIiNYZQXBhJLYRkiFMIA9FVVjRcr0c htVW00HqPNDq05LoPN1iONaWP6LqPMDqQMzkB6bkT6LdScbqUJreRM5ZBMraDInZRsvcQ MHbRdHfOMnfT7azOcnlTsPfSsWiRM5uOdLcPcLoSsbwPJqoCJGtD3WpDZGp with: A = "1540840307665744654003176437045463995983698152123540739506255 167235184981369874100601341823577069818317928442714597863988388736 761783769324538092721915238917488567908764625118970309039117506830 582863492060359753878958333592304051308214607010237207906833581987 891184516859028106830689778263784175551091596837339850972317447370 786690976814652660651161408507908790872233230598691360594909211360 681467576271644166275492362547607158772648745122532595439242971280 059132327632664112420574698735613632927712799198248455476764164640 093966784951741739596728324205805547296965925103620141665564971312 0296669122592188812766443488" I = "test" o = "replay detection,integrity=hmac-md5,confidentiality=blowfish, maxbuffersize=2147483643" S: 420G1kVN1PjchzeajtjwwsnDoRlOVq11x7SzE70TBF/MD1G9rM49Prwk7Psr4z3til XTbiMvmPXzayzF5Sij9D2dW3HpgJ9pxrupfGpU4G5RKR0xv0ednxdjxkXizizfqvPHLk4 APU9eC/m5ueZ9Xj3Vz1TwX.H7WGxz6sWQp6PnLgYbfP.klv6dW6wB./OIlyHLUzO34jjc 8pzyb6Sq9Qpm7wz4k2hV/mf7YanCvdqAXctIv260LhooJAKnYv7RQoWrgZHsRBK6MnfW2 cf/HoTs.puXJN9j.UpFWVgdb/kVZBkiSMr.x9fHAmwcr2Psb6SAh4o9.nliHIfE8MmgBV 1zz6 with: B = "1394806975793617459788496083554803630085100477069670229790536 663039054654983798737214003146850157571057005545879038184930611817 513956870847135668034099121265174715819508791670238346647996442928 236952271233942847218179322401410928004797472055889044274301042822 436472076200733427427417064560838528977725244677525054774294966690 351389984931057296810093285460463200076154198365512418582103361801 118376579659715751759450245145782015844858575973315196359638687590 Burdis & Naffah Expires May 5, 2002 [Page 20] Internet-Draft SRP SASL Mechanism November 2001 571237971749297255211039832183564686875820907022338494638496828197 764735581518471732704627877884396733044981224764257023002764217815 3897400684381472018003386182" C: L5Dz0j8MFVs3TyrnTLspZCIWq/mmo S: 235 Authentication successful. Burdis & Naffah Expires May 5, 2002 [Page 21] Internet-Draft SRP SASL Mechanism November 2001 7. Discussion 7.1 Mandatory Algorithms The algorithms specified as mandatory were chosen for utility and availablity. We felt that a mandatory confidentiality and integrity protection algorithm should be specified to ensure interoperability between implementations of these mechanisms. o The HMAC algorithm was chosen as an integrity algorithm because it is faster than MAC algorithms based on secret key encryption algorithms [RFC-2847]. o Rijndael was chosen as a cipher because it has undergone thorough scrutiny by the best cryptographers in the world and was chosen ahead of many other algorithms as the Advanced Encryption Standard. Since confidentiality protection is optional this mechanism should be usable in countries that have strict controls on the use of cryptography. 7.2 Modulus and generator values It is RECOMMENDED that the server use values for the modulus (N) and generator (g) chosen from those listed in Appendix A so that the client can avoid expensive constraint checks, since these predefined values already meet the constraints described in [RFC-2945]: "For maximum security, N should be a safe prime (i.e. a number of the form N = 2q + 1, where q is also prime). Also, g should be a generator modulo N (see [SRP] for details), which means that for any X where 0 < X < N, there exists a value x for which g^x % N == X." 7.3 Replay detection sequence number counters The mechanisms described in this document allow the use of a Replay Detection security service that works by including sequence number counters in the message authentication code (MAC) created by the Integrity Protection service. As noted in Section 4.2 integrity protection is always activated when the Replay Detection service is activated. Both the client and the server keep two sequence number counters. Each of these counters is a 32-bit unsigned integer initialised with a Starting Value and incremented by an Increment Value with every Burdis & Naffah Expires May 5, 2002 [Page 22] Internet-Draft SRP SASL Mechanism November 2001 successful transmission of an SASL buffer through the security layer. The Sent counter is incremented for each buffer sent through the security layer. The Received counter is incremented for each buffer received through the security layer. If the value of a sequence number counter exceeds 2**32 it wraps around and starts from zero again. When a sender sends a buffer it includes the value of its Sent counter in the computation of the MAC accompanying each integrity protected message. When a recipient receives a buffer it uses the value of it's Received counter in its computation of the integrity protection MAC for the received message. The recipient's Received counter must be the same as the sender's Sent counter in order for the received and computed MACs to match. This specification assumes that for each sequence number counter the Starting Value is ZERO, and that the Increment Value is ONE. These values do not affect the security or the intended objective of the replay detection service, since they never travel on the wire. 7.4 SASL Profile Considerations As mentioned briefly in [RFC-2222], and detailed in [SASL] a SASL specification has three layers: (a) a protocol definition using SASL known as the "Profile", (b) a SASL mechanism definition, and (c) the SASL framework. Point (3) in section 5 of [SASL] ("Protocol profile requirements") clearly states that it is the responsibility of the Profile to define "...how the challenges and responses are encoded, how the server indicates completion or failure of the exchange, how the client aborts an exchange, and how the exchange method interacts with any line length limits in the protocol." The username entity, referenced as "U" throughout this document, and used by the server to locate the password data, is assumed to travel "in the clear," meaning that no transformation is applied to its contents. This assumption was made to allow the same SRP password files to be used in these mechanisms, as those used with other SRP applications and tools. A Profile may decide, for privacy or other reason, to disallow such information to travel in the clear, and instead use a hashed version of U, or more generally a transformation function applied to U; i.e. f(U). Such a Profile would require additional tools to add the required entries to the SRP password files for the new value(s) of f(U). It is worth noting too that if this is the case, and the same user shall access the server through this mechanism as well as Burdis & Naffah Expires May 5, 2002 [Page 23] Internet-Draft SRP SASL Mechanism November 2001 through other SRP tools, then at least two entries, one with U and the other with f(U) need to be present in the SRP password files if those same files are to be used for both types of access. Burdis & Naffah Expires May 5, 2002 [Page 24] Internet-Draft SRP SASL Mechanism November 2001 8. Security Considerations These mechanisms rely on the security of SRP, which bases its security on the difficulty of solving the Diffie-Hellman problem in the multiplicative field modulo a large safe prime. See section 4 "Security Considerations" of [RFC-2945] and section 4 "Security analysis" of [SRP]. This mechanism also relies on the security of the HMAC algorithm and the underlying hash function when integrity protection is used. Section 6 "Security" of [RFC-2104] discusses these security issues in detail. Weaknesses found in MD5 do not impact HMAC-MD5 [DOBBERTIN]. U, I, A and o, sent from the client to the server, and N, g, L, s and B, sent from the server to the client could be modified by an attacker before reaching the other party. For this reason, these values are included in the respective calculations of evidence (M1 and M2) to prove that each party knows the session key. This allows each party to verify that these values were received unmodified. The use of integrity protection is RECOMMENDED to detect message tampering and to avoid session hijacking after authentication has taken place. Replay attacks may be avoided through the use of sequence numbers, because sequence numbers make each integrity protected message exchanged during a session different, and each session uses a different key. Research [KRAWCZYK] shows that the order and way of combining message encryption (Confidentiality Protection) and message authentication (Integrity Protection) are important. This mechanism follows the EtA (encrypt-then-authenticate) method and is "generically secure." Burdis & Naffah Expires May 5, 2002 [Page 25] Internet-Draft SRP SASL Mechanism November 2001 9. Acknowledgements The following people provided valuable feedback in the preparation of this document: Stephen Farrell Timothy Martin Magnus Nystr÷m Thomas Wu Burdis & Naffah Expires May 5, 2002 [Page 26] Internet-Draft SRP SASL Mechanism November 2001 References [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 0014, RFC 2119, March 1997, . [RFC-2440] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998, . [RFC-2279] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO 10646", RFC 2279, January 1998, . [ISO-10646] "International Standard --Information technology-- Universal Multiple-Octet Coded Character Set (UCS) -- Part 1 Architecture and Basic Multilingual Plane", ISO/IEC 10646-1, 1993. [RIJNDAEL] Daemen, Joan. and Vincent. Rijmen, "AES Proposal: Rijndael", September 1999, . [AES] National Institute of Standards and Technology, "Rijndael: NIST's Selection for the AES", December 2000, . [DOBBERTIN] Dobbertin, H., "The Status of MD5 After a Recent Attack", December 1996, . [RFC-2847] Eisler, M., "LIPKEY - A Low Infrastructure Public Key Mechanism Using SPKM", RFC 2847, June 2000, . [RFC-2104] Krawczyk, H., "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997, . [RFC-2222] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997, . [RFC-2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999, . Burdis & Naffah Expires May 5, 2002 [Page 27] Internet-Draft SRP SASL Mechanism November 2001 [SRP] Wu, T., "The Secure Remote Password Protocol", March 1998, . [RFC-2945] Wu, T., "The SRP Authentication and Key Exchange System", RFC 2945, September 2000, . [SRP'] Wu, T., "SRP: The Open Source Password Authentication Standard", March 1998, . [SCAN] Hopwood, D., "Standard Cryptographic Algorithm Naming", June 2000, . [HAC] Menezes, A., van Oorschot, P. and S. Vanstone, "Handbook of Applied Cryptography", CRC Press, Inc., ISBN 0-8493- 8523-7, 1997, . [PKCS7] RSA Data Security, Inc., "PKCS #7: Cryptographic Message Syntax Standard", Version 1.5, November 1993, . [RFC-1423] Balenson, D., "Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers", RFC 1423, February 1993, . [RFC-2554] Myers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999. [KRAWCZYK] Krawczyk, H., "The order of encryption and authentication for protecting communications (Or: how secure is SSL?)", June 2001, . [SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", April 2001, . Burdis & Naffah Expires May 5, 2002 [Page 28] Internet-Draft SRP SASL Mechanism November 2001 Authors' Addresses Keith Burdis Rhodes University Computer Science Department Grahamstown 6139 ZA EMail: keith@rucus.ru.ac.za URI: http://www.cryptix.org/~keith/ Raif S. Naffah Forge Research Pty. Limited Suite 116, Bay 9 Locomotive Workshop, Australian Technology Park Cornwallis Street Eveleigh, NSW 1430 AU EMail: raif@forge.com.au URI: http://www.cryptix.org/~raif/ Burdis & Naffah Expires May 5, 2002 [Page 29] Internet-Draft SRP SASL Mechanism November 2001 Appendix A. Modulus and Generator values Modulus (N) and generator (g) values for various modulus lengths are given below. In each case the modulus is a large safe prime and the generator is a primitve root of GF(n) [RFC-2945]. These values are taken from software developed by Tom Wu and Eugene Jhong for the Stanford SRP distribution [SRP']. [264 bits] Modulus (base 16) = 115B8B692E0E045692CF280B436735C77A5A9E8A9E7ED56C965F87DB5B2A2ECE 3 Generator = 2 [384 bits] Modulus (base 16) = 8025363296FB943FCE54BE717E0E2958A02A9672EF561953B2BAA3BAACC3ED57 54EB764C7AB7184578C57D5949CCB41B Generator = 2 [512 bits] Modulus (base 16) = D4C7F8A2B32C11B8FBA9581EC4BA4F1B04215642EF7355E37C0FC0443EF756EA 2C6B8EEB755A1C723027663CAA265EF785B8FF6A9B35227A52D86633DBDFCA43 Generator = 2 [640 bits] Modulus (base 16) = C94D67EB5B1A2346E8AB422FC6A0EDAEDA8C7F894C9EEEC42F9ED250FD7F0046 E5AF2CF73D6B2FA26BB08033DA4DE322E144E7A8E9B12A0E4637F6371F34A207 1C4B3836CBEEAB15034460FAA7ADF483 Generator = 2 [768 bits] Modulus (base 16) = B344C7C4F8C495031BB4E04FF8F84EE95008163940B9558276744D91F7CC9F40 2653BE7147F00F576B93754BCDDF71B636F2099E6FFF90E79575F3D0DE694AFF 737D9BE9713CEF8D837ADA6380B1093E94B6A529A8C6C2BE33E0867C60C3262B Generator = 2 [1024 bits] Modulus (base 16) = EEAF0AB9ADB38DD69C33F80AFA8FC5E86072618775FF3C0B9EA2314C9C256576 D674DF7496EA81D3383B4813D692C6E0E0D5D8E250B98BE48E495C1D6089DAD1 5DC7D7B46154D6B6CE8EF4AD69B15D4982559B297BCF1885C529F566660E57EC 68EDBC3C05726CC02FD4CBF4976EAA9AFD5138FE8376435B9FC61D2FC0EB06E3 Generator = 2 Burdis & Naffah Expires May 5, 2002 [Page 30] Internet-Draft SRP SASL Mechanism November 2001 [1280 bits] Modulus (base 16) = D77946826E811914B39401D56A0A7843A8E7575D738C672A090AB1187D690DC4 3872FC06A7B6A43F3B95BEAEC7DF04B9D242EBDC481111283216CE816E004B78 6C5FCE856780D41837D95AD787A50BBE90BD3A9C98AC0F5FC0DE744B1CDE1891 690894BC1F65E00DE15B4B2AA6D87100C9ECC2527E45EB849DEB14BB2049B163 EA04187FD27C1BD9C7958CD40CE7067A9C024F9B7C5A0B4F5003686161F0605B Generator = 2 [1536 bits] Modulus (base 16) = 9DEF3CAFB939277AB1F12A8617A47BBBDBA51DF499AC4C80BEEEA9614B19CC4D 5F4F5F556E27CBDE51C6A94BE4607A291558903BA0D0F84380B655BB9A22E8DC DF028A7CEC67F0D08134B1C8B97989149B609E0BE3BAB63D47548381DBC5B1FC 764E3F4B53DD9DA1158BFD3E2B9C8CF56EDF019539349627DB2FD53D24B7C486 65772E437D6C7F8CE442734AF7CCB7AE837C264AE3A9BEB87F8A2FE9B8B5292E 5A021FFF5E91479E8CE7A28C2442C6F315180F93499A234DCF76E3FED135F9BB Generator = 2 [2048 bits] Modulus (base 16) = AC6BDB41324A9A9BF166DE5E1389582FAF72B6651987EE07FC3192943DB56050 A37329CBB4A099ED8193E0757767A13DD52312AB4B03310DCD7F48A9DA04FD50 E8083969EDB767B0CF6095179A163AB3661A05FBD5FAAAE82918A9962F0B93B8 55F97993EC975EEAA80D740ADBF4FF747359D041D5C33EA71D281E446B14773B CA97B43A23FB801676BD207A436C6481F1D2B9078717461A5B9D32E688F87748 544523B524B0D57D5EA77A2775D2ECFA032CFBDBF52FB3786160279004E57AE6 AF874E7303CE53299CCC041C7BC308D82A5698F3A8D0C38271AE35F8E9DBFBB6 94B5C803D89F7AE435DE236D525F54759B65E372FCD68EF20FA7111F9E4AFF73 Generator = 2 Burdis & Naffah Expires May 5, 2002 [Page 31] Internet-Draft SRP SASL Mechanism November 2001 Appendix B. Changes since last draft Added element size limits and changed SHOULD to MUST in Section 3.7. Added "mandatory" and "maxbuffersize" options, and changed SHOULD, SHOULD NOT to MUST and MUST NOT in Section 4.2. The salt s is now sent with N and g. The rationale is to make the exchanges, as well as the ordering of their elements, closer to [RFC- 2945]. Made sending the server evidence M2 conditional upon activation of Confidentiality Protection security service. Now, the server MUST only send M2 if Confidentiality Protection is not activated, and MUST NOT if it is. Changed the order of elements when computing both M1 (client's evidence) and M2 (server's evidence) to reflect the informal SRP convention, which is to place any "extra" data for the hash at the end. Added a new section, "Replay detection sequence number counters" (Section 7.3), that describes how these counters are used to provide replay detection. Added a new section, "SASL Profile Considerations," (Section 7.4) where various SASL profile related issues are covered. Updated the list of contributors. Changed the references to use symbolic names instead of numbers. Burdis & Naffah Expires May 5, 2002 [Page 32] Internet-Draft SRP SASL Mechanism November 2001 Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Burdis & Naffah Expires May 5, 2002 [Page 33]