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

From: "Turner, Randy" <[email-masked]>
Date: Wed, 17 Dec 1997 17:55:57 -0800

Originally, Keith Moore had problems with our standard 
saying that implementing secure and non-secure IPP
was developing TWO protocols and would be pushed
back from the IESG.

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:	[email-masked] [SMTP:[email-masked]]
> Sent:	Wednesday, December 17, 1997 3:11 PM
> To:	[email-masked]
> 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: [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: Carl-Uno Manros <[email-masked]>
Date: Thu, 18 Dec 1997 02:48:41 -0800

At 11:37 PM 12/17/97 -0500, you wrote:
>I've gotta say that I agree with Ira on the topic of mandatory
>support for security.  Seems a bit extreme to require both ends
>of a comm session to perform a relatively heavy security dance
>when the customer does not wish to get involved with the
>attendant administration.
>
>	...jay
>
>Ira Mcdonald x10962 wrote:
>

I will do my best to respond as we have not yet heard from any of the 
Area Directors: 

Jay's assumption that both clients and servers have to support 
everything is false, only the clients have to support both servers that
use "HTTP security" and "TLS security". This was the compromise from
Washington DC.

The reason why the IETF is so stringent about security features is that
they are designing solutions for the INTERNET, they do not care about
INTRANETS. Part of the problem is that the press takes every opportunity
to criticize the "Internet" for its lack of security, which is threatening
the overall reputation of the whole Internet concept and has forced the
IETF to take somewhat extreme measures in response. 

If, like Ira states, implementors react against some of the security 
language in an IETF document, then they will implement an "almost conforming" 
version without the security features they do not like. In the end, the 
market decides what products you can sell at what price. My assumption
though is that customers will buy the "secure" versions, even if they cost
a bit more, as soon as the recently standardized IETF security features
become more generally available as products (which might take a couple of 
years). So I think that we are debating a timing problem rather than a
technical problem.

Carl-Uno

---

From: Carl-Uno Manros <[email-masked]>
Date: Fri, 19 Dec 1997 07:09:51 -0800

At 01:43 PM 12/19/97 +0100, [email-masked] wrote:
>
>[email-masked] said:
>> The alternative is for IPP to convince IESG that digest 
>> authentication alone really is adequate for a wide variety of printer 
>> authentication  scenarios.   I won't claim that it cannot be done, 
>> but offhand, I don't see how to do this. 
>
>The third alternative is, of course, to claim that the WG is now convinced
>that it's acceptable for an IPP client to be unable to print on any
>printer that requires non-shared-secret authentication.
>This did not seem to be the consensus in Washington, but after all,
>the list, not the meeting, is the final arbiter of IETF WG consensus.
>
>Remember - you are the domain experts who are supposed to know what the
>requirements for a print protocol are; the IESG requirement is that:
>
>- It's possible for all conformant implementations to be able to
>  interwork, if configured to do so
>- Whatever functions must be implemented use neither cleartext passwords
>  nor encumbered technology, if possible
>
>If ability of a client to print on a TLS-only-configured printer is not
>in your requirements set, then that should not be a requirement.
>
>                   Harald A

Well,

It seems that Harald has a more liberal view on this than Keith. This seems
to open up the possibility to to recommend that all clients SHOULD support
TLS, but not make it an absolute MUST.

Comments?

Carl-Uno

---

From: [email-masked] (Ira Mcdonald x10962)
Date: Sat, 20 Dec 1997 07:43:00 PST

Hi Harald and Keith,

The irony that I'm now cast as an apologist for leaving out security
in networks has given me wonderful amusement for the last three days.

Both here at Xerox and in the past 24 years, I have done significant
design and development work on security protocols and standards.  I
do NOT advocate leaving out security in IPP.

By a logic that escapes me entirely, it has been collectively deemed
'cheaper' for all IPP clients to implement TLS, rather than all IPP
printers.  That apparent concensus is heavily weighted by the
backgrounds of the participants.

I capitulate.  Let all IPP clients implement TLS (with the one
mandatory cipher suite, without encumbered technology).

Cheers,