rfc2617-htt11.txt

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

   utilized as follows.

       credentials      = "Digest" digest-response
       digest-response  = 1#( username | realm | nonce | digest-uri
                       | response | [ algorithm ] | [cnonce] |
                       [opaque] | [message-qop] |
                           [nonce-count]  | [auth-param] )

       username         = "username" "=" username-value
       username-value   = quoted-string
       digest-uri       = "uri" "=" digest-uri-value
       digest-uri-value = request-uri   ; As specified by HTTP/1.1
       message-qop      = "qop" "=" qop-value
       cnonce           = "cnonce" "=" cnonce-value
       cnonce-value     = nonce-value
       nonce-count      = "nc" "=" nc-value
       nc-value         = 8LHEX
       response         = "response" "=" request-digest
       request-digest = <"> 32LHEX <">
       LHEX             =  "0" | "1" | "2" | "3" |
                           "4" | "5" | "6" | "7" |
                           "8" | "9" | "a" | "b" |
                           "c" | "d" | "e" | "f"

   The values of the opaque and algorithm fields must be those supplied
   in the WWW-Authenticate response header for the entity being
   requested.

   response
     A string of 32 hex digits computed as defined below, which proves
     that the user knows a password

   username
     The user's name in the specified realm.





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


   digest-uri
     The URI from Request-URI of the Request-Line; duplicated here
     because proxies are allowed to change the Request-Line in transit.

   qop
     Indicates what "quality of protection" the client has applied to
     the message. If present, its value MUST be one of the alternatives
     the server indicated it supports in the WWW-Authenticate header.
     These values affect the computation of the request-digest. Note
     that this is a single token, not a quoted list of alternatives as
     in WWW- Authenticate.  This directive is optional in order to
     preserve backward compatibility with a minimal implementation of
     RFC 2069 [6], but SHOULD be used if the server indicated that qop
     is supported by providing a qop directive in the WWW-Authenticate
     header field.

   cnonce
     This MUST be specified if a qop directive is sent (see above), and
     MUST NOT be specified if the server did not send a qop directive in
     the WWW-Authenticate header field.  The cnonce-value is an opaque
     quoted string value provided by the client and used by both client
     and server to avoid chosen plaintext attacks, to provide mutual
     authHTTP/1.0 200 Document Follows
Date: Thu, 20 Jul 2000 01:03:58 GMT
Server: WinGate Engine
Content-Type: text/plain
Content-Length: 77638

entication, and to provide some message integrity protection.
     See the descriptions below of the calculation of the response-
     digest and request-digest values.

   nonce-count
     This MUST be specified if a qop directive is sent (see above), and
     MUST NOT be specified if the server did not send a qop directive in
     the WWW-Authenticate header field.  The nc-value is the hexadecimal
     count of the number of requests (including the current request)
     that the client has sent with the nonce value in this request.  For
     example, in the first request sent in response to a given nonce
     value, the client sends "nc=00000001".  The purpose of this
     directive is to allow the server to detect request replays by
     maintaining its own copy of this count - if the same nc-value is
     seen twice, then the request is a replay.   See the description
     below of the construction of the request-digest value.

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

   If a directive or its value is improper, or required directives are
   missing, the proper response is 400 Bad Request. If the request-
   digest is invalid, then a login failure should be logged, since
   repeated login failures from a single client may indicate an attacker
   attempting to guess passwords.



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


   The definition of request-digest above indicates the encoding for its
   value. The following definitions show how the value is computed.

3.2.2.1 Request-Digest

   If the "qop" value is "auth" or "auth-int":

      request-digest  = <"> < KD ( H(A1),     unq(nonce-value)
                                          ":" nc-value
                                          ":" unq(cnonce-value)
                                          ":" unq(qop-value)
                                          ":" H(A2)
                                  ) <">

   If the "qop" directive is not present (this construction is for
   compatibility with RFC 2069):

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

   See below for the definitions for A1 and A2.

3.2.2.2 A1

   If the "algorithm" directive's value is "MD5" or is unspecified, then
   A1 is:

      A1       = unq(username-value) ":" unq(realm-value) ":" passwd

   where

      passwd   = < user's password >

   If the "algorithm" directive's value is "MD5-sess", then A1 is
   calculated only once - on the first request by the client following
   receipt of a WWW-Authenticate challenge from the server.  It uses the
   server nonce from that challenge, and the first client nonce value to
   construct A1 as follows:

      A1       = H( unq(username-value) ":" unq(realm-value)
                     ":" passwd )
                     ":" unq(nonce-value) ":" unq(cnonce-value)

   This creates a 'session key' for the authentication of subsequent
   requests and responses which is different for each "authentication
   session", thus limiting the amount of material hashed with any one
   key.  (Note: see further discussion of the authentication session in



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


   section 3.3.) Because the server need only use the hash of the user
   credentials in order to create the A1 value, this construction could
   be used in conjunction with a third party authentication service so
   that the web server would not need the actual password value.  The
   specification of such a protocol is beyond the scope of this
   specification.

3.2.2.3 A2

   If the "qop" directive's value is "auth" or is unspecified, then A2
   is:

      A2       = Method ":" digest-uri-value

   If the "qop" value is "auth-int", then A2 is:

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

3.2.2.4 Directive values and quoted-string

   Note that the value of many of the directives, such as "username-
   value", are defined as a "quoted-string". However, the "unq" notation
   indicates that 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 "Circle Of Life" then H(A1) would be
   H(Mufasa:[e-mail]:Circle Of Life) 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 illustrated above must be

        Mufasa:[e-mail]:Circle Of Life

   with no white space on either side of the colons, but with the white
   space between the words used in the password value.  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.

   Also note that if integrity protection is applied (qop=auth-int), the
   H(entity-body) is the hash of the entity body, not the message body -
   it is computed before any transfer encoding is applied by the sender




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


   and after it has been removed by the recipient. Note that this
   includes multipart boundaries and embedded headers in each part of
   any multipart content-type.

3.2.2.5 Various considerations

   The "Method" value is the HTTP request method as specified in section
   5.1.1 of [2]. The "request-uri" value is the Request-URI from the
   request line as specified in section 5.1.2 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
   "cnonce-value" is an optional  client-chosen value whose purpose is
   to foil chosen plaintext attacks.

   The authenticating server must assure that the resource designated by
   the "uri" directive is the same as the resource specified in the
   Request-Line; if they are not, the server SHOULD return a 400 Bad
   Request error. (Since this may be a symptom of an attack, server
   implementers may want to consider logging such errors.) 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-Line. This altered (but presumably semantically
   equivalent) request would not result in the same digest as that
   calculated by the client.

   Implementers should be aware of how authenticated transactions
   interact with shared caches. The HTTP/1.1 protocol specifies that
   when a shared cache (see section 13.7 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.

3.2.3 The Authentication-Info Header

   The Authentication-Info header is used by the server to communicate
   some information regarding the successful authentication in the
   response.





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


        AuthenticationInfo = "Authentication-Info" ":" auth-info
        auth-info          = 1#(nextnonce | [ message-qop ]
                               | [ response-auth ] | [ cnonce ]
                               | [nonce-count] )
        nextnonce          = "nextnonce" "=" nonce-value
        response-auth      = "rspauth" "=" response-digest
        response-digest    = <"> *LHEX <">

   The value of the nextnonce directive is the nonce the server wishes
   the client to use for a future authentication response.  The server
   may send the Authentication-Info header with a nextnonce field as a
   means of implementing one-time or otherwise changing  nonces. If the
   nextnonce field is present the client SHOULD use it when constructing
   the Authorization header for its next request. Failure of the client
   to do so may result in a request to re-authenticate from the server