>>> "Carl-Uno Manros" <email@example.com> 04/30/99 09:48PM >>>
> 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.
> -----Original Message-----
> From: firstname.lastname@example.org [mailto:email@example.com] 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]
I would like to see a list of the issues we plan to present to the DA in =
Let's make sure it contains arguments/concerns he hasn't already addressed.=
> 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 =
> 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 =
> the Printer so that all, some, or none of the users are authenticated. =
> also [ipp-mod] section 8.
> An IPP Printer implementation SHOULD contain support for Operation =
> and Server Authentication as defined in the IPP/1.1 Encoding and =
> document [ipp-pro]. A Printer implementation MAY allow an administrator =
> 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 =
> requirements (Client Authentication, Server Authentication and Operation
> Privacy). Client Authentication is the mechanism by which the client =
> its identity to the server in a secure manner. Server Authentication is =
> mechanism by which the server proves its identity to the client in a =
> manner. Operation Privacy is defined as a mechanism for protecting
> from eavesdropping.
> 7.1 Security Conformance
> IPP clients MUST/SHOULD [which is to be determined in consultation with =
> Area Director] support both:
> Digest Authentication [rfc2069].
> MD5 and MD5-sess MUST be implemented and supported.
> The Message Integrity feature NEED NOT be used.
> Basic Authentication over a connection protected with TLS [rfc2068
> and rfc2246].
> The TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite =
> MUST be implemented. This is the mandatory cipher suite in =
> All other cipher suites are OPTIONAL.
We, Novell folks, have spent a fair deal of time studying this requirement =
and its implications,
since our meeting in New Orleans. We've taken a closer look at WebDAV and =
understand the direction in which the IETF and Internet technologies seem =
to be heading
in the area of security. We believe Digest Authentication to be an =
providing adequate authentication without imposing unreasonable demands =
for its implementation.
TLS, though a better technical option and one most security-conscious =
solutions are likely to=20
implement, may unduly delay the wide availability of fully-compliant IPP =
the requirement is placed on the client or printer). So, Novell is ready =
to endorse the decision
to require support for Digest Authentication in all IPP clients and =
printers and is willing to drop
its request that TLS be included as an option. Were there any other =
companies that wanted
TLS to be mandated in addition to or as an alternative to Digest Authentica=
> IPP Printers MUST/SHOULD [which is to be determined in consultation with =
> Area Director] support at least one of the two Client Authentication
> The IPP Model and Semantics document defines two printer attributes
> ("uri-authentication-supported" and "uri-security-supported") that the
> 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 =
> For backward compatibility with IPP version 1.0, IPP clients and =
> MAY also support SSL3. This is in addition to the security required in =
> 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
> asks to switch to TLS in its response. Secure communication begins with =
> server's response to switch to TLS. The initial connection is not =
> 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
> the original session is preserved.
> An IPP client that wants a secure connection MUST send "TLS/1.0" as one =
> 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
> request, it MUST respond with "101 Switching
> Protocols", and it MUST include the header "Upgrade: TLS/1.0" to =
> what it is switching to. An IPP client MUST be ready to react appropriat=
> if the server does not grant the upgrade request. Note: the 'Upgrade =
> mechanism allows unsecured and secured traffic to share the same port =
> this case, 631).
> With current technology, an IPP server can indicate that it wants an =
> only by returning "401 unauthorized" or "403 forbidden". A server MAY =
> the client an additional hint by including an "Upgrade: TLS" header in =
> response. When an IPP client receives such a response, it can perform =
> request again with an Upgrade header with the "TLS/1.0" value.
> The Message I
> If a server supports TLS, it SHOULD include the "Upgrade" header with =
> 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 =
> 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 =
> John Wenn, Bob Herriot, Carl-Uno Manros, Tom Hastings