340 lines
11 KiB
Plaintext
340 lines
11 KiB
Plaintext
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
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]
|
|||
|
|
|