draft-ietf-imap-auth-01.txt   rfc1731.txt 
Network Working Group J. G. Myers Network Working Group J. Myers
Internet Draft: IMAP4 Authentication Mechanisms Carnegie Mellon Request for Comments: 1731 Carnegie Mellon
Document: internet-drafts/draft-ietf-imap-auth-01.txt June 1994 Category: Standards Track December 1994
IMAP4 Authentication mechanisms
Status of this memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress``.
To learn the current status of any Internet-Draft, please check the IMAP4 Authentication Mechanisms
1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or
munnari.oz.au.
This is a draft document of the IETF IMAP Working Group. It is a Status of this Memo
preliminary specification of several authentication mechanisms for
use by the AUTHENTICATE command of the IMAP4 protocol.
A revised version of this draft document will be submitted to the RFC This document specifies an Internet standards track protocol for the
editor as a Proposed Standard for the Internet Community. Discussion Internet community, and requests discussion and suggestions for
and suggestions for improvement are requested. This document will improvements. Please refer to the current edition of the "Internet
expire before 31 December 1994. Distribution of this draft is Official Protocol Standards" (STD 1) for the standardization state
unlimited. Comments are solicited and should be sent to and status of this protocol. Distribution of this memo is unlimited.
imap@CAC.Washington.EDU.
Introduction 1. Introduction
The Internet Message Access Protocol, Version 4 [IMAP4] contains the The Internet Message Access Protocol, Version 4 [IMAP4] contains the
AUTHENTICATE command, for identifying and authenticating a user to an AUTHENTICATE command, for identifying and authenticating a user to an
IMAP4 server and for optionally negotiating a protection mechanism IMAP4 server and for optionally negotiating a protection mechanism
for subsequent protocol interactions. This document describes for subsequent protocol interactions. This document describes
several authentication mechanisms for use by the IMAP4 AUTHENTICATE several authentication mechanisms for use by the IMAP4 AUTHENTICATE
command. command.
Kerberos version 4 authentication mechanism 2. Kerberos version 4 authentication mechanism
The authentication type associated with Kerberos version 4 is The authentication type associated with Kerberos version 4 is
``KERBEROS_V4''. "KERBEROS_V4".
The data encoded in the first ready response contains a random 32-bit The data encoded in the first ready response contains a random 32-bit
number in network byte order. The client should respond with a number in network byte order. The client should respond with a
Kerberos ticket and an authenticator for the principal Kerberos ticket and an authenticator for the principal
"imap.hostname@realm", where "hostname" is the first component of the "imap.hostname@realm", where "hostname" is the first component of the
host name of the server with all letters in lower case and where host name of the server with all letters in lower case and where
"realm" is the Kerberos realm of the server. The encrypted checksum "realm" is the Kerberos realm of the server. The encrypted checksum
field included within the Kerberos authenticator should contain the field included within the Kerberos authenticator should contain the
server provided 32-bit number in network byte order. server provided 32-bit number in network byte order.
skipping to change at page 3, line 22 skipping to change at page 3, line 4
S: * OK IMAP4 Server S: * OK IMAP4 Server
C: A001 AUTHENTICATE KERBEROS_V4 C: A001 AUTHENTICATE KERBEROS_V4
S: + AmFYig== S: + AmFYig==
C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
+nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
S: + or//EoAADZI= S: + or//EoAADZI=
C: DiAF5A4gA+oOIALuBkAAmw== C: DiAF5A4gA+oOIALuBkAAmw==
S: A001 OK Kerberos V4 authentication successful S: A001 OK Kerberos V4 authentication successful
S: * OK IMAP4 Server S: * OK IMAP4 Server
C: A001 AUTHENTICATE KERBEROS_V4 C: A001 AUTHENTICATE KERBEROS_V4
S: + gcfgCA== S: + gcfgCA==
C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
+nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
S: A001 NO Kerberos V4 authentication failed S: A001 NO Kerberos V4 authentication failed
GSSAPI authentication mechanism 3. GSSAPI authentication mechanism
The authentication type associated with all mechanisms employing the The authentication type associated with all mechanisms employing the
GSSAPI [RFC1508] is ``GSSAPI''. GSSAPI [RFC1508] is "GSSAPI".
The first ready response issued by the server contains no data. The The first ready response issued by the server contains no data. The
client should call GSS_Init_sec_context, passing in 0 for client should call GSS_Init_sec_context, passing in 0 for
input_context_handle (initially) and a targ_name equal to output_name input_context_handle (initially) and a targ_name equal to output_name
from GSS_Import_Name called with input_name_type of NULL and from GSS_Import_Name called with input_name_type of NULL and
input_name_string of "SERVICE:imap@hostname" where "hostname" is the input_name_string of "SERVICE:imap@hostname" where "hostname" is the
fully qualified host name of the server with all letters in lower fully qualified host name of the server with all letters in lower
case. The client must then respond with the resulting output_token. case. The client must then respond with the resulting output_token.
If GSS_Init_sec_context returns GSS_CONTINUE_NEEDED, then the client If GSS_Init_sec_context returns GSS_CONTINUE_NEEDED, then the client
should expect the server to issue a token in a subsequent ready should expect the server to issue a token in a subsequent ready
skipping to change at page 5, line 4 skipping to change at page 4, line 31
second through fourth octets as the maximum size output_message to second through fourth octets as the maximum size output_message to
send to the client, and the remaining octets as the user name. Upon send to the client, and the remaining octets as the user name. Upon
verifying the src_name is authorized to authenticate as the user verifying the src_name is authorized to authenticate as the user
name, The server should then consider the client authenticated. name, The server should then consider the client authenticated.
The protection mechanisms and their corresponding bit-masks are as The protection mechanisms and their corresponding bit-masks are as
follows: follows:
1 No protection mechanism 1 No protection mechanism
2 Integrity protection. 2 Integrity protection.
Sender calls GSS_Seal with conf_flag set to FALSE Sender calls GSS_Seal with conf_flag set to FALSE
4 Privacy protection. 4 Privacy protection.
Sender calls GSS_Seal with conf_flag set to TRUE Sender calls GSS_Seal with conf_flag set to TRUE
S/Key authentication mechanism 4. S/Key authentication mechanism
The authentication type associated with S/Key [SKEY] is ``SKEY''. The authentication type associated with S/Key [SKEY] is "SKEY".
The first ready response issued by the server contains no data. The The first ready response issued by the server contains no data. The
client responds with the user name string. client responds with the user name string.
The data encoded in the second ready response contains the decimal The data encoded in the second ready response contains the decimal
sequence number followed by a single space and the seed string for sequence number followed by a single space and the seed string for
the indicated user. The client responds with the one-time-password, 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 as either a 64-bit value in network byte order or encoded in the "six
English words" format. English words" format.
skipping to change at page 6, line 5 skipping to change at page 5, line 25
S: A001 OK S/Key authentication successful S: A001 OK S/Key authentication successful
S: * OK IMAP4 Server S: * OK IMAP4 Server
C: A001 AUTHENTICATE SKEY C: A001 AUTHENTICATE SKEY
S: + S: +
C: c21pdGg= C: c21pdGg=
S: + OTUgUWE1ODMwOA== S: + OTUgUWE1ODMwOA==
C: BsAY3g4gBNo= C: BsAY3g4gBNo=
S: A001 NO S/Key authentication failed S: A001 NO S/Key authentication failed
References 5. References
[IMAP4] Crispin, Mark R., "Internet Message Access Protocol - [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4",
Version 4", Work in Progress of the IETF IMAP WG, draft-ietf-imap- RFC 1730, University of Washington, December 1994.
imap4-??.txt. Check Internet Drafts listing for latest version.
[RFC1508] Linn, John, "Generic Security Service Application Program [RFC1508] Linn, J., "Generic Security Service Application Program
Interface", RFC 1508. Interface", RFC 1508, Geer Zolot Associates, September 1993.
[SKEY] Haller, Neil M. "The S/Key One-Time Password System", [SKEY] Haller, Neil M. "The S/Key One-Time Password System",
Bellcore, Morristown, New Jersey, October 1993, Bellcore, Morristown, New Jersey, October 1993,
thumper.bellcore.com:pub/nmh/docs/ISOC.symp.ps thumper.bellcore.com:pub/nmh/docs/ISOC.symp.ps
Security Considerations 6. Security Considerations
Security issues are discussed throughout this memo. Security issues are discussed throughout this memo.
Author's Address 7. Author's Address
John G. Myers John G. Myers
Carnegie-Mellon University Carnegie-Mellon University
5000 Forbes Ave. 5000 Forbes Ave.
Pittsburgh PA, 15213-3890 Pittsburgh PA, 15213-3890
Email: jgm+@cmu.edu EMail: jgm+@cmu.edu
This document will expire before December 25, 1994.
 End of changes. 19 change blocks. 
48 lines changed or deleted 24 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/