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

  • Next message: Carl Kugler: "RE: IPP> Minutes of IPP Working Group Meeting [about Validate-Job security challenges]"

    Hi Carl,

    As you say (and RFC 2617 says) a (server-generated) 'nonce' acquired
    during one operation to a given 'Request-URI' MAY be single use or
    time-limited, so that it is NOT valid for a subsequent use. That's
    why I think that using your 'Expect: 100-continue' idea is so
    valuable.

    I could rewrite (1) and (2) below, but they still don't get us
    there. Unless the HTTP server (i.e., the IPP Printer) supports
    the 'Expect: 100-continue' behavior (I think we agree this can't
    be guaranteed), the problem of a client-generated 'Print-Job'
    failing due to authentication/authorization exchanges is not
    soluble.

    Since HTTP/1.1 Digest is weak security at best (per RFC 2617),
    shouldn't we be focusing on the use of TLS - with an appropriate
    key length and cipher algorithm to give reasonable security
    in the commercial environment?

    Cheers,
    - Ira McDonald

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

    Ira-

    I'm still not following you.

    Ira wrote:
    >
    >Hi Carl,
    >
    >Right, "WWW-Authenticate" as you say is a (server-generated)
    >response element.
    >
    So, I think we've established that 1) and 2) below are wrong as written.
    Could you please rewrite them to make sense?

    >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.
    >
    But the nonce is opaque to the client, and the server is free to construct
    the nonce such that it may only be used from a particular client, for a
    particular resource, for a limited period of time or number of uses, or any
    other restrictions. So a nonce acquired for a Get-Printer-Attributes MAY
    be useless for a Print-Job.

    >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.
    >
    I can't find this in the spec. In particular, depending on sever (Printer)
    policy, a client MAY be able to supress a challenge by preemptively
    including an "Authorization" header reusing credentials cached from an
    earlier request (whether or not that request was on the same connection).

         -Carl

    >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 : Mon Mar 19 2001 - 18:42:16 EST