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-2However, 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
