doc/specification/draft-nerenberg-sasl-crammd5-02.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-02.txt                   R. Catoe
   6                                                       L. Nerenberg (Ed.)
   7                                                                June 2002
   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-02.txt          [Page 1]
  61 \f
  62 Internet Draft           CRAM-MD5 SASL Mechanism               June 2002
  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). The client MUST NOT interpret or
  74      attempt to validate the contents of the challenge in any way.
  75
  76      This shared secret is a string known only to the client and server.
  77      The "digest" parameter itself is a 16-octet value which is sent in
  78      hexadecimal format, using lower-case US-ASCII characters.
  79
  80      When the server receives this client response, it verifies the
  81      digest provided.  Since the user name may contain the space charac-
  82      ter, the server MUST scan the client response from right to left;
  83      the first space character encountered separates the digest from the
  84      user name.  If the digest is correct, the server should consider
  85      the client authenticated and respond appropriately.
  86
  87      The user name and shared secret MUST be represented in the Unicode
  88      character set [UNICODE], and MUST be normalised using the Unicode
  89      Normalisation Form KC [NFKC]. The resulting values MUST be encoded
  90      as UTF-8 [UTF8].
  91
  92
  93 3.1.  Formal Syntax
  94
  95      The following syntax specification uses the augmented Backus-Naur
  96      Form (ABNF) as specified in [ABNF], and incorporates by reference
  97      the Core Rules defined in that document.
  98
  99      challenge  = "<" 1*DIGIT "." 1*DIGIT "@" hostname ">"
 100
 101      digest     = 32(DIGIT / %x61-66)
 102                   ; A hexadecimal string using only lower-case
 103                   ; letters
 104
 105      hostname   = 1*(ALPHA / DIGIT) *("." / "-" / ALPHA / DIGIT)
 106
 107      response   = user SP digest
 108
 109      user       = 1*OCTET
 110
 111
 112 3.2.  Examples
 113
 114      These examples show the use of the CRAM-MD5 mechanism with the
 115      IMAP4 AUTHENTICATE command [IMAP4].  The base64 encoding of the
 116      challenges and responses is part of the IMAP4 AUTHENTICATE command,
 117      not part of the CRAM-MD5 specification itself.
 118
 119
 120
 121
 122 Klensin, et al     draft-nerenberg-sasl-crammd5-02.txt          [Page 2]
 123 \f
 124 Internet Draft           CRAM-MD5 SASL Mechanism               June 2002
 125
 126
 127           S: * OK IMAP4rev1 Server
 128           C: A0001 AUTHENTICATE CRAM-MD5
 129           S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+
 130           C: dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw
 131           S: A0001 OK CRAM-MD5 authentication successful
 132
 133      In this example, the shared secret is the string
 134
 135           tanstaaftanstaaf
 136
 137      Hence, the Keyed MD5 digest is produced by calculating
 138
 139           MD5((tanstaaftanstaaf XOR opad),
 140                MD5((tanstaaftanstaaf XOR ipad),
 141                <1896.697170952@postoffice.reston.mci.net>))
 142
 143      where ipad and opad are as defined in [KEYED-MD5] and the string
 144      shown in the challenge is the base64 encoding of
 145      <1896.697170952@postoffice.reston.mci.net>. The shared secret is
 146      null-padded to a length of 64 bytes. If the shared secret is longer
 147      than 64 bytes, the MD5 digest of the shared secret is used as a 16
 148      byte input to the keyed MD5 calculation.
 149
 150      This produces a digest value (in hexadecimal) of
 151
 152           b913a602c7eda7a495b4e6e7334d3890
 153
 154      The user name is then prepended to it, forming
 155
 156           tim b913a602c7eda7a495b4e6e7334d3890
 157
 158      Which is then base64 encoded to meet the requirements of the IMAP4
 159      AUTHENTICATE command (or the similar POP3 AUTH command), yielding
 160
 161           dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw
 162
 163
 164 4.  References
 165
 166 4.1.  Normative References
 167
 168
 169      [ABNF]
 170           Crocker, D., P. Overell, "Augmented BNF for Syntax Specifica-
 171           tions: ABNF", RFC2234, Internet Mail Consortium and Demon
 172           Internet Ltd., November 1997.
 173
 174
 175      [KEYED-MD5]
 176           Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for Message
 177           Authentication", RFC 2104, IBM and UCSD, February 1997.
 178
 179
 180
 181
 182
 183
 184 Klensin, et al     draft-nerenberg-sasl-crammd5-02.txt          [Page 3]
 185 \f
 186 Internet Draft           CRAM-MD5 SASL Mechanism               June 2002
 187
 188
 189      [KEYWORDS]
 190           Bradner, S., "Key words for use in RFCs to Indicate Require-
 191           ment Levels", BCP 9, RFC2119, Harvard University, March 1997.
 192
 193
 194      [MD5]
 195           Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, MIT
 196           Laboratory for Computer Science and RSA Data Security, Inc.,
 197           April 1992.
 198
 199
 200      [NFKC]
 201           Davis, M., M. Durst, "Unicode Standard Annex #15: Unicode Nor-
 202           malisation Forms", An integral part of The Unicode Standard,
 203           Version 3.1.1 (http://www.uni-
 204           code.org/reports/tr15/tr15-21.html).
 205
 206
 207      [SASL]
 208           Myers, J., "Simple Authentication and Security Layer (SASL),"
 209           RFC 2222, Netscape Communications, October 1997.
 210
 211
 212      [UNICODE]
 213           The Unicode Consortium, "The Unicode Standard, Version 3.1.1",
 214           defined by: The Unicode Standard, Version 3.0 (Reading, MA,
 215           Addison-Wesley, 2000.  ISBN 0-201-61633-5), as amended by the
 216           Unicode Standard Annex #27: Unicode 3.1 (http://www.uni-
 217           code.org/reports/tr27/) and the Unicode 3.1.1 Update Notice
 218           (http://www.unicode.org/versions/ Unicode3.1.1.html).
 219
 220
 221      [UTF8]
 222           Yergeau, F., "UTF-8, a transformation format of ISO 10646",
 223           RFC 2279, Alis Technologies, January 1998.
 224
 225 4.2.  Informative References
 226
 227      [IMAP4] Crispin, M., "Internet Message Access Protocol - Version
 228      4rev1," RFC 2060, University of Washington, December 1996.
 229
 230 5.  Security Considerations
 231
 232      It is conjectured that use of the CRAM-MD5 authentication mechanism
 233      provides replay protection for a session.
 234
 235      This mechanism does not obscure the user name in any way.  Accord-
 236      ingly, a server that implements both a cleartext password command
 237      and this authentication type should not allow both methods of
 238      access for a given user name.
 239
 240      Keyed MD5 is chosen for this application because of the greater
 241      security imparted to authentication of short messages. In addition,
 242      the use of the techniques described in [KEYED-MD5] for
 243
 244
 245
 246 Klensin, et al     draft-nerenberg-sasl-crammd5-02.txt          [Page 4]
 247 \f
 248 Internet Draft           CRAM-MD5 SASL Mechanism               June 2002
 249
 250
 251      precomputation of intermediate results make it possible to avoid
 252      explicit cleartext storage of the shared secret on the server sys-
 253      tem by instead storing the intermediate results which are known as
 254      "contexts."
 255
 256      While the saving, on the server, of the MD5 "context" is marginally
 257      better than saving the shared secrets in cleartext, it is not suf-
 258      ficient to protect the secrets if the server itself is compromised.
 259      Consequently, servers that store the secrets or contexts must both
 260      be protected to a level appropriate to the potential information
 261      value in the data and services protected by this mechanism.  In
 262      other words, techniques like this one involve a tradeoff between
 263      vulnerability to network sniffing and I/O buffer snooping and vul-
 264      nerability of the server host's databases.  If one believes that
 265      the host and its databases are subject to compromise, and the net-
 266      work is not, this technique (and all others like it) is unattrac-
 267      tive.  It is perhaps even less attractive than cleartext passwords,
 268      which are typically stored on hosts in one-way hash form.  On the
 269      other hand, if the server databases are perceived as reasonably
 270      secure, and one is concerned about client-side or network intercep-
 271      tion of the passwords (secrets), then this (and similar) techniques
 272      are preferable to clear-text passwords by a wide margin.
 273
 274      As the length of the shared secret increases, so does the diffi-
 275      culty of deriving it.
 276
 277      While there are now suggestions in the literature that the use of
 278      MD5 and keyed MD5 in authentication procedures probably has a lim-
 279      ited effective lifetime, the technique is now widely deployed and
 280      widely understood.  It is believed that this general understanding
 281      may assist with the rapid replacement, by CRAM-MD5, of the current
 282      uses of permanent cleartext passwords in many protocols.  This doc-
 283      ument has been deliberately written to permit easy upgrading to use
 284      SHA (or whatever alternatives emerge) when they are considered to
 285      be widely available and adequately safe.
 286
 287      Even with the use of CRAM-MD5, users are still vulnerable to active
 288      attacks.  An example of an increasingly common active attack is
 289      'TCP Session Hijacking' as described in CERT Advisory CA-95:01.
 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-02.txt          [Page 5]
 309 \f
 310 Internet Draft           CRAM-MD5 SASL Mechanism               June 2002
 311
 312
 313 6.  Authors' Addresses
 314
 315      John C. Klensin
 316      MCI Telecommunications
 317      800 Boylston St, 7th floor
 318      Boston, MA 02199
 319      USA
 320
 321      EMail: klensin@mci.net
 322      Phone: +1 617 960 1011
 323
 324      Paul Krumviede
 325      MCI Telecommunications
 326      2100 Reston Parkway
 327      Reston, VA 22091
 328      USA
 329
 330      EMail: paul@mci.net
 331      Phone: +1 703 715 7251
 332
 333      Randy Catoe
 334      MCI Telecommunications
 335      2100 Reston Parkway
 336      Reston, VA 22091
 337      USA
 338
 339      EMail: randy@mci.net
 340      Phone: +1 703 715 7366
 341
 342      Lyndon Nerenberg (Ed.)
 343      ACI Worldwide
 344      Suite 900
 345      10117 Jasper Avenue
 346      Edmonton, AB
 347      Canada  T5J 1W8
 348
 349      Email: lyndon@atg.aciworldwide.com
 350      Phone: +1 780 424 4922
 351
 352
 353
 354
 355
 356
 357
 358
 359
 360
 361
 362
 363
 364
 365
 366
 367
 368
 369
 370 Klensin, et al     draft-nerenberg-sasl-crammd5-02.txt          [Page 6]
 371 \f