Following Keith's message, those who were at the meeting
last week resolved that minimum security for IPPv1.1 would
consist of:
1. Either Digest user authentication (not encryption of the
body) OR TLS secured channel w/Basic (not certificates) for
the IPP server (allow choice so low cost devices can simply
support Digest)
2. Both Digest (as described) AND TLS (as described) w/Basic
for the IPP client (need both for interoperability with
either type of server)
Obviously, this decision needs exposure to the reflector!
Hopefully we can all reach full agreement on this within
the next week or two at most.
Harry Lewis
IBM Printing Systems
harryl@us.ibm.com
---------------------- Forwarded by Harry Lewis/Boulder/IBM on 04/21/99
11:53 AM ---------------------------
Keith Moore <moore@cs.utk.edu> on 04/15/99 11:33:23 AM
To: Harry Lewis/Boulder/IBM
cc: moore@cs.utk.edu, cmanros@cp10.es.xerox.coM
Subject: Re: Security in IPP
> But, is it mandatory for every device that implements IPP to also
> implement a security protocol?
the IPP spec must require that all combinations of conforming client
and server implementations be able to provide authentication which
does not expose a password to eavesdroppers, and which protects the
printer resource against unauthorized use.
note that:
- there is not currently a requirement to provide protection
of the content - i.e. encryption is not required of a minimal
implementation
- this doesn't quite mean that all clients and servers have to
support algorithm X. the requirement could be met by requiring
all clients to support algorithms X and Y, and requiring all
servers to support either X or Y or both.
- there's not even a requirement that the device be able to
support an arbitrary number of users.
frankly, for a device that already needs to be capable of supporting
a network interface and TCP and HTTP, I don't see the problem with
requiring support for digest authentication for a small number of users.
The implementation overhead of HTTP digest appears to be fairly small -
looks like 4-6K bytes on a Intel x86 box.
my guess is that the real problem is providing a facility to manage
large numbers of accounts and passwords, and this is clearly not
something that should be required of a printer of modest capability.
such a printer should either be spooled through a proxy which knows
the printer's password, and which performs its own authentication of users,
or there should be a separate protocol which the printer can use to
"hand off" authentication to a separate server. IETF needs to define
such a protocol, but we almost certainly shouldn't block IPP's progress
until this happens.
Keith
**Attaching a portion of Harry's 4/15/99 query**
In the "final stretch", we are struggling to understand, accept
and address the security goals of the IETF as they apply to IPP.
(We are probably making this harder than it needs to be, stemming
from our lack of expertise in the area). In New Orleans, this week,
we had a bit of a disagreement regarding these goals.
The basic question is one of semantics regarding "specification"
vs. "implementation". If we view the Internet as a suite of protocols,
we readily agree that interoperation of these protocols is the source
of the overall synergy that drives the Internet and makes it useful.
The IETF has, appropriately, instructed the IPP working group to specify
a means of operating within the security framework, has explained why it
is not appropriate to specify the (encumbered) SSL protocol as part of
the standard and has encouraged us to embrace (the evolving) TLS
specification. Our main concern is that we would like to avoid creating
an artificial "bottom" to the range of devices that actually adopt the
Internet Printing Protocol.
It is mandatory for the IPP standard to specify a means of operating
within the Internet security framework - this is clear. But, is it
mandatory for every device that implements IPP to also implement a
security protocol? Printing solutions range from very low cost
($100 range) devices to very high end ($100K range) solutions.
Incredibly, IPP is robust and scalable enough to cover this entire range!
With IPP forming a viable alternative to transmitting documents to remote
locations (analogous to FAX, today), and likely to become the prevalent
print submission protocol for Intranet as well as Internet, the broader
computing/print landscape will beg for IPP in very low cost
implementations.
Typically, such low cost implementations focus only on the most fundamental
operations that support the function of their appliance. For example, such
a low cost printer would not support e-mail, PTS-FAX or (perhaps) Internet
Security. It would, however, PRINT via the predominant (IPP) protocol.
I think it would be helpful to clarify that the requirement for IPP is
to specify a standard way to interoperate with the Internet security
framework but that this does not mandate security in every IPP
implementation.
If I am wrong in this regard, than a succinct clarification, in general,
would still be useful.
Harry Lewis.