Re: [libmicrohttpd] Digest Authentication algorithm field case sensitivity

[Evgeny Grin]

Values must match precisely what is specified by RFC, so this fix 
definitely is an improvement.

However, it is not absolutely clear whether case-sensitive or 
case-insensitive match should be used for parameters and values.

The initial RFC2617 specified that:
* realm token must be case-insensitive,
* realm value must be case-sensitive,
* userids "might be" case sensitive,
* value "TRUE" for "stale" token is case-insensitive.

For the rest it is not clear what type of matching must be used.
As "realm" value is explicitly specified to be case-sensitive, one may 
assume that other values should be case-insensitive. However we have 
stale value that is explicitly case-insensitive.
Looks like all tokens names must be case-sensitive, with the only 
exception "realm" token.

However, according to 
https://datatracker.ietf.org/doc/html/rfc2616#section-2.1
any quoted "literal" is case-insensitive by default, so seems that all 
token names and all predefined token values (like "MD5", "MD5-sess") 
must be case-insensitive.

If you take newer RFCs into consideration, then 
https://datatracker.ietf.org/doc/html/rfc7235#section-2.1 clarifies 
token matching ("the name token is matched case-insensitively").

RFC 7616 only complicate things, because it requires only:
* "stale" value to be case-insensitive (like RFC2617),
* "charset" name and value to be case-insensitive.
Nothing is specified for other parameters.
This is quite strange because similar RFC for Basic Authentication
does require parameter names to be matched case-insensitive.
https://datatracker.ietf.org/doc/html/rfc7617#section-2
However, as RFC 7616 is based on RFC 7235, case-insensitive match should 
be assumed for tokens' names.

Nothing in Errata adds any clarity.

My conclusions:
MOST LIKELY parameter names (tokens) must be matched in case-insensitive 
way.
MOST LIKELY parameter values must be matched in case-sensitive way, 
except for "stale" and "charset".
However this approach may break compatibility with some clients.

I think a good balance between higher security and better compatibility 
would be caseless matching for all parameters names and values, except 
"realm", "nonce", and "opaque" values. Maybe "qop" value should be in 
exception as well as it is used in hash calculations.

Let me know if you have other opinion, interpretation, or more 
information about this topic.

--
Evgeny


On 17.01.2022 18:25, Christian Grothoff wrote:
> Dear Ahmet,
>
> Thanks for the report,
>
> I've fixed this in Git master now.
>
> -Christian
>
> On 17.01.22 09:50, Ahmet Kermen wrote:
> > Hi All,
> >
> > Since version 0.9.62 libmicrohttpd appears to be started adding optional
> > "algorithm" field for digest authentication header. According to
> > RFC2617 https://datatracker.ietf.org/doc/html/rfc2617
> > <https://datatracker.ietf.org/doc/html/rfc2617> and
> > RFC7616 https://datatracker.ietf.org/doc/html/rfc7616
> > <https://datatracker.ietf.org/doc/html/rfc7616> the algorithm value is
> > case-sensitive (no explicit definition, as for “stale” field) and should
> > be "MD5" (uppercase) if MD5 is selected, but libmicrohttpd sets as "md5"
> > (lowercase). The case difference makes some client libraries to fail
> > detecting digest authentication presence from server responses.
> >
> >  From RFC2617:
> > algorithm
> >       A string indicating a pair of algorithms used to produce the digest
> >       and a checksum. If this is not present it is assumed to be "MD5”.
> >
> >  From RFC7616:
> > algorithm
> >        A string indicating an algorithm used to produce the digest and an
> >        unkeyed digest.  If this is not present, it is assumed to be
> >        “MD5"
> >
> >
> > Best regards,
> > Ahmet Kermen

OpenPGP_signature
Description: OpenPGP digital signature