Re: [Technical Errata Reported] RFC7235 (6307)

[Mark Nottingham <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 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 <[e-mail]>
> 
> 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

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