What you would actually need would be a product of all the combinations of
identification and auth/secure channel methods.
URL1 = none, none
URL2 = basic, none
URL3 = basic, TLS
URL4 = basic, SSL3
URL5 = digest, none
...
URL9 = digest, SSL3
URL27 = foobar, XYZ
-----Original Message-----
From: Herriot, Robert [mailto:Robert.Herriot@pahv.xerox.com]
Sent: Thursday, March 25, 1999 5:35 PM
To: ipp@pwg.org
Subject: RE: IPP> MOD - Issue 2: How can client force authentication,
i.e ., identified mode? Solution #2 preferred
I prefer solution #2 because it avoids adding a new and rather strange
operation. Instead it adds some new attributes and fits in with the existing
infrastructure. Solution #2 is:
2. Use two URLs for the same IPP Printer object, one requires authentication
and the IPP server always issues a challenge; the other never does. So the
client that wants to be authenticated submits requests to the URL that
requires authentication. ISSUE: How does the client discover which URL to
use, since "uri-security-supported" is about security, not authentication?
This solution allows an administrator to control what combinations of basic,
digest and no authentication are supported.
To resolve the ISSUE in the above solution, I suggest that we add a printer
attribute "authentication-supported", which we would also add to the printer
template for SLP. This attribute would specify how a printer authenticates a
client -- a service that is incomplete in IPP. The values of this attribute
would be parallel to "printer-uri-supported" and "uri-security-supported",
and would include:
"none": The printer issues no HTTP challenge, and treats all users as
"anonymous". It ignores the "requesting-user-name" operation attribute.
"basic": The printer expects basic authentication or issues a basic
challenge. It ignores the "requesting-user-name" operation attribute.
"digest": The printer issues a digest challenge. It ignores the
"requesting-user-name" operation attribute.
"requesting-user-name": the printer issues no HTTP challenge, and uses
the operation attribute "requesting-user-name" to authenticate a user. If
the "requsting-user-name" is absent, the user is "anonymous"; alternatively,
the job is rejected.
"certificate-xxx": according to my understanding, we would need a
different "xxx" for each certificate authority in order to give useful
information.
We would also need to add a new job attribute "authentication-used" which
identifies the authentication mechanism used for the job.
With these new attributes, a Printer implementation could be augmented to
receive jobs via one or more URIs with different authentication mechanisms.
The Get-Jobs operation, except for security restrictions, would likly show
all jobs submitted to the printer, regardless of the URI. A Cancel-Job
operation would be more limited. A Printer would need to implement a new
mechanism that defines equivalence of users authenticated via different
mechanisms. This would determine whether a Cancel-Job requester is the job
owner.
It would simplest to say that a Cancel-Job requestor is identical to a job
owner if the user names and authentication mechanisms are the same. A less
restrictive mechanism would define a hierarchy of authentication mechanisms:
"none", "requesting-user-name", "basic", and "digest", where "digest" is the
most secure. An operation, such as Cancel-Job could be performed on a job if
the users are the same and if the authentication mechanism for the operation
equals or exceeds the authentication mechanism for the job submission.
Bob Herriot