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

RE: IPP> Security - Issues with the existing proposals

Gordon, Charles (CGordon@digprod.com)
Wed, 12 Nov 1997 16:40:33 -0500

If I understand what you are saying here, adopting option two would
require that all IPP servers implement some form of encryption, or
authentication and data signing. This will add additional requirements
to all IPP implementations, even low end ones which have no need for
security. Please bear in mind that many IPP printers (possibly most)
will not be used on the Internet at all. They will be used for printing
on internal corporate networks. There is no need for security for this
application, and requiring it simply adds to the cost of the product
with no real benefit to the user. While option two may be appropiate to
higher end IPP implementations, it would just be an unneeded burden for
the majority of the market.

Option one is much more reasonable, and I don't see any real
disadvantages to it. In the original message you stated that the
disadvantages to it are:

(1) It requires two URIs instead of one.
(2) It complicates the directory structure for IPP URIs.

As you point out in your comments, it is hard to come up with a reason
why printers need to support both modes of printing. In most cases,
printers will either be secure and will require a secure connection, or
will be unsecure and need not support security at all. As long as it is
one or the other, you will only have one URI base, and one directory
structure. There will be no disadvantages at all for these IPP
implementations. The only IPP implementations which will have to
support both URI's and a more complicated directory structure are those
which support both modes of printing. These will be high end printers
and it is reasonable to expect them to take on the extra burden for this
feature since they will probably have greater CPU resources and a larger
price tag.

Charles Gordon
Osicom/DPI

> -----Original Message-----
> From: Xavier D. Riley [SMTP:xriley@cp10.es.xerox.com]
> Sent: Wednesday, November 12, 1997 3:21 PM
> To: ipp@pwg.org
> Cc: CManros@cp10.es.xerox.com; JWenn@cp10.es.xerox.com;
> Manchala@cp10.es.xerox.com; XRiley@cp10.es.xerox.com
> Subject: IPP> Security - Issues with the existing proposals
>
> 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
> ______________________________________________________________________