[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [libmicrohttpd] Digest Authentication algorithm field case sensitivi
Re: [libmicrohttpd] Digest Authentication algorithm field case sensitivity
Mon, 17 Jan 2022 20:46:41 +0300
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0
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
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
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.
However, as RFC 7616 is based on RFC 7235, case-insensitive match should
be assumed for tokens' names.
Nothing in Errata adds any clarity.
MOST LIKELY parameter names (tokens) must be matched in case-insensitive
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.
On 17.01.2022 18:25, Christian Grothoff wrote:
Thanks for the report,
I've fixed this in Git master now.
On 17.01.22 09:50, Ahmet Kermen wrote:
Since version 0.9.62 libmicrohttpd appears to be started adding optional
"algorithm" field for digest authentication header. According to
<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.
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”.
A string indicating an algorithm used to produce the digest and an
unkeyed digest. If this is not present, it is assumed to be
Description: OpenPGP digital signature