[Errata Rejected] RFC7235 (6307)

RFC Errata System <rfc-editor@rfc-editor.org> Mon, 19 October 2020 04:09 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D99273A12A6 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 18 Oct 2020 21:09:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.748
X-Spam-Level:
X-Spam-Status: No, score=-0.748 tagged_above=-999 required=5 tests=[HEADER_FROM_DIFFERENT_DOMAINS=0.25, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 fbEIGAqChmQA for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 18 Oct 2020 21:09:43 -0700 (PDT)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38E273A12A5 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sun, 18 Oct 2020 21:09:42 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1kUMS1-00017B-Mc for ietf-http-wg-dist@listhub.w3.org; Mon, 19 Oct 2020 04:07:13 +0000
Resent-Date: Mon, 19 Oct 2020 04:07:13 +0000
Resent-Message-Id: <E1kUMS1-00017B-Mc@lyra.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <wwwrun@rfc-editor.org>) id 1kUMS0-00016Y-9f for ietf-http-wg@listhub.w3.org; Mon, 19 Oct 2020 04:07:12 +0000
Received: from rfc-editor.org ([4.31.198.49]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <wwwrun@rfc-editor.org>) id 1kUMRy-0004ri-1k for ietf-http-wg@w3.org; Mon, 19 Oct 2020 04:07:12 +0000
Received: by rfc-editor.org (Postfix, from userid 30) id 47E05F40711; Sun, 18 Oct 2020 21:06:55 -0700 (PDT)
To: nick.a.cullen@googlemail.com, fielding@gbiv.com, julian.reschke@greenbytes.de
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: barryleiba@computer.org, iesg@ietf.org, ietf-http-wg@w3.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20201019040655.47E05F40711@rfc-editor.org>
Date: Sun, 18 Oct 2020 21:06:55 -0700
Received-SPF: pass client-ip=4.31.198.49; envelope-from=wwwrun@rfc-editor.org; helo=rfc-editor.org
X-W3C-Hub-Spam-Status: No, score=-7.2
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1kUMRy-0004ri-1k 6121abb005eadbae63491f2c705a3000
X-Original-To: ietf-http-wg@w3.org
Subject: [Errata Rejected] RFC7235 (6307)
Archived-At: <https://www.w3.org/mid/20201019040655.47E05F40711@rfc-editor.org>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/38103
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

The following errata report has been rejected for RFC7235,
"Hypertext Transfer Protocol (HTTP/1.1): Authentication".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6307

--------------------------------------
Status: Rejected
Type: Technical

Reported by: Nick Cullen <nick.a.cullen@googlemail.com>
Date Reported: 2020-10-15
Rejected by: Barry Leiba (IESG)

Section: 2.1

Original Text
-------------
2.1.  Challenge and Response

   HTTP provides a simple challenge-response authentication framework
   that can be used by a server to challenge a client request and by a
   client to provide authentication information.  It uses a case-
   insensitive token as a means to identify the authentication scheme,
   followed by additional information necessary for achieving
   authentication via that scheme.  The latter can be either a comma-
   separated list of parameters or a single sequence of characters
   capable of holding base64-encoded information.

   Authentication parameters are name=value pairs, where the name token
   is matched case-insensitively, and each parameter name MUST only
   occur once per challenge.

     auth-scheme    = token

     auth-param     = token BWS "=" BWS ( token / quoted-string )


Corrected Text
--------------
2.1.  Challenge and Response

   HTTP provides a simple challenge-response authentication framework
   that can be used by a server to challenge a client request and by a
   client to provide authentication information.  It uses a case-
   insensitive token as a means to identify the authentication scheme,
   followed by additional information necessary for achieving
   authentication via that scheme.  The latter can be either a comma-
   separated list of parameters or a single sequence of characters
   capable of holding base64-encoded information.

   Authentication parameters are name=value pairs, where the name token
   is matched case-insensitively, and each parameter name MUST only
   occur once per challenge.

     auth-scheme    = itoken

     auth-param     = itoken BWS "=" BWS ( token / quoted-string )

N.B. itoken is a restricted subset of token to ensure well defined case insensitivity.


Notes
-----
The general token specification allows many characters (including VCHAR) which means that case insensitivity is tricky to define. A more limited subset of token would be sensible, and the distinction between itoken and token is important in understanding the BNF, and matching that to the specification. The section above is a good example of the confusion that can arise, with 3 instances of token in the ABNF, but two of them are to be interpreted in a different way than the third occurence..
Confusion causes incompatibility with NEGOTIATE being rejected by a system that implements the ABNF, but wrongly expects Negotiate.
P.S. My 'corrected text' and my understanding of ABNF are incomplete. I crave assistance in forming a properly written definition of itoken to 'well define' the safe subset.
 --VERIFIER NOTES-- 
   The RFC says exactly what was intended, and changing that is beyond the scope of errata reports, and likely beyond the scope of the document.  If there's an issue to discuss for a future revision of the RFC, an issue can be filed here:
  https://github.com/httpwg/http-core/issues/

--------------------------------------
RFC7235 (draft-ietf-httpbis-p7-auth-26)
--------------------------------------
Title               : Hypertext Transfer Protocol (HTTP/1.1): Authentication
Publication Date    : June 2014
Author(s)           : R. Fielding, Ed., J. Reschke, Ed.
Category            : PROPOSED STANDARD
Source              : Hypertext Transfer Protocol Bis APP
Area                : Applications
Stream              : IETF
Verifying Party     : IESG