Hugo,
Thanks for your comments. I am pleased to hear that people are now taking it
serious to make real estimates of the costs and efforts to implement a
minimum security option.
I have no objection to switching back to require only Digest for both
Clients and Printers, which would still fulfill the minimum requirements
from the IETF, as long as we can get everybody agreed on it.
Did you come up with any footprint figure for Digest?
Carl-Uno
> -----Original Message-----
> From: Hugo Parra [mailto:HPARRA at novell.com]
> Sent: Friday, April 30, 1999 11:34 PM
> To: carl at manros.com; ipp at pwg.org> Subject: Re: FW: IPP> SEC - Security Issue - Proposed New Text
>>> 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
> >
>