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

From: [email-masked] (Ira Mcdonald x10962) (by way of Carl-Uno Manros <[email-masked]>)
Date: Wed, 17 Dec 1997 19:42:50 -0800

Keith and Harald,

This is one strong reaction I got back on the DL as result of our attemps to
satisfy your security requirements in Washington.

Do you have any comments?

Carl-Uno

----

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: [email-masked]
>From: Carl-Uno Manros <[email-masked]>
>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".
>----------------------------------------------------------------------<

---

From: [email-masked]
Date: Thu, 18 Dec 1997 11:24:55 +0100

Thanks - will go back to WG list and reply.

       Harald A

---

From: Keith Moore <[email-masked]>
Date: Thu, 18 Dec 1997 09:44:22 -0500

> The IETF ADs are just plain WRONG about this

We respectfully disagree.  Internet standards specify requirements
for interoperability over the entire Internet, not just in an 
enterprise network.  Many enterprise networks also need security.

Be assured that the requirement for strong, mandatory, interoperable
authentication will not be changed.

> "mutual authentication, data integrity, and data confidentiality".

this is fine w/me.

Keith