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