Subject: Editorial issues with RFC 7616

From: Christer Holmberg <[email-masked]>
Date: Mon, 28 Jun 2021 09:45:26 +0000

(I am bringing the issues below to this list, as the HTTPAUTH list has been terminated.)

Hi,

The following issues can probably be considered editorial, and people will claim that "When you read the RFC you'll get it".

However, they have caused some confusion, why I think it is important to bring them up. If considered worthwhile fixing, I assume it can be done with the errata tool.

My apologies if the issues have already been discussed.

Section 3.8 contains the following text:

   "The digest-challenge used in the
   Proxy-Authenticate header field is the same as that for the WWW-
   Authenticate header field as defined above in Section 3.3."

Similar text existed in RFC 2617, which RFC 7616 obsoletes, but the difference is that Section 3.3 of RFC 7616 does not define the WWW-Authenticate header field.

Q1:

The WWW-Authenticate header field is nowadays defined in RFC 7235. And, eventhough Section 3.3 of RFC 7616 does contain a couple of references to RFC 7235, it is not clear that the references are for the header field definition. In addition, the references are to Section 2.2 of RFC 7235, which does not define the header field.

Q2

"digest-challenge" is not mentioned in Section 3.3 - or anywhere else in RFC 7616 (except in the statement above). RFC 7235 does not use the terminology either. It was used as an ANBF term in RFC 2617. It should be "Digest scheme challenge", which is also used elsewhere.

Again, it could be claimed that anyone should understand what "digest-challenge" means, but the confusion can arise if people look at 2617 ABNF and then wonder where it has disappeared.

Q3:

Section 3.3 of RFC 7616 lists the allowed WWW-Authenticate parameters. But, there is no syntax for them. At the end of Section 3.3 there is text saying which parameters should be encoded as quoted-strings, and which should not be encoded as quoted-strings. But, for the 'charset' and 'userhash' parameters there is no text. Should they be encoded as quoted-strings or not, or can they be both?

Yes, there are some examples where 'charset' and 'userhash' values are used without quoted-strings, but one should not have to implement examples.

Regards,

Christer

---

From: Julian Reschke <[email-masked]>
Date: Mon, 28 Jun 2021 11:57:39 +0200

Am 28.06.2021 um 11:45 schrieb Christer Holmberg:
> ...
> Q3:
>
> Section 3.3 of RFC 7616 lists the allowed WWW-Authenticate parameters.
> But, there is no syntax for them. At the end of Section 3.3 there is
> text saying which parameters should be encoded as quoted-strings, and
> which should not be encoded as quoted-strings. But, for the ‘charset’
> and ‘userhash’ parameters there is no text. Should they be encoded as
> quoted-strings or not, or can they be both?
> ...

The syntax is generic, as defined in
<https://greenbytes.de/tech/webdav/rfc7235.html#challenge.and.response>.

For the other issues I would recommend to raise errata.

Best regards, Julian

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 28 Jun 2021 10:43:54 +0000

Hi Julian,

Eventhough the generic syntax allows both tokens and quoted-strings for parameter values, I don't think it means that you by default can use both for a particular parameter. If it does, I think it should be explicitly stated.

Regards,

Christer

-----Original Message-----
From: Julian Reschke <[email-masked]> 
Sent: maanantai 28. kesäkuuta 2021 12.58
To: [email-masked]
Subject: Re: Editorial issues with RFC 7616

Am 28.06.2021 um 11:45 schrieb Christer Holmberg:
> which should not be encoded as quoted-strings. But, for the 'charset'
> and 'userhash' parameters there is no text. Should they be encoded as 

The syntax is generic, as defined in
<https://protect2.fireeye.com/v1/url?k=4b20e57b-14bbdc3f-4b20a5e0-861d41abace8-a333515a382dca50&q=1&e=32427685-fb2e-4541-99c4-0473c981d15a&u=https%3A%2F%2Fgreenbytes.de%2Ftech%2Fwebdav%2Frfc7235.html%23challenge.and.response>.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 28 Jun 2021 13:35:50 +0200

> Eventhough the generic syntax allows both tokens and quoted-strings for parameter values, I don't think it means that you by default can use both for a particular parameter. If it does, I think it…

Nope. In *general*, both notations need to be allowed - otherwise
there's no hope to write an universal parser.

If only one notation can be used for a specific parameter (for historic
reasons), it needs to be specified explicitly for that parameter.

Best regards, Julian

---

From: [email-masked]
Date: Mon, 28 Jun 2021 23:41:44 +1200

On 2021-06-28 22:43, Christer Holmberg wrote:
> Hi Julian,
> 
> Eventhough the generic syntax allows both tokens and quoted-strings
> for parameter values, I don't think it means that you by default can
> use both for a particular parameter.

That is exactly what it means. Either token or quoted-string can be used 
for any parameter value. Except parameters which are defined as needing 
a specific form.

Amos

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 28 Jun 2021 12:24:35 +0000

Hi,

> That is exactly what it means. Either token or quoted-string can be used for any parameter value. Except parameters which are defined as needing a specific form.

Ok, I found the following text in RFC 7231:

   "A parameter value that matches the token production can be
   transmitted either as a token or within a quoted-string.  The quoted
   and unquoted values are equivalent."

In addition, it seems like for HTTP quoted-string values are not case-sensitive, as the following examples are all equivalent:

     text/html;charset=utf-8
     text/html;charset=UTF-8
     Text/HTML;Charset="utf-8"
     text/html; charset="utf-8"

SIP also uses the header fields, and in SIP quoted-strings are by default *case-sensitive*, so e.g., "utf-8" and "UTF-8" would not be equivalent. But, I guess that is for SIP to sort out, if needed.

Regards,

Christer

---

From: Julian Reschke <[email-masked]>
Date: Mon, 28 Jun 2021 20:14:37 +0200

>     and unquoted values are equivalent."

Yes.

>       text/html; charset="utf-8"

That's because it's the charset parameter. Don't generalize from that
example.

> SIP also uses the header fields, and in SIP quoted-strings are by default *case-sensitive*, so e.g., "utf-8" and "UTF-8" would not be equivalent. But, I guess that is for SIP to sort out, if needed.

It's specific to the definition of the charset parameter in HTTP's
Content-Type field.

Best regards, Julian

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 30 Jun 2021 09:32:38 +0000

Hi,

> That's because it's the charset parameter. Don't generalize from that example.
>
> It's specific to the definition of the charset parameter in HTTP's Content-Type field.

Ok, but how does it work in general, then?

For example, assume I have a parameter foo that allows both token and quoted-string parameter values.

I then define/register the value "BAR". Does that mean that "BaR", "bar", "Bar" etc are now allowed - unless explicitly indicated, as in the case of charset?

Regards,

Christer

---

From: Julian Reschke <[email-masked]>
Date: Wed, 30 Jun 2021 13:05:18 +0200

> I then define/register the value "BAR". Does that mean that "BaR", "bar", "Bar" etc are now allowed - unless explicitly indicated, as in the case of charset?

They are "allowed" in any case (syntactically).

If the parameter is defined to be case-sensitive, then yes, they are
different. Otherwise they would be equivalent.

Note that that is true for the token form as well (it allows both upper
and lowercase).

Best regards, Julian

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 30 Jun 2021 12:16:22 +0000

Hi,

> They are "allowed" in any case (syntactically).

Sure. Bad wording.  What I meant was whether they are semantically identical.

>If the parameter is defined to be case-sensitive, then yes, they are different. Otherwise they would be equivalent.
>
>Note that that is true for the token form as well (it allows both upper and lowercase).

So, what are the case-sensitivity rules for 'userhash', 'domain', 'nonce', 'opaque' and 'algorithm' auth parameters? 

Section 2.1 of RFC 7235 *DOES* say:

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

So, based on that one could assume that case-insensitive is the default, unless otherwise explicitly specified. So far so good.

However, for a couple of parameter there is explicit text saying that the value is case-insensitive:

For the 'stale' parameter RFC 7616 explicitly says:

      "A case-insensitive flag indicating that the previous request from
      the client was rejected because the nonce value was stale."

For the 'charset' parameter RFC 7617 (which, btw, is only informatively referenced by RFC 7616) explicitly says:

   "The only allowed value is "UTF-8"; it is to be matched case-
   insensitively (see [RFC2978], Section 2.3)."

So, assuming that the default is case-insensitive, perhaps that can be clarified in an errata. I think it is related to my issue Q1.

Regards,

Christer

---

From: Julian Reschke <[email-masked]>
Date: Wed, 30 Jun 2021 14:23:05 +0200

> So, based on that one could assume that case-insensitive is the default, unless otherwise explicitly specified. So far so good.

No, that's not what it says. That statement is about the parameter *name*.

In general, if something is case-insensitive, it needs to be stated
explicitly.

>        the client was rejected because the nonce value was stale."

See?

> So, assuming that the default is case-insensitive, perhaps that can be clarified in an errata. I think it is related to my issue Q1.

Unless stated, things are case-sensitive, so I really don't see an issue
here yet.

Best regards, Julian

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 30 Jun 2021 12:52:50 +0000

Hi,

...

> No, that's not what it says. That statement is about the parameter *name*.

Doh! True. Sorry.

...

>Unless stated, things are case-sensitive, so I really don't see an issue here yet.

Is that defined for HTTP somewhere, or is it a generic ABNF rule?

The reason I ask is because for SIP the default for parameter values is case-insensitive, unless otherwise specified, and tokens are always case-insensitive.

Also, is there a reason for e.g., 'userhash' to be case-sensitive, while 'stale' is case-insensitive? For both parameters the only allowed values are "true" and "false".

Regards,

Christer

---

From: Julian Reschke <[email-masked]>
Date: Wed, 30 Jun 2021 15:00:57 +0200

> Is that defined for HTTP somewhere, or is it a generic ABNF rule?

The ABNF defines legal syntax, nothing more. That does not affect at all
whether case differences are significant.

In the HTTP specs, we try to be consistent in stating when things are
case-insensitive. If we don't say that, the default of case-sensitity
applies.

(Note that outside the ASCII-only niche of HTTP fields,
case-insensitivity is a hard problem, essentially requiring access to
the Unicode character database)

> Also, is there a reason for e.g., 'userhash' to be case-sensitive, while 'stale' is case-insensitive? For both parameters the only allowed values are "true" and "false".

That you would need to ask the authors of the Digest spec (I note that
"userhash" was introduced in 7616, while stale predates that).

Best regards, Julian