Subject: IPP> MOD - Randy's proposal in ASCII

From: Carl-Uno Manros <[email-masked]>
Date: Sun, 2 Nov 1997 02:23:47 PST

To comply with the IETF rules, I give you the content of Randy's recent
security text in ASCII below.

Carl-Uno

---

Proposed Changes to IPP Model Document Security Sections

[Proposal: I would like to move section 8 (Security Considerations) to
section 3.5 and only have one "Security Considerations" section in the
document.  Having this section earlier in the document would also make
sense due to the numerous places in the remainder of the document that, at
the moment, "forward" references security details. This would make the
model document easier to read, without scattering security information all
over different places. This document contains proposed content for the
combined section…..comments?]

[Proposal: Also, I would like to eliminate the REQUIREMENT that IPP over
HTTP support RFC 2069 or basic authentication. This would be keeping our
current philosophy with implementations NOT required to implement security]

3.1.5	Security Considerations

IPP implementations can be explicitly "secure" or "non-secure". Within the
context of this document, a "secure" implementation is one that utilizes a
transport layer that supports Transport Layer Security (TLS) Version 1.0. A
"non-secure" implementation may or may not support security. A "non-secure"
implementation MAY elect to support a transport layer that provides
inherent security mechanisms (such as HTTP). Secure IPP implementations are
capable of supporting mutual authentication as well as privacy of messages
via multiple encryption schemes.

It is difficult to anticipate the security risks that might exist in any
given IPP environment. For example, if IPP is used within a given
corporation over a private network, the risks of exposing document data may
be low enough that the corporation will choose not to use encryption on
that data.  However, if the connection between the client and the IPP
object is over a public network, the client may wish to protect the content
of the information during transmission through the network with encryption.

Furthermore, the value of the information being printed may vary from one
IPP environment to the next. Printing payroll checks, for example, would
have a different value than printing public information from a file.  There
is also the possibly of denial-of-service attacks, but denial-of-service
attacks against printing resources are not well understood and there is no
published precedents regarding this scenario
3.1.5.1 Authenticated Clients

An IPP server MAY utilize Transport Layer Security (TLS) that, among other
things, supplies the credentials of a client. Once the authenticated
identity of the requester has been supplied to the IPP implementation, the
implementation uses that identity to enforce any authorization policy that
might be in place.  An important point about security related information
is that, for a "secure" IPP server, the security-related parameters
(authentication, encryption keys, etc.) are "out-of-band" to the actual IPP
protocol. During a create-job operation, the client's credentials are
recorded in the Job object in an implementation-defined attribute. This
information can be used to verify a client's identity for subsequent
operations on that Job object in order to enforce any access control policy
that might be in effect. For example, one site's policy might be that only
the job owner is allowed to cancel a job. There are operation status codes
that allow an IPP server to return information back to a client about any
potential access control violations for an IPP object.

The details and mechanisms to set up a particular access control policy are
not part of IPP/1.0, and must be established via some other type of
administrative or access control framework

Since the security levels or the specific threats that any given IPP system
administrator may be concerned with cannot be anticipated, IPP MUST be
capable of operating with different security mechanisms and security
policies as required by the individual installation. Security policies
might vary from very strong, to very weak, to none at all, and
corresponding security mechanisms will be required. TLS Version 1.0
supports the type of negotiated levels of security required by most, if not
all, potential IPP environments. IPP environments that require no security
can elect to deploy IPP implementations that do not utilize the optional
TLS security mechanisms.

The following sections describe specific security attacks for IPP
environments.  Where examples are provided they should be considered
illustrative of the environment and not an exhaustive set. Not all of these
environments will necessarily be addressed in initial implementations of IPP.

3.1.5.1 Client and Server in the Same Security Domain

This environment is typical of internal networks where traditional office
workers print the output of personal productivity applications on shared
work-group printers, or where batch applications print their output on
large production printers. Although the identity of the user may be trusted
in this environment, a user might want to protect the content of a document
against such attacks as eavesdropping, replaying or tampering.

3.1.5.2 Client and Server in Different Security Domains

Examples of this environment include printing a document created by the
client on a publicly available printer, such as at a commercial print shop;
or printing a document remotely on a business associates's printer. This
latter operation is functionally equivalent to sending the document to the
business associate as a facsimile. Printing sensitive information on a
Printer in a different security domain requires strong security measures.
In this environment authentication of the printer is required as well as
protection against unauthorized use of print resources. Since the document
crosses security domains, protection against eavesdropping and document
tampering are also required. It will also be important in this environment
to protect Printers against "spamming" and malicious document content.

3.1.5.3 Print by Reference

When the document is not stored on the client, printing can be done by
reference. That is, the print request can contain a reference, or pointer,
to the document instead of the actual document itself. Standard methods
currently do not exist for remote entities to "assume" the credentials of a
client for forwarding requests to a 3rd party. It is anticipated that
Print-By-Reference will be used to access "public" documents and that
sophisticated methods for authenticating "proxies" will not be required for
version 1 of IPP.

3.1.5.4 The "requesting-user-name" Operation Attribute

An IPP server SHALL support the MANDATORY "requesting-user-name" operation
attribute. The client SHOULD include this attribute in all appropriate IPP
operations. Non-secure IPP servers MAY use the requesting-user-name
attribute to apply simple access control for IPP operations. An IPP client
implementation SHALL obtain the value for this attribute from an
environmental or network login name for the user, rather than allowing the
user to supply any value through a user interface mechanism. 

For create-job requests the Printer object, upon creating a new Job object,
SHALL store the originating user's name in the MANDATORY "job
originating-user-name" Job Description attribute.  The
"job-originating-user-name" attribute is used for presentation only, such
as returning in queries or printing on job separator pages. If no transport
layer security exists, non-secure IPP servers MAY utilize the
"originating-user-name" and "requesting-user-name" to enable simple access
control to IPP objects. If some type of transport layer authentication is
available, then transport layer authentication MUST be used. Transport
layer authentication can be provided by a fully secure TLS IPP
implementation, or through some non-IPP standard form of transport
authentication provided by protocols such as HTTP 1.1.

3.1.5.5 Restricted Queries

In many IPP operations, a client supplies a list of attributes to be
returned in the response.  For security reasons, an IPP object may be
configured not to return all attributes that a client requests.  The job
attributes returned MAY depend on whether the requesting user is the same
as the user that submitted the job. The IPP object MAY even return none of
the requested attributes. In such cases, the status returned is the same as
if the object had returned all requested attributes.  The client cannot
tell by such a response whether the requested attribute was present or
absent on the object.

Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: [email-masked]

---

From: [email-masked] (Ira Mcdonald x10962)
Date: Mon, 24 Nov 1997 17:42:41 PST

Hi Carl-Uno,

Thanks!  In addition to complying with IETF working group rules,
it let's those of us without MS Word see Randy's proposal.

Cheers,
- Ira McDonald