RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 2 records.

Status: Verified (1)

RFC 7616, "HTTP Digest Access Authentication", September 2015

Source of RFC: httpauth (sec)

Errata ID: 4495

Status: Verified
Type: Editorial

Reported By: Tuomo Untinen
Date Reported: 2015-10-09
Verifier Name: Kathleen Moriarty
Date Verified: 2015-12-08

Section 3.9.1. says:

   Both client and
   server know that the username for this document is "Mufasa" and the
   password is "Circle of Life" (with one space between each of the
   three words).

It should say:

   Both client and
   server know that the username for this document is "Mufasa" and the 
   password is "Circle of Life" (with one space between 
   each of the three words and non-capital o in word of).

Notes:

In RFC 2617, the password was "Circle Of Life" with capital O in the word "Of". Also, RFC 7616 section 3.4.5 mentions the password "Circle Of Life" with capital O in the word "Of". It can be difficult to notice a non-capital o from an example password as it is elsewhere capital O.

Status: Reported (1)

RFC 7616, "HTTP Digest Access Authentication", September 2015

Source of RFC: httpauth (sec)

Errata ID: 4897

Status: Reported
Type: Technical

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

Report New Errata



Search RFCs
Advanced Search
×