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 - 11:47:09 EST