IMAP4 Authentication Mechanisms
RFC 1731

Document Type RFC - Proposed Standard (December 1994; No errata)
Last updated 2015-10-14
Stream IETF
Formats plain text pdf html bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
This information refers to IESG processing after the RFC was initially published:
IESG IESG state RFC 1731 (Proposed Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD Chris Newman
IESG note Waiting for 2195 to go historic, but looks like that won't happen.
Send notices to (None)
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

2. Kerberos version 4 authentication mechanism

   The authentication type associated with Kerberos version 4 is

   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

      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
      S: + AmFYig==
      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
      S: + gcfgCA==
Show full document text