Below is a rough draft of a security document. This will be discussed at the
next IPP Security conference call (5/8). Two tables didn't convert nicely to
text, they will be distributed later today (possibly pdf files on the web
site?).
The previous IETF draft on security dealt with security terms and standards.
This draft tries to address IPP security requirements and examines various
standard security protocols to see how they meet the requirements.
---------------------------------------------
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
deployed (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.
HHTP 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.
Comparison of technologies implementing object security
Technology Certification structure Scaleability Comments
S/MIME Hierarchies with roles of user and certifier formalized Scaleable from
small groups to large enterprises. Interoperability with focus on email.
PGP Key-ring or web-of-trust Small work groups only Specification and
application.
PEM Hierarchy Large enterprises. Not easy to scale downward RFC 1421-1424.
Cannot handle MIME - 7bit text only.
MOSS Hierarchy Scaleable. Not interoperable between different implementations
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.