Initial release, version 0.0.0.
[gsasl.git] / doc / specification / draft-burdis-cat-srp-sasl-07.txt
blobedfc2dc3fa026da0c292b8164c0b8a0d85c9e78f
3 Network                                                        K. Burdis
4 Internet-Draft                                         Rhodes University
5 Expires: February 10, 2003                                     R. Naffah
6                                                           Forge Research
7                                                          August 12, 2002
10                  Secure Remote Password SASL Mechanism
11                       draft-burdis-cat-srp-sasl-07
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 http://
29    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 February 10, 2003.
36 Copyright Notice
38    Copyright (C) The Internet Society (2002).  All Rights Reserved.
40 Abstract
42    This document describes a SASL mechanism based on the Secure Remote
43    Password protocol.  This mechanism performs mutual authentication and
44    can provide a security layer with replay detection, integrity
45    protection and/or confidentiality protection.
55 Burdis & Naffah         Expires February 10, 2003               [Page 1]
57 Internet-Draft             SRP SASL Mechanism                August 2002
60 Table of Contents
62    1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  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 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  . . . . . . . . . . . 12
77    4.5   Client sends its evidence  . . . . . . . . . . . . . . . . . 12
78    4.6   Server sends its evidence  . . . . . . . . . . . . . . . . . 13
79    5.    Security Layer . . . . . . . . . . . . . . . . . . . . . . . 15
80    5.1   Cryptographic primitives . . . . . . . . . . . . . . . . . . 17
81    5.1.1 Pseudo random number generators  . . . . . . . . . . . . . . 17
82    5.1.2 Key derivation function  . . . . . . . . . . . . . . . . . . 18
83    5.2   Confidentiality Protection . . . . . . . . . . . . . . . . . 19
84    5.3   Replay Detection . . . . . . . . . . . . . . . . . . . . . . 20
85    5.4   Integrity Protection . . . . . . . . . . . . . . . . . . . . 21
86    5.5   Summary of Security Layer Output . . . . . . . . . . . . . . 21
87    6.    Example  . . . . . . . . . . . . . . . . . . . . . . . . . . 23
88    7.    Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 26
89    7.1   Mandatory Algorithms . . . . . . . . . . . . . . . . . . . . 26
90    7.2   Modulus and generator values . . . . . . . . . . . . . . . . 26
91    7.3   Replay detection sequence number counters  . . . . . . . . . 26
92    7.4   SASL Profile Considerations  . . . . . . . . . . . . . . . . 27
93    8.    Security Considerations  . . . . . . . . . . . . . . . . . . 29
94    9.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
95          References . . . . . . . . . . . . . . . . . . . . . . . . . 31
96          Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 33
97    A.    Modulus and Generator values . . . . . . . . . . . . . . . . 34
98    B.    Changes since the previous draft . . . . . . . . . . . . . . 36
99          Full Copyright Statement . . . . . . . . . . . . . . . . . . 38
111 Burdis & Naffah         Expires February 10, 2003               [Page 2]
113 Internet-Draft             SRP SASL Mechanism                August 2002
116 1. Introduction
118    The Secure Remote Password (SRP) is a password-based, zero-knowledge,
119    authentication and key-exchange protocol developed by Thomas Wu.  It
120    has good performance, is not plaintext-equivalent and maintains
121    perfect forward secrecy.  It provides authentication (optionally
122    mutual authentication) and the negotiation of a session key [SRP].
124    The mechanism described herein is based on the optimised SRP protocol
125    described at the end of section 3 in [RFC-2945], since this reduces
126    the total number of messages exchanged by grouping together pieces of
127    information that do not depend on earlier messages.  Due to the
128    design of the mechanism, mutual authentication is MANDATORY.
130    The SASL mechanism name associated with this protocol is "SRP".
167 Burdis & Naffah         Expires February 10, 2003               [Page 3]
169 Internet-Draft             SRP SASL Mechanism                August 2002
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 February 10, 2003               [Page 4]
225 Internet-Draft             SRP SASL Mechanism                August 2002
228 3. Data Element Formats
230    This section describes the encoding of the data elements used by the
231    SASL mechanism 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 February 10, 2003               [Page 5]
281 Internet-Draft             SRP SASL Mechanism                August 2002
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    This mechanism generates, uses and exchanges sequences of octets;
291    e.g.  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].  All text MUST be in Unicode
314    Normalization Form KC [UNICODE-KC] without NUL characters.
316    We shall use the syntax utf8(L) to denote the string L in UTF-8
317    encoding, preceded by a two-octet scalar quantity representing the
318    count of following octets.  Furthermore, we shall use the syntax
319    bytes(L) to denote the sequence of octets representing the UTF-8
320    encoding of L, in big-endian order.
322 3.6 Buffers
324    In this SASL mechanism data is exchanged between the client and
325    server using buffers.  A buffer acts as an envelope for the sequence
326    of data elements sent by one end-point of the exchange, and expected
327    by the other.
329    A buffer MAY NOT contain other buffers.  It may only contain zero,
330    one or more data elements.
335 Burdis & Naffah         Expires February 10, 2003               [Page 6]
337 Internet-Draft             SRP SASL Mechanism                August 2002
340    A buffer shall be encoded as two fields: a four-octet scalar quantity
341    representing the count of following octets, and the concatenation of
342    the octets of the data element(s) contained in the buffer.
344    We shall use the syntax {A|B|C} to denote a buffer containing A, B
345    and C in that order.  For example:
347       { mpi(N) | mpi(g) | utf8(L) }
349    is a buffer containing, in the designated order, the encoded forms of
350    an MPI N, an MPI g and a Text L.
352 3.7 Data Element Size Limits
354    The following table details the size limit, in number of octets, for
355    each of the SASL data element encodings described earlier.
357       Data element type          Header       Size limit in octets
358                                 (octets)       (excluding header)
359       ------------------------------------------------------------
360       Octet Sequence               1                  255
361       MPI                          2                 65,535
362       Text                         2                 65,535
363       Extended Octet Sequence      4             2,147,483,383
364       Buffer                       4             2,147,483,643
366    An implementation MUST signal an exception if any size constraint is
367    violated.
391 Burdis & Naffah         Expires February 10, 2003               [Page 7]
393 Internet-Draft             SRP SASL Mechanism                August 2002
396 4. Protocol Description
398    The following sections describe the sequence of data transmitted
399    between the client and server for the SRP SASL mechanism, as well as
400    the extra control information exchanged to enable a client to request
401    whether or not replay detection, integrity protection and/or
402    confidentiality protection should be provided by a security layer.
404    Mechanism data exchanges, during the authentication phase, are shown
405    below:
407        Client                                             Server
409          ---  { utf8(U) | utf8(I) }  ------------------------>
411          <--------  { mpi(N) | mpi(g) | os(s) | utf8(L) }  ---
413          ---  { mpi(A) | utf8(o) }  ------------------------->
415          <-----------------------------------  { mpi(B) }  ---
417          ---  { os(M1) }  ----------------------------------->
419                  ( no confidentiality protection )
421          <-----------------------------------  { os(M2) }  ---
423    where:
425       U     is the authentication identity (username),
427       I     is the authorisation identity,
429       N     is the safe prime modulus,
431       g     is the generator,
433       s     is the user's password salt,
435       L     is the options list indicating available security services,
437       A     is the client's ephemeral public key,
439       o     is the options list indicating chosen security services,
441       B     is the server's ephemeral public key,
443       M1    is the client's evidence that the shared key K is known,
447 Burdis & Naffah         Expires February 10, 2003               [Page 8]
449 Internet-Draft             SRP SASL Mechanism                August 2002
452       M2    is the server's evidence that the shared key K is known.
455 4.1 Client sends its identity
457    The client determines its authentication identity U and authorisation
458    identity I, encodes them and sends them to the server.
460    The client sends:
462       { utf8(U) | utf8(I) }
465 4.2 Server sends initial protocol elements
467    The server receives U, and looks up the safe prime modulus N, the
468    generator g, and the salt s to be used for that identity.
470    The server also creates an options list L, which consists of a comma-
471    separated list of option strings that specify the options the server
472    supports.  This options list MUST NOT contain any whitespace
473    characters and all alphabetic characters MUST be in lowercase.  When
474    used in digest calculations by the client the options list MUST be
475    used as received.
477    The following option strings are defined:
479    o  "mda=<message digest algorithm name>" indicates that the server
480       supports the designated hash function as the underlying Message
481       Digest Algorithm for the designated user to be used for all SRP
482       calculations - to compute both client-side and server-side
483       digests.  The specified algorithm MUST meet the requirements
484       specified in section 3.2 of [RFC-2945]:
486          "Any hash function used with SRP should produce an output of at
487          least 16 bytes and have the property that small changes in the
488          input cause significant nonlinear changes in the output."
490       Note that in the interests of interoperability between client and
491       server implementations and with other SRP-based tools, both the
492       client and the server MUST support SHA-160 as an underlying
493       Message Digest Algorithm.  While the server is not required to
494       list SHA-160 as an available underlying Message Digest Algorithm,
495       it must be able to do so.
497    o  "integrity=hmac-<MDA-name>" indicates that the server supports
498       integrity protection using the HMAC algorithm [RFC-2104] with
499       <MDA-name> as the underlying Message Digest Algorithm.  Acceptable
503 Burdis & Naffah         Expires February 10, 2003               [Page 9]
505 Internet-Draft             SRP SASL Mechanism                August 2002
508       MDA names are chosen from [SCAN] under the MessageDigest section.
509       A server SHOULD send such an option string for each HMAC algorithm
510       it supports.  The server MUST advertise at least one integrity
511       protection algorithm and in the interest of interoperability the
512       server SHOULD advertise support for the HMAC-SHA-160 algorithm.
514    o  "replay_detection" indicates that the server supports replay
515       detection using sequence numbers.  Replay detection SHALL NOT be
516       activated without also activating integrity protection.  If the
517       replay detection option is offered (by the server) and/or chosen
518       (by the client) without explicitly specifying an integrity
519       protection option, then the default integrity protection option
520       "integrity=hmac-sha-160" is implied and SHALL be activated.
522    o  "confidentiality=<cipher name>" indicates that the server supports
523       confidentiality protection using the symmetric key block cipher
524       algorithm <cipher name>.  The server SHOULD send such an option
525       string for each confidentiality protection algorithm it supports.
526       Note that in the interest of interoperability, if the server
527       offers confidentiality protection, it MUST send the option string
528       "confidentiality=aes" since it is then MANDATORY for it to provide
529       support for the [AES] algorithm.
531    o  "mandatory=[integrity|replay_detection|confidentiality]" is an
532       option only available to the server that indicates that the
533       specified security layer option is MANDATORY and MUST be chosen by
534       the client for use in the resulting security layer.  If a server
535       specifies an option as mandatory in this way, it MUST abort the
536       connection if the specified option is not chosen by the client.
537       It doesn't make sense for the client to send this option since it
538       is only able to choose options that the server advertises.  The
539       client SHOULD abort the connection if the server does not offer an
540       option that it requires.  If this option is not specified then
541       this implies that no options are mandatory.  The server SHOULD
542       always send the "mandatory=integrity" option indicating that
543       integrity protection is required.
545    o  "maxbuffersize=<number of bytes>" indicates to the peer the
546       maximum number of raw bytes (excluding the SASL buffer 4-byte
547       length header) to be processed by the security layer at a time, if
548       one is negotiated.  The value of <number of bytes> MUST NOT exceed
549       the Buffer size limit defined in section 3.7.  If this option is
550       not detected by a client or server mechanism, then it shall
551       operate its security layer on the assumption that the maximum
552       number of bytes that may be sent, to the peer server or client
553       mechanism respectively, is the Buffer data size limit indicated in
554       section 3.7.  On the other hand, if a recipient detects this
555       option, it shall break any octet-sequence longer than the
559 Burdis & Naffah         Expires February 10, 2003              [Page 10]
561 Internet-Draft             SRP SASL Mechanism                August 2002
564       designated limit into two or more fragments, each wrapped in a
565       SASL buffer, before sending them, in sequence, to the peer.
567    For example, if the server supports integrity protection using the
568    HMAC-SHA-160 and HMAC-MD5 algorithms, replay detection and no
569    confidentiality protection, the options list would be:
571       mda=sha-1,integrity=hmac-sha-160,integrity=hmac-
572       md5,replay_detection
574    The server sends:
576       { mpi(N) | mpi(g) | os(s) | utf8(L) }
579 4.3 Client sends its ephemeral public key
581    The client receives the options list L from the server that specifies
582    the Message Digest Algorithm(s) available to be used for all SRP
583    calculations, the security service options the server supports, and
584    the maximum buffer size the server can handle.  The client selects
585    options from this list and creates a new options list o that
586    specifies the selected Message Digest Algorithm to be used for SRP
587    calculations and the security services that will be used in the
588    security layer.  At most one available Message Digest Algorithm name,
589    one available integrity protection algorithm and one available
590    confidentiality protection algorithm may be selected.  In addition
591    the client may specify the maximum buffer size it can handle.  The
592    client MUST include any option specified by the mandatory option.
594    The client SHOULD always select an integrity protection algorithm
595    even if the server does not make it mandatory to do so.  If the
596    client selects a confidentiality protection algorithm it SHOULD then
597    also select an integrity protection algorithm.
599    This options list MUST NOT contain any whitespace characters and all
600    alphabetic characters MUST be in lowercase.  When used in digest
601    calculations by the server the options list MUST be used as received.
603    The client generates its ephemeral public key A as follows:
605       a = prng();
607       A = g**a % N;
609    where:
611       prng() is a random number generation function,
615 Burdis & Naffah         Expires February 10, 2003              [Page 11]
617 Internet-Draft             SRP SASL Mechanism                August 2002
620       a      is the MPI that will act as the client's private key,
622       **     is the exponentiation operator,
624       %      is the modulus operator,
626    The client sends:
628       { mpi(A) | utf8(o) }
631 4.4 Server sends its ephemeral public key
633    The server reads the client's verifier v, calculates the shared
634    context key K and generates its ephemeral public key B as follows:
636       b = prng();
638       B = (v + g**b) % N;
640       K = H2((A * v**u) ** b % N);
642    where:
644       b    is the MPI that will act as the server's private key,
646       v    is the stored password verifier value,
648       u    is a 32-bit unsigned integer which takes its value from the
649       first 32 bits of the hash of B, MSB first,
651       H2() is the "Interleaved SHA" function, as described in [RFC-
652       2945], but generalised to any message digest algorithm, and
653       applied using the underlying Message Digest Algorithm (see Section
654       4.2).
656    The server sends:
658       { mpi(B) }
661 4.5 Client sends its evidence
663    The client calculates the shared context key K, and calculates the
664    evidence M1 that proves to the server that it knows the shared
665    context key K, including I and L as part of the calculation.
667    K, on the client's side is computed as follows:
671 Burdis & Naffah         Expires February 10, 2003              [Page 12]
673 Internet-Draft             SRP SASL Mechanism                August 2002
676       x = H(s | H(U | ":" | p));
678       K = H2((B - g**x) ** (a + u * x) % N);
680    where:
682       H() is the result of digesting the designated input/data with the
683       underlying Message Digest Algorithm function (see Section 4.2).
685       p   is the password value.
687    M1 is computed as:
689             H(   bytes(H( bytes(N) )) ^ bytes( H( bytes(g) ))
690                | bytes(H( bytes(U) ))
691                | bytes(s)
692                | bytes(A)
693                | bytes(B)
694                | bytes(K)
695                | bytes(H( bytes(I) )
696                | bytes(H( bytes(L) ))
697             )
699    where:
701       ^ is the bitwise XOR operator.
703    All parameters received from the server that are used as input to a
704    digest operation MUST be used as received.
706    The client sends:
708       { os(M1) }
711 4.6 Server sends its evidence
713    When the Confidentiality Protection service is advertised by the
714    server and chosen by the client, the server MUST NOT send M2 but
715    instead conclude the SASL exchange after receiving and verifying the
716    client's M1.  Otherwise, M2 MUST be sent.
718    When the server has to send its evidence M2, which proves to the
719    client that it knows the shared context key K, as well as U, I and o,
720    it shall compute it as follows:
727 Burdis & Naffah         Expires February 10, 2003              [Page 13]
729 Internet-Draft             SRP SASL Mechanism                August 2002
732             H(   bytes(A)
733                | bytes(M1)
734                | bytes(K)
735                | bytes(H( bytes(U) ))
736                | bytes(H( bytes(I) ))
737                | bytes(H( bytes(o) ))
738             )
740    All parameters received from the client that are used as input to a
741    digest operation MUST be used as received.
743    If Confidentiality Protection was not negotiated the server sends:
745       { os(M2) }
783 Burdis & Naffah         Expires February 10, 2003              [Page 14]
785 Internet-Draft             SRP SASL Mechanism                August 2002
788 5. Security Layer
790    Section 3 of [RFC-2222] describes the operation of the security
791    layer:
793       "The security layer takes effect immediately following the last
794       response of the authentication exchange for data sent by the
795       client and the completion indication for data sent by the server.
796       Once the security layer is in effect, the protocol stream is
797       processed by the security layer into buffers of cipher-text.  Each
798       buffer is transferred over the connection as a stream of octets
799       prepended with a four octet field in network byte order that
800       represents the length of the following buffer.  The length of the
801       cipher-text buffer must be no larger than the maximum size that
802       was defined or negotiated by the other side."
804    Depending on the options offered by the server and chosen by the
805    client, the security layer may provide integrity protection, replay
806    detection, and/or confidentiality protection.
808    The security layer can be thought of as a three-stage filter through
809    which the data flows from the output of one stage to the input of the
810    following one.  The first input is the original data, while the last
811    output is the data after being subject to the transformations of this
812    filter.
814    The data always passes through this three-stage filter, though any of
815    the stages may be inactive.  Only when a stage is active would the
816    output be different from the input.  In other words, if a stage is
817    inactive, the octet sequence at the output side is an exact duplicate
818    of the same sequence at the input side.
820    Schematically, the three-stage filter security layer appears as
821    follows:
839 Burdis & Naffah         Expires February 10, 2003              [Page 15]
841 Internet-Draft             SRP SASL Mechanism                August 2002
844                  +----------------------------+
845                  |                            |     I/ p1
846          p1  --->| Confidentiality protection |---+
847                  |                            |   | A/ c
848                  +----------------------------+   |
849                                                   |
850              +------------------------------------+
851              |
852              |   +----------------------------+
853              |   |                            |     I/ p2
854          p2  +-->|      Replay detection      |---+
855                  |                            |   | A/ p2 | q
856                  +----------------------------+   |
857                                                   |
858              +------------------------------------+
859              |
860              |   +----------------------------+
861              |   |                            |     I/ p3
862          p3  +-->|    Integrity protection    |--->
863                  |                            |     A/ p3 | C
864                  +----------------------------+
866    where:
868       p1, p2 and p3 are the input octet sequences at each stage,
870       I/ denotes the output at the end of one stage if/when the stage is
871       inactive or disabled,
873       A/ denotes the output at the end of one stage if/when the stage is
874       active or enabled,
876       c is the encrypted (sender-side) or decrypted (receiver-side)
877       octet sequence.  c1 shall denote the value computed by the sender,
878       while c2 shall denote the value computed by the receiver.
880       q is a four-octet scalar quantity representing a sequence number,
882       C is the Message Authentication Code.  C1 shall denote the value
883       of the MAC as computed by the sender, while C2 shall denote the
884       value computed by the receiver.
886    It is worth noting here that both client and server have their own
887    distinct security contexts, including distinct encryption and
888    decryption sub-contexts.  In principal, nothing in this specification
889    should prevent an implementation from supporting asynchronous
890    connections.
895 Burdis & Naffah         Expires February 10, 2003              [Page 16]
897 Internet-Draft             SRP SASL Mechanism                August 2002
900 5.1 Cryptographic primitives
902 5.1.1 Pseudo random number generators
904    This mechanism requires random data to be generated for use in:
906    1.  The CALG key material and the cipher initial vectors (IVs) for
907        both the client and server when the Confidentiality Protection
908        service is enabled.
910    2.  The IALG key material for both the client and server when the
911        Integrity Protection service is enabled.
913    The PRNG used in this specification is based on the "UMacGenerator"
914    algorithm described in [UMAC].  It uses the [AES] algorithm, in its
915    256-bit key size variant, as the underlying symmetric key block
916    cipher for its operations.
918    A formal description of this PRNG follows:
920    o  Initialisation
922       *  SK: a 32-octet sequence (seeding key to AES)
924    o  Input
926       *  n: a positive integer
928    o  Output
930       *  Y: an n-octet sequence
932    o  Algorithm
934       *  (initialisation)
936          1.  Initialise an AES instance for encryption with the first 32
937              octets of SK as its user-supplied key material.  Let "aes"
938              be that instance; i.e.  aes = AES(SK, ENCRYPTION);
940          2.  Initialise T to be an all-zero 16-octet long sequence;
942       *  (for every input)
944          1.  Initialise "remaining" to n;
946          2.  Initialise Y to be a 0-length octet sequence;
951 Burdis & Naffah         Expires February 10, 2003              [Page 17]
953 Internet-Draft             SRP SASL Mechanism                August 2002
956          3.  while (remaining > 0) do
958              1.  T = aes(T);
960              2.  Append m octets from T to Y, where m is the minimum of
961                  16 and remaining;
963              3.  Subtract 16 from remaining;
965          4.  return Y;
967    In the rest of this document, "PRNG" will refer to this algorithm
968    with the initialisation parameter SK set to be the shared context key
969    K computed by the SRP calculations (see Section 4.4 and Section 4.5).
971    This algorithm MAY also be used as part of the SRP calculations to
972    generate the required "a" and "b" parameters used in creating the
973    client and server ephemeral private keys ("A" and "B").  In this case
974    the initialisation parameter SK can be any 32-octet sequence (e.g.
975    multiple representations of the time-of-day).
977    If the same PRNG instance is used for both the SRP calculations and
978    the calculations in this specification, it MUST be re-initialised
979    with the shared context key K before any of the latter calculations
980    are performed.
982 5.1.2 Key derivation function
984    During the authentication phase, both parties compute the shared
985    context key K (see Section 4.4 for the server, and Section 4.5 for
986    the client sides respectively).  The length of K is 2*s bits, where
987    "s" is the output length of the underlying Message Digest Algorithm
988    used in the SRP calculations (see "mda" option in Section 4.2).
990    When Confidentiality Protection is required, and the length of K is
991    not equal to the length of the user-supplied key material needed to
992    initialise the chosen Confidentiality Algorithm (CALG), the peers
993    MUST apply the Key Derivation Function (KDF) in order to obtain
994    enough data for this purpose.
996    Similarly, when Integrity Protection is required, and the length of K
997    is not equal to the required length of the key material needed to
998    initialise the chosen Integrity Algorithm (IALG), the peers MUST
999    apply the Key Derivation Function (KDF) in order to obtain enough
1000    data for this purpose too.
1002    We define this KDF as:
1007 Burdis & Naffah         Expires February 10, 2003              [Page 18]
1009 Internet-Draft             SRP SASL Mechanism                August 2002
1012       Km = KDF(K, n)
1014    where:
1016       Km: is the required key material,
1018       K: is the shared context key, and
1020       n: is the required length of Km.
1022    The following steps describe the KDF algorithm:
1024       If length of K is greater than or equal to n, then
1026          Let Km be the first n bytes of K;
1028       Else
1030          Let Km = PRNG(n);
1032       return Km
1035 5.2 Confidentiality Protection
1037    The plaintext data octet sequence p1 is encrypted using the chosen
1038    confidentiality algorithm (CALG) initialised for encryption with the
1039    key material Km obtained by applying the KDF to K (the shared context
1040    key K), and m (the key size of the chosen CALG) - see Section 5.1.2.
1042       Km = KDF(K, m)
1044       c1 = CALG(Km, ENCRYPTION)( bytes(p1) )
1046    On the receiving side, the ciphertext data octet sequence p1 is
1047    decrypted using the chosen confidentiality algorithm (CALG)
1048    initialised for decryption, with the key Km obtained by a similar
1049    process.
1051       Km = KDF(K, m)
1053       c2 = CALG(Km, DECRYPTION)( bytes(p1) )
1055    The designated CALG block cipher MUST be used in OFB (Output Feedback
1056    Block) mode in the ISO variant, as described in [HAC], algorithm
1057    7.20.
1059    Let k be the block size of the chosen symmetric key block cipher
1063 Burdis & Naffah         Expires February 10, 2003              [Page 19]
1065 Internet-Draft             SRP SASL Mechanism                August 2002
1068    algorithm; e.g.  for AES this is 128 bits or 16 octets.  The OFB mode
1069    used shall have a block size of k.
1071    It is recommended that Block ciphers operating in OFB mode be used
1072    with an Initial Vector (the mode's IV).  In such a mode of operation
1073    - OFB with key re-use - the IV need not be secret.  For the SASL
1074    mechanism described in this document, the IVs shall be:
1076       IV = PRNG(n);
1078    where n is the block size of the negotiated CALG.
1080    The input data to the confidentiality protection algorithm shall be a
1081    multiple of the symmetric key block cipher block size k.  When the
1082    input length is not a multiple of k octets, the data shall be padded
1083    according to the following scheme (described in [PKCS7] which itself
1084    is based on [RFC-1423]):
1086       Assuming the length of the input is l octets, (k - (l mod k))
1087       octets, all having the value (k - (l mod k)), shall be appended to
1088       the original data.  In other words, the input is padded at the
1089       trailing end with one of the following sequences:
1091                    01 -- if l mod k = k-1
1092                   02 02 -- if l mod k = k-2
1093                             ...
1094                             ...
1095                             ...
1096                 k k ... k k -- if l mod k = 0
1098       The padding can be removed unambiguously since all input is padded
1099       and no padding sequence is a suffix of another.  This padding
1100       method is well-defined if and only if k < 256 octets, which is the
1101       case with symmetric block ciphers today, and in the forseeable
1102       future.
1104    The output of this stage, when it is active, is:
1106       at the sending side: CALG(Km, ENCRYPT)( bytes(p1) )
1108       at the receiving side: CALG(Km, DECRYPT)( bytes(p1) )
1111 5.3 Replay Detection
1113    A sequence number q is incremented every time a message is sent to
1114    the peer.
1119 Burdis & Naffah         Expires February 10, 2003              [Page 20]
1121 Internet-Draft             SRP SASL Mechanism                August 2002
1124    The output of this stage, when it is active, is:
1126       p2 | q
1128    At the other end, the receiver increments its instance of the
1129    sequence number.  This new value of the sequence number is then used
1130    in the integrity protection transformation, which must also be active
1131    as described in Section 4.2.  See Section 7.3 for more details.
1133 5.4 Integrity Protection
1135    When the Integrity Protection stage is active, a message
1136    authentication code C is computed using the chosen integrity
1137    protection algorithm (IALG) as follows:
1139    o  the IALG is initialised (once) with the key material Kn obtained
1140       by applying the KDF to K (the shared context key K), and n (the
1141       required key size of the chosen IALG) - see Section 5.1.2; i.e.
1142       Kn = KDF(K, n),
1144    o  the IALG is updated with every exchange of the sequence p3,
1145       yielding the value C and a new IALG context for use in the
1146       following exchange.
1148    At the other end, the receiver computes its version of C, using the
1149    same transformation, and checks that its value is equal to that
1150    received.  If the two values do not agree, the receiver MUST signal
1151    an exception and abort.
1153    The output of this stage, when it is active, is then:
1155       IALG(Kn)( bytes(p3) )
1158 5.5 Summary of Security Layer Output
1160    The following table shows the data exchanged by the security layer
1161    peers, depending on the possible legal combinations of the three
1162    security services in operation:
1164       CP   IP   RD   Peer sends/receives
1166       I    I    I    { eos(p) }
1167       I    A    I    { eos(p) | os( IALG(K)( bytes(p) ) ) }
1168       I    A    A    { eos(p) | os( IALG(K)( bytes(p) | bytes(q)) ) }
1169       A    I    I    { eos(c) }
1170       A    A    I    { eos(c) | os( IALG(K)( bytes(c) ) ) }
1171       A    A    A    { eos(c) | os( IALG(K)((bytes(c) | bytes(q)) ) }
1175 Burdis & Naffah         Expires February 10, 2003              [Page 21]
1177 Internet-Draft             SRP SASL Mechanism                August 2002
1180    where
1182       CP    Confidentiality protection,
1184       IP    Integrity protection,
1186       RD    Replay detection,
1188       I     Security service is Inactive/disabled,
1190       A     Security service is Active/enabled,
1192       p     The original plaintext,
1194       q     The sequence number.
1196       c     The enciphered input obtained by either:
1198          CALG(Km, ENCRYPT)( bytes(p) ) at the sender's side, or
1200          CALG(Km, DECRYPT)( bytes(p) ) at the receiver's side
1231 Burdis & Naffah         Expires February 10, 2003              [Page 22]
1233 Internet-Draft             SRP SASL Mechanism                August 2002
1236 6. Example
1238    The example below uses SMTP authentication [RFC-2554].  The base64
1239    encoding of challenges and responses, as well as the reply codes
1240    preceding the responses are part of the SMTP authentication
1241    specification, not part of this SASL mechanism itself.
1243    "C:" and "S:" indicate lines sent by the client and server
1244    respectively.
1247     S: 220 smtp.example.com ESMTP server ready
1249     C: EHLO zaau.example.com
1251     S: 250-smtp.example.com
1252     S: 250 AUTH SRP CRAM-MD5 DIGEST-MD5
1254     C: AUTH SRP AAAADAAEdGVzdAAEdGVzdA==
1256      with:
1258        U = "test"
1260        I = "test"
1262     S: 334 AAABygEArGvbQTJKmpvxZt5eE4lYL69ytmUZh+4H/DGSlD21YFCjcynLtKCZ
1263     7YGT4HV3Z6E91SMSq0sDMQ3Nf0ip2gT9UOgIOWntt2ewz2CVF5oWOrNmGgX71fqq6Ck
1264     YqZYvC5O4Vfl5k+yXXuqoDXQK2/T/dHNZ0EHVwz6nHSgeRGsUdzvKl7Q6I/uAFna9IH
1265     pDbGSB8dK5B4cXRhpbnTLmiPh3SFRFI7UksNV9Xqd6J3XS7PoDLPvb9S+zeGFgJ5AE5
1266     Xrmr4dOcwPOUymczAQce8MI2CpWmPOo0MOCca41+Onb+7aUtcgD2J965DXeI21SX1R1
1267     m2XjcvzWjvIPpxEfnkr/cwABAgqsi3AvmIqdEbREALhtZGE9U0hBLTEsbWFuZGF0b3J
1268     5PXJlcGxheSBkZXRlY3Rpb24scmVwbGF5IGRldGVjdGlvbixpbnRlZ3JpdHk9aG1hYy
1269     1zaGExLGludGVncml0eT1obWFjLW1kNSxjb25maWRlbnRpYWxpdHk9YWVzLGNvbmZpZ
1270     GVudGlhbGl0eT1jYXN0NSxjb25maWRlbnRpYWxpdHk9Ymxvd2Zpc2gsbWF4YnVmZmVy
1271     c2l6ZT0yMTQ3NDgzNjQz
1273      with:
1275        N = "21766174458617435773191008891802753781907668374255538511144
1276        6432246898862353838409572109090130860564015713997172358072665816
1277        4960647214841029141336415219736447718088739565548373811507267740
1278        2235101762521901569820740293149529620419333266262073471054548368
1279        7360395197024862265062488610602569718029849535611214426801576680
1280        0076142998822245709041387397397017192709399211475176516806361476
1281        1119615476233422096442783117971236371647333871414335895773474667
1282        3089670508070055093204247996784170368679283167612722742303140675
1283        4829113358247958306143957755934710196177140617368437852270348349
1287 Burdis & Naffah         Expires February 10, 2003              [Page 23]
1289 Internet-Draft             SRP SASL Mechanism                August 2002
1292        5337037655006751328447510550299250924469288819"
1294        g = "2"
1296        s = "814819216327401865851972"
1298        L = "mda=sha-1,mandatory=replay_detection,replay_detection,integ
1299        rity=hmac-sha1,integrity=hmac-md5,confidentiality=aes,confidenti
1300        ality=cast5,confidentiality=blowfish,maxbuffersize=2147483643"
1302     C: AAABYwEAAp5q/4zhXoTUzXBscozN97SWgfDcAImIk3lNHNvd0b+Dr7jEm6upXblZ
1303     T5sL9mPgFsejlIh+B/eCu/HvzWCrXj6ylPZv8dy3LCH3LIORqQ45S7Lsbmrrg/dukDh
1304     4tZCJMLD4r3evzaY8KVhtJeLMVbeXuh4JljKP42Ll59Lzwf8jfPh4+4Lae1rpWUCL9D
1305     ueKcY+nN+xNHTit/ynLATxwL93P6+GoGY4TkUbUBfjiI1+rAMvyMDMw5XozGy07FOEc
1306     ++U0iPeXCQP4MT5FipOUoz8CYX7J1LbaXp2WJuFHlkyVXF7oCoyHbhld/5CfR3o6q/B
1307     /x9+yZRqaHH+JfllOgBfbWRhPVNIQS0xLHJlcGxheSBkZXRlY3Rpb24saW50ZWdyaXR
1308     5PWhtYWMtbWQ1LGNvbmZpZGVudGlhbGl0eT1ibG93ZmlzaCxtYXhidWZmZXJzaXplPT
1309     IxNDc0ODM2NDM=
1311      with:
1313        A = "33059541846712102497463123211304342021934496372587869281515
1314        9695658237779884462777478850394977744553746930451895815615888405
1315        0562780707370878253753979367019077142882237029766166623275718227
1316        6555389834190840322081091599089081947324537907613924707058150037
1317        7802790776231793962143786411792516760030102436603621046541729396
1318        6890613394379900527412007068242559299422872893332111365840536495
1319        1858834742328835373387573188369956379881606380890675411966073665
1320        1106922002294035533470301541999274557200666703389531481794516625
1321        4757418442215980634933876533189969562613241499465295849832999091
1322        40398081321840949606581251320320995783959866"
1324        o = mda=sha-1,replay_detection,integrity=hmac-md5,confidentialit
1325        y=blowfish,maxbuffersize=2147483643"
1327     S: 334 AAABAgEAOUKbXpnzMhziivGgMwm+FS8sKGSvjh5M3D+80RF/5z9rm0oPoi4+
1328     pF83fueWn4Hz9M+muF/22PHHZkHtlutDrtapj4OtirdxC21fS9bMtEh3F0whTX+3mPv
1329     thw5sk11turandHiLvcUZOgcrAGIoDKcBPoGyBud+8bMgpkf/uGfyBM2nEX/hV+oGgg
1330     X+LiHjmkxAJ3kewfQPH0eV9ffEuuyu8BUcBXkJsS6l7eWkuERSCttVOi/jS031c+CD/
1331     nuecUXYiF8IYzW03rbcwYhZzifmTi3VK9C8zG2K1WmGU+cDKlZMkyCPMmtCsxlbgE8z
1332     SHCuCiOgQ35XhcA0Qa0C3Q==
1334      with:
1336        B: "722842847565031844205403087285424428589273458129750231766015
1337        4465607827529853239240118185263492617243523916106658696965596526
1338        8585300845435562962039149169549800169184521786717633959469278439
1339        8771344445002432579509292115598435685062882631760796416554562980
1343 Burdis & Naffah         Expires February 10, 2003              [Page 24]
1345 Internet-Draft             SRP SASL Mechanism                August 2002
1348        8475896198325835507901319556929511421472132184990365213059654962
1349        7218189966140113906545856088040473723048909402258929560823932725
1350        2022154114087913895411927676707073040281136096806681758265221209
1351        8822374723416364340410020172215773934302794679034424699999611678
1352        9730443114919539575466941344964841591072763617954717789621871251
1353        71089179399349194452686682517183909017223901"
1355     C: AAAAFRTkoju6xGP+zH89iaDWIFjfIKt5Kg==
1357     S: 235 Authentication successful.
1399 Burdis & Naffah         Expires February 10, 2003              [Page 25]
1401 Internet-Draft             SRP SASL Mechanism                August 2002
1404 7. Discussion
1406 7.1 Mandatory Algorithms
1408    The algorithms specified as mandatory were chosen for utility and
1409    availablity.  We felt that a mandatory confidentiality and integrity
1410    protection algorithm for the security layer and a mandatory Message
1411    Digest Algorithm for SRP calculations should be specified to ensure
1412    interoperability between implementations of this mechanism:
1414    o  The SHA-160 Message Digest Algorithm was chosen as an underlying
1415       algorithm for SRP calculations because this allows for easy
1416       interoperability with other SRP-based tools that use the SRP-SHA1
1417       protocol described in section 3 of [RFC-2945] and create their
1418       password files using this algorithm.
1420    o  The HMAC algorithm was chosen as an integrity algorithm because it
1421       is faster than MAC algorithms based on secret key encryption
1422       algorithms [RFC-2847].
1424    o  AES was chosen as a cipher because it has undergone thorough
1425       scrutiny by the best cryptographers in the world.
1427    Since confidentiality protection is optional, this mechanism should
1428    be usable in countries that have strict controls on the use of
1429    cryptography.
1431 7.2 Modulus and generator values
1433    It is RECOMMENDED that the server use values for the modulus (N) and
1434    generator (g) chosen from those listed in Appendix A so that the
1435    client can avoid expensive constraint checks, since these predefined
1436    values already meet the constraints described in [RFC-2945]:
1438       "For maximum security, N should be a safe prime (i.e.  a number of
1439       the form N = 2q + 1, where q is also prime).  Also, g should be a
1440       generator modulo N (see [SRP] for details), which means that for
1441       any X where 0 < X < N, there exists a value x for which g**x % N
1442       == X."
1445 7.3 Replay detection sequence number counters
1447    The mechanism described in this document allows the use of a Replay
1448    Detection security service that works by including sequence number
1449    counters in the message authentication code (MAC) created by the
1450    Integrity Protection service.  As noted in Section 4.2 integrity
1451    protection is always activated when the Replay Detection service is
1455 Burdis & Naffah         Expires February 10, 2003              [Page 26]
1457 Internet-Draft             SRP SASL Mechanism                August 2002
1460    activated.
1462    Both the client and the server keep two sequence number counters.
1463    Each of these counters is a 32-bit unsigned integer initialised with
1464    a Starting Value and incremented by an Increment Value with every
1465    successful transmission of an SASL buffer through the security layer.
1466    The Sent counter is incremented for each buffer sent through the
1467    security layer.  The Received counter is incremented for each buffer
1468    received through the security layer.  If the value of a sequence
1469    number counter exceeds 2**32-1 it wraps around and starts from zero
1470    again.
1472    When a sender sends a buffer it includes the value of its Sent
1473    counter in the computation of the MAC accompanying each integrity
1474    protected message.  When a recipient receives a buffer it uses the
1475    value of it's Received counter in its computation of the integrity
1476    protection MAC for the received message.  The recipient's Received
1477    counter must be the same as the sender's Sent counter in order for
1478    the received and computed MACs to match.
1480    This specification assumes that for each sequence number counter the
1481    Starting Value is ZERO, and that the Increment Value is ONE.  These
1482    values do not affect the security or the intended objective of the
1483    replay detection service, since they never travel on the wire.
1485 7.4 SASL Profile Considerations
1487    As mentioned briefly in [RFC-2222], and detailed in [SASL] a SASL
1488    specification has three layers: (a) a protocol definition using SASL
1489    known as the "Profile", (b) a SASL mechanism definition, and (c) the
1490    SASL framework.
1492    Point (3) in section 5 of [SASL] ("Protocol profile requirements")
1493    clearly states that it is the responsibility of the Profile to define
1494    "...how the challenges and responses are encoded, how the server
1495    indicates completion or failure of the exchange, how the client
1496    aborts an exchange, and how the exchange method interacts with any
1497    line length limits in the protocol."
1499    The username entity, referenced as "U" throughout this document, and
1500    used by the server to locate the password data, is assumed to travel
1501    "in the clear," meaning that no transformation is applied to its
1502    contents.  This assumption was made to allow the same SRP password
1503    files to be used in this mechanism, as those used with other SRP
1504    applications and tools.
1506    A Profile may decide, for privacy or other reason, to disallow such
1507    information to travel in the clear, and instead use a hashed version
1511 Burdis & Naffah         Expires February 10, 2003              [Page 27]
1513 Internet-Draft             SRP SASL Mechanism                August 2002
1516    of U, or more generally a transformation function applied to U; i.e.
1517    f(U).  Such a Profile would require additional tools to add the
1518    required entries to the SRP password files for the new value(s) of
1519    f(U).  It is worth noting too that if this is the case, and the same
1520    user shall access the server through this mechanism as well as
1521    through other SRP tools, then at least two entries, one with U and
1522    the other with f(U) need to be present in the SRP password files if
1523    those same files are to be used for both types of access.
1567 Burdis & Naffah         Expires February 10, 2003              [Page 28]
1569 Internet-Draft             SRP SASL Mechanism                August 2002
1572 8. Security Considerations
1574    This mechanism relies on the security of SRP, which bases its
1575    security on the difficulty of solving the Diffie-Hellman problem in
1576    the multiplicative field modulo a large safe prime.  See section 4
1577    "Security Considerations" of [RFC-2945] and section 4 "Security
1578    analysis" of [SRP].
1580    B, the server's ephemeral public key, is computed as g**b + v = g**b
1581    + g**x, which is symmetric and allows two guesses per *active
1582    attack*.  In practical terms, this makes no difference to the
1583    security of SRP, since the number of active attacks needed is still
1584    linearly proportional to the number of guesses needed; only the
1585    constant factor (2 vs.  1) has changed.
1587    This mechanism also relies on the security of the HMAC algorithm and
1588    the underlying hash function when integrity protection is used.
1589    Section 6 "Security" of [RFC-2104] discusses these security issues in
1590    detail.  Weaknesses found in MD5 do not impact HMAC-MD5 [DOBBERTIN].
1592    U, A, I and o, sent from the client to the server, and N, g, L, s and
1593    B, sent from the server to the client could be modified by an
1594    attacker before reaching the other party.  For this reason, these
1595    values are included in the respective calculations of evidence (M1
1596    and M2) to prove that each party knows the session key K.  This
1597    allows each party to verify that these values were received
1598    unmodified.
1600    The use of integrity protection is RECOMMENDED to detect message
1601    tampering and to avoid session hijacking after authentication has
1602    taken place.
1604    Replay attacks may be avoided through the use of sequence numbers,
1605    because sequence numbers make each integrity protected message
1606    exchanged during a session different, and each session uses a
1607    different key.
1609    Research [KRAWCZYK] shows that the order and way of combining message
1610    encryption (Confidentiality Protection) and message authentication
1611    (Integrity Protection) are important.  This mechanism follows the EtA
1612    (encrypt-then-authenticate) method and is "generically secure."
1614    This mechanism uses a Pseudo-Random Number Generator (PRNG) for
1615    generating some of its parameters.  Section 5.1.1 describes a
1616    securely seeded, cryptographically strong PRNG implementation for
1617    this purpose.
1623 Burdis & Naffah         Expires February 10, 2003              [Page 29]
1625 Internet-Draft             SRP SASL Mechanism                August 2002
1628 9. Acknowledgements
1630    The following people provided valuable feedback in the preparation of
1631    this document:
1633       Stephen Farrell <stephen.farrell@baltimore.ie>
1635       Timothy Martin <tmartin@andrew.cmu.edu>
1637       Alexey Melnikov <mel@messagingdirect.com>
1639       Ken Murchison <ken@oceana.com>
1641       Magnus Nystrom <magnus@rsasecurity.com>
1643       Thomas Wu <tom@arcot.com>
1679 Burdis & Naffah         Expires February 10, 2003              [Page 30]
1681 Internet-Draft             SRP SASL Mechanism                August 2002
1684 References
1686    [AES]         National Institute of Standards and Technology,
1687                  "Rijndael: NIST's Selection for the AES", December
1688                  2000, <http://csrc.nist.gov/encryption/aes/rijndael/
1689                  Rijndael.pdf>.
1691    [DOBBERTIN]   Dobbertin, H., "The Status of MD5 After a Recent
1692                  Attack", December 1996, <ftp://ftp.rsasecurity.com/pub/
1693                  cryptobytes/crypto2n2.pdf>.
1695    [HAC]         Menezes, A., van Oorschot, P. and S. Vanstone,
1696                  "Handbook of Applied Cryptography", CRC Press, Inc.,
1697                  ISBN 0-8493-8523-7, 1997, <http://
1698                  www.cacr.math.uwaterloo.ca/hac/about/chap7.ps>.
1700    [ISO-10646]   "International Standard --Information technology--
1701                  Universal Multiple-Octet Coded Character Set (UCS) --
1702                  Part 1 Architecture and Basic Multilingual Plane. UTF-8
1703                  is described in Annex R, adopted but not yet published.
1704                  UTF-16 is described in Annex Q, adopted but not yet
1705                  published.", ISO/IEC 10646-1, 1993.
1707    [KRAWCZYK]    Krawczyk, H., "The order of encryption and
1708                  authentication for protecting communications (Or: how
1709                  secure is SSL?)", June 2001, <http://eprint.iacr.org/
1710                  2001/045/>.
1712    [PKCS7]       RSA Data Security, Inc., "PKCS #7: Cryptographic
1713                  Message Syntax Standard", Version 1.5, November 1993,
1714                  <ftp://ftp.rsasecurity.com/pub/pkcs/ascii/pkcs-7.asc>.
1716    [RFC-1423]    Balenson, D., "Privacy Enhancement for Internet
1717                  Electronic Mail: Part III: Algorithms, Modes, and
1718                  Identifiers", RFC 1423, February 1993, <http://
1719                  www.ietf.org/rfc/rfc1423.txt>.
1721    [RFC-2104]    Krawczyk, H., "HMAC: Keyed-Hashing for Message
1722                  Authentication", RFC 2104, February 1997, <http://
1723                  www.ietf.org/rfc/rfc2104.txt>.
1725    [RFC-2119]    Bradner, S., "Key words for use in RFCs to Indicate
1726                  Requirement Levels", BCP 0014, RFC 2119, March 1997,
1727                  <http://www.ietf.org/rfc/rfc2119.txt>.
1729    [RFC-2222]    Myers, J., "Simple Authentication and Security Layer
1730                  (SASL)", RFC 2222, October 1997, <http://www.ietf.org/
1731                  rfc/rfc2222.txt>.
1735 Burdis & Naffah         Expires February 10, 2003              [Page 31]
1737 Internet-Draft             SRP SASL Mechanism                August 2002
1740    [RFC-2279]    Yergeau, F., "UTF-8, a transformation format of Unicode
1741                  and ISO 10646", RFC 2279, January 1998, <http://
1742                  www.ietf.org/rfc/rfc2279.txt>.
1744    [RFC-2440]    Callas, J., Donnerhacke, L., Finney, H. and R. Thayer,
1745                  "OpenPGP Message Format", RFC 2440, November 1998,
1746                  <http://www.ietf.org/rfc/rfc2440.txt>.
1748    [RFC-2554]    Myers, J., "SMTP Service Extension for Authentication",
1749                  RFC 2554, March 1999.
1751    [RFC-2629]    Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
1752                  June 1999, <http://www.ietf.org/rfc/rfc2629.txt>.
1754    [RFC-2847]    Eisler, M., "LIPKEY - A Low Infrastructure Public Key
1755                  Mechanism Using SPKM", RFC 2847, June 2000, <http://
1756                  www.ietf.org/rfc/rfc2847.txt>.
1758    [RFC-2945]    Wu, T., "The SRP Authentication and Key Exchange
1759                  System", RFC 2945, September 2000, <http://
1760                  www.ietf.org/rfc/rfc2945.txt>.
1762    [SASL]        Myers, J., "Simple Authentication and Security Layer
1763                  (SASL)", April 2001, <http://www.ietf.org/internet-
1764                  drafts/draft-myers-saslrev-01.txt>.
1766    [SCAN]        Hopwood, D., "Standard Cryptographic Algorithm Naming",
1767                  June 2000, <http://www.eskimo.com/~weidai/scan-mirror/
1768                  >.
1770    [SRP]         Wu, T., "The Secure Remote Password Protocol", March
1771                  1998, <http://srp.stanford.edu/ndss.html>.
1773    [SRP-impl]    Wu, T., "SRP: The Open Source Password Authentication
1774                  Standard", March 1998, <http://srp.stanford.edu/srp/>.
1776    [UMAC]        Krovetz, T., Black, J., Halevi, S., Hevia, A.,
1777                  Krawczyk, H. and P. Rogaway, "UMAC: Message
1778                  Authentication Code using Universal Hashing", October
1779                  2000, <http://www.ietf.org/internet-drafts/draft-
1780                  krovetz-umac-01.txt>.
1782    [UNICODE-KC]  Durst, D., "Unicode Standard Annex #15: Unicode
1783                  Normalization Forms.", March 2001, <http://
1784                  www.unicode.org/unicode/reports/tr15>.
1791 Burdis & Naffah         Expires February 10, 2003              [Page 32]
1793 Internet-Draft             SRP SASL Mechanism                August 2002
1796 Authors' Addresses
1798    Keith Burdis
1799    Rhodes University
1800    Computer Science Department
1801    Grahamstown  6139
1802    ZA
1804    EMail: keith@rucus.ru.ac.za
1807    Raif S. Naffah
1808    Forge Research Pty. Limited
1809    Suite 116, Bay 9
1810    Locomotive Workshop,
1811    Australian Technology Park
1812    Cornwallis Street
1813    Eveleigh, NSW  1430
1814    AU
1816    EMail: raif@forge.com.au
1847 Burdis & Naffah         Expires February 10, 2003              [Page 33]
1849 Internet-Draft             SRP SASL Mechanism                August 2002
1852 Appendix A. Modulus and Generator values
1854    Modulus (N) and generator (g) values for various modulus lengths are
1855    given below.  In each case the modulus is a large safe prime and the
1856    generator is a primitve root of GF(n) [RFC-2945].  These values are
1857    taken from software developed by Tom Wu and Eugene Jhong for the
1858    Stanford SRP distribution [SRP-impl].
1861       [264 bits]
1862         Modulus (base 16) =
1863           115B8B692E0E045692CF280B436735C77A5A9E8A9E7ED56C965F87DB5B2A2
1864           ECE3
1865         Generator = 2
1867       [384 bits]
1868         Modulus (base 16) =
1869           8025363296FB943FCE54BE717E0E2958A02A9672EF561953B2BAA3BAACC3E
1870           D5754EB764C7AB7184578C57D5949CCB41B
1871         Generator = 2
1873       [512 bits]
1874         Modulus (base 16) =
1875           D4C7F8A2B32C11B8FBA9581EC4BA4F1B04215642EF7355E37C0FC0443EF75
1876           6EA2C6B8EEB755A1C723027663CAA265EF785B8FF6A9B35227A52D86633DB
1877           DFCA43
1878         Generator = 2
1880       [640 bits]
1881         Modulus (base 16) =
1882           C94D67EB5B1A2346E8AB422FC6A0EDAEDA8C7F894C9EEEC42F9ED250FD7F0
1883           046E5AF2CF73D6B2FA26BB08033DA4DE322E144E7A8E9B12A0E4637F6371F
1884           34A2071C4B3836CBEEAB15034460FAA7ADF483
1885         Generator = 2
1887       [768 bits]
1888         Modulus (base 16) =
1889           B344C7C4F8C495031BB4E04FF8F84EE95008163940B9558276744D91F7CC9
1890           F402653BE7147F00F576B93754BCDDF71B636F2099E6FFF90E79575F3D0DE
1891           694AFF737D9BE9713CEF8D837ADA6380B1093E94B6A529A8C6C2BE33E0867
1892           C60C3262B
1893         Generator = 2
1895       [1024 bits]
1896         Modulus (base 16) =
1897           EEAF0AB9ADB38DD69C33F80AFA8FC5E86072618775FF3C0B9EA2314C9C256
1898           576D674DF7496EA81D3383B4813D692C6E0E0D5D8E250B98BE48E495C1D60
1899           89DAD15DC7D7B46154D6B6CE8EF4AD69B15D4982559B297BCF1885C529F56
1903 Burdis & Naffah         Expires February 10, 2003              [Page 34]
1905 Internet-Draft             SRP SASL Mechanism                August 2002
1908           6660E57EC68EDBC3C05726CC02FD4CBF4976EAA9AFD5138FE8376435B9FC6
1909           1D2FC0EB06E3
1910         Generator = 2
1912       [1280 bits]
1913         Modulus (base 16) =
1914           D77946826E811914B39401D56A0A7843A8E7575D738C672A090AB1187D690
1915           DC43872FC06A7B6A43F3B95BEAEC7DF04B9D242EBDC481111283216CE816E
1916           004B786C5FCE856780D41837D95AD787A50BBE90BD3A9C98AC0F5FC0DE744
1917           B1CDE1891690894BC1F65E00DE15B4B2AA6D87100C9ECC2527E45EB849DEB
1918           14BB2049B163EA04187FD27C1BD9C7958CD40CE7067A9C024F9B7C5A0B4F5
1919           003686161F0605B
1920         Generator = 2
1922       [1536 bits]
1923         Modulus (base 16) =
1924           9DEF3CAFB939277AB1F12A8617A47BBBDBA51DF499AC4C80BEEEA9614B19C
1925           C4D5F4F5F556E27CBDE51C6A94BE4607A291558903BA0D0F84380B655BB9A
1926           22E8DCDF028A7CEC67F0D08134B1C8B97989149B609E0BE3BAB63D4754838
1927           1DBC5B1FC764E3F4B53DD9DA1158BFD3E2B9C8CF56EDF019539349627DB2F
1928           D53D24B7C48665772E437D6C7F8CE442734AF7CCB7AE837C264AE3A9BEB87
1929           F8A2FE9B8B5292E5A021FFF5E91479E8CE7A28C2442C6F315180F93499A23
1930           4DCF76E3FED135F9BB
1931         Generator = 2
1933       [2048 bits]
1934         Modulus (base 16) =
1935           AC6BDB41324A9A9BF166DE5E1389582FAF72B6651987EE07FC3192943DB56
1936           050A37329CBB4A099ED8193E0757767A13DD52312AB4B03310DCD7F48A9DA
1937           04FD50E8083969EDB767B0CF6095179A163AB3661A05FBD5FAAAE82918A99
1938           62F0B93B855F97993EC975EEAA80D740ADBF4FF747359D041D5C33EA71D28
1939           1E446B14773BCA97B43A23FB801676BD207A436C6481F1D2B9078717461A5
1940           B9D32E688F87748544523B524B0D57D5EA77A2775D2ECFA032CFBDBF52FB3
1941           786160279004E57AE6AF874E7303CE53299CCC041C7BC308D82A5698F3A8D
1942           0C38271AE35F8E9DBFBB694B5C803D89F7AE435DE236D525F54759B65E372
1943           FCD68EF20FA7111F9E4AFF73
1944         Generator = 2
1959 Burdis & Naffah         Expires February 10, 2003              [Page 35]
1961 Internet-Draft             SRP SASL Mechanism                August 2002
1964 Appendix B. Changes since the previous draft
1966    Removed the references to Rijndael since, strictly speaking it is not
1967    the AES.  This should also eliminate any ambiguities as to the
1968    required block and key sizes this specification refers to when
1969    mentioning the AES.
1971    Removed the requirement for (a) an all-zero IV, and (b) a dummy first
1972    block in the operations of the Confidentiality Service filter.
1974    Included the description of a secure PRNG.
1976    Included the description of a Key Derivation Function (KDF) to ensure
1977    there will always be enough bytes to initialise both the CALG and
1978    IALG from the shared context key computed by the SRP calculations.
1980    Added a paragraph before the end of the "Security layer" section to
1981    clarify that this specification does not mandate nor imply a lockstep
1982    in operating the security services.
1984    Added a paragraph to the "Security considerations" section about the
1985    quality of the PRNG to use.
1987    Added the restriction that all text should be in Unicode
1988    Normalization form KC with NULs prohibited.
1990    Tightened up the restrictions on the options lists L and o by
1991    specifying that they must not contain any whitespace and must always
1992    be in lowercase.  Changed "replay detection" to "replay_detection".
1993    This should simplify parsing of these lists.
1995    Added explicit notes that parameters received from the other party
1996    must be used as received in all digest calculations.  Clearly any
1997    alteration of these input parameters (such as changing the case of
1998    text) will prevent the digest calculations on each side from
1999    producing the same result.
2001    Made it mandatory for the server to advertise at least one integrity
2002    protection algorithm and recommended that the HMAC-SHA-160 algorithm
2003    always be advertised.  Recommended that the server always make
2004    integrity protection mandatory.
2006    Recommended that the client always select integrity protection, even
2007    if the server does not make it mandatory to do so.  Also recommended
2008    that the client always select integrity protection when it selects
2009    confidentiality protection.
2011    Added Alexey Melnikov to Section 9.
2015 Burdis & Naffah         Expires February 10, 2003              [Page 36]
2017 Internet-Draft             SRP SASL Mechanism                August 2002
2020    Added a quote from section 3 of [RFC-2222] to the description of the
2021    security layer in Section 8 to describe the operation of the security
2022    layer in SASL.
2024    TODO: Amend the Cryptix SASL library and re-generate the example.
2071 Burdis & Naffah         Expires February 10, 2003              [Page 37]
2073 Internet-Draft             SRP SASL Mechanism                August 2002
2076 Full Copyright Statement
2078    Copyright (C) The Internet Society (2002).  All Rights Reserved.
2080    This document and translations of it may be copied and furnished to
2081    others, and derivative works that comment on or otherwise explain it
2082    or assist in its implementation may be prepared, copied, published
2083    and distributed, in whole or in part, without restriction of any
2084    kind, provided that the above copyright notice and this paragraph are
2085    included on all such copies and derivative works.  However, this
2086    document itself may not be modified in any way, such as by removing
2087    the copyright notice or references to the Internet Society or other
2088    Internet organizations, except as needed for the purpose of
2089    developing Internet standards in which case the procedures for
2090    copyrights defined in the Internet Standards process must be
2091    followed, or as required to translate it into languages other than
2092    English.
2094    The limited permissions granted above are perpetual and will not be
2095    revoked by the Internet Society or its successors or assigns.
2097    This document and the information contained herein is provided on an
2098    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
2099    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
2100    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
2101    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
2102    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2104 Acknowledgement
2106    Funding for the RFC Editor function is currently provided by the
2107    Internet Society.
2127 Burdis & Naffah         Expires February 10, 2003              [Page 38]