Subject: Re: IPP> Security proposal

From: Carl-Uno Manros <[email-masked]>
Date: Fri, 7 Nov 1997 16:46:05 PST

At 02:55 PM 11/7/97 PST, Turner, Randy wrote:
>
>I have placed a draft of my IPP security proposal on the
>PWG FTP server.
>
>There is a Microsoft Word 2.0 document version
>
>ftp://ftp.pwg.org/pub/pwg/ipp/drafts/ippsec.doc
>
>and an HTML version
>
>ftp://ftp.pwg.org/pub/pwg/ipp/drafts/ippsec.html
>
>Randy
>

Randy,

Randy,

Thanks for taking the time to put your ideas on paper.

I looked over your proposal and would like you to comment on the following
things.
I expect to get back with more detailed comments after having spoken to my
security guys on Monday.

1) I was disappointed that you did not spell out what is now the minimum
"extra stuff" that every implementation would have to include if we
mandated TLS negotiation for all IPP clients and servers. My latest
impression is that it is a lot more than we anticipated when the subject
was discussed in the Boulder PWG meeting.

2) Earlier today Keith Moore came up with a proposal to take a new look at
SASL, which might eliviate some of the extra burden that 1) above might
incur. Do you or anybody else knows if "the world" is really going to
implement SASL in the foreseeable future (or are we up against yet another
road block here)? Judging from the comments on the DL recently, a number of
people have asked for a very light weight mechanism to do the initial
security negotiation, with the option to say "NO I do not want any
security", and I am still not convinced that TLS will deliver that.

---

If I have interpreted the feelings of the WG on this subject correctly, I
would like to draw a comparison with safe sex:

If you tend to mix with new or potentially unreliable partners, you are
quite likely to want to have some form of protection and would welcome the
subject to be brought up before you get too intimate. However, if you only
practise it with a steady and wellknown partner, you would probably be
upset to have to go through a forced negotitation about different types of
preventive tools and methods every time. If you trust your partner, you
should be allowed to practise unsafe sex at your own risk, without any
lengthy negotiation beforehand!

Regards,

Carl-Uno
Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: [email-masked]

---

From: "Turner, Randy" <[email-masked]>
Date: Tue, 11 Nov 1997 13:37:37 -0800

> -----Original Message-----
> From:	Scott Lawrence [SMTP:[email-masked]]
> Sent:	Monday, November 10, 1997 6:49 AM
> To:	[email-masked]
> Subject:	Re: IPP> Security proposal
> 
> 
> >>>>> "RT" == Randy Turner <[email-masked]> writes:
> 
> RT> Currently, I don't know of any way an HTTP client has to direct an
> RT> HTTP server to make a particular connection secure, and IPP needs
> RT> either end to indicate this requirement.
> 
> >>>>> "SL" == Scott Lawrence
> 
> SL>  If you're using 'secure' as 'confidential', then the client
> requests
> SL> that protection by making the connection on the SSL port (https:),
> SL>  and indicates that it does not require confidentiality by making
> the
> SL> request on a non-SSL port.
> 
> The problem is that HTTPS is a different URL. What I was considering
> was the
> case where there is only one URL specified for the IPP printer. What
> I'm trying to
> avoid is running two different IPP services (one secure and one
> non-secure) if
> I want to support both secure and non-secure environments. With one
> URL,
> we just connect and negotiate whether or not security is required. 
> 
> SL>  The service (the printer or print server) probably cares more
> about
> SL>  authentication than confidentiality for IPP, and it can get that
> on
> SL>  a connection that is either confidentiality protected or not
> using
> SL>  Digest Access Authentication.
> 
> The server caring more about authentication than confidentiality is
> emphaisized in my previous proposal, as is the option for 
> confidentiality or not.
> 
> Ultimately, my proposal prioritizes the selection of TLS for our only
> security framework for IPP. If we end up going down the path of
> supporting multiple URLs for different types of security, I think
> it would be unfortunate and add greater administrative and
> resource impact for those environments that would like to
> support both secure and non-secure IPP services. 
> 
	Randy

>  --
> Scott Lawrence           EmWeb Embedded Server
> <[email-masked]>
> Agranat Systems, Inc.        Engineering
> http://www.agranat.com/

---

From: [email-masked] (Philip Thambidurai)
Date: Wed, 12 Nov 1997 07:54:19 -0500

I don't really see a problem in having two URLs, one for non-secure and the 
other for secure (https). The directory schema could list both. If security is 
desired then TLS could be used to negogitate (automatically) to the desired 
ciphersuite.

The non-secure server could allow unauthenticated, basic-auth and digest-auth.
The unauthenticated case would correspond to the "anonymous printing" that Randy
mentioned earlier.

Using https and then negotiating down to no security at all still requires use 
of port 453 --- this is somewhat deceptive (to a sys admin person). It might?? 
be difficult to monitor who is using non-secure vs. secure if we use port 453 
for both. If security is mandated when using 453, then the sys admin does not 
have to worry as much about any potential attack. It then makes sense to keep 
the non-secure server separate (port 80).

Philip Thambidurai

______________________________ Reply Separator _________________________________
Subject: RE: IPP> Security proposal
Author:  "Turner; Randy" <[email-masked]> at INTERNET
Date:    11/11/97 1:37 PM

        Randy