The 'correct' solution is for HTTp to support this itself (but it doesnt)
-----Original Message-----
From: Herriot, Robert [mailto:Robert.Herriot@pahv.xerox.com]
Sent: Monday, March 29, 1999 6:04 PM
To: Paul Moore; Herriot, Robert; ipp@pwg.org
Subject: RE: IPP> MOD - Issue 2: How can client force authentication,
i.e ., identified mode? Solution #2 preferred
Does this solution seem like a better and simpler solution than the new
"force authentication" IPP operator that you originally proposed?
Bob Herriot
> -----Original Message-----
> From: Paul Moore [mailto:paulmo@microsoft.com]
> Sent: Monday, March 29, 1999 11:12 AM
> To: 'Herriot, Robert'; ipp@pwg.org
> Subject: RE: IPP> MOD - Issue 2: How can client force authentication,
> i.e ., identified mode? Solution #2 preferred
>
>
> How does trhis work in combination with various secure
> transmission RLS
> (ssl3, TLS, etc).
>
> 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
>