Attached below is the security document that will be submitted to the
IETF with out IPP/1.1 documents.
Shivaun
----------------------------------------------------------------------
The purpose of this memo is to explain the logic behind the IETF IPP
WG decision to RECOMMEND digest authentication rather than to REQUIRE
it in both the client and server implementation of IPP/1.1. While all
clients are required to implement security, the IPP/1.1 Model document
states that an IPP Printer (a.k.a. Server) SHOULD implement security
and the method for that security is Digest Authentication. While the
IETF IPP WG believes that security is important, it also believes that
there is a certain class of printer devices where security makes sense
and a certain class of printer devices where it does not make sense.
Specifically, a low-end/low-cost device with limited ROM space and low
paper throughput may not need authentication. This class of devices
typically requires firmware designers to make often extreme trade-offs
between protocols and functionality to arrive at the lowest-cost
solution possible to address the needs of a specific market. Factored
into this decision is not just the size of the code, but also the
testing, maintenance, usefulness and time-to-market impact for each
feature delivered to the customer. In addition, the administrative
burden of maintaining the user information for authentication may not
make sense in environments where low-end devices are typically
utilized. Forcing these devices to provide security in order to claim
IPP/1.1 compliance would not make business sense and could potentially
stall the adoption of the standard.
A high-end print device that has high-volume throughput and has more
available ROM space has a more compelling argument to provide security
that safeguards the device from unauthorized access. These devices
are prone to a high loss of consumables and paper if unauthorized
access should occur. Additionally, printers targeted for special
media such as checks or securities will obviously implement security
often using more advanced means such as TLS.
The IETF IPP WG group believes the examples set by other protocols
that were just recently approved by the IETF that did not include
security requirements are also appropriate for IPP. These two
protocols are: Service Location Protocol (SLP) version 2 and Internet
Fax (RFC2531). Neither of these protocols require security in order
to claim compliance.