IPP Mail Archive: Re: IPP> MOD - Issue 2: How can client force authentication, i.e., identified mode?

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

Ron Bergman (rbergma@dpc.com)
Thu, 25 Mar 1999 08:30:10 -0800 (Pacific Standard Time)

Why would a client ever want to require itself to be authenticated to an
IPP printer? What protection does this provide to the client?
Authentication only protects the server. Am I missing something?

Encryption does make sense for a client to specify.

Ron Bergman
Dataproducts Corp.

On Wed, 24 Mar 1999, Hugo Parra wrote:

> Question on alternative 1: Does the challenge issued by the IPP object specify what type of credential the user should send? If so, if the IPP object supports more than one authentication/security method, which one should it request?
>
> -Hugo
>
> >>> "Hastings, Tom N" <hastings@cp10.es.xerox.com> 03/23/99 06:24PM >>>
> Here is the third issue from the Bake Off that has several possible
> alternatives. This issue has also had a lot of email discussion since the
> Bake Off. We list some additional alternatives to adding a new operation.
> What do people think of the alternatives?
>
> Tom
>
> 2) ISSUE: How can client force identified mode?
>
> If an IPP Printer supports both authenticated and unauthenticated
> access, there is no way for a client to force itself to be
> authenticated, i.e., be in identified mode, since it is the server that
> forces authentication by issuing a challenge to the client. It is
> very useful for a client to be able to get into identified mode as soon
> as possible. Today you have to wait to be challenged by the server,
> which may never happen -- or happens at an unpredictable time. The
> security conformance requires that the authentication for operations be
> the same for all operations. So for authenticated Cancel-Job, the
> Print-Job has to be authenticated as well. We would like to add another
> operation that forces the server to generate a 401 authentication
> challenge which the client would submit before submitting the print job
> in the first place. Unless somebody has a different solution
> (Microsoft)
>
>
> Possible alternatives:
>
> 1.Add the operation as an OPTIONAL operation to IPP/1.0 and IPP/1.1
> that forces the IPP object to issue a challenge to the client.
>
> 2.Use two URLs for the same IPP Printer object, one requires
> authentication and the IPP server always issues a challenge and 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?
>
> 3.Use two IPP Printer objects that fan-in to the same device. One IPP
> Printer object requires authentication and always issues the
> challenge and the other never does. ISSUE: How does the client
> discover which IPP Printer to use for authenticated access?
>
> 4.Request that the HTTP WG add some kind of header that allows the
> client to request that the HTTP server issue a challenge. ISSUE: It
> is unlikely that the HTTP group would do such a thing, since it is
> not needed for the usual use of HTTP which is to access documents on
> a server.
>
>
>
>