IPP> Re: PRO - Issue 32: Use of Basic & Digest Authentication

IPP> Re: PRO - Issue 32: Use of Basic & Digest Authentication

IPP> Re: PRO - Issue 32: Use of Basic & Digest Authentication

Malcolm Holser mholser at Adobe.COM
Thu Apr 22 17:16:02 EDT 1999

>Paul Moore wrote:
>I have a printer in my office that
>a) doesnt support PS
>b) gets its IP stuff via DHCP
>c) allows anybody to do firmware updates
>d) allows anybody to install fonts
>e) allows anybody to print
>You are telling me that this device CANNOT support IPP no matter how much I
>want it for its non security related features.

Well, at least this printer does not support PostScript, otherwise it
is a real security hole.  I do not understand why there is a desire to
have this class of printer be _fully_ compliant with IPP in order to
do most IPP things.  It would seem to me that nobody is forcing a
printer to full compliance, only that a non-compliant printer must not
claim compliance.  This is pretty common in the real world with other
protocols.  Most machines don't comply in so way or another, but 
then they don't claim compliance (well, some do -- grrrr).

I think that it would be fine to build such a printer.  I would buy one for
home, even.  I would think twice about it, even for home, if it supported
a language like PostScript, and was more than just a dumb printer.

Of course, I'm a little confused as to what constitutes a *real* IPP
printer.  If you built something like a Netport device that was attached
to a dumb printer, but "did" IPP, is the combination an IPP device?
How about a driver on a host attached to a dumb printer?  If the first
is acceptable, then the second should be as well, since it is effectively
the same thing -- just that the host box runs more stuff.

Can a dumb printer, that does not support all of IPP gain full compliance
by using a host-side driver to handle the difficult stuff?  For instance, it is
true that you can't store an endlessly long password file in NVROM, but
you can create a secure connection to a host machine that can.  These
are all networked devices, so they are never in isolation. Can an existing 
printer "become" an IPP device simply by having a  dedicated server host
these functions?  Is a NIC card that does IPP any different than this?

I would hope so.

I live in an area that is considered "safe" -- nobody locks their doors, and 
most people leave their keys in the ignition so they are easy to find.  But
bad things can happen.  Just because it does not seem likely, or has not
happened yet is no assurance, and a standard must be stronger than it 
needs to be.  Cars *need* locks, even if nobody where I live uses them.

Currently, most "enterprise" printers connected to networks have _no_
security.  Most are PostScript devices.  The company I work for has
thousands of them.  You can damage all of them, and cause lots of
work for the administrators by sending a single line of PostScript:
      0 setcolor {clippath fill showpage} loop
This would cause physical damage to most laser printers, and run through
amazing quantities of consumables -- and money.  Such an attack 
would be extremely difficult to absorb for most companies today, but they
generally have their doors wide open for this.

IPP should not sidestep this issue -- there will certainly be a market for
simple non-IPP compliant printers well into the future.  Personally, I think
that stronger security is desireable.

I would rather build a stupid device, that had a simple secure connection
to a strong host, and have the host implement IPP and be "seen" outside
as the IPP printer, rather than trying to stuff more crap into one of the most
cost-reduced items in computing today.  I would believe than most small
printers are already sold below cost.  Adding more to them is generally a

Flame away -- I usually deserve it.

Malcolm Holser

More information about the Ipp mailing list