[Search] [pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08                                    
Network Working Group                                        K.R. Burdis
Internet-Draft                                         Rhodes University
Expires: March 13, 2001                               September 12, 2000


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

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 March 13, 2001.

Copyright Notice

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

Abstract

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











Burdis                   Expires March 13, 2001                 [Page 1]


Internet-Draft    Secure Remote Password SASL Mechanism   September 2000


Table of Contents

   1.    Conventions Used in this Document  . . . . . . . . . . . . .  3
   2.    Netstrings . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.    Protocol Description . . . . . . . . . . . . . . . . . . . .  5
   3.1   Server sends N, g and L  . . . . . . . . . . . . . . . . . .  6
   3.2   Client sends request . . . . . . . . . . . . . . . . . . . .  9
   3.3   Server sends response  . . . . . . . . . . . . . . . . . . . 10
   3.4   Client sends evidence  . . . . . . . . . . . . . . . . . . . 10
   3.5   Server sends evidence  . . . . . . . . . . . . . . . . . . . 10
   4.    Security Layer . . . . . . . . . . . . . . . . . . . . . . . 11
   4.1   Integrity Protection . . . . . . . . . . . . . . . . . . . . 11
   4.1.1 Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 11
   4.1.2 Decoding . . . . . . . . . . . . . . . . . . . . . . . . . . 12
   5.    Example  . . . . . . . . . . . . . . . . . . . . . . . . . . 13
   6.    Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 14
   7.    Security Considerations  . . . . . . . . . . . . . . . . . . 15
   8.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
         References . . . . . . . . . . . . . . . . . . . . . . . . . 17
         Author's Address . . . . . . . . . . . . . . . . . . . . . . 17
   A.    Modulus and Generator values . . . . . . . . . . . . . . . . 19
         Full Copyright Statement . . . . . . . . . . . . . . . . . . 21





























Burdis                   Expires March 13, 2001                 [Page 2]


Internet-Draft    Secure Remote Password SASL Mechanism   September 2000


1. Conventions Used in this Document

   In this document, a string of 8-bit bytes may be written in two
   different forms: as a series of hexadecimal numbers between angle
   brackets, or as a sequence of ASCII characters between double
   quotes. For example, <68 65 6c 6c 6f 20 77 6f 72 6c 64 21> is a
   string of length 12; it is the same as the string "hello world!"
   [1].  All data is encoded and sent in network byte order
   (big-endian).

   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[2].






































Burdis                   Expires March 13, 2001                 [Page 3]


Internet-Draft    Secure Remote Password SASL Mechanism   September 2000


2. Netstrings

   This mechanism makes extensive use of netstrings, which are
   described in more detail in [1]:

      A netstring is a self-delimiting encoding of a string. Netstrings
      are very easy to generate and to parse. Any string may be encoded
      as a netstring; there are no restrictions on length or on allowed
      bytes. Another virtue of a netstring is that it declares the
      string size up front. Thus an application can check in advance
      whether it has enough space to store the entire string.

      Any string of 8-bit bytes may be encoded as {len}":"{string}",".
      Here {string} is the string and {len} is a nonempty sequence of
      ASCII digits giving the length of {string} in decimal. The ASCII
      digits are <30> for 0, <31> for 1, and so on up through <39> for
      9. Extra zeros at the front of {len} are prohibited: {len} begins
      with <30> exactly when {string} is empty.

      For example, the string "hello world!" is encoded as <31 32 3a 68
      65 6c 6c 6f 20 77 6f 72 6c 64 21 2c>, i.e., "12:hello world!,".
      The empty string is encoded as "0:,".

      {len}":"{string}"," is called a netstring. {string} is called the
      interpretation of the netstring.

   Note that {string} may itself be a netstring.
























Burdis                   Expires March 13, 2001                 [Page 4]


Internet-Draft    Secure Remote Password SASL Mechanism   September 2000


3. Protocol Description

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

   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 [11].

   This mechanism is based on the optimised SRP-SHA1 protocol described
   at the end of section 3 in [10], 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.

   This document describes how the SRP-SHA1 data is encoded for
   transmission between the client and server, and it adds extra
   control information to enable the client to request whether or not
   replay detection, integrity protection and/or confidentiality
   protection should be provided by a security layer.

   Mechanism data exchanges are shown below:


        Client    Server

         <--  N,g,L  --

          --  U,I,A,o  -->

         <--  s,B  --

          --  M1  -->

         M1 = H(H(N) XOR H(g) | H(U) | s | H(L) | A | B | K)

         <--  M2  --

         M2 = H(A | H(U) | H(I) | H(o) | M1 | K)


   where:

      | is the concatenation operator

      H is the SHA-1 one-way function

      N is the prime modulus


Burdis                   Expires March 13, 2001                 [Page 5]


Internet-Draft    Secure Remote Password SASL Mechanism   September 2000


      g is the generator

      L is the options list indicating available security services

      U is the client's username (authentication identity)

      I is the client's authorisation identity

      A is the client's ephemeral public key

      o is the options list indicating requested security services

      s is the client's password salt

      B is the server's ephemeral public key

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

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

3.1 Server sends N, g and L

   The prime modulus (N) is encoded as a netstring (ns1). The generator
   (g) is encoded as a netstring (ns2).

   The server creates an options list (L), which consists of a
   comma-separated list of option strings that specify the security
   service options the server supports. The following option strings
   are defined:

   o  "integrity=HMAC-MD5" indicates that the server supports integrity
      protection using the HMAC-MD5 algorithm [5]. This option string
      MUST always be sent, since support for this algorithm is
      MANDATORY.

   o  "replay detection" indicates that the server supports replay
      detection using sequence numbers.

   o  "confidentiality=BLOWFISH-CBC" indicates that the server supports
      confidentiality protection using the Blowfish cipher in CBC mode
      [9]. If the server supports confidentiality protection, it MUST
      send this option string, since it is then MANDATORY for it to
      provide support for this algorithm.

   Other option strings MAY be sent. The options list SHOULD NOT be
   interpreted in a case-sensitive manner.

   For example, if the server supports integrity protection, replay
   detection and no confidentiality protection, the options list would


Burdis                   Expires March 13, 2001                 [Page 6]


Internet-Draft    Secure Remote Password SASL Mechanism   September 2000


   be:

      integrity=HMAC-MD5,replay detection

   This options list (L) is encoded as a netstring (ns3).

   These three netstrings (ns1, ns2 and ns3) are concatenated and this
   string is encoded as a netstring (ns4). The resulting string (ns4)
   is sent to the client.

   For example if:


     N = <EE AF 0A B9 AD B3 8D D6 9C 33 F8 0A FA 8F C5 E8
          60 72 61 87 75 FF 3C 0B 9E A2 31 4C 9C 25 65 76
          D6 74 DF 74 96 EA 81 D3 38 3B 48 13 D6 92 C6 E0
          E0 D5 D8 E2 50 B9 8B E4 8E 49 5C 1D 60 89 DA D1
          5D C7 D7 B4 61 54 D6 B6 CE 8E F4 AD 69 B1 5D 49
          82 55 9B 29 7B CF 18 85 C5 29 F5 66 66 0E 57 EC
          68 ED BC 3C 05 72 6C C0 2F D4 CB F4 97 6E AA 9A
          FD 51 38 FE 83 76 43 5B 9F C6 1D 2F C0 EB 06 E3>

   and:

     g = <02>

   and:

     L = "integrity=hmac-md5,replay detection,
          confidentiality=blowfish-cbc"

       or

     L = <69 6E 74 65 67 72 69 74 79 3D 68 6D 61 63 2D 6D
          64 35 2C 72 65 70 6C 61 79 20 64 65 74 65 63 74
          69 6F 6E 2C 63 6F 6E 66 69 64 65 6E 74 69 61 6C
          69 74 79 3D 62 6C 6F 77 66 69 73 68 2D 63 62 63>














Burdis                   Expires March 13, 2001                 [Page 7]


Internet-Draft    Secure Remote Password SASL Mechanism   September 2000


   N encoded as a netstring is:


     <31 32 38 3A EE AF 0A B9 AD B3 8D D6 9C 33 F8 0A FA 8F
      C5 E8 60 72 61 87 75 FF 3C 0B 9E A2 31 4C 9C 25 65 76
      D6 74 DF 74 96 EA 81 D3 38 3B 48 13 D6 92 C6 E0 E0 D5
      D8 E2 50 B9 8B E4 8E 49 5C 1D 60 89 DA D1 5D C7 D7 B4
      61 54 D6 B6 CE 8E F4 AD 69 B1 5D 49 82 55 9B 29 7B CF
      18 85 C5 29 F5 66 66 0E 57 EC 68 ED BC 3C 05 72 6C C0
      2F D4 CB F4 97 6E AA 9A FD 51 38 FE 83 76 43 5B 9F C6
      1D 2F C0 EB 06 E3 2C>


   g encoded as a netstring is:


     "1:" <02> ","

       or

     <31 3A 02 2C>


   L encoded as a netstring is:


     "64:integrity=hmac-md5,replay detection,
      confidentiality=blowfish-cbc,"

       or

     <36 34 3A 69 6E 74 65 67 72 69 74 79 3D 68 6D 61 63 2D
      6D 64 35 2C 72 65 70 6C 61 79 20 64 65 74 65 63 74 69
      6F 6E 2C 63 6F 6E 66 69 64 65 6E 74 69 61 6C 69 74 79
      3D 62 6C 6F 77 66 69 73 68 2D 63 62 63 2C>
















Burdis                   Expires March 13, 2001                 [Page 8]


Internet-Draft    Secure Remote Password SASL Mechanism   September 2000


   The final string is:


      "205:128:" <EE AF 0A B9 AD B3 8D D6 9C 33 F8 0A FA 8F
      C5 E8 60 72 61 87 75 FF 3C 0B 9E A2 31 4C 9C 25 65 76
      D6 74 DF 74 96 EA 81 D3 38 3B 48 13 D6 92 C6 E0 E0 D5
      D8 E2 50 B9 8B E4 8E 49 5C 1D 60 89 DA D1 5D C7 D7 B4
      61 54 D6 B6 CE 8E F4 AD 69 B1 5D 49 82 55 9B 29 7B CF
      18 85 C5 29 F5 66 66 0E 57 EC 68 ED BC 3C 05 72 6C C0
      2F D4 CB F4 97 6E AA 9A FD 51 38 FE 83 76 43 5B 9F C6
      1D 2F C0 EB 06 E3>  ",1:" <2> ",64:"  <69 6E 74 65 67
      72 69 74 79 3D 68 6D 61 63 2D 6D 64 35 2C 72 65 70 6C
      61 79 20 64 65 74 65 63 74 69 6F 6E 2C 63 6F 6E 66 69
      64 65 6E 74 69 61 6C 69 74 79 3D 62 6C 6F 77 66 69 73
      68 2D 63 62 63> ",,"

       or

     <32 30 35 3A 31 32 38 3A EE AF 0A B9 AD B3 8D D6 9C 33
      F8 0A FA 8F C5 E8 60 72 61 87 75 FF 3C 0B 9E A2 31 4C
      9C 25 65 76 D6 74 DF 74 96 EA 81 D3 38 3B 48 13 D6 92
      C6 E0 E0 D5 D8 E2 50 B9 8B E4 8E 49 5C 1D 60 89 DA D1
      5D C7 D7 B4 61 54 D6 B6 CE 8E F4 AD 69 B1 5D 49 82 55
      9B 29 7B CF 18 85 C5 29 F5 66 66 0E 57 EC 68 ED BC 3C
      05 72 6C C0 2F D4 CB F4 97 6E AA 9A FD 51 38 FE 83 76
      43 5B 9F C6 1D 2F C0 EB 06 E3 2C 31 3A 02 2C 36 34 3A
      69 6E 74 65 67 72 69 74 79 3D 68 6D 61 63 2D 6D 64 35
      2C 72 65 70 6C 61 79 20 64 65 74 65 63 74 69 6F 6E 2C
      63 6F 6E 66 69 64 65 6E 74 69 61 6C 69 74 79 3D 62 6C
      6F 77 66 69 73 68 2D 63 62 63 2C 2C>


3.2 Client sends request

   The client's username (U) is encoded as a netstring (ns1). The
   client's authorisation identity (I) is encoded as a netstring (ns2).
   The client generates its ephemeral public key (A) and this is
   encoded as a netstring (ns3).

   The client creates a comma-separated options list (o) that specifies
   the security service options that it requests. (The client can only
   select security services that the server has indicated it can
   provide). The defined options are:

   o  "integrity=HMAC-MD5": the client requests integrity protection
      using the HMAC-MD5 algorithm [5].

   o  "replay detection": the client requests replay detection using
      sequence numbers. (Note that an integrity protection algorithm


Burdis                   Expires March 13, 2001                 [Page 9]


Internet-Draft    Secure Remote Password SASL Mechanism   September 2000


      MUST be specified if this option is chosen).

   o  "confidentiality=BLOWFISH-CBC": the client requests
      confidentiality protection using the Blowfish cipher in CBC mode
      [9].

   Other options MAY be available.

   This options list (o) is encoded as a netstring (ns4).

   These four netstrings (ns1, ns2, ns3 and ns4) are concatenated and
   this string is encoded as a netstring (ns5). The resulting string
   (ns5) is sent to the server.

3.3 Server sends response

   The server calculates the shared context key (K).

   The client's salt (s) is encoded as a netstring (ns1). The server
   generates its ephemeral public key (B) and this is encoded as a
   netstring (ns2).

   These two netstrings (ns1 and ns2) are concatenated and this string
   is encoded as a netstring (ns3). The resulting string (ns3) is sent
   to the server.

3.4 Client sends evidence

   The client calculates the shared context key (K).

   The client calculates the evidence (M1) that proves to the server
   that it knows the shared context key (K), including L as part of the
   calculation.

      M1 = H(H(N) XOR H(g) | H(U) | s | H(L) | A | B | K)

   This evidence (M1) is encoded as a netstring (ns1) and sent to the
   server.

3.5 Server sends evidence

   The server calculates the evidence (M2) that proves to the client
   that it knows the shared context key (K), including U, I, and o as
   part of the calculation.

      M2 = H(A | H(U) | H(I) | H(o) | M1 | K)

   This evidence (M2) is encoded as a netstring (ns1) and sent to the
   client.


Burdis                   Expires March 13, 2001                [Page 10]


Internet-Draft    Secure Remote Password SASL Mechanism   September 2000


4. Security Layer

   Depending on the options specified by the initiator, the security
   layer may provide integrity protection, replay detection, and/or
   confidentiality protection. Messages are encoded as follows:

   o  If neither integrity nor confidentiality protection is requested
      then the message is sent unchanged to the other party.

   o  If just confidentiality protection is requested then the message
      data is encrypted using the chosen confidentiality algorithm (eg.
      Blowfish). The encrypted message is encoded as a netstring and
      sent to the other party.

   o  If just integrity protection is requested then the integrity
      checksum is calculated on the message data as described in
      Section 4.1.

   o  If both integrity protection and confidentiality protection are
      requested then the message data is first encrypted using the
      chosen confidentiality algorithm (eg. Blowfish). Thereafter the
      integrity checksum is calculated on the encrypted message data as
      described in Section 4.1.

   o  If replay detection is requested then the sequence number
      included in the integrity checksum is incremented after each
      message is sent, starting at zero, otherwise the sequence number
      is always zero.

4.1 Integrity Protection

   Integrity protection is provided using the chosen integrity
   protection algorithm (usually the HMAC-MD5 [5] algorithm), with the
   shared context key (K) used as the input key. The encoding and
   decoding of message data is described below.

4.1.1 Encoding

   The (possibly encrypted) message data is encoded as a netstring
   (ns1).  The (incremented) sequence number is encoded as a netstring
   (ns2). These two netstrings (ns1 and ns2) are concatenated and
   encoded as a netstring (ns3). A MAC is computed using the chosen
   integrity protection algorithm, the shared context key and ns3. The
   MAC is then encoded as a netstring (ns4).

   ns3 and ns4 are concatenated and this string is encoded as a
   netstring (ns5). ns5 is sent to the other party.




Burdis                   Expires March 13, 2001                [Page 11]


Internet-Draft    Secure Remote Password SASL Mechanism   September 2000


4.1.2 Decoding

   The received data is interpreted as a netstring. This string is the
   concatenation of two netstrings (ns3 and ns4). ns3 contains the
   concatenation of the (possibly encrypted) message data netstring
   (ns1) and the sequence number netstring (ns2). The interpretation of
   ns4 is the received message authentication code (MAC).

   The receiver computes a message authentication code using the chosen
   integrity protection algorithm (eg. HMAC-MD5), the shared context
   key and ns3. This computed MAC is compared with the received MAC. If
   the MACs do not match then that indicates that the message has been
   tampered with and the message SHOULD be rejected.

   If replay detection was requested then the receiver interprets ns2,
   checks that the sequence number is what it expects it to be, and
   rejects the message if it is not.

   The interpretation of ns3 is the (possibly encrypted) original
   message. If the message is encrypted it should be decrypted using
   the chosen confidentiality algorithm (eg. Blowfish) and the session
   key (K).





























Burdis                   Expires March 13, 2001                [Page 12]


Internet-Draft    Secure Remote Password SASL Mechanism   September 2000


5. Example

   The example below uses SMTP authentication [6]. The base64 encoding
   of challenges and responses, as well as the reply codes preceding
   the responses are part of the SMTP authentication[6] 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 krb.example.com

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

     C: AUTH SRP

     S: 334 MjA1OjEyODrurwq5rbON1pwz+Ar6j8XoYHJhh3X/PAueojFMnCVldtZ033S
     W6oHTODtIE9aSxuDg1djiULmL5I5JXB1gidrRXcfXtGFU1rbOjvStabFdSYJVmyl7z
     xiFxSn1ZmYOV+xo7bw8BXJswC/Uy/SXbqqa/VE4/oN2Q1ufxh0vwOsG4ywxOgIsNjQ
     6aW50ZWdyaXR5PWhtYWMtbWQ1LHJlcGxheSBkZXRlY3Rpb24sY29uZmlkZW50aWFsa
     XR5PWJsb3dmaXNoLWNiYyws

     C: MjE3OjU6a2VpdGgsNTprZWl0aCwxMjg6iNsL3XSGLjrCf/ecuOzQP0FyYI0WPJ6
     DFwlUKrnnsVTAo0mEWz03KcS4Q78BqTIQGpFny7W0KqP8WRX119ey5mcu4yh7M2qoS
     E51g/4baqVuCvPtrrodPExHIM1I+nIU/XlFMNjrC3WSuO/2P/jOQrHvflnOqoNltl0
     tpTW1F6IsNjQ6aW50ZWdyaXR5PWhtYWMtbWQ1LHJlcGxheSBkZXRlY3Rpb24sY29uZ
     mlkZW50aWFsaXR5PWJsb3dmaXNoLWNiYyws

     S: MTQ3OjEwOhUpUDmvEIlfBRAsMTI4OsSBV0SYkU6GiUISs1IIJgMbMJNMnSI+XSC
     aeoON4fPr1GrhE2k8YBvTx/gfNXg64Up7UwzxzrFO8CiizXc5By1vr0GPgjrlCA5t0
     zB9srXSN0rASwfVW4CJ9z3NZgnVEnEkHC31uk/pYMvepMDbHgyVzBVse4MmZEthOEJ
     An4/vLCw=

     C: MjA6+ebL5YgK6sztDcP1PZCrnMKIjFgs

     S: MjA6sE5gGxTxvc+yFPgygRuVvze9m6Ys

     C:

     S: 235 Authentication successful.







Burdis                   Expires March 13, 2001                [Page 13]


Internet-Draft    Secure Remote Password SASL Mechanism   September 2000


6. Discussion

   Although the MD5 and SHA-1 hash functions are used in this
   mechanism, they could be replaced with any iterative cryptographic
   hash function [5].

   The specified algorithms were chosen for utility and availablity. It
   was also felt that a mandatory confidentiality and integrity
   protection algorithm should be specified to ensure interoperability
   between implementations of this mechanism.

   The HMAC-MD5 algorithm was chosen as an integrity algorithm because
   it is faster than both HMAC-SHA1 and MAC algorithms based on secret
   key encryption algorithms [4].

   Blowfish was chosen as a cipher because [9]:

   o  it is free from intellectual property constraints

   o  it is fast

   o  it has withstood cryptanalysis since 1993

   o  a number of implementations in various programming languages are
      freely available

   Other algorithms that are identified as useful may be specified at a
   later stage.

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

   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 [10]:

      "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."








Burdis                   Expires March 13, 2001                [Page 14]


Internet-Draft    Secure Remote Password SASL Mechanism   September 2000


7. 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 [10] and section 4 "Security analysis"
   of [11].

   This mechanism also relies on the security of the HMAC algorithm and
   the underlying hash function. Section 6 "Security" of [5] discusses
   these security issues in detail. Weaknesses found in MD5 do not
   impact HMAC-MD5 [3].

   The Blowfish cipher has undergone cryptanalysis for a long period of
   time and no weaknesses have been found [9].

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

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

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




















Burdis                   Expires March 13, 2001                [Page 15]


Internet-Draft    Secure Remote Password SASL Mechanism   September 2000


8. Acknowledgements

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

      Timothy Martin <tmartin@andrew.cmu.edu>

      Raif S. Naffah <raif@forge.com.au>











































Burdis                   Expires March 13, 2001                [Page 16]


Internet-Draft    Secure Remote Password SASL Mechanism   September 2000


References

   [1]   Bernstein, D.J., "Netstrings", February 1997,
         <ftp://koobera.math.uic.edu/www/proto/netstrings.txt>.

   [2]   Bradner, S., "Key words for use in RFCs to Indicate
         Requirement Levels", BCP 0014, RFC 2119, March 1997.

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

   [4]   Eisler, M., "LIPKEY - A Low Infrastructure Public Key
         Mechanism Using SPKM", RFC 2847, June 2000.

   [5]   Krawczyk, H. et al, "HMAC: Keyed-Hashing for Message
         Authentication", RFC 2104, February 1997.

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

   [7]   Myers, J.G., "Simple Authentication and Security Layer
         (SASL)", RFC 2222, October 1997.

   [8]   Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June
         1999.

   [9]   Schneier, B., "The Blowfish Encryption Algorithm", March 1993,
         <http://www.counterpane.com/blowfish.html>.

   [10]  Wu, T., "Internet Draft: The SRP Authentication and Key
         Exchange System", July 1999, <draft-wu-srp-auth-03.txt>.

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

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













Burdis                   Expires March 13, 2001                [Page 17]


Internet-Draft    Secure Remote Password SASL Mechanism   September 2000


Author's Address

   K.R. Burdis
   Rhodes University
   Computer Science Department
   Grahamstown  6139
   ZA

   EMail: keith@rucus.ru.ac.za
   URI:   http://www.cryptix.org/~keith/









































Burdis                   Expires March 13, 2001                [Page 18]


Internet-Draft    Secure Remote Password SASL Mechanism   September 2000


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) [11]. These values are taken
   from software developed by Tom Wu and Eugene Jhong for the Stanford
   SRP distribution [12]. The modulus values are base64 encoded.


      [264 bits]
        Modulus =
          HMujfBWu4LfBFA0j3PpN7UbgUYfv.rMoMNuVRMoekpZ
        Generator = 2

      [384 bits]
        Modulus =
          W2KsCfRxb3/ELBvnVWufMA0gbdBlLXbJihgZkgp3xLTKwtPCUhSOHNZ5VLb9pBGR
        Generator = 2

      [512 bits]
        Modulus =
          3Kn/YYiomHkFkfM1x4kayR125MGkzpLUDy3y14FlTMwYnhZkjrMXnoC2TcFAecNl
          U5kFzgcpKYUbBOPZFRtyf3
        Generator = 2

      [640 bits]
        Modulus =
          CbDP.jR6YD6wAj2ByQWxQxQZ7.9J9xkn2.Uqb3zVm16vQyizprhBw9hi80psatZ8
          k54vwZfiIeEHZVsDnyqeWSSIpWso.wh5GD4OFgdhVI3
        Generator = 2

      [768 bits]
        Modulus =
          iqJ7nFZ4bGCRjE1F.FXEwL085Zb0kLM2TdHDaVVCdq0cKxvnH/0FLskJTKlDtt6s
          Dl89dc//aEULTVFGtcbA/tDzc.bnFE.DWthQOu2n2JwKjgKfgCR2lZFWXdnWmoOh
        Generator = 2

      [1024 bits]
        Modulus =
          Ewl2hcjiutMd3Fu2lgFnUXWSc67TVyy2vwYCKoS9MLsrdJVT9RgWTCuEqWJrfB6u
          E3LsE9GkOlaZabS7M29sj5TnzUqOLJMjiwEzArfiLr9WbMRANlF68N5AVLcPWvNx
          6Zjl3m5Scp0BzJBz9TkgfhzKJZ.WtP3Mv/67I/0wmRZ
        Generator = 2

      [1280 bits]
        Modulus =
          3NUKQ2Re4P5BEK0TLg2dX3gETNNNECPoe92h4OVMaDn3Xo/0QdjgG/EvM.hiVV1B
          dIGklSI14HA38Mpe5k04juR5/EXMU0r1WtsLhNXwKBlf2zEfoOh0zVmDvqInpU69
          5f29Iy7sNW3U5RIogcs740oUp2Kdv5wuITwnIx84cnO.e467/IV1lPnvMCr0pd1d


Burdis                   Expires March 13, 2001                [Page 19]


Internet-Draft    Secure Remote Password SASL Mechanism   September 2000


          gS0a.RV5eBJr03Q65Xy61R
        Generator = 2

      [1536 bits]
        Modulus =
          dUyyhxav9tgnyIg65wHxkzkb7VIPh4o0lkwfOKiPp4rVJrzLRYVBtb76gKlaO7ef
          5LYGEw3G.4E0jbMxcYBetDy2YdpiP/3GWJInoBbvYHIRO9uBuxgsFKTKWu7RnR7y
          Tau/IrFTdQ4LY/q.AvoCzMxV0PKvD9Odso/LFIItn8PbTov3VMn/ZEH2SqhtpBUk
          WtmcIkEflhX/YY/fkBKfBbe27/zUaKUUZEUYZ2H2nlCL60.JIPeZJSzsu/xHDVcx
        Generator = 2

      [2048 bits]
        Modulus =
          2iQzj1CagQc/5ctbuJYLWlhtAsPHc7xWVyCPAKFRLWKADpASkqe9djWPFWTNTdeJ
          tL8nAhImCn3Sr/IAdQ1FrGw0WvQUstPx3FO9KNcXOwisOQ1VlL.gheAHYfbYyBax
          XL.NcJx9TUwgWDT0hRzFzqSrdGGTN3FgSTA1v4QnHtEygNj3eZ.u0MThqWUaDiP8
          7nqha7XnT66bkTCkQ8.7T8L4KZjIImrNrUftedTTBi.WCi.zlrBxDuOM0da0JbUk
          QlXqvp0yvJAPpC11nxmmZOAbQOywZGmu9nhZNuwTlxjfIro0FOdthaDTuZRL9VL7
          MRPUDo/DQEyW.d4H.UIlzp
        Generator = 2































Burdis                   Expires March 13, 2001                [Page 20]


Internet-Draft    Secure Remote Password SASL Mechanism   September 2000


Full Copyright Statement

   Copyright (C) The Internet Society (2000). 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                   Expires March 13, 2001                [Page 21]