Subject: [Technical Errata Reported] RFC7235 (6307)

From: RFC Errata System <[email-masked]>
Date: Thu, 15 Oct 2020 05:05:37 -0700 (PDT)

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

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

--------------------------------------
Type: Technical
Reported by: Nick Cullen <[email-masked]>

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.

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. 

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

---

From: Julian Reschke <[email-masked]>
Date: Thu, 15 Oct 2020 15:02:21 +0200

This appears to be a proposal for an improvement, not an erratum. Thus I
recommend to reject it.

That said: making clearer what is case-insensitive in the ABNF is an
interesting idea, but the only thing available here would be a different
name (as suggested) plus prose saying what that means.

I believe it is better to leave things as they are: the ABNF defines the
legal syntax, the prose defines the matching process.

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 16 Oct 2020 13:24:51 +1100

Reject. ABNF is already case-insensitive, and limiting token goes far beyond the scope of an errata report.

If you think there's an issue to discuss here, please file at:
  https://github.com/httpwg/http-core/issues/

Cheers,

> On 15 Oct 2020, at 11:05 pm, RFC Errata System <[email-masked]> wrote:
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 16 Oct 2020 14:19:51 +1100

> On 16 Oct 2020, at 2:18 pm, Barry Leiba <[email-masked]> wrote:
> 
>  have to agree, though not for the reason that ABNF is case insensitive.  It’s trie that case mapping is quite dependent upon character sets (there’s case distinction in Latin and Cyrillic, but not in, say, Hebrew or Chinese, but it’s also dependent on language (consider the difference between turning “i” into upper case in English and in Turkish).  And comparisons in general are hard, with lots of other issues such as normalization, variants, and such (do you want 中国 and 中國 to compare as equal or not?).

Token is limited to a subset of ASCII.

Cheers,

---

From: Barry Leiba <[email-masked]>
Date: Thu, 15 Oct 2020 23:18:08 -0400

I have to agree, though not for the reason that ABNF is case insensitive.
It’s trie that case mapping is quite dependent upon character sets (there’s
case distinction in Latin and Cyrillic, but not in, say, Hebrew or Chinese,
but it’s also dependent on language (consider the difference between
turning “i” into upper case in English and in Turkish).  And comparisons in
general are hard, with lots of other issues such as normalization,
variants, and such (do you want 中国 and 中國 to compare as equal or not?).

All of this is way out of scope for this document, and it’s certainly not
“errata”: the document never intended to cover this, so it wasn’t an
oversight.  If anyone thinks the HTTP specs should deal with these sorts of
issues, a new document to add to the suite would be the necessary approach.

Barry

On Thu, Oct 15, 2020 at 10:25 PM Mark Nottingham <[email-masked]> wrote:

> > 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.
> >
> > Instructions:
> > -------------