INTERNET-DRAFT
                                                               Roger deBry
                                                           IBM Corporation
                                                             Jerry Hadsell
                                                           IBM Corporation
                                                           Daniel Manchala
                                                         Xerox Corporation
                                                              Xavier Riley
                                                         Xerox Corporation
                                                                 John Wenn
                                                         Xerox Corporation
                                                   June 12,
                                                             July 29, 1997

                        Internet Printing Protocol/1.0: Security
                        draft-ietf-ipp-security-00.txt
                             draft-ietf-ipp-security-01.txt

          Status of this memo

          This document is an Internet-Draft. Internet-Drafts are working
          documents of the Internet Engineering Task Force (IETF), its
          areas, and its working groups.  Note that other groups may also
          distribute working documents as Internet-Drafts. Internet-Drafts
          are draft documents valid for a maximum of six months and may be
          updated, replaced, or obsoleted by other documents at any time.
          It is inappropriate to use Internet-Drafts as reference material
          or to cite them other than as "work in progress."

          To learn the current status of any Internet-Draft, please check
          the "1id-abstracts.txt" listing contained in the Internet-Drafts
          Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net
     (Europe),
          (Europe) munnari.oz.au (Pacific Rim), ds.internic.net (US East
          Coast), or ftp.isi.edu (US West Coast).

          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

                                  Expires December 12, 1997 January 29, 1998
          describes a distributed printing service. The full set of IPP
          documents includes:

               Requirements for an Internet Printing Protocol/1.0: Requirements Protocol
               Internet Printing Protocol/1.0: Model and Semantics
               Internet Printing Protocol/1.0: Security
               Internet Printing Protocol/1.0: Protocol Specification
               Internet Printing Protocol/1.0: Directory Schema

          This documentis document is the `Internet Printing Protocol/1.0: Security'
          document.

                                 Expires December 12, 1997 January 29, 1998
          Table of Contents

          1.0 Introduction .........................................4
          2.0 Security Threats and Attacks .........................4 .........................5
             2.1 Threats ...........................................5
             2.2 Methods of Attack .................................5
          3.0 Internet Printing ....................................6 Environments........................6
             3.1 Printer and Client in the Same Security Domain ....7
             3.2 Printer and client in Different Security Domains ..7
             3.3 Print-by-Reference ................................7
                3.3.1 Unprotected Documents ........................8
                3.3.2 Protected Documents ..........................8
             3.4 Common Security Scenarios .........................8
                3.4.1 No Security ..................................8
                3.4.2 Message Protection During Transmission .......8 .......9
                3.4.3 Client Authentication and Authorization ......9
                3.4.4 Mutual Authentication, Authorization and Message
                      Protection ...................................9
          4.0 Security Services ....................................9
          5.0 Applying security to IPP operations .................10 .................11
             5.1 Create-Job .......................................11
             5.2 Send-Document ....................................11
             5.3 Print-Job ........................................11
             5.4 Cancel-Job .......................................11 .......................................12
             5.5 Validate .........................................12
             5.6 Get-Jobs .........................................12
             5.7 Get-Attributes ...................................12
             5.8 Print-URI ........................................12
             5.9 Send-URI .........................................12
             5.10 Get-Operations...................................13
             5.11 Asynchronous Notification .......................13
          6.0 Comments on Existing Security Technologies ..........12 ..........13
          6.1  Recommended Security Mechanisms ..................14 ....................14
          6.2  Firewall Consideration..............................15
          7.0 Appendix - Specific Features of Various Technologies 15
        7.1 S/MIME: (Secure/Multipurpose Internet Mail Ext.)..15
        7.2 Transport Layer Security 1.0 (TLS) ...............15
        7.3 SASL (Simple Authentication and Security Layer) ..16
        7.4 Digest Access Authentication .....................17
     8.0 References ..........................................20
     9.0 ..........................................17
          8.0 Authors' Addresses ..................................21 ..................................18

                                 Expires December 12, 1997 January 29, 1998
          1.0 Introduction

          The purpose of this document is to describe security
          considerations for the Internet Printing Protocol (IPP). Internet
          Printing is the application of Internet technology to network
          printing. Using Internet technology, users want to be able to
          locate printers, install and configure printer software, query
          printers for capabilities and status, and submit and track print
          jobs. The Internet Printing Protocol defines the network
          interface for many of these functions.

          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 Transport Layer Security
     (TLS)[draft-tls]
          (TLS)[1] and Basic Authentication[2] and Digest Access Authentication [rfc2069]in
          Authentication[3]in HTTP.

          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 not to 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, would 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.

                                 Expires January 29, 1998
          2.0 Security Threats and Attacks
                       Expires December 12, 1997

          Before discussing security services specifically as they relate
          to IPP, it will be useful to quickly discuss and categorize
          security threats in a general way and discuss the means by which
          these threats are carried out.

          2.1 Threats

          Security threats fall into the following broad categories:

          Resource stealing: The unauthorized use of facilities, such as
          printers, specific printer features, media, fonts, or logos etc.
          resulting in some value to the perpetrator.

          Vandalism: Similar to resource stealing, but usually without gain
          to the perpetrator.  Often results in denial of service to other
          authorized users.

          Leakage: The acquisition of information by unauthorized
          interceptors during transmission.

          Tampering: The interception and altering of information during
          transmission.

          2.2 Methods of Attack

          The methods by which security violations can be perpetrated
          depend upon obtaining access to existing communication channels
          or establishing channels that masquerade as connections to a user
          with some desired authority.  These methods are:

          Masquerading: Submission of print jobs or performing other IPP
          operations using the identity and password of another user
          without their authority, or by using an access token or
          capability after the authorization to use it has expired.

          Eavesdropping: Obtaining copies of documents and job instructions
          without authority, either directly from the network or by
          examining information that is inadequately protected in storage.

          Document tampering: Intercepting documents or other print job
          related information and altering their contents before passing
          them on to the printer or print server.

                                 Expires December 12, 1997 January 29, 1998
          Replaying: Intercepting and storing print jobs or documents, and
          have them submitted again later. Example: Stock Certificate
          Printing. Protection against replaying requires the use of a
          nonce and/or time stamp.

          Spamming: Sending irrelevant or nonsensical print jobs or other
          IPP operations to a printer or print server with the objective of
          overloading the system and preventing legal users from getting
          service.

          Malicious Document Content Code: Sending documents that contain
          malicious code which will bring the printer software into a loop
          or even ruin hardware components in the print device. Example:
          Using PostScript as a programming language to run the printer
          into an infinite loop.

          3.0 Internet Printing Environments

          It is now important to understand how the threats and attacks we
          have discussed above apply to the various environments in which
          IPP will operate.

          The IPP Model encapsulates the important elements required for
          printing into three simple objects, the Printer, the Job, and the
          Document. The Printer represents the functions associated with a
          physical output device along with the spooling, scheduling, and
          multiple output device management often associated with a print
          server. An IPP client uses the IPP protocol to invoke operations
          on IPP objects on other network nodes.

          The initial security needs of IPP are derived from two primary
          considerations.  First, the printing environments described in
          this document take into account the fact that the client, the
          Printer, and the document to be printed may all exist in
          different security domains. When objects are in different
          security domains the requirements for authentication and message
          protection are much stronger than when they are in the same
          domain.

          Secondly, the sensitivity and value of the content being printed
          will vary. For example, a publicly available document does not
          require the same level of privacy that a payroll document
          requires. There are at least two parties that have an interest in
          the value of the information being printed, the person asking to
          have the information printed and the person who originated the

                                 Expires December 12, 1997 January 29, 1998
          information. This brings into the picture the need to worry about
          copyrights and protection of the content.

          Security attacks are now described for the following IPP
          environments. Where examples are provided they should be
          considered illustrative of the environment and not an exhaustive
          set. Not all of these environments will necessarily be addressed
          in initial implementations of IPP.

          3.1 Client and Printer in the Same Security Domain

          This environment is typical of internal networks where
          traditional office workers print the output of personal
          productivity applications on shared work-group printers, or where
          batch applications print their output on large production
          printers. Although the identity of the user may be trusted in
          this environment, a user might want to protect the content of a
          document against such attacks as eavesdropping, replaying or
          tampering.

          3.2 Client and Printer in Different Security Domains

          Examples of this environment include printing a document created
          by the client on a publicly available printer, such as at a
          commercial print shop; or printing a document remotely on a
          business partner's printer. This latter operation is functionally
          equivalent to sending the document to the business partner as a
          facsimile. Printing sensitive information on a Printer in a
          different security domain requires strong security measures. In
          this environment authentication of the printer is required as
          well as protection against unauthorized use of print resources.
          Since the document crosses security domains, protection against
          eavesdropping and document tampering are also required. It will
          also be important in this environment to protect Printers against
          spamming and malicious document content code.

          3.3 Print by Reference

          When the document is not stored on the client, printing can be
          done by reference. That is, the print request can contain a
          reference, or pointer, to the document instead of the actual
          document itself. If the client physically gets the document
          before it prints it, then this defaults to one of the previous
          cases.

                                 Expires December 12, 1997 January 29, 1998
          3.3.1 Unprotected Documents

          In many cases, documents to be printed are literally available to
          anyone. Documents, such as this Internet Draft which are stored
          on anonymous FTP sites, are good examples of this. No security
          mechanisms are required to protect access to these document. documents.

          3.3.2 Protected Documents

          Clearly, there are cases where the nature of a document requires
          that access to it be protected by some authentication and/or
          authorization mechanism, or where the right to print the document
          must be paid for. This would be the case for sensitive or
          confidential information, or where documents are copyrighted or
          sold for profit. Unauthorized access to content is a major
          concern in this environment. Protection against eavesdropping,
          document tampering and unauthorized access to the document are
          also concerns if the content is sensitive.

          3.4 Common Security Scenarios

          As discussed earlier in this document,we document, we cannot anticipate the
          security levels or the specific threats that any given IPP print
          administrator may be concerned with. Security policies might vary
          from very strong, to very weak, to none at all, and corresponding
          security mechanisms will be required. In this section we will
          describe what we believe to be four common usage scenarios.

          1) No security at all
          2) Message protection during transmission
          3) Client authentication and authorization
          4) Mutual authentication, authorization, and message protection

          3.4.1 No Security

          If the server requires no authorization and the client wants no
          message protection the client can send the print job, i.e., the
          job content and the job attributes without invoking any security
          mechanisms. The printer will print the job for the client. Print
          by reference also works well in this environment as long as no
          security mechanisms are required to access the documents to be
          printed.

                                      Expires January 29, 1998
          3.4.2 Message Protection During Transmission

                       Expires December 12, 1997

          There are two types of security that could be used to provide
          message protection. These are channel security and object
          security. In the first case, the transport medium must be made
          secure by mutual authentication. Then everything between the
          client and server is encrypted by the transport medium. The
          transport medium can be either of the following: transport layer
          security (TLS) or network layer security (IPSec). (IPSec)[4].

          In the 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.
          The most widely used object security mechanisms are S/MIME
     [draft-smime], [5],
          S-HTTP [6] and PGP/MIME. PGP/MIME [7].

          3.4.3 Client Authentication and Authorization

          This scenario requires client authentication which may also be
          used for authorization. A user ID and password may be used for
          authorization purposes, and may be encrypted by the lower
          security layer. S/MIME and TLS are good examples of this. TLS
          supports both one sided and mutual authentication and can also be
     used in this scenario. authentication.

          3.4.4 Mutual Authentication, Authorization and Message Protection

          This scenario requires mutual authentication and message
          protection. TLS and Secure Sockets Layer version 3 (SSL3) are
          good channel level security providers in this category.

          4.0 Security Services

          Now that we have decribed described the security threats that exist in the
          various environments in which IPP may operate, we will discuss
          the security services that are generally available to counter
          these threats.  Security in general encompasses the software and
          hardware functionality to deliver the following services:

          Authorization: Only authorized users should be able to gain
          access to systems, applications, data or services. Authorization
          may be based on authenticated identity, location, time of day,
          role, possession of a physical device or token, or other
          criterion.

                                      Expires January 29, 1998
          Authentication: Authentication is the process of proving who a
          user or system is, and may apply to individual identities, roles,
                       Expires December 12, 1997
          or groups. Authentication may be done with traditional methods
          such as passwords or challenge-response mechansisms, mechanisms, or with
          publicly recognized methods such as certificates.

          Message Protection: Access control protects data when it is
          within a secure system environment. However, when data must
          travel outside of a secure system, such as across a public
          network, it needs to be protected. Message protection includes
          the following:

          Data origin authentication guarantees that the data originates
          from an identified source.

          Privacy protection guarantees that the data cannot be observed
          except by authorized parties.

          Integrity protection guarantees that the data cannot be
          undetectably modified except by authorized parties.

          Non-repudiation protection guarantees that actions taken on data
          cannot be denied by the subjects performing those actions.

          Liability: Responsibility of the user for the printed content.
          This holds the user accountable for making payments, usage of
          special resources like transparencies, color printing, etc. The
          printer is also responsible for the services performed and will
          be held responsible for it.

          Provability of Service: The printer should be able to prove that
          it performed correctly according to the job attributes which  the
          client/user had indeed issued. Example: The printer should be
          able to prove that the job request was indeed a monochrome when
          the user claims it issued a color copy. Provability of service
          requires non-repudiation.

          Payment and Accounting System: The Printer should insure that the
     wong
          wrong person is not charged when someone issues a print request.

                                 Expires January 29, 1998
          5.0 Applying Security to IPP Operations

          An IPP client uses the IPP protocol to invoke operations on
          remote Printer and Job objects. We now need to understand which
          security services are required for the various IPP operations.
          The IPP Operations are:

                       Expires December 12, 1997

          Create-Job - Create an instance of a Job object
          Send-Document - Append enclosed data to a Job object
          Print-Job - Print the enclosed job, with attributes
          Cancel-Job - Cancel a previously submitted print job
     Validate
          Validate-Job - Validate attributes for a specific object
          Get-Jobs - Return job queue information for a Printer object
          Get-Attributes - Return attribute information for a Printer or
                           Job object
          Print-URI - Print a document by reference
          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
          Object is opened a new security context must established. An
          administrator may set up different security requirements for
          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
          greater) level of security will be required to perform additional
          operations on that job.

          5.1 Create-Job

          When creating a print job, authentication of the client and the
          Printer are primary security considerations. Client
          authentication, along with authorization, protects against
          unauthorized use of print resources. Printer authentication
          guarantees the identitity identity of the remote Printer.

          5.2 Send-Document

          When sending document content to the Printer, message protection
          is the primary security service required.

          5.3 Print-Job

     PrintJob

          Print-Job combines the functions of CreateJob Create-Job and SendDocument, Send-Document,
          therefore authentication, authorization, and message protection
          are all required.

                                      Expires January 29, 1998
          5.4 Cancel-Job

          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
          authentication is required to protection against unauthorized
          cancellation of a job.
                       Expires December 12, 1997

          5.5 Validate Validate-Job

          Validate is used to validate the attributes of a remote object.
          Administrators may choose to restrict the ability for certain end
          users to see the attributes of a Printer, so authentication and
          authorization are required services.

          5.6 Get-Jobs

          The level of security associated with the GetJobs Get-Jobs operation
          depends on the policy set by an administrator.  One common policy
          is for the complete job queue to be returned to anyone who asks.
          This policy requires no security. For more secure Printers, a
          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.
          This policy requires client authentication and authorization to
          match the client to the print jobs.

          5.7 Get-Attributes

          An administrator should be able to establish the level of
          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

          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
          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
          3.3.1) documents to be printed by reference. Additional, as yet
          undefined security mechanisms are required to print a protected
          document by reference.

          5.9 Send-URI

          Send-URI is like send-Document except that only a reference to
          the document to be printed is sent in the request. This operation
          has the same security concerns as Print-URI.

     Issue: Does

                                 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 notification require any security? notifications, security levels should be consistent
          with those used in submitting the original print job.

          6.0 Comments on existing security technologies

                       Expires December 12, 1997

          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. TLS Provides channel level
          security.

          SSL 2 and SSL 3 - Secure Socket Layer:  Proprietary solution
          initially by Netscape, but TLS is very close. Provides channel
          level security.

          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. PGP/MIME
          provides object level security.

          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.
          S/MIME provides object level security.

          SASL - Simple Authentication and Session Layer: Layer [7]:  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 for
          IPP.

                                 Expires January 29, 1998
          HTTP 1.1 Digest Access Authentication, RFC 2069: Authentication:  This provides
          some limited security services, mainly only client side
          authentication.  It transmits a cryptographic digest derived from
          the user name, password, and a server generated challenge.

          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.

     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
          security on the IP layer. It consists of two separate mechanisms.
          The IP Authentication Header (AH) and the IP Encapsulating
          Security Payload (ESP). They can be used together or separately.
          The IP Authentication header provides integrity and
          authentication of IP datagrams. The IP Encapsulating Security
          Payload provides integrity, authentication and privacy. IPSec
          allows for either host keys or user keys to be used in security.
          IPSec can satisfy the IPP requirements for integrity and privacy.
          IPP Authentication, however, would require both IPSec use user
          keys and that the IPP application request use their own IPSec
          security association. Both requirements are recommended by IPSec
          but are not required.

          6.1 Recommended Security Mechanisms

     In order to provide security for the four common usage scenarios
     defined earlier, we recommend that

          IPP implementations should provide a range of security options to
          meet the
     following, which are suitable for use with HTTP 1.1.

     - No Security - nothing is required
     - Message Protection during transmission
       - TLS
       - IPSec
     - Client authentication needs of different installations and authorization
       - HTTP 1.1 Digest access authentication
       - TLS
     - Mutual authentication, authorization user populations.
          The specific security services employed will be established by a
          site administrator. The mechanisms used to establish these
          services and message protection
        - TLS to define user IDs and passwords to the system are
          implementation defined and outside the scope of IPP.

          The security protocol used by a particular IPP operation will
          depend upon the security services provided by implemented on the Printer Printer, the
          security policy established by a site administrator, and the
          selection made by the client. This requires that the right
          handshake messages be passed. passed to invoke the selected security
          service. These are described in more detail
     in the Appendix.

     Directory references for each security
          mechanism and Printer attributes are required so that an end user
     can query normally invoked by the level of security supported, but these are yet to
     be defined.

                       Expires December 12, 1997
     7.0 Appendix - Specific Features of various technologies

     7.1 S/MIME: (Secure/Multipurpose Internet Mail Extensions)

     Security services client. Two printer
          attributes, message-protection-supported and features offered:
     Sender Authentication is authentication-
          authorization-supported are provided using digital signatures. The
     recipient reads to help the sender's digital signature. Non-repudiation end user know
          what to expect in terms of origin is security. These attributes should also achieved using digital signatures.
     Privacy (using encryption).
     Integrity is achieved
          appear in the directory entry for each Printer.

                                      Expires January 29, 1998
          When utilizing HTTP 1.1 as a transport for IPP, the security
          considerations outlined in HTTP 1.1 apply. When set by using hashing an
          administrator, IPP servers MUST generate a 401 (Unauthorized)
          response code to detect message
     tampering.
     Provides anonymity by using anonymous e-mailers and gateways. The
     digital signature request client authentication and IPP clients
          should correctly respond with 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) proper Authorization header.
          Both basic authentication and #10(message for
     certification request).

     Usage, implementation 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 interoperability:
     Used is always preferred to securely transmit e-mail messages basic
          authentication.

          For secure communication (privacy in MIME format.
     Public domain mailer RIPEM available.
     RSA's toolkit TIPEM (Toolkit for Interoperable Privacy Enhanced
     Messaging)  can particular), IPP should 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
          run using a two layered protocol. The lower level TLS Record
     Protocol that sits on top of TCP and the TLS Handshake Protocol.
     The secure communications channel. Both 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 IPSec
          provide secure communications channels 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 provide for MAC computations.
     Authentication (Both one-sided and Mutual): mutual
          authentication. 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 secure communications channel must be incorporated as
     necessary.
     Efficiency: To reduce the number of sessions that need
          initiated prior to be
     established from scratch, TLS provides session caching scheme.
     Other operations: Compression, fragmentation is done by running the TLS
     Record Protocol.

     Handshake protocol steps:
     Exchange hello messages to agree on algorithms, exchange random
     values, and check IPP protocol. There is no
          mechanism 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 bootstrapping a master secret secure communication channel from
          within 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 IPP protocol version (TLS, SSL2, SSL3) it itself.

          It is using.
     Star (*) indicates optional messages.

     7.3 SASL (Simple Authentication and Security Layer)

     SASL provides a method for adding authentication support possible to
     connection-based protocols.  A command for identifying and
     authenticating combine a user and for (optionally) negotiating secure communication channel with
          either Basic or Digest Authentication.

          6.2 Firewall Considerations

          Firewalls mostly play a role of enforcing corporate security

                       Expires December 12, 1997
     layer
          policies, beyond that established 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:
     Kerberos
     GSS-API
     S/Key

     Handshaking protocol:
     1. Client sends data
     2. Server returns success* with additional data (challenge).
     Multiple authentication (s)* (Only one - individual servers within
          the latest security
     layer
          exists during multiple authentication).
          4. Registration procedures.*

     Note: SASL is not relevant for HTTP based protocols, but could be
     relevant to IPP, if IPP decides to later define firewall. For example, an IPP specific
     protocol.

     7.4 Digest Access Authentication [rfc2069]

     Digest Access Authentication is a proposed standard for weak
     authentication in HTTP 1.1.  It is intended as a replacement for
     Basic Access Authentication found in HTTP 1.0.  While Digest
     authentication is on the weak end of the security spectrum, it is
     a considerable improvement over the completely insecure Basic
     authentication.

     Security services and features offered:
     a.  Client Authentication is provided for by a client
     username/password pair.  A hash of the username/password (and
     other information) is sent from the client to the server. How the
     username/password is created is outside the protocol.
     b.  Integrity (optional) is provided for by a hash of the entity
     body, username/password, selected entity headers (and other
     information).  This can Printer may be done on either messages from the
     client or from the server.
                       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:
     a.  This is used by web servers and clients to pass
     authentication information.
     b.  This is a proposed feature addition to HTTP 1.1.  As such, it
     is limited to HTTP 1.1 implementations (currently a small
     number).
     c.  Different implementations have proven interoperable.

     Handshake protocol steps:
     a.  Client asks for an access-protected object and an acceptable
     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 set up to report
          back features to anyone. This is allowable as long as the
     fields:
        * username - user
          is behind the string supplied by firewall, but may be prohibited if the user
        * realm - is
          outside of the value supplied by firewall.

          Thus, the server
        * nonce - firewall acts as a proxy for all IPP Printers behind
          the value supplied by firewall and intercepts all incoming HTTP POSTs from the server
        * uri -
          outside. Firewall software may then respond appropriately, based
          on the URI requested
        * response - established security policy: It could pass the response hash (see below)
        * digest [optional] - message
          along to the digest hash (see below), used for
     integrity checking
        * algorithm [optional] - Printer, close the algorithm used
        * opaque - connection, or respond with some
          error response. This could be done on an operation by operation
          basis. Likewise, the value supplied IPP Printer responses would be filtered by
          the server
     d.  If authorization is granted, firewall software before passing them back to the Server responds with result
     of query, external
          client.

                                      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 January 29, 1998
          Firewall software could additionally filter requests based on job
          attributes, so, for
     integrity checking.

     Calculation of hashes

     The response hash uses the values of username, realm, password,
     nonce, HTTP method, and URI.  It is calculated by:
       response = Hash(Hash(A1) ":" nonce ":" Hash(A2))
       A1 = username ":" realm ":" password
       A2 = method ":" URI

     The digest hash uses the values of username, realm, password,
     nonce, HTTP method, date, URI, content-type, content-length,
     content-encoding, last-modified, expires, and the entity body.
     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 example, only jobs specifying a single copy
          or only duplex jobs could be sent.by
     either printed. However, it is very
          unlikely that firewall software would check for features
          specified in the client or actual document content, i.e. in 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) page
          description language.

                                 Expires December 12, 1997
     8.0 January 29, 1998
          7.0 References:

     [rfc2069]

          [1] T. Dierks, C. Allen, "The TLS Protocol", <draft-ietf-
          tls-protocol-03.txt>, March 24, 1997.

          [2] R. Fielding, J. Gettys, J. Mogul, H. Frystyk,
          T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1",
          RFC 2068, January 1997

          [3] J. Franks, P. Hallam-Baker, J. Hostetler, P. Leach, A.
          Luotonen, E. Sink, L. Stewart, _An "An Extension to HTTP: Digest
          Access Authentication_, Authentication", RFC-2069, Jan 1997.

     [draft-smime]

          [4] R. Atkinson, "Security Architecture for the Internet
          Protocol, RFC 1825", August 1995

          [5] S. Dusse, _S/MIME "S/MIME Message Specification_, Specification", <draft-
     dusse-mime-msg-spec-00.txt_,
          dusse-mime-msg-spec-00.txt, Sep. 1996.

     [draft-sasl]

          [6] E. Rescorla, A. Schiffman, "The Secure Hypertext
          Transfer Protocol" <draft-ietf-wts-04.txt>, March 1997

          [7] M. Elkins, "MIME Security with Pretty Good Privacy (PGP)"
          RFC 2015, October 1996

          [8] J. Myers, _Simple "Simple Authentication and Security Layer
     (SASL)_,
          (SASL)", <draft-myers-auth-sasl-11.txt>, April 1997.

     [draft-tsl] T. Dierks, C. Allen, _The TLS Protocol_, <draft-ietf-
     tls-protocol-03.txt>, March 24, 1997.

                                 Expires December 12, 1997
     9.0 January 29, 1998
          8.0 Authors' Addresses

          Roger deBry
          HUC/003G
          IBM Corporation
          P.O. Box 1900
          Boulder, CO 80301-9191
          rdebry@us.ibm.com

          Jerry Hadsell
          1130
          IBM Corporation
          Rt. 100
          Somers, N.Y. 10589
          hadsell@us.ibm.com

          Daniel Manchala
          Xerox Corporation
          701 Aviation Blvd.
          El Segundo, CA 90245
          manchala@cp10.es.xerox.com

          Xavier Riley
          Xerox Corporation
          701 Aviation Blvd.
          El Segundo, CA 90245
          xriley@cp10.es.xerox.com

          John Wenn
          Xerox Corporation
          701 Aviation Blvd.
          El Segundo, CA 90245
          jwenn@cp10.es.xerox.com

          Other Contributors

          Scott Isaacson, Novell
          Carl-Uno Manros, Xerox

                                 Expires December 12, 1997 January 29, 1998