If you think about it, the server side of IPP wants to
make sure that the potential client is authorized to
use the resources provided by the IPP service.
The client (printing in an open internet arena) on the
other hand, would probably not want potentially
sensitive information intercepted when sending his/her
job over the internet.
In other words, now is not the time to be changing
the charter. It is a trivial exercise to imagine large
scale use of either mechanism for an "internet"
printing protocol, IMHO.
Randy
> -----Original Message-----
> From: Keith Moore [SMTP:moore@cs.utk.edu]
> Sent: Thursday, December 18, 1997 3:35 PM
> To: Robert.Herriot@eng.sun.com
> Cc: imcdonal@eso.mc.xerox.com; moore@cs.utk.edu;
> Harald.T.Alvestrand@uninett.no; ipp@pwg.org
> Subject: Re: IPP> Re: ADM - Draft minutes [client security
> issues]
>
> > Your comments above suggest to me that authentication (of a client)
> is
> > required and that privacy and mutual authentication are not.
>
> That's pretty much my opinion. Printers have real and significant
> costs associated with their use, so some kind of authentication is
> needed.
>
> > So, would it be acceptable for IPP to drop TLS and require that all
> IPP
> > clients and servers support HTTP/1.1 digest authentication?
>
> Not without explaining how this will scale to IPP's anticipated use.
>
> The problem is that IPP wants print servers all over the world
> to be usable from anywhere by any IPP client. Shared secrets
> don't even scale to medium size workgroups, much less user
> populations of the size of the Internet.
>
> Most printers aren't suitable for providing service to all comers
> anyway, so it doesn't make sense to require all printers to support
> scalable authentication. But you clearly want clients to be able
> to print to any of: local printers, printers in their
> office/workgroup/
> building, and printers in Kinko's and Sir Speedy's and other service
> providers that will be out there. Wasn't this a primary goal of IPP?
>
> So if IPP wants clear direction about what's likely to get past IESG,
> I'll say that clients MUST support both digest and TLS, and servers
> MUST support digest and MAY support TLS.
>
> The alternative is for IPP to convince IESG that digest authentication
> alone really is adequate for a wide variety of printer authentication
> scenarios. I won't claim that it cannot be done, but offhand, I
> don't
> see how to do this.
>
> Keith