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
Tue Mar 30 16:19:09 EST 1999


I would like to suggest that your example of a student who uses a group
name/password to access the printer but uses his name for accounting is
a worthy case, but beyond the current architecture of IPP.

To allow your example to work, IPP would need the concept of users and group
membership.  It has only the former. 

I believe that we should not overload existing features in IPP in order to
support this new feature. So, I stand by my statement that a printer must
ignore "requesting-user-name" when using basic, digest or none.
 
Bob Herriot

> -----Original Message-----
> From: Michael Sweet [mailto:mike at easysw.com]
> Sent: Saturday, March 27, 1999 5:29 AM
> 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:
> > ...
> > > 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.
> 
> Correct.  If the student is getting billed for the prints s/he makes,
> then then they'd need to look at the server logs to see where the
> request came from, and then check to see who was logged on at the
> time.
> 
> I'm not saying that using the requesting-user-name over the HTTP
> authenticated user is a perfect solution, but if we decide that
> implementation should use the HTTP username over the IPP user name,
> it'll make any authentication in the "group" scenario impossible.
> 
> > >
> > > 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?
> 
> We'll need to have a consistent way to identify users, as the barcode
> reader will have to associate a print job with a specific student.
> 
> Also, when submitting a job the returned job status will be
> pending-held instead of pending. The IPP server will have to implement
> the barcode reader interface, and then release jobs when the correct
> user's card is read (this actually can be a separate program that then
> changes the job status, which is how we're providing the 
> hooks for it.)
> 
> > ...
> > > 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.
> 
> If you are able to gain access, then you'll be able to print. Period.
> 
> The "requesting-user-name" attribute should *not* be used for access
> control, only the HTTP authentication user should be (that's the
> one with the password).  The requesting user should only be used for
> accounting stuff, with the HTTP username substituted *only* if the
> requesting-user-name attribute is not provided.
> 
> This is at odds with section 4.3.6 of the model document, but IMHO
> it needs to be changed to address the "real" world.
> 
> If we really want to keep the HTTP user around, I suggest adding a
> job-authenticated-user-name attribute which contains the HTTP user
> name, while the job-originating-user-name will contain the
> requested-user-name or (if not specified) the HTTP 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.
> 
> I think we're confusing the authentication done with the HTTP username
> and password, and the accounting that can be performed with the
> requesting-user-name attribute.
> 
> Most typical HTTP servers will log the time, IP/hostname, and username
> of the requester.  While spoofing of the IPP user name could be done,
> it wouldn't accomplish much.
> 
> Again, I'm not saying to use requesting-user-name for access control.
> That would be ridiculous considering how easy it would be to spoof
> another user.
> 
> What I *am* saying is that the requesting-user-name attribute should
> not be overridden by default by the HTTP username.  If a client sends
> a user name, that user name should be used throughout the life of a
> job (and its "afterlife", if the server stores old jobs).  If a client
> doesn't send an IPP user name, the server should use the HTTP 
> user name
> (if available) so that *some* log of the printing user is made.
> 
> -- 
> ______________________________________________________________________
> Michael Sweet, Easy Software Products                  mike at easysw.com
> Printing Software for UNIX                       http://www.easysw.com
> 



More information about the Ipp mailing list