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>