This proposal introduces a method for IPP to utilize Transport Layer Security (TLS) as a security encapsulation for the Internet Printing Protocol. Specifically, the charter for the IPP working group includes the following paragraph:

The IPP requirements document also includes a number of scenarios wherein security is or could be required. In order to fulfill the requirements of the charter, the IPP working group must completely specify, end to end, how IPP documents can be transmitted securely, and how IPP clients can be successfully authenticated.

Because we are designing a printing model to work within both intranet and internet environments, the protocol must include the union of features required for both environments.

This proposal puts forth a predicate that says any sustainable protocol designed for information flow over the internet MUST have the ability to support authentication and privacy. Note that this predicate does not REQUIRE the use of these secure methods for ALL traffic. However, the ABILITY of the protocol to enter into a secure mode MUST be supported.

The following IPP security scenarios will describe how IPP security mechanisms should be applied.

Also, the following scenarios assume that within a particular IPP security session, digest authentication of all IPP message traffic is performed. Therefore, the minimally negotiated security for IPP/TLS sessions would be to use MD5 message digest. Note that these scenarios only point out the more typical scenarios; other scenarios are also possible and not precluded by the methods proposed in this document.

TLS supports both privacy and authentication, as required by the IPP charter. The initial specification includes both symmetrical and asymmetrical encryption algorithms, as well as authentication by means of digital certificates. TLS specifies an encapsulation on all transport messages. While TLS will be initially implemented over TCP, the design of the protocol, and the specification itself, do not preclude use of TLS on other transport/network protocols other than TCP. Prior to full deployment of TLS within the existing internet, the use of SSL3 is allowed in order to expedite deployment of IPP services. The TLS specification includes methods for compatibility with existing SSL3 clients and servers. Use of the TLS-SSL3 compatibility mode in no way sacrifices either the privacy or authentication features of the protocol.

In a typical client-requested security model, the client wishes to encrypt the data that is to be transported using IPP. Within the TLS specification, several encryption methods are supported. It is possible that some servers might impose privacy for IPP objects, but it is unlikely due to the fact that the server has no knowledge of the sensitivity of the document(s) to be printed. This is true also in the print-by-reference case. One other interesting scenario includes the case wherein a client has specified a print-by-reference document and the reference URI contains an HTTPS scheme. In this scenario, it would be nice if the server could assume the identity of the original client (using information derived from the client's authentication) to access the remote document. Again, using a standard security mechanism like TLS allows this type of interoperability.

In the client-requested security, the user would contact the IPP server and negotiate "up" to the level of security required by the client. If the server cannot support the level of security required by the client, the session is terminated.

An example of high-level protocol interactions, using IPP over HTTP, would be as follows:

In the server-imposed security model, the server will usually require that a potential client authenticate itself to gain access to an IPP printer resource. Subsequently, the authenticated user ID might be validated against an access control list (ACL) or by some other means to see if the requesting user has access rights to the IPP printer. In a typical case, using TLS, the user would be required to present a digital signature or certificate of some kind. If the server cannot authenticate the client, the session is terminated.

The sequence of protocol interactions is similar to Scenario 1, with the exception in step #4 wherein the server will initiate session termination if the client cannot be authenticated.

There are a couple of issues involved with multiple URI strings to differentiate secure and non-secure IPP servers. In Scenario 1, the client must somehow discover the secure URI of the printer before starting the print job. The client can use one of two methods to do this:

In any URI scheme (HTTP or some future transport), if IPP servers can optionally support TLS framing, then there will always be a need to define not only a new transport scheme for every new transport mapping, but also a "secure" version of the scheme so that clients can determine whether or not a particular IPP URI is secure or not. This requirement could be relaxed in a strict directory service discovery mode since we would always have the attribute that indicates whether or not a particular printer URI is secure. But we would still need to define both secure and non-secure URI schemes for environments not served by a directory service.

There is one possible exception to the requirement for secure and non-secure URIs, and that is to define specific URI port numbers that indicate secure and non-secure IPP printers. For example, using HTTP as an IPP transport, secure and non-secure URIs could be identified by either of the following methods:

Other transport-specific schemes may or may not have built-in rules to determine whether or not a particular connection would be secure or non-secure. Once the IPP infrastructure is in place, clients will always have to deal with the possibility of secure and non-secure URI strings, for all transports.

Another possible interoperability problem exists because most of the time, end users will not realize the security implications of particular URIs, without help from a directory service.

Using a single URI for IPP printer services is easier for end users and deployment of IPP services. The impact of supporting TLS framing on all IPP clients and servers benefits interoperability at the expense of additional code on the part of developers. The IPP working group should carefully determine which group, end users or developers, we are trying to satisfy.

Keith Moore, IETF area director for applications, has stated that the current TLS draft (04) will complete working group last call on 11/6/97. The IESG had issues with the previous draft (03) that have since been cleaned up. Keith has predicted that all of the issues with the IESG have been addressed, and that TLS should be at "proposed" status in time for IPP to reference the TLS RFC (when published).

There are a number of alternatives to TLS that could be considered for future IPP deployment. Only some of which are described below:

Transport-specific Security

Initial implementations of IPP will utilize the Hypertext Transfer Protocol (HTTP) Version 1.1 for transporting IPP messages. HTTP 1.1 includes built-in methods for a minimally secure environment. These include "basic" authentication and MD5 digest authentication. Neither of these methods support the security requirements set forth in the charter, and in certain IPP scenarios described in the IPP Requirements Document. HTTP Basic Authentication utilizes usernames and passwords that are passed over the network, in clear text form, which could be discovered by "snooping" the network. HTTP Digest Authentication only verifies that a particular HTTP operation has not been modified in route from source to destination. Neither of these methods provides support for privacy via encryption methods.

IP Security (IPSEC)

IP Security solves the privacy requirements for IPP, but not necessarily the authentication requirements. A cursory examination of RFC 1825("Security Architecture for the Internet Protocol") suggests that IPSEC is being designed to authenticate one IP host to another host or gateway. IPP authentication seeks to identify individual IPP client users or IPP server implementations. Also, the schedule for IPSEC deployment is unclear and potentially requires large scale changes in current IP infrastructure (IP tunnels not withstanding).

Secure MIME (S/MIME)

Up until recently, RSA, Inc. had not released patented technology regarding public key technology to the IETF. S/MIME has recently gained more attention by offering a non-discriminatory (no-cost) license to firms implementing S/MIME capable applications. Also, as a side topic, the patent for Diffie-Hellman encryption has expired. S/MIME offers more advantages to the email infrastructure due to the fact that no re-architecture of the current SMTP mail infrastructure would be required to implement S/MIME. For IPP, S/MIME offers no advantages over TLS, at least with regards to transport security.

Anytime optional capabilities are introduced into a protocol model, it opens up opportunities for points of diversion in implementations, which can lead to non-interoperability. This proposal suggests TLS as the only method by which IPP implementations meet the security requirements set forth in the IPP charter and requirements document. Whether or not the working group decides to use TLS exclusively on all client and server implementations is secondary to the goal of selecting only one security model. At the same time, we should try to focus on ease of deployment and maximizing interoperability between various implementations. It is in this spirit that this proposal emphasizes the use of TLS for all implementations, with negotiated levels of security depending upon the needs of clients and the requirements of servers.