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: McDonald, Ira (imcdonald@sharplabs.com)
Date: Sun Mar 18 2001 - 17:06:19 EST

  • Next message: McDonald, Ira: "RE: IPP> Minutes of IPP Working Group Meeting [about Validate-Jo bsecurity challenges]"

    Hi Carl,

    Right, "WWW-Authenticate" as you say is a (server-generated)
    response element.

    The point about (1) below (client acquiring an initial 'nonce'
    value by a Get-Printer-Attributes initial operation) is that
    HTTP/1.1 Digest (according to RFC 2617) ONLY providesprotection
    realms at the level of the Request-URI (the IPP Printer in our
    case) and NOT at the level of individual operations within that
    URI.

    So if an IPP Printer is going to ever require authentication
    on ANY operation via a particular IPP/HTTP URL, then it MUST
    require authentication for EVERY operation (not just selectively),
    although the IPP Printer can choose to only require authentication
    on the FIRST operation. But it's not conformant to RFC 2617 to
    allow the first operation without any authentication (Digest
    challenge in our case) and then issue a challenge on some
    subsequent operation in the same HTTP connection/session.

    Cheers,
    - Ira McDonald, consulting architect at Sharp and Xerox
      High North Inc

    -----Original Message-----
    From: Carl Kugler [mailto:kugler@us.ibm.com]
    Sent: Friday, March 16, 2001 2:31 PM
    To: McDonald, Ira
    Cc: Hastings, Tom N; ipp@pwg.org
    Subject: RE: IPP> Minutes of IPP Working Group Meeting [about
    Validate-Job security challenges]

    Umm, I think I mistakenly substituted "WWW-Authenticate" for
    "Authorization" in my last message. WWW-Authenticate is a response header,
    while Authorization is a request header, right? I'm not sure I understand
    what the client is sending in 1) below.

         -Carl

    "McDonald, Ira" <imcdonald@sharplabs.com> on 03/16/2001 02:57:03 PM

    To: Carl Kugler/Boulder/IBM@IBMUS, "Hastings, Tom N"
          <hastings@cp10.es.xerox.com>
    cc: ipp@pwg.org
    Subject: RE: IPP> Minutes of IPP Working Group Meeting [about Validate-Job
               security challenges]

    Hi Carl,

    I think there's some merit in your "Expect: 100-continue" proposal.

    I spent several hours yesterday reading RFC 2617 (HTTP Basic and
    Digest Authentication) in its entirety. Taking legal behavior
    from RFC 2617, let me suggest the following:

    1) An IPP Client always acquires a (server-side) 'nonce' at
        the beginning of a new session/connection by sending a
        "WWW-Authenticate" header with a Get-Printer-Attributes
        request (for example).

    2) When the IPP Client wants to print a job (or cancel a job
        or whatever), it uses your "Expect: 100-continue" but it
        ALSO forces a new challenge (if the server requires one)
        by unilaterally sending a "WWW-Authenticate" header using
        the previously acquired (server-side) 'nonce' (which is
        always legal, per RFC 2617).

    3a) If the (server-side) 'nonce' has _not_ expired (time-based
        or single use), the IPP Printer simply accepts the new
        Print-Job, Cancel-Job, etc., HTTP request and sends the
        continue back to the IPP Client and the IPP Client proceeds.

    3b) If the (server-side) 'nonce' _has_ expired, then the IPP
        Printer issues a new challenge with a new 'nonce' value
        in the continue response, and again the IPP Client proceeds.

    There are many weak points in HTTP Digest (as RFC 2617 clearly states),
    but MOST of the worst weak points are fixed by the IPP Client using
    the optional (client-side) 'cnonce' additional nonce in the authenticate
    exchange (e.g., man-in-the-middle attacks are defeated entirely).

    I think we want to strongly recommend that IPP Clients use (and
    IPP Printers expect to see used) the 'cnonce' option for better
    authentication, in the IIG.

    Comments?

    Cheers,
    - Ira McDonald, consulting architect at Sharp and Xerox
      High North Inc

    -----Original Message-----
    From: Carl Kugler [mailto:kugler@us.ibm.com]
    Sent: Wednesday, March 14, 2001 4:07 PM
    To: Hastings, Tom N
    Cc: ipp@pwg.org
    Subject: RE: IPP> Minutes of IPP Working Group Meeting [about
    Validate-Job security challenges]

    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 : Sun Mar 18 2001 - 17:13:18 EST