draft-ietf-httpauth-digest-02.txt   draft-ietf-httpauth-digest-03.txt 
HTTPAuth Working Group R. Shekh-Yusef, Ed. HTTPAuth Working Group R. Shekh-Yusef, Ed.
Internet-Draft D. Ahrens Internet-Draft D. Ahrens
Obsoletes: 2617 (if approved) Avaya Obsoletes: 2617 (if approved) Avaya
Intended Status: Standards Track S. Bremer Intended Status: Standards Track S. Bremer
Expires: July 22, 2014 Netzkonform Expires: July 23, 2014 Netzkonform
January 18, 2014 January 19, 2014
HTTP Digest Access Authentication HTTP Digest Access Authentication
draft-ietf-httpauth-digest-02.txt draft-ietf-httpauth-digest-03
Abstract Abstract
HTTP provides a simple challenge-response authentication mechanism HTTP provides a simple challenge-response authentication mechanism
that may be used by a server to challenge a client request and by a that may be used by a server to challenge a client request and by a
client to provide authentication information. This document defines client to provide authentication information. This document defines
the HTTP Digest Authentication scheme that may be used with the the HTTP Digest Authentication scheme that may be used with the
authentication mechanism. authentication mechanism.
Status of this Memo Status of this Memo
skipping to change at page 2, line 25 skipping to change at page 2, line 25
Table of Contents Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Syntax Convention . . . . . . . . . . . . . . . . . . . . . . . 4 2 Syntax Convention . . . . . . . . . . . . . . . . . . . . . . . 4
3 Digest Access Authentication Scheme . . . . . . . . . . . . . . 4 3 Digest Access Authentication Scheme . . . . . . . . . . . . . . 4
3.1 Overall Operation . . . . . . . . . . . . . . . . . . . . . 4 3.1 Overall Operation . . . . . . . . . . . . . . . . . . . . . 4
3.2 Representation of Digest Values . . . . . . . . . . . . . . 4 3.2 Representation of Digest Values . . . . . . . . . . . . . . 4
3.3 The WWW-Authenticate Response Header . . . . . . . . . . . . 5 3.3 The WWW-Authenticate Response Header . . . . . . . . . . . . 5
3.4 The Authorization Request Header . . . . . . . . . . . . . . 8 3.4 The Authorization Request Header . . . . . . . . . . . . . . 8
3.4.1 Request-Digest . . . . . . . . . . . . . . . . . . . . . 11 3.4.1 Request-Digest . . . . . . . . . . . . . . . . . . . . . 10
3.4.2 A1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.4.2 A1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4.3 A2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.4.3 A2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4.4 Username Hashing . . . . . . . . . . . . . . . . . . . . 12 3.4.4 Username Hashing . . . . . . . . . . . . . . . . . . . . 11
3.4.5 Directive Values and Quoted-String . . . . . . . . . . . 12 3.4.5 Directive Values and Quoted-String . . . . . . . . . . . 11
3.4.6 Various Considerations . . . . . . . . . . . . . . . . . 13 3.4.6 Various Considerations . . . . . . . . . . . . . . . . . 12
3.5 The Authentication-Info Header . . . . . . . . . . . . . . . 14 3.5 The Authentication-Info Header . . . . . . . . . . . . . . . 13
3.6 Digest Operation . . . . . . . . . . . . . . . . . . . . . . 15 3.6 Digest Operation . . . . . . . . . . . . . . . . . . . . . . 14
3.7 Security Protocol Negotiation . . . . . . . . . . . . . . . 17 3.7 Security Protocol Negotiation . . . . . . . . . . . . . . . 16
3.8 Proxy-Authentication and Proxy-Authorization . . . . . . . . 17 3.8 Proxy-Authenticate and Proxy-Authorization . . . . . . . . . 16
3.9 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.9 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4 Internationalization . . . . . . . . . . . . . . . . . . . . . . 20 4 Internationalization . . . . . . . . . . . . . . . . . . . . . . 19
5 Security Considerations . . . . . . . . . . . . . . . . . . . . 20 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 19
5.1 Limitations . . . . . . . . . . . . . . . . . . . . . . . . 20 5.1 Limitations . . . . . . . . . . . . . . . . . . . . . . . . 19
5.2 Authentication of Clients using Digest Authentication . . . 20 5.2 Authentication of Clients using Digest Authentication . . . 19
5.3 Limited Use Nonce Values . . . . . . . . . . . . . . . . . . 21 5.3 Limited Use Nonce Values . . . . . . . . . . . . . . . . . . 20
5.4 Replay Attacks . . . . . . . . . . . . . . . . . . . . . . . 22 5.4 Replay Attacks . . . . . . . . . . . . . . . . . . . . . . . 21
5.5 Weakness Created by Multiple Authentication Schemes . . . . 22 5.5 Weakness Created by Multiple Authentication Schemes . . . . 21
5.6 Online dictionary attacks . . . . . . . . . . . . . . . . . 23 5.6 Online dictionary attacks . . . . . . . . . . . . . . . . . 22
5.7 Man in the Middle . . . . . . . . . . . . . . . . . . . . . 23 5.7 Man in the Middle . . . . . . . . . . . . . . . . . . . . . 22
5.8 Chosen plaintext attacks . . . . . . . . . . . . . . . . . . 24 5.8 Chosen plaintext attacks . . . . . . . . . . . . . . . . . . 23
5.9 Precomputed dictionary attacks . . . . . . . . . . . . . . . 24 5.9 Precomputed dictionary attacks . . . . . . . . . . . . . . . 23
5.10 Batch brute force attacks . . . . . . . . . . . . . . . . . 25 5.10 Batch brute force attacks . . . . . . . . . . . . . . . . . 24
5.11 Spoofing by Counterfeit Servers . . . . . . . . . . . . . . 25 5.11 Spoofing by Counterfeit Servers . . . . . . . . . . . . . . 24
5.12 Storing passwords . . . . . . . . . . . . . . . . . . . . . 25 5.12 Storing passwords . . . . . . . . . . . . . . . . . . . . . 24
5.13 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 26 5.13 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 27 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 26
6.1 HTTP Digest Hash Algorithms Registry . . . . . . . . . . . 26
6.2 Digest . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 27 7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 27
8 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.1 Normative References . . . . . . . . . . . . . . . . . . . . 27 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 27
8.2 Informative References . . . . . . . . . . . . . . . . . . . 27 8.2 Informative References . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
1 Introduction 1 Introduction
HTTP provides a simple challenge-response authentication mechanism HTTP provides a simple challenge-response authentication mechanism
that may be used by a server to challenge a client request and by a that may be used by a server to challenge a client request and by a
client to provide authentication information. This document defines client to provide authentication information. This document defines
the HTTP Digest Authentication scheme that may be used with the the HTTP Digest Authentication scheme that may be used with the
authentication mechanism. authentication mechanism.
The details of the challenge-response authentication mechanism are The details of the challenge-response authentication mechanism are
specified in the [draft-ietf-httpbis-p7-auth-25] document. specified in the [HTTP-P7] document.
1.1 Terminology 1.1 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2 Syntax Convention 2 Syntax Convention
In the interest of clarity and readability, the extended parameters In the interest of clarity and readability, the extended parameters
skipping to change at page 5, line 17 skipping to change at page 5, line 17
representation of 1111 as 'f'. If the MD5 algorithm is used to representation of 1111 as 'f'. If the MD5 algorithm is used to
calculate the digest, then the digest will be represented as 32 calculate the digest, then the digest will be represented as 32
hexadecimal characters, SHA2-256 and SHA2-512/256 by 64 hexadecimal hexadecimal characters, SHA2-256 and SHA2-512/256 by 64 hexadecimal
characters. characters.
3.3 The WWW-Authenticate Response Header 3.3 The WWW-Authenticate Response Header
If a server receives a request for an access-protected object, and an If a server receives a request for an access-protected object, and an
acceptable Authorization header is not sent, the server responds with acceptable Authorization header is not sent, the server responds with
a "401 Unauthorized" status code, and a WWW-Authenticate header as a "401 Unauthorized" status code, and a WWW-Authenticate header as
per the framework defined above, which for the digest scheme is per the framework defined above, and include some or all of the
utilized as follows. following parameters:
The following defines the scheme and the parameters for the
challenge:
auth-scheme = "Digest" digest-challenge
digest-challenge = 1#( realm | [ domain ] | nonce |
[ opaque ] |[ stale ] | [ algorithm ] |
[ qop-options ] | [charset] | [userhash] )
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" |
"SHA2-256" | "SHA2-256-sess" |
"SHA2-512-256" | "SHA2-512-256-sess" |
token)
qop-options = "qop" "=" <"> 1#qop-value <">
qop-value = "auth" | "auth-int" | token
charset = "charset" "=" ("UTF-8" | token)
userhash = "userhash" "=" ( "true" | "false" )
The meanings of the values of the directives used above are as
follows:
realm realm
A string to be displayed to users so they know which username and 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 password to use. This string should contain at least the name of
the host performing the authentication and might additionally the host performing the authentication and might additionally
indicate the collection of users who might have access. An example indicate the collection of users who might have access. An example
might be "registered_users@gotham.news.com". might be "registered_users@gotham.news.com".
domain domain
A quoted, space-separated list of URIs, as specified in RFC XURI 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, [RFC2396], that define the protection space. If a URI is an
it is relative to the canonical root URL of the server being abs_path, it is relative to the canonical root URL of the server
accessed. An absoluteURI in this list may refer to a different being accessed. An absolute-URI in this list may refer to a
server than the one being accessed. The client can use this list different server than the one being accessed. The client can use
to determine the set of URIs for which the same authentication this list to determine the set of URIs for which the same
information may be sent: any URI that has a URI in this list as a authentication information may be sent: any URI that has a URI in
prefix (after both have been made absolute) may be assumed to be this list as a prefix (after both have been made absolute) may be
in the same protection space. If this directive is omitted or its assumed to be in the same protection space. If this directive is
value is empty, the client should assume that the protection space omitted or its value is empty, the client should assume that the
consists of all URIs on the responding server. protection space consists of all URIs on the responding server.
This directive is not meaningful in Proxy-Authenticate headers, This directive is not meaningful in Proxy-Authenticate headers,
for which the protection space is always the entire proxy; if for which the protection space is always the entire proxy; if
present it should be ignored. present it should be ignored.
nonce nonce
A server-specified data string which should be uniquely generated A server-specified data string which should be uniquely generated
each time a 401 response is made. It is recommended that this each time a 401 response is made. It is recommended that this
string be base64 or hexadecimal data. Specifically, since the string be base64 or hexadecimal data. Specifically, since the
string is passed in the header lines as a quoted string, the string is passed in the header lines as a quoted string, the
skipping to change at page 8, line 47 skipping to change at page 8, line 17
indicate the encoding scheme it supports. indicate the encoding scheme it supports.
userhash userhash
This is an OPTIONAL parameter that is used by the server to This is an OPTIONAL parameter that is used by the server to
indicate that it supports username hashing. indicate that it supports username hashing.
3.4 The Authorization Request Header 3.4 The Authorization Request Header
The client is expected to retry the request, passing an The client is expected to retry the request, passing an
Authorization header line, which is defined according to the Authorization header line, which is defined according to the
framework above, utilized as follows. framework above. The values of the opaque and algorithm fields
must be those supplied in the WWW-Authenticate response header for
The following defines the scheme and the parameters for the the entity being requested.
response:
auth-scheme = "Digest" digest-response
digest-response = 1#( username | realm | nonce |
digest-uri | response | [ algorithm ] |
[cnonce] | [opaque] | [message-qop] |
[nonce-count] | [charset] | [userhash])
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 = <"> *LHEX <">
LHEX = "0" | "1" | "2" | "3" |
"4" | "5" | "6" | "7" |
"8" | "9" | "a" | "b" |
"c" | "d" | "e" | "f"
charset = "charset" "=" ("UTF-8" | token)
userhash = "userhash" "=" ( "true" | "false" )
The values of the opaque and algorithm fields must be those The request includes some or all of the following parameters:
supplied in the WWW-Authenticate response header for the entity
being requested.
response response
A string of the hex digits computed as defined below, which proves A string of the hex digits computed as defined below, which proves
that the user knows a password that the user knows a password
username username
The user's name in the specified realm. The user's name in the specified realm.
digest-uri digest-uri
The URI from Request-URI of the Request-Line; duplicated here The URI from request-target of the Request-Line; duplicated here
because proxies are allowed to change the Request-Line in transit. because proxies are allowed to change the Request-Line in transit.
qop qop
Indicates what "quality of protection" the client has applied to Indicates what "quality of protection" the client has applied to
the message. If present, its value MUST be one of the alternatives the message. If present, its value MUST be one of the alternatives
the server indicated it supports in the WWW-Authenticate header. the server indicated it supports in the WWW-Authenticate header.
These values affect the computation of the request-digest. Note These values affect the computation of the request-digest. Note
that this is a single token, not a quoted list of alternatives as that this is a single token, not a quoted list of alternatives as
in WWW-Authenticate. This directive is optional in order to in WWW-Authenticate. This directive is optional in order to
preserve backward compatibility with a minimal implementation of preserve backward compatibility with a minimal implementation of
skipping to change at page 13, line 32 skipping to change at page 12, line 32
Also note that if integrity protection is applied (qop=auth-int), the 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 - 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 it is computed before any transfer encoding is applied by the sender
and after it has been removed by the recipient. Note that this and after it has been removed by the recipient. Note that this
includes multipart boundaries and embedded headers in each part of includes multipart boundaries and embedded headers in each part of
any multipart content-type. any multipart content-type.
3.4.6 Various Considerations 3.4.6 Various Considerations
The "Method" value is the HTTP request method as specified in section The "Method" value is the HTTP request method as specified in section
5.1.1 of [RFC2616]. The "request-uri" value is the Request-URI from 3.1.1 of [HTTP-P1]. The "request-target" value is the request-target
the request line as specified in section 5.1.2 of [RFC2616]. This may from the request line as specified in section 3.1.1 of [HTTP-P1].
be "*", an "absoluteURL" or an "abs_path" as specified in section This may be "*", an "absolute-URI" or an "absolute-path" as specified
5.1.2 of [RFC2616], but it MUST agree with the Request-URI. In in section 2.7 of [HTTP-P1], but it MUST agree with the request-
particular, it MUST be an "absoluteURL" if the Request-URI is an target. In particular, it MUST be an "absolute-URI" if the request-
"absoluteURL". The "cnonce-value" is an optional client-chosen value target is an "absolute-URI". The "cnonce-value" is an optional
whose purpose is to foil chosen plaintext attacks. client-chosen value whose purpose is to foil chosen plaintext
attacks.
The authenticating server must assure that the resource designated by The authenticating server must assure that the resource designated by
the "uri" directive is the same as the resource specified in the 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-Line; if they are not, the server SHOULD return a 400 Bad
Request error. (Since this may be a symptom of an attack, server Request error. (Since this may be a symptom of an attack, server
implementers may want to consider logging such errors.) The purpose implementers may want to consider logging such errors.) The purpose
of duplicating information from the request URL in this field is to of duplicating information from the request URL in this field is to
deal with the possibility that an intermediate proxy may alter the deal with the possibility that an intermediate proxy may alter the
client's Request-Line. This altered (but presumably semantically client's Request-Line. This altered (but presumably semantically
equivalent) request would not result in the same digest as that equivalent) request would not result in the same digest as that
calculated by the client. calculated by the client.
Implementers should be aware of how authenticated transactions Implementers should be aware of how authenticated transactions
interact with shared caches. The HTTP/1.1 protocol specifies that interact with shared caches. The HTTP/1.1 protocol specifies that
when a shared cache (see section 13.7 of [RFC2616]) has received a when a shared cache (see [HTTP-P6]) has received a request containing
request containing an Authorization header and a response from an Authorization header and a response from relaying that request, it
relaying that request, it MUST NOT return that response as a reply to MUST NOT return that response as a reply to any other request, unless
any other request, unless one of two Cache-Control (see section 14.9 one of two Cache-Control (see section 3.2 of [HTTP-P6]) directives
of [RFC2616]) directives was present in the response. If the original was present in the response. If the original response included the
response included the "must-revalidate" Cache-Control directive, the "must-revalidate" Cache-Control directive, the cache MAY use the
cache MAY use the entity of that response in replying to a subsequent entity of that response in replying to a subsequent request, but MUST
request, but MUST first revalidate it with the origin server, using first revalidate it with the origin server, using the request headers
the request headers from the new request to allow the origin server from the new request to allow the origin server to authenticate the
to authenticate the new request. Alternatively, if the original new request. Alternatively, if the original response included the
response included the "public" Cache-Control directive, the response "public" Cache-Control directive, the response entity MAY be returned
entity MAY be returned in reply to any subsequent request. in reply to any subsequent request.
3.5 The Authentication-Info Header 3.5 The Authentication-Info Header
The Authentication-Info header is used by the server to communicate The Authentication-Info header is used by the server to communicate
some information regarding the successful authentication in the some information regarding the successful authentication in the
response. response.
AuthenticationInfo = "Authentication-Info" ":" auth-info AuthenticationInfo = "Authentication-Info" ":" auth-info
auth-info = 1#(nextnonce | [ message-qop ] auth-info = 1#(nextnonce | [ message-qop ]
| [ response-auth ] | [ cnonce ] | [ response-auth ] | [ cnonce ]
skipping to change at page 17, line 38 skipping to change at page 16, line 38
* SHA2-512/256. * SHA2-512/256.
* MD5 (for backward compatibility). * MD5 (for backward compatibility).
A future version of this document might add SHA3 [SHA3] as a backup A future version of this document might add SHA3 [SHA3] as a backup
algorithm, once its definition has been finalized and published. algorithm, once its definition has been finalized and published.
When the client receives the response it SHOULD use the topmost When the client receives the response it SHOULD use the topmost
header that it supports, unless a local policy dictates otherwise. header that it supports, unless a local policy dictates otherwise.
The client should ignore any challenge it does not understand. The client should ignore any challenge it does not understand.
3.8 Proxy-Authentication and Proxy-Authorization 3.8 Proxy-Authenticate and Proxy-Authorization
The digest authentication scheme may also be used for authenticating The digest authentication scheme may also be used for authenticating
users to proxies, proxies to proxies, or proxies to origin servers by users to proxies, proxies to proxies, or proxies to origin servers by
use of the Proxy-Authenticate and Proxy-Authorization headers. These use of the Proxy-Authenticate and Proxy-Authorization headers. These
headers are instances of the Proxy-Authenticate and Proxy- headers are instances of the Proxy-Authenticate and Proxy-
Authorization headers specified in sections 10.33 and 10.34 of the Authorization headers specified in sections 4.2 and 4.3 of the
HTTP/1.1 specification [RFC2616] and their behavior is subject to HTTP/1.1 specification [HTTP-P7] and their behavior is subject to
restrictions described there. The transactions for proxy restrictions described there. The transactions for proxy
authentication are very similar to those already described. Upon authentication are very similar to those already described. Upon
receiving a request which requires authentication, the proxy/server receiving a request which requires authentication, the proxy/server
must issue the "407 Proxy Authentication Required" response with a must issue the "407 Proxy Authentication Required" response with a
"Proxy-Authenticate" header. The digest-challenge used in the Proxy- "Proxy-Authenticate" header. The digest-challenge used in the Proxy-
Authenticate header is the same as that for the WWW- Authenticate Authenticate header is the same as that for the WWW- Authenticate
header as defined above in section 3.2.1. header as defined above in section 3.2.1.
The client/proxy must then re-issue the request with a Proxy- The client/proxy must then re-issue the request with a Proxy-
Authorization header, with directives as specified for the Authorization header, with directives as specified for the
Authorization header in section 3.4 above. Authorization header in section 3.4 above.
On subsequent responses, the server sends Proxy-Authentication-Info On subsequent responses, the server sends Proxy-Authenticate-Info
with directives the same as those for the Authentication-Info header with directives the same as those for the Authentication-Info header
field. field.
Note that in principle a client could be asked to authenticate itself 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. to both a proxy and an end-server, but never in the same response.
3.9 Example 3.9 Example
The following example assumes that an access protected document is The following example assumes that an access protected document is
being requested from the server via a GET request. The URI of the being requested from the server via a GET request. The URI of the
skipping to change at page 20, line 21 skipping to change at page 19, line 21
The only allowed value is "UTF-8", to be matched case-insensitively, The only allowed value is "UTF-8", to be matched case-insensitively,
indicating that the server expects the UTF-8 character encoding to be indicating that the server expects the UTF-8 character encoding to be
used ([RFC3629]). used ([RFC3629]).
If the user agent supports the encoding indicated by the server, it If the user agent supports the encoding indicated by the server, it
MAY add the "charset" parameter, with the value it received from the MAY add the "charset" parameter, with the value it received from the
server, to the Proxy-Authenticate or WWW-Authenticate header fields server, to the Proxy-Authenticate or WWW-Authenticate header fields
it sends back to the server. it sends back to the server.
If the user agent does not support the encoding indicated by the If the user agent does not support the encoding indicated by the
server, it MAY add the "charset" parameter to the Proxy-Authenticate server, it MUST fail the request.
or WWW-Authenticate header fields it sends back to the server, but
the value in the parameter should be preceded by an exclamation point
(!).
5 Security Considerations 5 Security Considerations
5.1 Limitations 5.1 Limitations
HTTP Digest authentication, when used with human-memorable passwords, HTTP Digest authentication, when used with human-memorable passwords,
is vulnerable to dictionary attacks. Such attacks are much easier is vulnerable to dictionary attacks. Such attacks are much easier
than cryptographic attacks on any widely used algorithm, including than cryptographic attacks on any widely used algorithm, including
those that are no longer considered secure. In other words, algorithm those that are no longer considered secure. In other words, algorithm
agility does not make this usage any more secure. agility does not make this usage any more secure.
skipping to change at page 20, line 50 skipping to change at page 19, line 47
Digest authentication SHOULD be used over a secure channel like HTTPS Digest authentication SHOULD be used over a secure channel like HTTPS
[RFC2818]. [RFC2818].
5.2 Authentication of Clients using Digest Authentication 5.2 Authentication of Clients using Digest Authentication
Digest Authentication does not provide a strong authentication Digest Authentication does not provide a strong authentication
mechanism, when compared to public key based mechanisms, for example. mechanism, when compared to public key based mechanisms, for example.
However, it is significantly stronger than (e.g.) CRAM-MD5, which has 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 been proposed for use with LDAP [RFC2829], POP and IMAP (see RFC
[9]). It is intended to replace the much weaker and even more 2195). It is intended to replace the much weaker and even more
dangerous Basic mechanism. dangerous Basic mechanism.
Digest Authentication offers no confidentiality protection beyond Digest Authentication offers no confidentiality protection beyond
protecting the actual username and password. All of the rest of the protecting the actual username and password. All of the rest of the
request and response are available to an eavesdropper. request and response are available to an eavesdropper.
Digest Authentication offers only limited integrity protection for Digest Authentication offers only limited integrity protection for
the messages in either direction. If qop=auth-int mechanism is used, the messages in either direction. If qop=auth-int mechanism is used,
those parts of the message used in the calculation of the WWW- those parts of the message used in the calculation of the WWW-
Authenticate and Authorization header field response directive values Authenticate and Authorization header field response directive values
skipping to change at page 24, line 21 skipping to change at page 23, line 21
Or, a hostile proxy might spoof the client into making a request the Or, a hostile proxy might spoof the client into making a request the
attacker wanted rather than one the client wanted. Of course, this is attacker wanted rather than one the client wanted. Of course, this is
still much harder than a comparable attack against Basic still much harder than a comparable attack against Basic
Authentication. Authentication.
5.8 Chosen plaintext attacks 5.8 Chosen plaintext attacks
With Digest authentication, a MITM or a malicious server can With Digest authentication, a MITM or a malicious server can
arbitrarily choose the nonce that the client will use to compute the arbitrarily choose the nonce that the client will use to compute the
response. This is called a "chosen plaintext" attack. The ability to response. This is called a "chosen plaintext" attack. The ability to
choose the nonce is known to make cryptanalysis much easier [8]. choose the nonce is known to make cryptanalysis much easier.
However, no way to analyze the MD5 one-way function used by Digest However, no way to analyze the MD5 one-way function used by Digest
using chosen plaintext is currently known. using chosen plaintext is currently known.
The countermeasure against this attack is for clients to be The countermeasure against this attack is for clients to be
configured to require the use of the optional "cnonce" directive; configured to require the use of the optional "cnonce" directive;
this allows the client to vary the input to the hash in a way not this allows the client to vary the input to the hash in a way not
chosen by the attacker. chosen by the attacker.
5.9 Precomputed dictionary attacks 5.9 Precomputed dictionary attacks
skipping to change at page 27, line 7 skipping to change at page 26, line 7
possibility of replay. Others may satisfied with a nonce like the one possibility of replay. Others may satisfied with a nonce like the one
recommended above restricted to a single IP address and a single ETag recommended above restricted to a single IP address and a single ETag
or with a limited lifetime. or with a limited lifetime.
The bottom line is that *any* compliant implementation will be The bottom line is that *any* compliant implementation will be
relatively weak by cryptographic standards, but *any* compliant relatively weak by cryptographic standards, but *any* compliant
implementation will be far superior to Basic Authentication. implementation will be far superior to Basic Authentication.
6 IANA Considerations 6 IANA Considerations
6.1 HTTP Digest Hash Algorithms Registry
This specification creates a new IANA registry named "HTTP Digest This specification creates a new IANA registry named "HTTP Digest
Hash Algorithms". When registering a new hash algorithm, the Hash Algorithms". When registering a new hash algorithm, the
following information MUST be provided: following information MUST be provided:
o Hash Algorithm o Hash Algorithm
The textual name of the hash algorithm. The textual name of the hash algorithm.
o Digest Size o Digest Size
The size of the algorithm's output in hexadecimal characters. The size of the algorithm's output in hexadecimal characters.
skipping to change at page 27, line 31 skipping to change at page 26, line 33
o Reference o Reference
A reference to the specification that describes the new algorithm. A reference to the specification that describes the new algorithm.
The update policy for this registry shall be Specification Required. The update policy for this registry shall be Specification Required.
The initial registry will contain the following entries: The initial registry will contain the following entries:
Hash Algorithm Digest Size Preference Reference Hash Algorithm Digest Size Preference Reference
-------------- ----------- ---------- --------- -------------- ----------- ---------- ---------
"MD5" 32 0 RFC XXXX "MD5" 32 0 RFC XXXX
"SHA2-256" 64 1 RFC XXXX "SHA2-512-256" 64 1 RFC XXXX
"SHA2-512-256" 64 2 RFC XXXX "SHA2-256" 64 2 RFC XXXX
Each one of the algorithms defined in the registry might have a -sess Each one of the algorithms defined in the registry might have a -sess
variant, e.g. MD5-sess, SHA2-256-sess, etc. variant, e.g. MD5-sess, SHA2-256-sess, etc.
6.2 Digest
This specification registers the Digest scheme with the
Authentication Scheme Registry.
Authentication Scheme Name: Digest
Pointer to specification text: RFCXXX
7 Acknowledgments 7 Acknowledgments
TODO TODO
8 References 8 References
TODO
8.1 Normative References 8.1 Normative References
[RFC2069] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P.,
Luotonen, A., Sink, E., and L. Stewart, "An Extension to
HTTP : Digest Access Authentication", RFC 2069, January
1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2829] Wahl, M., Alvestrand, H., Hodges, J., and R. Morgan,
"Authentication Methods for LDAP", RFC 2829, May 2000.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[HTTP-P1] Fielding, R., Reschke, J., "Hypertext Transfer Protocol
(HTTP/1.1): Message Syntax and Routing", Work in Progress,
November 2013.
[HTTP-P6] Fielding, R., Nottingham, M., Reschke, J., "Hypertext
Transfer Protocol (HTTP/1.1): Caching", Work in Progress,
November 2013.
[HTTP-P7] Fielding, R., Reschke, J., "Hypertext Transfer Protocol
(HTTP/1.1): Authentication", Work in Progress, November
2013.
8.2 Informative References 8.2 Informative References
[RFC2195] Klensin, J., Catoe, R., and P. Krumviede, "IMAP/POP
AUTHorize Extension for Simple Challenge/Response",
RFC 2195, September 1997.
Authors' Addresses Authors' Addresses
Rifaat Shekh-Yusef (Editor) Rifaat Shekh-Yusef (Editor)
Avaya Avaya
250 Sydney Street 250 Sydney Street
Belleville, Ontario Belleville, Ontario
Canada Canada
Phone: +1-613-967-5267 Phone: +1-613-967-5267
Email: rifaat.ietf@gmail.com Email: rifaat.ietf@gmail.com
 End of changes. 26 change blocks. 
138 lines changed or deleted 135 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/