IPP Mail Archive: RE: IPP> Minutes of IPP Working Group Meet

IPP Mail Archive: RE: IPP> Minutes of IPP Working Group Meet

RE: IPP> Minutes of IPP Working Group Meeting [about Validate-Job security challenges]

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Wed Mar 14 2001 - 15:47:11 EST

  • Next message: McDonald, Ira: "IPP> SEC - TLS without PKI (Secure Remote Password)"


    Good discussion. Several comments:

    1. Authorization vs. authentication

    We need to keep authorization and authentication clearly separate. You used
    the former term below, when I think you meant the latter, correct?

    As I understand it, authentication is the Printer determining that you are
    who you say you are and authorization is the Printer determining whether or
    not to allow you to do what you want to do to the specified object according
    to the Printer's configured policy for you, that operation, and that object.

    For example, the Printer authenticates you as being the real Carl Kugler,
    while authorization checks whether the Cancel-Job operation that the real
    Carl Kugler issued for job 100 can be done to job 100, i.e., (a) does the
    real Carl Kugler have operator privileges on this Printer or (b) did the
    real Carl Kugler submit job 100.

    If you cannot be authenticated, i.e., the Printer has never heard of the
    real Carl Kugler, or you gave a wrong password, the Printer rejects the
    request with not-authenticated. [Probably at the HTTP layer, with an HTTP
    'client-error-not-authenticated' status code, not the IPP layer with the IPP
    'client-error-not-authenticated", correct?]

    If you were authenticated as the real Carl Kugler, if either answers to
    questions (a) or (b) are yes, the Printer (at the IPP layer) accepts the
    request, otherwise, the Printer rejects the request with the IPP
    'client-error-not-authorized' status code.

    2. Does Validate-Job force the Printer to perform the same authentication
    and authorization as Print-Job?

    That was certainly the IPP WG intent. We made it a REQUIRED operation.
    [With hind-sight, we should have made Create-Job REQUIRED (whether or not
    the Printer supported multi-document jobs). Then we wouldn't have needed
    Validate-Job.] And we wrote the semantics for Validate-Job as:

    3.2.3 Validate-Job Operation

    This REQUIRED operation is similar to the Print-Job operation (section
    3.2.1) except that a client supplies no document data and the Printer
    allocates no resources (i.e., it does not create a new Job object). This
    operation is used only to verify capabilities of a printer object against
    whatever attributes are supplied by the client in the Validate-Job request.
    By using the Validate-Job operation a client can validate that an identical
    Print-Job operation (with the document data) would be accepted. The
    Validate-Job operation also performs the same security negotiation as the
    Print-Job operation (see section 8), so that a client can check that the
    client and Printer object security requirements can be met before performing
    a Print-Job operation.

    About the only thing we didn't say was: The Printer MUST perform the same
    authentication and authorization as for a Print-Job operation.

    3. Question about Digest nonce: If the implementation only allows the nonce
    value to good for one request only, how does the client get another one? Is
    this the case where the Printer would issue a challenge on every request in
    order to generate a new nonce? If so, this is the case that REQUIRES the
    client to be prepared to accept a challenge any time, correct?


    -----Original Message-----
    From: Carl Kugler [mailto:kugler@us.ibm.com]
    Sent: Wednesday, March 14, 2001 09:32
    To: ipp@pwg.org
    Subject: IPP> Minutes of IPP Working Group Meeting

    > Bill Wagner noted that this issue revolves around the interpretation of
    allowable HTTP behavior?and
    > perhaps should be out of scope for the IPP WG. Since the group has
    already resolved that sending a
    > zero-length POST is invalid, he believes that the interoperability issue
    should be closed.

    I don't believe that we ever reached a consensus on whether authorization
    is always on the basis of URI. If we allow authorization on the basis of
    IPP operations, then you can't limit this issue to the HTTP layer.
    Remember that a request can be rejected at either the HTTP OR IPP layers.
    For example a request might be rejected with HTTP 401 (Unauthorized) OR IPP
    client-error-not-authenticated (0x0402).

    > It was noted that a Validate Job command will successfully generate a
    challenge?regardless of how the HTTP security might be implemented.

    I doubt that this statement is always true, unless some other conditions
    are in place. For printers that authorize on the basis of the request URI,
    this is true if the request URI refers to a protected resource. For
    printers that authorize on the basis of the IPP operation (or operation AND
    URI), this won't work unless the spec guarantees that Validate-Job MUST be
    authorized identically to Print-Job. Without such a requirement in the
    spec, it's not obvious to me that Validate-Job would be authorzed
    identically to Print-Job, since Validate-Job, unlike Print-Job, consumes
    virtually no resources. Also, for Digest, since the "nonce" value in the
    challenge may be good for only one request, the spec would have to
    guarantee that the response to a Validate-Job challenge will authorize a
    Print-Job request.


    This archive was generated by hypermail 2b29 : Wed Mar 14 2001 - 15:48:29 EST