Ira-
I agree that TLS is the way to go if you've got sensitive information to
protect. Digest authentication is useless for that, since it authenticates
the wrong party (i.e., for IPP it autheniticates the sender, not the
receiver!). However, there might be other use cases for Digest. For
example, authorizing administrative access (IPP extensions), or preventing
unauthorized consumption of resources (paper, toner, clicks, time, etc.).
(Although, to digress, Kerberos might be a better solution than Digest in
these situations. Apparently Microsoft has already shipped Kerberized IPP,
so the precendent has been set.) In summary, I think different
applications demand different aspects of security: privacy, authentication
(client, server, or mutual), authorization, message integrity,
non-repudiation, etc. Digest gives you client authentication, which might
be enough for some applications.
Anyway, support for "Expect: 100-continue" and the 100 (Continue) Status
is a requirement for HTTP/1.1 servers. It's not optional in the HTTP spec.
-Carl
"McDonald, Ira" <imcdonald@sharplabs.com> on 03/19/2001 04:34:59 PM
To: Carl Kugler/Boulder/IBM@IBMUS, "McDonald, Ira"
<imcdonald@sharplabs.com>
cc: "Hastings, Tom N" <hastings@cp10.es.xerox.com>, ipp@pwg.org
Subject: 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 : Tue Mar 20 2001 - 15:01:05 EST