Remove RFCs from the trunk, since we don't distribute them anyways. All of the removed RFCs are listed in the design-notes.html file, with the exception of NNTP (RFC977). Also add a link to the "LAN Mail Protocols" document to the design-notes.html file.

svn path=/trunk/; revision=4013

1 files changed, 0 insertions, 339 deletions

diff --git a/RFC/rfc1731.txt b/RFC/rfc1731.txt
deleted file mode 100644
index 42215dec..00000000
--- a/RFC/rfc1731.txt
+++ /dev/null
@@ -1,339 +0,0 @@
-

-

-

-

-

-

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

-