IETF Logo Mail Archive

[http-auth] [Technical Errata Reported] RFC7616 (4897)

RFC Errata System <rfc-editor@rfc-editor.org> Thu, 29 December 2016 19:37 UTC

Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: http-auth@ietfa.amsl.com
Delivered-To: http-auth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7FF8129614 for <http-auth@ietfa.amsl.com>; Thu, 29 Dec 2016 11:37:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.302
X-Spam-Level:
X-Spam-Status: No, score=-7.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNsdHMdJ3Y7p for <http-auth@ietfa.amsl.com>; Thu, 29 Dec 2016 11:37:13 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2768129488 for <http-auth@ietf.org>; Thu, 29 Dec 2016 11:37:13 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id 8E1D9B80132; Thu, 29 Dec 2016 11:37:13 -0800 (PST)
To: rifaat.ietf@gmail.com, ahrensdc@gmail.com, sophie.bremer@netzkonform.de, stephen.farrell@cs.tcd.ie, Kathleen.Moriarty.ietf@gmail.com, ynir.ietf@gmail.com, rifaat.ietf@gmail.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Message-Id: <20161229193713.8E1D9B80132@rfc-editor.org>
Date: Thu, 29 Dec 2016 11:37:13 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/http-auth/oZwVQ1vNhqAMi8gfCE6x0zzgLm0>
X-Mailman-Approved-At: Thu, 29 Dec 2016 12:04:04 -0800
Cc: http-auth@ietf.org, rfc-editor@rfc-editor.org
Subject: [http-auth] [Technical Errata Reported] RFC7616 (4897)
X-BeenThere: http-auth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: HTTP authentication methods <http-auth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/http-auth>, <mailto:http-auth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/http-auth/>
List-Post: <mailto:http-auth@ietf.org>
List-Help: <mailto:http-auth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-auth>, <mailto:http-auth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Dec 2016 19:37:15 -0000

The following errata report has been submitted for RFC7616,
"HTTP Digest Access Authentication".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=7616&eid=4897

--------------------------------------
Type: Technical
Reported by: Chaim Geretz <chaim.geretz@idt.net>

Section: 3.9.2

Original Text
-------------
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


Corrected Text
--------------
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

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC7616 (draft-ietf-httpauth-digest-19)
--------------------------------------
Title               : HTTP Digest Access Authentication
Publication Date    : September 2015
Author(s)           : R. Shekh-Yusef, Ed., D. Ahrens, S. Bremer
Category            : PROPOSED STANDARD
Source              : Hypertext Transfer Protocol Authentication
Area                : Security
Stream              : IETF
Verifying Party     : IESG

v2.23.0 | Report a Bug | By Email