IPP Mail Archive: IPP> Re: ADM - Draft minutes [client security issues]

IPP> Re: ADM - Draft minutes [client security issues]

Ira Mcdonald x10962 (imcdonal@eso.mc.xerox.com)
Wed, 17 Dec 1997 15:10:34 PST

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".
>----------------------------------------------------------------------<