Bob Herriot
> -----Original Message-----
> From: Michael Sweet [mailto:mike@easysw.com]
> Sent: Friday, March 26, 1999 2:25 PM
> To: Herriot, Robert
> Cc: ipp@pwg.org
> Subject: Re: IPP> MOD - Issue 2: How can client force authentication,
> i.e., identified mode? Solution #2 preferred
>
>
> "Herriot, Robert" wrote:
> >
> > 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.
>
> Consider the typical network printer - is there enough persistent
> memory to store usernames and passwords for 1000's of users?
>
> I'm thinking of our college/university customers, many of whom do
> exactly the type of group access control I mentioned in my previous
> message. It isn't feasible to manage separate usernames and passwords
> on 100's of printers and systems independently, so they assign
> usernames and passwords to groups that need access to common
> resources. These accounts are changed every 4 months, and with
> a robust enough server implementation (that logs the time and IP
> or hostname of the requestor) you can track down abusers pretty
> quickly.
In the above scenario, does the printer receive information about the
students name and group name or just the group name?
>
> 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.
>
> > 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".
>
> 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.
>
> > 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.
>
> I don't think including the HTTP authentication information in the
> IPP attributes is appropriate - aren't we trying to keep IPP
> separate from the actual transport protocol?
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.
>
> > With regard to your suggestion of "authentication-required"
> > attribute, the "authentication-supported" that I proposed serves
> > that function.
>
> "supported" implies that the authentication is optional. I think we
> need to define the *required* authentication for each URI supported
> by the server (i.e. if there are 4 URIs you can use, then there are
> 4 authentication-required's). If I understood your previous proposal,
> it sounded like you'd have a set of authentication types that were
> acceptable, and the client could choose from them (which won't work
> unless you store unencrypted passwords so you can compare clear-text
> or md5 encoded strings).
I picked a name that was parallel with "printer-uri-supported" and
"uri-security-supported". One could use your comments to argue that
"uri-security-supported" should be called "uri-security-required" because
each values specifies the security that MUST be used for the corresponding
uri, just as each value of "authentication-supported" specifies the
authentication that must be used with the corresponding uri.
>
> --
> ______________________________________________________________________
> Michael Sweet, Easy Software Products mike@easysw.com
> Printing Software for UNIX http://www.easysw.com
>