| blob | d800b2f41155425c6e0cda4ad2943d1cc941f89c |
3 Network Working Group K. Burdis
4 Internet-Draft Rhodes University
5 Expires: May 5, 2002 R. Naffah
6 Forge Research
7 November 4, 2001
10 Secure Remote Password SASL Mechanism
11 draft-burdis-cat-srp-sasl-05
13 Status of this Memo
15 This document is an Internet-Draft and is in full conformance with
16 all provisions of Section 10 of RFC2026.
18 Internet-Drafts are working documents of the Internet Engineering
19 Task Force (IETF), its areas, and its working groups. Note that
20 other groups may also distribute working documents as Internet-
21 Drafts.
23 Internet-Drafts are draft documents valid for a maximum of six months
24 and may be updated, replaced, or obsoleted by other documents at any
25 time. It is inappropriate to use Internet-Drafts as reference
26 material or to cite them other than as "work in progress."
28 The list of current Internet-Drafts can be accessed at
29 http://www.ietf.org/ietf/1id-abstracts.txt.
31 The list of Internet-Draft Shadow Directories can be accessed at
32 http://www.ietf.org/shadow.html.
34 This Internet-Draft will expire on May 5, 2002.
36 Copyright Notice
38 Copyright (C) The Internet Society (2001). All Rights Reserved.
40 Abstract
42 This document describes a family of SASL mechanisms based on the
43 Secure Remote Password protocol. These mechanisms perform mutual
44 authentication and can provide a security layer with replay
45 detection, integrity protection and/or confidentiality protection.
55 Burdis & Naffah Expires May 5, 2002 [Page 1]
56 \f
57 Internet-Draft SRP SASL Mechanism November 2001
60 Table of Contents
62 1. Mechanism Names . . . . . . . . . . . . . . . . . . . . . . . 3
63 2. Conventions Used in this Document . . . . . . . . . . . . . . 4
64 3. Data Element Formats . . . . . . . . . . . . . . . . . . . . . 5
65 3.1 Scalar numbers . . . . . . . . . . . . . . . . . . . . . . . . 5
66 3.2 Multi-Precision Integers . . . . . . . . . . . . . . . . . . . 5
67 3.3 Octet Sequences . . . . . . . . . . . . . . . . . . . . . . . 6
68 3.4 Extended Octet Sequences . . . . . . . . . . . . . . . . . . . 6
69 3.5 Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
70 3.6 Buffers . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
71 3.7 Data Element Size Limits . . . . . . . . . . . . . . . . . . . 7
72 4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 8
73 4.1 Client sends its authentication identity . . . . . . . . . . . 9
74 4.2 Server sends initial protocol elements . . . . . . . . . . . . 9
75 4.3 Client sends its ephemeral public key . . . . . . . . . . . . 11
76 4.4 Server sends its ephemeral public key . . . . . . . . . . . . 11
77 4.5 Client sends its evidence . . . . . . . . . . . . . . . . . . 12
78 4.6 Server sends its evidence . . . . . . . . . . . . . . . . . . 13
79 5. Security Layer . . . . . . . . . . . . . . . . . . . . . . . . 14
80 5.1 Confidentiality Protection . . . . . . . . . . . . . . . . . . 15
81 5.2 Replay Detection . . . . . . . . . . . . . . . . . . . . . . . 17
82 5.3 Integrity Protection . . . . . . . . . . . . . . . . . . . . . 17
83 5.4 Summary of Security Layer Output . . . . . . . . . . . . . . . 17
84 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
85 7. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 22
86 7.1 Mandatory Algorithms . . . . . . . . . . . . . . . . . . . . . 22
87 7.2 Modulus and generator values . . . . . . . . . . . . . . . . . 22
88 7.3 Replay detection sequence number counters . . . . . . . . . . 22
89 7.4 SASL Profile Considerations . . . . . . . . . . . . . . . . . 23
90 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25
91 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
92 References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29
94 A. Modulus and Generator values . . . . . . . . . . . . . . . . . 30
95 B. Changes since last draft . . . . . . . . . . . . . . . . . . . 32
96 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 33
111 Burdis & Naffah Expires May 5, 2002 [Page 2]
112 \f
113 Internet-Draft SRP SASL Mechanism November 2001
116 1. Mechanism Names
118 The family of SASL mechanisms associated with the protocol described
119 in this document are named "SRP-<MDA name>" where <MDA name> is the
120 canonical name of a Message Digest Algorithm.
122 For example, "SRP-SHA-160" shall denote the SASL mechanism using the
123 protocol described in this document with SHA-1 (20-octet output
124 length, or 160 bits) being used to compute both client-side and
125 server-side digests. Similarly, "SRP-RIPEMD-160" shall denote the
126 SASL mechanism using the protocol described in this document with
127 RIPEMD-160 as the underlying Message Digest Algorithm.
167 Burdis & Naffah Expires May 5, 2002 [Page 3]
168 \f
169 Internet-Draft SRP SASL Mechanism November 2001
172 2. Conventions Used in this Document
174 o A hex digit is an element of the set:
176 {0, 1, 2, 3, 4, 5, 6, 7, 8 , 9, A, B, C, D, E, F}
178 A hex digit is the representation of a 4-bit string. Examples:
180 7 = 0111
182 A = 1010
184 o An octet is an 8-bit string. In this document an octet may be
185 written as a pair of hex digits. Examples:
187 7A = 01111010
189 02 = 00000010
191 o All data is encoded and sent in network byte order (big-endian).
193 o The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
194 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
195 in this document are to be interpreted as described in [RFC-2119].
223 Burdis & Naffah Expires May 5, 2002 [Page 4]
224 \f
225 Internet-Draft SRP SASL Mechanism November 2001
228 3. Data Element Formats
230 This section describes the encoding of the data elements used by the
231 SASL mechanisms described in this document.
233 3.1 Scalar numbers
235 Scalar numbers are unsigned quantities. Using b[k] to refer to the
236 k-th octet being processed, the value of a two-octet scalar is:
238 ((b[0] << 8) + b[1]),
240 where << is the bit left-shift operator. The value of a four-octet
241 scalar is:
243 ((b[0] << 24) + (b[1] << 16) + (b[2] << 8) + b[3]).
246 3.2 Multi-Precision Integers
248 Multi-Precision Integers, or MPIs, are positive integers used to hold
249 large integers used in cryptographic computations.
251 MPIs are encoded using a scheme inspired by that used by OpenPGP -
252 [RFC-2440] (section 3.2) - for encoding such entities:
254 The encoded form of an MPI SHALL consist of two pieces: a two-
255 octet scalar that represents the length of the entity, in octets,
256 followed by a sequence of octets that contain the actual integer.
258 These octets form a big-endian number; A big-endian number can be
259 encoded by prefixing it with the appropriate length.
261 Examples: (all numbers are in hexadecimal)
263 The sequence of octets [00 01 01] encodes an MPI with the value
264 1, while the sequence [00 02 01 FF] encodes an MPI with the
265 value of 511.
267 Additional rule:
269 * The length field of an encoded MPI describes the octet count
270 starting from the MPI's first non-zero octet, containing the
271 most significant non-zero bit. Thus, the encoding [00 02 01]
272 is not formed correctly; It should be [00 01 01].
274 We shall use the syntax mpi(A) to denote the encoded form of the
275 multi-precision integer A. Furthermore, we shall use the syntax
279 Burdis & Naffah Expires May 5, 2002 [Page 5]
280 \f
281 Internet-Draft SRP SASL Mechanism November 2001
284 bytes(A) to denote the big-endian sequence of octets forming the
285 multi-precision integer with the most significant octet being the
286 first non-zero octet containing the most significant bit of A.
288 3.3 Octet Sequences
290 These mechanisms generate, use and exchange sequences of octets; e.g.
291 output values of message digest algorithm functions. When such
292 entities travel on the wire, they shall be preceded by a one-octet
293 scalar quantity representing the count of following octets.
295 We shall use the syntax os(s) to denote the encoded form of the octet
296 sequence. Furthermore, we shall use the syntax bytes(s) to denote
297 the sequence of octets s, in big-endian order.
299 3.4 Extended Octet Sequences
301 Extended sequences of octets are exchanged when using the security
302 layer. When these sequences travel on the wire, they shall be
303 preceded by a four-octet scalar quantity representing the count of
304 following octets.
306 We shall use the syntax eos(s) to denote the encoded form of the
307 extended octet sequence. Furthermore, we shall use the syntax
308 bytes(s) to denote the sequence of octets s, in big-endian order.
310 3.5 Text
312 The only character set for text is the UTF-8 encoding [RFC-2279] of
313 Unicode characters [ISO-10646].
315 We shall use the syntax utf8(L) to denote the string L in UTF-8
316 encoding, preceded by a two-octet scalar quantity representing the
317 count of following octets. Furthermore, we shall use the syntax
318 bytes(L) to denote the sequence of octets representing the UTF-8
319 encoding of L, in big-endian order.
321 3.6 Buffers
323 In these SASL mechanisms data is exchanged between the client and
324 server using buffers. A buffer acts as an envelope for the sequence
325 of data elements sent by one end-point of the exchange, and expected
326 by the other.
328 A buffer MAY NOT contain other buffers. It may only contain zero,
329 one or more data elements.
331 A buffer shall be encoded as two fields: a four-octet scalar quantity
335 Burdis & Naffah Expires May 5, 2002 [Page 6]
336 \f
337 Internet-Draft SRP SASL Mechanism November 2001
340 representing the count of following octets, and the concatenation of
341 the octets of the data element(s) contained in the buffer.
343 We shall use the syntax {A|B|C} to denote a buffer containing A, B
344 and C in that order. For example:
346 { mpi(N) | mpi(g) | utf8(L) }
348 is a buffer containing, in the designated order, the encoded forms of
349 an MPI N, an MPI g and a Text L.
351 3.7 Data Element Size Limits
353 The following table details the size limit, in number of octets, for
354 each of the SASL data element encodings described earlier.
356 Data element type Header Size limit in octets
357 (octets) (excluding header)
358 ------------------------------------------------------------
359 Octet Sequence 1 255
360 MPI 2 65,535
361 Text 2 65,535
362 Extended Octet Sequence 4 2,147,483,383
363 Buffer 4 2,147,483,643
365 An implementation MUST signal an exception if any size constraint is
366 violated.
391 Burdis & Naffah Expires May 5, 2002 [Page 7]
392 \f
393 Internet-Draft SRP SASL Mechanism November 2001
396 4. Protocol Description
398 SRP is a password-based, zero-knowledge, authentication and key-
399 exchange protocol developed by Thomas Wu. It has good performance,
400 is not plaintext-equivalent and maintains perfect forward secrecy.
401 It provides authentication (optionally mutual authentication) and the
402 negotiation of a session key [SRP].
404 The mechanisms described herein are based on the optimised SRP
405 protocol described at the end of section 3 in [RFC-2945], since this
406 reduces the total number of messages exchanged by grouping together
407 pieces of information that do not depend on earlier messages. Due to
408 the design of the mechanisms, mutual authentication is MANDATORY.
410 This document describes the sequence of data transmitted between the
411 client and server, and it adds extra control information to enable
412 the client to request whether or not replay detection, integrity
413 protection and/or confidentiality protection should be provided by a
414 security layer.
416 Mechanism data exchanges, during the authentication phase, are shown
417 below:
419 Client Server
421 --- { utf8(U) } ---------------------------------->
423 <-------- { mpi(N) | mpi(g) | os(s) | utf8(L) } ---
425 --- { mpi(A) | utf8(I) | utf8(o) } --------------->
427 <----------------------------------- { mpi(B) } ---
429 --- { os(M1) } ----------------------------------->
431 ( optionally )
433 <----------------------------------- { os(M2) } ---
435 where:
437 U is the authentication identity (username),
439 N is the safe prime modulus,
441 g is the generator,
443 s is the user's password salt,
447 Burdis & Naffah Expires May 5, 2002 [Page 8]
448 \f
449 Internet-Draft SRP SASL Mechanism November 2001
452 L is the options list indicating available security services,
454 A is the client's ephemeral public key,
456 I is the authorisation identity,
458 o is the options list indicating chosen security services,
460 B is the server's ephemeral public key,
462 M1 is the client's evidence that the shared key K is known,
464 M2 is the server's evidence that the shared key K is known.
467 4.1 Client sends its authentication identity
469 The client determines its authentication identity U, encodes it and
470 sends it to the server.
472 The client sends:
474 { utf8(U) }
477 4.2 Server sends initial protocol elements
479 The server receives U, and looks up the safe prime modulus N, the
480 generator g, and the salt s to be used for that identity.
482 The server also creates an options list L, which consists of a comma-
483 separated list of option strings that specify the options the server
484 supports. This options list MUST NOT be interpreted in a case-
485 sensitive manner, and whitespace characters MUST be ignored.
487 The following option strings are defined:
489 o "integrity=HMAC-<MDA-name>" indicates that the server supports
490 integrity protection using the HMAC algorithm [RFC-2104] with
491 <MDA-name> as the underlying Message Digest Algorithm. Acceptable
492 MDA names are chosen from [SCAN] under the MessageDigest section.
493 A server SHOULD send such an option string for each HMAC algorithm
494 it supports. Note that in the interest of interoperability, if
495 the server offers integrity protection it MUST, as a minimum, send
496 the option string "integrity=HMAC-SHA-160" since support for this
497 algorithm is then MANDATORY.
499 o "replay detection" indicates that the server supports replay
503 Burdis & Naffah Expires May 5, 2002 [Page 9]
504 \f
505 Internet-Draft SRP SASL Mechanism November 2001
508 detection using sequence numbers. Replay detection SHALL NOT be
509 activated without also activating integrity protection. If the
510 replay detection option is offered (by the server) and/or chosen
511 (by the client) without explicitely specifying an integrity
512 protection option, then the default integrity protection option
513 "integrity=HMAC-SHA-160" is implied and shall be activated.
515 o "confidentiality=<cipher name>" indicates that the server supports
516 confidentiality protection using the symmetric block cipher
517 algorithm <cipher name>. The server SHOULD send such an option
518 string for each confidentiality protection algorithm it supports.
519 Note that in the interest of interoperability, if the server
520 offers confidentiality protection, it MUST send the option string
521 "confidentiality=aes" since it is then MANDATORY for it to provide
522 support for this algorithm. (Rijndael [RIJNDAEL] is synonymous
523 with AES [AES].)
525 o "mandatory=[integrity|replay detection|confidentiality]" is an
526 option only available to the server that indicates that the
527 specified security layer option is MANDATORY and MUST be chosen by
528 the client for use in the resulting security layer. If a server
529 specifies an option as mandatory in this way, it MUST abort the
530 connection if the specified option is not chosen by the client.
531 It doesn't make sense for the client to send this option since it
532 is only able to choose options that the server advertises. The
533 client SHOULD abort the connection if the server does not offer an
534 option that it requires. If this option is not specified then
535 this implies that no options are mandatory.
537 o "maxbuffersize=<number of bytes>" indicates to the peer the
538 maximum number of raw bytes (excluding the SASL buffer 4-byte
539 length header) to be processed by the security layer at a time, if
540 one is negotiated. The value of <number of bytes> MUST NOT exceed
541 the Buffer size limit defined in section 3.7. If this option is
542 not detected by a client or server mechanism, then it shall
543 operate its security layer on the assumption that the maximum
544 number of bytes that may be sent, to the peer server or client
545 mechanism respectively, is the Buffer data size limit indicated in
546 section 3.7. On the other hand, if a recipient detects this
547 option, it shall break any octet-sequence longer than the
548 designated limit into two or more fragments, each wrapped in a
549 SASL buffer, before sending them, in sequence, to the peer.
551 For example, if the server supports integrity protection using the
552 HMAC-SHA-160 and HMAC-MD5 algorithms, replay detection and no
553 confidentiality protection, the options list would be:
555 integrity=HMAC-SHA-160,integrity=HMAC-MD5,replay detection
559 Burdis & Naffah Expires May 5, 2002 [Page 10]
560 \f
561 Internet-Draft SRP SASL Mechanism November 2001
564 The server sends:
566 { mpi(N) | mpi(g) | os(s) | utf8(L) }
569 4.3 Client sends its ephemeral public key
571 The client receives the options list L from the server that specifies
572 the security service options the server supports and the maximum
573 buffer size the server can handle. The client selects options from
574 this list and creates a new options list o that specifies the
575 security services that will be used in the security layer. At most
576 one available integrity protection algorithm and one available
577 confidentiality protection algorithm may be selected. The client
578 MUST include any option specified by the mandatory option.
580 The client determines its authorisation identity I, and generates its
581 ephemeral public key A as follows:
583 a = prng();
585 A = g**a % N;
587 where:
589 prng() is a random number generation function,
591 a is the MPI that will act as the client's private key,
593 ** is the exponentiation operator,
595 % is the modulus operator,
597 The client sends:
599 { mpi(A) | utf8(I) | utf8(o) }
602 4.4 Server sends its ephemeral public key
604 The server reads the client's verifier v, calculates the shared
605 context key K and generates its ephemeral public key B as follows:
607 b = prng();
609 B = (v + g**b) % N;
611 K = H2((A * v**u) ** b % N);
615 Burdis & Naffah Expires May 5, 2002 [Page 11]
616 \f
617 Internet-Draft SRP SASL Mechanism November 2001
620 where:
622 b is the MPI that will act as the server's private key,
624 v is the stored password verifier value,
626 u is a 32-bit unsigned integer which takes its value from the
627 first 32 bits of the hash of B, MSB first,
629 H2() is the "Interleaved SHA" function, as described in [RFC-
630 2945], but generalised to any message digest algorithm, and
631 applied using the underlying Message Digest Algorithm (see Section
632 1).
634 The server sends:
636 { mpi(B) }
639 4.5 Client sends its evidence
641 The client calculates the shared context key K, and calculates the
642 evidence M1 that proves to the server that it knows the shared
643 context key K, including L as part of the calculation. K, on the
644 client's side is computed as follows:
646 x = H(s | H(U | ":" | p));
648 K = H2((B - g**x) ** (a + u * x) % N);
650 where:
652 H() is the result of digesting the designated input/data with the
653 underlying Message Digest Algorithm function (see Section 1).
655 p is the password value.
657 M1 is computed as:
659 H( bytes(H( bytes(N) )) ^ bytes( H( bytes(g) ))
660 | bytes(H( bytes(U) ))
661 | bytes(s)
662 | bytes(A)
663 | bytes(B)
664 | bytes(K)
665 | bytes(H( bytes(L) ))
666 )
671 Burdis & Naffah Expires May 5, 2002 [Page 12]
672 \f
673 Internet-Draft SRP SASL Mechanism November 2001
676 where:
678 ^ is the bitwise XOR operator.
680 The client sends:
682 { os(M1) }
685 4.6 Server sends its evidence
687 When the Confidentiality Protection service is requested and
688 approved, the server MUST NOT send M2 but instead conclude the SASL
689 exchange with the reception and verification of the client's M1.
690 Otherwise, M2 MUST be sent.
692 When the server has to send its evidence M2, which proves to the
693 client that it knows the shared context key K, as well as U, I, and
694 o, it shall compute it as follows:
696 H( bytes(A)
697 | bytes(M1)
698 | bytes(K)
699 | bytes(H( bytes(U) ))
700 | bytes(H( bytes(I) ))
701 | bytes(H( bytes(o) ))
702 )
704 The server OPTIONALLY sends:
706 { os(M2) }
727 Burdis & Naffah Expires May 5, 2002 [Page 13]
728 \f
729 Internet-Draft SRP SASL Mechanism November 2001
732 5. Security Layer
734 Depending on the options offered by the server and specified by the
735 client, the security layer may provide integrity protection, replay
736 detection, and/or confidentiality protection.
738 The security layer can be thought of as a three-stage filter through
739 which the data flows from the output of one stage to the input of the
740 following one. The first input is the original data, while the last
741 output is the data after being subject to the transformations of this
742 filter.
744 The data always passes through this three-stage filter, though any of
745 the stages may be inactive. Only when a stage is active would the
746 output be different from the input. In other words, if a stage is
747 inactive, the octet sequence at the output side is an exact duplicate
748 of the same sequence at the input side.
750 Schematically, the three-stage filter security layer appears as
751 follows:
753 +----------------------------+
754 | | I/ p1
755 p1 --->| Confidentiality protection |---+
756 | | | A/ c
757 +----------------------------+ |
758 |
759 +------------------------------------+
760 |
761 | +----------------------------+
762 | | | I/ p2
763 p2 +-->| Replay detection |---+
764 | | | A/ p2 | q
765 +----------------------------+ |
766 |
767 +------------------------------------+
768 |
769 | +----------------------------+
770 | | | I/ p3
771 p3 +-->| Integrity protection |--->
772 | | A/ p3 | C
773 +----------------------------+
775 where:
777 p1, p2 and p3 are the input octet sequences at each stage,
779 I/ denotes the output at the end of one stage if/when the stage is
783 Burdis & Naffah Expires May 5, 2002 [Page 14]
784 \f
785 Internet-Draft SRP SASL Mechanism November 2001
788 inactive or disabled,
790 A/ denotes the output at the end of one stage if/when the stage is
791 active or enabled,
793 c is the encrypted (sender-side) or decrypted (receiver-side)
794 octet sequence. c1 shall denote the value computed by the sender,
795 while c2 shall denote the value computed by the receiver.
797 q is a four-octet scalar quantity representing a sequence number,
799 C is the Message Authentication Code. C1 shall denote the value
800 of the MAC as computed by the sender, while C2 shall denote the
801 value computed by the receiver.
803 The following paragraphs detail each of the transformations mentioned
804 above.
806 5.1 Confidentiality Protection
808 The plaintext data octet sequence p1 is encrypted using the chosen
809 confidentiality algorithm (CALG) initialised for encryption with the
810 shared context key K.
812 c1 = CALG(K, ENCRYPTION)( bytes(p1) )
814 On the receiving side, the ciphertext data octet sequence p1 is
815 decrypted using the chosen confidentiality algorithm (CALG)
816 initialised for decryption, with the shared context key K.
818 c2 = CALG(K, DECRYPTION)( bytes(p1) )
820 The designated CALG block cipher should be used in OFB (Output
821 Feedback Block) mode in the ISO variant, as described in [HAC],
822 algorithm 7.20.
824 Let k be the block size of the chosen symmetric cipher algorithm;
825 e.g. for AES this is 128 bits or 16 octets. The OFB mode used shall
826 be of length/size k.
828 It is recommended that Block ciphers operating in OFB mode be used
829 with an Initial Vector (the mode's IV). For the SASL mechanisms
830 described in this document, the IV shall be an all-zero octet
831 sequence of size k.
833 In such a mode of operation - OFB with key re-use - the IV, which
834 need not be secret, must be changed. Otherwise an identical
835 keystream results; and, by XORing corresponding ciphertexts, an
839 Burdis & Naffah Expires May 5, 2002 [Page 15]
840 \f
841 Internet-Draft SRP SASL Mechanism November 2001
844 adversary may reduce cryptanalysis to that of a running-key cipher
845 with one plaintext as the running key. To counter the effect of
846 fixing the IV to an all-zero octet sequence, the sender should use a
847 one k-octet sequence as the value of its first block, constructed as
848 follows:
850 o the first (most significant) (k-2) octets are random,
852 o the octets at position #k-1 and #k, assuming the first octet is at
853 position #1, are exact copies of those at positions #1 and #2
854 respectively.
856 The input data to the confidentiality protection algorithm shall be a
857 multiple of the symmetric cipher block size k. When the input length
858 is not a multiple of k octets, the data shall be padded according to
859 the following scheme (described in [PKCS7] which itself is based on
860 [RFC-1423]):
862 Assuming the length of the input is l octets, (k - (l mod k))
863 octets, all having the value (k - (l mod k)), shall be appended to
864 the original data. In other words, the input is padded at the
865 trailing end with one of the following sequences:
867 01 -- if l mod k = k-1
868 02 02 -- if l mod k = k-2
869 ...
870 ...
871 ...
872 k k ... k k -- if l mod k = 0
874 The padding can be removed unambiguously since all input is padded
875 and no padding sequence is a suffix of another. This padding
876 method is well-defined if and only if k < 256 octets, which is the
877 case with symmetric block ciphers today, and in the forseeable
878 future.
880 The output of this stage, when it is active, is:
882 at the sending side: CALG(K, ENCRYPT)( bytes(p1) )
884 at the receiving side: CALG(K, DECRYPT)( bytes(p1) )
886 If the receiver, after decrypting the first block, finds that the
887 last two octets do not match the value of the first two, it MUST
888 signal an exception and abort the exchange.
895 Burdis & Naffah Expires May 5, 2002 [Page 16]
896 \f
897 Internet-Draft SRP SASL Mechanism November 2001
900 5.2 Replay Detection
902 A sequence number q is incremented every time a message is sent to
903 the peer.
905 The output of this stage, when it is active, is:
907 p2 | q
909 At the other end, the receiver increments its copy of the sequence
910 number. This new value of the sequence number is then used in the
911 integrity protection transformation, which must also be active as
912 described in Section 4.2. See Section 7.3 for more details.
914 5.3 Integrity Protection
916 When the Integrity Protection stage is active, a message
917 authentication code C is computed using the chosen integrity
918 protection algorithm (IALG) as follows:
920 o the IALG is initialised (once) with the shared context key K,
922 o the IALG is updated with every exchange of the sequence p3,
923 yielding the value C and a new IALG context for use in the
924 following exchange.
926 At the other end, the receiver computes its version of C, using the
927 same transformation, and checks that its value is equal to that
928 received. If the two values do not agree, the receiver must signal
929 an exception and abort.
931 The output of this stage, when it is active, is then:
933 IALG(K)( bytes(p3) )
936 5.4 Summary of Security Layer Output
938 The following table shows the data exchanged by the security layer
939 peers, depending on the possible legal combinations of the three
940 security services in operation:
951 Burdis & Naffah Expires May 5, 2002 [Page 17]
952 \f
953 Internet-Draft SRP SASL Mechanism November 2001
956 CP IP RD Peer sends/receives
958 I I I { eos(p) }
959 I A I { eos(p) | os( IALG(K)( bytes(p) ) ) }
960 I A A { eos(p) | os( IALG(K)( bytes(p) | bytes(q)) ) }
961 A I I { eos(c) }
962 A A I { eos(c) | os( IALG(K)( bytes(c) ) ) }
963 A A A { eos(c) | os( IALG(K)((bytes(c) | bytes(q)) ) }
965 where
967 CP Confidentiality protection,
969 IP Integrity protection,
971 RD Replay detection,
973 I Security service is Inactive/disabled,
975 A Security service is Active/enabled,
977 p The original plaintext,
979 q The sequence number.
981 c The enciphered input obtained by either:
983 CALG(K, ENCRYPT)( bytes(p) ) at the sender's side, or
985 CALG(K, DECRYPT)( bytes(p) ) at the receiver's side
1007 Burdis & Naffah Expires May 5, 2002 [Page 18]
1008 \f
1009 Internet-Draft SRP SASL Mechanism November 2001
1012 6. Example
1014 The example below uses SMTP authentication [RFC-2554]. The base64
1015 encoding of challenges and responses, as well as the reply codes
1016 preceding the responses are part of the SMTP authentication
1017 specification, not part of this SASL mechanism itself.
1019 "C:" and "S:" indicate lines sent by the client and server
1020 respectively.
1023 S: 220 smtp.example.com ESMTP server ready
1025 C: EHLO zaau.example.com
1027 S: 250-smtp.example.com
1028 S: 250 AUTH SRP-SHA-1 CRAM-MD5 DIGEST-MD5
1030 C: AUTH SRP-SHA-1 600HqPNDq
1032 with:
1034 U = "test"
1036 S: S010Anhsq4oIfgRyMRUNXE9M2.lShPb6OVk1/mnafGzjM1GetCfoxIWcUs1a.1rTsU
1037 XFTKZ4gjB0p4DpNz8gTe4/L3e23bfxRTdiCzWbHUQ5ZgpPXe5.zNwgkWf6AcMBmkJk5Nv
1038 UPFibrxgg0rq2jlq/tHpMT11rSC.fnqe7aHh57SxofUqEYFxW1PslI1wGsnaWV7IkGU75
1039 qOQMvqoveZuTqXKHIEr9B3LVLwdUYTrqkpw0opxs/KlitXXO2UG1ELwvg.7JdC3pbCfdC
1040 m477l32DWgLfZpgD33Wd6kDVZfs/ksbBN80zYVUkGrtYDjKbzKTPjbutByrexo3wSH7vv
1041 A/tC00G8A7MFEPSXzBIn8fW2kRM5kP65qRt9vFN9bS6nXUI1aPNHbOtHfRsuiScLmR65v
1042 86HbT6LZT6blRYnfRdHbPt9fT7azQ6rXOorpQ64nB6bkT6LdScbqUJreRM5ZBMraDInZR
1043 svcQMHbRdHfOMnfT7azOMLpB6DlRcPfP6LkT6bXR6bqUJrZONDqDInZRsvcQMHbRdHfOM
1044 nfT7azOcnlTsPfSsWiRM5uOdLcPcLoSsbwPJqoCJGtD3WpDZGp
1046 with:
1048 N = "2176617445861743577319100889180275378190766837425553851114464
1049 322468988623538384095721090901308605640157139971723580726658164960
1050 647214841029141336415219736447718088739565548373811507267740223510
1051 176252190156982074029314952962041933326626207347105454836873603951
1052 970248622650624886106025697180298495356112144268015766800076142998
1053 822245709041387397397017192709399211475176516806361476111961547623
1054 342209644278311797123637164733387141433589577347466730896705080700
1055 550932042479967841703686792831676127227423031406754829113358247958
1056 306143957755934710196177140617368437852270348349533703765500675132
1057 8447510550299250924469288819"
1059 g = "2"
1063 Burdis & Naffah Expires May 5, 2002 [Page 19]
1064 \f
1065 Internet-Draft SRP SASL Mechanism November 2001
1068 s = "138789728180301372082342"
1070 L = "mandatory=replay detection,replay detection,integrity=hmac-sh
1071 a1,integrity=hmac-md5,confidentiality=aes,confidentiality=cast5,co
1072 nfidentiality=blowfish,maxbuffersize=2147483643"
1074 C: 5V0G1w3jr4GvQN9j8rfg5eqaqOJzBCtFl2nWpvlb7uIBXZ/KzuHiQ/Bv8LfgG0zANi
1075 Nk3QUSSv5EpflNw7R.oLjFtg9nQiIPFdpCa5PB.Er3fmU3zIjMVQi9QJKo9mI6RKqeIlR
1076 QcG56d.s8zmJr/GSGF.HfPylv0o4YonxH4Q7UD8HL0oskwSjjExxRiaXik51Qjv4DlasS
1077 UIi6aWn7XhLcdPkuCDxWRelURWp3jjknuK8sOb25Oh5vtXqM81iGSZO2UGmDEjAY2roJ6
1078 oJLEIiTKnOAF6TgJ8XaIB05lfLU6geAy6m81WX8zIiNYZQXBhJLYRkiFMIA9FVVjRcr0c
1079 htVW00HqPNDq05LoPN1iONaWP6LqPMDqQMzkB6bkT6LdScbqUJreRM5ZBMraDInZRsvcQ
1080 MHbRdHfOMnfT7azOcnlTsPfSsWiRM5uOdLcPcLoSsbwPJqoCJGtD3WpDZGp
1082 with:
1084 A = "1540840307665744654003176437045463995983698152123540739506255
1085 167235184981369874100601341823577069818317928442714597863988388736
1086 761783769324538092721915238917488567908764625118970309039117506830
1087 582863492060359753878958333592304051308214607010237207906833581987
1088 891184516859028106830689778263784175551091596837339850972317447370
1089 786690976814652660651161408507908790872233230598691360594909211360
1090 681467576271644166275492362547607158772648745122532595439242971280
1091 059132327632664112420574698735613632927712799198248455476764164640
1092 093966784951741739596728324205805547296965925103620141665564971312
1093 0296669122592188812766443488"
1095 I = "test"
1097 o = "replay detection,integrity=hmac-md5,confidentiality=blowfish,
1098 maxbuffersize=2147483643"
1100 S: 420G1kVN1PjchzeajtjwwsnDoRlOVq11x7SzE70TBF/MD1G9rM49Prwk7Psr4z3til
1101 XTbiMvmPXzayzF5Sij9D2dW3HpgJ9pxrupfGpU4G5RKR0xv0ednxdjxkXizizfqvPHLk4
1102 APU9eC/m5ueZ9Xj3Vz1TwX.H7WGxz6sWQp6PnLgYbfP.klv6dW6wB./OIlyHLUzO34jjc
1103 8pzyb6Sq9Qpm7wz4k2hV/mf7YanCvdqAXctIv260LhooJAKnYv7RQoWrgZHsRBK6MnfW2
1104 cf/HoTs.puXJN9j.UpFWVgdb/kVZBkiSMr.x9fHAmwcr2Psb6SAh4o9.nliHIfE8MmgBV
1105 1zz6
1107 with:
1109 B = "1394806975793617459788496083554803630085100477069670229790536
1110 663039054654983798737214003146850157571057005545879038184930611817
1111 513956870847135668034099121265174715819508791670238346647996442928
1112 236952271233942847218179322401410928004797472055889044274301042822
1113 436472076200733427427417064560838528977725244677525054774294966690
1114 351389984931057296810093285460463200076154198365512418582103361801
1115 118376579659715751759450245145782015844858575973315196359638687590
1119 Burdis & Naffah Expires May 5, 2002 [Page 20]
1120 \f
1121 Internet-Draft SRP SASL Mechanism November 2001
1124 571237971749297255211039832183564686875820907022338494638496828197
1125 764735581518471732704627877884396733044981224764257023002764217815
1126 3897400684381472018003386182"
1128 C: L5Dz0j8MFVs3TyrnTLspZCIWq/mmo
1130 S: 235 Authentication successful.
1175 Burdis & Naffah Expires May 5, 2002 [Page 21]
1176 \f
1177 Internet-Draft SRP SASL Mechanism November 2001
1180 7. Discussion
1182 7.1 Mandatory Algorithms
1184 The algorithms specified as mandatory were chosen for utility and
1185 availablity. We felt that a mandatory confidentiality and integrity
1186 protection algorithm should be specified to ensure interoperability
1187 between implementations of these mechanisms.
1189 o The HMAC algorithm was chosen as an integrity algorithm because it
1190 is faster than MAC algorithms based on secret key encryption
1191 algorithms [RFC-2847].
1193 o Rijndael was chosen as a cipher because it has undergone thorough
1194 scrutiny by the best cryptographers in the world and was chosen
1195 ahead of many other algorithms as the Advanced Encryption
1196 Standard.
1198 Since confidentiality protection is optional this mechanism should be
1199 usable in countries that have strict controls on the use of
1200 cryptography.
1202 7.2 Modulus and generator values
1204 It is RECOMMENDED that the server use values for the modulus (N) and
1205 generator (g) chosen from those listed in Appendix A so that the
1206 client can avoid expensive constraint checks, since these predefined
1207 values already meet the constraints described in [RFC-2945]:
1209 "For maximum security, N should be a safe prime (i.e. a number of
1210 the form N = 2q + 1, where q is also prime). Also, g should be a
1211 generator modulo N (see [SRP] for details), which means that for
1212 any X where 0 < X < N, there exists a value x for which g^x % N ==
1213 X."
1216 7.3 Replay detection sequence number counters
1218 The mechanisms described in this document allow the use of a Replay
1219 Detection security service that works by including sequence number
1220 counters in the message authentication code (MAC) created by the
1221 Integrity Protection service. As noted in Section 4.2 integrity
1222 protection is always activated when the Replay Detection service is
1223 activated.
1225 Both the client and the server keep two sequence number counters.
1226 Each of these counters is a 32-bit unsigned integer initialised with
1227 a Starting Value and incremented by an Increment Value with every
1231 Burdis & Naffah Expires May 5, 2002 [Page 22]
1232 \f
1233 Internet-Draft SRP SASL Mechanism November 2001
1236 successful transmission of an SASL buffer through the security layer.
1237 The Sent counter is incremented for each buffer sent through the
1238 security layer. The Received counter is incremented for each buffer
1239 received through the security layer. If the value of a sequence
1240 number counter exceeds 2**32 it wraps around and starts from zero
1241 again.
1243 When a sender sends a buffer it includes the value of its Sent
1244 counter in the computation of the MAC accompanying each integrity
1245 protected message. When a recipient receives a buffer it uses the
1246 value of it's Received counter in its computation of the integrity
1247 protection MAC for the received message. The recipient's Received
1248 counter must be the same as the sender's Sent counter in order for
1249 the received and computed MACs to match.
1251 This specification assumes that for each sequence number counter the
1252 Starting Value is ZERO, and that the Increment Value is ONE. These
1253 values do not affect the security or the intended objective of the
1254 replay detection service, since they never travel on the wire.
1256 7.4 SASL Profile Considerations
1258 As mentioned briefly in [RFC-2222], and detailed in [SASL] a SASL
1259 specification has three layers: (a) a protocol definition using SASL
1260 known as the "Profile", (b) a SASL mechanism definition, and (c) the
1261 SASL framework.
1263 Point (3) in section 5 of [SASL] ("Protocol profile requirements")
1264 clearly states that it is the responsibility of the Profile to define
1265 "...how the challenges and responses are encoded, how the server
1266 indicates completion or failure of the exchange, how the client
1267 aborts an exchange, and how the exchange method interacts with any
1268 line length limits in the protocol."
1270 The username entity, referenced as "U" throughout this document, and
1271 used by the server to locate the password data, is assumed to travel
1272 "in the clear," meaning that no transformation is applied to its
1273 contents. This assumption was made to allow the same SRP password
1274 files to be used in these mechanisms, as those used with other SRP
1275 applications and tools.
1277 A Profile may decide, for privacy or other reason, to disallow such
1278 information to travel in the clear, and instead use a hashed version
1279 of U, or more generally a transformation function applied to U; i.e.
1280 f(U). Such a Profile would require additional tools to add the
1281 required entries to the SRP password files for the new value(s) of
1282 f(U). It is worth noting too that if this is the case, and the same
1283 user shall access the server through this mechanism as well as
1287 Burdis & Naffah Expires May 5, 2002 [Page 23]
1288 \f
1289 Internet-Draft SRP SASL Mechanism November 2001
1292 through other SRP tools, then at least two entries, one with U and
1293 the other with f(U) need to be present in the SRP password files if
1294 those same files are to be used for both types of access.
1343 Burdis & Naffah Expires May 5, 2002 [Page 24]
1344 \f
1345 Internet-Draft SRP SASL Mechanism November 2001
1348 8. Security Considerations
1350 These mechanisms rely on the security of SRP, which bases its
1351 security on the difficulty of solving the Diffie-Hellman problem in
1352 the multiplicative field modulo a large safe prime. See section 4
1353 "Security Considerations" of [RFC-2945] and section 4 "Security
1354 analysis" of [SRP].
1356 This mechanism also relies on the security of the HMAC algorithm and
1357 the underlying hash function when integrity protection is used.
1358 Section 6 "Security" of [RFC-2104] discusses these security issues in
1359 detail. Weaknesses found in MD5 do not impact HMAC-MD5 [DOBBERTIN].
1361 U, I, A and o, sent from the client to the server, and N, g, L, s and
1362 B, sent from the server to the client could be modified by an
1363 attacker before reaching the other party. For this reason, these
1364 values are included in the respective calculations of evidence (M1
1365 and M2) to prove that each party knows the session key. This allows
1366 each party to verify that these values were received unmodified.
1368 The use of integrity protection is RECOMMENDED to detect message
1369 tampering and to avoid session hijacking after authentication has
1370 taken place.
1372 Replay attacks may be avoided through the use of sequence numbers,
1373 because sequence numbers make each integrity protected message
1374 exchanged during a session different, and each session uses a
1375 different key.
1377 Research [KRAWCZYK] shows that the order and way of combining message
1378 encryption (Confidentiality Protection) and message authentication
1379 (Integrity Protection) are important. This mechanism follows the EtA
1380 (encrypt-then-authenticate) method and is "generically secure."
1399 Burdis & Naffah Expires May 5, 2002 [Page 25]
1400 \f
1401 Internet-Draft SRP SASL Mechanism November 2001
1404 9. Acknowledgements
1406 The following people provided valuable feedback in the preparation of
1407 this document:
1409 Stephen Farrell <stephen.farrell@baltimore.ie>
1411 Timothy Martin <tmartin@andrew.cmu.edu>
1413 Magnus Nystr÷m <magnus@rsasecurity.com>
1415 Thomas Wu <tom@arcot.com>
1455 Burdis & Naffah Expires May 5, 2002 [Page 26]
1456 \f
1457 Internet-Draft SRP SASL Mechanism November 2001
1460 References
1462 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
1463 Requirement Levels", BCP 0014, RFC 2119, March 1997,
1464 <http://www.ietf.org/rfc/rfc2119.txt>.
1466 [RFC-2440] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer,
1467 "OpenPGP Message Format", RFC 2440, November 1998,
1468 <http://www.ietf.org/rfc/rfc2440.txt>.
1470 [RFC-2279] Yergeau, F., "UTF-8, a transformation format of Unicode
1471 and ISO 10646", RFC 2279, January 1998,
1472 <http://www.ietf.org/rfc/rfc2279.txt>.
1474 [ISO-10646] "International Standard --Information technology--
1475 Universal Multiple-Octet Coded Character Set (UCS) --
1476 Part 1 Architecture and Basic Multilingual Plane",
1477 ISO/IEC 10646-1, 1993.
1479 [RIJNDAEL] Daemen, Joan. and Vincent. Rijmen, "AES Proposal:
1480 Rijndael", September 1999,
1481 <http://www.esat.kuleuven.ac.be/~rijmen/rijndael/>.
1483 [AES] National Institute of Standards and Technology,
1484 "Rijndael: NIST's Selection for the AES", December 2000,
1485 <http://csrc.nist.gov/encryption/aes/rijndael/Rijndael.pdf>
1486 .
1488 [DOBBERTIN] Dobbertin, H., "The Status of MD5 After a Recent
1489 Attack", December 1996,
1490 <ftp://ftp.rsasecurity.com/pub/cryptobytes/crypto2n2.pdf>
1491 .
1493 [RFC-2847] Eisler, M., "LIPKEY - A Low Infrastructure Public Key
1494 Mechanism Using SPKM", RFC 2847, June 2000,
1495 <http://www.ietf.org/rfc/rfc2847.txt>.
1497 [RFC-2104] Krawczyk, H., "HMAC: Keyed-Hashing for Message
1498 Authentication", RFC 2104, February 1997,
1499 <http://www.ietf.org/rfc/rfc2104.txt>.
1501 [RFC-2222] Myers, J., "Simple Authentication and Security Layer
1502 (SASL)", RFC 2222, October 1997,
1503 <http://www.ietf.org/rfc/rfc2222.txt>.
1505 [RFC-2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
1506 June 1999, <http://www.ietf.org/rfc/rfc2629.txt>.
1511 Burdis & Naffah Expires May 5, 2002 [Page 27]
1512 \f
1513 Internet-Draft SRP SASL Mechanism November 2001
1516 [SRP] Wu, T., "The Secure Remote Password Protocol", March
1517 1998, <http://srp.stanford.edu/srp/ndss.html>.
1519 [RFC-2945] Wu, T., "The SRP Authentication and Key Exchange
1520 System", RFC 2945, September 2000,
1521 <http://www.ietf.org/rfc/rfc2945.txt>.
1523 [SRP'] Wu, T., "SRP: The Open Source Password Authentication
1524 Standard", March 1998, <http://srp.stanford.edu/srp/>.
1526 [SCAN] Hopwood, D., "Standard Cryptographic Algorithm Naming",
1527 June 2000, <http://www.eskimo.com/~weidai/scan-mirror/>.
1529 [HAC] Menezes, A., van Oorschot, P. and S. Vanstone, "Handbook
1530 of Applied Cryptography", CRC Press, Inc., ISBN 0-8493-
1531 8523-7, 1997,
1532 <http://www.cacr.math.uwaterloo.ca/hac/about/chap7.ps>.
1534 [PKCS7] RSA Data Security, Inc., "PKCS #7: Cryptographic Message
1535 Syntax Standard", Version 1.5, November 1993,
1536 <ftp://ftp.rsasecurity.com/pub/pkcs/ascii/pkcs-7.asc>.
1538 [RFC-1423] Balenson, D., "Privacy Enhancement for Internet
1539 Electronic Mail: Part III: Algorithms, Modes, and
1540 Identifiers", RFC 1423, February 1993,
1541 <http://www.ietf.org/rfc/rfc1423.txt>.
1543 [RFC-2554] Myers, J., "SMTP Service Extension for Authentication",
1544 RFC 2554, March 1999.
1546 [KRAWCZYK] Krawczyk, H., "The order of encryption and
1547 authentication for protecting communications (Or: how
1548 secure is SSL?)", June 2001,
1549 <http://eprint.iacr.org/2001/045/>.
1551 [SASL] Myers, J., "Simple Authentication and Security Layer
1552 (SASL)", April 2001, <http://www.ietf.org/internet-
1553 drafts/draft-myers-saslrev-01.txt>.
1567 Burdis & Naffah Expires May 5, 2002 [Page 28]
1568 \f
1569 Internet-Draft SRP SASL Mechanism November 2001
1572 Authors' Addresses
1574 Keith Burdis
1575 Rhodes University
1576 Computer Science Department
1577 Grahamstown 6139
1578 ZA
1580 EMail: keith@rucus.ru.ac.za
1581 URI: http://www.cryptix.org/~keith/
1584 Raif S. Naffah
1585 Forge Research Pty. Limited
1586 Suite 116, Bay 9
1587 Locomotive Workshop,
1588 Australian Technology Park
1589 Cornwallis Street
1590 Eveleigh, NSW 1430
1591 AU
1593 EMail: raif@forge.com.au
1594 URI: http://www.cryptix.org/~raif/
1623 Burdis & Naffah Expires May 5, 2002 [Page 29]
1624 \f
1625 Internet-Draft SRP SASL Mechanism November 2001
1628 Appendix A. Modulus and Generator values
1630 Modulus (N) and generator (g) values for various modulus lengths are
1631 given below. In each case the modulus is a large safe prime and the
1632 generator is a primitve root of GF(n) [RFC-2945]. These values are
1633 taken from software developed by Tom Wu and Eugene Jhong for the
1634 Stanford SRP distribution [SRP'].
1637 [264 bits]
1638 Modulus (base 16) =
1639 115B8B692E0E045692CF280B436735C77A5A9E8A9E7ED56C965F87DB5B2A2ECE
1640 3
1641 Generator = 2
1643 [384 bits]
1644 Modulus (base 16) =
1645 8025363296FB943FCE54BE717E0E2958A02A9672EF561953B2BAA3BAACC3ED57
1646 54EB764C7AB7184578C57D5949CCB41B
1647 Generator = 2
1649 [512 bits]
1650 Modulus (base 16) =
1651 D4C7F8A2B32C11B8FBA9581EC4BA4F1B04215642EF7355E37C0FC0443EF756EA
1652 2C6B8EEB755A1C723027663CAA265EF785B8FF6A9B35227A52D86633DBDFCA43
1653 Generator = 2
1655 [640 bits]
1656 Modulus (base 16) =
1657 C94D67EB5B1A2346E8AB422FC6A0EDAEDA8C7F894C9EEEC42F9ED250FD7F0046
1658 E5AF2CF73D6B2FA26BB08033DA4DE322E144E7A8E9B12A0E4637F6371F34A207
1659 1C4B3836CBEEAB15034460FAA7ADF483
1660 Generator = 2
1662 [768 bits]
1663 Modulus (base 16) =
1664 B344C7C4F8C495031BB4E04FF8F84EE95008163940B9558276744D91F7CC9F40
1665 2653BE7147F00F576B93754BCDDF71B636F2099E6FFF90E79575F3D0DE694AFF
1666 737D9BE9713CEF8D837ADA6380B1093E94B6A529A8C6C2BE33E0867C60C3262B
1667 Generator = 2
1669 [1024 bits]
1670 Modulus (base 16) =
1671 EEAF0AB9ADB38DD69C33F80AFA8FC5E86072618775FF3C0B9EA2314C9C256576
1672 D674DF7496EA81D3383B4813D692C6E0E0D5D8E250B98BE48E495C1D6089DAD1
1673 5DC7D7B46154D6B6CE8EF4AD69B15D4982559B297BCF1885C529F566660E57EC
1674 68EDBC3C05726CC02FD4CBF4976EAA9AFD5138FE8376435B9FC61D2FC0EB06E3
1675 Generator = 2
1679 Burdis & Naffah Expires May 5, 2002 [Page 30]
1680 \f
1681 Internet-Draft SRP SASL Mechanism November 2001
1684 [1280 bits]
1685 Modulus (base 16) =
1686 D77946826E811914B39401D56A0A7843A8E7575D738C672A090AB1187D690DC4
1687 3872FC06A7B6A43F3B95BEAEC7DF04B9D242EBDC481111283216CE816E004B78
1688 6C5FCE856780D41837D95AD787A50BBE90BD3A9C98AC0F5FC0DE744B1CDE1891
1689 690894BC1F65E00DE15B4B2AA6D87100C9ECC2527E45EB849DEB14BB2049B163
1690 EA04187FD27C1BD9C7958CD40CE7067A9C024F9B7C5A0B4F5003686161F0605B
1691 Generator = 2
1693 [1536 bits]
1694 Modulus (base 16) =
1695 9DEF3CAFB939277AB1F12A8617A47BBBDBA51DF499AC4C80BEEEA9614B19CC4D
1696 5F4F5F556E27CBDE51C6A94BE4607A291558903BA0D0F84380B655BB9A22E8DC
1697 DF028A7CEC67F0D08134B1C8B97989149B609E0BE3BAB63D47548381DBC5B1FC
1698 764E3F4B53DD9DA1158BFD3E2B9C8CF56EDF019539349627DB2FD53D24B7C486
1699 65772E437D6C7F8CE442734AF7CCB7AE837C264AE3A9BEB87F8A2FE9B8B5292E
1700 5A021FFF5E91479E8CE7A28C2442C6F315180F93499A234DCF76E3FED135F9BB
1701 Generator = 2
1703 [2048 bits]
1704 Modulus (base 16) =
1705 AC6BDB41324A9A9BF166DE5E1389582FAF72B6651987EE07FC3192943DB56050
1706 A37329CBB4A099ED8193E0757767A13DD52312AB4B03310DCD7F48A9DA04FD50
1707 E8083969EDB767B0CF6095179A163AB3661A05FBD5FAAAE82918A9962F0B93B8
1708 55F97993EC975EEAA80D740ADBF4FF747359D041D5C33EA71D281E446B14773B
1709 CA97B43A23FB801676BD207A436C6481F1D2B9078717461A5B9D32E688F87748
1710 544523B524B0D57D5EA77A2775D2ECFA032CFBDBF52FB3786160279004E57AE6
1711 AF874E7303CE53299CCC041C7BC308D82A5698F3A8D0C38271AE35F8E9DBFBB6
1712 94B5C803D89F7AE435DE236D525F54759B65E372FCD68EF20FA7111F9E4AFF73
1713 Generator = 2
1735 Burdis & Naffah Expires May 5, 2002 [Page 31]
1736 \f
1737 Internet-Draft SRP SASL Mechanism November 2001
1740 Appendix B. Changes since last draft
1742 Added element size limits and changed SHOULD to MUST in Section 3.7.
1744 Added "mandatory" and "maxbuffersize" options, and changed SHOULD,
1745 SHOULD NOT to MUST and MUST NOT in Section 4.2.
1747 The salt s is now sent with N and g. The rationale is to make the
1748 exchanges, as well as the ordering of their elements, closer to [RFC-
1749 2945].
1751 Made sending the server evidence M2 conditional upon activation of
1752 Confidentiality Protection security service. Now, the server MUST
1753 only send M2 if Confidentiality Protection is not activated, and MUST
1754 NOT if it is.
1756 Changed the order of elements when computing both M1 (client's
1757 evidence) and M2 (server's evidence) to reflect the informal SRP
1758 convention, which is to place any "extra" data for the hash at the
1759 end.
1761 Added a new section, "Replay detection sequence number counters"
1762 (Section 7.3), that describes how these counters are used to provide
1763 replay detection.
1765 Added a new section, "SASL Profile Considerations," (Section 7.4)
1766 where various SASL profile related issues are covered.
1768 Updated the list of contributors.
1770 Changed the references to use symbolic names instead of numbers.
1791 Burdis & Naffah Expires May 5, 2002 [Page 32]
1792 \f
1793 Internet-Draft SRP SASL Mechanism November 2001
1796 Full Copyright Statement
1798 Copyright (C) The Internet Society (2001). All Rights Reserved.
1800 This document and translations of it may be copied and furnished to
1801 others, and derivative works that comment on or otherwise explain it
1802 or assist in its implementation may be prepared, copied, published
1803 and distributed, in whole or in part, without restriction of any
1804 kind, provided that the above copyright notice and this paragraph are
1805 included on all such copies and derivative works. However, this
1806 document itself may not be modified in any way, such as by removing
1807 the copyright notice or references to the Internet Society or other
1808 Internet organizations, except as needed for the purpose of
1809 developing Internet standards in which case the procedures for
1810 copyrights defined in the Internet Standards process must be
1811 followed, or as required to translate it into languages other than
1812 English.
1814 The limited permissions granted above are perpetual and will not be
1815 revoked by the Internet Society or its successors or assigns.
1817 This document and the information contained herein is provided on an
1818 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1819 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1820 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1821 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1822 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1824 Acknowledgement
1826 Funding for the RFC Editor function is currently provided by the
1827 Internet Society.
1847 Burdis & Naffah Expires May 5, 2002 [Page 33]
1848 \f