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

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

Paul Moore paulmo at microsoft.com
Thu Apr 22 12:35:19 EDT 1999


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

-----Original Message-----
From: Keith Moore [mailto:moore at 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
Authentication 


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

Keith



More information about the Ipp mailing list