The right thing to do is digitally sign the drivers. The more recent versions of
Windows (2000 and 98SE I think)support this. In the case where the drivers are
not signed then depending on the settings on the client the driver will be
rejected or the user will be given the choice about installing it or not.
But this whole idea of loading executable code from the network is a potentially
huge hole. On NT4 and for some windows 2000 drivers the driver is kernel mode
code - the idea of installing stuff with that level of trust from who knows
where is scary. Digest does not help as it allows the server to trust the client
- what we need is for the client to trust the server. This means that it must
use SSL or TLS.
Michael Sweet <mike at easysw.com> on 05/03/2000 11:57:29 AM
To: Hugo Parra <HPARRA at novell.com>
cc: lfarrell at cissc.canon.com, hastings at cp10.es.xerox.com,
rbergma at hitachi-hkis.com, don at lexmark.com, carl at manros.com,
Robert.Herriot at pahv.xerox.com, pmoore at auco.com, ipp at pwg.org,
imcdonald at sharplabs.com, harryl at us.ibm.com, Peter.Zehler at usa.xerox.com
(bcc: Paul Moore/AUCO/US)
Subject: IPP> Re: Printer Driver Extension
Hugo Parra wrote:
> ...
> IPP currently requires Digest Authentication. Wouldn't this be
> sufficient?
I dunno. Digest can be used to authenticate the transfer of the
file from the server to the client (e.g. "man in the middle"
attacks), but it doesn't protect against attacks that originate
on the server itself. In other words, the IETF may require that
IPP provides some mechanism for doing third-party authentication
as well (not necessarily as part of IPP) so that the source (the
IPP object) can be authenticated.
Of course, Digest *may* be sufficient for the protocol and that
may be all we need to worry about, but we need to address all
security concerns, vulnerabilities, etc. since we're talking about
executable code...
> ...
> A couple of popular systems I'm familiar with download printer
> drivers from places on the network much more obscure than the
> printer users intent to print to. I understand that's not a good
> enough argument to sell the proposal to the IESG. What I'm saying
> is that there's a real and pressing need for this functionality and
> if we don't address the need in the standard, people are going to do
> it proprietarily (is that a word?), guaranteed. So we require
> Digest Authentication and/or TLS in the spec and let implementors
> decide if their target market justifies the cost of including the
> extra security.
There are two issues - supporting different types of printers and
drivers, and ensuring some minimum level of security.
Any IPP extension MUST be capable of supporting multiple platforms;
all IETF standards are supposed to be platform and vendor neutral.
> Realize that most users will have already established some level of
> trust on the printer they intent to download a driver from, as
> they're willing to submit documents to be printed on that device.
I don't think trust has anything to do with it, aside from maybe
trusting that the printer won't jam or something.
> This trust might be based on the fact that they're using an IPP url
> off an internal corporate site, or a url off a well-known web site
> which they might have already validated using SSL or TLS.
I'd say that most users don't even think about network security
unless their credit card number is involved...
> ...
> Let's fix collections or embrace an alternative solution that keeps
> things simple. I strongly disagree with those who think we don't
> need this functionality in IPP. We can't go on kludging specialized
> encodings each time we run into this problem (a la "tree amigos"
> attributes).
I'm not sure that we're on that path - so far we've only encountered
three situations in which collections might be useful, and the
current IPP specs and extensions probably cover 95% of all network
printing needs.
IMHO collections will only complicate IPP implementations. Current
implementations can work with a fixed set of data types, with
reasonably deterministic results. Adding collections makes the
job of implementing, testing, and validating IPP software harder
and less deterministic.
> ...
> I like the idea of endorsing other Standards work and we should
> make sure the solution we choose allows the UPDF (and PPD)
> technology to be used. But as you point out, the UPDF effort is
> far from complete and we don't have the luxury to wait another
> year, to be extremely optimistic, before UPDF reaches any type of
> critical mass presence. We cannot ignore either the enormous
> wealth of legacy printer drivers.
I'm still not sure how easy it will be to support "legacy printer
drivers" with your proposal. Any current format used by PC printer
drivers (e.g. self-extracting ZIP files, .CAB files, etc.) will
certainly raise flags in the IETF.
> ...
> Windows clients (in al their incarnations) currently make up the
> bulk of our market. So PPD is definitely not an answer.
Except that 99% of the IPP-capable printers are PostScript capable...
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw.com
Printing Software for UNIX http://www.easysw.com