IPP Mail Archive: RE: IPP> MOD - Issue 2 - Challenge

RE: IPP> MOD - Issue 2 - Challenge

Herriot, Robert (Robert.Herriot@pahv.xerox.com)
Tue, 30 Mar 1999 14:38:52 -0800

If I understand your second case correctly, you are describing current HTTP
behavior with an additional client feature which keeps a user from
accidentally performing an operation if a challenge is not received.

The problem you are solving is a bit different from the one originally
stated. The original desire was for a printer which would normally not
issue a challenge but which could be asked by a user to issue a challenge
when the user wanted better authentication.
The person who submitted this problem believes that it is important.

I have suggested that if there really is a problem needing a solution, the
simplest solution is for the printer to have two URLs one that always issues
a challenge and one that never issues a challenge.

Bob Herriot

> -----Original Message-----
> From: Scott Lawrence [mailto:lawrence@agranat.com]
> Sent: Tuesday, March 30, 1999 1:54 PM
> To: IETF-IPP
> Subject: RE: IPP> MOD - Issue 2 - Challenge
>
>
>
> > I have been pondering about whether we are trying to make life a
> > little too
> > difficult for ourselves when we look for a solution to this
> > issue.
>
> I'd say that was nicely understated.
>
> > Why don't we mandate in IPP/1.1 that IPP printers ALWAYS
> send a challenge
> > for Digest Authentication?
>
> I'm not clear on why this is an issue; as I see it there are
> two cases:
>
> - Print Service wants authentication.
> The server has all it needs to enforce that today in the HTTP layer.
>
> - User wants authentication.
> All that the user needs for this is an indication from the
> user agent
> that a particular operation is or is not authenticated, and
> perhaps some
> UI mechanism to indicate that it should not be performed without
> authentication.
>
> Note that I said 'Print Service' and 'User', _not_ 'Server'
> and 'Client (or
> User Agent)'. Software doesn't make these decisions, people
> do. Print
> services in some environments will be wide open; anyone who
> can get the
> packets there has a right to print. Others will require
> authentication to
> support accounting or access control. Some users will want
> to know that
> they are properly authenticated, or that the print service is
> authenticated
> (digest is symmetric).
>
> If IPP needs anything at all, it needs only a recommendation
> that the User
> have an indication and/or option to require authentication.
> If the service
> doesn't offer it, then the user can find a service that does.
>