We discussed this and agreed that there would be
far more differing platforms and implementations
for servers than clients; and that realistically, OS
vendors will include IPP clients in their operating
systems (if IPP is successful).
So if a vendor ships a fully functional and secure
client, then it would always have an interoperability solution
no matter which type of server implementation was
contacted. (Realizing that we should also write
a "TLS profile for IPP" section in our document).
It is my opinion that this is the vast majority of
real world cases. If IPP is successful, OS vendors
will implement the clients, and code,RAM, and CPU
resources will not be that much of an issue on
host machines. It is server implementations of IPP
that will experience the widest possible deployment
scenarios (dedicated, CGI-based, ISAPI-based, on
the host, on the printer, split-functionality, etc.).
All of the arguments about mandating TLS for
ALL IPP implementations came from vendors that
would have this code burden for embedded
(in the printer firmware) implementations of IPP
servers.
It is also my opinion that if we attempt to diverge
from the consensus we had at the meeting in
Washington D.C., we will definitely have a problem
getting our spec through the IESG.
Randy
(Also, Scott Isaacson contacted Paul Moore about
this and Paul did not indicate any pushback with
this new client requirement).
> -----Original Message-----
> From: imcdonal@eso.mc.xerox.com [SMTP:imcdonal@eso.mc.xerox.com]
> Sent: Wednesday, December 17, 1997 3:11 PM
> To: ipp@pwg.org
> Subject: IPP> Re: ADM - Draft minutes [client security issues]
>
> Hi folks, Wednesday (17 December
> 1997)
>
> My comments on security issues are imbedded below.
>
> Cheers,
> - Ira McDonald (outside consultant at Xerox)
> >---------------------------------------------------------------------
> -<
> >Date: Mon, 15 Dec 1997 14:35:50 PST
> >To: ipp@pwg.org
> >From: Carl-Uno Manros <cmanros@cp10.es.xerox.com>
> >Subject: IPP> ADM - Draft minutes from the IETF IPP WG Meeting
> >
> >Please read the following draft minutes taken by Steve Zilles during
> the
> >meeting. If any of the meeting participants have copmments or if any
> of the
> >non-attendents need further clarifications, give us those back on the
> DL ASAP.
> >snip...
> >
> >Minutes IETF IPP WG Meeting, 97/12/10, Washington DC
> >1-3PM, Executive Meeting Room
> >snip...
> >
> >5. MUST-implement requirements for text and name strings; each
> string has
> >a maximum length specification:
> >some 63 octets, others 127 or 1023 octets
> >
> >snip...
> >
> >Decision:
> >Digest authentication is already mandated for all HTTP/1.1 clients
> >IPP will mandate TLS for all clients
> >
>
> My client s/w colleagues here at Xerox object STRONGLY to being told
> that the "interoperability" problem belongs to clients, so that they
> cannot build a simple client (without TLS) for intranet IPP printers
> and claim conformance. The IETF ADs are just plain WRONG about this
> one! Security should be a customer purchasing choice, not a "cost of
> doing business using Internet 'standards track' protocols"! If IPP
> actually does supplant LPR in the enterprise network (as we all hope)
> MOST of the printers and clients will be configured WITHOUT security.
>
> >snip...
> >
> >16. Security
> >Allow for "non-secure", really "authenticated" servers
> >If Privacy and/or Mutual Authentication is implemented, then it Shall
> be TLS
> >For HTTP/1.1, mandate and allow what HTTP/1.1 mandates and allows
> >
> >Decision:
> >rename "non-secure" to "authenticated"
> >rename "secure" to "private and authenticated" (or something similar
> >
>
> Both ISO and IETF security standards have consistently mandated that
> "data confidentiality" (often shortened to "privacy") may ONLY be
> supported when BOTH "data integrity" (eg, hash matching) and "data
> authentication" (eg, certficate exchange) are used concurrently.
>
> Therefore, I suggest that we rename "secure" to "private" and clarify
> that, in any IPP protocol mapping, the IPP term "private" SHALL mean
> "mutual authentication, data integrity, and data confidentiality".
> >---------------------------------------------------------------------
> -<