CVS gsasl/doc/specification

[gsasl-commit]

Update of /home/cvs/gsasl/doc/specification
In directory dopio:/tmp/cvs-serv8360

Added Files:
        draft-ietf-sasl-rfc2831bis-05.txt 
Log Message:
Add.


--- /home/cvs/gsasl/doc/specification/draft-ietf-sasl-rfc2831bis-05.txt 
2005/04/29 22:16:27     NONE
+++ /home/cvs/gsasl/doc/specification/draft-ietf-sasl-rfc2831bis-05.txt 
2005/04/29 22:16:27     1.1






INTERNET-DRAFT                                                  P. Leach
Obsoletes: 2831                                                Microsoft
Intended category: Standards track                             C. Newman
                                                        Sun Microsystems
                                                             A. Melnikov
                                                              Isode Ltd.
                                                              April 2005

            Using Digest Authentication as a SASL Mechanism
                   draft-ietf-sasl-rfc2831bis-05.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).  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: October 2005                 [Page 1]





INTERNET DRAFT          DIGEST-MD5 SASL Mechanism             April 2005


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

   <<Page numbers are all wrong, sorry>>








Leach & Newman            Expires: October 2005                 [Page 2]





INTERNET DRAFT          DIGEST-MD5 SASL Mechanism             April 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

   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: October 2005                 [Page 3]





INTERNET DRAFT          DIGEST-MD5 SASL Mechanism             April 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  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: October 2005                 [Page 4]





INTERNET DRAFT          DIGEST-MD5 SASL Mechanism             April 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: October 2005                 [Page 5]





INTERNET DRAFT          DIGEST-MD5 SASL Mechanism             April 2005


   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 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
      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: October 2005                 [Page 6]





INTERNET DRAFT          DIGEST-MD5 SASL Mechanism             April 2005


      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

[2300 lines skipped]