IPP Mail Archive: IPP> URL vs Transaction based security

IPP Mail Archive: IPP> URL vs Transaction based security

IPP> URL vs Transaction based security

From: Harry Lewis (harryl@us.ibm.com)
Date: Mon Jan 29 2001 - 00:36:28 EST

  • Next message: pmoore@netreon.com: "IPP> New data types"

    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
    ----------------------------------------------



    This archive was generated by hypermail 2b29 : Mon Jan 29 2001 - 00:37:49 EST