[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: |
Fri, 28 Oct 2005 10:06:06 +0200 |
Update of /home/cvs/gsasl/doc/specification
In directory dopio:/tmp/cvs-serv16744
Added Files:
draft-ietf-sasl-rfc2831bis-07.txt
Log Message:
Add.
--- /home/cvs/gsasl/doc/specification/draft-ietf-sasl-rfc2831bis-07.txt
2005/10/28 08:06:06 NONE
+++ /home/cvs/gsasl/doc/specification/draft-ietf-sasl-rfc2831bis-07.txt
2005/10/28 08:06:06 1.1
INTERNET-DRAFT P. Leach
Obsoletes: 2831 Microsoft
Intended category: Standards track C. Newman
Sun Microsystems
A. Melnikov
Isode Ltd.
October 2005
Using Digest Authentication as a SASL Mechanism
draft-ietf-sasl-rfc2831bis-07.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 (2005).
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: April 2006 [Page 1]
INTERNET DRAFT DIGEST-MD5 SASL Mechanism October 2005
Table of Contents
1 INTRODUCTION.....................................................3
1.1 CONVENTIONS AND NOTATION......................................3
1.2 CHANNEL BINDINGS..............................................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 IANA CONSIDERATIONS.............................................28
7 ABNF............................................................29
7.1 AUGMENTED BNF................................................29
7.2 BASIC RULES..................................................31
8 SAMPLE CODE.....................................................33
9 AUTHORS' ADDRESSES..............................................XX
10 ACKNOWLEDGEMENTS..............................................34
11 FULL COPYRIGHT STATEMENT.......................................35
Appendix A: Changes from 2831.....................................36
Appendix B: Open Issues...........................................37
<<Page numbers are all wrong, sorry.
Section ordering should be changed too>>
Leach & Newman Expires: April 2006 [Page 2]
INTERNET DRAFT DIGEST-MD5 SASL Mechanism October 2005
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
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].
<<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: April 2006 [Page 3]
INTERNET DRAFT DIGEST-MD5 SASL Mechanism October 2005
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.
<<Other terms like "protocol profile" are defined in RFC2222.>>
1.2 Channel Bindings
"Channel binding" is a concept described in [RFC2743] and which
refers to the act of cryptographically binding authentication at one
network layer to a secure channel at another layer and where the end-
points at both layers are the same entities. In the context of the
DIGEST-MD5 SASL mechanism this means ensuring that the challenge and
response messages include the "channel bindings" of any cryptographic
channel (e.g. TLS) over which the DIGEST-MD5 exchange is transported,
and that the inputs to the digest function include the same as well.
The "channel bindings" of a channel here refer to information which
securely identifies one instance of such a channel to both endpoints
such that MITM attacks are detectable. For TLS, the channel
bindings are the TLS client and server finished messages.
Channel bindings are herein added to DIGEST-MD5 by overloading the
nonce and cnonce fields of the digest-challenge and digest-response
messages, respectively. Because these nonces are treated as opaque
octet strings in previous versions of this mechanism such overloading
is backwards compatible. Because these nonces are used in the
construction of the response-value (i.e., as input to the digest
function) using these fields for carrying channel bindings data makes
the channel binding operation possible without requiring incompatible
changes to the message formats. The fact that the odds that older
implementations may select random nonces that resemble actual channel
bindings data are so low allows new implementations to detect old
peers and to decide whether to allow such peers or reject them
according to local policy.
Leach & Newman Expires: April 2006 [Page 4]
INTERNET DRAFT DIGEST-MD5 SASL Mechanism October 2005
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
supports reauthentication and it has successfully authenticated to
the server before, the client may be able to use the more efficient
fast reauthentication mode as described in 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 is formatted according to the rules for the "digest-
challenge" defined as follows:
Leach & Newman Expires: April 2006 [Page 5]
INTERNET DRAFT DIGEST-MD5 SASL Mechanism October 2005
digest-challenge =
1#( realm | nonce | qop-options | stale | server_maxbuf | charset
algorithm | cipher-opts | auth-param )
realm = "realm" "=" realm-value
realm-value = quoted-string
nonce = "nonce" "=" nonce-value
nonce-value = quoted-string
;; contains data described by "nonce-data"
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 = "rc4-40" | "rc4" | "rc4-56" |
"aes-cbc" | cipher-token
;; cipher-token is reserved for new ciphersuites
cipher-token = token
auth-param = token "=" ( token | quoted-string )
nonce-data = new-nonce-data | obs-nonce-data
new-nonce-data = "CB-" channel-type ":" channel-bindings ":"
nonce-octets
obs-nonce-data = nonce-octets
;; nonce value as defined in RFC 2831. Should be
accepted
;; must not be generated.
channel-type = "TLS" / channel-type-ext
channel-type-ext = 1*(ALPHA | DIGIT)
;; for future channel bindings
channel-bindings = 1*TEXTCHAR
;; channel binding data as defined by the channel
type
nonce-octets = 1*TEXTCHAR
The meanings of the values of the directives used above are as
follows:
realm
Mechanistically, a string which enables users to decide which
username and password to use, in case they 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
Leach & Newman Expires: April 2006 [Page 6]
INTERNET DRAFT DIGEST-MD5 SASL Mechanism October 2005
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 (hide) 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
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.
[2300 lines skipped]
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- CVS gsasl/doc/specification,
gsasl-commit <=