draft-ietf-httpauth-digest-01.txt   draft-ietf-httpauth-digest-02.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 5, 2014 Netzkonform Expires: July 22, 2014 Netzkonform
January 1, 2014 January 18, 2014
HTTP Digest Access Authentication HTTP Digest Access Authentication
draft-ietf-httpauth-digest-01.txt draft-ietf-httpauth-digest-02.txt
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 18 skipping to change at page 2, line 18
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Syntax Convention . . . . . . . . . . . . . . . . . . . . . . . 6 2 Syntax Convention . . . . . . . . . . . . . . . . . . . . . . . 4
3 Digest Access Authentication Scheme . . . . . . . . . . . . . . 6 3 Digest Access Authentication Scheme . . . . . . . . . . . . . . 4
3.1 Overall Operation . . . . . . . . . . . . . . . . . . . . . 6 3.1 Overall Operation . . . . . . . . . . . . . . . . . . . . . 4
3.2 Representation of Digest Values . . . . . . . . . . . . . . 6 3.2 Representation of Digest Values . . . . . . . . . . . . . . 4
3.3 The WWW-Authenticate Response Header . . . . . . . . . . . . 7 3.3 The WWW-Authenticate Response Header . . . . . . . . . . . . 5
3.4 The Authorization Request Header . . . . . . . . . . . . . . 10 3.4 The Authorization Request Header . . . . . . . . . . . . . . 8
3.4.1 Request-Digest . . . . . . . . . . . . . . . . . . . . . 12 3.4.1 Request-Digest . . . . . . . . . . . . . . . . . . . . . 11
3.4.2 A1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.4.2 A1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4.3 A2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.4.3 A2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4.4 Username Hashing . . . . . . . . . . . . . . . . . . . . 14 3.4.4 Username Hashing . . . . . . . . . . . . . . . . . . . . 12
3.4.5 Directive Values and Quoted-String . . . . . . . . . . . 14 3.4.5 Directive Values and Quoted-String . . . . . . . . . . . 12
3.4.6 Various Considerations . . . . . . . . . . . . . . . . . 15 3.4.6 Various Considerations . . . . . . . . . . . . . . . . . 13
3.5 The Authentication-Info Header . . . . . . . . . . . . . . . 16 3.5 The Authentication-Info Header . . . . . . . . . . . . . . . 14
3.6 Digest Operation . . . . . . . . . . . . . . . . . . . . . . 17 3.6 Digest Operation . . . . . . . . . . . . . . . . . . . . . . 15
3.7 Security Protocol Negotiation . . . . . . . . . . . . . . . 19 3.7 Security Protocol Negotiation . . . . . . . . . . . . . . . 17
3.8 Proxy-Authentication and Proxy-Authorization . . . . . . . . 19 3.8 Proxy-Authentication and Proxy-Authorization . . . . . . . . 17
3.9 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.9 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4 Internationalization . . . . . . . . . . . . . . . . . . . . . . 22 4 Internationalization . . . . . . . . . . . . . . . . . . . . . . 20
5 Security Considerations . . . . . . . . . . . . . . . . . . . . 22 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 20
5.1 Limitations . . . . . . . . . . . . . . . . . . . . . . . . 22 5.1 Limitations . . . . . . . . . . . . . . . . . . . . . . . . 20
5.2 Authentication of Clients using Digest Authentication . . . 22 5.2 Authentication of Clients using Digest Authentication . . . 20
5.3 Limited Use Nonce Values . . . . . . . . . . . . . . . . . . 23 5.3 Limited Use Nonce Values . . . . . . . . . . . . . . . . . . 21
5.4 Replay Attacks . . . . . . . . . . . . . . . . . . . . . . . 24 5.4 Replay Attacks . . . . . . . . . . . . . . . . . . . . . . . 22
5.5 Weakness Created by Multiple Authentication Schemes . . . . 24 5.5 Weakness Created by Multiple Authentication Schemes . . . . 22
5.6 Online dictionary attacks . . . . . . . . . . . . . . . . . 25 5.6 Online dictionary attacks . . . . . . . . . . . . . . . . . 23
5.7 Man in the Middle . . . . . . . . . . . . . . . . . . . . . 25 5.7 Man in the Middle . . . . . . . . . . . . . . . . . . . . . 23
5.8 Chosen plaintext attacks . . . . . . . . . . . . . . . . . . 26 5.8 Chosen plaintext attacks . . . . . . . . . . . . . . . . . . 24
5.9 Precomputed dictionary attacks . . . . . . . . . . . . . . . 26 5.9 Precomputed dictionary attacks . . . . . . . . . . . . . . . 24
5.10 Batch brute force attacks . . . . . . . . . . . . . . . . . 27 5.10 Batch brute force attacks . . . . . . . . . . . . . . . . . 25
5.11 Spoofing by Counterfeit Servers . . . . . . . . . . . . . . 27 5.11 Spoofing by Counterfeit Servers . . . . . . . . . . . . . . 25
5.12 Storing passwords . . . . . . . . . . . . . . . . . . . . . 27 5.12 Storing passwords . . . . . . . . . . . . . . . . . . . . . 25
5.13 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 28 5.13 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 28 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 27
7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 29 7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 27
8 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.1 Normative References . . . . . . . . . . . . . . . . . . . . 29 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 27
8.2 Informative References . . . . . . . . . . . . . . . . . . . 29 8.2 Informative References . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 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. It uses an extensible, client to provide authentication information. This document defines
case-insensitive token to identify the authentication scheme, the HTTP Digest Authentication scheme that may be used with the
followed by a comma-separated list of attribute-value pairs which authentication mechanism.
carry the parameters necessary for achieving authentication via that
scheme.
auth-scheme = token
auth-param = token "=" ( token | quoted-string )
The 401 (Unauthorized) response message is used by an origin server
to challenge the authorization of a user agent. This response MUST
include a WWW-Authenticate header field containing at least one
challenge applicable to the requested resource. The 407 (Proxy
Authentication Required) response message is used by a proxy to
challenge the authorization of a client and MUST include a Proxy-
Authenticate header field containing at least one challenge
applicable to the proxy for the requested resource.
challenge = auth-scheme 1*SP 1#auth-param
Note: User agents will need to take special care in parsing the WWW-
Authenticate or Proxy-Authenticate header field value if it contains
more than one challenge, or if more than one WWW-Authenticate header
field is provided, since the contents of a challenge may itself
contain a comma-separated list of authentication parameters.
The authentication parameter realm is defined for all authentication
schemes:
realm = "realm" "=" realm-value
realm-value = quoted-string
The realm directive (case-insensitive) is required for all
authentication schemes that issue a challenge. The realm value (case-
sensitive), in combination with the canonical root URL (the
absoluteURI for the server whose abs_path is empty; see section 5.1.2
of [RFC2616]) of the server being accessed, defines the protection
space. These realms allow the protected resources on a server to be
partitioned into a set of protection spaces, each with its own
authentication scheme and/or authorization database. The realm value
is a string, generally assigned by the origin server, which may have
additional semantics specific to the authentication scheme. Note that
there may be multiple challenges with the same auth-scheme but
different realms.
A user agent that wishes to authenticate itself with an origin
server--usually, but not necessarily, after receiving a 401
(Unauthorized)--MAY do so by including an Authorization header field
with the request. A client that wishes to authenticate itself with a
proxy--usually, but not necessarily, after receiving a 407 (Proxy
Authentication Required)--MAY do so by including a Proxy-
Authorization header field with the request. Both the Authorization
field value and the Proxy-Authorization field value consist of
credentials containing the authentication information of the client
for the realm of the resource being requested. The user agent MUST
choose to use one of the challenges with the strongest auth-scheme it
understands and request credentials from the user based upon that
challenge.
credentials = auth-scheme #auth-param
Note that many browsers will only recognize Basic and will require
that it be the first auth-scheme presented. Servers should only
include Basic if it is minimally acceptable.
The protection space determines the domain over which credentials can
be automatically applied. If a prior request has been authorized, the
same credentials MAY be reused for all other requests within that
protection space for a period of time determined by the
authentication scheme, parameters, and/or user preference. Unless
otherwise defined by the authentication scheme, a single protection
space cannot extend outside the scope of its server.
If the origin server does not wish to accept the credentials sent
with a request, it SHOULD return a 401 (Unauthorized) response. The
response MUST include a WWW-Authenticate header field containing at
least one (possibly new) challenge applicable to the requested
resource. If a proxy does not accept the credentials sent with a
request, it SHOULD return a 407 (Proxy Authentication Required). The
response MUST include a Proxy-Authenticate header field containing a
(possibly new) challenge applicable to the proxy for the requested
resource.
The HTTP protocol does not restrict applications to this simple
challenge-response mechanism for access authentication. Additional
mechanisms MAY be used, such as encryption at the transport level or
via message encapsulation, and with additional header fields
specifying authentication information. However, these additional
mechanisms are not defined by this specification.
Proxies MUST be completely transparent regarding user agent The details of the challenge-response authentication mechanism are
authentication by origin servers. That is, they must forward the WWW- specified in the [draft-ietf-httpbis-p7-auth-25] document.
Authenticate and Authorization headers untouched, and follow the
rules found in section 14.8 of [RFC2616]. Both the Proxy-Authenticate
and the Proxy-Authorization header fields are hop-by-hop headers (see
section 13.5.1 of [RFC2616]).
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 6, line 35 skipping to change at page 4, line 43
The Digest scheme is based on a simple challenge-response paradigm. The Digest scheme is based on a simple challenge-response paradigm.
The Digest scheme challenges using a nonce value. A valid response The Digest scheme challenges using a nonce value. A valid response
contains a checksum of the username, the password, the given nonce contains a checksum of the username, the password, the given nonce
value, the HTTP method, and the requested URI. In this way, the value, the HTTP method, and the requested URI. In this way, the
password is never sent in the clear. The username and password must password is never sent in the clear. The username and password must
be prearranged in some fashion not addressed by this document. be prearranged in some fashion not addressed by this document.
3.2 Representation of Digest Values 3.2 Representation of Digest Values
An optional header allows the server to specify the algorithm used to An optional header allows the server to specify the algorithm used to
create the checksum or digest. By default the SHA2-256 algorithm is create the checksum or digest. This documents adds SHA2-256 and SHA2-
used, with SHA2-512/256 being used as a backup algorithm. To 512/256 algorithms. To maintain backwards compatibility, the MD5
maintain backwards compatibility, the MD5 algorithm is still algorithm is still supported but not recommended.
supported but not recommended.
The size of the digest depends on the algorithm used. The bits in The size of the digest depends on the algorithm used. The bits in
the digest are converted from the most significant to the least the digest are converted from the most significant to the least
significant bit, four bits at a time to the ASCII representation as significant bit, four bits at a time to the ASCII representation as
follows. Each four bits is represented by its familiar hexadecimal follows. Each four bits is represented by its familiar hexadecimal
notation from the characters 0123456789abcdef, that is binary 0000 is notation from the characters 0123456789abcdef, that is binary 0000 is
represented by the character '0', 0001 by '1' and so on up to the represented by the character '0', 0001 by '1' and so on up to the
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, which for the digest scheme is
utilized as follows: utilized as follows.
challenge = "Digest" digest-challenge The following defines the scheme and the parameters for the
challenge:
auth-scheme = "Digest" digest-challenge
digest-challenge = 1#( realm | [ domain ] | nonce | digest-challenge = 1#( realm | [ domain ] | nonce |
[ opaque ] |[ stale ] | [ algorithm ] | [ opaque ] |[ stale ] | [ algorithm ] |
[ qop-options ] | [charset] | [userhash] | [ qop-options ] | [charset] | [userhash] )
[auth-param])
domain = "domain" "=" <"> URI ( 1*SP URI ) <"> domain = "domain" "=" <"> URI ( 1*SP URI ) <">
URI = absoluteURI | abs_path URI = absoluteURI | abs_path
nonce = "nonce" "=" nonce-value nonce = "nonce" "=" nonce-value
nonce-value = quoted-string nonce-value = quoted-string
opaque = "opaque" "=" quoted-string opaque = "opaque" "=" quoted-string
stale = "stale" "=" ( "true" | "false" ) stale = "stale" "=" ( "true" | "false" )
algorithm = "algorithm" "=" ( algorithm = "algorithm" "=" (
"MD5" | "MD5-sess" | "MD5" | "MD5-sess" |
"SHA2-256" | "SHA2-256-sess" | "SHA2-256" | "SHA2-256-sess" |
skipping to change at page 10, line 24 skipping to change at page 8, line 36
implementations compliant with this version of the Digest scheme. implementations compliant with this version of the Digest scheme.
If present, it is a quoted string of one or more tokens indicating If present, it is a quoted string of one or more tokens indicating
the "quality of protection" values supported by the server. The the "quality of protection" values supported by the server. The
value "auth" indicates authentication; the value "auth-int" value "auth" indicates authentication; the value "auth-int"
indicates authentication with integrity protection; see the indicates authentication with integrity protection; see the
descriptions below for calculating the response directive value descriptions below for calculating the response directive value
for the application of this choice. Unrecognized options MUST be for the application of this choice. Unrecognized options MUST be
ignored. ignored.
charset charset
This is an optional parameter that could be used by the server to This is an OPTIONAL parameter that is used by the server to
indicate the encoding scheme it supports. indicate the encoding scheme it supports.
userhash userhash
This is an optional parameter that could be 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.
auth-param
This directive allows for future extensions. Any unrecognized
directive MUST be ignored.
3.4 The Authorization Request Header 3.4 The Authorization Request Header
The client is expected to retry the request, passing an Authorization The client is expected to retry the request, passing an
header line, which is defined according to the framework above, Authorization header line, which is defined according to the
utilized as follows. framework above, utilized as follows.
credentials = "Digest" digest-response The following defines the scheme and the parameters for the
digest-response = 1#( username | realm | nonce | digest-uri | response:
response | [ algorithm ] | [cnonce] |
[opaque] | [message-qop] |
[nonce-count] | [charset] | [userhash] |
[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 = <"> digest-size LHEX <">
digest-size = "32" | "64"
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 supplied auth-scheme = "Digest" digest-response
in the WWW-Authenticate response header for the entity being digest-response = 1#( username | realm | nonce |
requested. 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" )
response The values of the opaque and algorithm fields must be those
A string of digest-size hex digits computed as defined below, supplied in the WWW-Authenticate response header for the entity
which proves that the user knows a password being requested.
response
A string of the hex digits computed as defined below, which proves
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-URI 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
RFC 2069 [RFC2069], but SHOULD be used if the server indicated RFC 2069 [RFC2069], but SHOULD be used if the server indicated
that qop is supported by providing a qop directive in the WWW- that qop is supported by providing a qop directive in the WWW-
Authenticate header field. Authenticate header field.
cnonce cnonce
This MUST be specified if a qop directive is sent (see above), and 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 MUST NOT be specified if the server did not send a qop directive
in the WWW-Authenticate header field. The cnonce-value is an in the WWW-Authenticate header field. The cnonce-value is an
opaque quoted string value provided by the client and used by both opaque quoted string value provided by the client and used by both
skipping to change at page 12, line 21 skipping to change at page 10, line 30
hexadecimal count of the number of requests (including the current hexadecimal count of the number of requests (including the current
request) that the client has sent with the nonce value in this request) that the client has sent with the nonce value in this
request. For example, in the first request sent in response to a request. For example, in the first request sent in response to a
given nonce value, the client sends "nc=00000001". The purpose of given nonce value, the client sends "nc=00000001". The purpose of
this directive is to allow the server to detect request replays by 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 maintaining its own copy of this count - if the same nc-value is
seen twice, then the request is a replay. See the description seen twice, then the request is a replay. See the description
below of the construction of the request-digest value. below of the construction of the request-digest value.
charset charset
This is an optional parameter that could be used by the client to This OPTIONAL parameter is used by the client to indicate the
indicate the encoding scheme it supports. character encoding used for the username and password.
userhash userhash
This is an optional parameter that could be used by the client to This OPTIONAL parameter is used by the client to indicate that the
indicate that it supports username hashing. username has been hashed.
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 If a directive or its value is improper, or required directives are
missing, the proper response is 400 Bad Request. If the request- missing, the proper response is 400 Bad Request. If the request-
digest is invalid, then a login failure should be logged, since digest is invalid, then a login failure should be logged, since
repeated login failures from a single client may indicate an attacker repeated login failures from a single client may indicate an attacker
attempting to guess passwords. attempting to guess passwords.
The definition of request-digest above indicates the encoding for its The definition of request-digest above indicates the encoding for its
value. The following definitions show how the value is computed. value. The following definitions show how the value is computed.
skipping to change at page 14, line 24 skipping to change at page 12, line 27
A2 = Method ":" digest-uri-value ":" H(entity-body) A2 = Method ":" digest-uri-value ":" H(entity-body)
3.4.4 Username Hashing 3.4.4 Username Hashing
To protect the transport of the username from the client to the To protect the transport of the username from the client to the
server, the server SHOULD set the "userhash" parameter with the value server, the server SHOULD set the "userhash" parameter with the value
of "true" in the WWW-Authentication header. of "true" in the WWW-Authentication header.
If the client supports the "userhash" parameter, and the "userhash" If the client supports the "userhash" parameter, and the "userhash"
parameter value in the WWW-Authentication header is set to "true", parameter value in the WWW-Authentication header is set to "true",
then the client SHOULD calculate a hash of the username after any then the client MUST calculate a hash of the username after any other
other hash calculation and include the "userhash" parameter with the hash calculation and include the "userhash" parameter with the value
value of "true" in the Authorization Request Header. If the client of "true" in the Authorization Request Header. If the client does not
does not provide the "username" as a hash value or the "userhash" provide the "username" as a hash value or the "userhash" parameter
parameter with the value of "true", the server MAY reject the with the value of "true", the server MAY reject the request.
request.
The server may change the nonce value, so the client should be ready The server may change the nonce value, so the client should be ready
to recalculate the hashed username. to recalculate the hashed username.
The following is the operation that the client will take to hash the The following is the operation that the client will take to hash the
username: username:
username = H( H( username ":" realm ) ":" nonce) username = H( H( username ":" realm ) ":" nonce)
3.4.5 Directive Values and Quoted-String 3.4.5 Directive Values and Quoted-String
skipping to change at page 16, line 26 skipping to change at page 14, line 30
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 ]
| [nonce-count] ) | [nonce-count] )
nextnonce = "nextnonce" "=" nonce-value nextnonce = "nextnonce" "=" nonce-value
response-auth = "rspauth" "=" response-digest response-auth = "rspauth" "=" response-digest
response-digest = <"> digest-size LHEX <"> response-digest = <"> *LHEX <">
digest-size = "32" | "64"
The value of the nextnonce directive is the nonce the server wishes The value of the nextnonce directive is the nonce the server wishes
the client to use for a future authentication response. The server the client to use for a future authentication response. The server
may send the Authentication-Info header with a nextnonce field as a may send the Authentication-Info header with a nextnonce field as a
means of implementing one-time or otherwise changing nonces. If the means of implementing one-time or otherwise changing nonces. If the
nextnonce field is present the client SHOULD use it when constructing nextnonce field is present the client SHOULD use it when constructing
the Authorization header for its next request. Failure of the client 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 to do so may result in a request to re-authenticate from the server
with the "stale=TRUE". with the "stale=TRUE".
skipping to change at page 19, line 27 skipping to change at page 17, line 27
status code, and include one or more WWW-Authenticate headers. If the status code, and include one or more WWW-Authenticate headers. If the
server challenges with multiple Digest headers, then each one of server challenges with multiple Digest headers, then each one of
these headers MUST use a different digest algorithm. The server MUST these headers MUST use a different digest algorithm. The server MUST
add these Digest headers to the response in order of preference, add these Digest headers to the response in order of preference,
starting with the most preferred header, followed by the less starting with the most preferred header, followed by the less
preferred headers. preferred headers.
This specification defines the following preference list, starting This specification defines the following preference list, starting
with the most preferred algorithm: with the most preferred algorithm:
* SHA2-256 as the default algorithm. * SHA2-256.
* SHA2-512/256 as a backup algorithm. * 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-Authentication and Proxy-Authorization
skipping to change at page 22, line 41 skipping to change at page 20, line 41
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.
As a result, Digest authentication SHOULD be used only with passwords As a result, Digest authentication SHOULD be used only with passwords
that have a reasonable amount of entropy, e.g. 128-bit or more. Such that have a reasonable amount of entropy, e.g. 128-bit or more. Such
passwords typically cannot be memorized by humans but can be used for passwords typically cannot be memorized by humans but can be used for
automated web services. automated web services.
It is recommended that Digest authentication be used over a secure Digest authentication SHOULD be used over a secure channel like HTTPS
channel like HTTPS. [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 [10], POP and IMAP (see RFC 2195
[9]). It is intended to replace the much weaker and even more [9]). 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 password. All of the rest of the request and protecting the actual username and password. All of the rest of the
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
(see section 3.2 above) are protected. Most header fields and their (see section 3.2 above) are protected. Most header fields and their
values could be modified as a part of a man-in-the-middle attack. values could be modified as a part of a man-in-the-middle attack.
Many needs for secure HTTP transactions cannot be met by Digest Many needs for secure HTTP transactions cannot be met by Digest
Authentication. For those needs TLS or SHTTP are more appropriate Authentication. For those needs TLS or SHTTP are more appropriate
protocols. In particular Digest authentication cannot be used for any protocols. In particular Digest authentication cannot be used for any
transaction requiring confidentiality protection. Nevertheless many transaction requiring confidentiality protection. Nevertheless many
functions remain for which Digest authentication is both useful and functions remain for which Digest authentication is both useful and
appropriate. Any service in present use that uses Basic should be appropriate.
switched to Digest as soon as practical.
5.3 Limited Use Nonce Values 5.3 Limited Use Nonce Values
The Digest scheme uses a server-specified nonce to seed the The Digest scheme uses a server-specified nonce to seed the
generation of the request-digest value (as specified in section generation of the request-digest value (as specified in section
3.2.2.1 above). As shown in the example nonce in section 3.2.1, the 3.2.2.1 above). As shown in the example nonce in section 3.2.1, the
server is free to construct the nonce such that it may only be used server is free to construct the nonce such that it may only be used
from a particular client, for a particular resource, for a limited from a particular client, for a particular resource, for a limited
period of time or number of uses, or any other restrictions. Doing period of time or number of uses, or any other restrictions. Doing
so strengthens the protection provided against, for example, replay so strengthens the protection provided against, for example, replay
skipping to change at page 28, line 46 skipping to change at page 27, line 11
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
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 The textual name of the hash algorithm. o Hash Algorithm
o A reference to the specification that describes the new algorithm. The textual name of the hash algorithm.
o Digest Size
The size of the algorithm's output in hexadecimal characters.
o Preference
The preference of the algorithm, with zero being the least
preferred.
o Reference
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 Reference Hash Algorithm Digest Size Preference Reference
------------------ --------- -------------- ----------- ---------- ---------
"MD5" RFC XXXX "MD5" 32 0 RFC XXXX
"MD5-sess" RFC XXXX "SHA2-256" 64 1 RFC XXXX
"SHA2-256" RFC XXXX "SHA2-512-256" 64 2 RFC XXXX
"SHA2-256-sess" RFC XXXX
"SHA2-512-256" RFC XXXX Each one of the algorithms defined in the registry might have a -sess
"SHA2-512-256-sess" RFC XXXX variant, e.g. MD5-sess, SHA2-256-sess, etc.
7 Acknowledgments 7 Acknowledgments
TODO TODO
8 References 8 References
8.1 Normative References TODO
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC1776] Crocker, S., "The Address is the Message", RFC 1776, April
1 1995.
[TRUTHS] Callon, R., "The Twelve Networking Truths", RFC 1925, 8.1 Normative References
April 1 1996.
8.2 Informative References 8.2 Informative References
[EVILBIT] Bellovin, S., "The Security Flag in the IPv4 Header",
RFC 3514, April 1 2003.
[RFC5513] Farrel, A., "IANA Considerations for Three Letter
Acronyms", RFC 5513, April 1 2009.
[RFC5514] Vyncke, E., "IPv6 over Social Networks", RFC 5514, April 1
2009.
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. 32 change blocks. 
241 lines changed or deleted 134 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/