Initial release, version 0.0.0.

[gsasl.git] / doc / specification / draft-burdis-cat-srp-sasl-06.txt

Network Working Group                                        K.R. Burdis
Internet-Draft                                         Rhodes University
Expires: July 13, 2002                                         R. Naffah
                                                          Forge Research
                                                        January 12, 2002


                 Secure Remote Password SASL Mechanism
                      draft-burdis-cat-srp-sasl-06

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on July 13, 2002.

Copyright Notice

   Copyright (C) The Internet Society (2002). All Rights Reserved.

Abstract

   This document describes a SASL mechanism based on the Secure Remote
   Password protocol.  This mechanism performs mutual authentication
   and can provide a security layer with replay detection, integrity
   protection and/or confidentiality protection.









Burdis & Naffah          Expires July 13, 2002                  [Page 1]
\f
Internet-Draft             SRP SASL Mechanism               January 2002


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions Used in this Document  . . . . . . . . . . . . . .  4
   3.  Data Element Formats . . . . . . . . . . . . . . . . . . . . .  5
   3.1 Scalar numbers . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.2 Multi-Precision Integers . . . . . . . . . . . . . . . . . . .  5
   3.3 Octet Sequences  . . . . . . . . . . . . . . . . . . . . . . .  6
   3.4 Extended Octet Sequences . . . . . . . . . . . . . . . . . . .  6
   3.5 Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.6 Buffers  . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.7 Data Element Size Limits . . . . . . . . . . . . . . . . . . .  7
   4.  Protocol Description . . . . . . . . . . . . . . . . . . . . .  8
   4.1 Client sends its identity  . . . . . . . . . . . . . . . . . .  9
   4.2 Server sends initial protocol elements . . . . . . . . . . . .  9
   4.3 Client sends its ephemeral public key  . . . . . . . . . . . . 11
   4.4 Server sends its ephemeral public key  . . . . . . . . . . . . 11
   4.5 Client sends its evidence  . . . . . . . . . . . . . . . . . . 12
   4.6 Server sends its evidence  . . . . . . . . . . . . . . . . . . 13
   5.  Security Layer . . . . . . . . . . . . . . . . . . . . . . . . 14
   5.1 Confidentiality Protection . . . . . . . . . . . . . . . . . . 15
   5.2 Replay Detection . . . . . . . . . . . . . . . . . . . . . . . 16
   5.3 Integrity Protection . . . . . . . . . . . . . . . . . . . . . 17
   5.4 Summary of Security Layer Output . . . . . . . . . . . . . . . 17
   6.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
   7.  Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 22
   7.1 Mandatory Algorithms . . . . . . . . . . . . . . . . . . . . . 22
   7.2 Modulus and generator values . . . . . . . . . . . . . . . . . 22
   7.3 Replay detection sequence number counters  . . . . . . . . . . 22
   7.4 SASL Profile Considerations  . . . . . . . . . . . . . . . . . 23
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 25
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
       References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29
   A.  Modulus and Generator values . . . . . . . . . . . . . . . . . 30
   B.  Changes since the previous draft . . . . . . . . . . . . . . . 32
       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 33














Burdis & Naffah          Expires July 13, 2002                  [Page 2]
\f
Internet-Draft             SRP SASL Mechanism               January 2002


1. Introduction

   The Secure Remote Password (SRP) is a password-based,
   zero-knowledge, authentication and key-exchange protocol developed
   by Thomas Wu.  It has good performance, is not plaintext-equivalent
   and maintains perfect forward secrecy.  It provides authentication
   (optionally mutual authentication) and the negotiation of a session
   key [SRP].

   The mechanism described herein is based on the optimised SRP
   protocol described at the end of section 3 in [RFC-2945], since this
   reduces the total number of messages exchanged by grouping together
   pieces of information that do not depend on earlier messages.  Due
   to the design of the mechanism, mutual authentication is MANDATORY.

   The SASL mechanism name associated with this protocol is "SRP".



































Burdis & Naffah          Expires July 13, 2002                  [Page 3]
\f
Internet-Draft             SRP SASL Mechanism               January 2002


2. Conventions Used in this Document

   o  A hex digit is an element of the set: 

         {0, 1, 2, 3, 4, 5, 6, 7, 8 , 9, A, B, C, D, E, F}

      A hex digit is the representation of a 4-bit string.  Examples: 

         7 = 0111

         A = 1010

   o  An octet is an 8-bit string.  In this document an octet may be
      written as a pair of hex digits.  Examples: 

         7A = 01111010

         02 = 00000010

   o  All data is encoded and sent in network byte order (big-endian).

   o  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
      "OPTIONAL" in this document are to be interpreted as described in
      [RFC-2119]. 


























Burdis & Naffah          Expires July 13, 2002                  [Page 4]
\f
Internet-Draft             SRP SASL Mechanism               January 2002


3. Data Element Formats

   This section describes the encoding of the data elements used by the
   SASL mechanism described in this document.

3.1 Scalar numbers

   Scalar numbers are unsigned quantities.  Using b[k] to refer to the
   k-th octet being processed, the value of a two-octet scalar is: 

      ((b[0] << 8) + b[1]),

   where << is the bit left-shift operator.  The value of a four-octet
   scalar is: 

      ((b[0] << 24) + (b[1] << 16) + (b[2] << 8) + b[3]).

3.2 Multi-Precision Integers

   Multi-Precision Integers, or MPIs, are positive integers used to
   hold large integers used in cryptographic computations.

   MPIs are encoded using a scheme inspired by that used by OpenPGP -
   [RFC-2440] (section 3.2) - for encoding such entities: 

      The encoded form of an MPI SHALL consist of two pieces: a
      two-octet scalar that represents the length of the entity, in
      octets, followed by a sequence of octets that contain the actual
      integer.

      These octets form a big-endian number; A big-endian number can be
      encoded by prefixing it with the appropriate length.

      Examples: (all numbers are in hexadecimal) 

         The sequence of octets [00 01 01] encodes an MPI with the
         value 1, while the sequence [00 02 01 FF] encodes an MPI with
         the value of 511.

      Additional rule: 

      *  The length field of an encoded MPI describes the octet count
         starting from the MPI's first non-zero octet, containing the
         most significant non-zero bit.  Thus, the encoding [00 02 01]
         is not formed correctly; It should be [00 01 01].

   We shall use the syntax mpi(A) to denote the encoded form of the
   multi-precision integer A.  Furthermore, we shall use the syntax
   bytes(A) to denote the big-endian sequence of octets forming the


Burdis & Naffah          Expires July 13, 2002                  [Page 5]
\f
Internet-Draft             SRP SASL Mechanism               January 2002


   multi-precision integer with the most significant octet being the
   first non-zero octet containing the most significant bit of A.

3.3 Octet Sequences

   This mechanism generates, uses and exchanges sequences of octets;
   e.g. output values of message digest algorithm functions.  When such
   entities travel on the wire, they shall be preceded by a one-octet
   scalar quantity representing the count of following octets.

   We shall use the syntax os(s) to denote the encoded form of the
   octet sequence.  Furthermore, we shall use the syntax bytes(s) to
   denote the sequence of octets s, in big-endian order.

3.4 Extended Octet Sequences

   Extended sequences of octets are exchanged when using the security
   layer.  When these sequences travel on the wire, they shall be
   preceded by a four-octet scalar quantity representing the count of
   following octets. 

   We shall use the syntax eos(s) to denote the encoded form of the
   extended octet sequence.  Furthermore, we shall use the syntax
   bytes(s) to denote the sequence of octets s, in big-endian order.

3.5 Text

   The only character set for text is the UTF-8 encoding [RFC-2279] of
   Unicode characters [ISO-10646].

   We shall use the syntax utf8(L) to denote the string L in UTF-8
   encoding, preceded by a two-octet scalar quantity representing the
   count of following octets.  Furthermore, we shall use the syntax
   bytes(L) to denote the sequence of octets representing the UTF-8
   encoding of L, in big-endian order.

3.6 Buffers

   In this SASL mechanism data is exchanged between the client and
   server using buffers.  A buffer acts as an envelope for the sequence
   of data elements sent by one end-point of the exchange, and expected
   by the other.

   A buffer MAY NOT contain other buffers.  It may only contain zero,
   one or more data elements.

   A buffer shall be encoded as two fields: a four-octet scalar
   quantity representing the count of following octets, and the
   concatenation of the octets of the data element(s) contained in the


Burdis & Naffah          Expires July 13, 2002                  [Page 6]
\f
Internet-Draft             SRP SASL Mechanism               January 2002


   buffer.

   We shall use the syntax {A|B|C} to denote a buffer containing A, B
   and C in that order.  For example: 

      { mpi(N) | mpi(g) | utf8(L) }

   is a buffer containing, in the designated order, the encoded forms
   of an MPI N, an MPI g and a Text L.

3.7 Data Element Size Limits

   The following table details the size limit, in number of octets, for
   each of the SASL data element encodings described earlier.

      Data element type          Header       Size limit in octets
                                (octets)       (excluding header)
      ------------------------------------------------------------
      Octet Sequence               1                  255
      MPI                          2                 65,535
      Text                         2                 65,535
      Extended Octet Sequence      4             2,147,483,383
      Buffer                       4             2,147,483,643

   An implementation MUST signal an exception if any size constraint is
   violated.

























Burdis & Naffah          Expires July 13, 2002                  [Page 7]
\f
Internet-Draft             SRP SASL Mechanism               January 2002


4. Protocol Description

   The following sections describe the sequence of data transmitted
   between the client and server for the SRP SASL mechanism, as well as
   the extra control information exchanged to enable a client to
   request whether or not replay detection, integrity protection and/or
   confidentiality protection should be provided by a security layer.

   Mechanism data exchanges, during the authentication phase, are shown
   below:

       Client                                             Server

         ---  { utf8(U) | utf8(I) }  ------------------------>

         <--------  { mpi(N) | mpi(g) | os(s) | utf8(L) }  ---

         ---  { mpi(A) | utf8(o) }  ------------------------->

         <-----------------------------------  { mpi(B) }  ---

         ---  { os(M1) }  ----------------------------------->

                              ( optionally )

         <-----------------------------------  { os(M2) }  ---

   where: 

      U     is the authentication identity (username),

      I     is the authorisation identity,

      N     is the safe prime modulus,

      g     is the generator,

      s     is the user's password salt,

      L     is the options list indicating available security services,

      A     is the client's ephemeral public key,

      o     is the options list indicating chosen security services,

      B     is the server's ephemeral public key,

      M1    is the client's evidence that the shared key K is known,



Burdis & Naffah          Expires July 13, 2002                  [Page 8]
\f
Internet-Draft             SRP SASL Mechanism               January 2002


      M2    is the server's evidence that the shared key K is known.

4.1 Client sends its identity

   The client determines its authentication identity U and
   authorisation identity I, encodes them and sends them to the server.

   The client sends: 

      { utf8(U) | utf8(I) }

4.2 Server sends initial protocol elements

   The server receives U, and looks up the safe prime modulus N, the
   generator g, and the salt s to be used for that identity.

   The server also creates an options list L, which consists of a
   comma-separated list of option strings that specify the options the
   server supports.  This options list MUST NOT be interpreted in a
   case-sensitive manner, and whitespace characters MUST be ignored.

   The following option strings are defined: 

   o  "mda=<message digest algorithm name>" indicates that the server
      supports the designated hash function as the underlying Message
      Digest Algorithm for the designated user to be used for all SRP
      calculations - to compute both client-side and server-side
      digests.  The specified algorithm MUST meet the requirements
      specified in section 3.2 of [RFC-2945]: 

         "Any hash function used with SRP should produce an output of
         at least 16 bytes and have the property that small changes in
         the input cause significant nonlinear changes in the output."

      Note that in the interests of interoperability between client and
      server implementations and with other SRP-based tools, both the
      client and the server MUST support SHA-160 as an underlying
      Message Digest Algorithm.  While the server is not required to
      list SHA-160 as an available underlying Message Digest Algorithm,
      it must be able to do so.

   o  "integrity=HMAC-<MDA-name>" indicates that the server supports
      integrity protection using the HMAC algorithm [RFC-2104] with
      <MDA-name> as the underlying Message Digest Algorithm. 
      Acceptable MDA names are chosen from [SCAN] under the
      MessageDigest section.  A server SHOULD send such an option
      string for each HMAC algorithm it supports.  Note that in the
      interest of interoperability, if the server offers integrity
      protection it MUST, as a minimum, send the option string


Burdis & Naffah          Expires July 13, 2002                  [Page 9]
\f
Internet-Draft             SRP SASL Mechanism               January 2002


      "integrity=HMAC-SHA-160" since support for this algorithm is then
      MANDATORY.

   o  "replay detection" indicates that the server supports replay
      detection using sequence numbers.  Replay detection SHALL NOT be
      activated without also activating integrity protection.  If the
      replay detection option is offered (by the server) and/or chosen
      (by the client) without explicitely specifying an integrity
      protection option, then the default integrity protection option
      "integrity=HMAC-SHA-160" is implied and shall be activated.

   o  "confidentiality=<cipher name>" indicates that the server
      supports confidentiality protection using the symmetric block
      cipher algorithm <cipher name>.  The server SHOULD send such an
      option string for each confidentiality protection algorithm it
      supports. Note that in the interest of interoperability, if the
      server offers confidentiality protection, it MUST send the option
      string "confidentiality=aes" since it is then MANDATORY for it to
      provide support for this algorithm.  (Rijndael [RIJNDAEL] is
      synonymous with AES [AES].)

   o  "mandatory=[integrity|replay detection|confidentiality]" is an
      option only available to the server that indicates that the
      specified security layer option is MANDATORY and MUST be chosen
      by the client for use in the resulting security layer.  If a
      server specifies an option as mandatory in this way, it MUST
      abort the connection if the specified option is not chosen by the
      client.  It doesn't make sense for the client to send this option
      since it is only able to choose options that the server
      advertises.  The client SHOULD abort the connection if the server
      does not offer an option that it requires.  If this option is not
      specified then this implies that no options are mandatory.

   o  "maxbuffersize=<number of bytes>" indicates to the peer the
      maximum number of raw bytes (excluding the SASL buffer 4-byte
      length header) to be processed by the security layer at a time,
      if one is negotiated.  The value of <number of bytes> MUST NOT
      exceed the Buffer size limit defined in section 3.7.  If this
      option is not detected by a client or server mechanism, then it
      shall operate its security layer on the assumption that the
      maximum number of bytes that may be sent, to the peer server or
      client mechanism respectively, is the Buffer data size limit
      indicated in section 3.7.  On the other hand, if a recipient
      detects this option, it shall break any octet-sequence longer
      than the designated limit into two or more fragments, each
      wrapped in a SASL buffer, before sending them, in sequence, to
      the peer.

   For example, if the server supports integrity protection using the


Burdis & Naffah          Expires July 13, 2002                 [Page 10]
\f
Internet-Draft             SRP SASL Mechanism               January 2002


   HMAC-SHA-160 and HMAC-MD5 algorithms, replay detection and no
   confidentiality protection, the options list would be: 

      mda=SHA-1,integrity=HMAC-SHA-160,integrity=HMAC-MD5,replay
      detection

   The server sends: 

      { mpi(N) | mpi(g) | os(s) | utf8(L) }

4.3 Client sends its ephemeral public key

   The client receives the options list L from the server that
   specifies the Message Digest Algorithm(s) available to be used for
   all SRP calculations, the security service options the server
   supports, and the maximum buffer size the server can handle.  The
   client selects options from this list and creates a new options list
   o that specifies the selected Message Digest Algorithm to be used
   for SRP calculations and the security services that will be used in
   the security layer.  At most one available Message Digest Algorithm
   name, one available integrity protection algorithm and one available
   confidentiality protection algorithm may be selected.  The client
   MUST include any option specified by the mandatory option.

   The client generates its ephemeral public key A as follows: 

      a = prng();

      A = g**a % N;

   where: 

      prng() is a random number generation function,

      a      is the MPI that will act as the client's private key,

      **     is the exponentiation operator,

      %      is the modulus operator,

   The client sends: 

      { mpi(A) | utf8(o) }

4.4 Server sends its ephemeral public key

   The server reads the client's verifier v, calculates the shared
   context key K and generates its ephemeral public key B as follows: 



Burdis & Naffah          Expires July 13, 2002                 [Page 11]
\f
Internet-Draft             SRP SASL Mechanism               January 2002


      b = prng();

      B = (v + g**b) % N;

      K = H2((A * v**u) ** b % N);

   where: 

      b    is the MPI that will act as the server's private key,

      v    is the stored password verifier value,

      u    is a 32-bit unsigned integer which takes its value from the
      first 32 bits of the hash of B, MSB first,

      H2() is the "Interleaved SHA" function, as described in
      [RFC-2945], but generalised to any message digest algorithm, and
      applied using the underlying Message Digest Algorithm (see
      Section 4.2).

   The server sends: 

      { mpi(B) }

4.5 Client sends its evidence

   The client calculates the shared context key K, and calculates the
   evidence M1 that proves to the server that it knows the shared
   context key K, including I and L as part of the calculation.  K, on
   the client's side is computed as follows: 

      x = H(s | H(U | ":" | p));

      K = H2((B - g**x) ** (a + u * x) % N);

   where: 

      H() is the result of digesting the designated input/data with the
      underlying Message Digest Algorithm function (see Section 4.2).

      p   is the password value.

   M1 is computed as: 








Burdis & Naffah          Expires July 13, 2002                 [Page 12]
\f
Internet-Draft             SRP SASL Mechanism               January 2002


            H(   bytes(H( bytes(N) )) ^ bytes( H( bytes(g) ))
               | bytes(H( bytes(U) ))
               | bytes(s)
               | bytes(A)
               | bytes(B)
               | bytes(K)
               | bytes(H( bytes(I) )
               | bytes(H( bytes(L) ))
            )

   where: 

      ^ is the bitwise XOR operator.

   The client sends: 

      { os(M1) }

4.6 Server sends its evidence

   When the Confidentiality Protection service is requested and
   approved, the server MUST NOT send M2 but instead conclude the SASL
   exchange with the reception and verification of the client's M1. 
   Otherwise, M2 MUST be sent.

   When the server has to send its evidence M2, which proves to the
   client that it knows the shared context key K, as well as U, I and
   o, it shall compute it as follows: 

            H(   bytes(A)
               | bytes(M1)
               | bytes(K)
               | bytes(H( bytes(U) ))
               | bytes(H( bytes(I) ))
               | bytes(H( bytes(o) ))
            )

   The server OPTIONALLY sends: 

      { os(M2) }











Burdis & Naffah          Expires July 13, 2002                 [Page 13]
\f
Internet-Draft             SRP SASL Mechanism               January 2002


5. Security Layer

   Depending on the options offered by the server and specified by the
   client, the security layer may provide integrity protection, replay
   detection, and/or confidentiality protection.

   The security layer can be thought of as a three-stage filter through
   which the data flows from the output of one stage to the input of
   the following one.  The first input is the original data, while the
   last output is the data after being subject to the transformations
   of this filter.

   The data always passes through this three-stage filter, though any
   of the stages may be inactive.  Only when a stage is active would
   the output be different from the input.  In other words, if a stage
   is inactive, the octet sequence at the output side is an exact
   duplicate of the same sequence at the input side.

   Schematically, the three-stage filter security layer appears as
   follows: 

                 +----------------------------+
                 |                            |     I/ p1
         p1  --->| Confidentiality protection |---+
                 |                            |   | A/ c
                 +----------------------------+   |
                                                  |
             +------------------------------------+
             |
             |   +----------------------------+
             |   |                            |     I/ p2
         p2  +-->|      Replay detection      |---+
                 |                            |   | A/ p2 | q
                 +----------------------------+   |
                                                  |
             +------------------------------------+
             |
             |   +----------------------------+
             |   |                            |     I/ p3
         p3  +-->|    Integrity protection    |--->
                 |                            |     A/ p3 | C
                 +----------------------------+

   where: 

      p1, p2 and p3 are the input octet sequences at each stage,

      I/ denotes the output at the end of one stage if/when the stage
      is inactive or disabled,


Burdis & Naffah          Expires July 13, 2002                 [Page 14]
\f
Internet-Draft             SRP SASL Mechanism               January 2002


      A/ denotes the output at the end of one stage if/when the stage
      is active or enabled,

      c is the encrypted (sender-side) or decrypted (receiver-side)
      octet sequence.  c1 shall denote the value computed by the
      sender, while c2 shall denote the value computed by the receiver.

      q is a four-octet scalar quantity representing a sequence number,

      C is the Message Authentication Code.  C1 shall denote the value
      of the MAC as computed by the sender, while C2 shall denote the
      value computed by the receiver.

   The following paragraphs detail each of the transformations
   mentioned above.

5.1 Confidentiality Protection

   The plaintext data octet sequence p1 is encrypted using the chosen
   confidentiality algorithm (CALG) initialised for encryption with the
   shared context key K. 

      c1 = CALG(K, ENCRYPTION)( bytes(p1) )

   On the receiving side, the ciphertext data octet sequence p1 is
   decrypted using the chosen confidentiality algorithm (CALG)
   initialised for decryption, with the shared context key K. 

      c2 = CALG(K, DECRYPTION)( bytes(p1) )

   The designated CALG block cipher should be used in OFB (Output
   Feedback Block) mode in the ISO variant, as described in [HAC],
   algorithm 7.20.

   Let k be the block size of the chosen symmetric cipher algorithm;
   e.g. for AES this is 128 bits or 16 octets.  The OFB mode used shall
   be of length/size k.

   It is recommended that Block ciphers operating in OFB mode be used
   with an Initial Vector (the mode's IV).  For the SASL mechanism
   described in this document, the IV shall be an all-zero octet
   sequence of size k.

   In such a mode of operation - OFB with key re-use - the IV, which
   need not be secret, must be changed.  Otherwise an identical
   keystream results; and, by XORing corresponding ciphertexts, an
   adversary may reduce cryptanalysis to that of a running-key cipher
   with one plaintext as the running key.  To counter the effect of
   fixing the IV to an all-zero octet sequence, the sender should use a


Burdis & Naffah          Expires July 13, 2002                 [Page 15]
\f
Internet-Draft             SRP SASL Mechanism               January 2002


   one k-octet sequence as the value of its first block, constructed as
   follows: 

   o  the first (most significant) (k-2) octets are random,

   o  the octets at position #k-1 and #k, assuming the first octet is
      at position #1, are exact copies of those at positions #1 and #2
      respectively.

   The input data to the confidentiality protection algorithm shall be
   a multiple of the symmetric cipher block size k.  When the input
   length is not a multiple of k octets, the data shall be padded
   according to the following scheme (described in [PKCS7] which itself
   is based on [RFC-1423]): 

      Assuming the length of the input is l octets, (k - (l mod k))
      octets, all having the value (k - (l mod k)), shall be appended
      to the original data.  In other words, the input is padded at the
      trailing end with one of the following sequences: 

                      01 -- if l mod k = k-1
                     02 02 -- if l mod k = k-2
                               ...
                               ...
                               ...
                   k k ... k k -- if l mod k = 0

      The padding can be removed unambiguously since all input is
      padded and no padding sequence is a suffix of another.  This
      padding method is well-defined if and only if k < 256 octets,
      which is the case with symmetric block ciphers today, and in the
      forseeable future.

   The output of this stage, when it is active, is: 

      at the sending side: CALG(K, ENCRYPT)( bytes(p1) )

      at the receiving side: CALG(K, DECRYPT)( bytes(p1) )

   If the receiver, after decrypting the first block, finds that the
   last two octets do not match the value of the first two, it MUST
   signal an exception and abort the exchange.

5.2 Replay Detection

   A sequence number q is incremented every time a message is sent to
   the peer.

   The output of this stage, when it is active, is: 


Burdis & Naffah          Expires July 13, 2002                 [Page 16]
\f
Internet-Draft             SRP SASL Mechanism               January 2002


      p2 | q

   At the other end, the receiver increments its copy of the sequence
   number.  This new value of the sequence number is then used in the
   integrity protection transformation, which must also be active as
   described in Section 4.2.  See Section 7.3 for more details.

5.3 Integrity Protection

   When the Integrity Protection stage is active, a message
   authentication code C is computed using the chosen integrity
   protection algorithm (IALG) as follows: 

   o  the IALG is initialised (once) with the shared context key K,

   o  the IALG is updated with every exchange of the sequence p3,
      yielding the value C and a new IALG context for use in the
      following exchange.

   At the other end, the receiver computes its version of C, using the
   same transformation, and checks that its value is equal to that
   received. If the two values do not agree, the receiver must signal
   an exception and abort.

   The output of this stage, when it is active, is then: 

      IALG(K)( bytes(p3) )

5.4 Summary of Security Layer Output

   The following table shows the data exchanged by the security layer
   peers, depending on the possible legal combinations of the three
   security services in operation: 

      CP   IP   RD   Peer sends/receives

      I    I    I    { eos(p) }
      I    A    I    { eos(p) | os( IALG(K)( bytes(p) ) ) }
      I    A    A    { eos(p) | os( IALG(K)( bytes(p) | bytes(q)) ) }
      A    I    I    { eos(c) }
      A    A    I    { eos(c) | os( IALG(K)( bytes(c) ) ) }
      A    A    A    { eos(c) | os( IALG(K)((bytes(c) | bytes(q)) ) }

   where 

      CP    Confidentiality protection,

      IP    Integrity protection,



Burdis & Naffah          Expires July 13, 2002                 [Page 17]
\f
Internet-Draft             SRP SASL Mechanism               January 2002


      RD    Replay detection,

      I     Security service is Inactive/disabled,

      A     Security service is Active/enabled,

      p     The original plaintext,

      q     The sequence number.

      c     The enciphered input obtained by either: 

         CALG(K, ENCRYPT)( bytes(p) ) at the sender's side, or

         CALG(K, DECRYPT)( bytes(p) ) at the receiver's side




































Burdis & Naffah          Expires July 13, 2002                 [Page 18]
\f
Internet-Draft             SRP SASL Mechanism               January 2002


6. Example

   The example below uses SMTP authentication [RFC-2554]. The base64
   encoding of challenges and responses, as well as the reply codes
   preceding the responses are part of the SMTP authentication
   specification, not part of this SASL mechanism itself.

   "C:" and "S:" indicate lines sent by the client and server
   respectively.


    S: 220 smtp.example.com ESMTP server ready

    C: EHLO zaau.example.com

    S: 250-smtp.example.com
    S: 250 AUTH SRP CRAM-MD5 DIGEST-MD5

    C: AUTH SRP AAAADAAEdGVzdAAEdGVzdA==

     with:

       U = "test"

       I = "test"

    S: 334 AAABygEArGvbQTJKmpvxZt5eE4lYL69ytmUZh+4H/DGSlD21YFCjcynLtKCZ7Y
    GT4HV3Z6E91SMSq0sDMQ3Nf0ip2gT9UOgIOWntt2ewz2CVF5oWOrNmGgX71fqq6CkYqZY
    vC5O4Vfl5k+yXXuqoDXQK2/T/dHNZ0EHVwz6nHSgeRGsUdzvKl7Q6I/uAFna9IHpDbGSB
    8dK5B4cXRhpbnTLmiPh3SFRFI7UksNV9Xqd6J3XS7PoDLPvb9S+zeGFgJ5AE5Xrmr4dOc
    wPOUymczAQce8MI2CpWmPOo0MOCca41+Onb+7aUtcgD2J965DXeI21SX1R1m2XjcvzWjv
    IPpxEfnkr/cwABAgqsi3AvmIqdEbREALhtZGE9U0hBLTEsbWFuZGF0b3J5PXJlcGxheSB
    kZXRlY3Rpb24scmVwbGF5IGRldGVjdGlvbixpbnRlZ3JpdHk9aG1hYy1zaGExLGludGVn
    cml0eT1obWFjLW1kNSxjb25maWRlbnRpYWxpdHk9YWVzLGNvbmZpZGVudGlhbGl0eT1jY
    XN0NSxjb25maWRlbnRpYWxpdHk9Ymxvd2Zpc2gsbWF4YnVmZmVyc2l6ZT0yMTQ3NDgzNj
    Qz

     with:

       N = "2176617445861743577319100889180275378190766837425553851114464
       322468988623538384095721090901308605640157139971723580726658164960
       647214841029141336415219736447718088739565548373811507267740223510
       176252190156982074029314952962041933326626207347105454836873603951
       970248622650624886106025697180298495356112144268015766800076142998
       822245709041387397397017192709399211475176516806361476111961547623
       342209644278311797123637164733387141433589577347466730896705080700
       550932042479967841703686792831676127227423031406754829113358247958
       306143957755934710196177140617368437852270348349533703765500675132
       8447510550299250924469288819"


Burdis & Naffah          Expires July 13, 2002                 [Page 19]
\f
Internet-Draft             SRP SASL Mechanism               January 2002


       g = "2"

       s = "814819216327401865851972"

       L = "mda=SHA-1,mandatory=replay detection,replay detection,integri
       ty=hmac-sha1,integrity=hmac-md5,confidentiality=aes,confidentialit
       y=cast5,confidentiality=blowfish,maxbuffersize=2147483643"

    C: AAABYwEAAp5q/4zhXoTUzXBscozN97SWgfDcAImIk3lNHNvd0b+Dr7jEm6upXblZT5
    sL9mPgFsejlIh+B/eCu/HvzWCrXj6ylPZv8dy3LCH3LIORqQ45S7Lsbmrrg/dukDh4tZC
    JMLD4r3evzaY8KVhtJeLMVbeXuh4JljKP42Ll59Lzwf8jfPh4+4Lae1rpWUCL9DueKcY+
    nN+xNHTit/ynLATxwL93P6+GoGY4TkUbUBfjiI1+rAMvyMDMw5XozGy07FOEc++U0iPeX
    CQP4MT5FipOUoz8CYX7J1LbaXp2WJuFHlkyVXF7oCoyHbhld/5CfR3o6q/B/x9+yZRqaH
    H+JfllOgBfbWRhPVNIQS0xLHJlcGxheSBkZXRlY3Rpb24saW50ZWdyaXR5PWhtYWMtbWQ
    1LGNvbmZpZGVudGlhbGl0eT1ibG93ZmlzaCxtYXhidWZmZXJzaXplPTIxNDc0ODM2NDM=

     with:

       A = "3305954184671210249746312321130434202193449637258786928151596
       956582377798844627774788503949777445537469304518958156158884050562
       780707370878253753979367019077142882237029766166623275718227655538
       983419084032208109159908908194732453790761392470705815003778027907
       762317939621437864117925167600301024366036210465417293966890613394
       379900527412007068242559299422872893332111365840536495185883474232
       883537338757318836995637988160638089067541196607366511069220022940
       355334703015419992745572006667033895314817945166254757418442215980
       634933876533189969562613241499465295849832999091403980813218409496
       06581251320320995783959866"

       o = mda=SHA-1,replay detection,integrity=hmac-md5,confidentiality=
       blowfish,maxbuffersize=2147483643"

    S: 334 AAABAgEAOUKbXpnzMhziivGgMwm+FS8sKGSvjh5M3D+80RF/5z9rm0oPoi4+pF
    83fueWn4Hz9M+muF/22PHHZkHtlutDrtapj4OtirdxC21fS9bMtEh3F0whTX+3mPvthw5
    sk11turandHiLvcUZOgcrAGIoDKcBPoGyBud+8bMgpkf/uGfyBM2nEX/hV+oGggX+LiHj
    mkxAJ3kewfQPH0eV9ffEuuyu8BUcBXkJsS6l7eWkuERSCttVOi/jS031c+CD/nuecUXYi
    F8IYzW03rbcwYhZzifmTi3VK9C8zG2K1WmGU+cDKlZMkyCPMmtCsxlbgE8zSHCuCiOgQ3
    5XhcA0Qa0C3Q==

     with:

       B: "72284284756503184420540308728542442858927345812975023176601544
       656078275298532392401181852634926172435239161066586969655965268585
       300845435562962039149169549800169184521786717633959469278439877134
       444500243257950929211559843568506288263176079641655456298084758961
       983258355079013195569295114214721321849903652130596549627218189966
       140113906545856088040473723048909402258929560823932725202215411408
       791389541192767670707304028113609680668175826522120988223747234163
       643404100201722157739343027946790344246999996116789730443114919539


Burdis & Naffah          Expires July 13, 2002                 [Page 20]
\f
Internet-Draft             SRP SASL Mechanism               January 2002


       575466941344964841591072763617954717789621871251710891793993491944
       52686682517183909017223901"

    C: AAAAFRTkoju6xGP+zH89iaDWIFjfIKt5Kg==

    S: 235 Authentication successful.













































Burdis & Naffah          Expires July 13, 2002                 [Page 21]
\f
Internet-Draft             SRP SASL Mechanism               January 2002


7. Discussion

7.1 Mandatory Algorithms

   The algorithms specified as mandatory were chosen for utility and
   availablity.  We felt that a mandatory confidentiality and integrity
   protection algorithm for the security layer and a mandatory Message
   Digest Algorithm for SRP calculations should be specified to ensure
   interoperability between implementations of this mechanism: 

   o  The SHA-160 Message Digest Algorithm was chosen as an underlying
      algorithm for SRP calculations because this allows for easy
      interoperability with other SRP-based tools that use the SRP-SHA1
      protocol described in section 3 of [RFC-2945] and create their
      password files using this algorithm.

   o  The HMAC algorithm was chosen as an integrity algorithm because
      it is faster than MAC algorithms based on secret key encryption
      algorithms [RFC-2847].

   o  Rijndael was chosen as a cipher because it has undergone thorough
      scrutiny by the best cryptographers in the world and was chosen
      ahead of many other algorithms as the Advanced Encryption
      Standard.

   Since confidentiality protection is optional, this mechanism should
   be usable in countries that have strict controls on the use of
   cryptography.

7.2 Modulus and generator values

   It is RECOMMENDED that the server use values for the modulus (N) and
   generator (g) chosen from those listed in Appendix A so that the
   client can avoid expensive constraint checks, since these predefined
   values already meet the constraints described in [RFC-2945]:

      "For maximum security, N should be a safe prime (i.e. a number of
      the form N = 2q + 1, where q is also prime).  Also, g should be a
      generator modulo N (see [SRP] for details), which means that for
      any X where 0 < X < N, there exists a value x for which g**x % N
      == X."

7.3 Replay detection sequence number counters

   The mechanism described in this document allows the use of a Replay
   Detection security service that works by including sequence number
   counters in the message authentication code (MAC) created by the
   Integrity Protection service.  As noted in Section 4.2 integrity
   protection is always activated when the Replay Detection service is


Burdis & Naffah          Expires July 13, 2002                 [Page 22]
\f
Internet-Draft             SRP SASL Mechanism               January 2002


   activated.

   Both the client and the server keep two sequence number counters. 
   Each of these counters is a 32-bit unsigned integer initialised with
   a Starting Value and incremented by an Increment Value with every
   successful transmission of an SASL buffer through the security
   layer.  The Sent counter is incremented for each buffer sent through
   the security layer. The Received counter is incremented for each
   buffer received through the security layer.  If the value of a
   sequence number counter exceeds 2**32 it wraps around and starts
   from zero again.

   When a sender sends a buffer it includes the value of its Sent
   counter in the computation of the MAC accompanying each integrity
   protected message.  When a recipient receives a buffer it uses the
   value of it's Received counter in its computation of the integrity
   protection MAC for the received message.  The recipient's Received
   counter must be the same as the sender's Sent counter in order for
   the received and computed MACs to match.

   This specification assumes that for each sequence number counter the
   Starting Value is ZERO, and that the Increment Value is ONE.  These
   values do not affect the security or the intended objective of the
   replay detection service, since they never travel on the wire.

7.4 SASL Profile Considerations

   As mentioned briefly in [RFC-2222], and detailed in [SASL] a SASL
   specification has three layers: (a) a protocol definition using SASL
   known as the "Profile", (b) a SASL mechanism definition, and (c) the
   SASL framework.

   Point (3) in section 5 of [SASL] ("Protocol profile requirements")
   clearly states that it is the responsibility of the Profile to
   define "...how the challenges and responses are encoded, how the
   server indicates completion or failure of the exchange, how the
   client aborts an exchange, and how the exchange method interacts
   with any line length limits in the protocol."

   The username entity, referenced as "U" throughout this document, and
   used by the server to locate the password data, is assumed to travel
   "in the clear," meaning that no transformation is applied to its
   contents. This assumption was made to allow the same SRP password
   files to be used in this mechanism, as those used with other SRP
   applications and tools.

   A Profile may decide, for privacy or other reason, to disallow such
   information to travel in the clear, and instead use a hashed version
   of U, or more generally a transformation function applied to U; i.e.


Burdis & Naffah          Expires July 13, 2002                 [Page 23]
\f
Internet-Draft             SRP SASL Mechanism               January 2002


   f(U).  Such a Profile would require additional tools to add the
   required entries to the SRP password files for the new value(s) of
   f(U).  It is worth noting too that if this is the case, and the same
   user shall access the server through this mechanism as well as
   through other SRP tools, then at least two entries, one with U and
   the other with f(U) need to be present in the SRP password files if
   those same files are to be used for both types of access.












































Burdis & Naffah          Expires July 13, 2002                 [Page 24]
\f
Internet-Draft             SRP SASL Mechanism               January 2002


8. Security Considerations

   This mechanism relies on the security of SRP, which bases its
   security on the difficulty of solving the Diffie-Hellman problem in
   the multiplicative field modulo a large safe prime.  See section 4
   "Security Considerations" of [RFC-2945] and section 4 "Security
   analysis" of [SRP].

   B, the server's ephemeral public key, is computed as g**b + v = g**b
   + g**x, which is symmetric and allows two guesses per *active
   attack*.  In practical terms, this makes no difference to the
   security of SRP, since the number of active attacks needed is still
   linearly proportional to the number of guesses needed; only the
   constant factor (2 vs. 1) has changed.

   This mechanism also relies on the security of the HMAC algorithm and
   the underlying hash function when integrity protection is used. 
   Section 6 "Security" of [RFC-2104] discusses these security issues
   in detail.  Weaknesses found in MD5 do not impact HMAC-MD5
   [DOBBERTIN].

   U, A, I and o, sent from the client to the server, and N, g, L, s
   and B, sent from the server to the client could be modified by an
   attacker before reaching the other party.  For this reason, these
   values are included in the respective calculations of evidence (M1
   and M2) to prove that each party knows the session key K.  This
   allows each party to verify that these values were received
   unmodified.

   The use of integrity protection is RECOMMENDED to detect message
   tampering and to avoid session hijacking after authentication has
   taken place.

   Replay attacks may be avoided through the use of sequence numbers,
   because sequence numbers make each integrity protected message
   exchanged during a session different, and each session uses a
   different key.

   Research [KRAWCZYK] shows that the order and way of combining
   message encryption (Confidentiality Protection) and message
   authentication (Integrity Protection) are important.  This mechanism
   follows the EtA (encrypt-then-authenticate) method and is
   "generically secure."








Burdis & Naffah          Expires July 13, 2002                 [Page 25]
\f
Internet-Draft             SRP SASL Mechanism               January 2002


9. Acknowledgements

   The following people provided valuable feedback in the preparation
   of this document: 

      Stephen Farrell <stephen.farrell@baltimore.ie>

      Timothy Martin <tmartin@andrew.cmu.edu>

      Ken Murchison <ken@oceana.com>

      Magnus Nystrom <magnus@rsasecurity.com>

      Thomas Wu <tom@arcot.com>





































Burdis & Naffah          Expires July 13, 2002                 [Page 26]
\f
Internet-Draft             SRP SASL Mechanism               January 2002


References

   [AES]        National Institute of Standards and Technology,
                "Rijndael: NIST's Selection for the AES", December
                2000, 
                <http://csrc.nist.gov/encryption/aes/rijndael/Rijndael.p
                df>.

   [DOBBERTIN]  Dobbertin, H., "The Status of MD5 After a Recent
                Attack", December 1996, 
                <ftp://ftp.rsasecurity.com/pub/cryptobytes/crypto2n2.pdf
                >.

   [HAC]        Menezes, A.J., van Oorschot, P.C. and S.A. Vanstone,
                "Handbook of Applied Cryptography", CRC Press, Inc.,
                ISBN 0-8493-8523-7, 1997, 
                <http://www.cacr.math.uwaterloo.ca/hac/about/chap7.ps>.

   [ISO-10646]  "International Standard --Information technology--
                Universal Multiple-Octet Coded Character Set (UCS) --
                Part 1 Architecture and Basic Multilingual Plane",
                ISO/IEC 10646-1, 1993.

   [KRAWCZYK]   Krawczyk, H., "The order of encryption and
                authentication for protecting communications (Or: how
                secure is SSL?)", June 2001, 
                <http://eprint.iacr.org/2001/045/>.

   [PKCS7]      RSA Data Security, Inc., "PKCS #7: Cryptographic
                Message Syntax Standard", Version 1.5, November 1993, 
                <ftp://ftp.rsasecurity.com/pub/pkcs/ascii/pkcs-7.asc>.

   [RFC-1423]   Balenson, D., "Privacy Enhancement for Internet
                Electronic Mail: Part III: Algorithms, Modes, and
                Identifiers", RFC 1423, February 1993, 
                <http://www.ietf.org/rfc/rfc1423.txt>.

   [RFC-2104]   Krawczyk, H. et al, "HMAC: Keyed-Hashing for Message
                Authentication", RFC 2104, February 1997, 
                <http://www.ietf.org/rfc/rfc2104.txt>.

   [RFC-2119]   Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 0014, RFC 2119, March 1997, 
                <http://www.ietf.org/rfc/rfc2119.txt>.

   [RFC-2222]   Myers, J.G., "Simple Authentication and Security Layer
                (SASL)", RFC 2222, October 1997, 
                <http://www.ietf.org/rfc/rfc2222.txt>.



Burdis & Naffah          Expires July 13, 2002                 [Page 27]
\f
Internet-Draft             SRP SASL Mechanism               January 2002


   [RFC-2279]   Yergeau, F., "UTF-8, a transformation format of Unicode
                and ISO 10646", RFC 2279, January 1998, 
                <http://www.ietf.org/rfc/rfc2279.txt>.

   [RFC-2440]   Callas, J., Donnerhacke, L., Finney, H. and R. Thayer,
                "OpenPGP Message Format", RFC 2440, November 1998, 
                <http://www.ietf.org/rfc/rfc2440.txt>.

   [RFC-2554]   Myers, J.G., "SMTP Service Extension for
                Authentication", RFC 2554, March 1999.

   [RFC-2629]   Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
                June 1999, 
                <http://www.ietf.org/rfc/rfc2629.txt>.

   [RFC-2847]   Eisler, M., "LIPKEY - A Low Infrastructure Public Key
                Mechanism Using SPKM", RFC 2847, June 2000, 
                <http://www.ietf.org/rfc/rfc2847.txt>.

   [RFC-2945]   Wu, T., "The SRP Authentication and Key Exchange
                System", RFC 2945, September 2000, 
                <http://www.ietf.org/rfc/rfc2945.txt>.

   [RIJNDAEL]   Daemen, Joan and Vincent Rijmen, "AES Proposal:
                Rijndael", September 1999, 
                <http://www.esat.kuleuven.ac.be/~rijmen/rijndael/>.

   [SASL]       Myers, J.G., "Simple Authentication and Security Layer
                (SASL)", April 2001, 
                <http://www.ietf.org/internet-drafts/draft-myers-saslrev
                -01.txt>.

   [SCAN]       Hopwood, D., "Standard Cryptographic Algorithm Naming",
                June 2000, 
                <http://www.eskimo.com/~weidai/scan-mirror/>.

   [SRP]        Wu, T., "The Secure Remote Password Protocol", March
                1998, 
                <http://srp.stanford.edu/ndss.html>.

   [SRP']       Wu, T., "SRP: The Open Source Password Authentication
                Standard", March 1998, 
                <http://srp.stanford.edu/srp/>.








Burdis & Naffah          Expires July 13, 2002                 [Page 28]
\f
Internet-Draft             SRP SASL Mechanism               January 2002


Authors' Addresses

   Keith Burdis
   Rhodes University
   Computer Science Department
   Grahamstown  6139
   ZA

   EMail: keith@rucus.ru.ac.za


   Raif S. Naffah
   Forge Research Pty. Limited
   Suite 116, Bay 9
   Locomotive Workshop,
   Australian Technology Park
   Cornwallis Street
   Eveleigh, NSW  1430
   AU

   EMail: raif@forge.com.au






























Burdis & Naffah          Expires July 13, 2002                 [Page 29]
\f
Internet-Draft             SRP SASL Mechanism               January 2002


Appendix A. Modulus and Generator values

   Modulus (N) and generator (g) values for various modulus lengths are
   given below.  In each case the modulus is a large safe prime and the
   generator is a primitve root of GF(n) [RFC-2945].  These values are
   taken from software developed by Tom Wu and Eugene Jhong for the
   Stanford SRP distribution [SRP'].


      [264 bits]
        Modulus (base 16) =
          115B8B692E0E045692CF280B436735C77A5A9E8A9E7ED56C965F87DB5B2A2ECE
          3
        Generator = 2

      [384 bits]
        Modulus (base 16) =
          8025363296FB943FCE54BE717E0E2958A02A9672EF561953B2BAA3BAACC3ED57
          54EB764C7AB7184578C57D5949CCB41B
        Generator = 2

      [512 bits]
        Modulus (base 16) =
          D4C7F8A2B32C11B8FBA9581EC4BA4F1B04215642EF7355E37C0FC0443EF756EA
          2C6B8EEB755A1C723027663CAA265EF785B8FF6A9B35227A52D86633DBDFCA43
        Generator = 2

      [640 bits]
        Modulus (base 16) =
          C94D67EB5B1A2346E8AB422FC6A0EDAEDA8C7F894C9EEEC42F9ED250FD7F0046
          E5AF2CF73D6B2FA26BB08033DA4DE322E144E7A8E9B12A0E4637F6371F34A207
          1C4B3836CBEEAB15034460FAA7ADF483
        Generator = 2

      [768 bits]
        Modulus (base 16) =
          B344C7C4F8C495031BB4E04FF8F84EE95008163940B9558276744D91F7CC9F40
          2653BE7147F00F576B93754BCDDF71B636F2099E6FFF90E79575F3D0DE694AFF
          737D9BE9713CEF8D837ADA6380B1093E94B6A529A8C6C2BE33E0867C60C3262B
        Generator = 2

      [1024 bits]
        Modulus (base 16) =
          EEAF0AB9ADB38DD69C33F80AFA8FC5E86072618775FF3C0B9EA2314C9C256576
          D674DF7496EA81D3383B4813D692C6E0E0D5D8E250B98BE48E495C1D6089DAD1
          5DC7D7B46154D6B6CE8EF4AD69B15D4982559B297BCF1885C529F566660E57EC
          68EDBC3C05726CC02FD4CBF4976EAA9AFD5138FE8376435B9FC61D2FC0EB06E3
        Generator = 2



Burdis & Naffah          Expires July 13, 2002                 [Page 30]
\f
Internet-Draft             SRP SASL Mechanism               January 2002


      [1280 bits]
        Modulus (base 16) =
          D77946826E811914B39401D56A0A7843A8E7575D738C672A090AB1187D690DC4
          3872FC06A7B6A43F3B95BEAEC7DF04B9D242EBDC481111283216CE816E004B78
          6C5FCE856780D41837D95AD787A50BBE90BD3A9C98AC0F5FC0DE744B1CDE1891
          690894BC1F65E00DE15B4B2AA6D87100C9ECC2527E45EB849DEB14BB2049B163
          EA04187FD27C1BD9C7958CD40CE7067A9C024F9B7C5A0B4F5003686161F0605B
        Generator = 2

      [1536 bits]
        Modulus (base 16) =
          9DEF3CAFB939277AB1F12A8617A47BBBDBA51DF499AC4C80BEEEA9614B19CC4D
          5F4F5F556E27CBDE51C6A94BE4607A291558903BA0D0F84380B655BB9A22E8DC
          DF028A7CEC67F0D08134B1C8B97989149B609E0BE3BAB63D47548381DBC5B1FC
          764E3F4B53DD9DA1158BFD3E2B9C8CF56EDF019539349627DB2FD53D24B7C486
          65772E437D6C7F8CE442734AF7CCB7AE837C264AE3A9BEB87F8A2FE9B8B5292E
          5A021FFF5E91479E8CE7A28C2442C6F315180F93499A234DCF76E3FED135F9BB
        Generator = 2

      [2048 bits]
        Modulus (base 16) =
          AC6BDB41324A9A9BF166DE5E1389582FAF72B6651987EE07FC3192943DB56050
          A37329CBB4A099ED8193E0757767A13DD52312AB4B03310DCD7F48A9DA04FD50
          E8083969EDB767B0CF6095179A163AB3661A05FBD5FAAAE82918A9962F0B93B8
          55F97993EC975EEAA80D740ADBF4FF747359D041D5C33EA71D281E446B14773B
          CA97B43A23FB801676BD207A436C6481F1D2B9078717461A5B9D32E688F87748
          544523B524B0D57D5EA77A2775D2ECFA032CFBDBF52FB3786160279004E57AE6
          AF874E7303CE53299CCC041C7BC308D82A5698F3A8D0C38271AE35F8E9DBFBB6
          94B5C803D89F7AE435DE236D525F54759B65E372FCD68EF20FA7111F9E4AFF73
        Generator = 2





















Burdis & Naffah          Expires July 13, 2002                 [Page 31]
\f
Internet-Draft             SRP SASL Mechanism               January 2002


Appendix B. Changes since the previous draft

   The underlying message digest algorithm for SRP calculations is now
   selected during an exchange between the server and client. Section
   4.2 and Section 4.3 have been amended to reflect this change.

   Changed "mechanisms" to "mechanism" in various places and fixed the
   mechanism name to "SRP."

   Removed "Mechanism Names" section, since it is no longer needed, and
   replaced with "Introduction."

   Changed the mechanism data exchanges in Section 4 so that the
   authorisation identity (I) is sent with the authentication identity
   (U).

   Added a new bullet point to Section 7.1 justifying the selection of
   SHA-160 as the MANDATORY Message Digest Algorithm for SRP
   calculations.

   Added a new paragraph to Section 8 giving Tom Wu's response to the
   SRP password-guessing attack pointed out by Robert Moskowitz.

   Added Ken Murchison to Section 9.

   Used "**" consistently as the symbol for the exponentiation operator.

   Re-ordered the references alphabetically.























Burdis & Naffah          Expires July 13, 2002                 [Page 32]
\f
Internet-Draft             SRP SASL Mechanism               January 2002


Full Copyright Statement

   Copyright (C) The Internet Society (2002). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC editor function is currently provided by the
   Internet Society.



















Burdis & Naffah          Expires July 13, 2002                 [Page 33]
\f