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-00.txt < prev    next >
Text File  |  1997-06-02  |  12KB  |  341 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          C. Newman
  8. Internet Draft: Plain Transition SASL mechanism                 Innosoft
  9. Document: draft-newman-sasl-plaintrans-00.txt                   May 1997
  10.                                                    Expires in six months
  11.  
  12.  
  13.               Plaintext Password Transition SASL mechanism
  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.  Internet Drafts may be updated, replaced, or obsoleted by
  25.      other documents at any time.  It is not appropriate to use Internet
  26.      Drafts as reference material or to cite them other than as a
  27.      "working draft" or "work in progress".
  28.  
  29.      To learn the current status of any Internet-Draft, please check the
  30.      1id-abstracts.txt listing contained in the Internet-Drafts Shadow
  31.      Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or
  32.      munnari.oz.au.
  33.  
  34.      A revised version of this draft document will be submitted to the
  35.      RFC editor as a Proposed Standard for the Internet Community.
  36.      Discussion and suggestions for improvement are requested.  This
  37.      document will expire six months after publication.  Distribution of
  38.      this draft is unlimited.
  39.  
  40.  
  41. Abstract
  42.  
  43.      In order to replace plaintext passwords, the Internet community
  44.      needs a strong authentication system which is standards track,
  45.      general purpose, and sufficiently easy to implement that client
  46.      authors might be willing to spend valuable development time
  47.      implementing it.  The only mechanism which comes close to this
  48.      today is CRAM-MD5 [CRAM-MD5].
  49.  
  50.      Unfortunately, CRAM-MD5 and it's predecessor APOP [POP3] can not be
  51.      used with most server authentication databases in use today since
  52.      these databases store the password after applying an incompatible
  53.      one-way function.  This proposal defines a SASL [SASL] mechanism
  54.      and associated response codes which can be used to make the
  55.  
  56.  
  57.  
  58. Newman                                                          [Page 1]
  59.  
  60. Internet Draft      Plain Transition SASL mechanism             May 1997
  61.  
  62.  
  63.      transition relatively painless.
  64.  
  65.  
  66. 1. Conventions used in this document
  67.  
  68.      The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
  69.      in this document are to be interpreted as defined in "Key words for
  70.      use in RFCs to Indicate Requirement Levels" [KEYWORDS].
  71.  
  72.  
  73. 2. Plaintext Password Transition SASL mechanism
  74.  
  75.      The mechanism name associated with plaintext password transition is
  76.      "PLAINTRANSITION".
  77.  
  78.      The mechanism consists of a single message from the client to the
  79.      server.  The client sends the authorization identity, followed by a
  80.      US-ASCII tab character, followed by the authentication identity,
  81.      followed by a US-ASCII tab character, followed by the plaintext
  82.      password.  The client may leave the authorization identity empty to
  83.      indicate that it is the same as the authentication identity.
  84.  
  85.      The server will verify the authentication identity and password
  86.      with the system authentication database and verify that the
  87.      authentication credentials permit the client to login as the
  88.      authorization identity.  If both these steps succeed, the password
  89.      will be stored in a new authentication database capable of
  90.      supporting stronger authentication mechanisms.  Once this has
  91.      completed, the server MUST refuse future PLAINTRANSITION commands
  92.      by that authentication identity, and SHOULD refuse future plaintext
  93.      login commands by that authentication identity.
  94.  
  95.      The formal grammar for the client message using Augmented BNF
  96.      [ABNF] follows.
  97.  
  98.      message         = [authorize-id] TAB authenticate-id TAB password
  99.  
  100.      ACHAR           = %x20..7E
  101.  
  102.      PCHAR           = %x01..09 / %x0B..0C / %x0E..7F
  103.  
  104.      TAB             = %x09
  105.  
  106.      authenticate-id = 1*255ACHAR
  107.  
  108.      authorize-id    = 1*255ACHAR
  109.  
  110.      password        = 1*255PCHAR
  111.  
  112.  
  113.  
  114. Newman                                                          [Page 2]
  115.  
  116. Internet Draft      Plain Transition SASL mechanism             May 1997
  117.  
  118.  
  119. 3. New response codes
  120.  
  121.      This mechanism requires support for new failure codes in protocols
  122.      which use it.
  123.  
  124.      The failure codes for use with IMAP4 [IMAP4] are defined here:
  125.  
  126.      TRANSITION-NEEDED
  127.           This IMAP response code occurs on the tagged NO response to an
  128.           AUTHENTICATE command after an attempt to use a mechanism other
  129.           than PLAINTRANSITION.  It indicates that that mechanism is not
  130.           currently usable, but would be usable one a PLAINTRANSITION
  131.           has occured.  This may also occur in response to a LOGIN
  132.           command indicating that the user is required to use
  133.           PLAINTRANSITION but all other uses of plaintext passwords will
  134.           be denied.  This may also be used on an OK response to a LOGIN
  135.           command to indicate that the user should transition to a
  136.           stronger mechanism. In this context it may be followed by a
  137.           number indicating the number of days until the user's password
  138.           will expire if the user fails to transition.
  139.  
  140.  
  141.      PLAINTEXT-DENIED
  142.           This IMAP response code occurs on the tagged NO response to a
  143.           LOGIN command or "AUTHENTICATE PLAINTRANSITION" command.  It
  144.           indicates that a transition has already happened on the server
  145.           and plaintext passwords are no longer permitted.
  146.  
  147.  
  148.      The failure codes for use with POP3 [POP3] are defined here:
  149.  
  150.  
  151.      -ERR Transition needed
  152.           This occurs in response to an APOP or AUTH [POP-AUTH] command
  153.           that is not currently available, but will be available after
  154.           the use of PLAINTRANSITION.  It can occur in response to a
  155.           USER or PASS command to indicate that transition is required
  156.           but all other uses of plaintext passwords will be denied.
  157.           Additional text may be added on the end of this message to
  158.           explain the error more clearly.
  159.  
  160.  
  161.      +OK <number> days until password transition required
  162.           This message occurs in response to a successful PASS command
  163.           and indicates when the user's password will expire if the user
  164.           fails to transition.
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Newman                                                          [Page 3]
  171.  
  172. Internet Draft      Plain Transition SASL mechanism             May 1997
  173.  
  174.  
  175.      -ERR Plaintext passwords forbidden
  176.           This occurs in response to a USER, PASS or AUTH
  177.           PLAINTRANSITION command and indicates that the server no
  178.           longer permits plaintext passwords because a transition has
  179.           occurred.  Additional text may be added on the end of this
  180.           message to explain the error more clearly.
  181.  
  182.  
  183.  
  184. 4. Implementation Requirements for Plaintext Password Transition
  185.  
  186.      Clients MUST NOT use the PLAINTRANSITION mechanism unless the
  187.      server offers another SASL mechanism which the client understands.
  188.      Servers which support PLAINTRANSITION MUST support another stronger
  189.      SASL mechanism.
  190.  
  191.      Clients SHOULD NOT use PLAINTRANSITION unless they first attempt a
  192.      stronger mechanism and receive an indication from the server that a
  193.      transition is needed.  Clients are encouraged to warn the user that
  194.      the transition may be one way and could prevent future use of
  195.      insecure clients.  Clients are encouraged to negotiate an encrypted
  196.      stream prior to use of PLAINTRANSITION if possible.  Clients which
  197.      fail to do this may wish to warn the user that the transition
  198.      itself is an insecure process.
  199.  
  200.  
  201. 5. Example
  202.  
  203.      Here is a sample transition exchange between an IMAP client and
  204.      server.  In this example, "C:" and "S:" indicate lines sent by the
  205.      client and server respectively.  If such lines are wrapped without
  206.      a new "C:" or "S:" label, then the wrapping is for editorial
  207.      clarity and is not part of the command.
  208.  
  209.      Note that this example uses the IMAP profile [IMAP4] of SASL.  The
  210.      base64 encoding of challenges and responses, as well as the "+ "
  211.      preceding the responses are part of the IMAP4 profile, not part of
  212.      SASL itself.  Newer profiles of SASL will include the client
  213.      message with the AUTHENTICATE command itself so the extra round
  214.      trip below (the server response with an empty "+ ") can be
  215.      eliminated.
  216.  
  217.      In this example, the user's authentication identifier is "tim", his
  218.      authorization identifier is the same, and his password is
  219.      "tanstaaftanstaaf".
  220.  
  221.         S: * OK IMAP4 server ready
  222.         C: A001 CAPABILITY
  223.  
  224.  
  225.  
  226. Newman                                                          [Page 4]
  227.  
  228. Internet Draft      Plain Transition SASL mechanism             May 1997
  229.  
  230.  
  231.         S: * CAPABILITY IMAP4 IMAP4rev1 AUTH=CRAM-MD5 AUTH=PLAINTRANSITION
  232.         S: A001 OK done
  233.         C: A002 AUTHENTICATE CRAM-MD5
  234.         S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+
  235.         C: dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw
  236.         S: A002 NO [TRANSITION-NEEDED] You can't login securely until
  237.                 you've changed your password on the server
  238.         C: A003 AUTHENTICATE PLAINTRANSITION
  239.         S: +
  240.         C: CXRpbQl0YW5zdGFhZnRhbnN0YWFmCg==
  241.         S: A003 OK You can now login securely in the future.
  242.         C: A004 SELECT INBOX
  243.            ...
  244.  
  245. 6. Security Considerations
  246.  
  247.      Security considerations are discussed throughout this document.
  248.  
  249.      A passive network observer can aquire the user's password if a
  250.      client uses PLAINTRANSITION over an unencrypted stream.
  251.  
  252.      Clients are encouraged to record the occurance of a successful
  253.      strong authentication or a successful PLAINTRANSITION for a given
  254.      user, server and protocol combination and refuse to use plain text
  255.      passwords for that user and that server in the future.  This will
  256.      prevent a man in the middle or a spoof server from aquiring the
  257.      user's password by pretending no strong authentication mechanisms
  258.      are available.
  259.  
  260.  
  261. 7. References
  262.  
  263.      [ABNF] Crocker, D., "Augmented BNF for Syntax Specifications:
  264.      ABNF", Work in progress: draft-ietf-drums-abnf-xx.txt
  265.  
  266.      [CRAM-MD5] Klensin, Catoe, Krumviede, "IMAP/POP AUTHorize Extension
  267.      for Simple Challenge/Response", RFC 2095, MCI, January 1997.
  268.  
  269.          <ftp://ds.internic.net/rfc/rfc2095.txt>
  270.  
  271.      [IMAP4] Crispin, M., "Internet Message Access Protocol - Version
  272.      4rev1", RFC 2060, University of Washington, December 1996.
  273.  
  274.          <ftp://ds.internic.net/rfc/rfc2060.txt>
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Newman                                                          [Page 5]
  283.  
  284. Internet Draft      Plain Transition SASL mechanism             May 1997
  285.  
  286.  
  287.      [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate
  288.      Requirement Levels", RFC 2119, Harvard University, March 1997.
  289.  
  290.          <ftp://ds.internic.net/rfc/rfc2119.txt>
  291.  
  292.      [POP3] Myers, J., Rose, M., "Post Office Protocol - Version 3", RFC
  293.      1939, Carnegie Mellon, Dover Beach Consulting, Inc., May 1996.
  294.  
  295.              <ftp://ds.internic.net/rfc/rfc1939.txt>
  296.  
  297.      [POP-AUTH] Myers, "POP3 AUTHentication command", RFC 1734, Carnegie
  298.      Mellon, December 1994.
  299.  
  300.          <ftp://ds.internic.net/rfc/rfc1734.txt>
  301.  
  302.      [SASL] Myers, "Simple Authentication and Security Layer (SASL)",
  303.      work in progress.
  304.  
  305.      [UTF8] Yergeau, F. "UTF-8, a transformation format of Unicode and
  306.      ISO 10646", RFC 2044, Alis Technologies, October 1996.
  307.  
  308.          <ftp://ds.internic.net/rfc/rfc2044.txt>
  309.  
  310.  
  311. 8. Acknowledgements
  312.  
  313.      Special thanks to Ned Freed and Kevin Carosso for coming up with
  314.      the basic idea for this proposal.
  315.  
  316.  
  317. 9. Author's Address
  318.  
  319.      Chris Newman
  320.      Innosoft International, Inc.
  321.      1050 East Garvey Ave. South
  322.      West Covina, CA 91790 USA
  323.  
  324.      Email: chris.newman@innosoft.com
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Newman                                                          [Page 6]
  339.  
  340.  
  341.