OpenPrinting
use http->qop insted of http->algorithm to decide RFC 2617/7616 or RFC 2069 Digest response
Will consider this change, although the related issue seems to be a pretty clear-cut example of a broken printer... :/
@michaelrsweet I've checked all RFCs mentioned which are in play here and I'm not sure whether there is a reliable way how to figure out which RFC the destination implements - "qop" is optional in RFC 2617 and 7616, and "algorithm" is optional across all three RFCs (if not defined, MD5 is used).
So do we check for "algorithm" and hope the destination really implements newer RFCs?
With this it makes me curious about how other HTTP libraries solve this... do we use a specific http implementations so we can't use an external HTTP library or there wasn't time to migrate CUPS to one?
@zdohnal From RFC 2617 (similar wording in 7616):
qop-options
This directive is optional, but is made so only for backward compatibility with RFC 2069; it SHOULD be used by all implementations compliant with this version of the Digest scheme. If present, it is a quoted string of one or more tokens indicating the "quality of protection" values supported by the server. The value "auth" indicates authentication; the value "auth-int" indicates authentication with integrity protection; see the descriptions below for calculating the response directive value for the application of this choice. Unrecognized options MUST be ignored.
...
cnonce
This MUST be specified if a qop directive is sent (see above), and MUST NOT be specified if the server did not send a qop directive in the WWW-Authenticate header field. The cnonce-value is an opaque quoted string value provided by the client and used by both client and server to avoid chosen plaintext attacks, to provide mutual authentication, and to provide some message integrity protection. See the descriptions below of the calculation of the response-digest and request-digest values.
So reading this then we can determine whether to use the old or new hash construction (new uses cnonce, old doesn't) based on the usage of the "qop" parameter.
@michaelrsweet yes, we can tell between RFC 2069 and RFC 2617/7616, IF the qop+cnonce are sent. But "qop" is SHOULD, so even communication based on newer RFCs can be without those keywords, so we would take the newer RFC comm as old RFC 2069 comm.
So we would take such comm as old one and hope the destination supports it?
@zdohnal "qop" is REQUIRED to use "cnonce" (for additional integrity protection) - thus a client knows to send "cnonce" if the server sends "qop" and a server knows to use integrity protection if the client supplies "cnonce" (the server can also reject/fail the authentication if it requires "cnonce"...)
Ok, I've read the RFCs once more - first, I completely missed that qop is required in RFC 7616, so it leaves us with RFC 2617 and RFC 7616 if qop appears. The other thing I missed/misunderstood the note about backward compatibility and qop in RFC 2617 - so now I get it the way that if a device which follows RFC 2617, doesn't send 'qop' in WWW-authenticate response header, it tells us that it wants to communicate by RFC 2069.
Thank you for the explanation, @michaelrsweet !