IMAP4 auth: IMAP4 Authentication Mechanisms
Three ways an IMAP4 client can prove who it is, and how each one can protect the rest of the session.
Myers, J., "IMAP4 Authentication Mechanisms", RFC 1731, DOI 10.17487/RFC1731, December 1994, <https://www.rfc-editor.org/info/rfc1731>.
@misc{rfc1731,
series = {Request for Comments},
number = 1731,
howpublished = {RFC 1731},
publisher = {RFC Editor},
doi = {10.17487/RFC1731},
url = {https://www.rfc-editor.org/info/rfc1731},
author = {J. Myers},
title = {{IMAP4 Authentication Mechanisms}},
pagetotal = 6,
year = 1994,
month = dec,
} RFC text
Contents
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
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
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
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.
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
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
ISO Plain Language
On this page
§1Introduction
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. RFC 1731 defines three authentication mechanisms for use with that command: Kerberos version 4, GSSAPI and S/Key.
All three follow the same overall shape, shown in the examples in this memo. The client sends an AUTHENTICATE command naming the mechanism it wants, the server answers with a ready response, the client answers in turn, and the server closes the exchange with a tagged OK or NO. The tag used in the examples is A001, so the last line is either A001 OK Kerberos V4 authentication successful or A001 NO Kerberos V4 authentication failed.
Before a mail client can read a mailbox, it has to tell the server who it is. IMAP4 does that with a command called AUTHENTICATE. The client names the method it wants to use, the server sends a challenge, the client answers it, and the server says whether it accepts the answer. This RFC describes three methods.
§2Kerberos Version 4 Authentication
The mechanism is named KERBEROS_V4. The data in the first ready response contains a random 32-bit number in network byte order. The client answers with a Kerberos ticket and an authenticator for the principal imap.hostname@realm, where hostname is the first component of the server's host name with all letters in lower case, and realm is the server's Kerberos realm. The encrypted checksum field inside the authenticator carries the server's 32-bit number.
After decrypting and verifying the ticket and the authenticator, the server checks that the checksum inside equals the number it sent. If the check passes, the server adds one to the checksum and constructs 8 octets: the incremented checksum in the first four octets, a bit-mask naming the protection mechanisms the server supports in the fifth octet, and the maximum cipher-text buffer size the server can receive in the sixth through eighth octets. The server encrypts those 8 octets with the session key and issues them in a second ready response.
The client treats the server as authenticated when the first four octets of the decrypted data equal one plus the checksum it sent. The client then constructs its own data: the original checksum in the first four octets, the bit-mask of the protection mechanism it selected in the fifth, the maximum cipher-text buffer size it can receive in the sixth through eighth, and the user name string after that. It appends one to eight octets so the data length is a multiple of eight octets, encrypts the result with the session key using PCBC, and sends it. The server decrypts the data, verifies the checksum, and verifies that the principal in the Kerberos ticket is authorised to connect as that user name. After both verifications the authentication is complete.
The server starts by sending a random number. The client answers with a ticket from Kerberos that carries the same number inside it, so the server can tell that the answer is fresh and meant for it. The two sides then agree a protection setting and each send an encrypted block, one of which also carries the name of the user the client wants to act as.
- AUTHENTICATE KERBEROS_V4The client names the mechanism.
- ready response: random 32-bit number
- Kerberos ticket and authenticatorThe authenticator carries the server's number in its checksum field.
- ready response: 8 encrypted octetsIncremented checksum, protection bit-mask and the server's maximum cipher-text buffer size.
- encrypted 8 octets and user namePCBC encrypted with the session key and padded to a multiple of eight octets.
- OK Kerberos V4 authentication successful
§3GSSAPI Authentication
Every mechanism built on the Generic Security Service Application Program Interface (GSSAPI) shares the authentication type GSSAPI. The server's first ready response contains no data. The client calls GSS_Init_sec_context with a target name built from the string SERVICE:imap@hostname, where hostname is the fully qualified host name of the server with all letters in lower case, and answers with the resulting output token. If the call returns GSS_CONTINUE_NEEDED, the client expects a token from the server in a later ready response and passes it to another call. If it returns GSS_COMPLETE, the client answers with any remaining output token, or with no data, and then waits for the server's final token.
The client passes the server's last token to GSS_Unseal. The first octet of the resulting cleartext is a bit-mask naming the protection mechanisms the server supports, and the second through fourth octets are the maximum size message the server can receive. The client constructs data with the bit-mask of the protection mechanism it selected in the first octet, the maximum size message it can receive in the second through fourth octets, and the user name string after that. It passes the data to GSS_Seal with the confidentiality flag set to FALSE and answers with the generated message. The client can then consider the server authenticated.
On the server side, the first ready response carries no data, and the client's token is passed to GSS_Accept_sec_context as the input token, with the acceptor credential handle set to NULL to use the default credentials. When that call returns GSS_COMPLETE, the server constructs 4 octets: the protection bit-mask in the first octet and the maximum size token it can receive in the second through fourth octets. It seals the plaintext with the confidentiality flag set to FALSE and issues the result in a ready response. It then unseals the client's token, reads the selected bit-mask, the maximum message size and the user name, and checks that the source name is authorised to authenticate as that user name.
GSSAPI hands the whole exchange to a security library rather than defining its own steps. The client and the server pass tokens back and forth through that library until it reports the exchange is complete. Each side then reads the protection setting and the maximum message size out of the final token, and the client sends the user name inside a sealed block.
§4S/Key Authentication
The mechanism is named SKEY. The server's first ready response contains no data, and the client responds with the user name string. The data 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, either as a 64-bit value in network byte order or encoded in the "six English words" format. Once the one-time password has been verified, the server considers the client authenticated.
S/Key authentication does not provide for any protection mechanism, so the IMAP4 session that follows it is unprotected.
S/Key is the simplest of the three. The client sends the user name, the server sends a seed and a sequence number, and the client answers with a one-time password derived from them. Each password works only once, and it protects nothing after the login: the rest of the session runs in the clear.
§5Protection Mechanism Bit-Masks
| Mechanism | First ready response from the server | Protection choices |
|---|---|---|
| KERBEROS_V4 | A random 32-bit number | 1, 2 or 4 |
| GSSAPI | No data | 1, 2 or 4 |
| SKEY | No data | None |
Two of the three mechanisms also settle how the rest of the session is protected. The choice travels as a bit-mask, a single octet in which each value names one protection mechanism.
- Value 1: no protection mechanism.
- Value 2: integrity protection. Kerberos version 4 calls this
krb_mk_safe, and GSSAPI describes it as the sender callingGSS_Sealwith the confidentiality flag set to FALSE. - Value 4: privacy protection. Kerberos version 4 calls this
krb_mk_priv, and GSSAPI describes it as the sender callingGSS_Sealwith the confidentiality flag set to TRUE.
The client sends the bit-mask of the mechanism it selected, and the server reads that choice back out of the sealed message. Each side also states the largest cipher-text buffer it can receive, so neither peer sends more than the other can take.
After the login succeeds, the two sides can still choose how much protection the session gets. The choice is a one-byte code: no protection, protection that detects changes, or protection that also hides the content. S/Key offers none of these.
- 1No protection — No protection mechanism is applied to the session.
- 2Integrity — Kerberos version 4 calls this krb_mk_safe; GSSAPI calls it GSS_Seal with the confidentiality flag set to FALSE.
- 4Privacy — Kerberos version 4 calls this krb_mk_priv; GSSAPI calls it GSS_Seal with the confidentiality flag set to TRUE.
§6Security Considerations
The memo says security issues are discussed throughout it, and the sections above show where each decision is taken. The Kerberos version 4 and GSSAPI mechanisms both verify a ticket or a token before the user is accepted, and both check the principal or source name against the user name the client supplied, so a client cannot ask to act as a user its credentials do not cover.
The S/Key mechanism proves only that the client holds a valid one-time password. It provides no protection mechanism, so the IMAP4 commands that follow are sent unprotected.
Each mechanism decides something different about safety. Kerberos and GSSAPI check that the client is entitled to use the user name it asked for. S/Key checks only a one-time password and leaves the rest of the session unprotected.