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