A request could use a combination of the
authentication and security mechanisms.
IPP Attribute HTTP Authentication Socket Channel Security
(comment-like (authentication) (authentication, privacy
username setting) and data integrity)
====================== ==================== =======================
[requesting-user-name] [Basic, Digest] [SSL3, TLS]
For example, a request could use one of the following combination:
requesting-user-name and TLS, or
requesting-user-name and Digest, or
Basic, and SSL3, or
TLS,
etc
If an attribute is used for this information, it should be multi-valued.
--Xavier
> -----Original Message-----
> From: Herriot, Robert [mailto:Robert.Herriot at pahv.xerox.com]
> Sent: Thursday, March 25, 1999 5:35 PM
> To: ipp at 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
>