All,
Hugo Parra suggested to the DL that we go back to an earlier proposal
for security, which limits the client authentication to be Digest for
both IPP clients and IPP Printers. In our phone conference last Wednesday,
his proposal was supported by several other people, and I was given the
task to get a new version of the proposed security sections to reflect
this.
After consultation with John Wenn, we now have a revised version. The
new text does not change anything from last week's proposal for the
Model document, but has a few changes for the Encoding & Transport
document. This is the text that we now plan to put into our next
IPP/1.1 drafts which will be ready early next week.
I have duplicated the conformance text for Digest between clients
and Printers on purpose, just in case we end up with different
wording for clients and Printers after our discussion with Keith
in Philadelphia.
BTW, it may not be known to everybody yet, that we now have an OK
from Keith that he will phone in to the next IPP meeting for one
last discussion of security and any other IPP/1.1 issues that might
still be open come last week of May.
==============
The new paragraphs for the Model and Semantics document are:
(no changes from previous version sent to the DL)
-----------------------------------------------------------
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:
Digest Authentication [rfc2069].
MD5 and MD5-sess MUST be implemented and supported.
The Message Integrity feature NEED NOT be used.
IPP Printers MUST/SHOULD [which is to be determined in consultation with the
Area Director] support:
Digest Authentication [rfc2069].
MD5 and MD5-sess MUST be implemented and supported.
The Message Integrity feature NEED NOT be used.
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.
If TLS is used, 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.
If TLS is used to provide a secure channel for communication between an
IPP client and an IPP Printer, the Basic Authentication described in
HTTP/1.1
(see rfc 2068) or the Digest Authentication (see rfc 2069) MAY also be used.
--
John Wenn, Bob Herriot, Carl-Uno Manros, Tom Hastings
Carl-Uno Manros
Principal Engineer - Xerox Architecture Center - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: manros at cp10.es.xerox.com