doc/specification/draft-nerenberg-sasl-crammd5-00.txt

   1
   2
   3 Network Working Group                                         J. Klensin
   4 Internet Draft: The CRAM-MD5 SASL Mechanism                 P. Krumviede
   5 Document: draft-nerenberg-sasl-crammd5-00.txt                   R. Catoe
   6                                                             L. Nerenberg
   7                                                            November 2001
   8
   9
  10
  11                       The CRAM-MD5 SASL Mechanism
  12
  13
  14 Status of this memo
  15
  16      This document is an Internet Draft and is in full conformance with
  17      all provisions of Section 10 of RFC 2026.
  18
  19      Internet Drafts are working documents of the Internet Engineering
  20      Task Force (IETF), its areas, and its working groups.  Note that
  21      other groups may also distribute working documents as Internet
  22      Drafts.
  23
  24      Internet Drafts are draft documents valid for a maximum of six
  25      months and may be updated, replaced, or obsoleted by other
  26      documents at any time.  It is inappropriate to use Internet Drafts
  27      as reference material or to cite them other than as "work in
  28      progress."
  29
  30      The list of current Internet Drafts can be accessed at
  31      http://www.ietf.org/ietf/1id-abstracts.txt
  32
  33      The list of Internet Draft Shadow Directories can be accessed at
  34      http://www.ietf.org/shadow.html.
  35
  36      A revised version of this draft document will be submitted to the
  37      RFC editor as a Proposed Standard for the Internet Community.
  38      Discussion and suggestions for improvement are requested.
  39      Distribution of this draft is unlimited.
  40
  41 1.  How to Read This Document
  42
  43      The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD
  44      NOT", "RECOMMENDED" and "MAY" in this document are to be inter-
  45      preted as defined in [KEYWORDS].
  46
  47 2.  Introduction
  48
  49      This document defines a simple challenge-response [SASL] authenti-
  50      cation mechanism, using a [KEYED-MD5] digest.
  51
  52 3.  CRAM-MD5 Authentication Mechanism
  53
  54      The mechanism name associated with CRAM-MD5 is 'CRAM-MD5'.
  55
  56      This mechanism does not provide a security layer.
  57
  58
  59
  60 Klensin, et al     draft-nerenberg-sasl-crammd5-00.txt          [Page 1]
  61 \f
  62 Internet Draft           CRAM-MD5 SASL Mechanism           November 2001
  63
  64
  65      The data encoded in the challenge contains a presumptively arbi-
  66      trary string of random digits, a timestamp, and the fully-qualified
  67      primary host name of the server.
  68
  69      The client makes note of the data and then responds with a string
  70      consisting of the user name, a space, and a "digest."  The latter
  71      is computed by applying the keyed MD5 algorithm from [KEYED-MD5]
  72      where the key is a shared secret and the digested text is the chal-
  73      lenge (including angle-brackets).
  74
  75      This shared secret is a string known only to the client and server.
  76      The "digest" parameter itself is a 16-octet value which is sent in
  77      hexadecimal format, using lower-case US-ASCII characters.
  78
  79      When the server receives this client response, it verifies the
  80      digest provided.  Since the user name may contain the space charac-
  81      ter, the server MUST scan the client response from right to left;
  82      the first space character encountered seperates the digest from the
  83      user name.  If the digest is correct, the server should consider
  84      the client authenticated and respond appropriately.
  85
  86 3.1.  Formal Syntax
  87
  88      The following syntax specification uses the augmented Backus-Naur
  89      Form (ABNF) as specified in [ABNF], and incorporates by reference
  90      the Core Rules defined in that document.
  91
  92      challenge  = "<" 1*DIGIT "." 1*DIGIT "@" hostname ">"
  93
  94      digest     = 32(DIGIT / %x61-66)
  95                   ; A hexadecimal string using only lower-case
  96                   ; letters
  97
  98      hostname   = 1*(ALPHA / DIGIT) *("." / "-" / ALPHA / DIGIT)
  99
 100      response   = user SP digest
 101
 102      user       = 1*OCTET
 103
 104
 105 3.2.  Examples
 106
 107      These examples show the use of the CRAM-MD5 mechanism with the
 108      IMAP4 AUTHENTICATE command [IMAP4].  The base64 encoding of the
 109      challenges and responses is part of the IMAP4 AUTHENTICATE command,
 110      not part of the CRAM-MD5 specification itself.
 111
 112           S: * OK IMAP4rev1 Server
 113           C: A0001 AUTHENTICATE CRAM-MD5
 114           S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+
 115           C: dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw
 116           S: A0001 OK CRAM-MD5 authentication successful
 117
 118      In this example, the shared secret is the string
 119
 120
 121
 122 Klensin, et al     draft-nerenberg-sasl-crammd5-00.txt          [Page 2]
 123 \f
 124 Internet Draft           CRAM-MD5 SASL Mechanism           November 2001
 125
 126
 127           tanstaaftanstaaf
 128
 129      Hence, the Keyed MD5 digest is produced by calculating
 130
 131           MD5((tanstaaftanstaaf XOR opad),
 132                MD5((tanstaaftanstaaf XOR ipad),
 133                <1896.697170952@postoffice.reston.mci.net>))
 134
 135      where ipad and opad are as defined in [KEYED-MD5] and the string
 136      shown in the challenge is the base64 encoding of
 137      <1896.697170952@postoffice.reston.mci.net>. The shared secret is
 138      null-padded to a length of 64 bytes. If the shared secret is longer
 139      than 64 bytes, the MD5 digest of the shared secret is used as a 16
 140      byte input to the keyed MD5 calculation.
 141
 142      This produces a digest value (in hexadecimal) of
 143
 144           b913a602c7eda7a495b4e6e7334d3890
 145
 146      The user name is then prepended to it, forming
 147
 148           tim b913a602c7eda7a495b4e6e7334d3890
 149
 150      Which is then base64 encoded to meet the requirements of the IMAP4
 151      AUTHENTICATE command (or the similar POP3 AUTH command), yielding
 152
 153           dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw
 154
 155
 156 4.  References
 157
 158 4.1.  Normative References
 159
 160      [ABNF] Croker, D., P. Overell, "Augmented BNF for Syntax Specifica-
 161      tions: ABNF," RFC2234, November 1997
 162
 163      [KEYED-MD5] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for
 164      Message Authentication," RFC 2104, February 1997.
 165
 166      [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
 167      Requirement Levels," BCP 9, RFC2119, March 1997
 168
 169      [MD5] Rivest, R., "The MD5 Message Digest Algorithm," RFC 1321,
 170      April 1992.
 171
 172      [SASL] Myers, J., "Simple Authentication and Security Layer
 173      (SASL)," RFC 2222, October 1997
 174
 175 4.2.  Informative References
 176
 177      [IMAP4] Crispin, M., "Internet Message Access Protocol - Version
 178      4rev1," RFC 2060, December 1996.
 179
 180
 181
 182
 183
 184 Klensin, et al     draft-nerenberg-sasl-crammd5-00.txt          [Page 3]
 185 \f
 186 Internet Draft           CRAM-MD5 SASL Mechanism           November 2001
 187
 188
 189 5.  Security Considerations
 190
 191      It is conjectured that use of the CRAM-MD5 authentication mechanism
 192      provides replay protection for a session.
 193
 194      This mechanism does not obscure the user name in any way.  Accord-
 195      ingly, a server that implements both a cleartext password command
 196      and this authentication type should not allow both methods of
 197      access for a given user name.
 198
 199      Keyed MD5 is chosen for this application because of the greater
 200      security imparted to authentication of short messages. In addition,
 201      the use of the techniques described in [KEYED-MD5] for precomputa-
 202      tion of intermediate results make it possible to avoid explicit
 203      cleartext storage of the shared secret on the server system by
 204      instead storing the intermediate results which are known as "con-
 205      texts."
 206
 207      While the saving, on the server, of the MD5 "context" is marginally
 208      better than saving the shared secrets in cleartext, it is not suf-
 209      ficient to protect the secrets if the server itself is compromised.
 210      Consequently, servers that store the secrets or contexts must both
 211      be protected to a level appropriate to the potential information
 212      value in the data and services protected by this mechanism.  In
 213      other words, techniques like this one involve a tradeoff between
 214      vulnerabilty to network sniffing and I/O buffer snooping and vul-
 215      nerability of the server host's databases.  If one believes that
 216      the host and its databases are subject to compromise, and the net-
 217      work is not, this technique (and all others like it) is unattrac-
 218      tive.  It is perhaps even less attractive than cleartext passwords,
 219      which are typically stored on hosts in one-way hash form.  On the
 220      other hand, if the server databases are perceived as reasonably
 221      secure, and one is concerned about client-side or network intercep-
 222      tion of the passwords (secrets), then this (and similar) techniques
 223      are preferable to clear-text passwords by a wide margin.
 224
 225      As the length of the shared secret increases, so does the diffi-
 226      culty of deriving it.
 227
 228      While there are now suggestions in the literature that the use of
 229      MD5 and keyed MD5 in authentication procedures probably has a lim-
 230      ited effective lifetime, the technique is now widely deployed and
 231      widely understood.  It is believed that this general understanding
 232      may assist with the rapid replacement, by CRAM-MD5, of the current
 233      uses of permanent cleartext passwords in many protocols.  This doc-
 234      ument has been deliberately written to permit easy upgrading to use
 235      SHA (or whatever alternatives emerge) when they are considered to
 236      be widely available and adequately safe.
 237
 238      Even with the use of CRAM-MD5, users are still vulnerable to active
 239      attacks.  An example of an increasingly common active attack is
 240      'TCP Session Hijacking' as described in CERT Advisory CA-95:01.
 241
 242
 243
 244
 245
 246 Klensin, et al     draft-nerenberg-sasl-crammd5-00.txt          [Page 4]
 247 \f
 248 Internet Draft           CRAM-MD5 SASL Mechanism           November 2001
 249
 250
 251 6.  Authors' Addresses
 252
 253      John C. Klensin
 254      MCI Telecommunications
 255      800 Boylston St, 7th floor
 256      Boston, MA 02199
 257      USA
 258
 259      EMail: klensin@mci.net
 260      Phone: +1 617 960 1011
 261
 262      Paul Krumviede
 263      MCI Telecommunications
 264      2100 Reston Parkway
 265      Reston, VA 22091
 266      USA
 267
 268      EMail: paul@mci.net
 269      Phone: +1 703 715 7251
 270
 271      Randy Catoe
 272      MCI Telecommunications
 273      2100 Reston Parkway
 274      Reston, VA 22091
 275      USA
 276
 277      EMail: randy@mci.net
 278      Phone: +1 703 715 7366
 279
 280      Lyndon Nerenberg
 281      ACI Worldwide
 282      Suite 900
 283      10117 Jasper Avenue
 284      Edmonton, AB
 285      Canada  T5J 1W8
 286
 287      Email: lyndon@atg.aciworldwide.com
 288      Phone: +1 780 424 4922
 289
 290
 291
 292
 293
 294
 295
 296
 297
 298
 299
 300
 301
 302
 303
 304
 305
 306
 307
 308 Klensin, et al     draft-nerenberg-sasl-crammd5-00.txt          [Page 5]
 309 \f