IPP> SEC - Security Issue - Proposed New Text

IPP> SEC - Security Issue - Proposed New Text

IPP> SEC - Security Issue - Proposed New Text

Manros, Carl-Uno B cmanros at cp10.es.xerox.com
Fri Apr 30 21:42:18 EDT 1999


Here are the new sections for the Model and Semantics document and the
Encoding and Transport on security.  All of the TLS discussion is being
moved to the Encoding and Transport document.  See below.
 

The new paragraphs for the Model and Semantics document are:
-----------------------------------------------------------

Section 5.1 Client Conformance, add:

A client MUST/SHOULD [which is to be determined in consultation with the
Area Director] support Client Authentication as defined in the IPP/1.1
Encoding and Transport document [ipp-pro].  A client SHOULD support
Operation Privacy and Server Authentication as defined in the IPP/1.1
Encoding and Transport document [ipp-pro].  See also [ipp-mod] section 8. 

Add a new sub-section to Section 5.2 IPP Object Conformance:

5.2.7 Security
An IPP Printer implementation MUST/SHOULD [which is to be determined in
consultation with the Area Director] contain support for Client
Authentication as defined in the IPP/1.1 Encoding and Transport document
[ipp-pro].  A Printer implementation MAY allow an administrator to configure
the Printer so that all, some, or none of the users are authenticated.  See
also [ipp-mod] section 8.

An IPP Printer implementation SHOULD contain support for Operation Privacy
and Server Authentication as defined in the IPP/1.1 Encoding and Transport
document [ipp-pro].  A Printer implementation MAY allow an administrator to
configure the degree of support for Operation Privacy and Server
Authentication.  See also [ipp-mod] section 8.
 

Revised text for the Encoding and Transport document:
--------------------------------------------------------

7. Security Considerations

The IPP Model and Semantics document [ipp-mod] discusses high level security
requirements (Client 
Authentication, Server Authentication and Operation Privacy).   Client
Authentication is the mechanism by 
which the client proves its identity to the server in a secure manner.
Server Authentication is the 
mechanism by which the server proves its identity to the client in a secure
manner.  Operation Privacy is 
defined as a mechanism for protecting operations from eavesdropping.
  
7.1 Security Conformance

IPP clients MUST/SHOULD [which is to be determined in consultation with the
Area Director] support 
both:
	Digest Authentication [rfc2069]. 
		MD5 and MD5-sess MUST be implemented and  supported. The
Message 
		Integrity feature NEED NOT be used.

	and

	Basic Authentication over a connection protected with TLS [rfc2068
and rfc2246].
 
		The TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite[rfc2246]
MUST be 
		implemented.  This is the mandatory cipher suite in TLS. All
other cipher suites are OPTIONAL.

IPP Printers MUST/SHOULD [which is to be determined in consultation with the
Area Director] support at 
least one of the two Client Authentication mechanisms.
  
The IPP Model and Semantics document defines two printer attributes
("uri-authentication-supported" and 
"uri-security-supported") that the client uses to discover the security
policy of a printer. That document also 
outlines IPP-specific security considerations and should be the primary
reference for security implications 
with regards to the IPP protocol itself.

For backward compatibility with IPP version 1.0, IPP clients and printers
MAY also support SSL3.  This is 
in addition to the security required in this document.

7.2 Using IPP with TLS

An initial IPP request never uses TLS. The switch to TLS occurs either
because the server grants the 
client's request to upgrade to TLS, or a server asks to switch to TLS in its
response. Secure communication 
begins with a server's response to switch to TLS. The initial connection is
not secure.  Any client expecting 
a secure connection should first use a non-sensitive operation (e.g. an HTTP
POST with an empty message 
body) to establish a secure connection before sending any sensitive data.
During the TLS handshake, the 
original session is preserved.
 
An IPP client that wants a secure connection MUST send "TLS/1.0" as one of
the field-values of the 
HTTP/1.1 Upgrade request header, e.g. "Upgrade: TLS/1.0" (see rfc2068
section 14.42). If the origin-
server grants the upgrade request, it MUST respond with "101 Switching
Protocols", and it MUST include 
the header "Upgrade: TLS/1.0" to indicate what it is switching to.  An IPP
client MUST be ready to react 
appropriately if the server does not grant the upgrade request. Note: the
'Upgrade header' mechanism 
allows unsecured and secured traffic to share the same port (in this case,
631).

With current technology, an IPP server can indicate that it wants an upgrade
only by returning "401 
unauthorized" or "403 forbidden".  A server MAY give the client an
additional hint by including an 
"Upgrade: TLS" header in the response. When an IPP client receives such a
response, it can perform the 
request again with an Upgrade header with the "TLS/1.0" value.

If a server supports TLS, it SHOULD include the "Upgrade" header with the
value "TLS/1.0" in response 
to any OPTIONS request.

Upgrade is a hop-by-hop header (rfc2068, section 13.5.1), so each
intervening proxy which supports TLS 
MUST also request the same version of TLS/1.0 on its subsequent request.
Furthermore, any caching proxy 
which supports TLS MUST NOT reply from its cache when TLS/1.0 has been
requested (although clients 
are still recommended to explicitly include "Cache-control: no-cache").

Note: proxy servers may be able to request or initiate a TLS-secured
connection, e.g. the outgoing or 
incoming firewall of a trusted subnetwork.

--

John Wenn, Bob Herriot, Carl-Uno Manros, Tom Hastings


 



More information about the Ipp mailing list