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