IMAP4 Authentication Mechanisms (RFC1731)
Original Publication Date: 1994-Dec-01
Included in the Prior Art Database: 2019-Feb-12
Internet Society Requests For Comment (RFCs)
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. [STANDARDS-TRACK]
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.
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 PC...