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

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

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

Herriot, Robert Robert.Herriot at pahv.xerox.com
Fri Mar 26 16:14:17 EST 1999


I didn't expect to hear of such a scenario because it reduces security for a
user whose name could be spoofed by someone in the group who knows the
password.

If your scenario of a group name for digest authentication is likely, then
we could have two additional values for the "authentication-supported":
"basic-requesting-user-name" and "digest-requesting-user-name". The first
means that both basic authentication and the requesting-user-name are used
and that they may be different. The meaning of the second is similar except
with "digest".

Such a change would mean that the attribute "job-originating-user-name"
would have to keep both names encoded in some syntax, such as
"basic-name,requesting-user-name" if they are different.  It would also mean
that the hierarchy of authenication could not include these two if the names
were different.

With regard to your suggestion of "authentication-required" attribute, the
"authentication-supported" that I proposed serves that function.

Bob Herriot

> -----Original Message-----
> From: Michael Sweet [mailto:mike at easysw.com]
> Sent: Thursday, March 25, 1999 7:27 PM
> To: Herriot, Robert
> Cc: ipp at pwg.org
> Subject: Re: IPP> MOD - Issue 2: How can client force authentication,
> i.e., identified mode? Solution #2 preferred
> 
> 
> "Herriot, Robert" wrote:
> > 
> > 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:
> > ...
> > 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:
> > ...
> 
> I think ignoring the "requesting-user-name" attribute is a bad idea
> under any circumstances.  HTTP authentication is separate from the
> IPP request, and in many cases the HTTP username may be different
> from the actual requesting user (i.e. a group username/password to
> get access to the printer, with the IPP requesting user name used
> for accounting).
> 
> The best option might be to add a "authentication-required"
> attribute that defines what kind of authentication is required for
> each URI in "printer-uri-supported".  The values would be "None",
> "Basic", and "Digest" (at a minimum), and for Digest authentication
> the IPP client could then request the current printer state to
> initiate the challenge before the job is sent (there are issues if
> the printer has a time-based nonce...)
> 
> (FWIW, our current implementation uses the HTTP username value if
>  the "requesting-user-name" value is not specified, but is otherwise
>  ignored for purposes of printer accounting)
> 
> -- 
> ______________________________________________________________________
> Michael Sweet, Easy Software Products                  mike at easysw.com
> Printing Software for UNIX                       http://www.easysw.com
> 



More information about the Ipp mailing list