May 5, 1997 Expires November 5, 1997 Internet Printing Protocol/1.0: Security Abstract This document is one of a set of documents which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing on the Internet. The protocol is heavily influenced by the printing model introduced in the Document Printing Application (ISO/IEC 10175 DPA) standard, which describes a distributed printing service. The full set of IPP documents includes: Internet Printing Protocol/1.0: Requirements Internet Printing Protocol/1.0: Model and Semantics Internet Printing Protocol/1.0: Security Internet Printing Protocol/1.0: Protocol Specification This document deals with the security considerations for IPP. Table of Contents 1.0 Introduction 2.0 Internet Printing Scenarios 2.1 Printing public documents on well known printers 2.2 Printing private documents on well known printers 2.3 Printing public documents on outside printers 2.4 Printing private documents on outside printers 2.5 Printing public documents by reference 3.0 Security Considerations of IPP Operations 3.1 Submit Job 3.2 Cancel Job 3.3 List Jobs 4.0 Security Solutions ------ 1.0 Introduction It is required that the Internet Printing Protocol be able to operate within a secure environment. Wherever possible, IPP ought to make use of existing security protocols and services. IPP will not invent new security features when the requirements described in this document can be met by existing protocols and services. Examples of such services include Secure Sockets (SSL), Digest Access Authentication in HTTP, and the Content MD-5 Header Field in MIME. 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 print data may be low enough that the corporation will choose to not use encryption on that data. However, if the connection between the client and the Printer 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 use of the protocol to the next. Printing payroll checks, for example, might have a different value than printing public information from a file. Since we cannot anticipate the security levels or the specific threats that any given IPP print administrator may be concerned with, 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. This document will describe the various scenarios within which IPP must operate. It will then describe the security concerns of the various IPP operations. Finally, it will describe the standard security solutions that can be used for addressing the requirements. 2.0 Internet Printing Scenarios The scenarios described here are those expected to be used in IPP 1.0. There are explicitly several possible arrangements that are outside the scope of the initial solution. The security needs of the IPP are derived from two considerations. First is how well known the server is to the client. An environment where the clients and servers are well known to each other does not need as strong authentication as clients and servers that are working together for the first time. Second is the sensitivity of the document. A public document does not need as strong privacy as a document with sensitive information. 2.1 Printing public documents on well known printers This scenario happens frequently. Printing public information on a well known printer (e.g. local or part of an intranet) has minimal security concerns. 2.2 Printing private documents on well known printers If one prints private information, the contents of the document should be protected. While the identity of the printer may be well known, the document must still guarded against such threats as eavesdropping. The strongest security requirement here is that of privacy. 2.3 Printing public documents on outside printers When the printer and client are not well known to each other, the security requirement of authentication is added. There are two sides to authentication, (1) client authentication - where the client authenticates itself to the printer. This is part of client authorization, where only authorized clients can use the printer resource. (2) printer authentication - this protects the client against others pretending to be the printer. Of the two, client authentication is almost always used, with printer authentication being the weaker requirement. 2.4 Printing private documents on outside printers Printing sensitive information on a printer not well known to the client requires full security. This means privacy of the document contents and mutual authentication between the client and printer. 2.5 Printing public documents by reference Another usage of IPP is print by reference. Here a reference (e.g. URL) of a document is given to the printer, and the printer retrieves the document. In 1.0, only public documents will be printed by reference. Printing by reference of private documents would require that the client grant the printer some authorization information that the printer could then use to retrieve the document. This granting of authorization is not currently implemented in the internet security infrastructure (although work in this area is going on). 3.0 Security Considerations of IPP Operations Various IPP operations have security concerns. They are Submit Job, Cancel Job and List Jobs. One aspect of IPP is that the servers for the three operations may be different, even when following the life of a single print job. This means that a security context may have to be established with each server independently. If the different operations occur on the same server, a security context may be reused between operations (if the underlying security mechanism allows long lived security contexts). 3.1 Print This was the basis of the previous security discussion. For submitting a print job, the issues of privacy of the document being transferred and the authentication of client with printer are all possible. 3.2 Cancel Job Cancel Job security is an authorization issue. Is the client in attempting the operation authorized to do so? To securely determine the answer, client authentication is a requirement. 3.3 Get Jobs Whether the Get Jobs operation has security implications depends on the policy set by the printer. One common policy is for the complete job queue is returned to anyone who asks. This policy has no security. For more secure printers, a common policy is to list the details only on the print jobs owned by the client, while giving little or no details about other jobs. This policy requires client authentication to match the client to the print jobs. 4.0 Security Solutions This section is an examination of potential security solutions. As described in the introduction, these are all existing security protocols. It should be noted that the final security solutions chosen depends on the final IPP protocol. Not all of the potential solutions are applicable to all the IPP protocol choices. The security needs of the scenarios discussed in section two can be divided into the following categories. 1) no security (sections 2.1 and 2.5) 2) privacy only (section 2.2) 3) client authentication and authorization (section 2.3) 4) complete security, meaning mutual authentication, authorization and privacy (section 2.4) Category 1 If the client wants no security, it can send the print job, i.e., the job content and the job attributes to the printer direct. The printer will print the job for the client. Cases where there is no need for security or where security is difficult to obtain include the print by reference URL. Category 2 If the client needs privacy only, client could use PGP with the key ring, with probably one key in the ring. This key is used to encrypt a session key that could be used for privacy. S/MIME could also be used. S/MIME requires sender's authentication and may well fall into the third category. For channel only security, one could use SSL2, but this requires client authentication and may well fall into the third category. However, if a password is sent in the clear to the lower security layer that does encryption, one could use S/MIME or SSL2 or SSL3 or TLS. Category 3 The third category requires one sided authentication that is also used for authorization. The password in fact is used for authorization purposes, and is encrypted by the lower security layer. S/MIME and SSL2 are good examples. TLS supports both one sided and mutual authentication and can also be used for this category. Category 4 The fourth category requires mutual authentication, integrity, and privacy. Although, S/MIME provides all except mutual authentication, and two way mail can provide mutual authentication, we leave S/MIME into the third category. TLS and SSL3 are good channel level security providers in this category. A protocol selection should be made by IPP depending upon the security level section made by the client, and the right hand shake messages should be passed. Based on the key information on either side, job information including content and attributes are encrypted and send either using object security or channel security. For knowing the status of the job, or for performing more operations on the job, the session identifier could be reused if the call needs to be made to the same server. Otherwise the whole set of selections needs to be made, the security level can be inherited from the job submission or made independently. Event notification about the completion of the job can be made either securely, or need not have any security at all. The security features for this can be decided at the job submission time in the IPP protocol. (Carl-Uno: HOW, do we need an extra attribute for this?) ---- Security in IPP - Comparison of underlying technologies ------------------------------------------------------- [Table 1 here] Summary of the findings about security service applicability for IPP: TLS - Transport Layer Security: Seems OK, is near completion in the IETF and existing SSL product are probably compliant, or can be made compliant without much effort. SSL 2 and SSL 3 - Secure Socket Layer: Proprietary solution initially by Netscape, but TLS is very close. Cannot be used as reference in an IETF RFC. PGP/MIME - Pretty Good Privacy MIME variant: The original PGP is widely available (but not much liked by the US government). The PGP/MIME version is now being worked on but is still not out, not yet stable, and not yet implemented and deployed. Timing problem. S/MIME - Secure MIME: Currently a private implementation from RSA. Although coming out as product from a number of vendors, unlikely to make it on the IETF standards track unless RSA decides to release their proprietary products as open standards. This is unlikely to happen in the time frame that we need. SASL - Simple Authentication and Session Layer: This seems to be winning mind share in the IETF, but is really only a security feature negotiation protocol and does not provide any security services in itself. Hence quite limited usefulness. Also it is too new to be finished in the time frame that we need, it is not yet even an Internet-Draft from a WG. HTTP 1.1 Security Extensions, RFC 2069: This provides some limited security services, mainly only client side authentication. Security specialists frown upon this solution because it uses unencrypted user names and passwords. However, this solution could be used in combination with a protocol that provides for secure transport. SHTTP - Secure HTTP: Although on the IETF standards track, this seems to lack some important features and does not seem to go anywhere in the market place. ---- Security types for transmitting documents ----------------------------------------- There are two types of security that could be used for transmitting documents securely: channel security and object security. In the former case, the transmission medium is made secure by mutual authentication, and encrypting everything between the client and server by the transmission medium. The transmission medium can be any of the following: transport layer (SSL), network layer (IPV6) or higher layers (secure FTP or Telnet). In the latter case of object security, each object is encrypted and sent over either a secure or an insecure channel. The recipient has the corresponding key to decrypt the object and get the contents. Most of the widely used object security mechanisms are S/MIME and PGP/MIME which are email systems. From table 1, all rows except those corresponding to S/MIME and PGP/MIME provide channel security. (Table 1 here) Comparison of technologies implementing object security ------------------------------------------------------- (Table 2 here) Specific features of various technologies: S/MIME: (Secure/Multipurpose Internet Mail Extensions) Security services and features offered: a. Sender Authentication is provided using digital signatures. The recipient reads the sender's digital signature. Non-repudiation of origin is also achieved using digital signatures. b. Privacy (using encryption). c. Integrity is achieved by using hashing to detect message tampering. d. Provides anonymity by using anonymous e-mailers and gateways. The digital signature and the original message are placed in an encrypted digital envelope. e. Supports DES, Triple-DES, RC2. f. X.509 digital certificates supported. g. Supports PKCS #7(cryptographic message formatting, architecture for certificate-based key management) and #10(message for certification request). Usage, implementation and interoperability: a. Used to securely transmit e-mail messages in MIME format. b. Public domain mailer RIPEM available. c. RSA's toolkit TIPEM (Toolkit for Interoperable Privacy Enhanced Messaging) can be used to build S/MIME clients. It includes C object code for digital envelopes, digital signatures and digital certificate operations. d. Any two packages that implement S/MIME can communicate securely. e. Compatible with IMAP (Internet Message Access Protocol - RFC 1730). f. S/MIME works both on the Internet or any other e-mail environment. Transport Layer Security 1.0 (TLS) TLS is a two layered protocol. The lower level TLS Record Protocol that sits on top of TCP and the TLS Handshake Protocol. The TLS Handshake protocol consists of a suite of three sub protocols which are used to allow peers to agree upon security parameters for the record layer, authenticate themselves, instantiate negotiated security parameters, and report error conditions to each other. TLS is application protocol independent. It is based on SSL v3. Security services and features offered: a. Privacy: (optional). Uses symmetric keys. Encryption done by the TLS Record Protocol. The keys are generated for each connection by the TLS Handshake Protocol. b. Integrity: Using keyed MAC. Hash functions (SHA, MD5) are used for MAC computations. c. Authentication (Both one-sided and Mutual): The TLS Handshake Protocol uses public key cryptography. Encryption algorithms are negotiated. Usage, implementation and interoperability: a. Interoperability: Independent applications can be developed utilizing TLS and successfully exchange cryptographic parameters without knowledge of each others code. Cannot interoperate with SSL 3.0 b. Extensibility: New encryption methods can be incorporated as necessary. c. Efficiency: To reduce the number of sessions that need to be established from scratch, TLS provides session caching scheme. d. Other operations: Compression, fragmentation is done by the TLS Record Protocol. Handshake protocol steps: 1. Exchange hello messages to agree on algorithms, exchange random values, and check for session resumption. 2. Exchange the necessary cryptographic parameters to allow the client and server to agree on a premaster secret. 3. Exchange certificates and cryptographic information to allow the client and server to authenticate themselves. 4. Generate a master secret from the premaster secret and exchanged random values. 5. Provide security parameters to the record layer. 6. Allow the client and server to verify that their peer has calculated the same security parameters and that the handshake occurred without tampering by an attacker. [Table 3 here] Note: The https protocol uses port 443 regardless of which security protocol it is using. ----