RFC 1731 (rfc1731) - Page 1 of 6


IMAP4 Authentication Mechanisms



Alternative Format: Original Text Document

Next >


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


Next >


Web Standards & Support:

Link to and support eLook.org Powered by LoadedWeb Web Hosting
Valid XHTML 1.0! Valid CSS! eLook.org FireFox Extensions