IPP Mail Archive: Re: IPP> Security - Issues with the existing proposals

Re: IPP> Security - Issues with the existing proposals

Philip Thambidurai (pthambid@okidata.com)
Wed, 12 Nov 1997 16:21:29 -0500

A couple of comments on your good summary:


1) The TLS spec also states that the TLS_DH_anon ... ciphersuites
are "deprecated". These are part of SSL3.

2) In Proposal #2, when you say that "Digest Authentication" can be
used, I assume you are refering to the HTTP level.


My take on this is to go with your proposal #1. It would certainly be
more difficult for us to agree on ciphersuites!! (a "minimum" level).
Definitely not our domain or task to decide how much of TLS should be
required.

Philip Thambidurai

______________________________ Reply Separator _________________________________
Subject: IPP> Security - Issues with the existing proposals
Author: "Xavier D. Riley" <xriley@cp10.es.xerox.com> at INTERNET
Date: 11/12/97 12:20 PM

All,
The purpose of this note is to discuss the
implications of using the security schemes
discussed thus far related to IPP. The following is
a summary of details and issues of the security
schemes. It is assumed that there will be embedded
servers in some low-end IPP printers.

Proposal #1 (2 URI scheme)
++++++++++++++++++++++++++
- Characteristics
1. 2 URIs - one for secure and one for non-secure
connections
2. Non-secure connections would use the following
schemes:
-Digest Access Authentication
-No Authentication
3. Secure connections would use the following
schemes:
-TLS with configurable Cipher Suites at both
the client and server (negotiated at
connection time).
- Advantages:
1. Non-secure (as defined above) can be the
minimum security implemented
2. TLS implementation can be optionally implemented
in print systems.
3. No need to wait for TLS deployment (can use
existing off-the-shelf web servers)

- Disadvantages:
1. 2 URI configurations needed
Xavier's Editorial: It is debatable whether this
is a major disadvantage. It could be seen to some,
at most, an annoyance. The 2 URI scheme is the
existing model of the WWW (http & https). Keep in
mind that two URIs are only needed if a print
system is enabled to be both non-secure and secure.
In my opinion, most printers will either be secure
or non-secure, not both. (I would like to hear other
opinions on this.)

2. Complicated directory entries needed to reference
printers that are configured to support both
non-secure and secure schemes simultaneously. There
may need to be two entries with cross references to
each other.

Proposal #2 (1 URI scheme)
++++++++++++++++++++++++++
- Characteristics
1. Have a single URI for both secure and non-secure
using TLS framing.
2. As an minimum, one of the following cipher suites
would need to be implemented by all IPP compliant
printers since TLS_NULL_NULL_NULL is not an option
based on the latest TLS draft:
A. TLS_RSA_WITH_NULL_MD5
- Server authentication enabled (using RSA
certificate)
- No encryption of data
- Data Integrity (using the MD5 algorithm)
- Client Authentication is optional (using
either Client certificates or Digest Access
Authentication)
B. TLS_DH_anon_Export_with_RC4_40_MD5
- No server authentication
- Encryption (using RC4/DES40 algorithms)
- Data Integrity (using the MD5 algorithm)
- No client authentication (Digest Access
can be used)
C. TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
- No server authentication
- Encryption (using 3DES algorithms)
- Data Integrity (using the SHA algorithm)
- No client authentication (Digest Access can
be used)
Notes
- TLS uses (DH_anon*) as a minimum
- TLS_NULL_NULL_NULL is not an option for no
security. (See section A.5 of the latest
TLS draft)

- Advantages
1. Single URI
2. Simpler directory schema

- Disadvantages
1. Dependency on the deployment of TLS capable
web servers.
2. Increased footprint for embedded print systems
due to the mandatory implementation of the
minimum TLS cipher suites (MD5, RC4, 3DES,
SHA, or RSA CERTIFICATE INFRASTRUCTURE)
3. Runtime overhead for using encryption (RSA ,
RC4 or 3DES)

Carl-Uno Manros
John Wenn
Daniel Manchala
Xavier Riley

______________________________________________________________________
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: xriley@cp10.es.xerox.com
______________________________________________________________________