The line breaks looked so fine when I sent them off.
Here a tidied up, somewhat easier to read, version.
This is the dry standards text. We could add a little more background
in the IIG, to help implementers decide which alternative security
option to choose for a printer.
Carl-Uno
-----Original Message-----
From: owner-ipp@pwg.org [mailto:owner-ipp@pwg.org] On Behalf Of Manros,
Carl-Uno B
Sent: Friday, April 30, 1999 6:42 PM
To: IETF-IPP
Subject: IPP> SEC - Security Issue - Proposed New Text
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