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

Versions: 00 01 02 03 04 05 06 07 08                                    
Network Group                                                K.R. Burdis
Internet Draft                                         Rhodes University
Expires: July 2000                                          January 2000
draft-burdis-cat-srp-sasl-02.txt

                 Secure Remote Password SASL Mechanism

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.

Abstract

   This document describes an SASL mechanism based on the Secure Remote
   Password protocol. This mechanism allows a client to be authenticated
   to a server, and optionally the server authenticated to the client.
   Additionally a security layer providing replay detection, integrity
   protection and/or confidentiality protection can be provided.

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!" [Netstring].
   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 [KEYWORDS].

2 Netstrings

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

     A netstring is a self-delimiting encoding of a string. Netstrings



Burdis                                                          [Page 1]


draft-burdis-cat-srp-sasl-02.txt                            January 2000


     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.

3 Protocol Description

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

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

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

          --  U,A,o  -->

         <--  s,B  --




Burdis                                                          [Page 2]


draft-burdis-cat-srp-sasl-02.txt                            January 2000


          --  M1  -->

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

         <--  M2  --

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

   where:

     | is the concatenation operator

     H is the SHA-1 one-way function

     N is the prime modulus

     g is the generator

     Z is the options byte indicating which of the security services the
       server can provide

     U is the client's username

     A is the client's ephemeral public key

     o is the options byte 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 Z

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

   The server creates an 8-bit bit-string, most significant bit first,
   that specifies the security service options that it supports.

    * Bit 0 must be set indicating that the server suports integrity
      protection using the HMAC-MD5 algorithm [HMAC], support for which
      is MANDATORY.

    * If bit 1 is set then the server supports replay detection using
      sequence numbers.

    * If bit 2 is set then the server supports confidentiality
      protection using the Blowfish cipher in CBC mode [Blowfish].

   The other bits are reserved for future use. This options byte (Z) is



Burdis                                                          [Page 3]


draft-burdis-cat-srp-sasl-02.txt                            January 2000


   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 = <88 EA C4 53 65 6B 0E CC 2A AC 25 1A 9D F6 4F BB
          B4 D5 43 1C 4F 44 13 73 CE AF 7A 33 3A 4A FE CA
          26 14 FA B4 2A 5F EF 60 01 AD 72 05 B9 DD 08 2B
          1B DF BA 01 1E 15 9C 85 8C A0 E3 B9 5B 85 2C 78
          09 AA 70 68 0D 48 05 16 6E 57 CF A8 30 31 89 A3
          83 09 C8 9C C0 56 5B 47 3D 2F 39 43 D8 03 16 97
          97 9A E1 8D 10 86 08 63 5E CF F2 2F 52 4C 9F C5
          B9 8B E1 FD 92 E8 BB A1 E8 F6 8D CB 42 8E 6A F3>

   and:

     g = <02>

   and:

     Z = <07>

   N encoded as a netstring is:

     <31 32 38 3A 88 EA C4 53 65 6B 0E CC 2A AC 25 1A 9D F6
      4F BB B4 D5 43 1C 4F 44 13 73 CE AF 7A 33 3A 4A FE CA
      26 14 FA B4 2A 5F EF 60 01 AD 72 05 B9 DD 08 2B 1B DF
      BA 01 1E 15 9C 85 8C A0 E3 B9 5B 85 2C 78 09 AA 70 68
      0D 48 05 16 6E 57 CF A8 30 31 89 A3 83 09 C8 9C C0 56
      5B 47 3D 2F 39 43 D8 03 16 97 97 9A E1 8D 10 86 08 63
      5E CF F2 2F 52 4C 9F C5 B9 8B E1 FD 92 E8 BB A1 E8 F6
      8D CB 42 8E 6A F3 2C>

   g encoded as a netstring is:

     "1:<02>," or <31 3A 02 2C>

   Z encoded as a netstring is:

     "1:<07>," or <31 3A 07 2C>

   The final string is:

     "141:128:<88 EA C4 53 65 6B 0E CC 2A AC 25 1A 9D F6 4F
      BB B4 D5 43 1C 4F 44 13 73 CE AF 7A 33 3A 4A FE CA 26
      14 FA B4 2A 5F EF 60 01 AD 72 05 B9 DD 08 2B 1B DF BA
      01 1E 15 9C 85 8C A0 E3 B9 5B 85 2C 78 09 AA 70 68 0D
      48 05 16 6E 57 CF A8 30 31 89 A3 83 09 C8 9C C0 56 5B
      47 3D 2F 39 43 D8 03 16 97 97 9A E1 8D 10 86 08 63 5E
      CF F2 2F 52 4C 9F C5 B9 8B E1 FD 92 E8 BB A1 E8 F6 8D
      CB 42 8E 6A F3>,1:<02>,1:<07>,,"



Burdis                                                          [Page 4]


draft-burdis-cat-srp-sasl-02.txt                            January 2000


     or

     <31 34 31 3A 31 32 38 3A 88 EA C4 53 65 6B 0E CC 2A AC
      25 1A 9D F6 4F BB B4 D5 43 1C 4F 44 13 73 CE AF 7A 33
      3A 4A FE CA 26 14 FA B4 2A 5F EF 60 01 AD 72 05 B9 DD
      08 2B 1B DF BA 01 1E 15 9C 85 8C A0 E3 B9 5B 85 2C 78
      09 AA 70 68 0D 48 05 16 6E 57 CF A8 30 31 89 A3 83 09
      C8 9C C0 56 5B 47 3D 2F 39 43 D8 03 16 97 97 9A E1 8D
      10 86 08 63 5E CF F2 2F 52 4C 9F C5 B9 8B E1 FD 92 E8
      BB A1 E8 F6 8D CB 42 8E 6A F3 2C 31 3A 02 2C 31 3A 07
      2C 2C>

 3.2 Client sends request

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

   The client creates an 8-bit bit-string, most significant bit first,
   that specifies the security service options that it requests. (The
   client can only select security services that the server has
   indicated it can provide).

    * If bit 0 is set then the client requests integrity protection
      using the HMAC-MD5 algorithm [HMAC].

    * If bit 1 is set then the client requests replay detection using
      sequence numbers. (Note that bit 0 must be set if this bit is
      set).

    * If bit 2 is set then the client requests confidentiality
      protection using the Blowfish cipher in CBC mode [Blowfish].

   The other bits are reserved for future use. This options byte (o) is
   encoded as a netstring (ns2).

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




Burdis                                                          [Page 5]


draft-burdis-cat-srp-sasl-02.txt                            January 2000


   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 N, g, s, Z, A and
   B as part of the calculation.

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

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

 3.5 Server sends evidence

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

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

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

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:

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

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

    * if just integrity protection is requested then the integrity
      checksum is calculated on the message data as described in section
      4.1

    * if both integrity protection and confidentiality protection are
      requested then the message data is first encrypted using the
      chosen confidentiality algorithm (ie. Blowfish). Thereafter the
      integrity checksum is calculated on the encrypted message data as
      described in section 4.1

    * 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 may be provided using the HMAC-MD5 [HMAC]



Burdis                                                          [Page 6]


draft-burdis-cat-srp-sasl-02.txt                            January 2000


   algorithm. The shared context key (K) is 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 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 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.

  4.1.2 Decoding

   The message data is interpreted as a netstring. This string is the
   concatenation of two netstrings (ns3 and ns4). ns3 contains the
   concatenation of the received (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 HMAC-MD5,
   the shared context key and ns3. This MAC is compared with the
   received MAC. If the MACs do not match then that indicates that the
   message has been tampered with, the message should be discarded, and
   the other party informed.

   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 (ie. Blowfish) and the session key
   (K).

5 Example

   The example below uses POP authentication [POP3 AUTH]. The base64
   encoding of challenges and responses, as well as the "+ " preceding
   the responses are part of the [POP3 AUTH] specification, not part of
   this SASL mechanism itself.

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

     S: +OK POP3 server ready
     C: AUTH SRP-SASL
     S: + nCpSwCJ8uEeZgn5DbQmxCAgmb6ftsJxkqrKCSJqGJSywlUZCwIlxA9XJwj2fV
     xs01hN85kTq8AnlVkW4U5Po5ZA3ZkLk5B7W9gd1e3KW55cvNpwWmCOcZWmd8dC1MMq
     SzBp b3s0CMbvUQuOqGXWXZNi/oBr9CdyMvY.7zakYxeUZsZSj2ZchpB34w0Ymi
     C: CJGrEZKwQsLfT6WiCJ8uEYcuV8oVukbK4jbGFmK/WjzLwAEMu3cDN/lccHr6uET



Burdis                                                          [Page 7]


draft-burdis-cat-srp-sasl-02.txt                            January 2000


     atd6MihIY5Gvr2YNAiXVic0Ot92MdwNBK64Qk0ouQ88VNsCkNedFfY9XN4tmJgt43L
     NLN4e/xj6vGTHemh3tp.5qeP5USy/MJ9/qLc/mOyJNAq3.XAUaEjRJRTxmAQOlmB
     34w0Imi
     S: + 34qDpenC3eibawB5vqHzM.FB34oE3erYpK/70WbK/9gj3pdaUH3O2d2jHcuHz
     jaTJCFKHUtOmy9GGKooFMPHCE0xTRHH0uP936Kea7kBx7/STQvpjHQ3UzIPk1Gf9Rl
     MXMYzuzpJM2dvYV0Lfjko4/DDNNj6S1of2v7XlnoXElqCvQxL3O8LTpjfolhjR1SCD
     j50YYvEImi
     C: CZ0wiVpgmEU96.PIMKx1PS8wRUb0m8Wi
     S: + CZ0wN8a1KmQXLlbsd3Q8obkMu7wgAmqi
     C:
     S: +OK SRP-SASL authentication successful

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

   The specified algorithms were chosen for utility and availablity.

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

   Blowfish was chosen as a cipher because [Blowfish]:
    * it is free from intellectual property constraints
    * it is fast
    * it supports variable key lengths from 32 bits to 448 bits
    * it has withstood cryptanalysis since 1993
    * 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.

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

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

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



Burdis                                                          [Page 8]


draft-burdis-cat-srp-sasl-02.txt                            January 2000


   U, A and o sent from the client to the server, and N, g, Z, 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.

Acknowledgements

   Thanks to Raif S. Naffah <raif@forge.com.au> for corrections and
   helpful suggestions.

Author's Address

   Keith Burdis
   Computer Science Department
   Rhodes University
   6139 Grahamstown
   South Africa

   Email: cskb@cs.ru.ac.za

References

   [Blowfish]     Schneier, Bruce, "The Blowfish Encryption Algorithm",
   URL: http://www.counterpane.com/blowfish.html

   [Dobbertin]    Dobbertin, Hans, "The Status of MD5 After a Recent
   Attack", CryptoBytes, RSA Laboratories, URL:
   ftp://ftp.rsasecurity.com/pub/cryptobytes/crypto2n2.pdf

   [HMAC]         Krawczyk, Hugo et.al. "HMAC: Keyed-Hashing for Message
   Authentication", Internet RFC 2104

   [KEYWORDS]     Bradner, Scott, "Key words for use in RFCs to Indicate
   Requirement Levels", Internet RFC 2119

   [LIPKEY]       Eisler, Mike, "LIPKEY - A Low Infrastructure Public Key
   Mechanism Using SPKM", Internet Draft, draft-ietf-cat-lipkey-03.txt

   [Netstring]    Bernstein, Daniel J, "Netstrings", URL:
   ftp://koobera.math.uic.edu/www/proto/netstrings.txt

   [POP3 AUTH]    Myers, John G, "POP3 AUTHentication command", Internet
   RFC 1734



Burdis                                                          [Page 9]


draft-burdis-cat-srp-sasl-02.txt                            January 2000


   [SASL]         Myers, John G, "Simple Authentication and Security
   Layer (SASL)", Internet RFC 2222

   [SRP-DRAFT]    Wu, Thomas, "The SRP Authentication and Key Exchange
   System", Internet Draft, draft-wu-srp-auth-03.txt

   [SRP]          Wu, Thomas, "The Secure Remote Password Protocol", 1998
   Internet Society Symposium on Network and Distributed Security

















































Burdis                                                         [Page 10]