> -----Original Message-----
> From: Michael Sweet [mailto:email@example.com]
> Sent: Friday, March 26, 1999 2:25 PM
> To: Herriot, Robert
> Cc: firstname.lastname@example.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
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 email@example.com
> Printing Software for UNIX http://www.easysw.com