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 21:09:09 EST 1999


Comments below

> -----Original Message-----
> From: Michael Sweet [mailto:mike at easysw.com]
> Sent: Friday, March 26, 1999 5:02 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:
> > ...
> > In the above scenario, does the printer receive information 
> about the
> > students name and group name or just the group name?
> 
> Both names.  The group name (and password) gets past the HTTP
> authentication, and the student name is used for accounting (and in
> some cases billing).

So in the above case, I assume that it is fairly easy to spoof another
student's name, but the spoofer is likely to be another member of the group.
> 
> We even have some customers that are using barcode readers to validate
> jobs before they are printed (the student puts his ID card under the
> reader to release the job in the queue).

How do you see the above solution fitting in to the IPP issues we are
discussing?

> 
> > ...
> > > Also, given the current (lack of) transport-level encryption in
> > > IPP/1.0 (and likely in most IPP/1.1 products), HTTP authentication
> > > is just as prone to spoofing as the requesting-user-name field in
> > > the IPP request.
> > 
> > I agree, except that its a little harder because the 
> spoofer needs to
> > get two pieces of information: a password and a name.
> 
> Still not that difficult...
> 
> > ...
> > > I still don't like making the requesting-user-name attribute that
> > > weak.  In the group-account scenario it would allow a 
> member of the
> > > group to "anonymously" submit a job...
> > 
> > I don't know what you mean by "that weak". IPP says that a client
> > "should" supply the requesting user name.  If none is supplied, the
> > printer doesn't know who submitted the job except for basic/digest
> > information, if any. However, a printer implementation is free to
> > have a policy that denies access to anonymous job submitters.
> 
> I say "weak" because in your original proposal the HTTP username would
> override the requesting-user-name attribute.  The HTTP 
> username *should*
> be used, but IMHO only if requesting-user-name is not supplied.

But if the requesting-user-name overrides the HTTP name, then I can gain
access via digest using my name/password and then pretend I am someone else
by sending in a bogus requesting-user-name.

> 
> Also, since the spec doesn't require requesting-user-name, I don't
> think that a compliant server can refuse the job on that basis.

A compliant implementation cannot refuse such a job, but an administrator
may be allowed by the conforming implementation to enable such a policy.
Clealy, an administrator should not do this in an environment where clients
mostly don't include the requesting-user-name.

> 
> This isn't something for the standard, but definitely should be
> discussed in the implementer's guide.  Otherwise we'll end up with
> inconsistent implementations (both servers and clients) which will
> limit the acceptance of IPP by large installations.
> 
> > ...
> > No, an implementation must support values that apply to its 
> transport.
> > The values of the attribute "uri-security-supported" are 
> also tied to
> > what HTTP makes available.
> > ...
> 
> OK, that does make sense then...
> 
> -- 
> ______________________________________________________________________
> Michael Sweet, Easy Software Products                  mike at easysw.com
> Printing Software for UNIX                       http://www.easysw.com
> 



More information about the Ipp mailing list