[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
CVS gsasl/doc/specification
From: |
gsasl-commit |
Subject: |
CVS gsasl/doc/specification |
Date: |
Thu, 28 Oct 2004 22:34:36 +0200 |
Update of /home/cvs/gsasl/doc/specification
In directory dopio:/tmp/cvs-serv938
Added Files:
draft-ietf-sasl-crammd5-04.txt
draft-ietf-sasl-rfc2222bis-09.txt
Log Message:
Add.
--- /home/cvs/gsasl/doc/specification/draft-ietf-sasl-crammd5-04.txt
2004/10/28 20:34:36 NONE
+++ /home/cvs/gsasl/doc/specification/draft-ietf-sasl-crammd5-04.txt
2004/10/28 20:34:36 1.1
SASL Working Group L. Nerenberg, Ed.
Internet-Draft Orthanc Systems
Obsoletes: RFC2195 (if approved) October 25, 2004
Expires: April 25, 2005
The CRAM-MD5 SASL Mechanism
draft-ietf-sasl-crammd5-04
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 25, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document defines a simple challenge-response authentication
mechanism, using a keyed MD5 digest, for use with the Simple
Authentication and Security Layer (SASL).
Nerenberg Expires April 25, 2005 [Page 1]
Internet-Draft The CRAM-MD5 SASL Mechanism October 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The CRAM-MD5 SASL Mechanism . . . . . . . . . . . . . . . . . 3
3. Formal Grammar . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1 Normative References . . . . . . . . . . . . . . . . . . . . 5
5.2 Informative References . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6
A. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
A.1 IMAP4 . . . . . . . . . . . . . . . . . . . . . . . . . . 6
A.1.1 Example 1: Simple IMAP . . . . . . . . . . . . . . . . 7
A.1.2 Example 2: IMAP4 with embedded spaces . . . . . . . . 7
A.1.3 Example 3: IMAP4 with Unicode characters . . . . . . . 7
A.2 ACAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
A.2.1 Example 4: Simple ACAP . . . . . . . . . . . . . . . . 8
B. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
C. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 8
D. Changes since RFC 2195 . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . 10
Nerenberg Expires April 25, 2005 [Page 2]
Internet-Draft The CRAM-MD5 SASL Mechanism October 2004
1. Introduction
This document defines a simple challenge-response authentication
method, using a keyed MD5 [RFC2104] digest, for use with the Simple
Security and Authentication Layer (SASL)
[draft-ietf-sasl-rfc2222bis]. The mechanism name associated with
CRAM-MD5 is 'CRAM-MD5'.
This mechanism does not provide a security layer.
2. The CRAM-MD5 SASL Mechanism
The mechanism starts with the server issuing a <challenge>. The data
encoded in the challenge contains a presumptively arbitrary string of
random data.
The client makes note of the data and then responds with a <response>
consisting of the <username>, a space, and a <digest>. The digest is
computed by applying the keyed MD5 algorithm from RFC 2104 where the
key is a shared secret and the digested text is the challenge
(including angle-brackets). The client MUST NOT interpret or attempt
to validate the contents of the challenge in any way.
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 a
restricted hexadecimal format (see the <digest> production in Section
3).
When the server receives this client response, it verifies the digest
provided. Since the user name may contain the space character, the
server must take care to ensure the right-most space is recognised as
the token separating the user name from the digest. If the digest is
correct, the server should consider the client authenticated.
The client MUST prepare the user name and shared secret strings using
the SASLprep [draft-ietf-sasl-saslprep] profile of the Stringprep
[RFC3454] algorithm. The resulting values MUST be encoded as UTF-8
[RFC2279] strings. The server may store the prepared string instead
of, or as well as, the unprepared string, so that it does not have to
prepare it every time it is needed for computation. However, if the
original, unprepared string, is not stored, it may render the
computed secret to be incompatible with a future revisions of
SASLprep that support currently unassigned code points (compare
section 7 of Stringprep). It is therefor recommended to store the
unprepared string in the database.
Nerenberg Expires April 25, 2005 [Page 3]
Internet-Draft The CRAM-MD5 SASL Mechanism October 2004
3. Formal Grammar
The following grammar specification uses the Augmented Backus-Naur
Form (ABNF) as specified in [RFC2234], and incorporates by reference
the Core Rules defined in that document.
challenge = "<" 3*(%x21-3B / %x3D / %x3F-7E) ">"
; a bracketed string of printing ASCII characters, not
; containing embedded "<" or ">"
digest = 32(DIGIT / %x61-66)
; A hexadecimal string, using ONLY lower-case
; letters
response = username SP digest
username = 1*OCTET
; Must be well-formed UTF-8.
4. Security Considerations
It is conjectured that use of the CRAM-MD5 authentication mechanism
provides replay protection for a session.
This mechanism does not obscure the user name in any way.
Accordingly, a server that implements both a clear-text password
command and this authentication type should not allow both methods of
access for a given user name.
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 [RFC2104] for pre-computation
of intermediate results make it possible to avoid explicit clear-text
storage of the shared secret on the server system by instead storing
the intermediate results which are known as "contexts." While the
saving, on the server, of the MD5 context is marginally better than
saving the shared secrets in clear-text, 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 the data and services protected by this mechanism. In other
words, techniques like this one involve a trade-off between
vulnerability to network sniffing and I/O buffer snooping and
vulnerability of the server host's databases. If one believes that
the host and its databases are subject to compromise, and the network
is not, this technique (and all others like it) is unattractive. It
is perhaps even less attractive than clear-text passwords, which are
Nerenberg Expires April 25, 2005 [Page 4]
Internet-Draft The CRAM-MD5 SASL Mechanism October 2004
typically stored on hosts in one-way hash form. On the other hand,
if the server databases are perceived as reasonably secure, and one
is concerned about client-side or network interception of the
passwords (secrets), then this (and similar) techniques are
preferable to clear-text passwords by a wide margin.
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 clear-text passwords in many protocols. This document
has been 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-MD5, 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.
CRAM-MD5 does not authenticate the server and does not include a
client-supplied nonce. As a result, it is possible to construct a
server with a fixed challenge string that has pre-computed the hashes
for all possible passwords up to a certain length (or from a
dictionary). Such a server could then immediately determine the
user's password if it is sufficiently short.
5. References
5.1 Normative References
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:
Keyed-Hashing for Message Authentication", RFC 2104,
February 1997.
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications : ABNF", RFC 2234, November 1997.
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 2279, January 1998.
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
Internationalized Strings ("stringprep")", RFC 3454,
December 2002.
Nerenberg Expires April 25, 2005 [Page 5]
Internet-Draft The CRAM-MD5 SASL Mechanism October 2004
[draft-ietf-sasl-rfc2222bis]
Melnikov, A., "Simple Authentication and Security Layer
(SASL)", draft-ietf-sasl-rfc2222bis-07 (work in progress),
March 2004.
[draft-ietf-sasl-saslprep]
Zeilenga, K., "SASLprep: Stringprep profile for user names
and passwords", draft-ietf-sasl-saslprep-10 (work in
progress), July 2004.
5.2 Informative References
[RFC2244] Newman, C. and J. Myers, "ACAP -- Application
Configuration Access Protocol", RFC 2244, November 1997.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003.
Author's Address
Lyndon Nerenberg (editor)
Orthanc Systems
304 - 1755 Robson Street
Vancouver, BC V6G 3B7
Canada
EMail: address@hidden
Appendix A. Examples
The examples in this appendix DO NOT form part of the specification.
Where conflicts exist between the examples and the formal grammar or
the normative text in Section 2, the latter are authoritative.
A.1 IMAP4
These examples show the use of the CRAM-MD5 mechanism with the IMAP4
[RFC3501] AUTHENTICATE command. The base64 encoding of the
challenges and responses is part of the IMAP4 AUTHENTICATE command,
and not part of the CRAM-MD5 specification itself.
Nerenberg Expires April 25, 2005 [Page 6]
Internet-Draft The CRAM-MD5 SASL Mechanism October 2004
A.1.1 Example 1: Simple IMAP
In this example the shared secret is the string 'tanstaaftanstaaf'.
S: * OK [CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED AUTH=CRAM-MD5]
C: A0001 AUTHENTICATE CRAM-MD5
S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UuZXhhbXBsZS5uZXQ+
C: am9lIDNkYmM4OGYwNjI0Nzc2YTczN2IzOTA5M2Y2ZWI2NDI3
S: A0001 OK CRAM-MD5 authentication successful
Hence, the keyed MD5 digest is produced by calculating
MD5((SASLprep(tanstaaftanstaaf) XOR opad),
MD5((SASLprep(tanstaaftanstaaf) XOR ipad),
<address@hidden>))
where ipad and opad are as defined in RFC 2104 and the string shown
in the challenge is the base64 encoding of
'<address@hidden>'. 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
'3dbc88f0624776a737b39093f6eb6427'. The user name is then prepended
to it, forming 'joe 3dbc88f0624776a737b39093f6eb6427', which is then
base64 encoded to meet the requirements of the IMAP4 AUTHENTICATE
command yielding 'am9lIDNkYmM4OGYwNjI0Nzc2YTczN2IzOTA5M2Y2ZWI2NDI3'.
A.1.2 Example 2: IMAP4 with embedded spaces
This example uses the user name 'Ali Baba' and the shared secret
'Open, Sesame'. It illustrates that both user names and passwords
may contain non-alphanumeric characters.
S: <address@hidden>
C: Ali Baba 6fa32b6e768f073132588e3418e00f71
A.1.3 Example 3: IMAP4 with Unicode characters
This example demonstrates the processing of Unicode strings. The raw
user name is 'Al<U+00AA>dd<U+00AD>in<U+00AE>' where <U+00AA> is the
Unicode Latin symbol <FEMININE ORDINAL INDICATOR>, <U+00AD> is <SOFT
HYPHEN>, and <U+00AE> is the <REGISTERED SIGN>. Preparing the raw
user name with SASLprep returns 'Aladdin<U+00AE>' which we then
encode into the UTF-8 string 'Aladdin\xC2\xAE' (shown here and below
Nerenberg Expires April 25, 2005 [Page 7]
Internet-Draft The CRAM-MD5 SASL Mechanism October 2004
using C-style string format notation). As before, the shared secret
is 'Open, Sesame'.
S: <address@hidden>
C: Aladdin\xC2\xAE 9950ea407844a71e2f0cd3284cbd912d
[161 lines skipped]
--- /home/cvs/gsasl/doc/specification/draft-ietf-sasl-rfc2222bis-09.txt
2004/10/28 20:34:36 NONE
+++ /home/cvs/gsasl/doc/specification/draft-ietf-sasl-rfc2222bis-09.txt
2004/10/28 20:34:36 1.1
[2015 lines skipped]