draft-ietf-ipp-security-00.txt   draft-ietf-ipp-security-01.txt 
skipping to change at page 1, line 14 skipping to change at page 1, line 14
Roger deBry Roger deBry
IBM Corporation IBM Corporation
Jerry Hadsell Jerry Hadsell
IBM Corporation IBM Corporation
Daniel Manchala Daniel Manchala
Xerox Corporation Xerox Corporation
Xavier Riley Xavier Riley
Xerox Corporation Xerox Corporation
John Wenn John Wenn
Xerox Corporation Xerox Corporation
June 12, 1997 July 29, 1997
Internet Printing Protocol/1.0: Security Internet Printing Protocol/1.0: Security
draft-ietf-ipp-security-00.txt draft-ietf-ipp-security-01.txt
Status of this memo Status of this memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts. Internet-Drafts distribute working documents as Internet-Drafts. Internet-Drafts
are draft documents valid for a maximum of six months and may be are draft documents valid for a maximum of six months and may be
updated, replaced, or obsoleted by other documents at any time. updated, replaced, or obsoleted by other documents at any time.
It is inappropriate to use Internet-Drafts as reference material It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress." or to cite them other than as "work in progress."
To learn the current status of any Internet-Draft, please check To learn the current status of any Internet-Draft, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net
(Europe), (Europe) munnari.oz.au (Pacific Rim), ds.internic.net (US East
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or Coast), or ftp.isi.edu (US West Coast).
ftp.isi.edu (US West Coast).
Abstract Abstract
This document is one of a set of documents which together This document is one of a set of documents which together
describe all aspects of a new Internet Printing Protocol (IPP). describe all aspects of a new Internet Printing Protocol (IPP).
IPP is an application level protocol that can be used for IPP is an application level protocol that can be used for
distributed printing on the Internet. The protocol is heavily distributed printing on the Internet. The protocol is heavily
influenced by the printing model introduced in the Document influenced by the printing model introduced in the Document
Printing Application (ISO/IEC 10175 DPA) standard, which Printing Application (ISO/IEC 10175 DPA) standard, which
Expires December 12, 1997
Expires January 29, 1998
describes a distributed printing service. The full set of IPP describes a distributed printing service. The full set of IPP
documents includes: documents includes:
Internet Printing Protocol/1.0: Requirements Requirements for an Internet Printing Protocol
Internet Printing Protocol/1.0: Model and Semantics Internet Printing Protocol/1.0: Model and Semantics
Internet Printing Protocol/1.0: Security Internet Printing Protocol/1.0: Security
Internet Printing Protocol/1.0: Protocol Specification Internet Printing Protocol/1.0: Protocol Specification
Internet Printing Protocol/1.0: Directory Schema Internet Printing Protocol/1.0: Directory Schema
This documentis the `Internet Printing Protocol/1.0: Security' This documentis the `Internet Printing Protocol/1.0: Security'
document. document.
Expires December 12, 1997 Expires January 29, 1998
Table of Contents Table of Contents
1.0 Introduction .........................................4 1.0 Introduction .........................................4
2.0 Security Threats and Attacks .........................4 2.0 Security Threats and Attacks .........................5
2.1 Threats ...........................................5 2.1 Threats ...........................................5
2.2 Methods of Attack .................................5 2.2 Methods of Attack .................................5
3.0 Internet Printing ....................................6 3.0 Internet Printing Environments........................6
3.1 Printer and Client in the Same Security Domain ....7 3.1 Printer and Client in the Same Security Domain ....7
3.2 Printer and client in Different Security Domains ..7 3.2 Printer and client in Different Security Domains ..7
3.3 Print-by-Reference ................................7 3.3 Print-by-Reference ................................7
3.3.1 Unprotected Documents ........................8 3.3.1 Unprotected Documents ........................8
3.3.2 Protected Documents ..........................8 3.3.2 Protected Documents ..........................8
3.4 Common Security Scenarios .........................8 3.4 Common Security Scenarios .........................8
3.4.1 No Security ..................................8 3.4.1 No Security ..................................8
3.4.2 Message Protection During Transmission .......8 3.4.2 Message Protection During Transmission .......9
3.4.3 Client Authentication and Authorization ......9 3.4.3 Client Authentication and Authorization ......9
3.4.4 Mutual Authentication, Authorization and Message 3.4.4 Mutual Authentication, Authorization and Message
Protection ...................................9 Protection ...................................9
4.0 Security Services ....................................9 4.0 Security Services ....................................9
5.0 Applying security to IPP operations .................10 5.0 Applying security to IPP operations .................11
5.1 Create-Job .......................................11 5.1 Create-Job .......................................11
5.2 Send-Document ....................................11 5.2 Send-Document ....................................11
5.3 Print-Job ........................................11 5.3 Print-Job ........................................11
5.4 Cancel-Job .......................................11 5.4 Cancel-Job .......................................12
5.5 Validate .........................................12 5.5 Validate .........................................12
5.6 Get-Jobs .........................................12 5.6 Get-Jobs .........................................12
5.7 Get-Attributes ...................................12 5.7 Get-Attributes ...................................12
5.8 Print-URI ........................................12 5.8 Print-URI ........................................12
5.9 Send-URI .........................................12 5.9 Send-URI .........................................12
6.0 Comments on Existing Security Technologies ..........12 5.10 Get-Operations...................................13
6.1 Recommended Security Mechanisms ..................14 5.11 Asynchronous Notification .......................13
7.0 Appendix - Specific Features of Various Technologies 15 6.0 Comments on Existing Security Technologies ..........13
7.1 S/MIME: (Secure/Multipurpose Internet Mail Ext.)..15 6.1 Recommended Security Mechanisms ....................14
7.2 Transport Layer Security 1.0 (TLS) ...............15 6.2 Firewall Consideration..............................15
7.3 SASL (Simple Authentication and Security Layer) ..16 7.0 References ..........................................17
7.4 Digest Access Authentication .....................17 8.0 Authors' Addresses ..................................18
8.0 References ..........................................20
9.0 Authors' Addresses ..................................21
Expires December 12, 1997 Expires January 29, 1998
1.0 Introduction 1.0 Introduction
The purpose of this document is to describe security The purpose of this document is to describe security
considerations for the Internet Printing Protocol (IPP). Internet considerations for the Internet Printing Protocol (IPP). Internet
Printing is the application of Internet technology to network Printing is the application of Internet technology to network
printing. Using Internet technology, users want to be able to printing. Using Internet technology, users want to be able to
locate printers, install and configure printer software, query locate printers, install and configure printer software, query
printers for capabilities and status, and submit and track print printers for capabilities and status, and submit and track print
jobs. The Internet Printing Protocol defines the network jobs. The Internet Printing Protocol defines the network
interface for many of these functions. interface for many of these functions.
It is required that the Internet Printing Protocol be able to It is required that the Internet Printing Protocol be able to
operate within a secure environment. Wherever possible, IPP ought operate within a secure environment. Wherever possible, IPP ought
to make use of existing security protocols and services. IPP will to make use of existing security protocols and services. IPP will
not invent new security features when the requirements described not invent new security features when the requirements described
in this document can be met by existing protocols and services. in this document can be met by existing protocols and services.
Examples of such services include Transport Layer Security Examples of such services include Transport Layer Security
(TLS)[draft-tls] and Digest Access Authentication [rfc2069]in (TLS)[1] and Basic Authentication[2] and Digest Access
HTTP. Authentication[3]in HTTP.
It is difficult to anticipate the security risks that might exist It is difficult to anticipate the security risks that might exist
in any given IPP environment. For example, if IPP is used within in any given IPP environment. For example, if IPP is used within
a given corporation over a private network, the risks of a given corporation over a private network, the risks of
exposing print data may be low enough that the corporation will exposing print data may be low enough that the corporation will
choose not to use encryption on that data. However, if the choose not to use encryption on that data. However, if the
connection between the client and the Printer is over a public connection between the client and the Printer is over a public
network, the client may wish to protect the content of the network, the client may wish to protect the content of the
information during transmission through the network with information during transmission through the network with
encryption. encryption.
skipping to change at page 4, line 49 skipping to change at page 5, line 5
public information from a file. public information from a file.
Since we cannot anticipate the security levels or the specific Since we cannot anticipate the security levels or the specific
threats that any given IPP print administrator may be concerned threats that any given IPP print administrator may be concerned
with, IPP must be capable of operating with different security with, IPP must be capable of operating with different security
mechanisms and security policies as required by the individual mechanisms and security policies as required by the individual
installation. Security policies might vary from very strong, to installation. Security policies might vary from very strong, to
very weak, to none at all, and corresponding security mechanisms very weak, to none at all, and corresponding security mechanisms
will be required. will be required.
Expires January 29, 1998
2.0 Security Threats and Attacks 2.0 Security Threats and Attacks
Expires December 12, 1997
Before discussing security services specifically as they relate Before discussing security services specifically as they relate
to IPP, it will be useful to quickly discuss and categorize to IPP, it will be useful to quickly discuss and categorize
security threats in a general way and discuss the means by which security threats in a general way and discuss the means by which
these threats are carried out. these threats are carried out.
2.1 Threats 2.1 Threats
Security threats fall into the following broad categories: Security threats fall into the following broad categories:
Resource stealing: The unauthorized use of facilities, such as Resource stealing: The unauthorized use of facilities, such as
skipping to change at page 6, line 5 skipping to change at page 6, line 5
capability after the authorization to use it has expired. capability after the authorization to use it has expired.
Eavesdropping: Obtaining copies of documents and job instructions Eavesdropping: Obtaining copies of documents and job instructions
without authority, either directly from the network or by without authority, either directly from the network or by
examining information that is inadequately protected in storage. examining information that is inadequately protected in storage.
Document tampering: Intercepting documents or other print job Document tampering: Intercepting documents or other print job
related information and altering their contents before passing related information and altering their contents before passing
them on to the printer or print server. them on to the printer or print server.
Expires December 12, 1997 Expires January 29, 1998
Replaying: Intercepting and storing print jobs or documents, and Replaying: Intercepting and storing print jobs or documents, and
have them submitted again later. Example: Stock Certificate have them submitted again later. Example: Stock Certificate
Printing. Protection against replaying requires the use of a Printing. Protection against replaying requires the use of a
nonce and/or time stamp. nonce and/or time stamp.
Spamming: Sending irrelevant or nonsensical print jobs or other Spamming: Sending irrelevant or nonsensical print jobs or other
IPP operations to a printer or print server with the objective of IPP operations to a printer or print server with the objective of
overloading the system and preventing legal users from getting overloading the system and preventing legal users from getting
service. service.
skipping to change at page 7, line 4 skipping to change at page 7, line 4
security domains the requirements for authentication and message security domains the requirements for authentication and message
protection are much stronger than when they are in the same protection are much stronger than when they are in the same
domain. domain.
Secondly, the sensitivity and value of the content being printed Secondly, the sensitivity and value of the content being printed
will vary. For example, a publicly available document does not will vary. For example, a publicly available document does not
require the same level of privacy that a payroll document require the same level of privacy that a payroll document
requires. There are at least two parties that have an interest in requires. There are at least two parties that have an interest in
the value of the information being printed, the person asking to the value of the information being printed, the person asking to
have the information printed and the person who originated the have the information printed and the person who originated the
Expires December 12, 1997
Expires January 29, 1998
information. This brings into the picture the need to worry about information. This brings into the picture the need to worry about
copyrights and protection of the content. copyrights and protection of the content.
Security attacks are now described for the following IPP Security attacks are now described for the following IPP
environments. Where examples are provided they should be environments. Where examples are provided they should be
considered illustrative of the environment and not an exhaustive considered illustrative of the environment and not an exhaustive
set. Not all of these environments will necessarily be addressed set. Not all of these environments will necessarily be addressed
in initial implementations of IPP. in initial implementations of IPP.
3.1 Client and Printer in the Same Security Domain 3.1 Client and Printer in the Same Security Domain
skipping to change at page 8, line 5 skipping to change at page 8, line 5
3.3 Print by Reference 3.3 Print by Reference
When the document is not stored on the client, printing can be When the document is not stored on the client, printing can be
done by reference. That is, the print request can contain a done by reference. That is, the print request can contain a
reference, or pointer, to the document instead of the actual reference, or pointer, to the document instead of the actual
document itself. If the client physically gets the document document itself. If the client physically gets the document
before it prints it, then this defaults to one of the previous before it prints it, then this defaults to one of the previous
cases. cases.
Expires December 12, 1997 Expires January 29, 1998
3.3.1 Unprotected Documents 3.3.1 Unprotected Documents
In many cases, documents to be printed are literally available to In many cases, documents to be printed are literally available to
anyone. Documents, such as this Internet Draft which are stored anyone. Documents, such as this Internet Draft which are stored
on anonymous FTP sites, are good examples of this. No security on anonymous FTP sites, are good examples of this. No security
mechanisms are required to protect access to these document. mechanisms are required to protect access to these documents.
3.3.2 Protected Documents 3.3.2 Protected Documents
Clearly, there are cases where the nature of a document requires Clearly, there are cases where the nature of a document requires
that access to it be protected by some authentication and/or that access to it be protected by some authentication and/or
authorization mechanism, or where the right to print the document authorization mechanism, or where the right to print the document
must be paid for. This would be the case for sensitive or must be paid for. This would be the case for sensitive or
confidential information, or where documents are copyrighted or confidential information, or where documents are copyrighted or
sold for profit. Unauthorized access to content is a major sold for profit. Unauthorized access to content is a major
concern in this environment. Protection against eavesdropping, concern in this environment. Protection against eavesdropping,
skipping to change at page 8, line 45 skipping to change at page 8, line 45
2) Message protection during transmission 2) Message protection during transmission
3) Client authentication and authorization 3) Client authentication and authorization
4) Mutual authentication, authorization, and message protection 4) Mutual authentication, authorization, and message protection
3.4.1 No Security 3.4.1 No Security
If the server requires no authorization and the client wants no If the server requires no authorization and the client wants no
message protection the client can send the print job, i.e., the message protection the client can send the print job, i.e., the
job content and the job attributes without invoking any security job content and the job attributes without invoking any security
mechanisms. The printer will print the job for the client. Print mechanisms. The printer will print the job for the client. Print
by reference also works well in this environment as long no by reference also works well in this environment as long as no
security mechanisms are required to access the documents to be security mechanisms are required to access the documents to be
printed. printed.
Expires January 29, 1998
3.4.2 Message Protection During Transmission 3.4.2 Message Protection During Transmission
Expires December 12, 1997
There are two types of security that could be used to provide There are two types of security that could be used to provide
message protection. These are channel security and object message protection. These are channel security and object
security. In the first case, the transport medium must be made security. In the first case, the transport medium must be made
secure by mutual authentication. Then everything between the secure by mutual authentication. Then everything between the
client and server is encrypted by the transport medium. The client and server is encrypted by the transport medium. The
transport medium can be either of the following: transport layer transport medium can be either of the following: transport layer
security (TLS) or network layer security (IPSec). security (TLS) or network layer security (IPSec)[4].
In the case of object security, each object is encrypted and sent In the case of object security, each object is encrypted and sent
over either a secure or an insecure channel. The recipient has over either a secure or an insecure channel. The recipient has
the corresponding key to decrypt the object and get the contents. the corresponding key to decrypt the object and get the contents.
The most widely used object security mechanisms are S/MIME The most widely used object security mechanisms are S/MIME [5],
[draft-smime], S-HTTP and PGP/MIME. S-HTTP [6] and PGP/MIME [7].
3.4.3 Client Authentication and Authorization 3.4.3 Client Authentication and Authorization
This scenario requires client authentication which may also be This scenario requires client authentication which may also be
used for authorization. A user ID and password may be used for used for authorization. A user ID and password may be used for
authorization purposes, and may be encrypted by the lower authorization purposes, and may be encrypted by the lower
security layer. S/MIME and TLS are good examples of this. TLS security layer. S/MIME and TLS are good examples of this. TLS
supports both one sided and mutual authentication and can also be supports both one sided and mutual authentication.
used in this scenario.
3.4.4 Mutual Authentication, Authorization and Message Protection 3.4.4 Mutual Authentication, Authorization and Message Protection
This scenario requires mutual authentication and message This scenario requires mutual authentication and message
protection. TLS and Secure Sockets Layer version 3 (SSL3) are protection. TLS and Secure Sockets Layer version 3 (SSL3) are
good channel level security providers in this category. good channel level security providers in this category.
4.0 Security Services 4.0 Security Services
Now that we have decribed the security threats that exist in the Now that we have described the security threats that exist in the
various environments in which IPP may operate, we will discuss various environments in which IPP may operate, we will discuss
the security services that are generally available to counter the security services that are generally available to counter
these threats. Security in general encompasses the software and these threats. Security in general encompasses the software and
hardware functionality to deliver the following services: hardware functionality to deliver the following services:
Authorization: Only authorized users should be able to gain Authorization: Only authorized users should be able to gain
access to systems, applications, data or services. Authorization access to systems, applications, data or services. Authorization
may be based on authenticated identity, location, time of day, may be based on authenticated identity, location, time of day,
role, possession of a physical device or token, or other role, possession of a physical device or token, or other
criterion. criterion.
Expires January 29, 1998
Authentication: Authentication is the process of proving who a Authentication: Authentication is the process of proving who a
user or system is, and may apply to individual identities, roles, user or system is, and may apply to individual identities, roles,
Expires December 12, 1997
or groups. Authentication may be done with traditional methods or groups. Authentication may be done with traditional methods
such as passwords or challenge-response mechansisms, or with such as passwords or challenge-response mechanisms, or with
publicly recognized methods such as certificates. publicly recognized methods such as certificates.
Message Protection: Access control protects data when it is Message Protection: Access control protects data when it is
within a secure system environment. However, when data must within a secure system environment. However, when data must
travel outside of a secure system, such as across a public travel outside of a secure system, such as across a public
network, it needs to be protected. Message protection includes network, it needs to be protected. Message protection includes
the following: the following:
Data origin authentication guarantees that the data originates Data origin authentication guarantees that the data originates
from an identified source. from an identified source.
skipping to change at page 10, line 41 skipping to change at page 10, line 44
be held responsible for it. be held responsible for it.
Provability of Service: The printer should be able to prove that Provability of Service: The printer should be able to prove that
it performed correctly according to the job attributes which the it performed correctly according to the job attributes which the
client/user had indeed issued. Example: The printer should be client/user had indeed issued. Example: The printer should be
able to prove that the job request was indeed a monochrome when able to prove that the job request was indeed a monochrome when
the user claims it issued a color copy. Provability of service the user claims it issued a color copy. Provability of service
requires non-repudiation. requires non-repudiation.
Payment and Accounting System: The Printer should insure that the Payment and Accounting System: The Printer should insure that the
wong person is not charged when someone issues a print request. wrong person is not charged when someone issues a print request.
Expires January 29, 1998
5.0 Applying Security to IPP Operations 5.0 Applying Security to IPP Operations
An IPP client uses the IPP protocol to invoke operations on An IPP client uses the IPP protocol to invoke operations on
remote Printer and Job objects. We now need to understand which remote Printer and Job objects. We now need to understand which
security services are required for the various IPP operations. security services are required for the various IPP operations.
The IPP Operations are: The IPP Operations are:
Expires December 12, 1997
Create-Job - Create an instance of a Job object Create-Job - Create an instance of a Job object
Send-Document - Append enclosed data to a Job object Send-Document - Append enclosed data to a Job object
Print-Job - Print the enclosed job, with attributes Print-Job - Print the enclosed job, with attributes
Cancel-Job - Cancel a previously submitted print job Cancel-Job - Cancel a previously submitted print job
Validate - Validate attributes for a specific object Validate-Job - Validate attributes for a specific object
Get-Jobs - Return job queue information for a Printer object Get-Jobs - Return job queue information for a Printer object
Get-Attributes - Return attribute information for a Printer or Get-Attributes - Return attribute information for a Printer or
Job object Job object
Print-URI - Print a document by reference Print-URI - Print a document by reference
Send-URI - Append enclosed document reference to a Job object Send-URI - Append enclosed document reference to a Job object
Get-Operations - Return IPP operations supported by the server
Every time a new connection with a Printer Object or with a Job Every time a new connection with a Printer Object or with a Job
Object is opened a new security context must established. An Object is opened a new security context must established. An
administrator may set up different security requirements for administrator may set up different security requirements for
different operations, i.e. a user may be able to query a printer, different operations, i.e. a user may be able to query a printer,
but not submit a job. Once a Job is created, the same (or but not submit a job. Once a Job is created, the same (or
greater) level of security will be required to perform additional greater) level of security will be required to perform additional
operations on that job. operations on that job.
5.1 Create-Job 5.1 Create-Job
When creating a print job, authentication of the client and the When creating a print job, authentication of the client and the
Printer are primary security considerations. Client Printer are primary security considerations. Client
authentication, along with authorization, protects against authentication, along with authorization, protects against
unauthorized use of print resources. Printer authentication unauthorized use of print resources. Printer authentication
guarantees the identitity of the remote Printer. guarantees the identity of the remote Printer.
5.2 Send-Document 5.2 Send-Document
When sending document content to the Printer, message protection When sending document content to the Printer, message protection
is the primary security service required. is the primary security service required.
5.3 Print-Job 5.3 Print-Job
PrintJob combines the functions of CreateJob and SendDocument, Print-Job combines the functions of Create-Job and Send-Document,
therefore therefore authentication, authorization, and message protection
authentication, authorization, and message protection are all are all required.
required.
Expires January 29, 1998
5.4 Cancel-Job 5.4 Cancel-Job
Cancel-Job is only used to cancel a job. An end user may only be Cancel-Job is only used to cancel a job. An end user may only be
allowed to cancel his or her own print jobs. Therefore allowed to cancel his or her own print jobs. Therefore
authentication is required to protection against unauthorized authentication is required to protection against unauthorized
cancellation of a job. cancellation of a job.
Expires December 12, 1997
5.5 Validate 5.5 Validate-Job
Validate is used to validate the attributes of a remote object. Validate is used to validate the attributes of a remote object.
Administrators may choose to restrict the ability for certain end Administrators may choose to restrict the ability for certain end
users to see the attributes of a Printer, so authentication and users to see the attributes of a Printer, so authentication and
authorization are required services. authorization are required services.
5.6 Get-Jobs 5.6 Get-Jobs
The level of security associated with the GetJobs operation The level of security associated with the Get-Jobs operation
depends on the policy set by an administrator. One common policy depends on the policy set by an administrator. One common policy
is for the complete job queue to be returned to anyone who asks. is for the complete job queue to be returned to anyone who asks.
This policy requires no security. For more secure Printers, a This policy requires no security. For more secure Printers, a
common policy is to list details only on the print jobs owned by common policy is to list details only on the print jobs owned by
the end user, while giving little or no details about other jobs. the end user, while giving little or no details about other jobs.
This policy requires client authentication and authorization to This policy requires client authentication and authorization to
match the client to the print jobs. match the client to the print jobs.
5.7 Get-Attributes 5.7 Get-Attributes
An administrator should be able to establish the level of An administrator should be able to establish the level of
security associated with getting the attributes of a printer. security associated with getting the attributes of a printer.
How security affects which attributes are returned is a policy
decision and outside the scope of IPP.
5.8 Print-URI 5.8 Print-URI
Print-URI is like Print-Job except that only a reference to the Print-URI is like Print-Job except that only a reference to the
document to be printed is sent in the request. Thus the Printer document to be printed is sent in the request. Thus the Printer
must fetch the document from the given URI in order to print the must fetch the document from the given URI in order to print the
job. In IPP version 1.0 we only allow unprotected (see section job. In IPP version 1.0 we only allow unprotected (see section
3.3.1) documents to be printed by reference. Additional, as yet 3.3.1) documents to be printed by reference. Additional, as yet
undefined security mechanisms are required to print a protected undefined security mechanisms are required to print a protected
document by reference. document by reference.
5.9 Send-URI 5.9 Send-URI
Send-URI is like send-Document except that only a reference to Send-URI is like send-Document except that only a reference to
the document to be printed is sent in the request. This operation the document to be printed is sent in the request. This operation
has the same security concerns as Print-URI. has the same security concerns as Print-URI.
Issue: Does asynchronous notification require any security? Expires January 29, 1998
5.10 Get-Operations
An administrator should be able to establish the level of
security required for someone to see the operations supported on
a Printer.
5.11 Asynchronous Notification
When submitting a print job, a user may include an attribute
which describes the address and method to be used for notifying
the user of Printer events such as job completion. Notification
is outside the scope of IPP and includes such methods as email
and ftp. When security mechanisms are employed in delivering
asynchronous notifications, security levels should be consistent
with those used in submitting the original print job.
6.0 Comments on existing security technologies 6.0 Comments on existing security technologies
Expires December 12, 1997
TLS - Transport Layer Security: Seems OK, is near completion in TLS - Transport Layer Security: Seems OK, is near completion in
the IETF and existing SSL product are probably compliant, or can the IETF and existing SSL product are probably compliant, or can
be made compliant without much effort. TLS Provides channel level be made compliant without much effort. TLS Provides channel level
security. security.
SSL 2 and SSL 3 - Secure Socket Layer: Proprietary solution SSL 2 and SSL 3 - Secure Socket Layer: Proprietary solution
initially by Netscape, but TLS is very close. Provides channel initially by Netscape, but TLS is very close. Provides channel
level security. level security.
PGP/MIME - Pretty Good Privacy MIME variant: The original PGP is PGP/MIME - Pretty Good Privacy MIME variant: The original PGP is
skipping to change at page 13, line 27 skipping to change at page 13, line 45
PGP/MIME version is now being worked on but is still not out, not PGP/MIME version is now being worked on but is still not out, not
yet stable, and not yet implemented and deployed. PGP/MIME yet stable, and not yet implemented and deployed. PGP/MIME
provides object level security. provides object level security.
S/MIME - Secure MIME: Currently a private implementation from S/MIME - Secure MIME: Currently a private implementation from
RSA. Although coming out as product from a number of vendors, RSA. Although coming out as product from a number of vendors,
unlikely to make it on the IETF standards track unless RSA unlikely to make it on the IETF standards track unless RSA
decides to release their proprietary products as open standards. decides to release their proprietary products as open standards.
S/MIME provides object level security. S/MIME provides object level security.
SASL - Simple Authentication and Session Layer: This seems to be SASL - Simple Authentication and Session Layer [7]: This
winning mind share in the IETF, but is really only a security security feature negotiation protocol and does not provide any
feature negotiation protocol and does not provide any security security services in itself. Hence quite limited usefulness for
services in itself. Hence quite limited usefulness for IPP. IPP.
HTTP 1.1 Digest Access Authentication, RFC 2069: This provides Expires January 29, 1998
HTTP 1.1 Digest Access Authentication: This provides
some limited security services, mainly only client side some limited security services, mainly only client side
authentication. It transmits a cryptographic digest derived from authentication. It transmits a cryptographic digest derived from
the user name, password, and a server generated challenge. the user name, password, and a server generated challenge.
SHTTP - Secure HTTP: Although on the IETF standards track, this SHTTP - Secure HTTP: Although on the IETF standards track, this
seems to lack some important features and does not seem to go seems to lack some important features and does not seem to go
anywhere in the market place. anywhere in the market place.
PEM - Privacy Enhanced Mail. Specified in IEF RFCs 1421-1424. It
was an early standard for securing email that specified a message
format and a hierarchy structure for certification authorities
(CAs).
MOSS - MIME Object Security Services. Offers the same
functionality as PEM, but does not force a single trust model,
and allows the identification of users by names that don't have
any relationship to X.500, such as E-mail addresses.
Expires December 12, 1997
IPSec - IP Security is an IETF standards track protocol for IPSec - IP Security is an IETF standards track protocol for
security on the IP layer. It consists of two separate mechanisms. security on the IP layer. It consists of two separate mechanisms.
The IP Authentication Header (AH) and the IP Encapsulating The IP Authentication Header (AH) and the IP Encapsulating
Security Payload (ESP). They can be used together or separately. Security Payload (ESP). They can be used together or separately.
The IP Authentication header provides integrity and The IP Authentication header provides integrity and
authentication of IP datagrams. The IP Encapsulating Security authentication of IP datagrams. The IP Encapsulating Security
Payload provides integrity, authentication and privacy. IPSec Payload provides integrity, authentication and privacy. IPSec
allows for either host keys or user keys to be used in security. allows for either host keys or user keys to be used in security.
IPSec can satisfy the IPP requirements for integrity and privacy. IPSec can satisfy the IPP requirements for integrity and privacy.
IPP Authentication, however, would require both IPSec use user IPP Authentication, however, would require both IPSec use user
keys and that the IPP application request use their own IPSec keys and that the IPP application request use their own IPSec
security association. Both requirements are recommended by IPSec security association. Both requirements are recommended by IPSec
but are not required. but are not required.
6.1 Recommended Security Mechanisms 6.1 Recommended Security Mechanisms
In order to provide security for the four common usage scenarios IPP implementations should provide a range of security options to
defined earlier, we recommend that implementations provide the meet the needs of different installations and user populations.
following, which are suitable for use with HTTP 1.1. The specific security services employed will be established by a
site administrator. The mechanisms used to establish these
- No Security - nothing is required services and to define user IDs and passwords to the system are
- Message Protection during transmission implementation defined and outside the scope of IPP.
- TLS
- IPSec
- Client authentication and authorization
- HTTP 1.1 Digest access authentication
- TLS
- Mutual authentication, authorization and message protection
- TLS
The security protocol used by a particular IPP operation will The security protocol used by a particular IPP operation will
depend upon the security services provided by the Printer and the depend upon the security services implemented on the Printer, the
security policy established by a site administrator, and the
selection made by the client. This requires that the right selection made by the client. This requires that the right
handshake messages be passed. These are described in more detail handshake messages be passed to invoke the selected security
in the Appendix. service. These are described in the references for each security
mechanism and are normally invoked by the client. Two printer
Directory and Printer attributes are required so that an end user attributes, message-protection-supported and authentication-
can query the level of security supported, but these are yet to authorization-supported are provided to help the end user know
be defined. what to expect in terms of security. These attributes should also
appear in the directory entry for each Printer.
Expires December 12, 1997
7.0 Appendix - Specific Features of various technologies
7.1 S/MIME: (Secure/Multipurpose Internet Mail Extensions)
Security services and features offered:
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.
Privacy (using encryption).
Integrity is achieved by using hashing to detect message
tampering.
Provides anonymity by using anonymous e-mailers and gateways. The
digital signature and the original message are placed in an
encrypted digital envelope.
Supports DES, Triple-DES, RC2.
X.509 digital certificates supported.
Supports PKCS #7(cryptographic message formatting, architecture
for certificate-based key management) and #10(message for
certification request).
Usage, implementation and interoperability:
Used to securely transmit e-mail messages in MIME format.
Public domain mailer RIPEM available.
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.
Any two packages that implement S/MIME can communicate securely.
Compatible with IMAP (Internet Message Access Protocol - RFC
1730).
S/MIME works both on the Internet or any other e-mail
environment.
7.2 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:
Expires December 12, 1997
Privacy: (optional). Uses symmetric keys. Encryption done by the
TLS Record Protocol. The keys are generated for each connection
by the TLS Handshake Protocol.
Integrity: Using keyed MAC. Hash functions (SHA, MD5) are used
for MAC computations.
Authentication (Both one-sided and Mutual): The TLS Handshake
Protocol uses public key cryptography. Encryption algorithms are
negotiated.
Usage, implementation and interoperability:
Interoperability: Independent applications can be developed
utilizing TLS and successfully exchange cryptographic parameters
without knowledge of each others code. Cannot inter-operate with
SSL 3.0
Extensibility: New encryption methods can be incorporated as
necessary.
Efficiency: To reduce the number of sessions that need to be
established from scratch, TLS provides session caching scheme.
Other operations: Compression, fragmentation is done by the TLS
Record Protocol.
Handshake protocol steps:
Exchange hello messages to agree on algorithms, exchange random
values, and check for session resumption.
Exchange the necessary cryptographic parameters to allow the
client and server to agree on a premaster secret.
Exchange certificates and cryptographic information to allow the
client and server to authenticate themselves.
Generate a master secret from the premaster secret and exchanged
random values.
Provide security parameters to the record layer.
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.
Note: The https protocol uses port 443 regardless of which
security protocol version (TLS, SSL2, SSL3) it is using.
Star (*) indicates optional messages.
7.3 SASL (Simple Authentication and Security Layer)
SASL provides a method for adding authentication support to
connection-based protocols. A command for identifying and
authenticating a user and for (optionally) negotiating a security
Expires December 12, 1997
layer for subsequent protocol interactions is included with a
protocol.
Security services and features offered:
(These are layers that SASL would call. One of these could be
selected.)
No security
Integrity
Privacy
Security mechanisms: Expires January 29, 1998
Kerberos When utilizing HTTP 1.1 as a transport for IPP, the security
GSS-API considerations outlined in HTTP 1.1 apply. When set by an
S/Key administrator, IPP servers MUST generate a 401 (Unauthorized)
response code to request client authentication and IPP clients
should correctly respond with the proper Authorization header.
Both basic authentication and digest authentication flavors of
authentication should be supported. The administrator chooses
which type(s) of authentication to accept. Digest authentication
is a more secure method and is always preferred to basic
authentication.
Handshaking protocol: For secure communication (privacy in particular), IPP should be
1. Client sends data run using a secure communications channel. Both TLS and IPSec
2. Server returns success* with additional data (challenge). provide secure communications channels and provide for mutual
Multiple authentication (s)* (Only one - the latest security authentication. The secure communications channel must be
layer initiated prior to running the IPP protocol. There is no
exists during multiple authentication). mechanism for bootstrapping a secure communication channel from
4. Registration procedures.* within the IPP protocol itself.
Note: SASL is not relevant for HTTP based protocols, but could be It is possible to combine a secure communication channel with
relevant to IPP, if IPP decides to later define an IPP specific either Basic or Digest Authentication.
protocol.
7.4 Digest Access Authentication [rfc2069] 6.2 Firewall Considerations
Digest Access Authentication is a proposed standard for weak Firewalls mostly play a role of enforcing corporate security
authentication in HTTP 1.1. It is intended as a replacement for policies, beyond that established for individual servers within
Basic Access Authentication found in HTTP 1.0. While Digest the firewall. For example, an IPP Printer may be set up to report
authentication is on the weak end of the security spectrum, it is back features to anyone. This is allowable as long as the user
a considerable improvement over the completely insecure Basic is behind the firewall, but may be prohibited if the user is
authentication. outside of the firewall.
Security services and features offered: Thus, the firewall acts as a proxy for all IPP Printers behind
a. Client Authentication is provided for by a client the firewall and intercepts all incoming HTTP POSTs from the
username/password pair. A hash of the username/password (and outside. Firewall software may then respond appropriately, based
other information) is sent from the client to the server. How the on the established security policy: It could pass the message
username/password is created is outside the protocol. along to the Printer, close the connection, or respond with some
b. Integrity (optional) is provided for by a hash of the entity error response. This could be done on an operation by operation
body, username/password, selected entity headers (and other basis. Likewise, the IPP Printer responses would be filtered by
information). This can be done on either messages from the the firewall software before passing them back to the external
client or from the server. client.
Expires December 12, 1997
c. By default, the hash uses MD5. However, there are provisions
for other algorithms.
d. Digest authentication is vulnerable to replay attacks, man-
in-the-middle attacks, server spoofing, and attacks on the stored
password on the server. Well chosen implementations can
minimize, but not eliminate the vulnerability.
Usage, implementation and interoperability: Expires January 29, 1998
a. This is used by web servers and clients to pass Firewall software could additionally filter requests based on job
authentication information. attributes, so, for example, only jobs specifying a single copy
b. This is a proposed feature addition to HTTP 1.1. As such, it or only duplex jobs could be printed. However, it is very
is limited to HTTP 1.1 implementations (currently a small unlikely that firewall software would check for features
number). specified in the actual document content, i.e. in the page
c. Different implementations have proven interoperable. description language.
Handshake protocol steps: Expires January 29, 1998
a. Client asks for an access-protected object and an acceptable 7.0 References:
Authorization header is not sent.
b. The Server responds with a "401 Unauthorized" status code,
and a WWW-Authenticate header. The header has the fields:
* realm - a string indicating the context for the
authorization
* domain [optional] - a list of URIs the authentication is
used for
* nonce - a data string used in authentication
* opaque [optional] - a data string supplied by the server
* stale [optional] - a flag indicating the previous effort
used a stale nonce
* algorithm [optional] - a token indicating the hash algorithm
to use
c. The Client then asks the User for the username/password (if
needed). It then calculates the needed information and retries
the request with a Authorization header. The header has the
fields:
* username - the string supplied by the user
* realm - the value supplied by the server
* nonce - the value supplied by the server
* uri - the URI requested
* response - the response hash (see below)
* digest [optional] - the digest hash (see below), used for
integrity checking
* algorithm [optional] - the algorithm used
* opaque - the value supplied by the server
d. If authorization is granted, the Server responds with result
of query,
Expires December 12, 1997
optionally including a AuthenticationInfo header. The header has
the fields:
* nextnonce [optional] - the nonce the client should use for
the next request
* digest [optional] - the digest hash (see below) used for
integrity checking.
Calculation of hashes [1] T. Dierks, C. Allen, "The TLS Protocol", <draft-ietf-
tls-protocol-03.txt>, March 24, 1997.
The response hash uses the values of username, realm, password, [2] R. Fielding, J. Gettys, J. Mogul, H. Frystyk,
nonce, HTTP method, and URI. It is calculated by: T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1",
response = Hash(Hash(A1) ":" nonce ":" Hash(A2)) RFC 2068, January 1997
A1 = username ":" realm ":" password
A2 = method ":" URI
The digest hash uses the values of username, realm, password, [3] J. Franks, P. Hallam-Baker, J. Hostetler, P. Leach, A.
nonce, HTTP method, date, URI, content-type, content-length, Luotonen, E. Sink, L. Stewart, "An Extension to HTTP: Digest
content-encoding, last-modified, expires, and the entity body. Access Authentication", RFC-2069, Jan 1997.
The values of content-type, content-length, content-encoding,
last-modified and expires are all taken from the HTTP headers,
and are blank if not defined. The digest hash can be sent.by
either the client or the server. The digest hash is calculated
by:
digest = Hash(Hash(A1) ":" nonce ":" method ":" date ":"
entity-info ":"Hash(entity-body))
entity-info = Hash(URI ":" content-type ":" content-length ":"
content-encoding ":" last-modified ":" expires)
Expires December 12, 1997 [4] R. Atkinson, "Security Architecture for the Internet
8.0 References: Protocol, RFC 1825", August 1995
[rfc2069] J. Franks, P. Hallam-Baker, J. Hostetler, P. Leach, A. [5] S. Dusse, "S/MIME Message Specification", <draft-
Luotonen, E. Sink, L. Stewart, _An Extension to HTTP: Digest dusse-mime-msg-spec-00.txt, Sep. 1996.
Access Authentication_, RFC-2069, Jan 1997.
[draft-smime] S. Dusse, _S/MIME Message Specification_, <draft- [6] E. Rescorla, A. Schiffman, "The Secure Hypertext
dusse-mime-msg-spec-00.txt_, Sep. 1996. Transfer Protocol" <draft-ietf-wts-04.txt>, March 1997
[draft-sasl] J. Myers, _Simple Authentication and Security Layer [7] M. Elkins, "MIME Security with Pretty Good Privacy (PGP)"
(SASL)_, <draft-myers-auth-sasl-11.txt>, April 1997. RFC 2015, October 1996
[draft-tsl] T. Dierks, C. Allen, _The TLS Protocol_, <draft-ietf- [8] J. Myers, "Simple Authentication and Security Layer
tls-protocol-03.txt>, March 24, 1997. (SASL)", <draft-myers-auth-sasl-11.txt>, April 1997.
Expires December 12, 1997 Expires January 29, 1998
9.0 Authors' Addresses 8.0 Authors' Addresses
Roger deBry Roger deBry
HUC/003G HUC/003G
IBM Corporation IBM Corporation
P.O. Box 1900 P.O. Box 1900
Boulder, CO 80301-9191 Boulder, CO 80301-9191
rdebry@us.ibm.com rdebry@us.ibm.com
Jerry Hadsell Jerry Hadsell
1130 1130
skipping to change at line 862 skipping to change at line 713
Xerox Corporation Xerox Corporation
701 Aviation Blvd. 701 Aviation Blvd.
El Segundo, CA 90245 El Segundo, CA 90245
jwenn@cp10.es.xerox.com jwenn@cp10.es.xerox.com
Other Contributors Other Contributors
Scott Isaacson, Novell Scott Isaacson, Novell
Carl-Uno Manros, Xerox Carl-Uno Manros, Xerox
Expires December 12, 1997 Expires January 29, 1998
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/