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

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

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

Paul Moore (paulmo@microsoft.com)
Thu, 22 Apr 1999 09:35:19 -0700

How do I enter valid userid and password combinations into the net card of a

-----Original Message-----
From: Keith Moore [mailto:moore@cs.utk.edu]
Sent: Wednesday, April 21, 1999 8:26 PM
To: Herriot, Robert
Cc: Keith Moore; IETF-IPP
Subject: Re: IPP> Re: PRO - Issue 32: Use of Basic & Digest

> I have discovered two scenarios which make me wonder whether
> should be required in all situations.
> I would appreciate your comments on the authentication requirements for
> following two scenarios:
> a) printers that act like a fax
> b) printers that are on a family network with a firewall protecting the
> from intruders.

there is no intent to require that all printer operations be authenticated;
whether to accept a particular request (or more generally, what credentials
are regarded as sufficient, and what privileges are granted for a given
set of credentials) are matters of policy for the owner of the printer
to decide.

from the standardization point of view the requirement is only that a
conforming printer *be capable* of requiring strong authentication in a
manner that can interoperate with any conforming client
(assuming that the client has been given the necessary credentials)

so although the printer will be required to implement either digest
or basic-over-TLS, nothing stops the owner of the printer from
accepting print jobs from any user regardless of the credentials
presented. maybe we need to define an "anonymous ipp" convention,
similar to "anonymous ftp" to make it clear how to do unauthenticated
printing. (though I do suspect that printer owners will want to impose
some rate- or page- limits on unauthenticated print jobs to prevent
attackers from consuming all of their paper/toner/ink)

> In the family network scenario, a printer vendor may be selling low-end
> printers for use in a family network where everyone within the LAN is
> trusted. There is a firewall installed to keep bad-guys out of the
> family-LAN and thus out of the printer.

in general, we don't want to standardize or encourage such practices.
a lot of the strength of the internet is in flexibility /transpaency/
location-independence and the interchangability of tools. if you have
a mobile computer, you want to be able to connect to the network and
access your services (including your printer) regardless of whether
you are wired or wireless, or at home, at work, or on the road.
having what is effectively a different printer protocol for "home"
use vs "office" use eventually means that you will need to use
different tools to print to each printer, or that you will have
arbitrary restrictions imposed on when you can print to a particular
printer, even if you have the right to do so. e.g. If I'm accessing
my work machine from home (whether by X windows or PC anywhere),
or vice versa, why shouldn't I be able to send something from the
computer I'm accessing (even though it is in a remote location) to o
the printer that is next to me? Or if I'm carrying around a
handheld PDA with a radio link to the net, for which I pay a flat
monthly rate for unlimited bandwidth (such deals are available now)
why in the world shouldn't I be able to send things from it to my
printer over the Internet? Okay I might want to be able to block
such things as a matter of policy but I don't want this blocked
due to an inherent limitation of the printer.

(and yes, I frequently find it useful to print to my home printer
from my desktop at work, and vice versa, sometimes even when I'm
not physically near that printer.)

the requirement for all ipp conforming printers (even those intended
for the "family LAN" market) to support authentication amounts to a
requirement that they be just slightly more flexible than necessary
for the family LAN. all it has to do is be willing to accept a
small number of usernames/passwords via HTTP digest. this is not
an onerous implementation barrier, nor a huge maintenance problem,
any more than the system password in postscript.

and as a practical matter the IESG is simply not going to accept an
IPP protocol standard that doesn't require strong authentication.
this is a matter of policy for the entire organization, and has
a lot of support not just in IESG and IAB but throughout the IETF
community. even if I were to say "it's okay with me" it wouldn't
be okay with others who are in a position to decide.