At the IPP WG meeting, we agreed to resolution 2 for Issue 3.2. However, on
the IPP telecon today, Ira pointed out that HTTP security is
connection-based, not transaction-based. There is a new experimental RFC
2660 for SHTTP (August 1999), which has transaction-based security, but we
don't want IPP to have to use that.
So resolution 2 won't work; the challenge has to be issued for the
connection, not on an operation-by-operation basis. Therefore, each
different security regime that a Printer supports MUST have a distinct URL.
What about authentication?
As to whether sending a zero length HTTP Post (also ISSUE 3.2) and being
guaranteed that the server will always issue the challenge (if the URL is
one that supports security that challenges), needs further work.
NEW ISSUE: The "Job and Printer Set Operation" specification has two
different security regimes with the same URL. See the extracted text
following this issue text. What to do about that?
Issue 3.2: OPEN
Some IPP Clients issues a zero length HTTP Post. The Client
assumed that this would force a challenge if security is enabled on the
Printer. The Client would have a problem if a subsequent print operation
were challenged.
Proposed Resolutions:
There are two competing resolutions.
Resolution 1 is that a challenge should be issued whenever
an HTTP operation is received on a particular URL. (assuming the URL is part
of an authentication space) The client must accept and respond to a
challenge the first time a URL is accessed.
Resolution 2 allows the vendor to determine when a challenge
is issued. The vendor is free to use the contents of the HTTP request to
determine if the operation mandates a challenge. The client must accept and
respond to a challenge at any time.
The Client should use the IPP operation "validate-job" to
check if a job will be accepted. This operation will cause the Printer to
issue a challenge and check the print request before sending the data. The
IPP Client should also be able to handle a challenge when issuing an IPP
operation since there is no guarantee the connection has not been torn down.
Furthermore, a Printer should accept an empty HTTP post and
issue a challenge based on the URL of the post.
Resolution 1:
From Bob Herriot:
I raised the issue about whether a Printer should perform
the authentication
challenge based solely on the URL or whether it could react
differently to
an empty request than to a Validate-Job request.
I asked an HTTP expert and received the following
information.
1) An HTTP server can have any policy.
This means that resolution 2 is allowable.
2) It is best for a client if it can associate the URL tree
with the authentication space.
This means that our decision could be
better. That is, we should require an IPP Printer to decide whether to issue
an authentication challenge by examining the URL and nothing else, e.g. a
Printer receiving a request for a particular URL, gives the same challenge
to an empty request as to a Validate-Job request.
This solution allows a client to use
Validate-Job to request a challenge as we decided to allow. It also allows a
client to use the empty request.
The important difference between our
decision and what I am proposing is that the Printer must perform an
authentication challenge consistently for a URL regardless of the contents
of the message body. This rule make IPP behavior consistent with good HTTP
policy.
Resolution 2:
From Peter Zehler:
Allowing IPP Printers to use the contents of an IPP request
to determine if a challenge should be issued allows for increased usability.
The client does not have to keep track of multiple instances of the same
printer and select the appropriate one based on the operation to be
performed. The printer is free to determine when authentication is
required. This allows the client to use a single URL and authenticate
himself when the printer places restrictions on operations or features.
This resolution does not prohibit challenges based
statically on a URL. Resolution 2 does require a client to be ready at any
time to receive a challenge. This should be done anyway since the client
application may be unaware that an HTTP connection has dropped after
authenticating the connection, resulting in a new challenge. Some HTTP
servers have security realms that apply only to a transaction as well as
being connection based.
>From the Job and Print Set spec:
"printer-xri-supported =
{ "xri-uri" = ipp://abc.com/p1
"xri-authentication" = basic, digest
"xri-security" = tls
},
{ "xri-uri" = http://abc.com/pq
"xri-authentication" = none
"xri-security" = none
}
would cause the Printer to set the three corresponding IPP/1.1 READ-ONLY
attributes, each with three parallel values as follows:
"printer-uri-supported" = { ipp://abc.com/p1,ipp://abc.com/p1,http://abc.com/pq }
"uri-authentication-supported" = { basic, digest, none }
"uri-security-supported" = { tls, tls, none }
Because there were two authentication values for the ipp://abc.com/p1 URL,
that URL value is repeated. Had the ipp URL had 2 authentication values and
3 security values, then there would have been 7 (2*3 + 1) parallel values
for each of the three attributes, 6 with the same ipp URI and 1 with the
http URI.