Browse Prior Art Database

IMAP4 Authentication Mechanisms (RFC1731)

IP.com Disclosure Number: IPCOM000003980D
Original Publication Date: 1994-Dec-01
Included in the Prior Art Database: 2000-Sep-12
Document File: 5 page(s) / 11K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

J. Myers: AUTHOR

Abstract

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.

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 26% of the total text.

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 ...