FW: IPP> SEC - Security Issue - Proposed New Text

FW: IPP> SEC - Security Issue - Proposed New Text

FW: IPP> SEC - Security Issue - Proposed New Text

Hugo Parra HPARRA at novell.com
Sat May 1 02:33:47 EDT 1999


I've inserted some comments in the text below.
-Hugo

>>> "Carl-Uno Manros" <carl at 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 at pwg.org [mailto:owner-ipp at 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 
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 
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 Authentication?

>
> 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.
>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.
> 
> --
> 
> John Wenn, Bob Herriot, Carl-Uno Manros, Tom Hastings
> 



More information about the Ipp mailing list