home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_n_r / draft-newman-sasl-plaintrans-03.txt < prev    next >
Text File  |  1997-07-29  |  15KB  |  396 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          C. Newman
  8. Internet Draft: Plaintext Password SASL Mechanism               Innosoft
  9. Document: draft-newman-sasl-plaintrans-03.txt                  July 1997
  10.                                                    Expires in six months
  11.  
  12.  
  13.        Plaintext Password SASL Mechanism and Transition Strategy
  14.  
  15.  
  16. Status of this memo
  17.  
  18.      This document is an Internet-Draft.  Internet-Drafts are working
  19.      documents of the Internet Engineering Task Force (IETF), its areas,
  20.      and its working groups.  Note that other groups may also distribute
  21.      working documents as Internet-Drafts.
  22.  
  23.      Internet-Drafts are draft documents valid for a maximum of six
  24.      months and may be updated, replaced, or obsoleted by other
  25.      documents at any time.  It is inappropriate to use Internet-Drafts
  26.      as reference material or to cite them other than as "work in
  27.      progress."
  28.  
  29.      To view the entire list of current Internet-Drafts, please check
  30.      the "1id-abstracts.txt" listing contained in the Internet-Drafts
  31.      Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
  32.      (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
  33.      Coast), or ftp.isi.edu (US West Coast).
  34.  
  35.  
  36. Abstract
  37.  
  38.      While plaintext passwords have very poor security characteristics
  39.      by themselves, there are a number of contexts where they are useful
  40.      or necessary.  This defines a plaintext password mechanism for SASL
  41.      [SASL] which is intended to be used in combination with an external
  42.      encryption layer, as a transition mechanism from a legacy
  43.      authentication database, or to use (insecurely) a legacy
  44.      authentication database which can not practically be replaced.
  45.  
  46.      In hopes of promoting the future elimination of unencrypted
  47.      plaintext passwords, this defines error codes for use with POP3 and
  48.      IMAP4: one to indiciate the need for a transition to a stronger
  49.      mechanism, a second to indicate that a SASL mechanism is too weak
  50.      for per-user security policy for a given service, and a third to
  51.      indicate that a SASL mechanism is only accepted in combination with
  52.      an external strong encryption mechanism.  Any protocol offering the
  53.      PLAIN mechanism SHOULD also support equivalent error codes.
  54.  
  55.  
  56.  
  57.  
  58. Newman                                                          [Page 1]
  59.  
  60. Internet Draft     Plaintext Password SASL Mechanism           July 1997
  61.  
  62.  
  63. 1. Conventions Used in this Document
  64.  
  65.      The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
  66.      in this document are to be interpreted as defined in "Key words for
  67.      use in RFCs to Indicate Requirement Levels" [KEYWORDS].
  68.  
  69.  
  70. 2. Security Impact of Plaintext Passwords
  71.  
  72.      Use of unencrypted plaintext passwords over the Internet is a
  73.      severe security risk.  In particular, a passive observer can get
  74.      the password with any packet sniffer.  This requires no technical
  75.      expertise, as one can simply plug a consumer level computer into
  76.      the network and run widely available network snoop programs.  Such
  77.      attacks are difficult or impossible to detect, and can only be
  78.      prevented by complete physical and virtual security of the network
  79.      between the client and server -- something which is usually
  80.      impossible to achieve.
  81.  
  82.      Unfortunately, most modern servers use legacy authentication
  83.      databases, usually tightly integrated with the operating system,
  84.      which apply a one-way function to the user's password preventing
  85.      the use of any mechanism other than plaintext passwords.  This
  86.      means that plaintext passwords are the only authentication
  87.      technology today which will work with the vast majority of deployed
  88.      authentication databases.  Often the cost of deploying a new
  89.      authentication technology or having different authentication
  90.      credentials for different services outweighs the security risks of
  91.      plaintext passwords.
  92.  
  93.      Thus there are three situations where plaintext passwords are
  94.      necessary or useful:
  95.  
  96.      (1) As a method to transition, on a per-user basis, from a legacy
  97.      authentication database a secure password mechanism such as
  98.      CRAM-MD5 [CRAM-MD5].
  99.  
  100.      (2) As the only feasible mechanism when a legacy authentication
  101.      database is in use, multiple remote services are offered, there is
  102.      no way to transition all the remote services, and it is
  103.      unacceptable to have different passwords for different services.
  104.  
  105.      (3) In conjunction with a strong encryption layer.
  106.  
  107.      In all other cases, plaintext passwords SHOULD NOT be used.  In
  108.      addition, any client or server supporting this mechanism SHOULD
  109.      also support a strong encryption layer or a stronger authentication
  110.      mechanism.
  111.  
  112.  
  113.  
  114. Newman                                                          [Page 2]
  115.  
  116. Internet Draft     Plaintext Password SASL Mechanism           July 1997
  117.  
  118.  
  119. 3. Plaintext Password SASL mechanism
  120.  
  121.      The mechanism name associated with plaintext passwords is "PLAIN".
  122.  
  123.      The mechanism consists of a single message from the client to the
  124.      server.  The client sends the authorization identity, followed by a
  125.      US-ASCII NUL character, followed by the authentication identity,
  126.      followed by a US-ASCII NUL character, followed by the plaintext
  127.      password.  The client may leave the authorization identity empty to
  128.      indicate that it is the same as the authentication identity.
  129.  
  130.      The server will verify the authentication identity and password
  131.      with the system authentication database and verify that the
  132.      authentication credentials permit the client to login as the
  133.      authorization identity.  If both these steps succeed, the user is
  134.      logged in.
  135.  
  136.      When used as a transition mechanism, the password will be stored in
  137.      a new authentication database capable of supporting stronger
  138.      authentication mechanisms.  Once this is completed, the server MAY
  139.      refuse future use of the PLAIN mechanism by that authentication
  140.      identity.
  141.  
  142.      Non-US-ASCII characters are permitted as long as they can be
  143.      represented in UTF-8 [UTF8].  Use of non-visible characters or
  144.      characters which a user may be unable to enter on some keyboards is
  145.      discouraged.
  146.  
  147.      The formal grammar for the client message using Augmented BNF
  148.      [ABNF] follows.
  149.  
  150.      message         = [authorize-id] NUL authenticate-id NUL password
  151.  
  152.      NUL             = %x00
  153.  
  154.      US-ASCII-SAFE   = %x01..09 / %x0B..0C / %x0E..7F
  155.                       ;; US-ASCII except CR, LF, NUL
  156.  
  157.      UTF8-SAFE       = US-ASCII-SAFE / UTF8-1 / UTF8-2 / UTF8-3
  158.                           / UTF8-4 / UTF8-5
  159.  
  160.      UTF8-CONT       = %x80..BF
  161.  
  162.      UTF8-1          = %xC0..DF UTF8-CONT
  163.  
  164.      UTF8-2          = %xE0..EF 2UTF8-CONT
  165.  
  166.      UTF8-3          = %xF0..F7 3UTF8-CONT
  167.  
  168.  
  169.  
  170. Newman                                                          [Page 3]
  171.  
  172. Internet Draft     Plaintext Password SASL Mechanism           July 1997
  173.  
  174.  
  175.      UTF8-4          = %xF8..FB 4UTF8-CONT
  176.  
  177.      UTF8-5          = %xFC..FD 5UTF8-CONT
  178.  
  179.      authenticate-id = 1*255UTF8-SAFE
  180.  
  181.      authorize-id    = 1*255UTF8-SAFE
  182.  
  183.      password        = 1*255UTF8-SAFE
  184.  
  185.  
  186. 4. New Error/Response Codes
  187.  
  188.      When used as a transition mechanism, two new response codes are
  189.      helpful to provide guidance to clients.  A third response code is
  190.      useful to indicate the need for an external encryption mechanism.
  191.  
  192.      The failure codes for use with IMAP4 [IMAP4] are defined here:
  193.  
  194.      TRANSITION-NEEDED
  195.           This IMAP response code occurs on the tagged NO response to an
  196.           AUTHENTICATE command after an attempt to use a mechanism other
  197.           than PLAIN.  It indicates that that mechanism is not currently
  198.           usable, but will be usable once "AUTHENTICATE PLAIN" or LOGIN
  199.           is used.
  200.  
  201.  
  202.      AUTH-TOO-WEAK
  203.           This IMAP response code occurs on the tagged NO response to a
  204.           LOGIN or AUTHENTICATE command.  It indicates that the
  205.           requested mechanism is not available to the specified user
  206.           based on site security policy.  This may also be used on the
  207.           untagged OK response to a LOGIN or "AUTHENTICATE PLAIN"
  208.           command to indicate that plaintext passwords will not be
  209.           accepted from that user at a later date.
  210.  
  211.  
  212.      ENCRYPT-NEEDED
  213.           This IMAP response code occurs on the tagged NO response to a
  214.           LOGIN or AUTHENTICATE command.  It indicates that the
  215.           specified mechanism may only be used in combination with an
  216.           external strong encryption service.  This is intended
  217.           primarily for use with plaintext passwords.
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Newman                                                          [Page 4]
  227.  
  228. Internet Draft     Plaintext Password SASL Mechanism           July 1997
  229.  
  230.  
  231.      The failure codes for use with POP3 [POP3] are defined here:
  232.  
  233.      -ERR [TRANSITION-NEEDED] A password transition is needed.
  234.           The portion between the "[" and "]" is a machine parsable
  235.           message, interpreted in a case insensitive fashion.  The
  236.           remainer of the line may contain any implementation-specific
  237.           human readable text.
  238.  
  239.           This occurs in response to an APOP or AUTH [POP-AUTH] command
  240.           that is not currently available, but will be available after
  241.           the use of the PLAIN mechanism or the USER/PASS commands.
  242.  
  243.  
  244.      -ERR [AUTH-TOO-WEAK] Plaintext passwords forbidden
  245.           This occurs in response to a USER, PASS, APOP or AUTH command
  246.           and indicates that the server no longer permits the requested
  247.           authentication mechanism due to site security policy.  It may
  248.           also occur on a "+OK" line after a successful PASS or AUTH
  249.           PLAIN command to indicate that plaintext passwords will not be
  250.           accepted from that user at a later date.
  251.  
  252.  
  253.      -ERR [ENCRYPT-NEEDED] Plaintext passwords need encryption
  254.           This occurs in response to a USER, PASS, APOP or AUTH command
  255.           and indicates that the server does not permit use of the
  256.           specified mechanism except with an external encryption
  257.           mechanism for the specified user.  This is intended primarily
  258.           for use with plaintext passwords.
  259.  
  260.  
  261. 5. Example
  262.  
  263.      Here is a sample transition exchange between an IMAP client and
  264.      server.  In this example, "C:" and "S:" indicate lines sent by the
  265.      client and server respectively.  If such lines are wrapped without
  266.      a new "C:" or "S:" label, then the wrapping is for editorial
  267.      clarity and is not part of the command.
  268.  
  269.      Note that this example uses the IMAP profile [IMAP4] of SASL.  The
  270.      base64 encoding of challenges and responses, as well as the "+ "
  271.      preceding the responses are part of the IMAP4 profile, not part of
  272.      SASL itself.  Newer profiles of SASL will include the client
  273.      message with the AUTHENTICATE command itself so the extra round
  274.      trip below (the server response with an empty "+ ") can be
  275.      eliminated.
  276.  
  277.      In this example, the user's authentication identifier is "tim", his
  278.      authorization identifier is the same, and his password is
  279.  
  280.  
  281.  
  282. Newman                                                          [Page 5]
  283.  
  284. Internet Draft     Plaintext Password SASL Mechanism           July 1997
  285.  
  286.  
  287.      "tanstaaftanstaaf".
  288.  
  289.         S: * OK IMAP4 server ready
  290.         C: A001 CAPABILITY
  291.         S: * CAPABILITY IMAP4 IMAP4rev1 AUTH=CRAM-MD5 AUTH=PLAIN
  292.         S: A001 OK done
  293.         C: A002 AUTHENTICATE CRAM-MD5
  294.         S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+
  295.         C: dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw
  296.         S: A002 NO [TRANSITION-NEEDED] You can't login securely until
  297.                 you've changed your password on the server
  298.         C: A003 AUTHENTICATE PLAIN
  299.         S: +
  300.         C: AHRpbQB0YW5zdGFhZnRhbnN0YWFm
  301.         S: A003 OK You can now login securely in the future.
  302.         C: A004 SELECT INBOX
  303.            ...
  304.  
  305. 6. Security Considerations
  306.  
  307.      Security considerations are discussed throughout this document.
  308.  
  309.      A man in the middle or a spoof server may be able to aquire the
  310.      user's password by pretending no strong authentication mechanisms
  311.      are available.  The are two steps the client can take to help
  312.      defeat such attacks.  First, clients MAY record the occurance of an
  313.      AUTH-TOO-WEAK or ENCRYPT-NEEDED error for a given user, server and
  314.      protocol combination and refuse to use unencrypted plaintext
  315.      passwords for that combination in the future.  Second, clients
  316.      SHOULD get permission from the user prior to using an unencrypted
  317.      plaintext password, especially in response to a TRANSITION-NEEDED
  318.      response code.  If the user normally makes a secure connection and
  319.      suddenly sees a warning, this might prevent a password compromise.
  320.  
  321.      Unencrypted plaintext passwords are visible to any network snooper,
  322.      as discussed in section 2.  Servers SHOULD have the ability to
  323.      enable the AUTH-TOO-WEAK or ENCRYPT-NEEDED errors on a per-user
  324.      basis to ease the transition away from unencrypted plaintext
  325.      passwords.
  326.  
  327.  
  328. 7. References
  329.  
  330.      [ABNF] Crocker, D., "Augmented BNF for Syntax Specifications:
  331.      ABNF", Work in progress: draft-ietf-drums-abnf-xx.txt
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Newman                                                          [Page 6]
  339.  
  340. Internet Draft     Plaintext Password SASL Mechanism           July 1997
  341.  
  342.  
  343.      [CRAM-MD5] Klensin, Catoe, Krumviede, "IMAP/POP AUTHorize Extension
  344.      for Simple Challenge/Response", RFC 2095, MCI, January 1997.
  345.  
  346.          <ftp://ds.internic.net/rfc/rfc2095.txt>
  347.  
  348.      [IMAP4] Crispin, M., "Internet Message Access Protocol - Version
  349.      4rev1", RFC 2060, University of Washington, December 1996.
  350.  
  351.          <ftp://ds.internic.net/rfc/rfc2060.txt>
  352.  
  353.      [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate
  354.      Requirement Levels", RFC 2119, Harvard University, March 1997.
  355.  
  356.          <ftp://ds.internic.net/rfc/rfc2119.txt>
  357.  
  358.      [POP3] Myers, J., Rose, M., "Post Office Protocol - Version 3", RFC
  359.      1939, Carnegie Mellon, Dover Beach Consulting, Inc., May 1996.
  360.  
  361.              <ftp://ds.internic.net/rfc/rfc1939.txt>
  362.  
  363.      [POP-AUTH] Myers, "POP3 AUTHentication command", RFC 1734, Carnegie
  364.      Mellon, December 1994.
  365.  
  366.          <ftp://ds.internic.net/rfc/rfc1734.txt>
  367.  
  368.      [SASL] Myers, "Simple Authentication and Security Layer (SASL)",
  369.      work in progress.
  370.  
  371.      [UTF8] Yergeau, F. "UTF-8, a transformation format of Unicode and
  372.      ISO 10646", RFC 2044, Alis Technologies, October 1996.
  373.  
  374.          <ftp://ds.internic.net/rfc/rfc2044.txt>
  375.  
  376. 8. Acknowledgements
  377.  
  378.      Thanks to John Myers and Larry Osterman for providing feedback on
  379.      the initial version of this specification.  Thanks to Ned Freed and
  380.      Kevin Carosso for coming up with the basic plaintext transition
  381.      idea.
  382.  
  383. 9. Author's Address
  384.  
  385.      Chris Newman
  386.      Innosoft International, Inc.
  387.      1050 Lakes Drive
  388.      West Covina, CA 91790 USA
  389.  
  390.      Email: chris.newman@innosoft.com
  391.  
  392.  
  393.  
  394. Newman                                                          [Page 7]
  395.  
  396.