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: Carl Kugler (kugler@us.ibm.com)
Date: Wed Mar 14 2001 - 19:07:17 EST

  • Next message: sandeep@teil.soft.net: "(no subject)"

    Tom-

    Re: 1. Authorization vs. authentication
    The trouble is, authorization and authentication are not necessarily
    mutually independent. When authorization is not required, neither is
    authentication. For example, a Printer may not challenge a
    Get-Printer-Attributes request, if anyone is authorized to
    Get-Printer-Attributes. But a one-shot client needs to know in advance
    whether or not it will be challenged for a Print-Job request. One solution
    is to require authentication for every request with a given URI prefix,
    whether or not authorization is required. This is what I was calling
    URI-based authorization: the philosophy is that you are authorized to
    access a particular resource, regardless of what operation you want to do
    to that resource. Maybe I should have said that you are authenticated
    based on the resource you are trying to access, regardless of what
    operation you want to do to that resource. One problem with that approach
    is that you must be authenticated regardless of whether or not
    authorization is required for the operation you want to perform, which
    could be inefficient or inconvenient.

    Re: 2. Does Validate-Job force the Printer to perform the same
    authentication
    and authorization as Print-Job?
    Those words in the spec come close, but there is more to this problem than
    checking that the Printer security requirement can be met. A one-shot
    client needs to be able to form a valid WWW-Authenticate request header
    BEFORE it sends the Print-Job request body. So, for Digest, it needs a
    nonce value that it can use in order to form a valid WWW-Authenticate
    header. Here, again, authorization and authentication may not be separate,
    because (in general) a Printer may generate different nonces for different
    operations.

    Re: 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?
    Well, if certain conditions are met, it could issue another Validate-Job to
    get a fresh nonce and then send a Print-Job request using that nonce. This
    bait-and-switch approach is a little exceptional from a security point of
    view, but as long as it's explicitly documented I guess it'll work.

    It's easy to say the client must be prepared to accept a challenge at any
    time, but this is a problem for those clients that are unable to retry
    Print-Job requests (typically because they generate document data
    on-the-fly and are unable to back up the content generator for a retry).
    Not to mention that it's inefficient to retry complete Print-Job requests.
    This is the motivation for the "Expect: 100-continue" solution.

         -Carl

    "Hastings, Tom N" <hastings@cp10.es.xerox.com> on 03/14/2001 01:47:11 PM

    To: Carl Kugler/Boulder/IBM@IBMUS
    cc: ipp@pwg.org
    Subject: RE: IPP> Minutes of IPP Working Group Meeting [about Validate-Job
           security challenges]

    Carl,

    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?

    Tom

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

         -Carl



    This archive was generated by hypermail 2b29 : Wed Mar 14 2001 - 20:30:34 EST