Subject: IPP> Use of SSL3 Framing

From: Carl-Uno Manros <[email-masked]>
Date: Fri, 31 Oct 1997 14:12:09 PST

Bob,

The decision to require SSL3 framing has a number of consequences which
needs to be reflected in the Protocol document.

Where you speak about Encoding of Transport Layer (lines 350 - 357), you
now need to say that we are using the combination of SSL3/HTTP. The default
port for this is 443 (rather than 80), and the scheme for SSL3/HTTP is:
https (rather than http). All Printer-URI and Job-URIs will now start with
"https://"

Hope this reaches you in time to get these changes in.

Scott may need to check for similar changes in the Model document.

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: Randy Turner <[email-masked]>
Date: Sat, 01 Nov 1997 00:28:14 -0800

As an action item from the Boulder meeting, I am preparing a 
proposal document that addresses the order of operations for
negotiating security. This document also discusses, in part,
the use of URLs to designate security. A number of outside
parties involved with security (TLS working group and others)
will be reviewing this short document prior to distribution to
the IPP working gruop at large. This is in order to save the
IPP WG time reviewing and trying to understand something that
is technically inaccurate. Carl Kugler at IBM has also 
volunteered to help review and verify a security
negotitation proposal for IPP.

One of the ideas expressed in this document is that the
working group does not have to explicitly mandate the use
of HTTPS for a security scheme.

I will try to have this document out late next week.

Randy

---

From: Bob Van Andel <[email-masked]>
Date: Wed, 5 Nov 1997 23:44:44 -0500

Carl-Uno,

>needs to be reflected in the Protocol document.

The minutes from the Boulder meeting do not reflect why this decision was
made.  Can you enlighten me?

I could envision the following scenarios where this requirement would not
be necessary.

 - IP level security is in place
 - the entire conversation is on a private intranets behind firewalls
 - the printer is designated as equivalent to a public fax machine.

This requirement increases implementation and execution costs for both
clients and servers.

Regards,

Bob

----------------------------------------
Bob Van Andel
Allegro Software Development Corporation
43 Waite Road
Boxborough, MA  01719
(978) 266-1375
(978) 266-2839 fax

Information on the RomPager embedded web server toolkit is at
<http://www.allegrosoft.com/>

---

From: Randy Turner <[email-masked]>
Date: Wed, 05 Nov 1997 21:54:38 -0800

The fact that scenarios exist where security is not
necessary, do not obviate the need for the standard
to specify security as a requirement. Its possible
that one of the machines in one of these scenarios
might be moved or requested to communicate outside
of the scenario-specific domain and we don't want
to have to modify the configuration or install new
software in order to interoperate.

TCP supports re-ordering of packets and checksumming
but neither of these is really needed for hosts on
a single ethernet segment; nevertheless, the standard
specifies the capability in order to interoperate
outside of the segment, if need be.

The requirement for a specific security mechanism to
be used for IPP is closer to guaranteeing that some
level of security can be negotiated, end to end,
across any number of topologies.

Randy

---

From: Bob Van Andel <[email-masked]>
Date: Thu, 6 Nov 1997 09:18:57 -0500

Randy,

>software in order to interoperate.
<snip>

Existing Web browsers and servers make the transition from insecure
(non-SSL3) to secure (SSL3) modes and back all the time.  Why can't IPP
clients dynamically negotiate those transitions for those environments
where the site configuration warrants it.

I would expect that a number of site configuration issues will be necessary
that don't require software changes to interoperate, but do require
administrative attention.  Why is this different than the administrator
configuring which bin has letterhead?  I'm assuming that the IPP spec
allows a printer with a single paper source to ignore multi-tray attributes.

Bob

---

From: Randy Turner <[email-masked]>
Date: Thu, 06 Nov 1997 06:56:08 -0800

> where the site configuration warrants it.

SSL3 allows security parameters to be negotiated dynamically. All thats
required is the support for SSL3 framing and session initialization. We're
not absolutely requiring all of the cipher suites and authentication
mechanisms the SSL3 spec includes.
> allows a printer with a single paper source to ignore multi-tray attributes.s

Thats true, but security requirements for a particular
printer will not change as often as media in a tray, or other
printing-specific attributes. An administrator will decide if
a device should be secured and it will probably stay that way.
Security requirements for a printing server will be somewhat
static.

Also, I might point out, for a lot of cases, it will be client 
that decides security is necessary for a particular session
because the client knows the sensitivity of the content that
will be transmitted to the server.

In any of these scenarios, publishing a single URL for the
printer and using SSL3/TLS to negotiate security will come
closer to making sure client and server can interoperate,
at least as far as security is concerned.

Randy

---

From: "Xavier D. Riley" <[email-masked]>
Date: Thu, 6 Nov 1997 08:53:52 PST

Randy,
> This requirement increases implementation and execution costs for both

I second this opinion.  Although I support your intentions of wanting to have 
one entry for both a non-secure and secure IPP print system, I think the 
FUTURE TLS is the only practical solution to this problem.

I would speculate that most SSL3 web server implementations don't support
configuring the Cipher Suite to be SSL_NULL_NULL_WITH_NULL_NULL.

My vote (today) is to keep secure and non-secure entries separate for 
IPP 1.0 and when TLS is approved and deployed in existing off the shelf 
web servers, we specify the use of it in a later version of IPP.  I will 
hold my final vote until I read the document you plan to release this week.

The advertisement of non-secure and secure IPP print systems can occur outside
the IPP specification by the simple use of a Web page or LDAP server
advertising 
both print system URLs. I would venture to say that most implementations
would 
either be configured to be non-secure or secure, not both.

Non-Secure IPP Print Systems = No Authentication
                               Basic Authentication
                               Digest Access Authentication.

Secure IPP Print Systems = Channel level security (i.e. SSL3)

______________________________________________________________________
Xavier Riley                     
Xerox Corp.                      
Corp. Research & Tech.           Voice: 310-333-8329 / 8*823-8329   
701 S. Aviation Blvd ESAE-231    Fax: 310-333-6618 / 8*823-6618
El Segundo, California 90245     Email: [email-masked]
______________________________________________________________________