use (new) http->qop insted of http->algorithm to decide RFC 2617/7616 or RFC 2069 Digest response

[mgoppold]

starting point:

print to passwort protected queue does not work

• Printer: HP Color LaserJet Pro MFP M479fdw
• CUPS: 2.3.3op2
• Queue: lpadmin -p ipptestuser -E -v ipp://user:[email protected]/ipp/print -m HPP00013.PPD

Since that Printer+Queue worked before, I verified it with cups-1.5.4. and saved Job-Logs and tcpdump.

actual situation

The Printer Response: HTTP/1.1 401 Unauthorized contains

WWW-Authenticate: Digest realm="IPP-Print", nonce="23745ef9fd75fcb9c584f6bb637cd811", algorithm=MD5, qop="auth", opaque="6e07a11341adfad0dbb22d413520ece5", username="guest"

and CUPS send Request (Get-Jobs)

Authorization: Digest username="user", realm="IPP-Print", nonce="23745ef9fd75fcb9c584f6bb637cd811", algorithm=MD5, qop=auth, opaque="6e07a11341adfad0dbb22d413520ece5", cnonce="09E111C7E1E7ACB6F8CAC0BB2FC4C8BC2AE3BAAAB9165CC458E199CB89F51B13", nc=00000002, uri="/ipp/print", response="a2498fedd95d587a0f3917cd71a33a23"

which is correct but the job hangs and is not processed.

The printer expects a response after RFC 2069.

While reading the RFCs 2069/2617/7616 I noticed that it is better to look at qop instead of algorithm to decide whether the answer should be written according to RFC 2069 or RFC 2617/7616.

qop is not mentioned in RFC 2069 and in RFC 2617

qop
Indicates what "quality of protection" the client has applied to
the message. If present, its value MUST be one of the alternatives
the server indicated it supports in the WWW-Authenticate header.
These values affect the computation of the request-digest. Note
that this is a single token, not a quoted list of alternatives as
in WWW- Authenticate. This directive is optional in order to
preserve backward compatibility with a minimal implementation of
RFC 2069 [6], but SHOULD be used if the server indicated that qop
is supported by providing a qop directive in the WWW-Authenticate
header field.

./cups/http-support.c _httpSetDigestAuthString

If any HashAlg
   Follow RFC 2617/7616...
else
   Use old RFC 2069 Digest method...
   assume MD5 HashAlg

proposal

Evaluation of qop and

If any qop
   Follow RFC 2617/7616...
   if qop is "auth"
      test algorithms
      ...
   else
      skip while auth-int not supportetd yet
else
   Use old RFC 2069 Digest method...

I realize that with these changes the print will still not work because the printer does not react as expected to the correct answer, but I also reported it to HP.

My changes are in pull request #260

[mgoppold]

Is it possible that if we tried N times to request after RFC 2617/7616 and it didn't work, to fallback to RFC 2069?

[michaelrsweet]

@mgoppold I would hesitate to retry the legacy format (which is less secure) when the printer is returning the new format. Better to get them to fix their implementation...

[mgoppold]

@mgoppold I would hesitate to retry the legacy format (which is less secure) when the printer is returning the new format. Better to get them to fix their implementation...

And what about a queue parameter if i know the printer expect the legacy format?

[michaelrsweet]

@mgoppold I hesitate to add any functionality to work around a problem like this because it gives the vendor an excuse for not fixing things and it breaks the "it just works" philosophy of IPP Everywhere/AirPrint.

[mgoppold]

@michaelrsweet I ' with you, but it doesn't cost anything to ask for it

[zdohnal]

I will need to examine the RFC deeply to decide whether we should add the checking of qop into CUPS. Currently I'm on Mike's side, since the printer uses algorithm, then it should follow the correct RFC.