draft-ietf-httpauth-digest-00.txt   draft-ietf-httpauth-digest-01.txt 
HTTPAuth Working Group R. Shekh-Yusef, Ed. HTTPAuth Working Group R. Shekh-Yusef, Ed.
Internet-Draft D. Ahrens, Ed. Internet-Draft D. Ahrens
Obsoletes: 2617 (if approved) Avaya Obsoletes: 2617 (if approved) Avaya
Intended Status: Standards Track October 7, 2013 Intended Status: Standards Track S. Bremer
Expires: April 10, 2014 Expires: July 5, 2014 Netzkonform
January 1, 2014
HTTP Digest Access Authentication HTTP Digest Access Authentication
draft-ietf-httpauth-digest-00.txt draft-ietf-httpauth-digest-01.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 1, line 43 skipping to change at page 1, line 44
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Copyright and License Notice Copyright and License Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
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
skipping to change at page 2, line 27 skipping to change at page 2, line 27
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Syntax Convention . . . . . . . . . . . . . . . . . . . . . . . 6 2 Syntax Convention . . . . . . . . . . . . . . . . . . . . . . . 6
3 Digest Access Authentication Scheme . . . . . . . . . . . . . . 6 3 Digest Access Authentication Scheme . . . . . . . . . . . . . . 6
3.1 Overall Operation . . . . . . . . . . . . . . . . . . . . . 6 3.1 Overall Operation . . . . . . . . . . . . . . . . . . . . . 6
3.2 Representation of Digest Values . . . . . . . . . . . . . . 6 3.2 Representation of Digest Values . . . . . . . . . . . . . . 6
3.3 The WWW-Authenticate Response Header . . . . . . . . . . . . 7 3.3 The WWW-Authenticate Response Header . . . . . . . . . . . . 7
3.4 The Authorization Request Header . . . . . . . . . . . . . . 10 3.4 The Authorization Request Header . . . . . . . . . . . . . . 10
3.4.1 Request-Digest . . . . . . . . . . . . . . . . . . . . . 12 3.4.1 Request-Digest . . . . . . . . . . . . . . . . . . . . . 12
3.4.2 A1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.4.2 A1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4.3 A2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.4.3 A2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.4.4 Directive Values and Quoted-String . . . . . . . . . . . 13 3.4.4 Username Hashing . . . . . . . . . . . . . . . . . . . . 14
3.4.5 Various Considerations . . . . . . . . . . . . . . . . . 14 3.4.5 Directive Values and Quoted-String . . . . . . . . . . . 14
3.6 Digest Operation . . . . . . . . . . . . . . . . . . . . . . 16 3.4.6 Various Considerations . . . . . . . . . . . . . . . . . 15
3.7 Security Protocol Negotiation . . . . . . . . . . . . . . . 18 3.5 The Authentication-Info Header . . . . . . . . . . . . . . . 16
3.8 Proxy-Authentication and Proxy-Authorization . . . . . . . . 18 3.6 Digest Operation . . . . . . . . . . . . . . . . . . . . . . 17
3.9 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.7 Security Protocol Negotiation . . . . . . . . . . . . . . . 19
4 Internationalization . . . . . . . . . . . . . . . . . . . . . . 21 3.8 Proxy-Authentication and Proxy-Authorization . . . . . . . . 19
5 Security Considerations . . . . . . . . . . . . . . . . . . . . 21 3.9 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.1 Limitations . . . . . . . . . . . . . . . . . . . . . . . . 21 4 Internationalization . . . . . . . . . . . . . . . . . . . . . . 22
5.2 Authentication of Clients using Digest Authentication . . . 21 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 22
5.3 Limited Use Nonce Values . . . . . . . . . . . . . . . . . . 22 5.1 Limitations . . . . . . . . . . . . . . . . . . . . . . . . 22
5.4 Replay Attacks . . . . . . . . . . . . . . . . . . . . . . . 22 5.2 Authentication of Clients using Digest Authentication . . . 22
5.5 Weakness Created by Multiple Authentication Schemes . . . . 23 5.3 Limited Use Nonce Values . . . . . . . . . . . . . . . . . . 23
5.6 Online dictionary attacks . . . . . . . . . . . . . . . . . 24 5.4 Replay Attacks . . . . . . . . . . . . . . . . . . . . . . . 24
5.7 Man in the Middle . . . . . . . . . . . . . . . . . . . . . 24 5.5 Weakness Created by Multiple Authentication Schemes . . . . 24
5.8 Chosen plaintext attacks . . . . . . . . . . . . . . . . . . 25 5.6 Online dictionary attacks . . . . . . . . . . . . . . . . . 25
5.9 Precomputed dictionary attacks . . . . . . . . . . . . . . . 25 5.7 Man in the Middle . . . . . . . . . . . . . . . . . . . . . 25
5.10 Batch brute force attacks . . . . . . . . . . . . . . . . . 25 5.8 Chosen plaintext attacks . . . . . . . . . . . . . . . . . . 26
5.11 Spoofing by Counterfeit Servers . . . . . . . . . . . . . . 26 5.9 Precomputed dictionary attacks . . . . . . . . . . . . . . . 26
5.12 Storing passwords . . . . . . . . . . . . . . . . . . . . . 26 5.10 Batch brute force attacks . . . . . . . . . . . . . . . . . 27
5.13 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.11 Spoofing by Counterfeit Servers . . . . . . . . . . . . . . 27
6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 27 5.12 Storing passwords . . . . . . . . . . . . . . . . . . . . . 27
7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.13 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 28
7.1 Normative References . . . . . . . . . . . . . . . . . . . . 27
7.2 Informative References . . . . . . . . . . . . . . . . . . . 27 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 29
8 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.1 Normative References . . . . . . . . . . . . . . . . . . . . 29
8.2 Informative References . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
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. It uses an extensible,
case-insensitive token to identify the authentication scheme, case-insensitive token to identify the authentication scheme,
followed by a comma-separated list of attribute-value pairs which followed by a comma-separated list of attribute-value pairs which
carry the parameters necessary for achieving authentication via that carry the parameters necessary for achieving authentication via that
scheme. scheme.
skipping to change at page 5, line 11 skipping to change at page 5, line 11
additional semantics specific to the authentication scheme. Note that additional semantics specific to the authentication scheme. Note that
there may be multiple challenges with the same auth-scheme but there may be multiple challenges with the same auth-scheme but
different realms. different realms.
A user agent that wishes to authenticate itself with an origin A user agent that wishes to authenticate itself with an origin
server--usually, but not necessarily, after receiving a 401 server--usually, but not necessarily, after receiving a 401
(Unauthorized)--MAY do so by including an Authorization header field (Unauthorized)--MAY do so by including an Authorization header field
with the request. A client that wishes to authenticate itself with a with the request. A client that wishes to authenticate itself with a
proxy--usually, but not necessarily, after receiving a 407 (Proxy proxy--usually, but not necessarily, after receiving a 407 (Proxy
Authentication Required)--MAY do so by including a Proxy- Authentication Required)--MAY do so by including a Proxy-
Authorization header field with the request. Both the Authorization Authorization header field with the request. Both the Authorization
field value and the Proxy-Authorization field value consist of field value and the Proxy-Authorization field value consist of
credentials containing the authentication information of the client credentials containing the authentication information of the client
for the realm of the resource being requested. The user agent MUST 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 choose to use one of the challenges with the strongest auth-scheme it
understands and request credentials from the user based upon that understands and request credentials from the user based upon that
challenge. challenge.
credentials = auth-scheme #auth-param credentials = auth-scheme #auth-param
Note that many browsers will only recognize Basic and will require Note that many browsers will only recognize Basic and will require
skipping to change at page 7, line 13 skipping to change at page 7, line 13
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 challenge = "Digest" digest-challenge
digest-challenge = 1#( realm | [ domain ] | nonce | digest-challenge = 1#( realm | [ domain ] | nonce |
[ opaque ] |[ stale ] | [ algorithm ] | [ opaque ] |[ stale ] | [ algorithm ] |
[ qop-options ] | [charset] | [auth-param]) [ 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" |
"SHA2-512-256" | "SHA2-512-256-sess" | "SHA2-512-256" | "SHA2-512-256-sess" |
token) token)
qop-options = "qop" "=" <"> 1#qop-value <"> qop-options = "qop" "=" <"> 1#qop-value <">
qop-value = "auth" | "auth-int" | token qop-value = "auth" | "auth-int" | token
charset = "charset" "=" ("UTF-8" | token) charset = "charset" "=" ("UTF-8" | token)
userhash = "userhash" "=" ( "true" | "false" )
The meanings of the values of the directives used above are as The meanings of the values of the directives used above are as
follows: 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".
skipping to change at page 8, line 36 skipping to change at page 8, line 37
where time-stamp is a server-generated time or other non-repeating where time-stamp is a server-generated time or other non-repeating
value, ETag is the value of the HTTP ETag header associated with value, ETag is the value of the HTTP ETag header associated with
the requested entity, and private-key is data known only to the the requested entity, and private-key is data known only to the
server. With a nonce of this form a server would recalculate the server. With a nonce of this form a server would recalculate the
hash portion after receiving the client authentication header and hash portion after receiving the client authentication header and
reject the request if it did not match the nonce from that header reject the request if it did not match the nonce from that header
or if the time-stamp value is not recent enough. In this way the or if the time-stamp value is not recent enough. In this way the
server can limit the time of the nonce's validity. The inclusion server can limit the time of the nonce's validity. The inclusion
of the ETag prevents a replay request for an updated version of of the ETag prevents a replay request for an updated version of
the resource. (Note: including the IP address of the client in the resource. (Note: including the IP address of the client in the
the nonce would appear to offer the server the ability to limit nonce would appear to offer the server the ability to limit the
the reuse of the nonce to the same client that originally got it. reuse of the nonce to the same client that originally got it.
However, that would break proxy farms, where requests from a However, that would break proxy farms, where requests from a
single user often go through different proxies in the farm. Also, single user often go through different proxies in the farm. Also,
IP address spoofing is not that hard.) IP address spoofing is not that hard.)
An implementation might choose not to accept a previously used An implementation might choose not to accept a previously used
nonce or a previously used digest, in order to protect against a nonce or a previously used digest, in order to protect against a
replay attack. Or, an implementation might choose to use one-time replay attack. Or, an implementation might choose to use one-time
nonces or digests for POST or PUT requests and a time-stamp for nonces or digests for POST or PUT requests and a time-stamp for
GET requests. For more details on the issues involved see section GET requests. For more details on the issues involved see section
5 of this document. 5 of this document.
The nonce is opaque to the client. The nonce is opaque to the client.
opaque opaque
A string of data, specified by the server, which should be A string of data, specified by the server, which should be
returned by the client unchanged in the Authorization header of returned by the client unchanged in the Authorization header of
subsequent requests with URIs in the same protection space. It is subsequent requests with URIs in the same protection space. It is
recommended that this string be base64 or hexadecimal data. recommended that this string be base64 or hexadecimal data.
stale stale
A flag, indicating that the previous request from the client was A case-insensitive flag, indicating that the previous request from
rejected because the nonce value was stale. If stale is TRUE the client was rejected because the nonce value was stale. If
(case-insensitive), the client may wish to simply retry the stale is TRUE, the client may wish to simply retry the request
request with a new encrypted response, without reprompting the with a new encrypted response, without reprompting the user for a
user for a new username and password. The server should only set new username and password. The server should only set stale to
stale to TRUE if it receives a request for which the nonce is TRUE if it receives a request for which the nonce is invalid but
invalid but with a valid digest for that nonce (indicating that with a valid digest for that nonce (indicating that the client
the client knows the correct username/password). If stale is knows the correct username/password). If stale is FALSE, or
FALSE, or anything other than TRUE, or the stale directive is not anything other than TRUE, or the stale directive is not present,
present, the username and/or password are invalid, and new values the username and/or password are invalid, and new values must be
must be obtained. obtained.
algorithm algorithm
A string indicating a pair of algorithms used to produce the A string indicating a pair of algorithms used to produce the
digest and a checksum. If this is not present it is assumed to be digest and a checksum. If this is not present it is assumed to be
"MD5". If the algorithm is not understood, the challenge should be "MD5". If the algorithm is not understood, the challenge should be
ignored (and a different one used, if there is more than one). ignored (and a different one used, if there is more than one).
In this document the string obtained by applying the digest In this document the string obtained by applying the digest
algorithm to the data "data" with secret "secret" will be denoted algorithm to the data "data" with secret "secret" will be denoted
by KD(secret, data), and the string obtained by applying the by KD(secret, data), and the string obtained by applying the
skipping to change at page 10, line 27 skipping to change at page 10, line 27
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 could be used by the server to
indicate the encoding scheme it supports. indicate the encoding scheme it supports.
userhash
This is an optional parameter that could be used by the server to
indicate that it supports username hashing.
auth-param auth-param
This directive allows for future extensions. Any unrecognized This directive allows for future extensions. Any unrecognized
directive MUST be ignored. 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 Authorization
header line, which is defined according to the framework above, header line, which is defined according to the framework above,
utilized as follows. utilized as follows.
credentials = "Digest" digest-response credentials = "Digest" digest-response
digest-response = 1#( username | realm | nonce | digest-uri | digest-response = 1#( username | realm | nonce | digest-uri |
response | [ algorithm ] | [cnonce] | response | [ algorithm ] | [cnonce] |
[opaque] | [message-qop] | [opaque] | [message-qop] |
[nonce-count] | [charset] | [auth-param] ) [nonce-count] | [charset] | [userhash] |
[auth-param] )
username = "username" "=" username-value username = "username" "=" username-value
username-value = quoted-string username-value = quoted-string
digest-uri = "uri" "=" digest-uri-value digest-uri = "uri" "=" digest-uri-value
digest-uri-value = request-uri ; As specified by HTTP/1.1 digest-uri-value = request-uri ; As specified by HTTP/1.1
message-qop = "qop" "=" qop-value message-qop = "qop" "=" qop-value
cnonce = "cnonce" "=" cnonce-value cnonce = "cnonce" "=" cnonce-value
cnonce-value = nonce-value cnonce-value = nonce-value
nonce-count = "nc" "=" nc-value nonce-count = "nc" "=" nc-value
nc-value = 8LHEX nc-value = 8LHEX
response = "response" "=" request-digest response = "response" "=" request-digest
request-digest = <"> digest-size LHEX <"> request-digest = <"> digest-size LHEX <">
digest-size = "32" | "64" digest-size = "32" | "64"
LHEX = "0" | "1" | "2" | "3" | LHEX = "0" | "1" | "2" | "3" |
"4" | "5" | "6" | "7" | "4" | "5" | "6" | "7" |
"8" | "9" | "a" | "b" | "8" | "9" | "a" | "b" |
"c" | "d" | "e" | "f" "c" | "d" | "e" | "f"
charset = "charset" "=" ("UTF-8" | token) charset = "charset" "=" ("UTF-8" | token)
userhash = "userhash" "=" ( "true" | "false" )
The values of the opaque and algorithm fields must be those supplied The values of the opaque and algorithm fields must be those supplied
in the WWW-Authenticate response header for the entity being in the WWW-Authenticate response header for the entity being
requested. requested.
response response
A string of digest-size hex digits computed as defined below, A string of digest-size hex digits computed as defined below,
which proves that the user knows a password which proves that the user knows a password
username username
skipping to change at page 11, line 41 skipping to change at page 11, line 48
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
client and server to avoid chosen plaintext attacks, to provide client and server to avoid chosen plaintext attacks, to provide
mutual authentication, and to provide some message integrity mutual authentication, and to provide some message integrity
protection. See the descriptions below of the calculation of the protection. See the descriptions below of the calculation of the
response- digest and request-digest values. response- digest and request-digest values.
nonce-count nonce-count
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 nc-value is the in the WWW-Authenticate header field. The nc-value is the
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 is an optional parameter that could be used by the client to
indicate the encoding scheme it supports. indicate the encoding scheme it supports.
userhash
This is an optional parameter that could be used by the client to
indicate that it supports username hashing.
auth-param auth-param
This directive allows for future extensions. Any unrecognized This directive allows for future extensions. Any unrecognized
directive MUST be ignored. 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.
3.4.1 Request-Digest 3.4.1 Request-Digest
If the "qop" value is "auth" or "auth-int": If the "qop" value is "auth" or "auth-int":
request-digest = <"> < KD ( H(A1), unq(nonce-value) request-digest = <"> < KD ( H(A1), unq(nonce-value)
":" nc-value ":" nc-value
":" unq(cnonce-value) ":" unq(cnonce-value)
":" unq(qop-value) ":" unq(qop-value)
":" H(A2) ":" H(A2)
) <"> ) <">
If the "qop" directive is not present (this construction is for If the "qop" directive is not present (this construction is for
compatibility with RFC 2069): compatibility with RFC 2069):
request-digest = request-digest =
<"> < KD ( H(A1), unq(nonce-value) ":" H(A2) ) > <"> < KD ( H(A1), unq(nonce-value) ":" H(A2) ) > <">
<">
See below for the definitions for A1 and A2. See below for the definitions for A1 and A2.
3.4.2 A1 3.4.2 A1
If the "algorithm" directive's value is "MD5", "SHA2-256", or "SHA2- If the "algorithm" directive's value is "MD5", "SHA2-256", or "SHA2-
512-256", then A1 is: 512-256", then A1 is:
A1 = unq(username-value) ":" unq(realm-value) ":" passwd A1 = unq(username-value) ":" unq(realm-value) ":" passwd
where where
passwd = < user's password > passwd = < user's password >
If the "algorithm" directive's value is "MD5-sess", "SHA2-256", or If the "algorithm" directive's value is "MD5-sess", "SHA2-256-sess",
"SHA2-512-256", then A1 is calculated only once - on the first or "SHA2-512-256-sess", then A1 is calculated only once - on the
request by the client following receipt of a WWW-Authenticate first request by the client following receipt of a WWW-Authenticate
challenge from the server. It uses the server nonce from that challenge from the server. It uses the server nonce from that
challenge, and the first client nonce value to construct A1 as challenge, and the first client nonce value to construct A1 as
follows: follows:
A1 = H( unq(username-value) ":" unq(realm-value) A1 = H( unq(username-value) ":" unq(realm-value)
":" passwd ) ":" passwd )
":" unq(nonce-value) ":" unq(cnonce-value) ":" unq(nonce-value) ":" unq(cnonce-value)
This creates a 'session key' for the authentication of subsequent This creates a 'session key' for the authentication of subsequent
requests and responses which is different for each "authentication requests and responses which is different for each "authentication
skipping to change at page 13, line 49 skipping to change at page 14, line 16
If the "qop" directive's value is "auth" or is unspecified, then A2 If the "qop" directive's value is "auth" or is unspecified, then A2
is: is:
A2 = Method ":" digest-uri-value A2 = Method ":" digest-uri-value
If the "qop" value is "auth-int", then A2 is: If the "qop" value is "auth-int", then A2 is:
A2 = Method ":" digest-uri-value ":" H(entity-body) A2 = Method ":" digest-uri-value ":" H(entity-body)
3.4.4 Directive Values and Quoted-String 3.4.4 Username Hashing
To protect the transport of the username from the client to the
server, the server SHOULD set the "userhash" parameter with the value
of "true" in the WWW-Authentication header.
If the client supports the "userhash" parameter, and the "userhash"
parameter value in the WWW-Authentication header is set to "true",
then the client SHOULD calculate a hash of the username after any
other hash calculation and include the "userhash" parameter with the
value of "true" in the Authorization Request Header. If the client
does not provide the "username" as a hash value or the "userhash"
parameter with the value of "true", the server MAY reject the
request.
The server may change the nonce value, so the client should be ready
to recalculate the hashed username.
The following is the operation that the client will take to hash the
username:
username = H( H( username ":" realm ) ":" nonce)
3.4.5 Directive Values and Quoted-String
Note that the value of many of the directives, such as "username- Note that the value of many of the directives, such as "username-
value", are defined as a "quoted-string". However, the "unq" notation value", are defined as a "quoted-string". However, the "unq" notation
indicates that surrounding quotation marks are removed in forming the indicates that surrounding quotation marks are removed in forming the
string A1. Thus if the Authorization header includes the fields string A1. Thus if the Authorization header includes the fields
username="Mufasa", realm=myhost@testrealm.com username="Mufasa", realm=myhost@testrealm.com
and the user Mufasa has password "Circle Of Life" then H(A1) would be and the user Mufasa has password "Circle Of Life" then H(A1) would be
H(Mufasa:myhost@testrealm.com:Circle Of Life) with no quotation marks H(Mufasa:myhost@testrealm.com:Circle Of Life) with no quotation marks
in the digested string. in the digested string.
skipping to change at page 14, line 35 skipping to change at page 15, line 25
side of the colons which delimit their fields unless that white space side of the colons which delimit their fields unless that white space
was in the quoted strings or entity body being digested. was in the quoted strings or entity body being digested.
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.5 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 5.1.1 of [RFC2616]. The "request-uri" value is the Request-URI from
the request line as specified in section 5.1.2 of [RFC2616]. This may the request line as specified in section 5.1.2 of [RFC2616]. This may
be "*", an "absoluteURL" or an "abs_path" as specified in section be "*", an "absoluteURL" or an "abs_path" as specified in section
5.1.2 of [RFC2616], but it MUST agree with the Request-URI. In 5.1.2 of [RFC2616], but it MUST agree with the Request-URI. In
particular, it MUST be an "absoluteURL" if the Request-URI is an particular, it MUST be an "absoluteURL" if the Request-URI is an
"absoluteURL". The "cnonce-value" is an optional client-chosen value "absoluteURL". The "cnonce-value" is an optional client-chosen value
whose purpose is to foil chosen plaintext attacks. whose purpose is to foil chosen plaintext attacks.
skipping to change at page 15, line 25 skipping to change at page 16, line 14
any other request, unless one of two Cache-Control (see section 14.9 any other request, unless one of two Cache-Control (see section 14.9
of [RFC2616]) directives was present in the response. If the original of [RFC2616]) directives was present in the response. If the original
response included the "must-revalidate" Cache-Control directive, the response included the "must-revalidate" Cache-Control directive, the
cache MAY use the entity of that response in replying to a subsequent cache MAY use the entity of that response in replying to a subsequent
request, but MUST first revalidate it with the origin server, using request, but MUST first revalidate it with the origin server, using
the request headers from the new request to allow the origin server the request headers from the new request to allow the origin server
to authenticate the new request. Alternatively, if the original to authenticate the new request. Alternatively, if the original
response included the "public" Cache-Control directive, the response response included the "public" Cache-Control directive, the response
entity MAY be returned in reply to any subsequent request. entity MAY be returned 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 ]
| [nonce-count] ) | [nonce-count] )
nextnonce = "nextnonce" "=" nonce-value nextnonce = "nextnonce" "=" nonce-value
response-auth = "rspauth" "=" response-digest response-auth = "rspauth" "=" response-digest
response-digest = <"> *LHEX <"> response-digest = <"> digest-size 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 16, line 4 skipping to change at page 16, line 42
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".
Server implementations should carefully consider the performance Server implementations should carefully consider the performance
implications of the use of this mechanism; pipelined requests will implications of the use of this mechanism; pipelined requests will
not be possible if every response includes a nextnonce directive not be possible if every response includes a nextnonce directive
that must be used on the next request received by the server. that must be used on the next request received by the server.
Consideration should be given to the performance vs. security Consideration should be given to the performance vs. security
tradeoffs of allowing an old nonce value to be used for a limited tradeoffs of allowing an old nonce value to be used for a limited
time to permit request pipelining. Use of the nonce-count can time to permit request pipelining. Use of the nonce-count can
retain most of the security advantages of a new server nonce retain most of the security advantages of a new server nonce
without the deleterious affects on pipelining. without the deleterious affects on pipelining.
message-qop message-qop
Indicates the "quality of protection" options applied to the Indicates the "quality of protection" options applied to the
response by the server. The value "auth" indicates response by the server. The value "auth" indicates
authentication; the value "auth-int" indicates authentication with authentication; the value "auth-int" indicates authentication with
integrity protection. The server SHOULD use the same value for the integrity protection. The server SHOULD use the same value for the
message- qop directive in the response as was sent by the client message- qop directive in the response as was sent by the client
in the corresponding request. in the corresponding request.
skipping to change at page 19, line 19 skipping to change at page 20, line 19
On subsequent responses, the server sends Proxy-Authentication-Info On subsequent responses, the server sends Proxy-Authentication-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 is borrowed from RFC2617 and assumes that an The following example assumes that an access protected document is
access protected document is being requested from the server via a being requested from the server via a GET request. The URI of the
GET request. The URI of the document is document is http://www.nowhere.org/dir/index.html". Both client and
http://www.nowhere.org/dir/index.html". Both client and server know server know that the username for this document is "Mufasa" and the
that the username for this document is "Mufasa" and the password is password is "Circle of Life" ( with one space between each of the
"Circle of Life" ( with one space between each of the three words). three words).
The first time the client requests the document, no Authorization The first time the client requests the document, no Authorization
header is sent, so the server responds with: header is sent, so the server responds with:
HTTP/1.1 401 Unauthorized HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest WWW-Authenticate: Digest
realm = "testrealm@host.com", realm = "testrealm@host.com",
qop="auth, auth-int", qop="auth, auth-int",
algorithm="SHA2-256", algorithm="SHA2-256",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
skipping to change at page 21, line 51 skipping to change at page 23, line 4
It is recommended that Digest authentication be used over a secure It is recommended that Digest authentication be used over a secure
channel like HTTPS. channel like HTTPS.
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 password. All of the rest of the request and
response are available to an eavesdropper. 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
skipping to change at page 24, line 6 skipping to change at page 25, line 8
5.5 Weakness Created by Multiple Authentication Schemes 5.5 Weakness Created by Multiple Authentication Schemes
An HTTP/1.1 server may return multiple challenges with a 401 An HTTP/1.1 server may return multiple challenges with a 401
(Authenticate) response, and each challenge may use a different auth- (Authenticate) response, and each challenge may use a different auth-
scheme. A user agent MUST choose to use the strongest auth- scheme it scheme. A user agent MUST choose to use the strongest auth- scheme it
understands and request credentials from the user based upon that understands and request credentials from the user based upon that
challenge. challenge.
Note that many browsers will only recognize Basic and will require Note that many browsers will only recognize Basic and will require
that it be the first auth-scheme presented. Servers should only that it be the first auth-scheme presented. Servers should only
include Basic if it is minimally acceptable. include Basic if it is minimally acceptable.
When the server offers choices of authentication schemes using the When the server offers choices of authentication schemes using the
WWW-Authenticate header, the strength of the resulting authentication WWW-Authenticate header, the strength of the resulting authentication
is only as good as that of the of the weakest of the authentication is only as good as that of the of the weakest of the authentication
schemes. See section 4.8 below for discussion of particular attack schemes. See section 5.7 below for discussion of particular attack
scenarios that exploit multiple authentication schemes. scenarios that exploit multiple authentication schemes.
5.6 Online dictionary attacks 5.6 Online dictionary attacks
If the attacker can eavesdrop, then it can test any overheard If the attacker can eavesdrop, then it can test any overheard
nonce/response pairs against a list of common words. Such a list is nonce/response pairs against a list of common words. Such a list is
usually much smaller than the total number of possible passwords. The usually much smaller than the total number of possible passwords. The
cost of computing the response for each password on the list is paid cost of computing the response for each password on the list is paid
once for each challenge. once for each challenge.
skipping to change at page 27, line 32 skipping to change at page 28, line 42
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
<IANA considerations text> This specification creates a new IANA registry named "HTTP Digest
Hash Algorithms". When registering a new hash algorithm, the
following information MUST be provided:
7 References o The textual name of the hash algorithm.
o A reference to the specification that describes the new algorithm.
7.1 Normative References The update policy for this registry shall be Specification Required.
7.2 Informative References The initial registry will contain the following entries:
Hash Algorithm Reference
------------------ ---------
"MD5" RFC XXXX
"MD5-sess" RFC XXXX
"SHA2-256" RFC XXXX
"SHA2-256-sess" RFC XXXX
"SHA2-512-256" RFC XXXX
"SHA2-512-256-sess" RFC XXXX
7 Acknowledgments
TODO
8 References
8.1 Normative References
[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,
April 1 1996.
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 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
David Ahrens David Ahrens
Avaya Avaya
California California
USA USA
EMail: ahrensdc@gmail.com EMail: ahrensdc@gmail.com
Sophie Bremer
Netzkonform
Germany
Email: sophie.bremer@netzkonform.de
 End of changes. 37 change blocks. 
80 lines changed or deleted 161 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/