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 at us.ibm.com]
Sent: Wednesday, March 14, 2001 4:07 PM
To: Hastings, Tom N
Cc: ipp at 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 at cp10.es.xerox.com> on 03/14/2001 01:47:11 PM
To: Carl Kugler/Boulder/IBM at IBMUS
cc: ipp at 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 at us.ibm.com]
Sent: Wednesday, March 14, 2001 09:32
To: ipp at 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