Added two new RFCs relevant to IMAP AUTH extension mechanisms.

@@ -129,7 +129,7 @@ For more information on,
 
 
 @itemize @bullet
 @itemize @bullet
 @item
 @item
-on SMTP
+SMTP
 
 
 @itemize @minus
 @itemize @minus
 @item
 @item
@@ -140,7 +140,7 @@ on SMTP
 @end itemize
 @end itemize
 
 
 @item
 @item
-on POP3
+POP3
 
 
 @itemize @minus
 @itemize @minus
 @item
 @item
@@ -161,7 +161,7 @@ Protocol (POP3)}
 @end itemize
 @end itemize
 
 
 @item
 @item
-on IMAP4
+IMAP4
 
 
 @itemize @minus
 @itemize @minus
 @item
 @item
@@ -181,10 +181,17 @@ on IMAP4
 
 
 @item
 @item
 @cite{RFC 2192: IMAP URL Scheme}
 @cite{RFC 2192: IMAP URL Scheme}
+
+@item
+@cite{RFC 1731: IMAP4 Authentication Mechanisms}
+
+@item
+@cite{RFC 2245: Anonymous SASL Mechanism}
+
 @end itemize
 @end itemize
 
 
 @item
 @item
-on message formats
+message formats
 
 
 @itemize @minus
 @itemize @minus
 @item
 @item
@@ -211,7 +218,7 @@ Conformance Criteria and Examples}
 @end itemize
 @end itemize
 
 
 @item
 @item
-on miscellaneous related topics
+miscellaneous related topics
 
 
 @itemize @minus
 @itemize @minus
 @item
 @item

+
+
+
+
+
+
+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]
+

+
+
+
+
+
+
+Network Working Group                                          C. Newman
+Request for Comments: 2245                                      Innosoft
+Category: Standards Track                                  November 1997
+
+
+                        Anonymous SASL Mechanism
+
+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.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1997).  All Rights Reserved.
+
+Abstract
+
+   It is common practice on the Internet to permit anonymous access to
+   various services.  Traditionally, this has been done with a plain
+   text password mechanism using "anonymous" as the user name and
+   optional trace information, such as an email address, as the
+   password.  As plaintext login commands are not permitted in new IETF
+   protocols, a new way to provide anonymous login is needed within the
+   context of the SASL [SASL] framework.
+
+1. Conventions Used in this Document
+
+   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
+   in this document are to be interpreted as defined in "Key words for
+   use in RFCs to Indicate Requirement Levels" [KEYWORDS].
+
+2. Anonymous SASL mechanism
+
+   The mechanism name associated with anonymous access is "ANONYMOUS".
+   The mechanism consists of a single message from the client to the
+   server.  The client sends optional trace information in the form of a
+   human readable string.  The trace information should take one of
+   three forms: an Internet email address, an opaque string which does
+   not contain the '@' character and can be interpreted by the system
+   administrator of the client's domain, or nothing.  For privacy
+   reasons, an Internet email address should only be used with
+   permission from the user.
+
+
+
+
+
+Newman                      Standards Track                     [Page 1]
+
+RFC 2245                Anonymous SASL Mechanism           November 1997
+
+
+   A server which permits anonymous access will announce support for the
+   ANONYMOUS mechanism, and allow anyone to log in using that mechanism,
+   usually with restricted access.
+
+   The formal grammar for the client message using Augmented BNF [ABNF]
+   follows.
+
+   message         = [email / token]
+
+   TCHAR           = %x20-3F / %x41-7E
+                     ;; any printable US-ASCII character except '@'
+
+   email           = addr-spec
+                     ;; as defined in [IMAIL], except with no free
+                     ;; insertion of linear-white-space, and the
+                     ;; local-part MUST either be entirely enclosed in
+                     ;; quotes or entirely unquoted
+
+   token           = 1*255TCHAR
+
+3. Example
+
+
+   Here is a sample anonymous login between an IMAP client and server.
+   In this example, "C:" and "S:" indicate lines sent by the client and
+   server respectively.  If such lines are wrapped without a new "C:" or
+   "S:" label, then the wrapping is for editorial clarity and is not
+   part of the command.
+
+   Note that this example uses the IMAP profile [IMAP4] of SASL.  The
+   base64 encoding of challenges and responses, as well as the "+ "
+   preceding the responses are part of the IMAP4 profile, not part of
+   SASL itself.  Newer profiles of SASL will include the client message
+   with the AUTHENTICATE command itself so the extra round trip below
+   (the server response with an empty "+ ") can be eliminated.
+
+   In this example, the user's opaque identification token is "sirhc".
+
+        S: * OK IMAP4 server ready
+        C: A001 CAPABILITY
+        S: * CAPABILITY IMAP4 IMAP4rev1 AUTH=CRAM-MD5 AUTH=ANONYMOUS
+        S: A001 OK done
+        C: A002 AUTHENTICATE ANONYMOUS
+        S: +
+        C: c2lyaGM=
+        S: A003 OK Welcome, trace information has been logged.
+
+
+
+
+
+Newman                      Standards Track                     [Page 2]
+
+RFC 2245                Anonymous SASL Mechanism           November 1997
+
+
+4. Security Considerations
+
+   The anonymous mechanism grants access to information by anyone.  For
+   this reason it should be disabled by default so the administrator can
+   make an explicit decision to enable it.
+
+   If the anonymous user has any write privileges, a denial of service
+   attack is possible by filling up all available space.  This can be
+   prevented by disabling all write access by anonymous users.
+
+   If anonymous users have read and write access to the same area, the
+   server can be used as a communication mechanism to anonymously
+   exchange information.  Servers which accept anonymous submissions
+   should implement the common "drop box" model which forbids anonymous
+   read access to the area where anonymous submissions are accepted.
+
+   If the anonymous user can run many expensive operations (e.g., an
+   IMAP SEARCH BODY command), this could enable a denial of service
+   attack.  Servers are encouraged to limit the number of anonymous
+   users and reduce their priority or limit their resource usage.
+
+   If there is no idle timeout for the anonymous user and there is a
+   limit on the number of anonymous users, a denial of service attack is
+   enabled.  Servers should implement an idle timeout for anonymous
+   users.
+
+   The trace information is not authenticated so it can be falsified.
+   This can be used as an attempt to get someone else in trouble for
+   access to questionable information.  Administrators trying to trace
+   abuse need to realize this information may be falsified.
+
+   A client which uses the user's correct email address as trace
+   information without explicit permission may violate that user's
+   privacy.  Information about who accesses an anonymous archive on a
+   sensitive subject (e.g., sexual abuse) has strong privacy needs.
+   Clients should not send the email address without explicit permission
+   of the user and should offer the option of supplying no trace token
+   -- thus only exposing the source IP address and time.  Anonymous
+   proxy servers could enhance this privacy, but would have to consider
+   the resulting potential denial of service attacks.
+
+   Anonymous connections are susceptible to man in the middle attacks
+   which view or alter the data transferred.  Clients and servers are
+   encouraged to support external integrity and encryption mechanisms.
+
+   Protocols which fail to require an explicit anonymous login are more
+   susceptible to break-ins given certain common implementation
+   techniques.  Specifically, Unix servers which offer user login may
+
+
+
+Newman                      Standards Track                     [Page 3]
+
+RFC 2245                Anonymous SASL Mechanism           November 1997
+
+
+   initially start up as root and switch to the appropriate user id
+   after an explicit login command.  Normally such servers refuse all
+   data access commands prior to explicit login and may enter a
+   restricted security environment (e.g., the Unix chroot function) for
+   anonymous users.  If anonymous access is not explicitly requested,
+   the entire data access machinery is exposed to external security
+   attacks without the chance for explicit protective measures.
+   Protocols which offer restricted data access should not allow
+   anonymous data access without an explicit login step.
+
+5. References
+
+   [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+   Specifications: ABNF", RFC 2234, November 1997.
+
+   [IMAIL] Crocker, D., "Standard for the Format of Arpa Internet Text
+   Messages", STD 11, RFC 822, August 1982.
+
+   [IMAP4] Crispin, M., "Internet Message Access Protocol - Version
+   4rev1", RFC 2060, December 1996.
+
+   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
+   Requirement Levels", RFC 2119, March 1997.
+
+   [SASL] Myers, J., "Simple Authentication and Security Layer (SASL)",
+   RFC 2222, October 1997.
+
+6. Author's Address
+
+   Chris Newman
+   Innosoft International, Inc.
+   1050 Lakes Drive
+   West Covina, CA 91790 USA
+
+   Email: chris.newman@innosoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newman                      Standards Track                     [Page 4]
+
+RFC 2245                Anonymous SASL Mechanism           November 1997
+
+
+7.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1997).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newman                      Standards Track                     [Page 5]
+