IPP> MOD - Issue 2: How can client force authentication, i.e ., identified mode? Solution #2 preferred

IPP> MOD - Issue 2: How can client force authentication, i.e ., identified mode? Solution #2 preferred

IPP> MOD - Issue 2: How can client force authentication, i.e ., identified mode? Solution #2 preferred

Herriot, Robert Robert.Herriot at pahv.xerox.com
Thu Mar 25 20:34:46 EST 1999


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



More information about the Ipp mailing list