rfc2831.txt

LINUX下发送邮件的库,测试很好用,有各种发送测试的例子

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
      "[e-mail]".  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