Skip to content

John McEleney / mailutils

Go to a project
Toggle navigation
Toggle navigation pinning
Commit 4ae57543 4ae57543b36b5a104eee1e3a7e666d6c4522f221 by Sam Roberts
Options

added SASL rfcs and registry

1 parent b9d20048
Inline Side-by-side
Showing 7 changed files with 4668 additions and 0 deletions
Network Working Group J. Klensin
Request for Comments: 2195 R. Catoe
Category: Standards Track P. Krumviede
Obsoletes: 2095 MCI
September 1997
IMAP/POP AUTHorize Extension for Simple Challenge/Response
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.
Abstract
While IMAP4 supports a number of strong authentication mechanisms as
described in RFC 1731, it lacks any mechanism that neither passes
cleartext, reusable passwords across the network nor requires either
a significant security infrastructure or that the mail server update
a mail-system-wide user authentication file on each mail access.
This specification provides a simple challenge-response
authentication protocol that is suitable for use with IMAP4. Since
it utilizes Keyed-MD5 digests and does not require that the secret be
stored in the clear on the server, it may also constitute an
improvement on APOP for POP3 use as specified in RFC 1734.
1. Introduction
Existing Proposed Standards specify an AUTHENTICATE mechanism for the
IMAP4 protocol [IMAP, IMAP-AUTH] and a parallel AUTH mechanism for
the POP3 protocol [POP3-AUTH]. The AUTHENTICATE mechanism is
intended to be extensible; the four methods specified in [IMAP-AUTH]
are all fairly powerful and require some security infrastructure to
support. The base POP3 specification [POP3] also contains a
lightweight challenge-response mechanism called APOP. APOP is
associated with most of the risks associated with such protocols: in
particular, it requires that both the client and server machines have
access to the shared secret in cleartext form. CRAM offers a method
for avoiding such cleartext storage while retaining the algorithmic
simplicity of APOP in using only MD5, though in a "keyed" method.
Klensin, Catoe & Krumviede Standards Track [Page 1]
RFC 2195 IMAP/POP AUTHorize Extension September 1997
At present, IMAP [IMAP] lacks any facility corresponding to APOP.
The only alternative to the strong mechanisms identified in [IMAP-
AUTH] is a presumably cleartext username and password, supported
through the LOGIN command in [IMAP]. This document describes a
simple challenge-response mechanism, similar to APOP and PPP CHAP
[PPP], that can be used with IMAP (and, in principle, with POP3).
This mechanism also has the advantage over some possible alternatives
of not requiring that the server maintain information about email
"logins" on a per-login basis. While mechanisms that do require such
per-login history records may offer enhanced security, protocols such
as IMAP, which may have several connections between a given client
and server open more or less simultaneous, may make their
implementation particularly challenging.
2. Challenge-Response Authentication Mechanism (CRAM)
The authentication type associated with CRAM is "CRAM-MD5".
The data encoded in the first ready response contains an
presumptively arbitrary string of random digits, a timestamp, and the
fully-qualified primary host name of the server. The syntax of the
unencoded form must correspond to that of an RFC 822 'msg-id'
[RFC822] as described in [POP3].
The client makes note of the data and then responds with a string
consisting of the user name, a space, and a 'digest'. The latter is
computed by applying the keyed MD5 algorithm from [KEYED-MD5] where
the key is a shared secret and the digested text is the timestamp
(including angle-brackets).
This shared secret is a string known only to the client and server.
The `digest' parameter itself is a 16-octet value which is sent in
hexadecimal format, using lower-case ASCII characters.
When the server receives this client response, it verifies the digest
provided. If the digest is correct, the server should consider the
client authenticated and respond appropriately.
Keyed MD5 is chosen for this application because of the greater
security imparted to authentication of short messages. In addition,
the use of the techniques described in [KEYED-MD5] for precomputation
of intermediate results make it possible to avoid explicit cleartext
storage of the shared secret on the server system by instead storing
the intermediate results which are known as "contexts".
Klensin, Catoe & Krumviede Standards Track [Page 2]
RFC 2195 IMAP/POP AUTHorize Extension September 1997
CRAM does not support a protection mechanism.
Example:
The examples in this document show the use of the CRAM mechanism with
the IMAP4 AUTHENTICATE command [IMAP-AUTH]. The base64 encoding of
the challenges and responses is part of the IMAP4 AUTHENTICATE
command, not part of the CRAM specification itself.
S: * OK IMAP4 Server
C: A0001 AUTHENTICATE CRAM-MD5
S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+
C: dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw
S: A0001 OK CRAM authentication successful
In this example, the shared secret is the string
'tanstaaftanstaaf'. Hence, the Keyed MD5 digest is produced by
calculating
MD5((tanstaaftanstaaf XOR opad),
MD5((tanstaaftanstaaf XOR ipad),
<1896.697170952@postoffice.reston.mci.net>))
where ipad and opad are as defined in the keyed-MD5 Work in
Progress [KEYED-MD5] and the string shown in the challenge is the
base64 encoding of <1896.697170952@postoffice.reston.mci.net>. The
shared secret is null-padded to a length of 64 bytes. If the
shared secret is longer than 64 bytes, the MD5 digest of the
shared secret is used as a 16 byte input to the keyed MD5
calculation.
This produces a digest value (in hexadecimal) of
b913a602c7eda7a495b4e6e7334d3890
The user name is then prepended to it, forming
tim b913a602c7eda7a495b4e6e7334d3890
Which is then base64 encoded to meet the requirements of the IMAP4
AUTHENTICATE command (or the similar POP3 AUTH command), yielding
dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw
Klensin, Catoe & Krumviede Standards Track [Page 3]
RFC 2195 IMAP/POP AUTHorize Extension September 1997
3. References
[CHAP] Lloyd, B., and W. Simpson, "PPP Authentication Protocols",
RFC 1334, October 1992.
[IMAP] Crispin, M., "Internet Message Access Protocol - Version
4rev1", RFC 2060, University of Washington, December 1996.
[IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanisms",
RFC 1731, Carnegie Mellon, December 1994.
[KEYED-MD5] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for
Message Authentication", RFC 2104, February 1997.
[MD5] Rivest, R., "The MD5 Message Digest Algorithm",
RFC 1321, MIT Laboratory for Computer Science, April 1992.
[POP3] Myers, J., and M. Rose, "Post Office Protocol - Version 3",
STD 53, RFC 1939, Carnegie Mellon, May 1996.
[POP3-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734,
Carnegie Mellon, December, 1994.
4. Security Considerations
It is conjectured that use of the CRAM authentication mechanism
provides origin identification and replay protection for a session.
Accordingly, a server that implements both a cleartext password
command and this authentication type should not allow both methods of
access for a given user.
While the saving, on the server, of "contexts" (see section 2) is
marginally better than saving the shared secrets in cleartext as is
required by CHAP [CHAP] and APOP [POP3], it is not sufficient to
protect the secrets if the server itself is compromised.
Consequently, servers that store the secrets or contexts must both be
protected to a level appropriate to the potential information value
in user mailboxes and identities.
As the length of the shared secret increases, so does the difficulty
of deriving it.
While there are now suggestions in the literature that the use of MD5
and keyed MD5 in authentication procedures probably has a limited
effective lifetime, the technique is now widely deployed and widely
understood. It is believed that this general understanding may
assist with the rapid replacement, by CRAM-MD5, of the current uses
of permanent cleartext passwords in IMAP. This document has been
Klensin, Catoe & Krumviede Standards Track [Page 4]
RFC 2195 IMAP/POP AUTHorize Extension September 1997
deliberately written to permit easy upgrading to use SHA (or whatever
alternatives emerge) when they are considered to be widely available
and adequately safe.
Even with the use of CRAM, users are still vulnerable to active
attacks. An example of an increasingly common active attack is 'TCP
Session Hijacking' as described in CERT Advisory CA-95:01 [CERT95].
See section 1 above for additional discussion.
5. Acknowledgements
This memo borrows ideas and some text liberally from [POP3] and
[RFC-1731] and thanks are due the authors of those documents. Ran
Atkinson made a number of valuable technical and editorial
contributions to the document.
6. Authors' Addresses
John C. Klensin
MCI Telecommunications
800 Boylston St, 7th floor
Boston, MA 02199
USA
EMail: klensin@mci.net
Phone: +1 617 960 1011
Randy Catoe
MCI Telecommunications
2100 Reston Parkway
Reston, VA 22091
USA
EMail: randy@mci.net
Phone: +1 703 715 7366
Paul Krumviede
MCI Telecommunications
2100 Reston Parkway
Reston, VA 22091
USA
EMail: paul@mci.net
Phone: +1 703 715 7251
Klensin, Catoe & Krumviede Standards Track [Page 5]
Network Working Group J. Myers
Request for Comments: 2222 Netscape Communications
Category: Standards Track October 1997
Simple Authentication and Security Layer (SASL)
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.
Copyright Notice
Copyright (C) The Internet Society (1997). All Rights Reserved.
Table of Contents
1. Abstract .............................................. 2
2. Organization of this Document ......................... 2
2.1. How to Read This Document ............................. 2
2.2. Conventions Used in this Document ..................... 2
2.3. Examples .............................................. 3
3. Introduction and Overview ............................. 3
4. Profiling requirements ................................ 4
5. Specific issues ....................................... 5
5.1. Client sends data first ............................... 5
5.2. Server returns success with additional data ........... 5
5.3. Multiple authentications .............................. 5
6. Registration procedures ............................... 6
6.1. Comments on SASL mechanism registrations .............. 6
6.2. Location of Registered SASL Mechanism List ............ 6
6.3. Change Control ........................................ 7
6.4. Registration Template ................................. 7
7. Mechanism definitions ................................. 8
7.1. Kerberos version 4 mechanism .......................... 8
7.2. GSSAPI mechanism ...................................... 9
7.2.1 Client side of authentication protocol exchange ....... 9
7.2.2 Server side of authentication protocol exchange ....... 10
7.2.3 Security layer ........................................ 11
7.3. S/Key mechanism ....................................... 11
7.4. External mechanism .................................... 12
8. References ............................................ 13
9. Security Considerations ............................... 13
10. Author's Address ...................................... 14
Myers Standards Track [Page 1]
RFC 2222 SASL October 1997
Appendix A. Relation of SASL to Transport Security .......... 15
Full Copyright Statement .................................... 16
1. Abstract
This document describes a method for adding authentication support to
connection-based protocols. To use this specification, a protocol
includes a command for identifying and authenticating a user to a
server and for optionally negotiating protection of subsequent
protocol interactions. If its use is negotiated, a security layer is
inserted between the protocol and the connection. This document
describes how a protocol specifies such a command, defines several
mechanisms for use by the command, and defines the protocol used for
carrying a negotiated security layer over the connection.
2. Organization of this Document
2.1. How to Read This Document
This document is written to serve two different audiences, protocol
designers using this specification to support authentication in their
protocol, and implementors of clients or servers for those protocols
using this specification.
The sections "Introduction and Overview", "Profiling requirements",
and "Security Considerations" cover issues that protocol designers
need to understand and address in profiling this specification for
use in a specific protocol.
Implementors of a protocol using this specification need the
protocol-specific profiling information in addition to the
information in this document.
2.2. Conventions Used in this Document
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
in this document are to be interpreted as defined in "Key words for
use in RFCs to Indicate Requirement Levels" [RFC 2119].
Myers Standards Track [Page 2]
RFC 2222 SASL October 1997
2.3. Examples
Examples in this document are for the IMAP profile [RFC 2060] of this
specification. The base64 encoding of challenges and responses, as
well as the "+ " preceding the responses are part of the IMAP4
profile, not part of the SASL specification itself.
3. Introduction and Overview
The Simple Authentication and Security Layer (SASL) is a method for
adding authentication support to connection-based protocols. To use
this specification, a protocol includes a command for identifying and
authenticating a user to a server and for optionally negotiating a
security layer for subsequent protocol interactions.
The command has a required argument identifying a SASL mechanism.
SASL mechanisms are named by strings, from 1 to 20 characters in
length, consisting of upper-case letters, digits, hyphens, and/or
underscores. SASL mechanism names must be registered with the IANA.
Procedures for registering new SASL mechanisms are given in the
section "Registration procedures"
If a server supports the requested mechanism, it initiates an
authentication protocol exchange. This consists of a series of
server challenges and client responses that are specific to the
requested mechanism. The challenges and responses are defined by the
mechanisms as binary tokens of arbitrary length. The protocol's
profile then specifies how these binary tokens are then encoded for
transfer over the connection.
After receiving the authentication command or any client response, a
server may issue a challenge, indicate failure, or indicate
completion. The protocol's profile specifies how the server
indicates which of the above it is doing.
After receiving a challenge, a client may issue a response or abort
the exchange. The protocol's profile specifies how the client
indicates which of the above it is doing.
During the authentication protocol exchange, the mechanism performs
authentication, transmits an authorization identity (frequently known
as a userid) from the client to server, and negotiates the use of a
mechanism-specific security layer. If the use of a security layer is
agreed upon, then the mechanism must also define or negotiate the
maximum cipher-text buffer size that each side is able to receive.
Myers Standards Track [Page 3]
RFC 2222 SASL October 1997
The transmitted authorization identity may be different than the
identity in the client's authentication credentials. This permits
agents such as proxy servers to authenticate using their own
credentials, yet request the access privileges of the identity for
which they are proxying. With any mechanism, transmitting an
authorization identity of the empty string directs the server to
derive an authorization identity from the client's authentication
credentials.
If use of a security layer is negotiated, it is applied to all
subsequent data sent over the connection. The security layer takes
effect immediately following the last response of the authentication
exchange for data sent by the client and the completion indication
for data sent by the server. Once the security layer is in effect,
the protocol stream is processed by the security layer into buffers
of cipher-text. Each buffer is transferred over the connection as a
stream of octets prepended with a four octet field in network byte
order that represents the length of the following buffer. The length
of the cipher-text buffer must be no larger than the maximum size
that was defined or negotiated by the other side.
4. Profiling requirements
In order to use this specification, a protocol definition must supply
the following information:
1. A service name, to be selected from the IANA registry of "service"
elements for the GSSAPI host-based service name form [RFC 2078].
2. A definition of the command to initiate the authentication
protocol exchange. This command must have as a parameter the
mechanism name being selected by the client.
The command SHOULD have an optional parameter giving an initial
response. This optional parameter allows the client to avoid a
round trip when using a mechanism which is defined to have the
client send data first. When this initial response is sent by the
client and the selected mechanism is defined to have the server
start with an initial challenge, the command fails. See section
5.1 of this document for further information.
3. A definition of the method by which the authentication protocol
exchange is carried out, including how the challenges and
responses are encoded, how the server indicates completion or
failure of the exchange, how the client aborts an exchange, and
how the exchange method interacts with any line length limits in
the protocol.
Myers Standards Track [Page 4]
RFC 2222 SASL October 1997
4. Identification of the octet where any negotiated security layer
starts to take effect, in both directions.
5. A specification of how the authorization identity passed from the
client to the server is to be interpreted.
5. Specific issues
5.1. Client sends data first
Some mechanisms specify that the first data sent in the
authentication protocol exchange is from the client to the server.
If a protocol's profile permits the command which initiates an
authentication protocol exchange to contain an initial client
response, this parameter SHOULD be used with such mechanisms.
If the initial client response parameter is not given, or if a
protocol's profile does not permit the command which initiates an
authentication protocol exchange to contain an initial client
response, then the server issues a challenge with no data. The
client's response to this challenge is then used as the initial
client response. (The server then proceeds to send the next
challenge, indicates completion, or indicates failure.)
5.2. Server returns success with additional data
Some mechanisms may specify that server challenge data be sent to the
client along with an indication of successful completion of the
exchange. This data would, for example, authenticate the server to
the client.
If a protocol's profile does not permit this server challenge to be
returned with a success indication, then the server issues the server
challenge without an indication of successful completion. The client
then responds with no data. After receiving this empty response, the
server then indicates successful completion.
5.3. Multiple authentications
Unless otherwise stated by the protocol's profile, only one
successful SASL negotiation may occur in a protocol session. In this
case, once an authentication protocol exchange has successfully
completed, further attempts to initiate an authentication protocol
exchange fail.
Myers Standards Track [Page 5]
RFC 2222 SASL October 1997
In the case that a profile explicitly permits multiple successful
SASL negotiations to occur, then in no case may multiple security
layers be simultaneously in effect. If a security layer is in effect
and a subsequent SASL negotiation selects no security layer, the
original security layer remains in effect. If a security layer is in
effect and a subsequent SASL negotiation selects a second security
layer, then the second security layer replaces the first.
6. Registration procedures
Registration of a SASL mechanism is done by filling in the template
in section 6.4 and sending it in to iana@isi.edu. IANA has the right
to reject obviously bogus registrations, but will perform no review
of clams made in the registration form.
There is no naming convention for SASL mechanisms; any name that
conforms to the syntax of a SASL mechanism name can be registered.
While the registration procedures do not require it, authors of SASL
mechanisms are encouraged to seek community review and comment
whenever that is feasible. Authors may seek community review by
posting a specification of their proposed mechanism as an internet-
draft. SASL mechanisms intended for widespread use should be
standardized through the normal IETF process, when appropriate.
6.1. Comments on SASL mechanism registrations
Comments on registered SASL mechanisms should first be sent to the
"owner" of the mechanism. Submitters of comments may, after a
reasonable attempt to contact the owner, request IANA to attach their
comment to the SASL mechanism registration itself. If IANA approves
of this the comment will be made accessible in conjunction with the
SASL mechanism registration itself.
6.2. Location of Registered SASL Mechanism List
SASL mechanism registrations will be posted in the anonymous FTP
directory "ftp://ftp.isi.edu/in-notes/iana/assignments/sasl-
mechanisms/" and all registered SASL mechanisms will be listed in the
periodically issued "Assigned Numbers" RFC [currently STD 2, RFC
1700]. The SASL mechanism description and other supporting material
may also be published as an Informational RFC by sending it to "rfc-
editor@isi.edu" (please follow the instructions to RFC authors [RFC
2223]).
Myers Standards Track [Page 6]
RFC 2222 SASL October 1997
6.3. Change Control
Once a SASL mechanism registration has been published by IANA, the
author may request a change to its definition. The change request
follows the same procedure as the registration request.
The owner of a SASL mechanism may pass responsibility for the SASL
mechanism to another person or agency by informing IANA; this can be
done without discussion or review.
The IESG may reassign responsibility for a SASL mechanism. The most
common case of this will be to enable changes to be made to
mechanisms where the author of the registration has died, moved out
of contact or is otherwise unable to make changes that are important
to the community.
SASL mechanism registrations may not be deleted; mechanisms which are
no longer believed appropriate for use can be declared OBSOLETE by a
change to their "intended use" field; such SASL mechanisms will be
clearly marked in the lists published by IANA.
The IESG is considered to be the owner of all SASL mechanisms which
are on the IETF standards track.
6.4. Registration Template
To: iana@iana.org
Subject: Registration of SASL mechanism X
SASL mechanism name:
Security considerations:
Published specification (optional, recommended):
Person & email address to contact for further information:
Intended usage:
(One of COMMON, LIMITED USE or OBSOLETE)
Author/Change controller:
(Any other information that the author deems interesting may be
added below this line.)
Myers Standards Track [Page 7]
RFC 2222 SASL October 1997
7. Mechanism definitions
The following mechanisms are hereby defined.
7.1. Kerberos version 4 mechanism
The mechanism name associated with Kerberos version 4 is
"KERBEROS_V4".
The first challenge consists of a random 32-bit number in network
byte order. The client responds with a Kerberos ticket and an
authenticator for the principal "service.hostname@realm", where
"service" is the service name specified in the protocol's profile,
"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 contains the server provided challenge in
network byte order.
Upon decrypting and verifying the ticket and authenticator, the
server verifies 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 security layers 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 using DES ECB mode the 8 octets of data in the session
key and issue that encrypted data in a second challenge. The client
considers the server authenticated if the first four octets of 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 security layer,
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 the authorization identity. The
client must then append from one to eight zero-valued octets so that
the length of the data is a multiple of eight octets. The client must
then encrypt using DES PCBC mode the data with the session key and
respond with the encrypted data. The server decrypts the data and
verifies the contained checksum. The server must verify that the
principal identified in the Kerberos ticket is authorized to connect
as that authorization identity. After this verification, the
authentication process is complete.
Myers Standards Track [Page 8]
RFC 2222 SASL October 1997
The security layers and their corresponding bit-masks are as follows:
1 No security layer
2 Integrity (krb_mk_safe) protection
4 Privacy (krb_mk_priv) protection
Other bit-masks may be defined in the future; bits which are not
understood must be negotiated off.
EXAMPLE: The following are two Kerberos version 4 login scenarios to
the IMAP4 protocol (note that the line breaks in the sample
authenticators are for editorial clarity and are not in real
authenticators)
S: * OK IMAP4 Server
C: A001 AUTHENTICATE KERBEROS_V4
S: + AmFYig==
C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
+nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
S: + or//EoAADZI=
C: DiAF5A4gA+oOIALuBkAAmw==
S: A001 OK Kerberos V4 authentication successful
S: * OK IMAP4 Server
C: A001 AUTHENTICATE KERBEROS_V4
S: + gcfgCA==
C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
+nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
S: A001 NO Kerberos V4 authentication failed
7.2. GSSAPI mechanism
The mechanism name associated with all mechanisms employing the
GSSAPI [RFC 2078] is "GSSAPI".
7.2.1 Client side of authentication protocol exchange
The client calls GSS_Init_sec_context, passing in 0 for
input_context_handle (initially) and a targ_name equal to output_name
from GSS_Import_Name called with input_name_type of
GSS_C_NT_HOSTBASED_SERVICE and input_name_string of
"service@hostname" where "service" is the service name specified in
the protocol's profile, and "hostname" is the fully qualified host
name of the server. The client then responds with the resulting
output_token. If GSS_Init_sec_context returns GSS_S_CONTINUE_NEEDED,
Myers Standards Track [Page 9]
RFC 2222 SASL October 1997
then the client should expect the server to issue a token in a
subsequent challenge. The client must pass the token to another call
to GSS_Init_sec_context, repeating the actions in this paragraph.
When GSS_Init_sec_context returns GSS_S_COMPLETE, the client takes
the following actions: If the last call to GSS_Init_sec_context
returned an output_token, then the client responds with the
output_token, otherwise the client responds with no data. The client
should then expect the server to issue a token in a subsequent
challenge. The client passes this token to GSS_Unwrap and interprets
the first octet of resulting cleartext as a bit-mask specifying the
security layers supported by the server and the second through fourth
octets as the maximum size output_message to send to the server. The
client then constructs data, with the first octet containing the
bit-mask specifying the selected security layer, the second through
fourth octets containing in network byte order the maximum size
output_message the client is able to receive, and the remaining
octets containing the authorization identity. The client passes the
data to GSS_Wrap with conf_flag set to FALSE, and responds with the
generated output_message. The client can then consider the server
authenticated.
7.2.2 Server side of authentication protocol exchange
The server passes the initial client response to
GSS_Accept_sec_context as input_token, setting input_context_handle
to 0 (initially). If GSS_Accept_sec_context returns
GSS_S_CONTINUE_NEEDED, the server returns the generated output_token
to the client in challenge and passes the resulting response to
another call to GSS_Accept_sec_context, repeating the actions in this
paragraph.
When GSS_Accept_sec_context returns GSS_S_COMPLETE, the client takes
the following actions: If the last call to GSS_Accept_sec_context
returned an output_token, the server returns it to the client in a
challenge and expects a reply from the client with no data. Whether
or not an output_token was returned (and after receipt of any
response from the client to such an output_token), the server then
constructs 4 octets of data, with the first octet containing a bit-
mask specifying the security layers supported by the server and the
second through fourth octets containing in network byte order the
maximum size output_token the server is able to receive. The server
must then pass the plaintext to GSS_Wrap with conf_flag set to FALSE
and issue the generated output_message to the client in a challenge.
The server must then pass the resulting response to GSS_Unwrap and
interpret the first octet of resulting cleartext as the bit-mask for
the selected security layer, the second through fourth octets as the
maximum size output_message to send to the client, and the remaining
Myers Standards Track [Page 10]
RFC 2222 SASL October 1997
octets as the authorization identity. The server must verify that
the src_name is authorized to authenticate as the authorization
identity. After these verifications, the authentication process is
complete.
7.2.3 Security layer
The security layers and their corresponding bit-masks are as follows:
1 No security layer
2 Integrity protection.
Sender calls GSS_Wrap with conf_flag set to FALSE
4 Privacy protection.
Sender calls GSS_Wrap with conf_flag set to TRUE
Other bit-masks may be defined in the future; bits which are not
understood must be negotiated off.
7.3. S/Key mechanism
The mechanism name associated with S/Key [RFC 1760] using the MD4
digest algorithm is "SKEY".
The client sends an initial response with the authorization identity.
The server then issues a challenge which contains the decimal
sequence number followed by a single space and the seed string for
the indicated authorization identity. The client responds with the
one-time-password, as either a 64-bit value in network byte order or
encoded in the "six English words" format.
The server must verify the one-time-password. After this
verification, the authentication process is complete.
S/Key authentication does not provide for any security layers.
EXAMPLE: The following are two S/Key login scenarios in the IMAP4
protocol.
S: * OK IMAP4 Server
C: A001 AUTHENTICATE SKEY
S: +
C: bW9yZ2Fu
S: + OTUgUWE1ODMwOA==
C: Rk9VUiBNQU5OIFNPT04gRklSIFZBUlkgTUFTSA==
S: A001 OK S/Key authentication successful
Myers Standards Track [Page 11]
RFC 2222 SASL October 1997
S: * OK IMAP4 Server
C: A001 AUTHENTICATE SKEY
S: +
C: c21pdGg=
S: + OTUgUWE1ODMwOA==
C: BsAY3g4gBNo=
S: A001 NO S/Key authentication failed
The following is an S/Key login scenario in an IMAP4-like protocol
which has an optional "initial response" argument to the AUTHENTICATE
command.
S: * OK IMAP4-Like Server
C: A001 AUTHENTICATE SKEY bW9yZ2Fu
S: + OTUgUWE1ODMwOA==
C: Rk9VUiBNQU5OIFNPT04gRklSIFZBUlkgTUFTSA==
S: A001 OK S/Key authentication successful
7.4. External mechanism
The mechanism name associated with external authentication is
"EXTERNAL".
The client sends an initial response with the authorization identity.
The server uses information, external to SASL, to determine whether
the client is authorized to authenticate as the authorization
identity. If the client is so authorized, the server indicates
successful completion of the authentication exchange; otherwise the
server indicates failure.
The system providing this external information may be, for example,
IPsec or TLS.
If the client sends the empty string as the authorization identity
(thus requesting the authorization identity be derived from the
client's authentication credentials), the authorization identity is
to be derived from authentication credentials which exist in the
system which is providing the external authentication.
Myers Standards Track [Page 12]
RFC 2222 SASL October 1997
8. References
[RFC 2060] Crispin, M., "Internet Message Access Protocol - Version
4rev1", RFC 2060, December 1996.
[RFC 2078] Linn, J., "Generic Security Service Application Program
Interface, Version 2", RFC 2078, January 1997.
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC 2223] Postel, J., and J. Reynolds, "Instructions to RFC
Authors", RFC 2223, October 1997.
[RFC 1760] Haller, N., "The S/Key One-Time Password System", RFC
1760, February 1995.
[RFC 1700] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
RFC 1700, October 1994.
9. Security Considerations
Security issues are discussed throughout this memo.
The mechanisms that support integrity protection are designed such
that the negotiation of the security layer and authorization identity
is integrity protected. When the client selects a security layer
with at least integrity protection, this protects against an active
attacker hijacking the connection and modifying the authentication
exchange to negotiate a plaintext connection.
When a server or client supports multiple authentication mechanisms,
each of which has a different security strength, it is possible for
an active attacker to cause a party to use the least secure mechanism
supported. To protect against this sort of attack, a client or
server which supports mechanisms of different strengths should have a
configurable minimum strength that it will use. It is not sufficient
for this minimum strength check to only be on the server, since an
active attacker can change which mechanisms the client sees as being
supported, causing the client to send authentication credentials for
its weakest supported mechanism.
Myers Standards Track [Page 13]
RFC 2222 SASL October 1997
The client's selection of a SASL mechanism is done in the clear and
may be modified by an active attacker. It is important for any new
SASL mechanisms to be designed such that an active attacker cannot
obtain an authentication with weaker security properties by modifying
the SASL mechanism name and/or the challenges and responses.
Any protocol interactions prior to authentication are performed in
the clear and may be modified by an active attacker. In the case
where a client selects integrity protection, it is important that any
security-sensitive protocol negotiations be performed after
authentication is complete. Protocols should be designed such that
negotiations performed prior to authentication should be either
ignored or revalidated once authentication is complete.
10. Author's Address
John G. Myers
Netscape Communications
501 E. Middlefield Road
Mail Stop MV-029
Mountain View, CA 94043-4042
EMail: jgmyers@netscape.com
Myers Standards Track [Page 14]
RFC 2222 SASL October 1997
Appendix A. Relation of SASL to Transport Security
Questions have been raised about the relationship between SASL and
various services (such as IPsec and TLS) which provide a secured
connection.
Two of the key features of SASL are:
1. The separation of the authorization identity from the identity in
the client's credentials. This permits agents such as proxy
servers to authenticate using their own credentials, yet request
the access privileges of the identity for which they are proxying.
2. Upon successful completion of an authentication exchange, the
server knows the authorization identity the client wishes to use.
This allows servers to move to a "user is authenticated" state in
the protocol.
These features are extremely important to some application protocols,
yet Transport Security services do not always provide them. To
define SASL mechanisms based on these services would be a very messy
task, as the framing of these services would be redundant with the
framing of SASL and some method of providing these important SASL
features would have to be devised.
Sometimes it is desired to enable within an existing connection the
use of a security service which does not fit the SASL model. (TLS is
an example of such a service.) This can be done by adding a command,
for example "STARTTLS", to the protocol. Such a command is outside
the scope of SASL, and should be different from the command which
starts a SASL authentication protocol exchange.
In certain situations, it is reasonable to use SASL underneath one of
these Transport Security services. The transport service would
secure the connection, either service would authenticate the client,
and SASL would negotiate the authorization identity. The SASL
negotiation would be what moves the protocol from "unauthenticated"
to "authenticated" state. The "EXTERNAL" SASL mechanism is
explicitly intended to handle the case where the transport service
secures the connection and authenticates the client and SASL
negotiates the authorization identity.
When using SASL underneath a sufficiently strong Transport Security
service, a SASL security layer would most likely be redundant. The
client and server would thus probably want to negotiate off the use
of a SASL security layer.
Myers Standards Track [Page 15]
RFC 2222 SASL October 1997
Full Copyright Statement
Copyright (C) The Internet Society (1997). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published
andand distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Myers Standards Track [Page 16]
Network Working Group C. Newman
Request for Comments: 2444 Innosoft
Updates: 2222 October 1998
Category: Standards Track
The One-Time-Password SASL Mechanism
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.
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
Abstract
OTP [OTP] provides a useful authentication mechanism for situations
where there is limited client or server trust. Currently, OTP is
added to protocols in an ad-hoc fashion with heuristic parsing. This
specification defines an OTP SASL [SASL] mechanism so it can be
easily and formally integrated into many application protocols.
1. How to Read This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
"RECOMMENDED" and "MAY" in this document are to be interpreted as
defined in "Key words for use in RFCs to Indicate Requirement Levels"
[KEYWORDS].
This memo assumes the reader is familiar with OTP [OTP], OTP extended
responses [OTP-EXT] and SASL [SASL].
2. Intended Use
The OTP SASL mechanism replaces the SKEY SASL mechanism [SASL]. OTP
is a good choice for usage scenarios where the client is untrusted
(e.g., a kiosk client), as a one-time password will only give the
client a single opportunity to act on behalf of the user. OTP is
also a good choice for situations where interactive logins are
permitted to the server, as a compromised OTP authentication database
is only subject to dictionary attacks, unlike authentication
databases for other simple mechanisms such as CRAM-MD5 [CRAM-MD5].
Newman Standards Track [Page 1]
RFC 2444 OTP SASL Mechanism October 1998
It is important to note that each use of the OTP mechanism causes the
authentication database entry for a user to be updated.
This SASL mechanism provides a formal way to integrate OTP into
SASL-enabled protocols including IMAP [IMAP4], ACAP [ACAP], POP3
[POP-AUTH] and LDAPv3 [LDAPv3].
3. Profiling OTP for SASL
OTP [OTP] and OTP extended responses [OTP-EXT] offer a number of
options. However, for authentication to succeed, the client and
server need compatible option sets. This specification defines a
single SASL mechanism: OTP. The following rules apply to this
mechanism:
o The extended response syntax MUST be used.
o Servers MUST support the following four OTP extended responses:
"hex", "word", "init-hex" and "init-word". Servers MUST support
the "word" and "init-word" responses for the standard dictionary
and SHOULD support alternate dictionaries. Servers MUST NOT
require use of any additional OTP extensions or options.
o Clients SHOULD support display of the OTP challenge to the user
and entry of an OTP in multi-word format. Clients MAY also
support direct entry of the pass phrase and compute the "hex" or
"word" response.
o Clients MUST indicate when authentication fails due to the
sequence number getting too low and SHOULD offer the user the
option to reset the sequence using the "init-hex" or "init-word"
response.
Support for the MD5 algorithm is REQUIRED, and support for the SHA1
algorithm is RECOMMENDED.
4. OTP Authentication Mechanism
The mechanism does not provide any security layer.
The client begins by sending a message to the server containing the
following two pieces of information.
(1) An authorization identity. When the empty string is used, this
defaults to the authentication identity. This is used by system
administrators or proxy servers to login with a different user
identity. This field may be up to 255 octets and is terminated by a
NUL (0) octet. US-ASCII printable characters are preferred, although
Newman Standards Track [Page 2]
RFC 2444 OTP SASL Mechanism October 1998
UTF-8 [UTF-8] printable characters are permitted to support
international names. Use of character sets other than US-ASCII and
UTF-8 is forbidden.
(2) An authentication identity. The identity whose pass phrase will
be used. This field may be up to 255 octets. US-ASCII printable
characters are preferred, although UTF-8 [UTF-8] printable characters
are permitted to support international names. Use of character sets
other than US-ASCII and UTF-8 is forbidden.
The server responds by sending a message containing the OTP challenge
as described in OTP [OTP] and OTP extended responses [OTP-EXT].
If a client sees an unknown hash algorithm name it will not be able
to process a pass phrase input by the user. In this situation the
client MAY prompt for the six-word format, issue the cancel sequence
as specified by the SASL profile for the protocol in use and try a
different SASL mechanism, or close the connection and refuse to
authenticate. As a result of this behavior, a server is restricted
to one OTP hash algorithm per user.
On success, the client generates an extended response in the "hex",
"word", "init-hex" or "init-word" format. The client is not required
to terminate the response with a space or a newline and SHOULD NOT
include unnecessary whitespace.
Servers MUST tolerate input of arbitrary length, but MAY fail the
authentication if the length of client input exceeds reasonable size.
5. Examples
In these example, "C:" represents lines sent from the client to the
server and "S:" represents lines sent from the server to the client.
The user name is "tim" and no authorization identity is provided.
The "<NUL>" below represents an ASCII NUL octet.
The following is an example of the OTP mechanism using the ACAP
[ACAP] profile of SASL. The pass phrase used in this example is:
This is a test.
C: a001 AUTHENTICATE "OTP" {4}
C: <NUL>tim
S: + "otp-md5 499 ke1234 ext"
C: "hex:5bf075d9959d036f"
S: a001 OK "AUTHENTICATE completed"
Newman Standards Track [Page 3]
RFC 2444 OTP SASL Mechanism October 1998
Here is the same example using the six-words response:
C: a001 AUTHENTICATE "OTP" {4}
C: <NUL>tim
S: + "otp-md5 499 ke1234 ext"
C: "word:BOND FOGY DRAB NE RISE MART"
S: a001 OK "AUTHENTICATE completed"
Here is the same example using the OTP-SHA1 mechanism:
C: a001 AUTHENTICATE "OTP" {4}
C: <NUL>tim
S: + "otp-sha1 499 ke1234 ext"
C: "hex:c90fc02cc488df5e"
S: a001 OK "AUTHENTICATE completed"
Here is the same example with the init-hex extended response
C: a001 AUTHENTICATE "OTP" {4}
C: <NUL>tim
S: + "otp-md5 499 ke1234 ext"
C: "init-hex:5bf075d9959d036f:md5 499 ke1235:3712dcb4aa5316c1"
S: a001 OK "OTP sequence reset, authentication complete"
The following is an example of the OTP mechanism using the IMAP
[IMAP4] profile of SASL. The pass phrase used in this example is:
this is a test
C: a001 AUTHENTICATE OTP
S: +
C: AHRpbQ==
S: + b3RwLW1kNSAxMjMga2UxMjM0IGV4dA==
C: aGV4OjExZDRjMTQ3ZTIyN2MxZjE=
S: a001 OK AUTHENTICATE completed
Note that the lack of an initial client response and the base64
encoding are characteristics of the IMAP profile of SASL. The server
challenge is "otp-md5 123 ke1234 ext" and the client response is
"hex:11d4c147e227c1f1".
6. Security Considerations
This specification introduces no security considerations beyond those
those described in SASL [SASL], OTP [OTP] and OTP extended responses
[OTP-EXT]. A brief summary of these considerations follows:
This mechanism does not provide session privacy, server
authentication or protection from active attacks.
Newman Standards Track [Page 4]
RFC 2444 OTP SASL Mechanism October 1998
This mechanism is subject to passive dictionary attacks. The
severity of this attack can be reduced by choosing pass phrases well.
The server authentication database necessary for use with OTP need
not be plaintext-equivalent.
Server implementations MUST protect against the race attack [OTP].
7. Multinational Considerations
As remote access is a crucial service, users are encouraged to
restrict user names and pass phrases to the US-ASCII character set.
However, if characters outside the US-ASCII chracter set are used in
user names and pass phrases, then they are interpreted according to
UTF-8 [UTF-8].
Server support for alternate dictionaries is strongly RECOMMENDED to
permit use of the six-word format with non-English words.
8. IANA Considerations
Here is the registration template for the OTP SASL mechanism:
SASL mechanism name: OTP
Security Considerations: See section 6 of this memo
Published specification: this memo
Person & email address to contact for futher information:
see author's address section below
Intended usage: COMMON
Author/Change controller: see author's address section below
This memo also amends the SKEY SASL mechanism registration [SASL] by
changing its intended usage to OBSOLETE.
9. References
[ACAP] Newman, C. and J. Myers, "ACAP -- Application
Configuration Access Protocol", RFC 2244, November 1997.
[CRAM-MD5] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP
AUTHorize Extension for Simple Challenge/Response", RFC
2195, September 1997.
[IMAP4] Crispin, M., "Internet Message Access Protocol - Version
4rev1", RFC 2060, December 1996.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Newman Standards Track [Page 5]
RFC 2444 OTP SASL Mechanism October 1998
[LDAPv3] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
Access Protocol (v3)", RFC 2251, December 1997.
[MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321,
April 1992.
[OTP] Haller, N., Metz, C., Nesser, P. and M. Straw, "A One-Time
Password System", RFC 2289, February 1998.
[OTP-EXT] Metz, C., "OTP Extended Responses", RFC 2243, November
1997.
[POP-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734,
December 1994.
[SASL] Myers, J., "Simple Authentication and Security Layer
(SASL)", RFC 2222, October 1997.
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 2279, January 1998.
10. Author's Address
Chris Newman
Innosoft International, Inc.
1050 Lakes Drive
West Covina, CA 91790 USA
EMail: chris.newman@innosoft.com
Newman Standards Track [Page 6]
RFC 2444 OTP SASL Mechanism October 1998
11. Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Newman Standards Track [Page 7]
Network Working Group C. Newman
Request for Comments: 2595 Innosoft
Category: Standards Track June 1999
Using TLS with IMAP, POP3 and ACAP
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.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
1. Motivation
The TLS protocol (formerly known as SSL) provides a way to secure an
application protocol from tampering and eavesdropping. The option of
using such security is desirable for IMAP, POP and ACAP due to common
connection eavesdropping and hijacking attacks [AUTH]. Although
advanced SASL authentication mechanisms can provide a lightweight
version of this service, TLS is complimentary to simple
authentication-only SASL mechanisms or deployed clear-text password
login commands.
Many sites have a high investment in authentication infrastructure
(e.g., a large database of a one-way-function applied to user
passwords), so a privacy layer which is not tightly bound to user
authentication can protect against network eavesdropping attacks
without requiring a new authentication infrastructure and/or forcing
all users to change their password. Recognizing that such sites will
desire simple password authentication in combination with TLS
encryption, this specification defines the PLAIN SASL mechanism for
use with protocols which lack a simple password authentication
command such as ACAP and SMTP. (Note there is a separate RFC for the
STARTTLS command in SMTP [SMTPTLS].)
There is a strong desire in the IETF to eliminate the transmission of
clear-text passwords over unencrypted channels. While SASL can be
used for this purpose, TLS provides an additional tool with different
deployability characteristics. A server supporting both TLS with
Newman Standards Track [Page 1]
RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999
simple passwords and a challenge/response SASL mechanism is likely to
interoperate with a wide variety of clients without resorting to
unencrypted clear-text passwords.
The STARTTLS command rectifies a number of the problems with using a
separate port for a "secure" protocol variant. Some of these are
mentioned in section 7.
1.1. Conventions Used in this Document
The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in "Key words for use in RFCs to Indicate Requirement
Levels" [KEYWORDS].
Terms related to authentication are defined in "On Internet
Authentication" [AUTH].
Formal syntax is defined using ABNF [ABNF].
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
2. Basic Interoperability and Security Requirements
The following requirements apply to all implementations of the
STARTTLS extension for IMAP, POP3 and ACAP.
2.1. Cipher Suite Requirements
Implementation of the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [TLS] cipher
suite is REQUIRED. This is important as it assures that any two
compliant implementations can be configured to interoperate.
All other cipher suites are OPTIONAL.
2.2. Privacy Operational Mode Security Requirements
Both clients and servers SHOULD have a privacy operational mode which
refuses authentication unless successful activation of an encryption
layer (such as that provided by TLS) occurs prior to or at the time
of authentication and which will terminate the connection if that
encryption layer is deactivated. Implementations are encouraged to
have flexability with respect to the minimal encryption strength or
cipher suites permitted. A minimalist approach to this
recommendation would be an operational mode where the
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite is mandatory prior to
permitting authentication.
Newman Standards Track [Page 2]
RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999
Clients MAY have an operational mode which uses encryption only when
it is advertised by the server, but authentication continues
regardless. For backwards compatibility, servers SHOULD have an
operational mode where only the authentication mechanisms required by
the relevant base protocol specification are needed to successfully
authenticate.
2.3. Clear-Text Password Requirements
Clients and servers which implement STARTTLS MUST be configurable to
refuse all clear-text login commands or mechanisms (including both
standards-track and nonstandard mechanisms) unless an encryption
layer of adequate strength is active. Servers which allow
unencrypted clear-text logins SHOULD be configurable to refuse
clear-text logins both for the entire server, and on a per-user
basis.
2.4. Server Identity Check
During the TLS negotiation, the client MUST check its understanding
of the server hostname against the server's identity as presented in
the server Certificate message, in order to prevent man-in-the-middle
attacks. Matching is performed according to these rules:
- The client MUST use the server hostname it used to open the
connection as the value to compare against the server name as
expressed in the server certificate. The client MUST NOT use any
form of the server hostname derived from an insecure remote source
(e.g., insecure DNS lookup). CNAME canonicalization is not done.
- If a subjectAltName extension of type dNSName is present in the
certificate, it SHOULD be used as the source of the server's
identity.
- Matching is case-insensitive.
- A "*" wildcard character MAY be used as the left-most name
component in the certificate. For example, *.example.com would
match a.example.com, foo.example.com, etc. but would not match
example.com.
- If the certificate contains multiple names (e.g. more than one
dNSName field), then a match with any one of the fields is
considered acceptable.
If the match fails, the client SHOULD either ask for explicit user
confirmation, or terminate the connection and indicate the server's
identity is suspect.
Newman Standards Track [Page 3]
RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999
2.5. TLS Security Policy Check
Both the client and server MUST check the result of the STARTTLS
command and subsequent TLS negotiation to see whether acceptable
authentication or privacy was achieved. Ignoring this step
completely invalidates using TLS for security. The decision about
whether acceptable authentication or privacy was achieved is made
locally, is implementation-dependent, and is beyond the scope of this
document.
3. IMAP STARTTLS extension
When the TLS extension is present in IMAP, "STARTTLS" is listed as a
capability in response to the CAPABILITY command. This extension
adds a single command, "STARTTLS" to the IMAP protocol which is used
to begin a TLS negotiation.
3.1. STARTTLS Command
Arguments: none
Responses: no specific responses for this command
Result: OK - begin TLS negotiation
BAD - command unknown or arguments invalid
A TLS negotiation begins immediately after the CRLF at the end of
the tagged OK response from the server. Once a client issues a
STARTTLS command, it MUST NOT issue further commands until a
server response is seen and the TLS negotiation is complete.
The STARTTLS command is only valid in non-authenticated state.
The server remains in non-authenticated state, even if client
credentials are supplied during the TLS negotiation. The SASL
[SASL] EXTERNAL mechanism MAY be used to authenticate once TLS
client credentials are successfully exchanged, but servers
supporting the STARTTLS command are not required to support the
EXTERNAL mechanism.
Once TLS has been started, the client MUST discard cached
information about server capabilities and SHOULD re-issue the
CAPABILITY command. This is necessary to protect against
man-in-the-middle attacks which alter the capabilities list prior
to STARTTLS. The server MAY advertise different capabilities
after STARTTLS.
The formal syntax for IMAP is amended as follows:
Newman Standards Track [Page 4]
RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999
command_any =/ "STARTTLS"
Example: C: a001 CAPABILITY
S: * CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED
S: a001 OK CAPABILITY completed
C: a002 STARTTLS
S: a002 OK Begin TLS negotiation now
<TLS negotiation, further commands are under TLS layer>
C: a003 CAPABILITY
S: * CAPABILITY IMAP4rev1 AUTH=EXTERNAL
S: a003 OK CAPABILITY completed
C: a004 LOGIN joe password
S: a004 OK LOGIN completed
3.2. IMAP LOGINDISABLED capability
The current IMAP protocol specification (RFC 2060) requires the
implementation of the LOGIN command which uses clear-text passwords.
Many sites may choose to disable this command unless encryption is
active for security reasons. An IMAP server MAY advertise that the
LOGIN command is disabled by including the LOGINDISABLED capability
in the capability response. Such a server will respond with a tagged
"NO" response to any attempt to use the LOGIN command.
An IMAP server which implements STARTTLS MUST implement support for
the LOGINDISABLED capability on unencrypted connections.
An IMAP client which complies with this specification MUST NOT issue
the LOGIN command if this capability is present.
This capability is useful to prevent clients compliant with this
specification from sending an unencrypted password in an environment
subject to passive attacks. It has no impact on an environment
subject to active attacks as a man-in-the-middle attacker can remove
this capability. Therefore this does not relieve clients of the need
to follow the privacy mode recommendation in section 2.2.
Servers advertising this capability will fail to interoperate with
many existing compliant IMAP clients and will be unable to prevent
those clients from disclosing the user's password.
4. POP3 STARTTLS extension
The POP3 STARTTLS extension adds the STLS command to POP3 servers.
If this is implemented, the POP3 extension mechanism [POP3EXT] MUST
also be implemented to avoid the need for client probing of multiple
commands. The capability name "STLS" indicates this command is
present and permitted in the current state.
Newman Standards Track [Page 5]
RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999
STLS
Arguments: none
Restrictions:
Only permitted in AUTHORIZATION state.
Discussion:
A TLS negotiation begins immediately after the CRLF at the
end of the +OK response from the server. A -ERR response
MAY result if a security layer is already active. Once a
client issues a STLS command, it MUST NOT issue further
commands until a server response is seen and the TLS
negotiation is complete.
The STLS command is only permitted in AUTHORIZATION state
and the server remains in AUTHORIZATION state, even if
client credentials are supplied during the TLS negotiation.
The AUTH command [POP-AUTH] with the EXTERNAL mechanism
[SASL] MAY be used to authenticate once TLS client
credentials are successfully exchanged, but servers
supporting the STLS command are not required to support the
EXTERNAL mechanism.
Once TLS has been started, the client MUST discard cached
information about server capabilities and SHOULD re-issue
the CAPA command. This is necessary to protect against
man-in-the-middle attacks which alter the capabilities list
prior to STLS. The server MAY advertise different
capabilities after STLS.
Possible Responses:
+OK -ERR
Examples:
C: STLS
S: +OK Begin TLS negotiation
<TLS negotiation, further commands are under TLS layer>
...
C: STLS
S: -ERR Command not permitted when TLS active
Newman Standards Track [Page 6]
RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999
5. ACAP STARTTLS extension
When the TLS extension is present in ACAP, "STARTTLS" is listed as a
capability in the ACAP greeting. No arguments to this capability are
defined at this time. This extension adds a single command,
"STARTTLS" to the ACAP protocol which is used to begin a TLS
negotiation.
5.1. STARTTLS Command
Arguments: none
Responses: no specific responses for this command
Result: OK - begin TLS negotiation
BAD - command unknown or arguments invalid
A TLS negotiation begins immediately after the CRLF at the end of
the tagged OK response from the server. Once a client issues a
STARTTLS command, it MUST NOT issue further commands until a
server response is seen and the TLS negotiation is complete.
The STARTTLS command is only valid in non-authenticated state.
The server remains in non-authenticated state, even if client
credentials are supplied during the TLS negotiation. The SASL
[SASL] EXTERNAL mechanism MAY be used to authenticate once TLS
client credentials are successfully exchanged, but servers
supporting the STARTTLS command are not required to support the
EXTERNAL mechanism.
After the TLS layer is established, the server MUST re-issue an
untagged ACAP greeting. This is necessary to protect against
man-in-the-middle attacks which alter the capabilities list prior
to STARTTLS. The client MUST discard cached capability
information and replace it with the information from the new ACAP
greeting. The server MAY advertise different capabilities after
STARTTLS.
The formal syntax for ACAP is amended as follows:
command_any =/ "STARTTLS"
Example: S: * ACAP (SASL "CRAM-MD5") (STARTTLS)
C: a002 STARTTLS
S: a002 OK "Begin TLS negotiation now"
<TLS negotiation, further commands are under TLS layer>
S: * ACAP (SASL "CRAM-MD5" "PLAIN" "EXTERNAL")
Newman Standards Track [Page 7]
RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999
6. PLAIN SASL mechanism
Clear-text passwords are simple, interoperate with almost all
existing operating system authentication databases, and are useful
for a smooth transition to a more secure password-based
authentication mechanism. The drawback is that they are unacceptable
for use over an unencrypted network connection.
This defines the "PLAIN" SASL mechanism for use with ACAP and other
protocols with no clear-text login command. The PLAIN SASL mechanism
MUST NOT be advertised or used unless a strong encryption layer (such
as the provided by TLS) is active or backwards compatibility dictates
otherwise.
The mechanism consists of a single message from the client to the
server. The client sends the authorization identity (identity to
login as), followed by a US-ASCII NUL character, followed by the
authentication identity (identity whose password will be used),
followed by a US-ASCII NUL character, followed by the clear-text
password. The client may leave the authorization identity empty to
indicate that it is the same as the authentication identity.
The server will verify the authentication identity and password with
the system authentication database and verify that the authentication
credentials permit the client to login as the authorization identity.
If both steps succeed, the user is logged in.
The server MAY also use the password to initialize any new
authentication database, such as one suitable for CRAM-MD5
[CRAM-MD5].
Non-US-ASCII characters are permitted as long as they are represented
in UTF-8 [UTF-8]. Use of non-visible characters or characters which
a user may be unable to enter on some keyboards is discouraged.
The formal grammar for the client message using Augmented BNF [ABNF]
follows.
message = [authorize-id] NUL authenticate-id NUL password
authenticate-id = 1*UTF8-SAFE ; MUST accept up to 255 octets
authorize-id = 1*UTF8-SAFE ; MUST accept up to 255 octets
password = 1*UTF8-SAFE ; MUST accept up to 255 octets
NUL = %x00
UTF8-SAFE = %x01-09 / %x0B-0C / %x0E-7F / UTF8-2 /
UTF8-3 / UTF8-4 / UTF8-5 / UTF8-6
UTF8-1 = %x80-BF
UTF8-2 = %xC0-DF UTF8-1
UTF8-3 = %xE0-EF 2UTF8-1
Newman Standards Track [Page 8]
RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999
UTF8-4 = %xF0-F7 3UTF8-1
UTF8-5 = %xF8-FB 4UTF8-1
UTF8-6 = %xFC-FD 5UTF8-1
Here is an example of how this might be used to initialize a CRAM-MD5
authentication database for ACAP:
Example: S: * ACAP (SASL "CRAM-MD5") (STARTTLS)
C: a001 AUTHENTICATE "CRAM-MD5"
S: + "<1896.697170952@postoffice.reston.mci.net>"
C: "tim b913a602c7eda7a495b4e6e7334d3890"
S: a001 NO (TRANSITION-NEEDED)
"Please change your password, or use TLS to login"
C: a002 STARTTLS
S: a002 OK "Begin TLS negotiation now"
<TLS negotiation, further commands are under TLS layer>
S: * ACAP (SASL "CRAM-MD5" "PLAIN" "EXTERNAL")
C: a003 AUTHENTICATE "PLAIN" {21+}
C: <NUL>tim<NUL>tanstaaftanstaaf
S: a003 OK CRAM-MD5 password initialized
Note: In this example, <NUL> represents a single ASCII NUL octet.
7. imaps and pop3s ports
Separate "imaps" and "pop3s" ports were registered for use with SSL.
Use of these ports is discouraged in favor of the STARTTLS or STLS
commands.
A number of problems have been observed with separate ports for
"secure" variants of protocols. This is an attempt to enumerate some
of those problems.
- Separate ports lead to a separate URL scheme which intrudes into
the user interface in inappropriate ways. For example, many web
pages use language like "click here if your browser supports SSL."
This is a decision the browser is often more capable of making than
the user.
- Separate ports imply a model of either "secure" or "not secure."
This can be misleading in a number of ways. First, the "secure"
port may not in fact be acceptably secure as an export-crippled
cipher suite might be in use. This can mislead users into a false
sense of security. Second, the normal port might in fact be
secured by using a SASL mechanism which includes a security layer.
Thus the separate port distinction makes the complex topic of
security policy even more confusing. One common result of this
confusion is that firewall administrators are often misled into
Newman Standards Track [Page 9]
RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999
permitting the "secure" port and blocking the standard port. This
could be a poor choice given the common use of SSL with a 40-bit
key encryption layer and plain-text password authentication is less
secure than strong SASL mechanisms such as GSSAPI with Kerberos 5.
- Use of separate ports for SSL has caused clients to implement only
two security policies: use SSL or don't use SSL. The desirable
security policy "use TLS when available" would be cumbersome with
the separate port model, but is simple with STARTTLS.
- Port numbers are a limited resource. While they are not yet in
short supply, it is unwise to set a precedent that could double (or
worse) the speed of their consumption.
8. IANA Considerations
This constitutes registration of the "STARTTLS" and "LOGINDISABLED"
IMAP capabilities as required by section 7.2.1 of RFC 2060 [IMAP].
The registration for the POP3 "STLS" capability follows:
CAPA tag: STLS
Arguments: none
Added commands: STLS
Standard commands affected: May enable USER/PASS as a side-effect.
CAPA command SHOULD be re-issued after successful completion.
Announced states/Valid states: AUTHORIZATION state only.
Specification reference: this memo
The registration for the ACAP "STARTTLS" capability follows:
Capability name: STARTTLS
Capability keyword: STARTTLS
Capability arguments: none
Published Specification(s): this memo
Person and email address for further information:
see author's address section below
The registration for the PLAIN SASL mechanism follows:
SASL mechanism name: PLAIN
Security Considerations: See section 9 of this memo
Published specification: this memo
Person & email address to contact for further information:
see author's address section below
Intended usage: COMMON
Author/Change controller: see author's address section below
Newman Standards Track [Page 10]
RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999
9. Security Considerations
TLS only provides protection for data sent over a network connection.
Messages transferred over IMAP or POP3 are still available to server
administrators and usually subject to eavesdropping, tampering and
forgery when transmitted through SMTP or NNTP. TLS is no substitute
for an end-to-end message security mechanism using MIME security
multiparts [MIME-SEC].
A man-in-the-middle attacker can remove STARTTLS from the capability
list or generate a failure response to the STARTTLS command. In
order to detect such an attack, clients SHOULD warn the user when
session privacy is not active and/or be configurable to refuse to
proceed without an acceptable level of security.
A man-in-the-middle attacker can always cause a down-negotiation to
the weakest authentication mechanism or cipher suite available. For
this reason, implementations SHOULD be configurable to refuse weak
mechanisms or cipher suites.
Any protocol interactions prior to the TLS handshake are performed in
the clear and can be modified by a man-in-the-middle attacker. For
this reason, clients MUST discard cached information about server
capabilities advertised prior to the start of the TLS handshake.
Clients are encouraged to clearly indicate when the level of
encryption active is known to be vulnerable to attack using modern
hardware (such as encryption keys with 56 bits of entropy or less).
The LOGINDISABLED IMAP capability (discussed in section 3.2) only
reduces the potential for passive attacks, it provides no protection
against active attacks. The responsibility remains with the client
to avoid sending a password over a vulnerable channel.
The PLAIN mechanism relies on the TLS encryption layer for security.
When used without TLS, it is vulnerable to a common network
eavesdropping attack. Therefore PLAIN MUST NOT be advertised or used
unless a suitable TLS encryption layer is active or backwards
compatibility dictates otherwise.
When the PLAIN mechanism is used, the server gains the ability to
impersonate the user to all services with the same password
regardless of any encryption provided by TLS or other network privacy
mechanisms. While many other authentication mechanisms have similar
weaknesses, stronger SASL mechanisms such as Kerberos address this
issue. Clients are encouraged to have an operational mode where all
mechanisms which are likely to reveal the user's password to the
server are disabled.
Newman Standards Track [Page 11]
RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999
The security considerations for TLS apply to STARTTLS and the
security considerations for SASL apply to the PLAIN mechanism.
Additional security requirements are discussed in section 2.
10. References
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[ACAP] Newman, C. and J. Myers, "ACAP -- Application
Configuration Access Protocol", RFC 2244, November 1997.
[AUTH] Haller, N. and R. Atkinson, "On Internet Authentication",
RFC 1704, October 1994.
[CRAM-MD5] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP
AUTHorize Extension for Simple Challenge/Response", RFC
2195, September 1997.
[IMAP] Crispin, M., "Internet Message Access Protocol - Version
4rev1", RFC 2060, December 1996.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[MIME-SEC] Galvin, J., Murphy, S., Crocker, S. and N. Freed,
"Security Multiparts for MIME: Multipart/Signed and
Multipart/Encrypted", RFC 1847, October 1995.
[POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
STD 53, RFC 1939, May 1996.
[POP3EXT] Gellens, R., Newman, C. and L. Lundblade, "POP3 Extension
Mechanism", RFC 2449, November 1998.
[POP-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734,
December 1994.
[SASL] Myers, J., "Simple Authentication and Security Layer
(SASL)", RFC 2222, October 1997.
[SMTPTLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over
TLS", RFC 2487, January 1999.
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
Newman Standards Track [Page 12]
RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 2279, January 1998.
11. Author's Address
Chris Newman
Innosoft International, Inc.
1050 Lakes Drive
West Covina, CA 91790 USA
EMail: chris.newman@innosoft.com
A. Appendix -- Compliance Checklist
An implementation is not compliant if it fails to satisfy one or more
of the MUST requirements for the protocols it implements. An
implementation that satisfies all the MUST and all the SHOULD
requirements for its protocols is said to be "unconditionally
compliant"; one that satisfies all the MUST requirements but not all
the SHOULD requirements for its protocols is said to be
"conditionally compliant".
Rules Section
----- -------
Mandatory-to-implement Cipher Suite 2.1
SHOULD have mode where encryption required 2.2
server SHOULD have mode where TLS not required 2.2
MUST be configurable to refuse all clear-text login
commands or mechanisms 2.3
server SHOULD be configurable to refuse clear-text
login commands on entire server and on per-user basis 2.3
client MUST check server identity 2.4
client MUST use hostname used to open connection 2.4
client MUST NOT use hostname from insecure remote lookup 2.4
client SHOULD support subjectAltName of dNSName type 2.4
client SHOULD ask for confirmation or terminate on fail 2.4
MUST check result of STARTTLS for acceptable privacy 2.5
client MUST NOT issue commands after STARTTLS
until server response and negotiation done 3.1,4,5.1
client MUST discard cached information 3.1,4,5.1,9
client SHOULD re-issue CAPABILITY/CAPA command 3.1,4
IMAP server with STARTTLS MUST implement LOGINDISABLED 3.2
IMAP client MUST NOT issue LOGIN if LOGINDISABLED 3.2
POP server MUST implement POP3 extensions 4
ACAP server MUST re-issue ACAP greeting 5.1
Newman Standards Track [Page 13]
RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999
client SHOULD warn when session privacy not active and/or
refuse to proceed without acceptable security level 9
SHOULD be configurable to refuse weak mechanisms or
cipher suites 9
The PLAIN mechanism is an optional part of this specification.
However if it is implemented the following rules apply:
Rules Section
----- -------
MUST NOT use PLAIN unless strong encryption active
or backwards compatibility dictates otherwise 6,9
MUST use UTF-8 encoding for characters in PLAIN 6
Newman Standards Track [Page 14]
RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999
Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Newman Standards Track [Page 15]
Network Working Group M. Nystrom
Request for Comments: 2808 RSA Laboratories
Category: Informational April 2000
The SecurID(r) SASL Mechanism
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
SecurID is a hardware token card product (or software emulation
thereof) produced by RSA Security Inc., which is used for end-user
authentication. This document defines a SASL [RFC2222] authentication
mechanism using these tokens, thereby providing a means for such
tokens to be used in SASL environments. This mechanism is only for
authentication, and has no effect on the protocol encoding and is not
designed to provide integrity or confidentiality services.
This memo assumes the reader has basic familiarity with the SecurID
token, its associated authentication protocol and SASL.
How to read this document
The key words "MUST", "MUST NOT", "SHALL", "SHOULD" and "MAY" in this
document are to be interpreted as defined in [RFC2119].
In examples, "C:" and "S:" indicate messages sent by the client and
server respectively.
1. Introduction
The SECURID SASL mechanism is a good choice for usage scenarios where
a client, acting on behalf of a user, is untrusted, as a one-time
passcode will only give the client a single opportunity to act
maliciously. This mechanism provides authentication only.
Nystrom Informational [Page 1]
RFC 2808 The SecurID(r) SASL Mechanism April 2000
The SECURID SASL mechanism provides a formal way to integrate the
existing SecurID authentication method into SASL-enabled protocols
including IMAP [RFC2060], ACAP [RFC2244], POP3 [RFC1734] and LDAPv3
[RFC2251].
2. Authentication Model
The SECURID SASL mechanism provides two-factor based user
authentication as defined below.
There are basically three entities in the authentication mechanism
described here: A user, possessing a SecurID token, an application
server, to which the user wants to connect, and an authentication
server, capable of authenticating the user. Even though the
application server in practice may function as a client with respect
to the authentication server, relaying authentication credentials
etc. as needed, both servers are, unless explicitly mentioned,
collectively termed "the server" here. The protocol used between the
application server and the authentication server is outside the scope
of this memo. The application client, acting on behalf of the user,
is termed "the client".
The mechanism is based on the use of a shared secret key, or "seed",
and a personal identification number (PIN), which is known both by
the user and the authentication server. The secret seed is stored on
a token that the user possesses, as well as on the authentication
server. Hence the term "two-factor authentication", a user needs not
only physical access to the token but also knowledge about the PIN in
order to perform an authentication. Given the seed, current time of
day, and the PIN, a "PASSCODE(r)" is generated by the user's token
and sent to the server.
The SECURID SASL mechanism provides one service:
- User authentication where the user provides information to the
server, so that the server can authenticate the user.
This mechanism is identified with the SASL key "SECURID".
3. Authentication Procedure
a) The client generates the credentials using local information
(seed, current time and user PIN/password).
Nystrom Informational [Page 2]
RFC 2808 The SecurID(r) SASL Mechanism April 2000
b) If the underlying protocol permits, the client sends credentials
to the server in an initial response message. Otherwise, the
client sends a request to the server to initiate the
authentication mechanism, and sends credentials after the server's
response (see [RFC2222] section 5.1 for more information regarding
the initial response option).
Unless the server requests a new PIN (see below), the contents of
the client's initial response SHALL be as follows:
(1) An authorization identity. When this field is empty, it
defaults to the authentication identity. This field MAY be used
by system administrators or proxy servers to login with a
different user identity. This field MUST NOT be longer than 255
octets, SHALL be terminated by a NUL (0) octet, and MUST consist
of UTF-8-encoded [RFC2279] printable characters only (US-ASCII
[X3.4] is a subset of UTF-8).
(2) An authentication identity. The identity whose passcode will
be used. If this field is empty, it is assumed to have been
transferred by other means (e.g. if the underlying protocol has
support for this, like [RFC2251]). This field MUST NOT be longer
than 255 octets, SHALL be terminated by a NUL (0) octet, and MUST
consist of UTF-8-encoded printable characters only.
(3) A passcode. The one-time password that will be used to grant
access. This field MUST NOT be shorter than 4 octets, MUST NOT be
longer than 32 octets, SHALL be terminated by a NUL (0) octet, and
MUST consist of UTF-8-encoded printable characters only.
Passcodes usually consist of 4-8 digits.
The ABNF [RFC2234] form of this message is as follows:
credential-pdu = authorization-id authentication-id passcode [pin]
authorization-id = 0*255VUTF8 %x00
authentication-id = 0*255VUTF8 %x00
passcode = 4*32VUTF8 %x00
pin ::= 4*32VUTF8 %x00
VUTF8 = <Visible (printable) UTF8-encoded characters>
Regarding the <pin> rule, see d) below.
Nystrom Informational [Page 3]
RFC 2808 The SecurID(r) SASL Mechanism April 2000
c) The server verifies these credentials using its own information.
If the verification succeeds, the server sends back a response
indicating success to the client. After receiving this response,
the client is authenticated. Otherwise, the verification either
failed or the server needs an additional set of credentials from
the client in order to authenticate the user.
d) If the server needs an additional set of credentials, it requests
them now. This request has the following format, described in ABNF
notation:
server-request = passcode | pin
passcode = "passcode" %x00
pin = "pin" %x00 [suggested-pin]
suggested-pin = 4*32VUTF8 %x00 ; Between 4 and 32 UTF-8 characters
The 'passcode' choice will be sent when the server requests
another passcode. The 'pin' choice will be sent when the server
requests a new user PIN. The server will either send an empty
string or suggest a new user PIN in this message.
e) The client generates a new set of credentials using local
information and depending on the server's request and sends them
to the server. Authentication now continues as in c) above.
Note 1: Case d) above may occur e.g. when the clocks on which the
server and the client relies are not synchronized.
Note 2: If the server requests a new user PIN, the client MUST
respond with a new user PIN (together with a passcode), encoded as a
UTF-8 string. If the server supplies the client with a suggested PIN,
the client accepts this by replying with the same PIN, but MAY
replace it with another one. The length of the PIN is application-
dependent as are any other requirements for the PIN, e.g. allowed
characters. If the server for some reason does not accept the
received PIN, the client MUST be prepared to receive either a message
indicating the failure of the authentication or a repeated request
for a new PIN. Mechanisms for transferring knowledge about PIN
requirements from the server to the client are outside the scope of
this memo. However, some information MAY be provided in error
messages transferred from the server to the client when applicable.
Nystrom Informational [Page 4]
RFC 2808 The SecurID(r) SASL Mechanism April 2000
4. Examples
4.1 IMAP4
The following example shows the use of the SECURID SASL mechanism
with IMAP4. The example is only designed to illustrate the protocol
interaction but do provide valid encoding examples.
The base64 encoding of the last client response, as well as the "+ "
preceding the response, is part of the IMAP4 profile, and not a part
of this specification itself.
S: * OK IMAP4 server ready
C: A001 CAPABILITY
S: * CAPABILITY IMAP4 AUTH=CRAM-MD5 AUTH=SECURID
S: A001 OK done
C: A002 AUTHENTICATE SECURID
S: +
C: AG1hZ251cwAxMjM0NTY3OAA=
S: A002 OK Welcome, SECURID authenticated user: magnus
4.2 LDAPv3
The following examples show the use of the SECURID SASL mechanism
with LDAPv3. The examples are only designed to illustrate the
protocol interaction, but do provide valid encoding examples.
Usernames, passcodes and PINs are of course fictitious. For
readability, all messages are shown in the value-notation defined in
[X680]. <credential-pdu> values are shown hex-encoded in the
'credentials' field of LDAP's 'BindRequest' and <server-request>
values are shown hex-encoded in the 'serverSaslCreds' field of LDAP's
'BindResponse'.
4.2.1 LDAPv3 Example 1
Initial response message, successful authentication.
C: { messageID 1,
protocolOp bindRequest :
{ version 1,
name '434E3D4D41474E5553'H, -- "CN=MAGNUS"
authentication sasl :
{ mechanism '53454355524944'H, -- "SECURID"
credentials '006d61676e757300313233343536373800'H
}
}
}
Nystrom Informational [Page 5]
RFC 2808 The SecurID(r) SASL Mechanism April 2000
S: { messageID 1,
protocolOp bindResponse :
{ resultCode success,
matchedDN ''H,
errorMessage ''H,
}
}
4.2.2 LDAPv3 Example 2
Initial response message, server requires second passcode.
C: {
messageID 1,
protocolOp bindRequest : {
version 1,
name '434E3D4D41474E5553'H, -- "CN=MAGNUS"
authentication sasl : {
mechanism '53454355524944'H, -- "SECURID"
credentials '006d61676e757300313233343536373800'H
}
}
}
S: {
messageID 1,
protocolOp bindResponse : {
resultCode saslBindInProgress,
matchedDN ''H,
errorMessage ''H,
serverSaslCreds '70617373636f646500'H
}
}
C: {
messageID 1,
protocolOp bindRequest : {
version 1,
name '434E3D4D41474E5553'H, -- "CN=MAGNUS"
authentication sasl : {
mechanism '53454355524944'H, -- "SECURID"
credentials '006d61676e757300383736353433323100'H
}
}
}
S: {
messageID 1,
Nystrom Informational [Page 6]
RFC 2808 The SecurID(r) SASL Mechanism April 2000
protocolOp bindResponse : {
resultCode success,
matchedDN ''H,
errorMessage ''H,
}
}
4.2.3 LDAPv3 Example 3
Initial response message, server requires new PIN and passcode, and
supplies client with a suggested new PIN (which the client accepts).
C: {
messageID 1,
protocolOp bindRequest : {
version 1,
name '434E3D4D41474E5553'H, -- "CN=MAGNUS"
authentication sasl : {
mechanism '53454355524944'H, -- "SECURID"
credentials '006d61676e757300313233343536373800'H
}
}
}
S: {
messageID 1,
protocolOp bindResponse : {
resultCode saslBindInProgress,
matchedDN ''H,
errorMessage ''H,
serverSaslCreds '70696e006b616c6c6500'H
}
}
C: {
messageID 1,
protocolOp bindRequest : {
version 1,
name '434E3D4D41474E5553'H, -- "CN=MAGNUS"
authentication sasl : {
mechanism '53454355524944'H, -- "SECURID"
credentials '006d61676e7573003837343434363734006b616c6c6500'H
}
}
}
S: {
messageID 1,
Nystrom Informational [Page 7]
RFC 2808 The SecurID(r) SASL Mechanism April 2000
protocolOp bindResponse : {
resultCode success,
matchedDN ''H,
errorMessage ''H,
}
}
5. Security Considerations
This mechanism only provides protection against passive eavesdropping
attacks. It does not provide session privacy, server authentication
or protection from active attacks. In particular, man-in-the-middle
attacks, were an attacker acts as an application server in order to
acquire a valid passcode are possible.
In order to protect against such attacks, the client SHOULD make sure
that the server is properly authenticated. When user PINs are
transmitted, user authentication SHOULD take place on a server-
authenticated and confidentiality-protected connection.
Server implementations MUST protect against replay attacks, since an
attacker could otherwise gain access by replaying a previous, valid
request. Clients MUST also protect against replay of PIN-change
messages.
5.1 The Race Attack
It is possible for an attacker to listen to most of a passcode, guess
the remainder, and then race the legitimate user to complete the
authentication. As for OTP [RFC2289], conforming server
implementations MUST protect against this race condition. One defense
against this attack is outlined below and borrowed from [RFC2289];
implementations MAY use this approach or MAY select an alternative
defense.
One possible defense is to prevent a user from starting multiple
simultaneous authentication sessions. This means that once the
legitimate user has initiated authentication, an attacker would be
blocked until the first authentication process has completed. In
this approach, a timeout is necessary to thwart a denial of service
attack.
6. IANA Considerations
By registering the SecurID protocol as a SASL mechanism, implementers
will have a well-defined way of adding this authentication mechanism
to their product. Here is the registration template for the SECURID
SASL mechanism:
Nystrom Informational [Page 8]
RFC 2808 The SecurID(r) SASL Mechanism April 2000
SASL mechanism name: SECURID
Security Considerations: See corresponding section of this memo
Published specification: This memo
Person & email address to
contact for further
information: See author's address section below
Intended usage: COMMON
Author/Change controller: See author's address section below
7. Intellectual Property Considerations
RSA Security Inc. does not make any claims on the general
constructions described in this memo, although underlying techniques
may be covered. Among the underlying techniques, the SecurID
technology is covered by a number of US patents (and foreign
counterparts), in particular US patent no. 4,885,778, no. 5,097,505,
no. 5,168,520, and 5,657,388.
SecurID is a registered trademark, and PASSCODE is a trademark, of
RSA Security Inc.
8. References
[RFC1734] Myers, J., "POP3 AUTHentication command", RFC 1734,
December 1994.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2060] Crispin, M., "Internet Message Access Protocol - Version
4rev1", RFC 2060, December 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2222] Myers, J., "Simple Authentication and Security Layer", RFC
2222, October 1997.
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC2244] Newman, C. and J. Myers, "ACAP -- Application Configuration
Access Protocol", RFC 2244, November 1997.
[RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
Access Protocol (v3)", RFC 2251, December 1997.
Nystrom Informational [Page 9]
RFC 2808 The SecurID(r) SASL Mechanism April 2000
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
RFC 2279, January 1998.
[RFC2289] Haller, N., Metz, C., Nesser, P. and M. Straw, "A One-Time
Password System", RFC 2289, February 1998.
[X3.4] ANSI, "ANSI X3.4: Information Systems - Coded Character
Sets - 7-Bit American National Standard Code for
Information Interchange (7-Bit ASCII)," American National
Standards Institute.
[X680] ITU-T, "Information Technology - Abstract Syntax Notation
One (ASN.1): Specification of Basic Notation,"
International Telecommunication Union, 1997.
9. Acknowledgements
The author gratefully acknowledges the contributions of various
reviewers of this memo, in particular the ones from John Myers. They
have significantly clarified and improved the utility of this
specification.
10. Author's Address
Magnus Nystrom
RSA Laboratories
Box 10704
121 29 Stockholm
Sweden
Phone: +46 8 725 0900
EMail: magnus@rsasecurity.com
Nystrom Informational [Page 10]
RFC 2808 The SecurID(r) SASL Mechanism April 2000
11. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Nystrom Informational [Page 11]
Network Working Group P. Leach
Request for Comments: 2831 Microsoft
Category: Standards Track C. Newman
Innosoft
May 2000
Using Digest Authentication as a SASL Mechanism
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.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
This specification defines how HTTP Digest Authentication [Digest]
can be used as a SASL [RFC 2222] mechanism for any protocol that has
a SASL profile. It is intended both as an improvement over CRAM-MD5
[RFC 2195] and as a convenient way to support a single authentication
mechanism for web, mail, LDAP, and other protocols.
Table of Contents
1 INTRODUCTION.....................................................2
1.1 CONVENTIONS AND NOTATION......................................2
1.2 REQUIREMENTS..................................................3
2 AUTHENTICATION...................................................3
2.1 INITIAL AUTHENTICATION........................................3
2.1.1 Step One...................................................3
2.1.2 Step Two...................................................6
2.1.3 Step Three................................................12
2.2 SUBSEQUENT AUTHENTICATION....................................12
2.2.1 Step one..................................................13
2.2.2 Step Two..................................................13
2.3 INTEGRITY PROTECTION.........................................13
2.4 CONFIDENTIALITY PROTECTION...................................14
3 SECURITY CONSIDERATIONS.........................................15
3.1 AUTHENTICATION OF CLIENTS USING DIGEST AUTHENTICATION........15
3.2 COMPARISON OF DIGEST WITH PLAINTEXT PASSWORDS................16
3.3 REPLAY ATTACKS...............................................16
Leach & Newman Standards Track [Page 1]
RFC 2831 Digest SASL Mechanism May 2000
3.4 ONLINE DICTIONARY ATTACKS....................................16
3.5 OFFLINE DICTIONARY ATTACKS...................................16
3.6 MAN IN THE MIDDLE............................................17
3.7 CHOSEN PLAINTEXT ATTACKS.....................................17
3.8 SPOOFING BY COUNTERFEIT SERVERS..............................17
3.9 STORING PASSWORDS............................................17
3.10 MULTIPLE REALMS.............................................18
3.11 SUMMARY.....................................................18
4 EXAMPLE.........................................................18
5 REFERENCES......................................................20
6 AUTHORS' ADDRESSES..............................................21
7 ABNF............................................................21
7.1 AUGMENTED BNF................................................21
7.2 BASIC RULES..................................................23
8 SAMPLE CODE.....................................................25
9 FULL COPYRIGHT STATEMENT........................................27
1 Introduction
This specification describes the use of HTTP Digest Access
Authentication as a SASL mechanism. The authentication type
associated with the Digest SASL mechanism is "DIGEST-MD5".
This specification is intended to be upward compatible with the
"md5-sess" algorithm of HTTP/1.1 Digest Access Authentication
specified in [Digest]. The only difference in the "md5-sess"
algorithm is that some directives not needed in a SASL mechanism have
had their values defaulted.
There is one new feature for use as a SASL mechanism: integrity
protection on application protocol messages after an authentication
exchange.
Also, compared to CRAM-MD5, DIGEST-MD5 prevents chosen plaintext
attacks, and permits the use of third party authentication servers,
mutual authentication, and optimized reauthentication if a client has
recently authenticated to a server.
1.1 Conventions and Notation
This specification uses the same ABNF notation and lexical
conventions as HTTP/1.1 specification; see appendix A.
Let { a, b, ... } be the concatenation of the octet strings a, b, ...
Let H(s) be the 16 octet MD5 hash [RFC 1321] of the octet string s.
Leach & Newman Standards Track [Page 2]
RFC 2831 Digest SASL Mechanism May 2000
Let KD(k, s) be H({k, ":", s}), i.e., the 16 octet hash of the string
k, a colon and the string s.
Let HEX(n) be the representation of the 16 octet MD5 hash n as a
string of 32 hex digits (with alphabetic characters always in lower
case, since MD5 is case sensitive).
Let HMAC(k, s) be the 16 octet HMAC-MD5 [RFC 2104] of the octet
string s using the octet string k as a key.
The value of a quoted string constant as an octet string does not
include any terminating null character.
1.2 Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC 2119].
An implementation is not compliant if it fails to satisfy one or more
of the MUST level requirements for the protocols it implements. An
implementation that satisfies all the MUST level and all the SHOULD
level requirements for its protocols is said to be "unconditionally
compliant"; one that satisfies all the MUST level requirements but
not all the SHOULD level requirements for its protocols is said to be
"conditionally compliant."
2 Authentication
The following sections describe how to use Digest as a SASL
authentication mechanism.
2.1 Initial Authentication
If the client has not recently authenticated to the server, then it
must perform "initial authentication", as defined in this section. If
it has recently authenticated, then a more efficient form is
available, defined in the next section.
2.1.1 Step One
The server starts by sending a challenge. The data encoded in the
challenge contains a string formatted according to the rules for a
"digest-challenge" defined as follows:
Leach & Newman Standards Track [Page 3]
RFC 2831 Digest SASL Mechanism May 2000
digest-challenge =
1#( realm | nonce | qop-options | stale | maxbuf | charset
algorithm | cipher-opts | auth-param )
realm = "realm" "=" <"> realm-value <">
realm-value = qdstr-val
nonce = "nonce" "=" <"> nonce-value <">
nonce-value = qdstr-val
qop-options = "qop" "=" <"> qop-list <">
qop-list = 1#qop-value
qop-value = "auth" | "auth-int" | "auth-conf" |
token
stale = "stale" "=" "true"
maxbuf = "maxbuf" "=" maxbuf-value
maxbuf-value = 1*DIGIT
charset = "charset" "=" "utf-8"
algorithm = "algorithm" "=" "md5-sess"
cipher-opts = "cipher" "=" <"> 1#cipher-value <">
cipher-value = "3des" | "des" | "rc4-40" | "rc4" |
"rc4-56" | token
auth-param = token "=" ( token | quoted-string )
The meanings of the values of the directives used above are as
follows:
realm
Mechanistically, a string which can enable users to know which
username and password to use, in case they might have different
ones for different servers. Conceptually, it is the name of a
collection of accounts that might include the user's account. This
string should contain at least the name of the host performing the
authentication and might additionally indicate the collection of
users who might have access. An example might be
"registered_users@gotham.news.example.com". This directive is
optional; if not present, the client SHOULD solicit it from the
user or be able to compute a default; a plausible default might be
the realm supplied by the user when they logged in to the client
system. Multiple realm directives are allowed, in which case the
user or client must choose one as the realm for which to supply to
username and password.
nonce
A server-specified data string which MUST be different each time a
digest-challenge is sent as part of initial authentication. It is
recommended that this string be base64 or hexadecimal data. Note
that since the string is passed as a quoted string, the
double-quote character is not allowed unless escaped (see section
7.2). The contents of the nonce are implementation dependent. The
Leach & Newman Standards Track [Page 4]
RFC 2831 Digest SASL Mechanism May 2000
security of the implementation depends on a good choice. It is
RECOMMENDED that it contain at least 64 bits of entropy. The nonce
is opaque to the client. This directive is required and MUST
appear exactly once; if not present, or if multiple instances are
present, the client should abort the authentication exchange.
qop-options
A quoted string of one or more tokens indicating the "quality of
protection" values supported by the server. The value "auth"
indicates authentication; the value "auth-int" indicates
authentication with integrity protection; the value "auth-conf"
indicates authentication with integrity protection and encryption.
This directive is optional; if not present it defaults to "auth".
The client MUST ignore unrecognized options; if the client
recognizes no option, it should abort the authentication exchange.
stale
The "stale" directive is not used in initial authentication. See
the next section for its use in subsequent authentications. This
directive may appear at most once; if multiple instances are
present, the client should abort the authentication exchange.
maxbuf
A number indicating the size of the largest buffer the server is
able to receive when using "auth-int" or "auth-conf". If this
directive is missing, the default value is 65536. This directive
may appear at most once; if multiple instances are present, the
client should abort the authentication exchange.
charset
This directive, if present, specifies that the server supports
UTF-8 encoding for the username and password. If not present, the
username and password must be encoded in ISO 8859-1 (of which
US-ASCII is a subset). The directive is needed for backwards
compatibility with HTTP Digest, which only supports ISO 8859-1.
This directive may appear at most once; if multiple instances are
present, the client should abort the authentication exchange.
algorithm
This directive is required for backwards compatibility with HTTP
Digest., which supports other algorithms. . This directive is
required and MUST appear exactly once; if not present, or if
multiple instances are present, the client should abort the
authentication exchange.
Leach & Newman Standards Track [Page 5]
RFC 2831 Digest SASL Mechanism May 2000
cipher-opts
A list of ciphers that the server supports. This directive must be
present exactly once if "auth-conf" is offered in the
"qop-options" directive, in which case the "3des" and "des" modes
are mandatory-to-implement. The client MUST ignore unrecognized
options; if the client recognizes no option, it should abort the
authentication exchange.
des
the Data Encryption Standard (DES) cipher [FIPS] in cipher
block chaining (CBC) mode with a 56 bit key.
3des
the "triple DES" cipher in CBC mode with EDE with the same key
for each E stage (aka "two keys mode") for a total key length
of 112 bits.
rc4, rc4-40, rc4-56
the RC4 cipher with a 128 bit, 40 bit, and 56 bit key,
respectively.
auth-param This construct allows for future extensions; it may appear
more than once. The client MUST ignore any unrecognized
directives.
For use as a SASL mechanism, note that the following changes are made
to "digest-challenge" from HTTP: the following Digest options (called
"directives" in HTTP terminology) are unused (i.e., MUST NOT be sent,
and MUST be ignored if received):
opaque
domain
The size of a digest-challenge MUST be less than 2048 bytes.
2.1.2 Step Two
The client makes note of the "digest-challenge" and then responds
with a string formatted and computed according to the rules for a
"digest-response" defined as follows:
Leach & Newman Standards Track [Page 6]
RFC 2831 Digest SASL Mechanism May 2000
digest-response = 1#( username | realm | nonce | cnonce |
nonce-count | qop | digest-uri | response |
maxbuf | charset | cipher | authzid |
auth-param )
username = "username" "=" <"> username-value <">
username-value = qdstr-val
cnonce = "cnonce" "=" <"> cnonce-value <">
cnonce-value = qdstr-val
nonce-count = "nc" "=" nc-value
nc-value = 8LHEX
qop = "qop" "=" qop-value
digest-uri = "digest-uri" "=" <"> digest-uri-value <">
digest-uri-value = serv-type "/" host [ "/" serv-name ]
serv-type = 1*ALPHA
host = 1*( ALPHA | DIGIT | "-" | "." )
serv-name = host
response = "response" "=" response-value
response-value = 32LHEX
LHEX = "0" | "1" | "2" | "3" |
"4" | "5" | "6" | "7" |
"8" | "9" | "a" | "b" |
"c" | "d" | "e" | "f"
cipher = "cipher" "=" cipher-value
authzid = "authzid" "=" <"> authzid-value <">
authzid-value = qdstr-val
username
The user's name in the specified realm, encoded according to the
value of the "charset" directive. This directive is required and
MUST be present exactly once; otherwise, authentication fails.
realm
The realm containing the user's account. This directive is
required if the server provided any realms in the
"digest-challenge", in which case it may appear exactly once and
its value SHOULD be one of those realms. If the directive is
missing, "realm-value" will set to the empty string when computing
A1 (see below for details).
nonce
The server-specified data string received in the preceding
digest-challenge. This directive is required and MUST be present
exactly once; otherwise, authentication fails.
Leach & Newman Standards Track [Page 7]
RFC 2831 Digest SASL Mechanism May 2000
cnonce
A client-specified data string which MUST be different each time a
digest-response is sent as part of initial authentication. The
cnonce-value is an opaque quoted string value provided by the
client and used by both client and server to avoid chosen
plaintext attacks, and to provide mutual authentication. The
security of the implementation depends on a good choice. It is
RECOMMENDED that it contain at least 64 bits of entropy. This
directive is required and MUST be present exactly once; otherwise,
authentication fails.
nonce-count
The nc-value is the hexadecimal count of the number of requests
(including the current request) that the client has sent with the
nonce value in this request. For example, in the first request
sent in response to a given nonce value, the client sends
"nc=00000001". The purpose of this directive is to allow the
server to detect request replays by maintaining its own copy of
this count - if the same nc-value is seen twice, then the request
is a replay. See the description below of the construction of
the response value. This directive may appear at most once; if
multiple instances are present, the client should abort the
authentication exchange.
qop
Indicates what "quality of protection" the client accepted. If
present, it may appear exactly once and its value MUST be one of
the alternatives in qop-options. If not present, it defaults to
"auth". These values affect the computation of the response. Note
that this is a single token, not a quoted list of alternatives.
serv-type
Indicates the type of service, such as "www" for web service,
"ftp" for FTP service, "smtp" for mail delivery service, etc. The
service name as defined in the SASL profile for the protocol see
section 4 of [RFC 2222], registered in the IANA registry of
"service" elements for the GSSAPI host-based service name form
[RFC 2078].
host
The DNS host name or IP address for the service requested. The
DNS host name must be the fully-qualified canonical name of the
host. The DNS host name is the preferred form; see notes on server
processing of the digest-uri.
Leach & Newman Standards Track [Page 8]
RFC 2831 Digest SASL Mechanism May 2000
serv-name
Indicates the name of the service if it is replicated. The service
is considered to be replicated if the client's service-location
process involves resolution using standard DNS lookup operations,
and if these operations involve DNS records (such as SRV, or MX)
which resolve one DNS name into a set of other DNS names. In this
case, the initial name used by the client is the "serv-name", and
the final name is the "host" component. For example, the incoming
mail service for "example.com" may be replicated through the use
of MX records stored in the DNS, one of which points at an SMTP
server called "mail3.example.com"; it's "serv-name" would be
"example.com", it's "host" would be "mail3.example.com". If the
service is not replicated, or the serv-name is identical to the
host, then the serv-name component MUST be omitted.
digest-uri
Indicates the principal name of the service with which the client
wishes to connect, formed from the serv-type, host, and serv-name.
For example, the FTP service on "ftp.example.com" would have a
"digest-uri" value of "ftp/ftp.example.com"; the SMTP server from
the example above would have a "digest-uri" value of
"smtp/mail3.example.com/example.com".
Servers SHOULD check that the supplied value is correct. This will
detect accidental connection to the incorrect server. It is also so
that clients will be trained to provide values that will work with
implementations that use a shared back-end authentication service
that can provide server authentication.
The serv-type component should match the service being offered. The
host component should match one of the host names of the host on
which the service is running, or it's IP address. Servers SHOULD NOT
normally support the IP address form, because server authentication
by IP address is not very useful; they should only do so if the DNS
is unavailable or unreliable. The serv-name component should match
one of the service's configured service names.
This directive may appear at most once; if multiple instances are
present, the client should abort the authentication exchange.
Note: In the HTTP use of Digest authentication, the digest-uri is the
URI (usually a URL) of the resource requested -- hence the name of
the directive.
response
A string of 32 hex digits computed as defined below, which proves
that the user knows a password. This directive is required and
MUST be present exactly once; otherwise, authentication fails.
Leach & Newman Standards Track [Page 9]
RFC 2831 Digest SASL Mechanism May 2000
maxbuf
A number indicating the size of the largest buffer the client is
able to receive. If this directive is missing, the default value
is 65536. This directive may appear at most once; if multiple
instances are present, the server should abort the authentication
exchange.
charset
This directive, if present, specifies that the client has used
UTF-8 encoding for the username and password. If not present, the
username and password must be encoded in ISO 8859-1 (of which
US-ASCII is a subset). The client should send this directive only
if the server has indicated it supports UTF-8. The directive is
needed for backwards compatibility with HTTP Digest, which only
supports ISO 8859-1.
LHEX
32 hex digits, where the alphabetic characters MUST be lower case,
because MD5 is not case insensitive.
cipher
The cipher chosen by the client. This directive MUST appear
exactly once if "auth-conf" is negotiated; if required and not
present, authentication fails.
authzid
The "authorization ID" as per RFC 2222, encoded in UTF-8. This
directive is optional. If present, and the authenticating user has
sufficient privilege, and the server supports it, then after
authentication the server will use this identity for making all
accesses and access checks. If the client specifies it, and the
server does not support it, then the response-value will be
incorrect, and authentication will fail.
The size of a digest-response MUST be less than 4096 bytes.
2.1.2.1 Response-value
The definition of "response-value" above indicates the encoding for
its value -- 32 lower case hex characters. The following definitions
show how the value is computed.
Although qop-value and components of digest-uri-value may be
case-insensitive, the case which the client supplies in step two is
preserved for the purpose of computing and verifying the
response-value.
response-value =
Leach & Newman Standards Track [Page 10]
RFC 2831 Digest SASL Mechanism May 2000
HEX( KD ( HEX(H(A1)),
{ nonce-value, ":" nc-value, ":",
cnonce-value, ":", qop-value, ":", HEX(H(A2)) }))
If authzid is specified, then A1 is
A1 = { H( { username-value, ":", realm-value, ":", passwd } ),
":", nonce-value, ":", cnonce-value, ":", authzid-value }
If authzid is not specified, then A1 is
A1 = { H( { username-value, ":", realm-value, ":", passwd } ),
":", nonce-value, ":", cnonce-value }
where
passwd = *OCTET
The "username-value", "realm-value" and "passwd" are encoded
according to the value of the "charset" directive. If "charset=UTF-8"
is present, and all the characters of either "username-value" or
"passwd" are in the ISO 8859-1 character set, then it must be
converted to ISO 8859-1 before being hashed. This is so that
authentication databases that store the hashed username, realm and
password (which is common) can be shared compatibly with HTTP, which
specifies ISO 8859-1. A sample implementation of this conversion is
in section 8.
If the "qop" directive's value is "auth", then A2 is:
A2 = { "AUTHENTICATE:", digest-uri-value }
If the "qop" value is "auth-int" or "auth-conf" then A2 is:
A2 = { "AUTHENTICATE:", digest-uri-value,
":00000000000000000000000000000000" }
Note that "AUTHENTICATE:" must be in upper case, and the second
string constant is a string with a colon followed by 32 zeros.
These apparently strange values of A2 are for compatibility with
HTTP; they were arrived at by setting "Method" to "AUTHENTICATE" and
the hash of the entity body to zero in the HTTP digest calculation of
A2.
Also, in the HTTP usage of Digest, several directives in the
Leach & Newman Standards Track [Page 11]
RFC 2831 Digest SASL Mechanism May 2000
"digest-challenge" sent by the server have to be returned by the
client in the "digest-response". These are:
opaque
algorithm
These directives are not needed when Digest is used as a SASL
mechanism (i.e., MUST NOT be sent, and MUST be ignored if received).
2.1.3 Step Three
The server receives and validates the "digest-response". The server
checks that the nonce-count is "00000001". If it supports subsequent
authentication (see section 2.2), it saves the value of the nonce and
the nonce-count. It sends a message formatted as follows:
response-auth = "rspauth" "=" response-value
where response-value is calculated as above, using the values sent in
step two, except that if qop is "auth", then A2 is
A2 = { ":", digest-uri-value }
And if qop is "auth-int" or "auth-conf" then A2 is
A2 = { ":", digest-uri-value, ":00000000000000000000000000000000" }
Compared to its use in HTTP, the following Digest directives in the
"digest-response" are unused:
nextnonce
qop
cnonce
nonce-count
2.2 Subsequent Authentication
If the client has previously authenticated to the server, and
remembers the values of username, realm, nonce, nonce-count, cnonce,
and qop that it used in that authentication, and the SASL profile for
a protocol permits an initial client response, then it MAY perform
"subsequent authentication", as defined in this section.
Leach & Newman Standards Track [Page 12]
RFC 2831 Digest SASL Mechanism May 2000
2.2.1 Step one
The client uses the values from the previous authentication and sends
an initial response with a string formatted and computed according to
the rules for a "digest-response", as defined above, but with a
nonce-count one greater than used in the last "digest-response".
2.2.2 Step Two
The server receives the "digest-response". If the server does not
support subsequent authentication, then it sends a
"digest-challenge", and authentication proceeds as in initial
authentication. If the server has no saved nonce and nonce-count from
a previous authentication, then it sends a "digest-challenge", and
authentication proceeds as in initial authentication. Otherwise, the
server validates the "digest-response", checks that the nonce-count
is one greater than that used in the previous authentication using
that nonce, and saves the new value of nonce-count.
If the response is invalid, then the server sends a
"digest-challenge", and authentication proceeds as in initial
authentication (and should be configurable to log an authentication
failure in some sort of security audit log, since the failure may be
a symptom of an attack). The nonce-count MUST NOT be incremented in
this case: to do so would allow a denial of service attack by sending
an out-of-order nonce-count.
If the response is valid, the server MAY choose to deem that
authentication has succeeded. However, if it has been too long since
the previous authentication, or for any other reason, the server MAY
send a new "digest-challenge" with a new value for nonce. The
challenge MAY contain a "stale" directive with value "true", which
says that the client may respond to the challenge using the password
it used in the previous response; otherwise, the client must solicit
the password anew from the user. This permits the server to make sure
that the user has presented their password recently. (The directive
name refers to the previous nonce being stale, not to the last use of
the password.) Except for the handling of "stale", after sending the
"digest-challenge" authentication proceeds as in the case of initial
authentication.
2.3 Integrity Protection
If the server offered "qop=auth-int" and the client responded
"qop=auth-int", then subsequent messages, up to but not including the
next subsequent authentication, between the client and the server
Leach & Newman Standards Track [Page 13]
RFC 2831 Digest SASL Mechanism May 2000
MUST be integrity protected. Using as a base session key the value of
H(A1) as defined above the client and server calculate a pair of
message integrity keys as follows.
The key for integrity protecting messages from client to server is:
Kic = MD5({H(A1),
"Digest session key to client-to-server signing key magic constant"})
The key for integrity protecting messages from server to client is:
Kis = MD5({H(A1),
"Digest session key to server-to-client signing key magic constant"})
where MD5 is as specified in [RFC 1321]. If message integrity is
negotiated, a MAC block for each message is appended to the message.
The MAC block is 16 bytes: the first 10 bytes of the HMAC-MD5 [RFC
2104] of the message, a 2-byte message type number in network byte
order with value 1, and the 4-byte sequence number in network byte
order. The message type is to allow for future extensions such as
rekeying.
MAC(Ki, SeqNum, msg) = (HMAC(Ki, {SeqNum, msg})[0..9], 0x0001,
SeqNum)
where Ki is Kic for messages sent by the client and Kis for those
sent by the server. The sequence number is initialized to zero, and
incremented by one for each message sent.
Upon receipt, MAC(Ki, SeqNum, msg) is computed and compared with the
received value; the message is discarded if they differ.
2.4 Confidentiality Protection
If the server sent a "cipher-opts" directive and the client responded
with a "cipher" directive, then subsequent messages between the
client and the server MUST be confidentiality protected. Using as a
base session key the value of H(A1) as defined above the client and
server calculate a pair of message integrity keys as follows.
The key for confidentiality protecting messages from client to server
is:
Kcc = MD5({H(A1)[0..n],
"Digest H(A1) to client-to-server sealing key magic constant"})
The key for confidentiality protecting messages from server to client
is:
Leach & Newman Standards Track [Page 14]
RFC 2831 Digest SASL Mechanism May 2000
Kcs = MD5({H(A1)[0..n],
"Digest H(A1) to server-to-client sealing key magic constant"})
where MD5 is as specified in [RFC 1321]. For cipher "rc4-40" n is 5;
for "rc4-56" n is 7; for the rest n is 16. The key for the "rc-*"
ciphers is all 16 bytes of Kcc or Kcs; the key for "des" is the first
7 bytes; the key for "3des" is the first 14 bytes. The IV for "des"
and "3des" is the last 8 bytes of Kcc or Kcs.
If message confidentiality is negotiated, each message is encrypted
with the chosen cipher and a MAC block is appended to the message.
The MAC block is a variable length padding prefix followed by 16
bytes formatted as follows: the first 10 bytes of the HMAC-MD5 [RFC
2104] of the message, a 2-byte message type number in network byte
order with value 1, and the 4-byte sequence number in network byte
order. If the blocksize of the chosen cipher is not 1 byte, the
padding prefix is one or more octets each containing the number of
padding bytes, such that total length of the encrypted part of the
message is a multiple of the blocksize. The padding and first 10
bytes of the MAC block are encrypted along with the message.
SEAL(Ki, Kc, SeqNum, msg) =
{CIPHER(Kc, {msg, pad, HMAC(Ki, {SeqNum, msg})[0..9])}), 0x0001,
SeqNum}
where CIPHER is the chosen cipher, Ki and Kc are Kic and Kcc for
messages sent by the client and Kis and Kcs for those sent by the
server. The sequence number is initialized to zero, and incremented
by one for each message sent.
Upon receipt, the message is decrypted, HMAC(Ki, {SeqNum, msg}) is
computed and compared with the received value; the message is
discarded if they differ.
3 Security Considerations
3.1 Authentication of Clients using Digest Authentication
Digest Authentication does not provide a strong authentication
mechanism, when compared to public key based mechanisms, for example.
However, since it prevents chosen plaintext attacks, it is stronger
than (e.g.) CRAM-MD5, which has been proposed for use with LDAP [10],
POP and IMAP (see RFC 2195 [9]). It is intended to replace the much
weaker and even more dangerous use of plaintext passwords; however,
since it is still a password based mechanism it avoids some of the
potential deployabilty issues with public-key, OTP or similar
mechanisms.
Leach & Newman Standards Track [Page 15]
RFC 2831 Digest SASL Mechanism May 2000
Digest Authentication offers no confidentiality protection beyond
protecting the actual password. All of the rest of the challenge and
response are available to an eavesdropper, including the user's name
and authentication realm.
3.2 Comparison of Digest with Plaintext Passwords
The greatest threat to the type of transactions for which these
protocols are used is network snooping. This kind of transaction
might involve, for example, online access to a mail service whose use
is restricted to paying subscribers. With plaintext password
authentication an eavesdropper can obtain the password of the user.
This not only permits him to access anything in the database, but,
often worse, will permit access to anything else the user protects
with the same password.
3.3 Replay Attacks
Replay attacks are defeated if the client or the server chooses a
fresh nonce for each authentication, as this specification requires.
3.4 Online dictionary attacks
If the attacker can eavesdrop, then it can test any overheard
nonce/response pairs against a (potentially very large) list of
common words. Such a list is usually much smaller than the total
number of possible passwords. The cost of computing the response for
each password on the list is paid once for each challenge.
The server can mitigate this attack by not allowing users to select
passwords that are in a dictionary.
3.5 Offline dictionary attacks
If the attacker can choose the challenge, then it can precompute the
possible responses to that challenge for a list of common words. Such
a list is usually much smaller than the total number of possible
passwords. The cost of computing the response for each password on
the list is paid just once.
Offline dictionary attacks are defeated if the client chooses a fresh
nonce for each authentication, as this specification requires.
Leach & Newman Standards Track [Page 16]
RFC 2831 Digest SASL Mechanism May 2000
3.6 Man in the Middle
Digest authentication is vulnerable to "man in the middle" (MITM)
attacks. Clearly, a MITM would present all the problems of
eavesdropping. But it also offers some additional opportunities to
the attacker.
A possible man-in-the-middle attack would be to substitute a weaker
qop scheme for the one(s) sent by the server; the server will not be
able to detect this attack. For this reason, the client should always
use the strongest scheme that it understands from the choices
offered, and should never choose a scheme that does not meet its
minimum requirements.
3.7 Chosen plaintext attacks
A chosen plaintext attack is where a MITM or a malicious server can
arbitrarily choose the challenge that the client will use to compute
the response. The ability to choose the challenge is known to make
cryptanalysis much easier [8].
However, Digest does not permit the attack to choose the challenge as
long as the client chooses a fresh nonce for each authentication, as
this specification requires.
3.8 Spoofing by Counterfeit Servers
If a user can be led to believe that she is connecting to a host
containing information protected by a password she knows, when in
fact she is connecting to a hostile server, then the hostile server
can obtain challenge/response pairs where it was able to partly
choose the challenge. There is no known way that this can be
exploited.
3.9 Storing passwords
Digest authentication requires that the authenticating agent (usually
the server) store some data derived from the user's name and password
in a "password file" associated with a given realm. Normally this
might contain pairs consisting of username and H({ username-value,
":", realm-value, ":", passwd }), which is adequate to compute H(A1)
as described above without directly exposing the user's password.
The security implications of this are that if this password file is
compromised, then an attacker gains immediate access to documents on
the server using this realm. Unlike, say a standard UNIX password
file, this information need not be decrypted in order to access
documents in the server realm associated with this file. On the other
Leach & Newman Standards Track [Page 17]
RFC 2831 Digest SASL Mechanism May 2000
hand, decryption, or more likely a brute force attack, would be
necessary to obtain the user's password. This is the reason that the
realm is part of the digested data stored in the password file. It
means that if one Digest authentication password file is compromised,
it does not automatically compromise others with the same username
and password (though it does expose them to brute force attack).
There are two important security consequences of this. First the
password file must be protected as if it contained plaintext
passwords, because for the purpose of accessing documents in its
realm, it effectively does.
A second consequence of this is that the realm string should be
unique among all realms that any single user is likely to use. In
particular a realm string should include the name of the host doing
the authentication.
3.10 Multiple realms
Use of multiple realms may mean both that compromise of a the
security database for a single realm does not compromise all
security, and that there are more things to protect in order to keep
the whole system secure.
3.11 Summary
By modern cryptographic standards Digest Authentication is weak,
compared to (say) public key based mechanisms. But for a large range
of purposes it is valuable as a replacement for plaintext passwords.
Its strength may vary depending on the implementation.
4 Example
This example shows the use of the Digest SASL mechanism with the
IMAP4 AUTHENTICATE command [RFC 2060].
In this example, "C:" and "S:" represent a line sent by the client or
server respectively including a CRLF at the end. Linebreaks and
indentation within a "C:" or "S:" are editorial and not part of the
protocol. The password in this example was "secret". Note that the
base64 encoding of the challenges and responses is part of the IMAP4
AUTHENTICATE command, not part of the Digest specification itself.
S: * OK elwood.innosoft.com PMDF IMAP4rev1 V6.0-9
C: c CAPABILITY
S: * CAPABILITY IMAP4 IMAP4rev1 ACL LITERAL+ NAMESPACE QUOTA
UIDPLUS AUTH=CRAM-MD5 AUTH=DIGEST-MD5 AUTH=PLAIN
S: c OK Completed
Leach & Newman Standards Track [Page 18]
RFC 2831 Digest SASL Mechanism May 2000
C: a AUTHENTICATE DIGEST-MD5
S: + cmVhbG09ImVsd29vZC5pbm5vc29mdC5jb20iLG5vbmNlPSJPQTZNRzl0
RVFHbTJoaCIscW9wPSJhdXRoIixhbGdvcml0aG09bWQ1LXNlc3MsY2hh
cnNldD11dGYtOA==
C: Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2
QuaW5ub3NvZnQuY29tIixub25jZT0iT0E2TUc5dEVRR20yaGgiLG5jPTAw
MDAwMDAxLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLGRpZ2VzdC11cmk9Im
ltYXAvZWx3b29kLmlubm9zb2Z0LmNvbSIscmVzcG9uc2U9ZDM4OGRhZDkw
ZDRiYmQ3NjBhMTUyMzIxZjIxNDNhZjcscW9wPWF1dGg=
S: + cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA==
C:
S: a OK User logged in
---
The base64-decoded version of the SASL exchange is:
S: realm="elwood.innosoft.com",nonce="OA6MG9tEQGm2hh",qop="auth",
algorithm=md5-sess,charset=utf-8
C: charset=utf-8,username="chris",realm="elwood.innosoft.com",
nonce="OA6MG9tEQGm2hh",nc=00000001,cnonce="OA6MHXh6VqTrRk",
digest-uri="imap/elwood.innosoft.com",
response=d388dad90d4bbd760a152321f2143af7,qop=auth
S: rspauth=ea40f60335c427b5527b84dbabcdfffd
The password in this example was "secret".
This example shows the use of the Digest SASL mechanism with the
ACAP, using the same notational conventions and password as in the
previous example. Note that ACAP does not base64 encode and uses
fewer round trips that IMAP4.
S: * ACAP (IMPLEMENTATION "Test ACAP server") (SASL "CRAM-MD5"
"DIGEST-MD5" "PLAIN")
C: a AUTHENTICATE "DIGEST-MD5"
S: + {94}
S: realm="elwood.innosoft.com",nonce="OA9BSXrbuRhWay",qop="auth",
algorithm=md5-sess,charset=utf-8
C: {206}
C: charset=utf-8,username="chris",realm="elwood.innosoft.com",
nonce="OA9BSXrbuRhWay",nc=00000001,cnonce="OA9BSuZWMSpW8m",
digest-uri="acap/elwood.innosoft.com",
response=6084c6db3fede7352c551284490fd0fc,qop=auth
S: a OK (SASL {40}
S: rspauth=2f0b3d7c3c2e486600ef710726aa2eae) "AUTHENTICATE
Completed"
---
Leach & Newman Standards Track [Page 19]
RFC 2831 Digest SASL Mechanism May 2000
The server uses the values of all the directives, plus knowledge of
the users password (or the hash of the user's name, server's realm
and the user's password) to verify the computations above. If they
check, then the user has authenticated.
5 References
[Digest] Franks, J., et al., "HTTP Authentication: Basic and Digest
Access Authentication", RFC 2617, June 1999.
[ISO-8859] ISO-8859. International Standard--Information Processing--
8-bit Single-Byte Coded Graphic Character Sets --
Part 1: Latin alphabet No. 1, ISO-8859-1:1987.
Part 2: Latin alphabet No. 2, ISO-8859-2, 1987.
Part 3: Latin alphabet No. 3, ISO-8859-3, 1988.
Part 4: Latin alphabet No. 4, ISO-8859-4, 1988.
Part 5: Latin/Cyrillic alphabet, ISO-8859-5, 1988.
Part 6: Latin/Arabic alphabet, ISO-8859-6, 1987.
Part 7: Latin/Greek alphabet, ISO-8859-7, 1987.
Part 8: Latin/Hebrew alphabet, ISO-8859-8, 1988.
Part 9: Latin alphabet No. 5, ISO-8859-9, 1990.
[RFC 822] Crocker, D., "Standard for The Format of ARPA Internet
Text Messages," STD 11, RFC 822, August 1982.
[RFC 1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[RFC 2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII Text",
RFC 2047, November 1996.
[RFC 2052] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the
location of services (DNS SRV)", RFC 2052, October 1996.
[RFC 2060] Crispin, M., "Internet Message Access Protocol - Version
4rev1", RFC 2060, December 1996.
[RFC 2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February
1997.
[RFC 2195] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP
AUTHorize Extension for Simple Challenge/Response", RFC
2195, September 1997.
Leach & Newman Standards Track [Page 20]
RFC 2831 Digest SASL Mechanism May 2000
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2222] Myers, J., "Simple Authentication and Security Layer
(SASL)", RFC 2222, October 1997.
[USASCII] US-ASCII. Coded Character Set - 7-Bit American Standard
Code for Information Interchange. Standard ANSI X3.4-1986,
ANSI, 1986.
6 Authors' Addresses
Paul Leach
Microsoft
1 Microsoft Way
Redmond, WA 98052
EMail: paulle@microsoft.com
Chris Newman
Innosoft International, Inc.
1050 Lakes Drive
West Covina, CA 91790 USA
EMail: chris.newman@innosoft.com
7 ABNF
What follows is the definition of the notation as is used in the
HTTP/1.1 specification (RFC 2616) and the HTTP authentication
specification (RFC 2617); it is reproduced here for ease of
reference. Since it is intended that a single Digest implementation
can support both HTTP and SASL-based protocols, the same notation is
used in both to facilitate comparison and prevention of unwanted
differences. Since it is cut-and-paste from the HTTP specifications,
not all productions may be used in this specification. It is also not
quite legal ABNF; again, the errors were copied from the HTTP
specifications.
7.1 Augmented BNF
All of the mechanisms specified in this document are described in
both prose and an augmented Backus-Naur Form (BNF) similar to that
used by RFC 822 [RFC 822]. Implementers will need to be familiar with
the notation in order to understand this specification.
Leach & Newman Standards Track [Page 21]
RFC 2831 Digest SASL Mechanism May 2000
The augmented BNF includes the following constructs:
name = definition
The name of a rule is simply the name itself (without any
enclosing "<" and ">") and is separated from its definition by the
equal "=" character. White space is only significant in that
indentation of continuation lines is used to indicate a rule
definition that spans more than one line. Certain basic rules are
in uppercase, such as SP, LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle
brackets are used within definitions whenever their presence will
facilitate discerning the use of rule names.
"literal"
Quotation marks surround literal text. Unless stated otherwise,
the text is case-insensitive.
rule1 | rule2
Elements separated by a bar ("|") are alternatives, e.g., "yes |
no" will accept yes or no.
(rule1 rule2)
Elements enclosed in parentheses are treated as a single element.
Thus, "(elem (foo | bar) elem)" allows the token sequences
"elem foo elem" and "elem bar elem".
*rule
The character "*" preceding an element indicates repetition. The
full form is "<n>*<m>element" indicating at least <n> and at most
<m> occurrences of element. Default values are 0 and infinity so
that "*(element)" allows any number, including zero; "1*element"
requires at least one; and "1*2element" allows one or two.
[rule]
Square brackets enclose optional elements; "[foo bar]" is
equivalent to "*1(foo bar)".
N rule
Specific repetition: "<n>(element)" is equivalent to
"<n>*<n>(element)"; that is, exactly <n> occurrences of (element).
Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three
alphabetic characters.
#rule
A construct "#" is defined, similar to "*", for defining lists of
elements. The full form is "<n>#<m>element" indicating at least
<n> and at most <m> elements, each separated by one or more commas
(",") and OPTIONAL linear white space (LWS). This makes the usual
form of lists very easy; a rule such as
Leach & Newman Standards Track [Page 22]
RFC 2831 Digest SASL Mechanism May 2000
( *LWS element *( *LWS "," *LWS element ))
can be shown as
1#element
Wherever this construct is used, null elements are allowed, but do
not contribute to the count of elements present. That is,
"(element), , (element) " is permitted, but counts as only two
elements. Therefore, where at least one element is required, at
least one non-null element MUST be present. Default values are 0
and infinity so that "#element" allows any number, including zero;
"1#element" requires at least one; and "1#2element" allows one or
two.
; comment
A semi-colon, set off some distance to the right of rule text,
starts a comment that continues to the end of line. This is a
simple way of including useful notes in parallel with the
specifications.
implied *LWS
The grammar described by this specification is word-based. Except
where noted otherwise, linear white space (LWS) can be included
between any two adjacent words (token or quoted-string), and
between adjacent words and separators, without changing the
interpretation of a field. At least one delimiter (LWS and/or
separators) MUST exist between any two tokens (for the definition
of "token" below), since they would otherwise be interpreted as a
single token.
7.2 Basic Rules
The following rules are used throughout this specification to
describe basic parsing constructs. The US-ASCII coded character set
is defined by ANSI X3.4-1986 [USASCII].
OCTET = <any 8-bit sequence of data>
CHAR = <any US-ASCII character (octets 0 - 127)>
UPALPHA = <any US-ASCII uppercase letter "A".."Z">
LOALPHA = <any US-ASCII lowercase letter "a".."z">
ALPHA = UPALPHA | LOALPHA
DIGIT = <any US-ASCII digit "0".."9">
CTL = <any US-ASCII control character
(octets 0 - 31) and DEL (127)>
CR = <US-ASCII CR, carriage return (13)>
LF = <US-ASCII LF, linefeed (10)>
SP = <US-ASCII SP, space (32)>
HT = <US-ASCII HT, horizontal-tab (9)>
<"> = <US-ASCII double-quote mark (34)>
CRLF = CR LF
Leach & Newman Standards Track [Page 23]
RFC 2831 Digest SASL Mechanism May 2000
All linear white space, including folding, has the same semantics as
SP. A recipient MAY replace any linear white space with a single SP
before interpreting the field value or forwarding the message
downstream.
LWS = [CRLF] 1*( SP | HT )
The TEXT rule is only used for descriptive field contents and values
that are not intended to be interpreted by the message parser. Words
of *TEXT MAY contain characters from character sets other than
ISO-8859-1 [ISO 8859] only when encoded according to the rules of RFC
2047 [RFC 2047].
TEXT = <any OCTET except CTLs,
but including LWS>
A CRLF is allowed in the definition of TEXT only as part of a header
field continuation. It is expected that the folding LWS will be
replaced with a single SP before interpretation of the TEXT value.
Hexadecimal numeric characters are used in several protocol elements.
HEX = "A" | "B" | "C" | "D" | "E" | "F"
| "a" | "b" | "c" | "d" | "e" | "f" | DIGIT
Many HTTP/1.1 header field values consist of words separated by LWS
or special characters. These special characters MUST be in a quoted
string to be used within a parameter value.
token = 1*<any CHAR except CTLs or separators>
separators = "(" | ")" | "<" | ">" | "@"
| "," | ";" | ":" | "\" | <">
| "/" | "[" | "]" | "?" | "="
| "{" | "}" | SP | HT
A string of text is parsed as a single word if it is quoted using
double-quote marks.
quoted-string = ( <"> qdstr-val <"> )
qdstr-val = *( qdtext | quoted-pair )
qdtext = <any TEXT except <">>
Note that LWS is NOT implicit between the double-quote marks (<">)
surrounding a qdstr-val and the qdstr-val; any LWS will be considered
part of the qdstr-val. This is also the case for quotation marks
surrounding any other construct.
Leach & Newman Standards Track [Page 24]
RFC 2831 Digest SASL Mechanism May 2000
The backslash character ("\") MAY be used as a single-character
quoting mechanism only within qdstr-val and comment constructs.
quoted-pair = "\" CHAR
The value of this construct is CHAR. Note that an effect of this rule
is that backslash must be quoted.
8 Sample Code
The sample implementation in [Digest] also applies to DIGEST-MD5.
The following code implements the conversion from UTF-8 to 8859-1 if
necessary.
/* if the string is entirely in the 8859-1 subset of UTF-8, then
* translate to 8859-1 prior to MD5
*/
void MD5_UTF8_8859_1(MD5_CTX *ctx, const unsigned char *base,
int len)
{
const unsigned char *scan, *end;
unsigned char cbuf;
end = base + len;
for (scan = base; scan < end; ++scan) {
if (*scan > 0xC3) break; /* abort if outside 8859-1 */
if (*scan >= 0xC0 && *scan <= 0xC3) {
if (++scan == end || *scan < 0x80 || *scan > 0xBF)
break;
}
}
/* if we found a character outside 8859-1, don't alter string
*/
if (scan < end) {
MD5Update(ctx, base, len);
return;
}
/* convert to 8859-1 prior to applying hash
*/
do {
for (scan = base; scan < end && *scan < 0xC0; ++scan)
;
if (scan != base) MD5Update(ctx, base, scan - base);
if (scan + 1 >= end) break;
cbuf = ((scan[0] & 0x3) << 6) | (scan[1] & 0x3f);
MD5Update(ctx, &cbuf, 1);
Leach & Newman Standards Track [Page 25]
RFC 2831 Digest SASL Mechanism May 2000
base = scan + 2;
} while (base < end);
}
Leach & Newman Standards Track [Page 26]
RFC 2831 Digest SASL Mechanism May 2000
9 Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Leach & Newman Standards Track [Page 27]
SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL) MECHANISMS
----------------------------------------------------------
(last updated 2001 Jul 24)
The Simple Authentication and Security Layer (SASL) [RFC2222] is a
method for adding authentication support to connection-based
protocols. To use this specification, a protocol includes a command
for identifying and authenticating a user to a server and for
optionally negotiating a security layer for subsequent protocol
interactions. The command has a required argument identifying a SASL
mechanism.
SASL mechanisms are named by strings, from 1 to 20 characters in
length, consisting of upper-case letters, digits, hyphens, and/or
underscores. SASL mechanism names must be registered with the IANA.
Procedures for registering new SASL mechanisms are given in the
section "Registration procedures" of RFC2222.
MECHANISMS OWNER REFERENCE
---------- ----- ---------
KERBEROS_V4 IESG <iesg@ietf.org> [RFC2222]
GSSAPI IESG <iesg@ietf.org> [RFC2222]
SKEY (OBSOLETE) IESG <iesg@ietf.org> [RFC2444]
EXTERNAL IESG <iesg@ietf.org> [RFC2222]
CRAM-MD5 IESG <iesg@ietf.org> [RFC2195]
ANONYMOUS IESG <iesg@ietf.org> [RFC2245]
OTP IESG <iesg@ietf.org> [RFC2444]
GSS-SPNEGO Paul Leach <paulle@microsoft.com> [Leach]
PLAIN IESG <iesg@ietf.org> [RFC2595]
SECURID Magnus Nystrom <magnus@rsasecurity.com>[RFC2808]
NTLM Paul Leach <paulle@microsoft.com> [Leach]
NMAS_LOGIN Mark G. Gayman <mgayman@novell.com> [Gayman]
NMAS_AUTHEN Mark G. Gayman <mgayman@novell.com> [Gayman]
DIGEST-MD5 IESG <iesg@ietf.org> [RFC2831]
9798-U-RSA-SHA1-ENC robert.zuccherato@entrust.com [RFCZUCC]
9798-M-RSA-SHA1-ENC robert.zuccherato@entrust.com [RFCZUCC]
9798-U-DSA-SHA1 robert.zuccherato@entrust.com [RFCZUCC]
9798-M-DSA-SHA1 robert.zuccherato@entrust.com [RFCZUCC]
9798-U-ECDSA-SHA1 robert.zuccherato@entrust.com [RFCZUCC]
9798-M-ECDSA-SHA1 robert.zuccherato@entrust.com [RFCZUCC]
References
----------
[RFC2222] Myers, J., "Simple Authentication and Security Layer
(SASL)", RFC 2222, Netscape Communications, October 1997.
[RFC2195] Klensin, J., Catoe, R., Krumviede, P. "IMAP/POP AUTHorize
Extension for Simple Challenge/Response", RFC 2195, MCI,
September 1997.
[RFC2245] Newman, C., "Anonymous SASL Mechanism", RFC 2245, Innosoft,
November 1997.
[RFC2444] Newman, C., "The One-Time-Password SASL Mechanism", RFC
2444, October 1998.
[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595,
Innosoft, June 1999.
[RFC2808] Nystrom, M., "The SecurID(r) SASL Mechanism", RFC 2808,
April 2000.
[RFC2831] Leach, P. and C. Newman, "Using Digest Authentication as a
SASL Mechanism", RFC 2831, May 2000.
[RFCZUCC] R. Zuccherato and M. Nystrom, "ISO/IEC 9798-3 Authentication
SASL Mechanism", RFC XXXX, Month 2001.
People
------
[Gayman] Mark G. Gayman, <mgayman@novell.com>, September 2000.
[Leach] Paul Leach, <paulle@microsoft.com>, December 1998, June 2000.
[]