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

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

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

Manros, Carl-Uno B cmanros at cp10.es.xerox.com
Tue Mar 23 21:05:30 EST 1999


Tom,

You did not get the last alternative that I suggested quite right.
It would NOT require a NEW header, we would use the Upgrade header 
in the same way that we use it for TLS in IPP/1.1 already. We
will need to register a new value for the existing header.

Carl-Uno

> -----Original Message-----
> From: Hastings, Tom N [mailto:hastings at cp10.es.xerox.com]
> Sent: Tuesday, March 23, 1999 5:24 PM
> To: ipp
> Subject: IPP> MOD - Issue 2: How can client force 
> authentication, i.e.,
> identi fied mode?
> 
> 
> 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.
> 
> 



More information about the Ipp mailing list