Subject: IPP> SEC - Draft document prereading for IPP Security phone conference

From: John Wenn <[email-masked]>
Date: Wed, 7 May 1997 04:54:10 PDT

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.

---

From: "Scott Lawrence" <[email-masked]>
Date: Mon, 12 May 1997 16:31:15 -0400

SEC> RFC 2069: This provides some limited security services, mainly
SEC> only client side authentication.  Security specialists frown upon
SEC> this solution because it uses unencrypted user names and
SEC> passwords.  However, this solution could be used in combination
SEC> with a protocol that provides for secure transport.

  RFC 2069 does not transmit user names or passwords in any form - put
  simply, it transmits a cryptographic digest derived from the
  username, password, and a server generated challenge.  The
  authentication derives from the fact that the client cannot generate
  it correctly without knowing the user credentials.

SEC> SHTTP - Secure HTTP: Although on the IETF standards track, this
SEC> seems to lack some important features and does not seem to go
SEC> anywhere in the market place.

  Actually, I believe that it provides everything IPP would need
  (including non-repudiation - a service that has received too little
  attention), but it is true that it may not be getting enough support
  from the marketplace and doesn't seem to enjoy support in the IESG
  (I don't know why not).

--
Scott Lawrence           EmWeb Embedded Server       <[email-masked]>
Agranat Systems, Inc.        Engineering            http://www.agranat.com/