doc/draft-ietf-sasl-crammd5-xx.txt

   1
   2
   3 Network Working Group                               L. Nerenberg, Editor
   4 Internet Draft: The CRAM-MD5 SASL Mechanism              Orthanc Systems
   5 Document: draft-ietf-sasl-crammd5-01.txt                   November 2003
   6
   7
   8
   9                       The CRAM-MD5 SASL Mechanism
  10
  11
  12 Status of this Memo
  13
  14      This document is an Internet Draft and is in full conformance with
  15      all provisions of Section 10 of RFC 2026.
  16
  17      Internet Drafts are working documents of the Internet Engineering
  18      Task Force (IETF), its areas, and its working groups.  Note that
  19      other groups may also distribute working documents as Internet
  20      Drafts.
  21
  22      Internet Drafts are draft documents valid for a maximum of six
  23      months and may be updated, replaced, or obsoleted by other docu-
  24      ments at any time.  It is inappropriate to use Internet Drafts as
  25      reference material or to cite them other than as "work in
  26      progress."
  27
  28      The list of current Internet Drafts can be accessed at
  29      http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet
  30      Draft Shadow Directories can be accessed at
  31      http://www.ietf.org/shadow.html.
  32
  33      Copyright 2003, The Internet Society.  All Rights Reserved.
  34
  35      Please see the Copyright section near the end of this document for
  36      more information.
  37
  38 Abstract
  39
  40      This document defines a simple challenge-response authentication
  41      mechanism, using a keyed-hash digest, for use with the Simple
  42      Authentication and Security Layer (SASL).
  43
  44 1.  Conventions Used in this Document
  45
  46      The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
  47      in this document are to be interpreted as defined in [KEYWORD].
  48
  49
  50 2.  CRAM-MD5 Authentication Mechanism
  51
  52      This document defines a simple challenge-response [SASL] authenti-
  53      cation mechanism, using a [KEYED-MD5] digest, for use with [SASL].
  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 Nerenberg            draft-ietf-sasl-crammd5-01.txt             [Page 1]
  61 \f
  62 Internet Draft           CRAM-MD5 SASL Mechanism           November 2003
  63
  64
  65      The data encoded in the challenge contains a presumptively arbi-
  66      trary string of random digits, a time-stamp, and the fully-quali-
  67      fied 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 client MUST prepare the user name and shared secret strings
  88      using the [SASLPrep] profile of the [StringPrep] algorithm.  The
  89      resulting values MUST be encoded as UTF-8 [UTF8].
  90
  91
  92 2.1.  Formal Syntax
  93
  94      The following syntax specification uses the augmented Backus-Naur
  95      Form (ABNF) as specified in [ABNF], and incorporates by reference
  96      the Core Rules defined in that document.
  97
  98      challenge  = "<" 1*DIGIT "." 1*DIGIT "@" hostname ">"
  99
 100      digest     = 32(DIGIT / %x61-66)
 101                   ; A hexadecimal string using only lower-case
 102                   ; letters
 103
 104      hostname   = 1*(ALPHA / DIGIT) *("." / "-" / ALPHA / DIGIT)
 105
 106      response   = user SP digest
 107
 108      user       = 1*OCTET
 109
 110
 111 2.2.  Examples
 112
 113      The examples in this section do NOT form part of the specification.
 114      Where conflicts exist between the examples and the formal grammar
 115      or specification text, the latter are authoritative.
 116
 117      These examples show the use of the CRAM-MD5 mechanism with the
 118      IMAP4 AUTHENTICATE command [IMAP4].  The base64 encoding of the
 119
 120
 121
 122 Nerenberg            draft-ietf-sasl-crammd5-01.txt             [Page 2]
 123 \f
 124 Internet Draft           CRAM-MD5 SASL Mechanism           November 2003
 125
 126
 127      challenges and responses is part of the IMAP4 AUTHENTICATE command,
 128      not part of the CRAM-MD5 specification itself.
 129
 130      S: * OK [CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED AUTH=CRAM-MD5]
 131      C: A0001 AUTHENTICATE CRAM-MD5
 132      S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+
 133      C: dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw
 134      S: A0001 OK CRAM-MD5 authentication successful
 135
 136      In this example, the shared secret is the string
 137
 138           tanstaaftanstaaf
 139
 140      Hence, the Keyed MD5 digest is produced by calculating
 141
 142           MD5((tanstaaftanstaaf XOR opad),
 143                MD5((tanstaaftanstaaf XOR ipad),
 144                <1896.697170952@postoffice.example.net>))
 145
 146      where ipad and opad are as defined in [KEYED-MD5] and the string
 147      shown in the challenge is the base64 encoding of
 148      <1896.697170952@postoffice.reston.mci.net>. The shared secret is
 149      null-padded to a length of 64 bytes. If the shared secret is longer
 150      than 64 bytes, the MD5 digest of the shared secret is used as a 16
 151      byte input to the keyed MD5 calculation.
 152
 153      This produces a digest value (in hexadecimal) of
 154
 155           b913a602c7eda7a495b4e6e7334d3890
 156
 157      The user name is then prepended to it, forming
 158
 159           tim b913a602c7eda7a495b4e6e7334d3890
 160
 161      Which is then base64 encoded to meet the requirements of the IMAP4
 162      AUTHENTICATE command (or the similar POP3 AUTH command), yielding
 163
 164           dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw
 165
 166
 167
 168 3.  References
 169
 170 3.1.  Normative References
 171
 172 [ABNF]
 173      Crocker, D., P. Overell, "Augmented BNF for Syntax Specifications:
 174      ABNF", RFC2234, Internet Mail Consortium and Demon Internet Ltd.,
 175      November 1997.
 176
 177 [KEYED-MD5]
 178      Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for Message
 179      Authentication", RFC 2104, IBM and UCSD, February 1997.
 180
 181
 182
 183
 184 Nerenberg            draft-ietf-sasl-crammd5-01.txt             [Page 3]
 185 \f
 186 Internet Draft           CRAM-MD5 SASL Mechanism           November 2003
 187
 188
 189 [KEYWORD]
 190      Bradner, S., "Key words for use in RFCs to Indicate Requirement
 191      Levels", BCP 14, RFC2119, Harvard University, March 1997.
 192
 193 [MD5]
 194      Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, MIT Labo-
 195      ratory for Computer Science and RSA Data Security, Inc., April
 196      1992.
 197
 198 [SASL]
 199      Myers, J., "Simple Authentication and Security Layer (SASL)," RFC
 200      2222, Netscape Communications, October 1997.
 201
 202 [SASLPrep]
 203      Zeilenga, K., "SASL String Preparation Profiles", draft-ietf-sasl-
 204      saslprep (work in progress)
 205
 206 [StringPrep]
 207      Hoffman, P., M. Blanchet, "Preparation of Internationalized Strings
 208      (stringprep)", RFC 3454, IMC and Viagenie, December 2002.
 209
 210 [UTF8]
 211      Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
 212      2279, Alis Technologies, January 1998.
 213
 214 3.2.  Informative References
 215
 216 [IMAP4]
 217      Crispin, M., "Internet Message Access Protocol - Version 4rev1,"
 218      RFC 3501, University of Washington, March 2003.
 219
 220
 221 4.  Security Considerations
 222
 223      It is conjectured that use of the CRAM-MD5 authentication mechanism
 224      provides replay protection for a session.
 225
 226      This mechanism does not obscure the user name in any way.  Accord-
 227      ingly, a server that implements both a clear-text password command
 228      and this authentication type should not allow both methods of
 229      access for a given user name.
 230
 231      Keyed MD5 is chosen for this application because of the greater
 232      security imparted to authentication of short messages. In addition,
 233      the use of the techniques described in [KEYED-MD5] for pre-computa-
 234      tion of intermediate results make it possible to avoid explicit
 235      clear-text storage of the shared secret on the server system by
 236      instead storing the intermediate results which are known as "con-
 237      texts."  While the saving, on the server, of the MD5 "context" is
 238      marginally better than saving the shared secrets in clear-text, it
 239      is not sufficient to protect the secrets if the server itself is
 240      compromised.  Consequently, servers that store the secrets or con-
 241      texts must both be protected to a level appropriate to the poten-
 242      tial information value in the data and services protected by this
 243
 244
 245
 246 Nerenberg            draft-ietf-sasl-crammd5-01.txt             [Page 4]
 247 \f
 248 Internet Draft           CRAM-MD5 SASL Mechanism           November 2003
 249
 250
 251      mechanism.  In other words, techniques like this one involve a
 252      trade-off between vulnerability to network sniffing and I/O buffer
 253      snooping and vulnerability of the server host's databases.  If one
 254      believes that the host and its databases are subject to compromise,
 255      and the network is not, this technique (and all others like it) is
 256      unattractive.  It is perhaps even less attractive than clear-text
 257      passwords, which are typically stored on hosts in one-way hash
 258      form.  On the other hand, if the server databases are perceived as
 259      reasonably secure, and one is concerned about client-side or net-
 260      work interception of the passwords (secrets), then this (and simi-
 261      lar) techniques are preferable to clear-text passwords by a wide
 262      margin.
 263
 264      As the length of the shared secret increases, so does the diffi-
 265      culty of deriving it.
 266
 267      While there are now suggestions in the literature that the use of
 268      MD5 and keyed MD5 in authentication procedures probably has a lim-
 269      ited effective lifetime, the technique is now widely deployed and
 270      widely understood.  It is believed that this general understanding
 271      may assist with the rapid replacement, by CRAM-MD5, of the current
 272      uses of permanent clear-text passwords in many protocols.  This
 273      document has been deliberately written to permit easy upgrading to
 274      use SHA (or whatever alternatives emerge) when they are considered
 275      to be widely available and adequately safe.
 276
 277      Even with the use of CRAM-MD5, users are still vulnerable to active
 278      attacks.  An example of an increasingly common active attack is
 279      'TCP Session Hijacking' as described in CERT Advisory CA-95:01.
 280
 281      CRAM-MD5 does not authenticate the server and does not include a
 282      client-supplied nonce.  As a result, it is possible to construct a
 283      server with a fixed challenge string that has pre-computed the
 284      hashes for all possible passwords up to a certain length (or from a
 285      dictionary).  Such a server could then immediately determine the
 286      user's password if it is sufficiently short.
 287
 288
 289 5.  IANA Considerations
 290
 291      The SASL Mechanism Registry entry for CRAM-MD5 must be updated to
 292      reference this specification.
 293
 294
 295 6.  Contributors
 296
 297      The CRAM-MD5 mechanism was originally specified in RFC 2095,
 298      IMAP/POP AUTHorize Extension for Simple Challenge/Response.  The
 299      authors of that document -- John C. Klensin, Paul Krumviede, and
 300      Randy Catoe -- are to be credited with the design and specification
 301      of CRAM-MD5. This memo serves only to re-state CRAM-MD5 within the
 302      formal context of SASL, which specification it preceded by several
 303      months.
 304
 305
 306
 307
 308 Nerenberg            draft-ietf-sasl-crammd5-01.txt             [Page 5]
 309 \f
 310 Internet Draft           CRAM-MD5 SASL Mechanism           November 2003
 311
 312
 313 7.  Intellectual Property
 314
 315      The IETF takes no position regarding the validity or scope of any
 316      intellectual property or other rights that might be claimed to per-
 317      tain to the implementation or use of the technology described in
 318      this document or the extent to which any license under such rights
 319      might or might not be available; neither does it represent that it
 320      has made any effort to identify any such rights.  Information on
 321      the IETF's procedures with respect to rights in standards-track and
 322      standards-related documentation can be found in BCP-11.  Copies of
 323      claims of rights made available for publication and any assurances
 324      of licenses to be made available, or the result of an attempt made
 325      to obtain a general license or permission for the use of such pro-
 326      prietary rights by implementers or users of this specification can
 327      be obtained from the IETF Secretariat.
 328
 329      The IETF invites any interested party to bring to its attention any
 330      copyrights, patents or patent applications, or other proprietary
 331      rights which may cover technology that may be required to practice
 332      this standard.  Please address the information to the IETF Execu-
 333      tive Director.
 334
 335
 336 8.  Editors' Address
 337
 338      Lyndon Nerenberg
 339      Orthanc Systems
 340      1606 - 10770 Winterburn Road
 341      Edmonton, Alberta
 342      Canada T5S 1T6
 343      Email: lyndon+rfc-crammd5@orthanc.ca
 344
 345
 346
 347
 348
 349
 350
 351
 352
 353
 354
 355
 356
 357
 358
 359
 360
 361
 362
 363
 364
 365
 366
 367
 368
 369
 370 Nerenberg            draft-ietf-sasl-crammd5-01.txt             [Page 6]
 371 \f
 372 Internet Draft           CRAM-MD5 SASL Mechanism           November 2003
 373
 374
 375 9.  Full Copyright Statement
 376
 377      Copyright 2003, The Internet Society. All Rights Reserved.
 378
 379      This document and translations of it may be copied and furnished to
 380      others, and derivative works that comment on or otherwise explain
 381      it or assist in its implementation may be prepared, copied, pub-
 382      lished and distributed, in whole or in part, without restriction of
 383      any kind, provided that the above copyright notice and this para-
 384      graph are included on all such copies and derivative works.  How-
 385      ever, this document itself may not be modified in any way, such as
 386      by removing the copyright notice or references to the Internet
 387      Society or other Internet organizations, except as needed for the
 388      purpose of developing Internet standards in which case the proce-
 389      dures for copyrights defined in the Internet Standards process must
 390      be followed, or as required to translate it into languages other
 391      than English.  The limited permissions granted above are perpetual
 392      and will not be revoked by the Internet Society or its successors
 393      or assigns.
 394
 395      This document and the information contained herein is provided on
 396      an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGI-
 397      NEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
 398      INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 399      INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WAR-
 400      RANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 401
 402
 403
 404
 405
 406
 407
 408
 409
 410
 411
 412
 413
 414
 415
 416
 417
 418
 419
 420
 421
 422
 423
 424
 425
 426
 427
 428
 429
 430
 431
 432 Nerenberg            draft-ietf-sasl-crammd5-01.txt             [Page 7]
 433 \f
 434