>>> "Carl-Uno Manros" <carl@manros.com> 04/30/99 09:48PM >>>
> Sigh,
>
> 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]
I would like to see a list of the issues we plan to present to the DA in =
Philadelphia.
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 =
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.
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 =
tried to=20
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 =
acceptable compromise,
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 =
implementations (whether
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=
tion?
>
> 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 appropriat=
ely
> 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.
>Id.
> The Message I
> 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.
>=20
> --
>=20
> John Wenn, Bob Herriot, Carl-Uno Manros, Tom Hastings
>=20