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=85..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.=20
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: manros@cp10.es.xerox.com