rfc2617-htt11.txt

串口配置工具 ·作车牌识别的人一定要看

   with the "stale=TRUE".

     Server implementations should carefully consider the performance
     implications of the use of this mechanism; pipelined requests will
     not be possible if every response includes a nextnonce directive
     that must be used on the next request received by the server.
     Consideration should be given to the performance vs. security
     tradeoffs of allowing an old nonce value to be used for a limited
     time to permit request pipelining.  Use of the nonce-count can
     retain most of the security advantages of a new server nonce
     without the deleterious affects on pipelining.

   message-qop
     Indicates the "quality of protection" options applied to the
     response by the server.  The value "auth" indicates authentication;
     the value "auth-int" indicates authentication with integrity
     protection. The server SHOULD use the same value for the message-
     qop directive in the response as was sent by the client in the
     corresponding request.

   The optional response digest in the "response-auth" directive
   supports mutual authentication -- the server proves that it knows the
   user's secret, and with qop=auth-int also provides limited integrity
   protection of the response. The "response-digest" value is calculated
   as for the "request-digest" in the Authorization header, except that
   if "qop=auth" or is not specified in the Authorization header for the
   request, A2 is

      A2       = ":" digest-uri-value

   and if "qop=auth-int", then A2 is

      A2       = ":" digest-uri-value ":" H(entity-body)



Franks, et al.              Standards Track                    [Page 16]

RFC 2617                  HTTP Authentication                  June 1999


   where "digest-uri-value" is the value of the "uri" directive on the
   Authorization header in the request. The "cnonce-value" and "nc-
   value" MUST be the ones for the client request to which this message
   is the response. The "response-auth", "cnonce", and "nonce-count"
   directives MUST BE present if "qop=auth" or "qop=auth-int" is
   specified.

   The Authentication-Info header is allowed in the trailer of an HTTP
   message transferred via chunked transfer-coding.

3.3 Digest Operation

   Upon receiving the Authorization header, the server may check its
   validity by looking up the password that corresponds to the submitted
   username. Then, the server must perform the same digest operation
   (e.g., MD5) performed by the client, and compare the result to the
   given request-digest value.

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

   The client response to a WWW-Authenticate challenge for a protection
   space starts an authentication session with that protection space.
   The authentication session lasts until the client receives another
   WWW-Authenticate challenge from any server in the protection space. A
   client should remember the username, password, nonce, nonce count and
   opaque values associated with an authentication session to use to
   construct the Authorization header in future requests within that
   protection space. The Authorization header may be included
   preemptively; doing so improves server efficiency and avoids extra
   round trips for authentication challenges. The server may choose to
   accept the old Authorization header information, even though the
   nonce value included might not be fresh. Alternatively, the server
   may 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 tells the client to retry with the new nonce, but without
   prompting for a new username and password.

   Because the client is required to return the value of the opaque
   directive given to it by the server for the duration of a session,
   the opaque data may be used to transport authentication session state
   information. (Note that any such use can also be accomplished more
   easily and safely by including the state in the nonce.) For example,
   a server could be responsible for authenticating content that
   actually sits on another server. It would achieve this by having the
   first 401 response include a domain directive whose value includes a
   URI on the second server, and an opaque directive whose value



Franks, et al.              Standards Track                    [Page 17]

RFC 2617                  HTTP Authentication                  June 1999


   contains the state information. The client will retry the request, at
   which time the server might respond with a 301/302 redirection,
   pointing to the URI on the second server. The client will follow the
   redirection, and pass an Authorization header , including the
   <opaque> data.

   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 3.6
   below.

3.4 Security Protocol Negotiation

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

   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 only authentication schemes it cannot handle.

3.5 Example

   The following example assumes that an access-protected document is
   being requested from the server via a GET request. 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 "Circle Of Life" (with one space between each of the
   three words).

   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]",
                 qop="auth,auth-int",
                 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:





Franks, et al.              Standards Track                    [Page 18]

RFC 2617                  HTTP Authentication                  June 1999


         Authorization: Digest username="Mufasa",
                 realm="[e-mail]",
                 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
                 uri="/dir/index.html",
                 qop=auth,
                 nc=00000001,
                 cnonce="0a4f113b",
                 response="6629fae49393a05397450978507c4ef1",
                 opaque="5ccc069c403ebaf9f0171e9517f40e41"

3.6 Proxy-Authentication and Proxy-Authorization

   The digest authentication scheme may also be used for authenticating
   users to proxies, proxies to proxies, or proxies to origin servers by
   use of the Proxy-Authenticate and Proxy-Authorization headers. These
   headers are instances of the Proxy-Authenticate and Proxy-
   Authorization headers specified in sections 10.33 and 10.34 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 "407 Proxy Authentication Required" response with a
   "Proxy-Authenticate" header.  The digest-challenge used in the
   Proxy-Authenticate header is the same as that for the WWW-
   Authenticate header as defined above in section 3.2.1.

   The client/proxy must then re-issue the request with a Proxy-
   Authorization header, with directives as specified for the
   Authorization header in section 3.2.2 above.

   On subsequent responses, the server sends Proxy-Authentication-Info
   with directives the same as those for the Authentication-Info header
   field.

   Note that in principle a client could be asked to authenticate itself
   to both a proxy and an end-server, but never in the same response.

4 Security Considerations

4.1 Authentication of Clients using Basic Authentication

   The Basic authentication scheme is not a secure method of user
   authentication, nor does it in any way protect the entity, which is
   transmitted in cleartext across the physical network used as the
   carrier. HTTP does not prevent additional authentication schemes and
   encryption mechanisms from being employed to increase security or the
   addition of enhancements (such as schemes to use one-time passwords)
   to Basic authentication.



Franks, et al.              Standards Track                    [Page 19]

RFC 2617                  HTTP Authentication                  June 1999


   The most serious flaw in Basic authentication is that it results in
   the essentially cleartext transmission of the user's password over
   the physical network. It is this problem which Digest Authentication
   attempts to address.

   Because Basic authentication involves the cleartext transmission of
   passwords it SHOULD NOT be used (without enhancements) to protect
   sensitive or valuable information.

   A common use of Basic authentication is for identification purposes
   -- requiring the user to provide a user name and password as a means
   of identification, for example, for purposes of gathering accurate
   usage statistics on a server. When used in this way it is tempting to
   think that there is no danger in its use if illicit access to the
   protected documents is not a major concern. This is only correct if
   the server issues both user name and password to the users and in
   particular does not allow the user to choose his or her own password.
   The danger arises because naive users frequently reuse a single
   password to avoid the task of maintaining multiple passwords.

   If a server permits users to select their own passwords, then the
   threat is not only unauthorized access to documents on the server but
   also unauthorized access to any other resources on other systems that
   the user protects with the same password. Furthermore, in the
   server's password database, many of the passwords may also be users'
   passwords for other sites. The owner or administrator of such a
   system could therefore expose all users of the system to the risk of
   unauthorized access to all those sites if this information is not
   maintained in a secure fashion.

   Basic Authentication is also vulnerable to spoofing by counterfeit
   servers. If a user can be led to believe that he is connecting to a
   host containing information protected by Basic authentication when,
   in fact, he is connecting to a hostile server or gateway, then the
   attacker can request a password, store it for later use, and feign an
   error. This type of attack is not possible with Digest
   Authentication. Server implementers SHOULD guard against the
   possibility of this sort of counterfeiting by gateways or CGI
   scripts. In particular it is very dangerous for a server to simply
   turn over a connection to a gateway.  That gateway can then use the
   persistent connection mechanism to engage in multiple transactions
   with the client while impersonating the original server in a way that
   is not detectable by the client.

4.2 Authentication of Clients using Digest Authentication

   Digest Authentication does not provide a strong authentication
   mechanism, when compared to public key based mechanisms, for example.



Franks, et al.              Standards Track                    [Page 20]

RFC 2617                  HTTP Authentication                  June 1999


   However, it is significantly 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 Basic mechanism.

   Digest Authentication offers no confidentiality protection beyond
   protecting the actual password. All of the rest of the request and
   response are available to an eavesdropper.

   Digest Authentication offers only limited integrity protection for
   the messages in either direction. If  qop=auth-int mechanism is used,
   those parts of the message used in the calculation of the WWW-
   Authenticate and Authorization header field response directive values
   (see section 3.2 above) are  protected.  Most header fields and their
   values could be modified as a part of a man-in-the-middle attack.

   Many needs for secure HTTP transactions cannot be met by Digest
   Authentication. For those needs TLS or SHTTP are more appropriate
   protocols. In particular Digest authentication cannot be used for any
   transaction requiring confidentiality protection.  Nevertheless many
   functions remain for which Digest authentication is both useful and
   appropriate.  Any service in present use that uses Basic should be
   switched to Digest as soon as practical.