doc/specification/draft-ietf-sasl-crammd5-08.txt

   1
   2
   3
   4 SASL Working Group                                     L. Nerenberg, Ed.
   5 Internet-Draft                                           Orthanc Systems
   6 Obsoletes: RFC2195                                         March 5, 2007
   7 (if approved)
   8 Intended status: Standards Track
   9 Expires: September 6, 2007
  10
  11
  12                       The CRAM-MD5 SASL Mechanism
  13                        draft-ietf-sasl-crammd5-08
  14
  15 Status of this Memo
  16
  17    By submitting this Internet-Draft, each author represents that any
  18    applicable patent or other IPR claims of which he or she is aware
  19    have been or will be disclosed, and any of which he or she becomes
  20    aware will be disclosed, in accordance with Section 6 of BCP 79.
  21
  22    Internet-Drafts are working documents of the Internet Engineering
  23    Task Force (IETF), its areas, and its working groups.  Note that
  24    other groups may also distribute working documents as Internet-
  25    Drafts.
  26
  27    Internet-Drafts are draft documents valid for a maximum of six months
  28    and may be updated, replaced, or obsoleted by other documents at any
  29    time.  It is inappropriate to use Internet-Drafts as reference
  30    material or to cite them other than as "work in progress."
  31
  32    The list of current Internet-Drafts can be accessed at
  33    http://www.ietf.org/ietf/1id-abstracts.txt.
  34
  35    The list of Internet-Draft Shadow Directories can be accessed at
  36    http://www.ietf.org/shadow.html.
  37
  38    This Internet-Draft will expire on September 6, 2007.
  39
  40 Copyright Notice
  41
  42    Copyright (C) The IETF Trust (2007).
  43
  44 Abstract
  45
  46    This document defines a simple challenge-response authentication
  47    mechanism, using a keyed MD5 digest, for use with the Simple
  48    Authentication and Security Layer (SASL).
  49
  50
  51
  52
  53
  54
  55 Nerenberg               Expires September 6, 2007               [Page 1]
  56 \f
  57 Internet-Draft         The CRAM-MD5 SASL Mechanism            March 2007
  58
  59
  60 Table of Contents
  61
  62    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
  63    2.  The CRAM-MD5 SASL Mechanism  . . . . . . . . . . . . . . . . .  3
  64    3.  Formal Grammar . . . . . . . . . . . . . . . . . . . . . . . .  3
  65    4.  Interoperability Considerations  . . . . . . . . . . . . . . .  4
  66    5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  5
  67    6.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  6
  68      6.1.  Normative References . . . . . . . . . . . . . . . . . . .  6
  69      6.2.  Informative References . . . . . . . . . . . . . . . . . .  6
  70    Appendix A.  Examples  . . . . . . . . . . . . . . . . . . . . . .  7
  71      A.1.  IMAP4  . . . . . . . . . . . . . . . . . . . . . . . . . .  7
  72        A.1.1.  Example 1: Simple IMAP . . . . . . . . . . . . . . . .  7
  73        A.1.2.  Example 2: IMAP4 with embedded spaces  . . . . . . . .  8
  74        A.1.3.  Example 3: IMAP4 with Unicode characters . . . . . . .  8
  75      A.2.  ACAP . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
  76        A.2.1.  Example 4: Simple ACAP . . . . . . . . . . . . . . . .  8
  77    Appendix B.  IANA Considerations . . . . . . . . . . . . . . . . .  9
  78    Appendix C.  Contributors  . . . . . . . . . . . . . . . . . . . .  9
  79    Appendix D.  Changes since RFC 2195  . . . . . . . . . . . . . . .  9
  80    Author's Address . . . . . . . . . . . . . . . . . . . . . . . . .  9
  81    Intellectual Property and Copyright Statements . . . . . . . . . . 10
  82
  83
  84
  85
  86
  87
  88
  89
  90
  91
  92
  93
  94
  95
  96
  97
  98
  99
 100
 101
 102
 103
 104
 105
 106
 107
 108
 109
 110
 111 Nerenberg               Expires September 6, 2007               [Page 2]
 112 \f
 113 Internet-Draft         The CRAM-MD5 SASL Mechanism            March 2007
 114
 115
 116 1.  Introduction
 117
 118    This document defines a simple challenge-response authentication
 119    method, using a keyed MD5 [RFC2104] digest, for use with the Simple
 120    Security and Authentication Layer (SASL) [RFC4422].  The mechanism
 121    name associated with CRAM-MD5 is 'CRAM-MD5'.
 122
 123    This mechanism does not provide a security layer.
 124
 125    The CRAM-MD5 mechanism is intended to have limited use on the
 126    Internet.  The mechanism offers inadequate protection against common
 127    attacks against application-level protocols (see Section 5) and is
 128    prone to interoperability problems (see Section 4).
 129
 130
 131 2.  The CRAM-MD5 SASL Mechanism
 132
 133    The mechanism starts with the server issuing a <challenge>.  The data
 134    contained in the challenge contains a string of random data.
 135
 136    The client makes note of the data and then responds with a <response>
 137    consisting of the <username>, a space, and a <digest>.  The digest is
 138    computed by applying the keyed MD5 algorithm from [RFC2104] where the
 139    key is a shared secret and the digested text is the <challenge>
 140    (including angle-brackets).  The client MUST NOT interpret or attempt
 141    to validate the contents of the challenge in any way.
 142
 143    This shared secret is a string known only to the client and server.
 144    The digest parameter itself is a 16-octet value which is sent in a
 145    restricted hexadecimal format (see the <digest> production in
 146    Section 3).
 147
 148    When the server receives this client response, it verifies the digest
 149    provided.  Since the user name may contain the space character, the
 150    server MUST ensure the right-most space character is recognised as
 151    the token separating the user name from the digest.  If the digest is
 152    correct, the server should consider the client authenticated.
 153
 154
 155 3.  Formal Grammar
 156
 157    The following grammar specification uses the Augmented Backus-Naur
 158    Form (ABNF) as specified in [RFC4234], and incorporates by reference
 159    the Core Rules defined in that document.
 160
 161
 162
 163
 164
 165
 166
 167 Nerenberg               Expires September 6, 2007               [Page 3]
 168 \f
 169 Internet-Draft         The CRAM-MD5 SASL Mechanism            March 2007
 170
 171
 172      challenge  = "<" 3*(%x21-3B / %x3D / %x3F-7E) ">"
 173                   ; a bracketed string of printing ASCII characters, not
 174                   ; containing embedded "<" or ">"
 175
 176      digest     = 32(DIGIT / %x61-66)
 177                   ; A hexadecimal string, using ONLY lower-case
 178                   ; letters
 179
 180      response   = username SP digest
 181
 182      username   = 1*OCTET
 183                   ; MUST be well-formed UTF-8.
 184
 185
 186 4.  Interoperability Considerations
 187
 188    The design of CRAM-MD5 [RFC2095] pre-dated any widespread use of
 189    UTF-8 to encode protocol elements.  It was initially deployed as an
 190    extension to the IMAP4 protocol at a time when authentication and
 191    authorization identifiers were almost exclusively encoded in the US-
 192    ASCII character set, therefore it is silent about the encoding and
 193    representation of non-US-ASCII data elements.  When sites first began
 194    using alternate character sets to encode user names (and passwords)
 195    they simply used the raw 8-bit character representation.  This works
 196    - for the most part - but only because these enclaves tend to use a
 197    common character set amongst themselves.  When a second group of
 198    users using a different character set is introduced into the mix,
 199    interoperability suffers.
 200
 201    So as not to render existing implementations non-compliant, this
 202    update preserves the existing opaque nature of user names and
 203    passwords.  However, implementors are strongly encouraged to process
 204    the user name and password data as described in the next paragraph.
 205    Doing so prevents interoperability problems caused by incompatible
 206    character set encodings.
 207
 208    The client SHOULD prepare the user name and shared secret strings
 209    using the SASLprep [RFC4013] profile of the Stringprep [RFC3454]
 210    algorithm.  The resulting values SHOULD be encoded as UTF-8 [RFC3629]
 211    strings.  The server may store the prepared string instead of, or as
 212    well as, the unprepared string, so that it does not have to prepare
 213    it every time it is needed for computation.  However, if the original
 214    (unprepared) string is not stored, it may render the computed secret
 215    to be incompatible with a future revisions of SASLprep that support
 216    currently unassigned code points (see section 7 of [RFC3454]).  It is
 217    therefor recommended to store the unprepared string in the database.
 218
 219
 220
 221
 222
 223 Nerenberg               Expires September 6, 2007               [Page 4]
 224 \f
 225 Internet-Draft         The CRAM-MD5 SASL Mechanism            March 2007
 226
 227
 228 5.  Security Considerations
 229
 230    CRAM-MD5 is no longer considered to provide adequate protection.
 231
 232    This mechanism is vulnerable to dictionary attack by any passive
 233    listener able to observe the user name, challenge and response.  An
 234    attacker can use the user name and challenge to compute a series of
 235    responses based on a pass-phrase dictionary, looking for a match to
 236    the response sent by the client.
 237
 238    CRAM-MD5 does not authenticate the server and does not include a
 239    client-supplied nonce.  As a result, it is possible to construct a
 240    server with a fixed challenge string that has pre-computed the hashes
 241    for all possible passwords up to a certain length (or from a
 242    dictionary).  Such a server could then immediately determine the
 243    user's password if it is sufficiently short or non-random.
 244
 245    This mechanism does not obscure the user name in any way.
 246    Accordingly, a server that implements both a clear-text password
 247    command and this authentication type should not allow both methods of
 248    access for a given user name.
 249
 250    For the reasons described above, CRAM-MD5 SHOULD NOT be used unless
 251    the application protocol session is protected by an encryption layer,
 252    such as provided by TLS.
 253
 254    Keyed MD5 is chosen for this application because of the greater
 255    security imparted to authentication of short messages.  In addition,
 256    the use of the techniques described in [RFC2104] for pre-computation
 257    of intermediate results make it possible to avoid explicit clear-text
 258    storage of the shared secret on the server system by instead storing
 259    the intermediate results which are known as "contexts."  While the
 260    saving, on the server, of the MD5 context is marginally better than
 261    saving the shared secrets in clear-text, it is not sufficient to
 262    protect the secrets if the server itself is compromised.
 263    Consequently, servers that store the secrets or contexts must both be
 264    protected to a level appropriate to the potential information value
 265    in the data and services protected by this mechanism.  In other
 266    words, techniques like this one involve a trade-off between
 267    vulnerability to network sniffing and I/O buffer snooping and
 268    vulnerability of the server host's databases.  If one believes that
 269    the host and its databases are subject to compromise, and the network
 270    is not, this technique (and all others like it) is unattractive.  It
 271    is perhaps even less attractive than clear-text passwords, which are
 272    typically stored on hosts in one-way hash form.  On the other hand,
 273    if the server databases are perceived as reasonably secure, and one
 274    is concerned about client-side or network interception of the
 275    passwords (secrets), then this (and similar) techniques are
 276
 277
 278
 279 Nerenberg               Expires September 6, 2007               [Page 5]
 280 \f
 281 Internet-Draft         The CRAM-MD5 SASL Mechanism            March 2007
 282
 283
 284    preferable to clear-text passwords by a wide margin.
 285
 286    While there are now suggestions in the literature that the use of MD5
 287    and keyed MD5 in authentication procedures probably has a limited
 288    effective lifetime, the technique is now widely deployed and widely
 289    understood.  It is believed that this general understanding may
 290    assist with the rapid replacement, by CRAM-MD5, of the current uses
 291    of permanent clear-text passwords in many protocols.  This document
 292    has been deliberately written to permit easy upgrading to use SHA (or
 293    whatever alternatives emerge) when they are considered to be widely
 294    available and adequately safe.
 295
 296    Even with the use of CRAM-MD5, users are still vulnerable to active
 297    attacks.  An example of an increasingly common active attack is 'TCP
 298    Session Hijacking' as described in CERT Advisory CA-95:01.
 299
 300
 301 6.  References
 302
 303 6.1.  Normative References
 304
 305    [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
 306               Hashing for Message Authentication", RFC 2104,
 307               February 1997.
 308
 309    [RFC3454]  Hoffman, P. and M. Blanchet, "Preparation of
 310               Internationalized Strings ("stringprep")", RFC 3454,
 311               December 2002.
 312
 313    [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
 314               10646", STD 63, RFC 3629, November 2003.
 315
 316    [RFC4013]  Zeilenga, K., "SASLprep: Stringprep Profile for User Names
 317               and Passwords", RFC 4013, February 2005.
 318
 319    [RFC4234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
 320               Specifications: ABNF", RFC 4234, October 2005.
 321
 322    [RFC4422]  Melnikov, A. and K. Zeilenga, "Simple Authentication and
 323               Security Layer (SASL)", RFC 4422, June 2006.
 324
 325 6.2.  Informative References
 326
 327    [RFC2095]  Klensin, J., Catoe, R., and P. Krumviede, "IMAP/POP
 328               AUTHorize Extension for Simple Challenge/Response",
 329               RFC 2095, January 1997.
 330
 331    [RFC2244]  Newman, C. and J. Myers, "ACAP -- Application
 332
 333
 334
 335 Nerenberg               Expires September 6, 2007               [Page 6]
 336 \f
 337 Internet-Draft         The CRAM-MD5 SASL Mechanism            March 2007
 338
 339
 340               Configuration Access Protocol", RFC 2244, November 1997.
 341
 342    [RFC3501]  Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
 343               4rev1", RFC 3501, March 2003.
 344
 345    [RFC4616]  Zeilenga, K., "The PLAIN Simple Authentication and
 346               Security Layer (SASL) Mechanism", RFC 4616, August 2006.
 347
 348
 349 Appendix A.  Examples
 350
 351    The examples in this appendix DO NOT form part of the specification.
 352    Where conflicts exist between the examples and the formal grammar or
 353    the normative text in Section 2, the latter are authoritative.
 354
 355 A.1.  IMAP4
 356
 357    These examples show the use of the CRAM-MD5 mechanism with the IMAP4
 358    [RFC3501] AUTHENTICATE command.  The base64 encoding of the
 359    challenges and responses is part of the IMAP4 AUTHENTICATE command,
 360    and not part of the CRAM-MD5 specification itself.
 361
 362 A.1.1.  Example 1: Simple IMAP
 363
 364    In this example the shared secret is the string 'tanstaaftanstaaf'.
 365
 366      S: * OK [CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED AUTH=CRAM-MD5]
 367      C: A0001 AUTHENTICATE CRAM-MD5
 368      S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UuZXhhbXBsZS5uZXQ+
 369      C: am9lIDNkYmM4OGYwNjI0Nzc2YTczN2IzOTA5M2Y2ZWI2NDI3
 370      S: A0001 OK CRAM-MD5 authentication successful
 371
 372    Hence, the keyed MD5 digest is produced by calculating
 373
 374      MD5((SASLprep(tanstaaftanstaaf) XOR opad),
 375          MD5((SASLprep(tanstaaftanstaaf) XOR ipad),
 376             <1896.697170952@postoffice.example.net>))
 377
 378
 379    where ipad and opad are as defined in RFC 2104 and the string shown
 380    in the challenge is the base64 encoding of
 381    '<1896.697170952@postoffice.example.net>'.  The shared secret is
 382    null-padded to a length of 64 bytes.  If the shared secret is longer
 383    than 64 bytes, the MD5 digest of the shared secret is used as a 16
 384    byte input to the keyed MD5 calculation.
 385
 386    This produces a digest value (in hexadecimal) of
 387    '3dbc88f0624776a737b39093f6eb6427'.  The user name is then prepended
 388
 389
 390
 391 Nerenberg               Expires September 6, 2007               [Page 7]
 392 \f
 393 Internet-Draft         The CRAM-MD5 SASL Mechanism            March 2007
 394
 395
 396    to it, forming 'joe 3dbc88f0624776a737b39093f6eb6427', which is then
 397    base64 encoded to meet the requirements of the IMAP4 AUTHENTICATE
 398    command yielding 'am9lIDNkYmM4OGYwNjI0Nzc2YTczN2IzOTA5M2Y2ZWI2NDI3'.
 399
 400 A.1.2.  Example 2: IMAP4 with embedded spaces
 401
 402    This example uses the user name 'Ali Baba' and the shared secret
 403    'Open, Sesame'.  It illustrates that both user names and passwords
 404    may contain non-alphanumeric characters.
 405
 406      S: <68451038525716401353.0@localhost>
 407      C: Ali Baba 6fa32b6e768f073132588e3418e00f71
 408
 409 A.1.3.  Example 3: IMAP4 with Unicode characters
 410
 411    This example demonstrates the processing of Unicode strings.  The raw
 412    user name is 'Al<U+00AA>dd<U+00AD>in<U+00AE>' where <U+00AA> is the
 413    Unicode Latin symbol <FEMININE ORDINAL INDICATOR>, <U+00AD> is <SOFT
 414    HYPHEN>, and <U+00AE> is the <REGISTERED SIGN>.  Preparing the raw
 415    user name with SASLprep returns 'Aladdin<U+00AE>' which we then
 416    encode into the UTF-8 string 'Aladdin\xC2\xAE' (shown here and below
 417    using C-style string format notation).  As before, the shared secret
 418    is 'Open, Sesame'.
 419
 420      S: <92230559549732219941.0@localhost>
 421      C: Aladdin\xC2\xAE 9950ea407844a71e2f0cd3284cbd912d
 422
 423 A.2.  ACAP
 424
 425    An example of using CRAM-MD5 with ACAP [RFC2244].
 426
 427 A.2.1.  Example 4: Simple ACAP
 428
 429    This example uses the user name 'joe' and the shared secret
 430    'tanstaaftanstaaf'.
 431
 432     S: * ACAP (IMPLEMENTATION "Infotrope ACAP Server, version 0.1.3,
 433         Copyright 2002-2004 Dave Cridland <dave@cridland.net>")
 434         (SASL "PLAIN" "DIGEST-MD5" "CRAM-MD5" "ANONYMOUS") (STARTTLS)
 435     C: AUTH AUTHENTICATE "CRAM-MD5"
 436     S: + {43}
 437     S: <2262304172.6455022@gw2.gestalt.entity.net>
 438     C: {36+}
 439     C: joe 2aa383bf320a941d8209a7001ef6aeb6
 440     S: AUTH OK "You're logged in as joe. Frooby."
 441
 442
 443
 444
 445
 446
 447 Nerenberg               Expires September 6, 2007               [Page 8]
 448 \f
 449 Internet-Draft         The CRAM-MD5 SASL Mechanism            March 2007
 450
 451
 452 Appendix B.  IANA Considerations
 453
 454    It is requested that the Internet Assigned Numbers Authority (IANA)
 455    update the SASL Mechanism Registry entry for CRAM-MD5 to refer to
 456    this document.
 457
 458    To: iana@iana.org
 459    Subject: Updated Registration of SASL CRAM-MD5 mechanism.
 460
 461    SASL mechanism name: CRAM-MD5
 462    Security considerations: See RFC XXXX
 463    Published specification: RFC XXXX
 464    Person & email address to contact for further information:
 465        Lyndon Nerenberg <lyndon+rfc-crammd5@orthanc.ca>
 466        IETF SASL WG     <ietf-sasl@imc.org>
 467
 468
 469 Appendix C.  Contributors
 470
 471    The CRAM-MD5 mechanism was originally specified in RFC 2095, IMAP/POP
 472    AUTHorize Extension for Simple Challenge/Response.  The authors of
 473    that document -- John C. Klensin, Paul Krumviede, and Randy Catoe --
 474    are to be credited with the design and specification of CRAM-MD5, and
 475    they are the original authors of the majority of the text in this
 476    document.  This memo serves only to re-state CRAM-MD5 within the
 477    formal context of SASL, which specification it preceded by several
 478    months.
 479
 480    Dave Cridland and Simon Josefsson contributed updated examples.
 481
 482
 483 Appendix D.  Changes since RFC 2195
 484
 485    The syntax of the <challenge> has been relaxed.
 486
 487    A section on interoperability concerns has been added.
 488
 489    The security considerations have been updated to reflect the current
 490    views of the security community.
 491
 492
 493 Author's Address
 494
 495    Lyndon Nerenberg (editor)
 496    Orthanc Systems
 497
 498    Email: lyndon+rfc-crammd5@orthanc.ca
 499
 500
 501
 502
 503 Nerenberg               Expires September 6, 2007               [Page 9]
 504 \f
 505 Internet-Draft         The CRAM-MD5 SASL Mechanism            March 2007
 506
 507
 508 Full Copyright Statement
 509
 510    Copyright (C) The IETF Trust (2007).
 511
 512    This document is subject to the rights, licenses and restrictions
 513    contained in BCP 78, and except as set forth therein, the authors
 514    retain all their rights.
 515
 516    This document and the information contained herein are provided on an
 517    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 518    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
 519    THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
 520    OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 521    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 522    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 523
 524
 525 Intellectual Property
 526
 527    The IETF takes no position regarding the validity or scope of any
 528    Intellectual Property Rights or other rights that might be claimed to
 529    pertain to the implementation or use of the technology described in
 530    this document or the extent to which any license under such rights
 531    might or might not be available; nor does it represent that it has
 532    made any independent effort to identify any such rights.  Information
 533    on the procedures with respect to rights in RFC documents can be
 534    found in BCP 78 and BCP 79.
 535
 536    Copies of IPR disclosures made to the IETF Secretariat and any
 537    assurances of licenses to be made available, or the result of an
 538    attempt made to obtain a general license or permission for the use of
 539    such proprietary rights by implementers or users of this
 540    specification can be obtained from the IETF on-line IPR repository at
 541    http://www.ietf.org/ipr.
 542
 543    The IETF invites any interested party to bring to its attention any
 544    copyrights, patents or patent applications, or other proprietary
 545    rights that may cover technology that may be required to implement
 546    this standard.  Please address the information to the IETF at
 547    ietf-ipr@ietf.org.
 548
 549
 550 Acknowledgment
 551
 552    Funding for the RFC Editor function is provided by the IETF
 553    Administrative Support Activity (IASA).
 554
 555
 556
 557
 558
 559 Nerenberg               Expires September 6, 2007              [Page 10]
 560 \f