rfc2617-htt11.txt

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

      password    = *TEXT

   Userids might be case sensitive.

   If the user agent wishes to send the userid "Aladdin" and password
   "open sesame", it would use the following header field:

      Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

   A client SHOULD assume that all paths at or deeper than the depth of
   the last symbolic element in the path field of the Request-URI also
   are within the protection space specified by the Basic realm value of
   the current challenge. A client MAY preemptively send the
   corresponding Authorization header with requests for resources in
   that space without receipt of another challenge from the server.
   Similarly, when a client sends a request to a proxy, it may reuse a
   userid and password in the Proxy-Authorization header field without
   receiving another challenge from the proxy server. See section 4 for
   security considerations associated with Basic authentication.

3 Digest Access Authentication Scheme

3.1 Introduction

3.1.1 Purpose

   The protocol referred to as "HTTP/1.0" includes the specification for
   a Basic Access Authentication scheme[1]. That scheme is not
   considered to be a secure method of user authentication, as the user
   name and password are passed over the network in an unencrypted form.
   This section provides the specification for a scheme that does not
   send the password in cleartext,  referred to as "Digest Access
   Authentication".

   The Digest Access Authentication scheme is not intended to be a
   complete answer to the need for security in the World Wide Web. This
   scheme provides no encryption of message content. The intent is
   simply to create an access authentication method that avoids the most
   serious flaws of Basic authentication.

3.1.2 Overall Operation

   Like Basic Access Authentication, the Digest scheme is based on a
   simple challenge-response paradigm. The Digest scheme challenges
   using a nonce value. A valid response contains a checksum (by



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


   default, the MD5 checksum) of the username, the password, the given
   nonce value, the HTTP method, and the requested URI. In this way, the
   password is never sent in the clear. Just as with the Basic scheme,
   the username and password must be prearranged in some fashion not
   addressed by this document.

3.1.3 Representation of digest values

   An optional header allows the server to specify the algorithm used to
   create the checksum or digest. By default the MD5 algorithm is used
   and that is the only algorithm described in this document.

   For the purposes of this document, an MD5 digest of 128 bits is
   represented as 32 ASCII printable characters. The bits in the 128 bit
   digest are converted from most significant to least significant bit,
   four bits at a time to their ASCII presentation as follows. Each four
   bits is represented by its familiar hexadecimal notation from the
   characters 0123456789abcdef. That is, binary 0000 gets represented by
   the character '0', 0001, by '1', and so on up to the representation
   of 1111 as 'f'.

3.1.4 Limitations

   The Digest authentication scheme described in this document suffers
   from many known limitations. It is intended as a replacement for
   Basic authentication and nothing more. It is a password-based system
   and (on the server side) suffers from all the same problems of any
   password system. In particular, no provision is made in this protocol
   for the initial secure arrangement between user and server to
   establish the user's password.

   Users and implementors should be aware that this protocol is not as
   secure as Kerberos, and not as secure as any client-side private-key
   scheme. Nevertheless it is better than nothing, better than what is
   commonly used with telnet and ftp, and better than Basic
   authentication.

3.2 Specification of Digest Headers

   The Digest Access Authentication scheme is conceptually similar to
   the Basic scheme. The formats of the modified WWW-Authenticate header
   line and the Authorization header line are specified below. In
   addition, a new header, Authentication-Info, is specified.








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


3.2.1 The WWW-Authenticate Response Header

   If a server receives a request for an access-protected object, and an
   acceptable Authorization header is not sent, the server responds with
   a "401 Unauthorized" status code, and a WWW-Authenticate header as
   per the framework defined above, which for the digest scheme is
   utilized as follows:

      challenge        =  "Digest" digest-challenge

      digest-challenge  = 1#( realm | [ domain ] | nonce |
                          [ opaque ] |[ stale ] | [ algorithm ] |
                          [ qop-options ] | [auth-param] )


      domain            = "domain" "=" <"> URI ( 1*SP URI ) <">
      URI               = absoluteURI | abs_path
      nonce             = "nonce" "=" nonce-value
      nonce-value       = quoted-string
      opaque            = "opaque" "=" quoted-string
      stale             = "stale" "=" ( "true" | "false" )
      algorithm         = "algorithm" "=" ( "MD5" | "MD5-sess" |
                           token )
      qop-options       = "qop" "=" <"> 1#qop-value <">
      qop-value         = "auth" | "auth-int" | token

   The meanings of the values of the directives used above are as
   follows:

   realm
     A string to be displayed to users so they know which username and
     password to use. 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]".

   domain
     A quoted, space-separated list of URIs, as specified in RFC XURI
     [7], that define the protection space.  If a URI is an abs_path, it
     is relative to the canonical root URL (see section 1.2 above) of
     the server being accessed. An absoluteURI in this list may refer to
     a different server than the one being accessed. The client can use
     this list to determine the set of URIs for which the same
     authentication information may be sent: any URI that has a URI in
     this list as a prefix (after both have been made absolute) may be
     assumed to be in the same protection space. If this directive is
     omitted or its value is empty, the client should assume that the
     protection space consists of all URIs on the responding server.



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


     This directive is not meaningful in Proxy-Authenticate headers, for
     which the protection space is always the entire proxy; if present
     it should be ignored.

   nonce
     A server-specified data string which should be uniquely generated
     each time a 401 response is made. It is recommended that this
     string be base64 or hexadecimal data. Specifically, since the
     string is passed in the header lines as a quoted string, the
     double-quote character is not allowed.

     The contents of the nonce are implementation dependent. The quality
     of the implementation depends on a good choice. A nonce might, for
     example, be constructed as the base 64 encoding of

         time-stamp H(time-stamp ":" ETag ":" private-key)

     where time-stamp is a server-generated time or other non-repeating
     value, ETag is the value of the HTTP ETag header associated with
     the requested entity, and private-key is data known only to the
     server.  With a nonce of this form a server would recalculate the
     hash portion after receiving the client authentication header and
     reject the request if it did not match the nonce from that header
     or if the time-stamp value is not recent enough. In this way the
     server can limit the time of the nonce's validity. The inclusion of
     the ETag prevents a replay request for an updated version of the
     resource.  (Note: including the IP address of the client in the
     nonce would appear to offer the server the ability to limit the
     reuse of the nonce to the same client that originally got it.
     However, that would break proxy farms, where requests from a single
     user often go through different proxies in the farm. Also, IP
     address spoofing is not that hard.)

     An implementation might choose not to accept a previously used
     nonce or a previously used digest, in order to protect against a
     replay attack. Or, an implementation might choose to use one-time
     nonces or digests for POST or PUT requests and a time-stamp for GET
     requests.  For more details on the issues involved see section 4.
     of this document.

     The nonce is opaque to the client.

   opaque
     A string of data, specified by the server, which should be returned
     by the client unchanged in the Authorization header of subsequent
     requests with URIs in the same protection space. It is recommended
     that this string be base64 or hexadecimal data.




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


   stale
     A flag, indicating that the previous request from the client was
     rejected because the nonce value was stale. If stale is TRUE
     (case-insensitive), the client may wish to simply retry the request
     with a new encrypted response, without reprompting the user for a
     new username and password. The server should only set stale to TRUE
     if it receives a request for which the nonce is invalid but with a
     valid digest for that nonce (indicating that the client knows the
     correct username/password). If stale is FALSE, or anything other
     than TRUE, or the stale directive is not present, the username
     and/or password are invalid, and new values must be obtained.

   algorithm
     A string indicating a pair of algorithms used to produce the digest
     and a checksum. If this is not present it is assumed to be "MD5".
     If the algorithm is not understood, the challenge should be ignored
     (and a different one used, if there is more than one).

     In this document the string obtained by applying the digest
     algorithm to the data "data" with secret "secret" will be denoted
     by KD(secret, data), and the string obtained by applying the
     checksum algorithm to the data "data" will be denoted H(data). The
     notation unq(X) means the value of the quoted-string X without the
     surrounding quotes.

     For the "MD5" and "MD5-sess" algorithms

         H(data) = MD5(data)

     and

         KD(secret, data) = H(concat(secret, ":", data))

     i.e., the digest is the MD5 of the secret concatenated with a colon
     concatenated with the data. The "MD5-sess" algorithm is intended to
     allow efficient 3rd party authentication servers; for the
     difference in usage, see the description in section 3.2.2.2.

   qop-options
     This directive is optional, but is made so only for backward
     compatibility with RFC 2069 [6]; it SHOULD be used by all
     implementations compliant with this version of the Digest scheme.
     If present, it is 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; see the





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


     descriptions below for calculating the response directive value for
     the application of this choice. Unrecognized options MUST be
     ignored.

   auth-param
     This directive allows for future extensions. Any unrecognized
     directive MUST be ignored.

3.2.2 The Authorization Request Header

   The client is expected to retry the request, passing an Authorization
   header line, which is defined according to the framework above,