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 : Wed Mar 14 2001 - 15:48:29 EST