Auth-param
This instruction is used for future expansion. Any indication that cannot be identified must be ignored.
3.2.2 Authorization Request Header (The Authorization Request Header)
The client wants to retry the send request and pass the authorized header line defined by the previous frame, 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 value of the Opaque field and algorithm domain must be given in the WWW-authentication response header of the requested entity.
Response
It is a string that consists of 32 calculated 16-based numbers to prove whether the user knows the password.
Username
User name is the specified Realm item.
Franks, et al. Standards TRACK [Page 11]
Digest-URI
The URI obtained from the request queue (Request-line); there is a replica because the proxy (Proxy) allows you to modify the request queue when transmitting.
QOP
Indicates the client's protection grade for the message application (Quality of Protection). If it is not empty, its value must be one of several values that the server supports in the WWW-authentication header. These values affect the computation of request-classification (Request-Digest). Note that this is a separate symbol, not like WWW-Authenticate, is a list of optional values with quotation marks. This indication is optional, which is for the minimum implementation of the minimum implementation of the RFC 2069 [6]. However, if the server is added to add a QOP instruction in the WWW-Authenticate Title domain, the server supports QOP, and thus this item must be used. Cnonce
When the QOP indication is sent (see above), the indication must be specified, and when the server end does not add a QOP instruction in the WWW-Authenticate Title domain, the indication must not be specified. Cnonce-Value is a string provided by the client, which is used by the client and the server to avoid selecting a plain text attack, providing common authentication, providing integrity protection of certain messages. See the following response classification value and the request--Digest value calculation of the RESPONSE-Digest value.
Nonce-count
When the QOP indication is sent (see above), the indication must be specified, and when the server end does not add a QOP instruction in the WWW-Authenticate Title domain, the indication must not be specified. Nc-value is the count value indicated by the 16-based, used to count the number of requests (including the current request) with the Nonce value sent by the client. For example, the value of Nonce is given in the first request response, and the client sends "NC = 00000001", the purpose is to allow the server to detect the request repetition by maintenance of this calculation copy, that is, the same NC-Value appears twice, the request is playable. See the Request-Digest value of the request for details.
Auth-param
This instruction is used for future expansion. Any instructions that cannot be identified should be ignored.
If the indication or its value is incorrect, or if the required instruction is not given, it will receive a 400 (illegal request) response. If the request - classification is illegal, the login failed will be recorded in the log because the repeated login fails in a separate client may mean that the attacker is trying to guess the password.
FRANKS, ET Al. Standards Track [Page 12] Request-Digest indicates its encoding mode. The following definition will indicate how these values participate in calculations.
3.2.2.1 Request - Classification (Request-Digest)
If the "QOP" value is "auth" or "auth-int":
Request-Digest = <"> ":" NC-Value ":" unq (cnonce-value) ":" QOP-VALUE ":" h (a2) <"> If the "QOP" indicates that there is no given (holding compatibility with RFC 2069): Request-Digest = <"> ":" H (a2) <"> The definitions of A1 and A2 are below. 3.2.2.2 A1 If the algorithm ("Algorithm") is "MD5" or not specified, A1 is: A1 = UNAME-VALUE ":" unq (realm-value): "Passwd among them Passwd = If the "algorithm" value is "MD5-sess", A1 is calculated as long as the client is calculated, and the first request is issued, and the server receives the WWW-Authenticate challenge (CHALLLENGE). It uses the server of the server in this question, the first client Nonce value used to build A1 should be: A1 = h (Username-Value ":" UNQ (Realm-Value) ":" Passwd) ":" UNCE-VALUE ":" unq (cnonce-value) The above formula generates a 'session key' (session key) for concurrent requests and responses, which is different for each 'authentication session', so that it limits any key to any key. The number of hash processes (Note: Different sessions have a deeper discussion to see Section 3.3). Franks, et al. Standards TRACK [Page 13] Because the server only needs to use the hash value of the user trusted to generate a A1 value, the mechanism can allow third parties to participate in the authentication service so that the web server no longer needs the actual password value. The specification of the protocol has exceeded the scope of this specification. 3.2.2.3 A2 If the "QOP" value is "auth" or not given, then A2: A2 = Method ":" Digest-Uri-Value If the "QOP" value is "auth-int", A2: A2 = Method ":" Digest-Uri-Value ":" H (entity-body) 3.2.2.4 Indicates the value of the string with quotes (Directive Values and quoted-string) Note that many indicated values, such as "User-Value", etc., is defined as quoted-string. In fact, "UNQ" comment indicates that the exterior quotation is removed when the string A1 is generated. Thus, if the authorization title includes this domain, such as: Username = "mufasa", realm=myhost@testrealm.com indicates that the user MUFASA's password is "circle of life", which h (a1) can be represented. H (Mufasa: MyHost@testrealm.com: Circle of Life), note that there is no quotation in the classified string. Note that a space is not allowed in the string in the classification function h (), unless the space appears in the character string with quotation marks or to mark the string classification. For example, the string A1 that appears above must be Mufasa: myhost@testrealm.com: Circle of Life There is no space on both sides of the colon, but spaces are allowed between password words (Circle SP OF SP LIFE). Likewise, other strings classified by the H () are also impossible to bind their sparkles between the colon separated between the domain, unless the space is within the quotation or classified entity main body. It is also important to note that if integrity protection, ie qP = auth-int, the H (entity-main body) is the hash value of the entity main body, not a hash value of the message body, this value Before the sender performs any transmission coding, it is later deleted by the recipient. Franks, et al. Standards TRACK [Page 14] Note that it includes a plurality of boundaries and embedded titles in each part in any multipart content-type (Multipart Content-Type. 3.2.2.5 Diversity Considerations (Various Considance) "Method" value refers to the method of HTTP request, see Section 5.1.1 of [2]. The request URI specified in the "Request-URI" value request queue, see Section 5.1.2 of [2]. There may be "*", ie absolute URL ("absoluteurl" or "ABS_PATH"), see [2], 5.1.2, but must be consistent with the request URI. Special circumstances, when the requesting URI is absolute URL, it must also be in the form of an absolute URL. "Cnonce-Value" is an optional value for clients to prevent plain text attacks. The authentication server must ensure that the resources pointed to by "URI" are the same as the resources specified in the request queue; if different, the server should respond to the 400 (illegal request) message. Note that since this is probably an attack, the server implementation may have to log record. The purpose of the request URL in this domain contains the purpose of repetition is because the intermediate proxy server may change the client's request queue. Requests that have been changed (although it can be restored) will result in changes in the classification calculated by the client. Developers should pay attention to how to identify how to interact with shared caches. The HTTP / 1.1 protocol regulations, if the shared cache (see [2] 13.7) The authorization title and response included in the request is transmitted by the request, it will not be able to respond as other requests Answer unless any of the response includes any of two cache-control (Cache-Control) instructions. If the original server responds to the "Must-Revalidate" cache control indication, the cache can use the response when responding to concurrent requests, but must be approved from the original server, approved method It is the request to obtain authorization at the original server with the request of the new request. Also, if the original server responds to the "public" cache control indication, this response can be applied to any concurrent request. 3.2.3 Differentiation Information Title (The Authentication-Info HEADER) The Authentication-Info title is used by the server to make some information that is identified in the response. Franks, et al. Standards TRACK [Page 15] 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 <"> Nextnonce Value is a Nonce value that the server hopes that the client will use in the future. The server may send an Authentication-INFO title with the NextNonce domain to achieve a one-time or variable authentication. If the NEXTNONCE domain values, the client should use this value in the next request to build an authorization title. If there is "Stale = true" exists, the client's failure will cause the server to reassure the request. The implementation of the server should be careful that the potential performance problem caused by this mechanism; if each request is specified by the server, the NEXTnOnce value that must be used when the next request is used, then the PIPELINED request is not possible. To implement management requests, and to take into account the balance of performance and security, the old Nonce value can be used in a limited time. Using nonce-count can keep most of the security features of the new server NONCE without harming the pipeline. Message-qop Indicates the protection grade option for the server response. The "Auth" value represents the identification; and the "auth-int" value indicates the authentication of integrity protection. When the server responds to the client request, the same value as the Message-QOP should be used. The optional response classification in "response-auth" supports mutual authentication, that is, the server can confirm that it knows the secret of the user, or provides limited integrity protection by QOP = Auth-Int to respond. The "response-digest" value is used in the calculation of the "request-Digest" value in the authorized title, unless the authorization title of the specified request contains "QOP = auth" or not specified, A2 is: A2 = ":" Digest-Uri-Value If "QOP = Auth-Int" is included, A2 is: A2 = ":" Digest-Uri-Value ":" H (entity-body) Franks, et al. Standards TRACK [Page 16] Among them, "DiGest-Uri-Value" is "URI" pointed to by the request to authorize the title. "CNONCE-VALUE" and "NC-Value" must be part of the response message for the client request. When "QOP = Auth" or "QOP = Auth-Int" is specified, "response-auth", "cnonce", and "nonce-count" must be given. The Authentication-Info Title allows you to track the HTTP messages transmitted by block encoding transfer-coding. 3.3 Category Operation (Digest Operation) Before receiving the authorization title, the server may first check the legality of the response username and password. At this time, the server must perform the same classification operation (eg, MD5) as the client, and compare the result with a given request - classification (Request-Digest). Note that the HTTP server only needs to support H (A1), you don't have to know the user's password, and the legality of the authorized title can be identified. When the client responds to the WWW-Authenticate challenge to the protected section, the client starts the authentication session between the protected area. Identification Sessions are terminated when the client receives WWW-Authenticate challenges issued by any server in the protected area. The client should remember the UserName, Password, Nonce, Nonce Count, and Opaque values associated with the identification session, so that the authorization title request for the specified protected area request will be built. Authorization titles should be given priority to increase server efficiency and avoid identifying additional cycles that may occur. The server may choose to accept the old authorization title information, even in which the Nonce value is expired. Similarly, the server may respond to 401, including a new Nonce value, which will cause the client to retry the request; specify Stale = True in response, the server notifies the client to retry the request with the new Non, but will not Request to enter the new username and password. Because the client is returned to the server to its opaque value during the session, the opaque value can be used to deliver status information for authentication sessions. (Note, it can be implemented by way of the state in Nonce, which is safer and simple.) For example, the server should be responsible for the authentication content already located in other servers, and its implementation is in the first 401 response including Domain. Indicates (including URIs on the second server) and Opaque instructions (including status information) Franks, et al. Standards Track [Page 17] The client retry the request when the server responds to 301 or 302 (redirect, i.e., pointing to the URI on the second server). The client will transmit the authorized title according to the redirection information, including 3.4 Security Protocol Discussion (Security Protocol Negotiation) For the server, it is useful to understand which security scheme for client capability processing. There may be this situation, the server-side directly acquires the classification as its authentication method, regardless of whether the client supports it. If this happens, the authentication scheme specified by the server happens to be not supported by the client, and the client should make a clear response failure. 3.5 examples (Example) The following example assumes that the server is acquired to obtain a document with access protection on the server. The URI of the document is "http://www.nowhere.org/dir/index.html", the client and server know that the user name of the document is "mufasa", the password is "circle of life" (three words room) Separate with a space). When the client requests the document for the first time, the author shall not send an authorization title, so the server responds: HTTP / 1.1 401 unauthorized WWW-Authenticate: Digest Realm = "TestRealm@host.com", QOP = "auth, auth-int", NONCE = "DCD98B7102DD2F0E8B11D0F600BFB0C093", Opaque = "5ccc069c403ebaf9f0171e9517f40e41" The client may provide username and password in new requests, including the following authorization title: Franks, et al. Standards TRACK [Page 18] Authorization: Digest UserName = "MUFASA", Realm = "TestRealm@host.com", NONCE = "DCD98B7102DD2F0E8B11D0F600BFB0C093", URI = "/ dir / index.html", QOP = auth, NC = 00000001, Cnonce = "0A4f113b", Response = "6629fae49393a05397450978507c4ef1", Opaque = "5ccc069c403ebaf9f0171e9517f40e41" 3.6 Agent Differentiation and Proxy-Authorization By using the Proxy-Authenticate and Proxy-Authorization headers, the classification authentication scheme can also be implemented between the agent, the agent, and the proxy and the original server. These headings are examples of Proxy-Authenticate and Proxy-Authorization titles (see HTTP / 1.1 specification [2], 10.33, and 10.34, the behavior limit describes). Agent identification transaction is very similar to already described. Before receiving requests that need to be identified, the agent must issue 407 (requirement agent authentication) to respond, which contains the "Proxy-Authenticate title. The classification challenge used in the Proxy-Authenticate header is the same as the WWW-Authenticate title defined in the previous section 3.2.1. The client / agent must re-issue a request with a proxy-authorization title, which is written as a license title on the top 3.2.2 above. When concurrency responds, the server will send proxy authentication information (Proxy-Authentication-Info), which is the same as the Authentication-Info title field. Note, in principle, request the client to provide its own authentication for the agent and the final server, but cannot be in the same response. 4 Safety Considering (Security Considance) 4.1 Application of Basic Differential Client (Authentication Of Clients Using Basic Authentication) The basic identification scheme is not a safe user authentication method, nor does any form of protection in a sub-manual network in a physical network. HTTP allows you to use additional authentication schemes or encryption mechanisms to enhance the security of basic protocols (such as a primary communication scheme). Franks, et al. Standards TRACK [Page 19] The basic discrimination method is the most serious vulnerability that it uses the user password in a clear manner in the physical network, and this is the Digest Authentication method to try to solve. Because basic identification uses a clear textual transmission mode of the password, it is not possible to protect sensitive or valuable information if there is no enhancement. Basic authentication methods are commonly used for identification purposes - require users to provide usernames and passwords as identity identifiers, for example, used for exact statistical use conditions of servers. This situation seems to be in danger, and the illegal access to the protected documents is not the main problem. However, this method may be safe unless you send the user name, password to the user, and the user is not allowed to select your own password. Otherwise, the danger will be increased, because some natural users are to avoid maintaining multiple passwords, and always use a single password. If the server allows users to freely select passwords, the dangers are not only unauthorized access to server files, but also unauthorized access to other system resources for users with the same password protection. In addition, in the server password database, many passwords are also passwords that users access to other sites. Thus, if such information is not secure, the owner or administrator of the system will assume the risk of system user information exposure due to unauthorized access. Basic identification is also easily attacked by counterfeit servers. When the user firmly believes in a host that is protected by the basic identification plan, he may not think that he may be connected to the hostile server or gateway. The attacker can intercept the password and store it stand up, and pretend to return an error. This type of attack is impossible to succeed in a classification identification scheme. Server-end developers should implement protection against counterfeit gateways or camouflage CGI Script. In special cases, it is possible to generate serious consequences of the connection with a gateway. Because the gateway can play into the original server, the gateway has been established with the customer. Business interaction, and customers may not know about it. 4.2 Client Differences Differentiated by Category (Authentication Of Clients Using Digest Authentication) Compared with other safety mechanisms, such as public key technology, classification identification mechanisms should be fragile. Franks, et al. Standards TRACK [Page 20]
