At the January f2f, we had a protracted discussion about authentication at
the HTTP level using "Expect 100 Continue" vs. "content" or "transaction"
based security based, essential, on the IPP ValidateJob operation. At the
meeting, what I would describe as a "weak" consensus formed around using
IPP Validate Job. It was thought that this would facilitate the desired
ability to authenticate on specific operations or attributes rather than
on the URL where any operation might subsequently be attempted. In review
of this position, Carl Kugler has outlined the attached comments which
represent an objection to this resolution. I agree with Carl's
observations and would like to continue to investigate this topic via
e-mail with a wider audience than was available at the f2f.
Carl....
The Validate-Job proposal isn't very satisfactory. According to the
Digest Auth standard, the "nonce" value in the server's challenge may be
good for one use only (for those really paranoid about replay attacks).
So, you do Validate, get a challenge, then you have to be optimistic and
go ahead and send your Print-Job*. If there is any problem, like
incorrect password, you wasted your one shot at Print-Job (for those
clients that can't back up and regenerate the doc). With 100-Continue,
you send your HTTP headers, get your challenge, and then ONLY if you get 100-Continue, you send your Print-Job. Otherwise, you can try
again with another password until you get 100-Continue. 100-Continue
gives you a reasonable expectation that the final HTTP response for your
request will be 200 OK (even though the response body could conceivably
contain an IPP response with client-error-forbidden,
client-error-not-authenticated, or client-error-not-authorized).
A request can always be rejected at EITHER the HTTP level OR the IPP level. E.g., you could get an HTTP (401 Unauthorized) or you
could get HTTP 200 (OK) with an IPP client-error-not-authenticated
(0x0402). If a request is going to be rejected on the basis of the HTTP
headers alone (i.e., you are not going to get a 200 OK from the HTTP layer
no matter what's in your IPP request), you might as well find that out
before you transmit your big document. And, 100-Continue support is a
MUST in the HTTP standard. For those Printers that DO authenticate by
URL, you might as well take advantage of 100-Continue, even if that
doesn't solve the problem for all Printers.
BTW, if a client receives the HTTP 200 (OK)/IPP
client-error-not-authenticated (0x0402) combination, I would interpret
that as meaning that the client should look at the printers
"uri-authentication-supported" and "uri-supported" attributes and look for
a more authenticated URI. However, if this is a one-shot client, it might
have already blown its Print-Job. So I guess I would argue that we really
need both 100-Continue and Validate-Job, with clarification that
Validate-Job requires the same authentication as Print-Job. That way the
one-shot clients can be expected to work with the single-URL printers.
----------------------------------------------
Harry Lewis
IBM Printing Systems
----------------------------------------------