RFC Errata
RFC 7616, "HTTP Digest Access Authentication", September 2015
Source of RFC: httpauth (sec)
Errata ID: 4897
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Chaim Geretz
Date Reported: 2016-12-29
Section 3.9.2 says:
3.9.2. Example with SHA-512-256, Charset, and Userhash
The following example assumes that an access-protected document is
being requested from the server via a GET request. The URI for the
request is "http://api.example.org/doe.json". Both client and server
know the userhash of the username, support the UTF-8 character
encoding scheme, and use the SHA-512-256 algorithm. The username for
the request is a variation of "Jason Doe", where the 'a' actually is
Unicode code point U+00E4 ("LATIN SMALL LETTER A WITH DIAERESIS"),
and the first 'o' is Unicode code point U+00F8 ("LATIN SMALL LETTER O
WITH STROKE"), leading to the octet sequence using the UTF-8 encoding
scheme:
J U+00E4 s U+00F8 n D o e
4A C3A4 73 C3B8 6E 20 44 6F 65
The password is "Secret, or not?".
The first time the client requests the document, no Authorization
header field is sent, so the server responds with:
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest
realm="api@example.org",
qop="auth",
algorithm=SHA-512-256,
nonce="5TsQWLVdgBdmrQ0XsxbDODV+57QdFR34I9HAbC/RVvkK",
opaque="HRPCssKJSGjCrkzDg8OhwpzCiGPChXYjwrI2QmXDnsOS",
charset=UTF-8,
userhash=true
Shekh-Yusef, et al. Standards Track [Page 19]
RFC 7616 HTTP Digest Access Authentication September 2015
The client can prompt the user for the required credentials and send
a new request with following Authorization header field:
Authorization: Digest
username="488869477bf257147b804c45308cd62ac4e25eb717
b12b298c79e62dcea254ec",
realm="api@example.org",
uri="/doe.json",
algorithm=SHA-512-256,
nonce="5TsQWLVdgBdmrQ0XsxbDODV+57QdFR34I9HAbC/RVvkK",
nc=00000001,
cnonce="NTg6RKcb9boFIAS3KrFK9BGeh+iDa/sm6jUMp2wds69v",
qop=auth,
response="ae66e67d6b427bd3f120414a82e4acff38e8ecd9101d
6c861229025f607a79dd",
opaque="HRPCssKJSGjCrkzDg8OhwpzCiGPChXYjwrI2QmXDnsOS",
userhash=true
If the client cannot provide a hashed username for any reason, the
client can try a request with this Authorization header field:
Authorization: Digest
username*=UTF-8''J%C3%A4s%C3%B8n%20Doe,
realm="api@example.org",
uri="/doe.json",
algorithm=SHA-512-256,
nonce="5TsQWLVdgBdmrQ0XsxbDODV+57QdFR34I9HAbC/RVvkK",
nc=00000001,
cnonce="NTg6RKcb9boFIAS3KrFK9BGeh+iDa/sm6jUMp2wds69v",
qop=auth,
response="ae66e67d6b427bd3f120414a82e4acff38e8ecd9101d
6c861229025f607a79dd",
opaque="HRPCssKJSGjCrkzDg8OhwpzCiGPChXYjwrI2QmXDnsOS",
userhash=false
It should say:
3.9.2. Example with SHA-512-256, Charset, and Userhash
The following example assumes that an access-protected document is
being requested from the server via a GET request. The URI for the
request is "http://api.example.org/doe.json". Both client and server
know the userhash of the username, support the UTF-8 character
encoding scheme, and use the SHA-512-256 algorithm. The username for
the request is a variation of "Jason Doe", where the 'a' actually is
Unicode code point U+00E4 ("LATIN SMALL LETTER A WITH DIAERESIS"),
and the first 'o' is Unicode code point U+00F8 ("LATIN SMALL LETTER O
WITH STROKE"), leading to the octet sequence using the UTF-8 encoding
scheme:
J U+00E4 s U+00F8 n D o e
4A C3A4 73 C3B8 6E 20 44 6F 65
The password is "Secret, or not?".
The first time the client requests the document, no Authorization
header field is sent, so the server responds with:
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest
realm="api@example.org",
qop="auth",
algorithm=SHA-512-256,
nonce="5TsQWLVdgBdmrQ0XsxbDODV+57QdFR34I9HAbC/RVvkK",
opaque="HRPCssKJSGjCrkzDg8OhwpzCiGPChXYjwrI2QmXDnsOS",
charset=UTF-8,
userhash=true
Shekh-Yusef, et al. Standards Track [Page 19]
RFC 7616 HTTP Digest Access Authentication September 2015
The client can prompt the user for the required credentials and send
a new request with following Authorization header field:
Authorization: Digest
username="793263caabb707a56211940d90411ea4a575adeccb
7e360aeb624ed06ece9b0b",
realm="api@example.org",
uri="/doe.json",
algorithm=SHA-512-256,
nonce="5TsQWLVdgBdmrQ0XsxbDODV+57QdFR34I9HAbC/RVvkK",
nc=00000001,
cnonce="NTg6RKcb9boFIAS3KrFK9BGeh+iDa/sm6jUMp2wds69v",
qop=auth,
response="3798d4131c277846293534c3edc11bd8a5e4cdcbff78
b05db9d95eeb1cec68a5",
opaque="HRPCssKJSGjCrkzDg8OhwpzCiGPChXYjwrI2QmXDnsOS",
userhash=true
If the client cannot provide a hashed username for any reason, the
client can try a request with this Authorization header field:
Authorization: Digest
username*=UTF-8''J%C3%A4s%C3%B8n%20Doe,
realm="api@example.org",
uri="/doe.json",
algorithm=SHA-512-256,
nonce="5TsQWLVdgBdmrQ0XsxbDODV+57QdFR34I9HAbC/RVvkK",
nc=00000001,
cnonce="NTg6RKcb9boFIAS3KrFK9BGeh+iDa/sm6jUMp2wds69v",
qop=auth,
response="3798d4131c277846293534c3edc11bd8a5e4cdcbff78
b05db9d95eeb1cec68a5",
opaque="HRPCssKJSGjCrkzDg8OhwpzCiGPChXYjwrI2QmXDnsOS",
userhash=false
Notes:
If the SHA512/256 algorithm first mentioned in Section 3.2 is to be implemented as defined in FIPS 180.4 Section 6.7 the values of username and response need to be corrected.
Changes start at page 19 of the RFC.
I created this as technical errata since the current values given in the example are for a SHA512/256 algorithm implemented as described in Section 7 of both FIPS 180-3 and FIPS 180-4