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

Versions: 00 01 02 03 04 05 06 07 08                                    
Network Working Group                                        K.R. Burdis
Internet Draft                                         Rhodes University
Expires: March 1999                                          August 1999
draft-burdis-cat-srp-sasl-00.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 integrity 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].

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

Burdis                                                          [Page 1]


draft-burdis-cat-srp-sasl-01.txt                               August 1999

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

3 Protocol Description

   This mechanism is based on the SRP-SHA1 protocol described in [SRP-
   DRAFT].  Additionally optimised SRP as described in [SRP] is used.
   It 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 mutual authentication
   and integrity protection should take place.

     Client          Server

        <-- N, g --

        -- c,A -->

        <-- s,B --

        -- M1,o,m -->

        <-- M2 --

 3.1 Server sends N and g

   The prime modulus (N) is encoded as a netstring. The generator (g) is
   encoded as a netstring. These two netstrings are appended and this
   string is encoded as a netstring. The resulting string 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:

Burdis                                                          [Page 2]


draft-burdis-cat-srp-sasl-01.txt                               August 1999

     g = <02>

   N encoded as a netstring is:

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

   g encoded as a netstring is:

     1:<02>,

   The final string is:

     137: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>,,

 3.2 Client sends request

   The client's username (c) is encoded as a netstring. The client
   generates its ephemeral public key (A) and this is encoded as a
   netstring. These two netstrings are appended and this string is
   encoded as a netstring.  The resulting string is sent to the server.

 3.3 Server sends response

   The client's salt (s) is encoded as a netstring. The server generates
   its ephemeral public key (B) and this is encoded as a netstring.
   These two netstrings are appended and this string is encoded as a
   netstring.  The resulting string is sent to the client.

 3.4 Client sends evidence

   The client calculates the shared context key (k).

   The client calculates the evidence that proves to the server that it
   knows the shared context key. This evidence (M1) is encoded as a
   netstring.

   The client creates an 8-bit bit-string that specifies the options
   that it requests. If bit 0 is set then the client requests mutual
   authentication.  If bit 1 is set then the client requests integrity
   protection. The other bits are reserved for future use. This options

Burdis                                                          [Page 3]


draft-burdis-cat-srp-sasl-01.txt                               August 1999

   byte (o) is encoded as a netstring.

   The client calculates a message authentication code (MAC) over the
   options byte netstring. The HMAC-SHA1 algorithm [HMAC] is used, with
   the shared context key (k) as the input key. The MAC (m) is encoded
   as a netstring.

   These three netstrings are appended together and this string is
   encoded as a netstring. The resulting string is sent to the client.

 3.5 Server sends evidence

   The server calculates the shared context key (k).

   If the client requested mutual authentication then the server
   calculates the evidence (M2) that proves to the client that it knows
   the shared context key. This evidence is encoded as a netstring and
   sent to the client. (Note that section 5.2 of [SASL] "Server returns
   success with additional data" applies here.)

4 Security Layer

   The security layer provides integrity protection using the HMAC-SHA1
   [HMAC] algorithm. The shared context key (k) is used as the input
   key.  The encoding and decoding of message data is described below.

 4.1 Encoding

   The message data is encoded as a netstring. A MAC is computed using
   the shared context key and the unencoded message data. The MAC is
   then encoded as a netstring. These two netstrings are appended and
   the string is encoded as a netstring. The resulting string is sent to
   the other party.

 4.2 Decoding

   The message data is interpreted as a netstring. This string is then
   interpreted as two netstrings. The first netstring interpretation is
   the received message data. The second netstring interpretation is the
   received message authentication code (MAC). A message authentication
   code is computed using the shared context key and the received
   message data. This 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 discarded, and the other party
   informed.

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

Burdis                                                          [Page 4]


draft-burdis-cat-srp-sasl-01.txt                               August 1999

   respectively.

     S: +OK POP3 server ready
     C: AUTH SRP
     S: + nCpSwCJ8uEeZgn5DbQmxCAgmb6ftsJxkqrKCSJqGJSywlUZCwIlxA9XJwj2fV
     xs01hN85kTq8AnlVkW4U5Po5ZA3ZkLk5B7W9gd1e3KW55cvNpwWmCOcZWmd8dC1MMq
     SzBp b3s0CMbvUQuOqGXWXZNi/oBr9CdyMvY.7zakYxeUZsZSj2ZchpB34w0Ymi
     C: CJGrEZKwQsLfT6WiCJ8uEYcuV8oVukbK4jbGFmK/WjzLwAEMu3cDN/lccHr6uET
     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 authentication successful

Security Considerations

   This mechanism relies on the security of SRP, which is believed to be
   extremely secure. Please see section 4 "Security Considerations" of
   [SRP-DRAFT] and section 4 "Security analysis" of [SRP].

   The options byte that is used by the client to possibly request
   mutual authentication and integrity protection could be modified by
   an attacker before reaching the server. For this reason a MAC
   generated using HMAC-SHA1 and the shared context key is used to
   insure the server of its integrity.

6. Author's Address

   Keith Burdis
   Computer Science Department
   Rhodes University
   6139 Grahamstown

   Email: cskb@cs.ru.ac.za

7. References

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

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

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

   [SASL] Myers, John G, "Simple Authentication and Security Layer

Burdis                                                          [Page 5]


draft-ietf-cat-srp-sasl-01.txt                               August 1999

          (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 6]