rfc2831.txt

中、英文RFC文档大全打包下载完全版 .

   where Ki is Kic for messages sent by the client and Kis for those
   sent by the server. The sequence number is initialized to zero, and
   incremented by one for each message sent.

   Upon receipt, MAC(Ki, SeqNum, msg) is computed and compared with the
   received value; the message is discarded if they differ.

2.4   Confidentiality Protection

   If the server sent a "cipher-opts" directive and the client responded
   with a "cipher" directive, then subsequent messages between the
   client and the server MUST be confidentiality protected. Using as a
   base session key the value of H(A1) as defined above the client and
   server calculate a pair of message integrity keys as follows.

   The key for confidentiality protecting messages from client to server
   is:

   Kcc = MD5({H(A1)[0..n],
   "Digest H(A1) to client-to-server sealing key magic constant"})

   The key for confidentiality protecting messages from server to client
   is:



Leach & Newman              Standards Track                    [Page 14]

RFC 2831                 Digest SASL Mechanism                  May 2000


   Kcs = MD5({H(A1)[0..n],
   "Digest H(A1) to server-to-client sealing key magic constant"})

   where MD5 is as specified in [RFC 1321]. For cipher "rc4-40" n is 5;
   for "rc4-56" n is 7; for the rest n is 16. The key for the "rc-*"
   ciphers is all 16 bytes of Kcc or Kcs; the key for "des" is the first
   7 bytes; the key for "3des" is the first 14 bytes. The IV for "des"
   and "3des" is the last 8 bytes of Kcc or Kcs.

   If message confidentiality is negotiated, each message is encrypted
   with the chosen cipher and a MAC block is appended to the message.

   The MAC block is a variable length padding prefix followed by 16
   bytes formatted as follows: the first 10 bytes of the HMAC-MD5 [RFC
   2104] of the message, a 2-byte message type number in network byte
   order with value 1, and the 4-byte sequence number in network byte
   order. If the blocksize of the chosen cipher is not 1 byte, the
   padding prefix is one or more octets each containing the number of
   padding bytes, such that total length of the encrypted part of the
   message is a multiple of the blocksize. The padding and first 10
   bytes of the MAC block are encrypted along with the message.

   SEAL(Ki, Kc, SeqNum, msg) =
         {CIPHER(Kc, {msg, pad, HMAC(Ki, {SeqNum, msg})[0..9])}), 0x0001,
          SeqNum}

   where CIPHER is the chosen cipher, Ki and Kc are Kic and Kcc for
   messages sent by the client and Kis and Kcs for those sent by the
   server. The sequence number is initialized to zero, and incremented
   by one for each message sent.

   Upon receipt, the message is decrypted, HMAC(Ki, {SeqNum, msg}) is
   computed and compared with the received value; the message is
   discarded if they differ.

3  Security Considerations

3.1   Authentication of Clients using Digest Authentication

   Digest Authentication does not provide a strong authentication
   mechanism, when compared to public key based mechanisms, for example.
   However, since it prevents chosen plaintext attacks, it is stronger
   than (e.g.) CRAM-MD5, which has been proposed for use with LDAP [10],
   POP and IMAP (see RFC 2195 [9]).   It is intended to replace the much
   weaker and even more dangerous use of plaintext passwords; however,
   since it is still a password based mechanism it avoids some of the
   potential deployabilty issues with public-key, OTP or similar
   mechanisms.



Leach & Newman              Standards Track                    [Page 15]

RFC 2831                 Digest SASL Mechanism                  May 2000


   Digest Authentication offers no confidentiality protection beyond
   protecting the actual password. All of the rest of the challenge and
   response are available to an eavesdropper, including the user's name
   and authentication realm.

3.2   Comparison of Digest with Plaintext Passwords

   The greatest threat to the type of transactions for which these
   protocols are used is network snooping. This kind of transaction
   might involve, for example, online access to a mail service whose use
   is restricted to paying subscribers. With plaintext password
   authentication an eavesdropper can obtain the password of the user.
   This not only permits him to access anything in the database, but,
   often worse, will permit access to anything else the user protects
   with the same password.

3.3   Replay Attacks

   Replay attacks are defeated if the client or the server chooses a
   fresh nonce for each authentication, as this specification requires.

3.4  Online dictionary attacks

   If the attacker can eavesdrop, then it can test any overheard
   nonce/response pairs against a (potentially very large) list of
   common words. Such a list is usually much smaller than the total
   number of possible passwords. The cost of computing the response for
   each password on the list is paid once for each challenge.

   The server can mitigate this attack by not allowing users to select
   passwords that are in a dictionary.

3.5  Offline dictionary attacks

   If the attacker can choose the challenge, then it can precompute the
   possible responses to that challenge for a list of common words. Such
   a list is usually much smaller than the total number of possible
   passwords. The cost of computing the response for each password on
   the list is paid just once.

   Offline dictionary attacks are defeated if the client chooses a fresh
   nonce for each authentication, as this specification requires.









Leach & Newman              Standards Track                    [Page 16]

RFC 2831                 Digest SASL Mechanism                  May 2000


3.6  Man in the Middle

   Digest authentication is vulnerable to "man in the middle" (MITM)
   attacks. Clearly, a MITM would present all the problems of
   eavesdropping. But it also offers some additional opportunities to
   the attacker.

   A possible man-in-the-middle attack would be to substitute a weaker
   qop scheme for the one(s) sent by the server; the server will not be
   able to detect this attack. For this reason, the client should always
   use the strongest scheme that it understands from the choices
   offered, and should never choose a scheme that does not meet its
   minimum requirements.

3.7  Chosen plaintext attacks

   A chosen plaintext attack is where a MITM or a malicious server can
   arbitrarily choose the challenge that the client will use to compute
   the response. The ability to choose the challenge is known to make
   cryptanalysis much easier [8].

   However, Digest does not permit the attack to choose the challenge as
   long as the client chooses a fresh nonce for each authentication, as
   this specification requires.

3.8  Spoofing by Counterfeit Servers

   If a user can be led to believe that she is connecting to a host
   containing information protected by a password she knows, when in
   fact she is connecting to a hostile server, then the hostile server
   can obtain challenge/response pairs where it was able to partly
   choose the challenge. There is no known way that this can be
   exploited.

3.9  Storing passwords

   Digest authentication requires that the authenticating agent (usually
   the server) store some data derived from the user's name and password
   in a "password file" associated with a given realm. Normally this
   might contain pairs consisting of username and H({ username-value,
   ":", realm-value, ":", passwd }), which is adequate to compute H(A1)
   as described above without directly exposing the user's password.

   The security implications of this are that if this password file is
   compromised, then an attacker gains immediate access to documents on
   the server using this realm. Unlike, say a standard UNIX password
   file, this information need not be decrypted in order to access
   documents in the server realm associated with this file. On the other



Leach & Newman              Standards Track                    [Page 17]

RFC 2831                 Digest SASL Mechanism                  May 2000


   hand, decryption, or more likely a brute force attack, would be
   necessary to obtain the user's password. This is the reason that the
   realm is part of the digested data stored in the password file. It
   means that if one Digest authentication password file is compromised,
   it does not automatically compromise others with the same username
   and password (though it does expose them to brute force attack).

   There are two important security consequences of this. First the
   password file must be protected as if it contained plaintext
   passwords, because for the purpose of accessing documents in its
   realm, it effectively does.

   A second consequence of this is that the realm string should be
   unique among all realms that any single user is likely to use. In
   particular a realm string should include the name of the host doing
   the authentication.

3.10  Multiple realms

   Use of multiple realms may mean both that compromise of a the
   security database for a single realm does not compromise all
   security, and that there are more things to protect in order to keep
   the whole system secure.

3.11  Summary

   By modern cryptographic standards Digest Authentication is weak,
   compared to (say) public key based mechanisms. But for a large range
   of purposes it is valuable as a replacement for plaintext passwords.
   Its strength may vary depending on the implementation.

4  Example

   This example shows the use of the Digest SASL mechanism with the
   IMAP4 AUTHENTICATE command [RFC 2060].

   In this example, "C:" and "S:" represent a line sent by the client or
   server respectively including a CRLF at the end.  Linebreaks and
   indentation within a "C:" or "S:" are editorial and not part of the
   protocol. The password in this example was "secret".  Note that the
   base64 encoding of the challenges and responses is part of the IMAP4
   AUTHENTICATE command, not part of the Digest specification itself.

    S: * OK elwood.innosoft.com PMDF IMAP4rev1 V6.0-9
    C: c CAPABILITY
    S: * CAPABILITY IMAP4 IMAP4rev1 ACL LITERAL+ NAMESPACE QUOTA
                UIDPLUS AUTH=CRAM-MD5 AUTH=DIGEST-MD5 AUTH=PLAIN
    S: c OK Completed



Leach & Newman              Standards Track                    [Page 18]

RFC 2831                 Digest SASL Mechanism                  May 2000


    C: a AUTHENTICATE DIGEST-MD5
    S: + cmVhbG09ImVsd29vZC5pbm5vc29mdC5jb20iLG5vbmNlPSJPQTZNRzl0
         RVFHbTJoaCIscW9wPSJhdXRoIixhbGdvcml0aG09bWQ1LXNlc3MsY2hh
         cnNldD11dGYtOA==
    C: Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2
       QuaW5ub3NvZnQuY29tIixub25jZT0iT0E2TUc5dEVRR20yaGgiLG5jPTAw
       MDAwMDAxLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLGRpZ2VzdC11cmk9Im
       ltYXAvZWx3b29kLmlubm9zb2Z0LmNvbSIscmVzcG9uc2U9ZDM4OGRhZDkw
       ZDRiYmQ3NjBhMTUyMzIxZjIxNDNhZjcscW9wPWF1dGg=
    S: + cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA==
    C:
    S: a OK User logged in
    ---

    The base64-decoded version of the SASL exchange is:

    S: realm="elwood.innosoft.com",nonce="OA6MG9tEQGm2hh",qop="auth",
       algorithm=md5-sess,charset=utf-8
    C: charset=utf-8,username="chris",realm="elwood.innosoft.com",
       nonce="OA6MG9tEQGm2hh",nc=00000001,cnonce="OA6MHXh6VqTrRk",
       digest-uri="imap/elwood.innosoft.com",
       response=d388dad90d4bbd760a152321f2143af7,qop=auth
    S: rspauth=ea40f60335c427b5527b84dbabcdfffd

    The password in this example was "secret".

   This example shows the use of the Digest SASL mechanism with the
   ACAP, using the same notational conventions and password as in the
   previous example. Note that ACAP does not base64 encode and uses
   fewer round trips that IMAP4.

    S: * ACAP (IMPLEMENTATION "Test ACAP server") (SASL "CRAM-MD5"
               "DIGEST-MD5" "PLAIN")
    C: a AUTHENTICATE "DIGEST-MD5"
    S: + {94}
    S: realm="elwood.innosoft.com",nonce="OA9BSXrbuRhWay",qop="auth",
       algorithm=md5-sess,charset=utf-8
    C: {206}
    C: charset=utf-8,username="chris",realm="elwood.innosoft.com",
       nonce="OA9BSXrbuRhWay",nc=00000001,cnonce="OA9BSuZWMSpW8m",
       digest-uri="acap/elwood.innosoft.com",
       response=6084c6db3fede7352c551284490fd0fc,qop=auth
    S: a OK (SASL {40}
    S: rspauth=2f0b3d7c3c2e486600ef710726aa2eae) "AUTHENTICATE
    Completed"
    ---





Leach & Newman              Standards Track                    [Page 19]

RFC 2831                 Digest SASL Mechanism                  May 2000


   The server uses the values of all the directives, plus knowledge of
   the users password (or the hash of the user's name, server's realm
   and the user's password) to verify the computations above. If they
   check, then the user has authenticated.

5   References

   [Digest]   Franks, J., et al., "HTTP Authentication: Basic and Digest
              Access Authentication", RFC 2617, June 1999.

   [ISO-8859] ISO-8859. International Standard--Information Processing--
              8-bit Single-Byte Coded Graphic Character Sets --
              Part 1: Latin alphabet No. 1, ISO-8859-1:1987.
              Part 2: Latin alphabet No. 2, ISO-8859-2, 1987.
              Part 3: Latin alphabet No. 3, ISO-8859-3, 1988.
              Part 4: Latin alphabet No. 4, ISO-8859-4, 1988.
              Part 5: Latin/Cyrillic alphabet, ISO-8859-5, 1988.
              Part 6: Latin/Arabic alphabet, ISO-8859-6, 1987.
              Part 7: Latin/Greek alphabet, ISO-8859-7, 1987.
              Part 8: Latin/Hebrew alphabet, ISO-8859-8, 1988.
              Part 9: Latin alphabet No. 5, ISO-8859-9, 1990.

   [RFC 822]  Crocker, D., "Standard for The Format of ARPA Internet
              Text Messages," STD 11, RFC 822, August 1982.

   [RFC 1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
              April 1992.

   [RFC 2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
              Part Three: Message Header Extensions for Non-ASCII Text",
              RFC 2047, November 1996.

   [RFC 2052] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the
              location of services (DNS SRV)", RFC 2052, October 1996.

   [RFC 2060] Crispin, M., "Internet Message Access Protocol - Version
              4rev1", RFC 2060, December 1996.

   [RFC 2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:  Keyed-
              Hashing for  Message Authentication", RFC 2104, February
              1997.

   [RFC 2195] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP
              AUTHorize Extension for Simple Challenge/Response", RFC
              2195, September 1997.






Leach & Newman              Standards Track                    [Page 20]

RFC 2831                 Digest SASL Mechanism                  May 2000


   [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC 2222] Myers, J., "Simple Authentication and Security Layer
              (SASL)", RFC 2222, October 1997.

   [USASCII]  US-ASCII. Coded Character Set - 7-Bit American Standard
              Code for Information Interchange. Standard ANSI X3.4-1986,
              ANSI, 1986.

6  Authors' Addresses