rfc2069.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.


RFC 2069              Digest Access Authentication          January 1997


     response-digest     =
          <"> < KD ( H(A1), unquoted nonce-value ":" H(A2) > <">

     A1             = unquoted username-value ":" unquoted realm-value
                                                ":" password
     password       = < user's password >
     A2             = Method ":" digest-uri-value

   The "username-value" field is a "quoted-string" as specified in
   section 2.2 of the HTTP/1.1 specification [2].  However, the
   surrounding quotation marks are removed in forming the string A1.
   Thus if the Authorization header includes the fields

    username="Mufasa", realm="[e-mail]"

   and the user Mufasa has password "CircleOfLife" then H(A1) would be
   H(Mufasa:[e-mail]:CircleOfLife) with no quotation marks
   in the digested string.

   No white space is allowed in any of the strings to which the digest
   function H() is applied unless that white space exists in the quoted
   strings or entity body whose contents make up the string to be
   digested.  For example, the string A1 in the illustrated above must
   be Mufasa:[e-mail]:CircleOfLife with no white space on
   either side of the colons.  Likewise, the other strings digested by
   H() must not have white space on either side of the colons which
   delimit their fields unless that white space was in the quoted
   strings or entity body being digested.

   "Method" is the HTTP request method as specified in section 5.1 of
   [2].  The "request-uri" value is the Request-URI from the request
   line as specified in section 5.1 of [2].  This may be "*", an
   "absoluteURL" or an "abs_path" as specified in section 5.1.2 of [2],
   but it MUST agree with the Request-URI. In particular, it MUST be an
   "absoluteURL" if the Request-URI is an "absoluteURL".

   The authenticating server must assure that the document designated by
   the "uri" parameter is the same as the document served.  The purpose
   of duplicating information from the request URL in this field is to
   deal with the possibility that an intermediate proxy may alter the
   client's request.  This altered (but presumably semantically
   equivalent) request would not result in the same digest as that
   calculated by the client.

   The optional "digest" field contains a digest of the entity body and
   some of the associated entity headers.  This digest can be useful in
   both request and response transactions.  In a request it can insure
   the integrity of POST data or data being PUT to the server.  In a



Franks, et. al.             Standards Track                     [Page 7]

RFC 2069              Digest Access Authentication          January 1997


   response it insures the integrity of the served document.  The value
   of the "digest" field is an <entity-digest> which is defined as
   follows.

entity-digest = <"> KD (H(A1), unquoted nonce-value ":" Method ":"
                           date ":" entity-info ":" H(entity-body)) <">
       ; format is <"> *LHEX <">

date = = rfc1123-date            ; see section 3.3.1 of [2]
entity-info = H(
          digest-uri-value ":"
          media-type ":"         ; Content-type, see section 3.7 of [2]
          *DIGIT ":"             ; Content length, see 10.12 of [2]
          content-coding ":"     ; Content-encoding, see 3.5 of [2]
          last-modified ":"      ; last modified date, see 10.25 of [2]
          expires                ; expiration date; see 10.19 of [2]
          )

last-modified   = rfc1123-date  ; see section 3.3.1 of [2]
expires         = rfc1123-date

   The entity-info elements incorporate the values of the URI used to
   request the entity as well as the associated entity headers Content-
   type, Content-length, Content-encoding, Last-modified, and Expires.
   These headers are all end-to-end headers (see section 13.5.1 of [2])
   which must not be modified by proxy caches.  The "entity-body" is as
   specified by section 10.13 of [2] or RFC 1864.

   Note that not all entities will have an associated URI or all of
   these headers.  For example, an entity which is the data of a POST
   request will typically not have a digest-uri-value or Last-modified
   or Expires headers.  If an entity does not have a digest-uri-value or
   a header corresponding to one of the entity-info fields, then that
   field is left empty in the computation of entity-info.  All the
   colons specified above are present, however.  For example the value
   of the entity-info associated with POST data which has content-type
   "text/plain", no content-encoding and a length of 255 bytes would be
   H(:text/plain:255:::).  Similarly a request may not have a "Date"
   header.  In this case the date field of the entity-digest should be
   empty.

   In the entity-info and entity-digest computations, except for the
   blank after the comma in "rfc1123-date", there must be no white space
   between "words" and "tspecials", and exactly one blank between
   "words" (see section 2.2 of [2]).






Franks, et. al.             Standards Track                     [Page 8]

RFC 2069              Digest Access Authentication          January 1997


   Implementors should be aware of how authenticated transactions
   interact with proxy caches.  The HTTP/1.1 protocol specifies that
   when a shared cache (see section 13.10 of [2]) has received a request
   containing an Authorization header and a response from relaying that
   request, it MUST NOT return that response as a reply to any other
   request, unless one of two Cache-control (see section 14.9 of [2])
   directives was present in the response.  If the original response
   included the "must-revalidate" Cache-control directive, the cache MAY
   use the entity of that response in replying to a subsequent request,
   but MUST first revalidate it with the origin server, using the
   request headers from the new request to allow the origin server to
   authenticate the new request.  Alternatively, if the original
   response included the "public" Cache-control directive, the response
   entity MAY be returned in reply to any subsequent request.

2.1.3 The AuthenticationInfo Header

   When authentication succeeds, the Server may optionally provide a
   Authentication-info header indicating that the server wants to
   communicate some information regarding the successful authentication
   (such as an entity digest or a new nonce to be used for the next
   transaction).  It has two fields, digest and nextnonce.  Both are
   optional.

    AuthenticationInfo = "Authentication-info" ":"
                                      1#( digest | nextnonce )

    nextnonce      = "nextnonce" "=" nonce-value

    digest = "digest" "=" entity-digest

   The optional digest allows the client to verify that the body of the
   response has not been changed en-route.  The server would probably
   only send this when it has the document and can compute it.  The
   server would probably not bother generating this header for CGI
   output.  The value of the "digest" is an <entity-digest> which is
   computed as described above.

   The value of the nextnonce parameter is the nonce the server wishes
   the client to use for the next authentication response.  Note that
   either field is optional.  In particular the server may send the
   Authentication-info header with only the nextnonce field as a means
   of implementing one-time nonces.  If the nextnonce field is present
   the client is strongly encouraged to use it for the next WWW-
   Authenticate header.  Failure of the client to do so may result in a
   request to re-authenticate from the server with the "stale=TRUE."





Franks, et. al.             Standards Track                     [Page 9]

RFC 2069              Digest Access Authentication          January 1997


2.2 Digest Operation

   Upon receiving the Authorization header, the server may check its
   validity by looking up its known password which corresponds to the
   submitted username.  Then, the server must perform the same MD5
   operation performed by the client, and compare the result to the
   given response-digest.

   Note that the HTTP server does not actually need to know the user's
   clear text password.  As long as H(A1) is available to the server,
   the validity of an Authorization header may be verified.

   A client may remember the username, password and nonce values, so
   that future requests within the specified <domain> may include the
   Authorization header preemptively.  The server may choose to accept
   the old Authorization header information, even though the nonce value
   included might not be fresh. Alternatively, the server could return a
   401 response with a new nonce value, causing the client to retry the
   request.  By specifying stale=TRUE with this response, the server
   hints to the client that the request should be retried with the new
   nonce, without reprompting the user for a new username and password.

   The opaque data is useful for transporting state information around.
   For example, a server could be responsible for authenticating content
   which actually sits on another server.  The first 401 response would
   include a domain field which includes the URI on the second server,
   and the opaque field for specifying state information.  The client
   will retry the request, at which time the server may respond with a
   301/302 redirection, pointing to the URI on the second server.  The
   client will follow the redirection, and pass the same Authorization
   header, including the <opaque> data which the second server may
   require.

   As with the basic scheme, proxies must be completely transparent in
   the Digest access authentication scheme. That is, they must forward
   the WWW-Authenticate, Authentication-info and Authorization headers
   untouched. If a proxy wants to authenticate a client before a request
   is forwarded to the server, it can be done using the Proxy-
   Authenticate and Proxy-Authorization headers described in section 2.5
   below.

2.3 Security Protocol Negotiation

   It is useful for a server to be able to know which security schemes a
   client is capable of handling.

   If this proposal is accepted as a required part of the HTTP/1.1
   specification, then a server may assume Digest support when a client



Franks, et. al.             Standards Track                    [Page 10]

RFC 2069              Digest Access Authentication          January 1997


   identifies itself as HTTP/1.1 compliant.

   It is possible that a server may want to require Digest as its
   authentication method, even if the server does not know that the
   client supports it.  A client is encouraged to fail gracefully if the
   server specifies any authentication scheme it cannot handle.

2.4 Example

   The following example assumes that an access-protected document is
   being requested from the server.  The URI of the document is
   "http://www.nowhere.org/dir/index.html".  Both client and server know
   that the username for this document is "Mufasa", and the password is
   "CircleOfLife".

   The first time the client requests the document, no Authorization
   header is sent, so the server responds with:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest    realm="[e-mail]",
                            nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
                            opaque="5ccc069c403ebaf9f0171e9517f40e41"

  The client may prompt the user for the username and password, after
  which it will respond with a new request, including the following
  Authorization header:

Authorization: Digest       username="Mufasa",
                            realm="[e-mail]",
                            nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
                            uri="/dir/index.html",
                            response="e966c932a9242554e42c8ee200cec7f6",
                            opaque="5ccc069c403ebaf9f0171e9517f40e41"

2.5 Proxy-Authentication and Proxy-Authorization

   The digest authentication scheme may also be used for authenticating
   users to proxies, proxies to proxies, or proxies to end servers by
   use of the Proxy-Authenticate and Proxy-Authorization headers. These
   headers are instances of the general Proxy-Authenticate and Proxy-
   Authorization headers specified in sections 10.30 and 10.31 of the
   HTTP/1.1 specification [2] and their behavior is subject to
   restrictions described there.  The transactions for proxy
   authentication are very similar to those already described.  Upon
   receiving a request which requires authentication, the proxy/server
   must issue the "HTTP/1.1 401 Unauthorized" header followed by a
   "Proxy-Authenticate" header of the form




Franks, et. al.             Standards Track                    [Page 11]

RFC 2069              Digest Access Authentication          January 1997


     Proxy-Authentication     = "Proxy-Authentication" ":" "Digest"
                                   digest-challenge

   where digest-challenge is as defined above in section 2.1. The
   client/proxy must then re-issue the request with a Proxy-Authenticate
   header of the form

     Proxy-Authorization      = "Proxy-Authorization" ":"
                                   digest-response

   where digest-response is as defined above in section 2.1. When
   authentication succeeds, the Server may optionally provide a Proxy-
   Authentication-info header of the form

Proxy-Authentication-info = "Proxy-Authentication-info" ":" nextnonce

   where nextnonce has the same semantics as the nextnonce field in the
   Authentication-info header described above in section 2.1.

   Note that in principle a client could be asked to authenticate itself
   to both a proxy and an end-server.  It might receive an "HTTP/1.1 401
   Unauthorized" header followed by both a WWW-Authenticate and a
   Proxy-Authenticate header.  However, it can never receive more than
   one Proxy-Authenticate header since such headers are only for
   immediate connections and must not be passed on by proxies.  If the
   client receives both headers, it must respond with both the
   Authorization and Proxy-Authorization headers as described above,
   which will likely involve different combinations of username,
   password, nonce, etc.

3. Security Considerations

   Digest Authentication does not provide a strong authentication
   mechanism.  That is not its intent.  It is intended solely to replace
   a much weaker and even more dangerous authentication mechanism: Basic
   Authentication.  An important design constraint is that the new
   authentication scheme be free of patent and export restrictions.

   Most needs for secure HTTP transactions cannot be met by Digest
   Authentication.  For those needs SSL or SHTTP are more appropriate
   protocols.  In particular digest authentication cannot be used for
   any transaction requiring encrypted content.  Nevertheless many
   functions remain for which digest authentication is both useful and
   appropriate.







Franks, et. al.             Standards Track                    [Page 12]

RFC 2069              Digest Access Authentication          January 1997