As per Relevance of the word containing, we have this rfc below:
Network Working Group J.
Request for Comments: 1731 Carnegie
Category: Standards Track December 1994
IMAP4 Authentication
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
1.
The Internet Message Access Protocol, Version 4 [IMAP4] contains
AUTHENTICATE command, for identifying and authenticating a user to
IMAP4 server and for optionally negotiating a protection
for subsequent protocol interactions. This document
several authentication mechanisms for use by the IMAP4
command
2. Kerberos version 4 authentication
The authentication type associated with Kerberos version 4
"KERBEROS_V4".
The data encoded in the first ready response contains a random 32-
number in network byte order. The client should respond with
Kerberos ticket and an authenticator for the
"imap.hostname@realm", where "hostname" is the first component of
host name of the server with all letters in lower case and
"realm" is the Kerberos realm of the server. The encrypted
field included within the Kerberos authenticator should contain
server provided 32-bit number in network byte order
Upon decrypting and verifying the ticket and authenticator,
server should verify that the contained checksum field equals
original server provided random 32-bit number. Should
verification be successful, the server must add one to the
and construct 8 octets of data, with the first four octets
the incremented checksum in network byte order, the fifth
containing a bit-mask specifying the protection mechanisms
by the server, and the sixth through eighth octets containing,
Myers [Page 1]
RFC 1731 IMAP4 Authentication Mechanisms December 1994
network byte order, the maximum cipher-text buffer size the server
able to receive. The server must encrypt the 8 octets of data in
session key and issue that encrypted data in a second ready response
The client should consider the server authenticated if the first
octets the un-encrypted data is equal to one plus the checksum
previously sent
The client must construct data with the first four octets
the original server-issued checksum in network byte order, the
octet containing the bit-mask specifying the selected
mechanism, the sixth through eighth octets containing in network
order the maximum cipher-text buffer size the client is able
receive, and the following octets containing a user name string.
client must then append from one to eight octets so that the
of the data is a multiple of eight octets. The client must then
encrypt the data with the session key and respond to the second
response with the encrypted data. The server decrypts the data
verifies the contained checksum. The username field identifies
user for whom subsequent IMAP operations are to be performed;
server must verify that the principal identified in the
ticket is authorized to connect as that user. After
verifications, the authentication process is complete
The protection mechanisms and their corresponding bit-masks are
follows
1 No protection
2 Integrity (krb_mk_safe)
4 Privacy (krb_mk_priv)
EXAMPLE: The following are two Kerberos version 4 login
(note that the line breaks in the sample authenticators are
editorial clarity and are not in real authenticators
S: * OK IMAP4
C: A001 AUTHENTICATE KERBEROS_V
S: + AmFYig==
C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4
+nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/
WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1
S: + or//EoAADZI
C: DiAF5A4gA+oOIALuBkAAmw==
S: A001 OK Kerberos V4 authentication
Myers [Page 2]
RFC 1731 IMAP4 Authentication Mechanisms December 1994
S: * OK IMAP4
C: A001 AUTHENTICATE KERBEROS_V
S: + gcfgCA==
C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4
+nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/
WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1
S: A001 NO Kerberos V4 authentication
3. GSSAPI authentication
The authentication type associated with all mechanisms employing
GSSAPI [RFC1508] is "GSSAPI".
The first ready response issued by the server contains no data.
client should call GSS_Init_sec_context, passing in 0
input_context_handle (initially) and a targ_name equal to output_
from GSS_Import_Name called with input_name_type of NULL
input_name_string of "SERVICE:imap@hostname" where "hostname" is
fully qualified host name of the server with all letters in
case. The client must then respond with the resulting output_token
If GSS_Init_sec_context returns GSS_CONTINUE_NEEDED, then the
should expect the server to issue a token in a subsequent
response. The client must pass the token to another call
GSS_Init_sec_context
If GSS_Init_sec_context returns GSS_COMPLETE, then the client
respond with any resulting output_token. If there is
output_token, the client should respond with no data. The
should then expect the server to issue a token in a subsequent
response. The client should pass this token to GSS_Unseal
interpret the first octet of resulting cleartext as a bit-
specifying the protection mechanisms supported by the server and
second through fourth octets as the maximum size output_message
send to the server. The client should construct data, with the
octet containing the bit-mask specifying the selected
mechanism, the second through fourth octets containing in
byte order the maximum size output_message the client is able
receive, and the remaining octets containing a user name string.
client must pass the data to GSS_Seal with conf_flag set to FALSE
and respond with the generated output_message. The client can
consider the server authenticated
The server must issue a ready response with no data and pass
resulting client supplied token to GSS_Accept_sec_context
input_token, setting acceptor_cred_handle to NULL (for "use
credentials"), and 0 for input_context_handle (initially).
GSS_Accept_sec_context returns GSS_CONTINUE_NEEDED, the server
Myers [Page 3]
RFC 1731 IMAP4 Authentication Mechanisms December 1994
return the generated output_token to the client in a ready
and pass the resulting client supplied token to another call
GSS_Accept_sec_context
If GSS_Accept_sec_context returns GSS_COMPLETE, then if
output_token is returned, the server should return it to the
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
then construct 4 octets of data, with the first octet containing
bit-mask specifying the protection mechanisms supported by the
and the second through fourth octets containing in network byte
the maximum size output_token the server is able to receive.
server must then pass the plaintext to GSS_Seal with conf_flag set
FALSE and issue the generated output_message to the client in a
response. The server must then pass the resulting client
token to GSS_Unseal and interpret the first octet of
cleartext as the bit-mask for the selected protection mechanism,
second through fourth octets as the maximum size output_message
send to the client, and the remaining octets as the user name.
verifying the src_name is authorized to authenticate as the
name, The server should then consider the client authenticated
The protection mechanisms and their corresponding bit-masks are
follows
1 No protection
2 Integrity protection
Sender calls GSS_Seal with conf_flag set to
4 Privacy protection
Sender calls GSS_Seal with conf_flag set to
4. S/Key authentication
The authentication type associated with S/Key [SKEY] is "SKEY".
The first ready response issued by the server contains no data.
client responds with the user name string
The data encoded in the second ready response contains the
sequence number followed by a single space and the seed string
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 "
English words" format
Upon successful verification of the one-time-password, the
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
C: A001 AUTHENTICATE
S: +
C: bW9yZ2
S: + OTUgUWE1ODMwOA==
C: Rk9VUiBNQU5OIFNPT04gRklSIFZBUlkgTUFTSA==
S: A001 OK S/Key authentication
S: * OK IMAP4
C: A001 AUTHENTICATE
S: +
C: c21pdGg
S: + OTUgUWE1ODMwOA==
C: BsAY3g4gBNo
S: A001 NO S/Key authentication
5.
[IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4",
RFC 1730, University of Washington, December 1994.
[RFC1508] Linn, J., "Generic Security Service Application
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.
Myers [Page 5]
RFC 1731 IMAP4 Authentication Mechanisms December 1994
6. Security
Security issues are discussed throughout this memo
7. Author's
John G.
Carnegie-Mellon
5000 Forbes Ave
Pittsburgh PA, 15213-3890
EMail: jgm+@cmu.
Myers [Page 6]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
