Add files from ESR's dev directory that weren't under version control

[~andy/fetchmail] / RFC / rfc1731.txt

\r
\r
\r
\r
\r
\r
Network Working Group                                           J. Myers\r
Request for Comments: 1731                               Carnegie Mellon\r
Category: Standards Track                                  December 1994\r
\r
\r
                    IMAP4 Authentication Mechanisms\r
\r
Status of this Memo\r
\r
   This document specifies an Internet standards track protocol for the\r
   Internet community, and requests discussion and suggestions for\r
   improvements.  Please refer to the current edition of the "Internet\r
   Official Protocol Standards" (STD 1) for the standardization state\r
   and status of this protocol.  Distribution of this memo is unlimited.\r
\r
\r
1. Introduction\r
\r
   The Internet Message Access Protocol, Version 4 [IMAP4] contains the\r
   AUTHENTICATE command, for identifying and authenticating a user to an\r
   IMAP4 server and for optionally negotiating a protection mechanism\r
   for subsequent protocol interactions.  This document describes\r
   several authentication mechanisms for use by the IMAP4 AUTHENTICATE\r
   command.\r
\r
\r
2. Kerberos version 4 authentication mechanism\r
\r
   The authentication type associated with Kerberos version 4 is\r
   "KERBEROS_V4".\r
\r
   The data encoded in the first ready response contains a random 32-bit\r
   number in network byte order.  The client should respond with a\r
   Kerberos ticket and an authenticator for the principal\r
   "imap.hostname@realm", where "hostname" is the first component of the\r
   host name of the server with all letters in lower case and where\r
   "realm" is the Kerberos realm of the server.  The encrypted checksum\r
   field included within the Kerberos authenticator should contain the\r
   server provided 32-bit number in network byte order.\r
\r
   Upon decrypting and verifying the ticket and authenticator, the\r
   server should verify that the contained checksum field equals the\r
   original server provided random 32-bit number.  Should the\r
   verification be successful, the server must add one to the checksum\r
   and construct 8 octets of data, with the first four octets containing\r
   the incremented checksum in network byte order, the fifth octet\r
   containing a bit-mask specifying the protection mechanisms supported\r
   by the server, and the sixth through eighth octets containing, in\r
\r
\r
\r
Myers                                                           [Page 1]\r
\f\r
RFC 1731            IMAP4 Authentication Mechanisms        December 1994\r
\r
\r
   network byte order, the maximum cipher-text buffer size the server is\r
   able to receive.  The server must encrypt the 8 octets of data in the\r
   session key and issue that encrypted data in a second ready response.\r
   The client should consider the server authenticated if the first four\r
   octets the un-encrypted data is equal to one plus the checksum it\r
   previously sent.\r
\r
   The client must construct data with the first four octets containing\r
   the original server-issued checksum in network byte order, the fifth\r
   octet containing the bit-mask specifying the selected protection\r
   mechanism, the sixth through eighth octets containing in network byte\r
   order the maximum cipher-text buffer size the client is able to\r
   receive, and the following octets containing a user name string.  The\r
   client must then append from one to eight octets so that the length\r
   of the data is a multiple of eight octets. The client must then PCBC\r
   encrypt the data with the session key and respond to the second ready\r
   response with the encrypted data.  The server decrypts the data and\r
   verifies the contained checksum.  The username field identifies the\r
   user for whom subsequent IMAP operations are to be performed; the\r
   server must verify that the principal identified in the Kerberos\r
   ticket is authorized to connect as that user.  After these\r
   verifications, the authentication process is complete.\r
\r
   The protection mechanisms and their corresponding bit-masks are as\r
   follows:\r
\r
      1 No protection mechanism\r
      2 Integrity (krb_mk_safe) protection\r
      4 Privacy (krb_mk_priv) protection\r
\r
\r
   EXAMPLE: The following are two Kerberos version 4 login scenarios\r
   (note that the line breaks in the sample authenticators are for\r
   editorial clarity and are not in real authenticators)\r
\r
      S: * OK IMAP4 Server\r
      C: A001 AUTHENTICATE KERBEROS_V4\r
      S: + AmFYig==\r
      C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT\r
         +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd\r
         WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh\r
      S: + or//EoAADZI=\r
      C: DiAF5A4gA+oOIALuBkAAmw==\r
      S: A001 OK Kerberos V4 authentication successful\r
\r
\r
\r
\r
\r
\r
\r
Myers                                                           [Page 2]\r
\f\r
RFC 1731            IMAP4 Authentication Mechanisms        December 1994\r
\r
\r
      S: * OK IMAP4 Server\r
      C: A001 AUTHENTICATE KERBEROS_V4\r
      S: + gcfgCA==\r
      C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT\r
         +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd\r
         WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh\r
      S: A001 NO Kerberos V4 authentication failed\r
\r
\r
3. GSSAPI authentication mechanism\r
\r
   The authentication type associated with all mechanisms employing the\r
   GSSAPI [RFC1508] is "GSSAPI".\r
\r
   The first ready response issued by the server contains no data.  The\r
   client should call GSS_Init_sec_context, passing in 0 for\r
   input_context_handle (initially) and a targ_name equal to output_name\r
   from GSS_Import_Name called with input_name_type of NULL and\r
   input_name_string of "SERVICE:imap@hostname" where "hostname" is the\r
   fully qualified host name of the server with all letters in lower\r
   case.  The client must then respond with the resulting output_token.\r
   If GSS_Init_sec_context returns GSS_CONTINUE_NEEDED, then the client\r
   should expect the server to issue a token in a subsequent ready\r
   response.  The client must pass the token to another call to\r
   GSS_Init_sec_context.\r
\r
   If GSS_Init_sec_context returns GSS_COMPLETE, then the client should\r
   respond with any resulting output_token.  If there is no\r
   output_token, the client should respond with no data.  The client\r
   should then expect the server to issue a token in a subsequent ready\r
   response.  The client should pass this token to GSS_Unseal and\r
   interpret the first octet of resulting cleartext as a bit-mask\r
   specifying the protection mechanisms supported by the server and the\r
   second through fourth octets as the maximum size output_message to\r
   send to the server.  The client should construct data, with the first\r
   octet containing the bit-mask specifying the selected protection\r
   mechanism, the second through fourth octets containing in network\r
   byte order the maximum size output_message the client is able to\r
   receive, and the remaining octets containing a user name string.  The\r
   client must pass the data to GSS_Seal with conf_flag set to FALSE,\r
   and respond with the generated output_message.  The client can then\r
   consider the server authenticated.\r
\r
   The server must issue a ready response with no data and pass the\r
   resulting client supplied token to GSS_Accept_sec_context as\r
   input_token, setting acceptor_cred_handle to NULL (for "use default\r
   credentials"), and 0 for input_context_handle (initially).  If\r
   GSS_Accept_sec_context returns GSS_CONTINUE_NEEDED, the server should\r
\r
\r
\r
Myers                                                           [Page 3]\r
\f\r
RFC 1731            IMAP4 Authentication Mechanisms        December 1994\r
\r
\r
   return the generated output_token to the client in a ready response\r
   and pass the resulting client supplied token to another call to\r
   GSS_Accept_sec_context.\r
\r
   If GSS_Accept_sec_context returns GSS_COMPLETE, then if an\r
   output_token is returned, the server should return it to the client\r
   in a ready response and expect a reply from the client with no data.\r
   Whether or not an output_token was returned, the server then should\r
   then construct 4 octets of data, with the first octet containing a\r
   bit-mask specifying the protection mechanisms supported by the server\r
   and the second through fourth octets containing in network byte order\r
   the maximum size output_token the server is able to receive.  The\r
   server must then pass the plaintext to GSS_Seal with conf_flag set to\r
   FALSE and issue the generated output_message to the client in a ready\r
   response.  The server must then pass the resulting client supplied\r
   token to GSS_Unseal and interpret the first octet of resulting\r
   cleartext as the bit-mask for the selected protection mechanism, the\r
   second through fourth octets as the maximum size output_message to\r
   send to the client, and the remaining octets as the user name.  Upon\r
   verifying the src_name is authorized to authenticate as the user\r
   name, The server should then consider the client authenticated.\r
\r
   The protection mechanisms and their corresponding bit-masks are as\r
   follows:\r
\r
      1 No protection mechanism\r
      2 Integrity protection.\r
        Sender calls GSS_Seal with conf_flag set to FALSE\r
      4 Privacy protection.\r
        Sender calls GSS_Seal with conf_flag set to TRUE\r
\r
\r
4. S/Key authentication mechanism\r
\r
   The authentication type associated with S/Key [SKEY] is "SKEY".\r
\r
   The first ready response issued by the server contains no data.  The\r
   client responds with the user name string.\r
\r
   The data encoded in the second ready response contains the decimal\r
   sequence number followed by a single space and the seed string for\r
   the indicated user.  The client responds with the one-time-password,\r
   as either a 64-bit value in network byte order or encoded in the "six\r
   English words" format.\r
\r
   Upon successful verification of the one-time-password, the server\r
   should consider the client authenticated.\r
\r
\r
\r
\r
Myers                                                           [Page 4]\r
\f\r
RFC 1731            IMAP4 Authentication Mechanisms        December 1994\r
\r
\r
   S/Key authentication does not provide for any protection mechanisms.\r
\r
\r
   EXAMPLE: The following are two S/Key login scenarios.\r
\r
      S: * OK IMAP4 Server\r
      C: A001 AUTHENTICATE SKEY\r
      S: +\r
      C: bW9yZ2Fu\r
      S: + OTUgUWE1ODMwOA==\r
      C: Rk9VUiBNQU5OIFNPT04gRklSIFZBUlkgTUFTSA==\r
      S: A001 OK S/Key authentication successful\r
\r
\r
      S: * OK IMAP4 Server\r
      C: A001 AUTHENTICATE SKEY\r
      S: +\r
      C: c21pdGg=\r
      S: + OTUgUWE1ODMwOA==\r
      C: BsAY3g4gBNo=\r
      S: A001 NO S/Key authentication failed\r
\r
\r
5. References\r
\r
   [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4",\r
   RFC 1730, University of Washington, December 1994.\r
\r
   [RFC1508] Linn, J., "Generic Security Service Application Program\r
   Interface", RFC 1508, Geer Zolot Associates, September 1993.\r
\r
   [SKEY] Haller, Neil M. "The S/Key One-Time Password System",\r
   Bellcore, Morristown, New Jersey, October 1993,\r
   thumper.bellcore.com:pub/nmh/docs/ISOC.symp.ps\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
Myers                                                           [Page 5]\r
\f\r
RFC 1731            IMAP4 Authentication Mechanisms        December 1994\r
\r
\r
6. Security Considerations\r
\r
   Security issues are discussed throughout this memo.\r
\r
\r
7. Author's Address\r
\r
   John G. Myers\r
   Carnegie-Mellon University\r
   5000 Forbes Ave.\r
   Pittsburgh PA, 15213-3890\r
\r
   EMail: jgm+@cmu.edu\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
Myers                                                           [Page 6]\r
\f\r