摘要认证就是要核实，参与通信的双方，都知道双方共享的一个秘密（即口令）。
当服务器想要查证用户的身份，它产生一个摘要盘问（digest challenge），并发送给用户。典型的摘要盘问如下：
Digest realm="iptel.org", qop="auth,auth-int",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque="", algorithm=MD5
这里包括了一组参数，也要发送给用户。用户使用这些参数，来产生正确的摘要回答，并发送给服务器。摘要盘问中的各个参数，其意义如下：
realm（领域）：领域参数是强制的，在所有的盘问中都必须有。它是目的是鉴别SIP消息中的机密。在SIP实际应用中，它通常设置为SIP代理服务器所负责的域名。
在要求用户输入用户名和口令时，SIP用户代理则会显示这个参数的内容给用户，以便用户使用正确的用户名和口令（这个服务器的）。
nonce（现时）：这是由服务器规定的数据字符串，在服务器每次产生一个摘要盘问时，这个参数都是不一样的（与前面所产生的不会雷同）。“现时”通常是由一些数据通过md5杂凑运算构造的。这样的数据通常包括时间标识和服务器的机密短语。这确保每个“现时”都有一个有限的生命期（也就是过了一些时间后会失效，并且以后再也不会使用），而且是独一无二的（即任何其它的服务器都不能产生一个相同的“现时”）。
客户端使用这个“现时”来产生摘要响应（digest response），这样服务器也会在一个摘要响应中收到“现时”的内容。服务器先要检查了“现时”的有效性后，才会检查摘要响应的其它部分。
因而，“现时”在本质上是一种标识符，确保收到的摘要机密，是从某个特定的摘要盘问产生的。还限制了摘要盘问的生命期，防止未来的重播攻击。
opaque（不透明体）：这是一个不透明的（不让外人知道其意义）数据字符串，在盘问中发送给用户。
在摘要响应中，用户会将这个数据字符串发送回给服务器。这使得服务器可以是无状态的。如果需要在盘问和响应之间维护一些状态，可以用这个参数传送状态给客户端，此后当摘要响应回来时，再读这个状态。
algorithm（算法）：这是用来计算杂凑的算法。当前只支持MD5算法。
qop（保护的质量）。这个参数规定服务器支持哪种保护方案。客户端可以从列表中选择一个。值
“auth”表示只进行身份查验， “auth-int”表示进行查验外，还有一些完整性保护。需要看更详细的描述，请参阅RFC2617。
在收到了摘要盘问后，如果没有预先配置，用户代理软件通常会提示用户输入用户名和口令，产生一个摘要响应，并将这个响应发送给服务器。例如，摘要响应可能如下：
Digest username="jan", realm="iptel.org",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", uri="sip:iptel.org",
qop=auth, nc=00000001, cnonce="0a4f113b",
response="6629fae49393a05397450978507c4ef1", opaque=""
摘要响应类似于摘要盘问。相同的参数，则与摘要盘问有相同的意义。这里只描述新的参数：
uri（统一资源指示符）：这个参数包含了客户端想要访问的URI。
qop：客户端选择的保护方式。
nc：“现时”计数器，这是一个16进制的数值，即客户端发送出请求的数量（包括当前这个请求），这
些请求都使用了当前请求中这个“现时”值。例如，对一个给定的“现时”值，在响应的第一个请求中，客户端将发送“nc=00000001”。这个指示值的目的，是让服务器保持这个计数器的一个副本，以便检测重复的请求。如果这个相同的值看到了两次，则这个请求是重复的。
cnonce：这也是一个不透明的字符串值，由客户端提供，并且客户端和服务器都会使用，以避免用明文文本。这使得双方都可以查验对方的身份，并对消息的完整性提供一些保护。
response（响应）：这是由用户代理软件计算出的一个字符串，以证明用户知道口令。
当服务器接收到摘要响应，也要重新计算响应中各参数的值，并利用客户端提供的参数值，和服务器上存储的口令，进行比对。如果计算结果与收到的客户响应值是相同的，则客户已证明它知道口令，因而客户的身份验证通过。
Digest access authentication
Digest access authentication is one of the agreed-upon methods a web server can use to negotiate credentials with a user's web browser. It applies a hash function to a password before sending it over the network, which is safer than basic access authentication, which sends plaintext.
Technically, digest authentication is an application of MD5 cryptographic hashing with usage of nonce values to discourage cryptanalysis. It uses the HTTPprotocol.
Contents[hide]
|
Overview
Digest access authentication was originally specified by RFC 2069 (An Extension to HTTP: Digest Access Authentication). RFC 2069 specifies roughly a traditional digest authentication scheme with security maintained by a server-generated nonce value. The authentication response is formed as follows (where HA1, HA2, A1, A2 are names of string variables):
RFC 2069 was later replaced by RFC 2617 (HTTP Authentication: Basic and Digest Access Authentication). RFC 2617 introduced a number of optional security enhancements to digest authentication; "quality of protection" (qop), nonce counter incremented by client, and a client-generated random nonce. These enhancements are designed to protect against, for example,chosen-plaintext attack cryptanalysis.
If the qop directive's value is "auth" or is unspecified, then HA2 is
If the qop directive's value is "auth-int", then HA2 is
If the qop directive's value is "auth" or "auth-int", then compute the response as follows:
If the qop directive is unspecified, then compute the response as follows:
The above shows that when qop is not specified, the simpler RFC 2069 standard is followed.
[edit]Impact of MD5 security on digest authentication
The MD5 calculations used in HTTP digest authentication is intended to be "one way", meaning that it should be difficult to determine the original input when only the output is known. If the password itself is too simple, however, then it may be possible to test all possible inputs and find a matching output (a brute-force attack) – perhaps aided by a dictionary or suitable look-up list.
The HTTP scheme was designed by Phillip Hallam-Baker at CERN in 1993 and does not incorporate subsequent improvements in authentication systems, such as the development of keyed-hash message authentication code (HMAC). Although the cryptographic construction that is used is based on the MD5 hash function, collision attacks were in 2004 generally believed to not affect applications where the plaintext (i.e. password) is not known.[1][citation needed] However, claims in 2006 (Kim, Biryukov2, Preneel, Hong, "On the Security of HMAC and NMAC Based on HAVAL MD4 MD5 SHA-0 and SHA-1") cause some doubt over other MD5 applications as well. So far, however, MD5 collision attacks have not been shown to pose a threat to digest authentication, and the RFC 2617 allows servers to implement mechanisms to detect some collision and replay attacks.
[edit]HTTP digest authentication considerations
[edit]Advantages
HTTP digest authentication is designed to be more secure than traditional digest authentication schemes; e.g., "significantly stronger than (e.g.) CRAM-MD5 ..." (RFC2617).
Some of the security strengths of HTTP digest authentication are:
- The password is not used directly in the digest, but rather HA1 = MD5(username:realm:password). This allows some implementations (e.g. JBoss DIGESTAuth) to store HA1 rather than thecleartext password.
- Client nonce was introduced in RFC 2617, which allows the client to prevent Chosen-plaintext attacks (which otherwise makes e.g. rainbow tables a threat to digest authentication schemes).
- Server nonce is allowed to contain timestamps. Therefore the server may inspect nonce attributes submitted by clients, to prevent replay attacks.
- Server is also allowed to maintain a list of recently issued or used server nonce values to prevent reuse.
[edit]Disadvantages
Digest access authentication is intended as a security trade-off. It is intended to replace unencrypted HTTP basic access authentication. It is not, however, intended to replace strong authentication protocols, such as public-key or Kerberos authentication.
In terms of security, there are several drawbacks with digest access authentication:
- Many of the security options in RFC 2617 are optional. If quality-of-protection (qop) is not specified by the server, the client will operate in a security-reduced legacy RFC 2069 mode.
- Digest access authentication is vulnerable to a man-in-the-middle (MitM) attack. For example, a MitM attacker could tell clients to use basic access authentication or legacy RFC2069 digest access authentication mode. To extend this further, digest access authentication provides no mechanism for clients to verify the server's identity.
- Some servers require passwords to be stored using reversible encryption. However, it is possible to instead store the digested value of the username, realm, and password.[2]
- It prevents the use of a strong password hash (such as bcrypt) when storing passwords (since either the password, or the digested username, realm and password must be recoverable).
[edit]Alternative authentication protocols
Some strong authentication protocols for web-based applications include:
- Public key authentication (usually implemented with HTTPS / SSL client certificates).
- Kerberos or SPNEGO authentication, primarily employed by Microsoft IIS running configured for Integrated Windows Authentication (IWA).
- Secure Remote Password protocol (preferably within the HTTPS / TLS layer).
Weak cleartext protocols are also often in use:
- Basic access authentication scheme
- HTTP+HTML form-based authentication
These weak cleartext protocols used together with HTTPS network encryption resolve many of the threats that digest access authentication is designed to prevent.
[edit]Example with explanation
The following example was originally given in RFC 2617 and is expanded here to show the full text expected for each request and response. Note that only the "auth" (authentication) quality of protection code is covered – at the time of writing, only the Opera and Konqueror web browsers are known to support "auth-int" (authentication with integrity protection). Although the specification mentions HTTP version 1.1, the scheme can be successfully added to a version 1.0 server, as shown here.
This typical transaction consists of the following steps.
- The client asks for a page that requires authentication but does not provide a username and password. Typically this is because the user simply entered the address or followed a link to the page.
- The server responds with the 401 "Unauthorized" response code, providing the authentication realm and a randomly-generated, single-use value called a nonce.
- At this point, the browser will present the authentication realm (typically a description of the computer or system being accessed) to the user and prompt for a username and password. The user may decide to cancel at this point.
- Once a username and password have been supplied, the client re-sends the same request but adds an authentication header that includes the response code.
- In this example, the server accepts the authentication and the page is returned. If the username is invalid and/or the password is incorrect, the server might return the "401" response code and the client would prompt the user again.
Note: A client may already have the required username and password without needing to prompt the user, e.g. if they have previously been stored by a web browser.
- Client request (no authentication)
GET /dir/index.html HTTP/1.0
Host: localhost
(followed by a new line, in the form of a carriage return followed by a line feed).[citation needed]
- Server response
HTTP/1.0 401 Unauthorized
Server: HTTPd/0.9
Date: Sun, 10 Apr 2005 20:26:47 GMT
WWW-Authenticate: Digest realm="testrealm@host.com",
qop="auth,auth-int",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
Content-Type: text/html
Content-Length: 311
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
" http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd ">
<HTML>
<HEAD>
<TITLE>Error</TITLE>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
</HEAD>
<BODY><H1>401 Unauthorized.</H1></BODY>
</HTML>
- Client request (username "Mufasa", password "Circle Of Life")
GET /dir/index.html HTTP/1.0
Host: localhost
Authorization: Digest username="Mufasa",
realm="testrealm@host.com",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
uri="/dir/index.html",
qop=auth,
nc=00000001,
cnonce="0a4f113b",
response="6629fae49393a05397450978507c4ef1",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
(followed by a blank line, as before).
- Server response
HTTP/1.0 200 OK
Server: HTTPd/0.9
Date: Sun, 10 Apr 2005 20:27:03 GMT
Content-Type: text/html
Content-Length: 7984
(followed by a blank line and HTML text of the restricted page).
The "response" value is calculated in three steps, as follows. Where values are combined, they are delimited by colon symbols.
- The MD5 hash of the combined username, authentication realm and password is calculated. The result is referred to as HA1.
- The MD5 hash of the combined method and digest URI is calculated, e.g. of
"GET"and"/dir/index.html". The result is referred to as HA2.
- The MD5 hash of the combined HA1 result, server nonce (nonce), request counter (nc), client nonce (cnonce), quality of protection code (qop) and HA2 result is calculated. The result is the "response" value provided by the client.
Since the server has the same information as the client, the response can be checked by performing the same calculation. In the example given above the result is formed as follows, whereMD5() represents a function used to calculate an MD5 hash, backslashes represent a continuation and the quotes shown are not used in the calculation.
Completing the example given in RFC 2617 gives the following results for each step.
HA1 = MD5( "Mufasa:testrealm@host.com:Circle Of Life" )
= 939e7578ed9e3c518a452acee763bce9
HA2 = MD5( "GET:/dir/index.html" )
= 39aff3a2bab6126f332b942af96d3366
Response = MD5( "939e7578ed9e3c518a452acee763bce9:\
dcd98b7102dd2f0e8b11d0f600bfb0c093:\
00000001:0a4f113b:auth:\
39aff3a2bab6126f332b942af96d3366" )
= 6629fae49393a05397450978507c4ef1
At this point the client may make another request, reusing the server nonce value (the server only issues a new nonce for each "401" response) but providing a new client nonce (cnonce). For subsequent requests, the hexadecimal request counter (nc) must be greater than the last value it used – otherwise an attacker could simply "replay" an old request with the same credentials. It is up to the server to ensure that the counter increases for each of the nonce values that it has issued, rejecting any bad requests appropriately. Obviously changing the method, URI and/or counter value will result in a different response value.
The server should remember nonce values that it has recently generated. It may also remember when each nonce value was issued, expiring them after a certain amount of time. If an expired value is used, the server should respond with the "401" status code and add stale=TRUE to the authentication header, indicating that the client should re-send with the new nonce provided, without prompting the user for another username and password.
The server does not need to keep any expired nonce values – it can simply assume that any unrecognised values have expired. It is also possible for the server to only allow each nonce value to be returned once, although this forces the client to repeat every request. Note that expiring a server nonce immediately will not work, as the client would never get a chance to use it.
[edit]SIP digest authentication
SIP uses basically the same digest authentication algorithm. It is specified by RFC 3261.
[edit]Browser implementation
Most browsers have substantially implemented the spec, some barring certain features such as auth-int checking or the MD5-sess algorithm. If the server requires that these optional features be handled, clients may not be able to authenticate (though note mod_auth_digest for Apache does not fully implement RFC 2617 either).
- Amaya
- Gecko-based: (not including auth-int: [1])
- Mozilla Application Suite
- Mozilla Firefox
- Netscape 7+
- iCab 3.0.3+
- KHTML- and WebKit-based: (not including auth-int [2])
- iCab 4
- Konqueror
- Google Chrome
- Safari
- Tasman-based:
- Internet Explorer for Mac
- Trident-based:
- Internet Explorer 7+ [3] (not including auth-int)
- Presto-based:
- Opera
- Opera Mobile
- Opera Mini
- Nintendo DS Browser
- Nokia 770 Browser
- Sony Mylo 1's Browser
- Wii Internet Channel Browser
Digest access authentication is one of the agreed-upon methods a web server can use to negotiate credentials with a user's web browser. It applies a hash function to a password before sending it over the network, which is safer than basic access authentication, which sends plaintext.
Technically, digest authentication is an application of MD5 cryptographic hashing with usage of nonce values to discourage cryptanalysis. It uses the HTTPprotocol.
Contents[hide]
|
Overview
Digest access authentication was originally specified by RFC 2069 (An Extension to HTTP: Digest Access Authentication). RFC 2069 specifies roughly a traditional digest authentication scheme with security maintained by a server-generated nonce value. The authentication response is formed as follows (where HA1, HA2, A1, A2 are names of string variables):
RFC 2069 was later replaced by RFC 2617 (HTTP Authentication: Basic and Digest Access Authentication). RFC 2617 introduced a number of optional security enhancements to digest authentication; "quality of protection" (qop), nonce counter incremented by client, and a client-generated random nonce. These enhancements are designed to protect against, for example,chosen-plaintext attack cryptanalysis.
If the qop directive's value is "auth" or is unspecified, then HA2 is
If the qop directive's value is "auth-int", then HA2 is
If the qop directive's value is "auth" or "auth-int", then compute the response as follows:
If the qop directive is unspecified, then compute the response as follows:
The above shows that when qop is not specified, the simpler RFC 2069 standard is followed.
[edit]Impact of MD5 security on digest authentication
The MD5 calculations used in HTTP digest authentication is intended to be "one way", meaning that it should be difficult to determine the original input when only the output is known. If the password itself is too simple, however, then it may be possible to test all possible inputs and find a matching output (a brute-force attack) – perhaps aided by a dictionary or suitable look-up list.
The HTTP scheme was designed by Phillip Hallam-Baker at CERN in 1993 and does not incorporate subsequent improvements in authentication systems, such as the development of keyed-hash message authentication code (HMAC). Although the cryptographic construction that is used is based on the MD5 hash function, collision attacks were in 2004 generally believed to not affect applications where the plaintext (i.e. password) is not known.[1][citation needed] However, claims in 2006 (Kim, Biryukov2, Preneel, Hong, "On the Security of HMAC and NMAC Based on HAVAL MD4 MD5 SHA-0 and SHA-1") cause some doubt over other MD5 applications as well. So far, however, MD5 collision attacks have not been shown to pose a threat to digest authentication, and the RFC 2617 allows servers to implement mechanisms to detect some collision and replay attacks.
[edit]HTTP digest authentication considerations
[edit]Advantages
HTTP digest authentication is designed to be more secure than traditional digest authentication schemes; e.g., "significantly stronger than (e.g.) CRAM-MD5 ..." (RFC2617).
Some of the security strengths of HTTP digest authentication are:
- The password is not used directly in the digest, but rather HA1 = MD5(username:realm:password). This allows some implementations (e.g. JBoss DIGESTAuth) to store HA1 rather than thecleartext password.
- Client nonce was introduced in RFC 2617, which allows the client to prevent Chosen-plaintext attacks (which otherwise makes e.g. rainbow tables a threat to digest authentication schemes).
- Server nonce is allowed to contain timestamps. Therefore the server may inspect nonce attributes submitted by clients, to prevent replay attacks.
- Server is also allowed to maintain a list of recently issued or used server nonce values to prevent reuse.
[edit]Disadvantages
Digest access authentication is intended as a security trade-off. It is intended to replace unencrypted HTTP basic access authentication. It is not, however, intended to replace strong authentication protocols, such as public-key or Kerberos authentication.
In terms of security, there are several drawbacks with digest access authentication:
- Many of the security options in RFC 2617 are optional. If quality-of-protection (qop) is not specified by the server, the client will operate in a security-reduced legacy RFC 2069 mode.
- Digest access authentication is vulnerable to a man-in-the-middle (MitM) attack. For example, a MitM attacker could tell clients to use basic access authentication or legacy RFC2069 digest access authentication mode. To extend this further, digest access authentication provides no mechanism for clients to verify the server's identity.
- Some servers require passwords to be stored using reversible encryption. However, it is possible to instead store the digested value of the username, realm, and password.[2]
- It prevents the use of a strong password hash (such as bcrypt) when storing passwords (since either the password, or the digested username, realm and password must be recoverable).
[edit]Alternative authentication protocols
Some strong authentication protocols for web-based applications include:
- Public key authentication (usually implemented with HTTPS / SSL client certificates).
- Kerberos or SPNEGO authentication, primarily employed by Microsoft IIS running configured for Integrated Windows Authentication (IWA).
- Secure Remote Password protocol (preferably within the HTTPS / TLS layer).
Weak cleartext protocols are also often in use:
- Basic access authentication scheme
- HTTP+HTML form-based authentication
These weak cleartext protocols used together with HTTPS network encryption resolve many of the threats that digest access authentication is designed to prevent.
[edit]Example with explanation
The following example was originally given in RFC 2617 and is expanded here to show the full text expected for each request and response. Note that only the "auth" (authentication) quality of protection code is covered – at the time of writing, only the Opera and Konqueror web browsers are known to support "auth-int" (authentication with integrity protection). Although the specification mentions HTTP version 1.1, the scheme can be successfully added to a version 1.0 server, as shown here.
This typical transaction consists of the following steps.
- The client asks for a page that requires authentication but does not provide a username and password. Typically this is because the user simply entered the address or followed a link to the page.
- The server responds with the 401 "Unauthorized" response code, providing the authentication realm and a randomly-generated, single-use value called a nonce.
- At this point, the browser will present the authentication realm (typically a description of the computer or system being accessed) to the user and prompt for a username and password. The user may decide to cancel at this point.
- Once a username and password have been supplied, the client re-sends the same request but adds an authentication header that includes the response code.
- In this example, the server accepts the authentication and the page is returned. If the username is invalid and/or the password is incorrect, the server might return the "401" response code and the client would prompt the user again.
Note: A client may already have the required username and password without needing to prompt the user, e.g. if they have previously been stored by a web browser.
- Client request (no authentication)
GET /dir/index.html HTTP/1.0
Host: localhost
(followed by a new line, in the form of a carriage return followed by a line feed).[citation needed]
- Server response
HTTP/1.0 401 Unauthorized
Server: HTTPd/0.9
Date: Sun, 10 Apr 2005 20:26:47 GMT
WWW-Authenticate: Digest realm="testrealm@host.com",
qop="auth,auth-int",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
Content-Type: text/html
Content-Length: 311
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
" http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd ">
<HTML>
<HEAD>
<TITLE>Error</TITLE>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
</HEAD>
<BODY><H1>401 Unauthorized.</H1></BODY>
</HTML>
- Client request (username "Mufasa", password "Circle Of Life")
GET /dir/index.html HTTP/1.0
Host: localhost
Authorization: Digest username="Mufasa",
realm="testrealm@host.com",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
uri="/dir/index.html",
qop=auth,
nc=00000001,
cnonce="0a4f113b",
response="6629fae49393a05397450978507c4ef1",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
(followed by a blank line, as before).
- Server response
HTTP/1.0 200 OK
Server: HTTPd/0.9
Date: Sun, 10 Apr 2005 20:27:03 GMT
Content-Type: text/html
Content-Length: 7984
(followed by a blank line and HTML text of the restricted page).
The "response" value is calculated in three steps, as follows. Where values are combined, they are delimited by colon symbols.
- The MD5 hash of the combined username, authentication realm and password is calculated. The result is referred to as HA1.
- The MD5 hash of the combined method and digest URI is calculated, e.g. of
"GET"and"/dir/index.html". The result is referred to as HA2.
- The MD5 hash of the combined HA1 result, server nonce (nonce), request counter (nc), client nonce (cnonce), quality of protection code (qop) and HA2 result is calculated. The result is the "response" value provided by the client.
Since the server has the same information as the client, the response can be checked by performing the same calculation. In the example given above the result is formed as follows, whereMD5() represents a function used to calculate an MD5 hash, backslashes represent a continuation and the quotes shown are not used in the calculation.
Completing the example given in RFC 2617 gives the following results for each step.
HA1 = MD5( "Mufasa:testrealm@host.com:Circle Of Life" )
= 939e7578ed9e3c518a452acee763bce9
HA2 = MD5( "GET:/dir/index.html" )
= 39aff3a2bab6126f332b942af96d3366
Response = MD5( "939e7578ed9e3c518a452acee763bce9:\
dcd98b7102dd2f0e8b11d0f600bfb0c093:\
00000001:0a4f113b:auth:\
39aff3a2bab6126f332b942af96d3366" )
= 6629fae49393a05397450978507c4ef1
At this point the client may make another request, reusing the server nonce value (the server only issues a new nonce for each "401" response) but providing a new client nonce (cnonce). For subsequent requests, the hexadecimal request counter (nc) must be greater than the last value it used – otherwise an attacker could simply "replay" an old request with the same credentials. It is up to the server to ensure that the counter increases for each of the nonce values that it has issued, rejecting any bad requests appropriately. Obviously changing the method, URI and/or counter value will result in a different response value.
The server should remember nonce values that it has recently generated. It may also remember when each nonce value was issued, expiring them after a certain amount of time. If an expired value is used, the server should respond with the "401" status code and add stale=TRUE to the authentication header, indicating that the client should re-send with the new nonce provided, without prompting the user for another username and password.
The server does not need to keep any expired nonce values – it can simply assume that any unrecognised values have expired. It is also possible for the server to only allow each nonce value to be returned once, although this forces the client to repeat every request. Note that expiring a server nonce immediately will not work, as the client would never get a chance to use it.
[edit]SIP digest authentication
SIP uses basically the same digest authentication algorithm. It is specified by RFC 3261.
[edit]Browser implementation
Most browsers have substantially implemented the spec, some barring certain features such as auth-int checking or the MD5-sess algorithm. If the server requires that these optional features be handled, clients may not be able to authenticate (though note mod_auth_digest for Apache does not fully implement RFC 2617 either).
- Amaya
- Gecko-based: (not including auth-int: [1])
- Mozilla Application Suite
- Mozilla Firefox
- Netscape 7+
- iCab 3.0.3+
- KHTML- and WebKit-based: (not including auth-int [2])
- iCab 4
- Konqueror
- Google Chrome
- Safari
- Tasman-based:
- Internet Explorer for Mac
- Trident-based:
- Internet Explorer 7+ [3] (not including auth-int)
- Presto-based:
- Opera
- Opera Mobile
- Opera Mini
- Nintendo DS Browser
- Nokia 770 Browser
- Sony Mylo 1's Browser
- Wii Internet Channel Browser
