[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, 09 Sep 2004 11:19:37 +0200 |
Update of /home/cvs/gsasl/doc/specification
In directory dopio:/tmp/cvs-serv10041
Added Files:
draft-ietf-sasl-rfc2831bis-04.txt
Log Message:
Add.
--- /home/cvs/gsasl/doc/specification/draft-ietf-sasl-rfc2831bis-04.txt
2004/09/09 09:19:32 NONE
+++ /home/cvs/gsasl/doc/specification/draft-ietf-sasl-rfc2831bis-04.txt
2004/09/09 09:19:32 1.1
INTERNET-DRAFT P. Leach
Obsoletes: 2831 Microsoft
Intended category: Standards track C. Newman
Sun Microsystems
A. Melnikov
Isode Ltd.
September 2004
Using Digest Authentication as a SASL Mechanism
draft-ietf-sasl-rfc2831bis-04.txt
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.
Copyright Notice
Copyright (C) The Internet Society (2004). 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.
Leach & Newman Expires: March 2005 [Page 1]
INTERNET DRAFT DIGEST-MD5 SASL Mechanism September 2004
Table of Contents
1 INTRODUCTION.....................................................3
1.1 CONVENTIONS AND NOTATION......................................3
1.2 REQUIREMENTS..................................................4
2 AUTHENTICATION...................................................5
2.1 INITIAL AUTHENTICATION........................................5
2.1.1 Step One...................................................5
2.1.2 Step Two...................................................9
2.1.3 Step Three................................................16
2.2 SUBSEQUENT AUTHENTICATION....................................17
2.2.1 Step one..................................................17
2.2.2 Step Two..................................................17
2.3 INTEGRITY PROTECTION.........................................18
2.4 CONFIDENTIALITY PROTECTION...................................18
3 SECURITY CONSIDERATIONS.........................................21
3.1 AUTHENTICATION OF CLIENTS USING DIGEST AUTHENTICATION........21
3.2 COMPARISON OF DIGEST WITH PLAINTEXT PASSWORDS................21
3.3 REPLAY ATTACKS...............................................21
3.4 ONLINE DICTIONARY ATTACKS....................................22
3.5 OFFLINE DICTIONARY ATTACKS...................................22
3.6 MAN IN THE MIDDLE............................................22
3.7 CHOSEN PLAINTEXT ATTACKS.....................................22
3.8 CBC MODE ATTACKS.............................................
3.9 SPOOFING BY COUNTERFEIT SERVERS..............................23
3.10 STORING PASSWORDS...........................................23
3.11 MULTIPLE REALMS.............................................24
3.12 SUMMARY.....................................................24
4 EXAMPLE.........................................................24
5 REFERENCES......................................................26
5.1 NORMATIVE REFERENCES.........................................26
5.2 INFORMATIVE REFERENCES.......................................27
6 AUTHORS' ADDRESSES..............................................28
7 ABNF............................................................29
7.1 AUGMENTED BNF................................................29
7.2 BASIC RULES..................................................31
8 SAMPLE CODE.....................................................33
10 ACKNOWLEDGEMENTS..............................................34
11 FULL COPYRIGHT STATEMENT.......................................35
Appendix A: Changes from 2831.....................................36
Appendix B: Open Issues...........................................37
Leach & Newman Expires: March 2005 [Page 2]
INTERNET DRAFT DIGEST-MD5 SASL Mechanism September 2004
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 section 7.
Let { a, b, ... } be the concatenation of the octet strings a, b, ...
Let ** denote the power operation.
Let H(s) be the 16 octet MD5 hash [RFC 1321] of the octet string s.
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.
Leach & Newman Expires: March 2005 [Page 3]
INTERNET DRAFT DIGEST-MD5 SASL Mechanism September 2004
Let unq(X) be the value of the quoted-string X without the
surrounding quotes and with all escape characters "\\" removed. For
example for the quoted-string "Babylon" the value of unq("Babylon")
is Babylon; for the quoted string "ABC\"123\\" the value of
unq("ABC\"123\\") is ABC"123\.
The value of a quoted string constant as an octet string does not
include any terminating null character.
<<"Protocol profile" is defined in RFC2222>>
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."
Leach & Newman Expires: March 2005 [Page 4]
INTERNET DRAFT DIGEST-MD5 SASL Mechanism September 2004
2 Authentication
DIGEST-MD5 can operate in two modes. Initial authentication (section
2.1) is usually used when a client authenticates to a server for the
first time. If protocol profile supports initial client response
(see "Protocol profile requirements" in [RFC 2222]) and the client
has successfully authenticated to the server before and the client
supports reauthentication (i.e. it has cached some values from a
previous authentication exchange, as described in 2.2), the client
can use fast reauthentication mode (section 2.2).
The following sections describe these two modes in details.
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 Expires: March 2005 [Page 5]
INTERNET DRAFT DIGEST-MD5 SASL Mechanism September 2004
digest-challenge =
1#( realm | nonce | qop-options | stale | server_maxbuf | charset
algorithm | cipher-opts | auth-param )
realm = "realm" "=" <"> realm-value <">
realm-value = qdstr-val
nonce = "nonce" "=" <"> nonce-value <">
nonce-value = *qdtext
qop-options = "qop" "=" <"> qop-list <">
qop-list = 1#qop-value
qop-value = "auth" | "auth-int" | "auth-conf" |
qop-token
;; qop-token is reserved for identifying future
;; extensions to DIGEST-MD5
qop-token = token
stale = "stale" "=" "true"
server_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" | "aes-cbc" | cipher-token
;; "des" and "3des" ciphers are obsolete.
;; cipher-token is reserved for new ciphersuites
cipher-token = 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 the name of the host performing the
authentication and might additionally indicate the collection of
users who might have access. An example might be
"address@hidden". Note that the server
MAY not advertise some or all realms it supports.
Other examples:
1) "dc=gotham, dc=news, dc=example, dc=com".
2) If there are two servers (e.g. server1.example.com and
server2.example.com) that share authentication database, they
Leach & Newman Expires: March 2005 [Page 6]
INTERNET DRAFT DIGEST-MD5 SASL Mechanism September 2004
both
may advertise "example.com" as the realm.
A server implementation that uses a fixed string as the advertised
realm is compliant with this specification, however this is not
recommended. See also sections 3.10 "Storing passwords" and 3.11
"Multiple realms" for discussion.
The value of this directive is case-sensitive. 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
username and password.
Requirements on UIs: UIs MUST allow users to enter arbitrary user
names and realm names. In order to achieve this, UIs MAY present
two separate edit boxes. Alternatively, UIs MAY present a single
edit box and allow user to enter a special character that
separates user name from the realm name. In the latter case, UIs
MUST be able to escape the special character and they need to
present their escape rules to the user. UIs MUST also present the
list of realms advertised by the server.
If at least one realm is present and the charset directive is also
specified (which means that realm(s) are encoded as UTF-8), the
client SHOULD prepare each instance of realm using the "SASLPrep"
profile [SASLPrep] of the "stringprep" algorithm [RFC 3454]. If
preparation of a realm instance fails or results in an empty
string (unless the realm instance was the empty string), the
client SHOULD abort the authentication exchange.
Note, that if the client picks one of the realms provided by the
server, it MUST send it exactly as received from the server, even
if the prepared version of the realm differs from the received
version.
nonce
[2294 lines skipped]
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- CVS gsasl/doc/specification,
gsasl-commit <=