IPP> Re: New I-Ds from the IPP WG - RESENT DUE TO NON-REPLY

IPP> Re: New I-Ds from the IPP WG - RESENT DUE TO NON-REPLY

Carl-Uno Manros cmanros at cp10.es.xerox.com
Wed Jun 25 19:15:50 EDT 1997


--=====================_867305750==_
Content-Type: text/plain; charset="us-ascii"


At 01:17 PM 6/23/97 PDT, Cynthia Clark wrote:
>
>hi carl-uno,
>
>please excuse me for the delay as i've just
>returned here from a vacation.
>
>these filenames are fine.
>
>later
>
>cynthia
>




Cynthia,


thanks, attached is the IPP Security document.


Regards,


Carl-Uno


Co-chair IETF WG for IPP
--=====================_867305750==_
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: attachment; filename="draft-ietf-ipp-security-00.txt"






















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






                   Internet Printing Protocol/1.0: Security
                        draft-ietf-ipp-security-00.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),
     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
     DeBry, Hadsell, Manchala, Riley, Wenn             [Page 1]
                        Expires December 12, 1997











     INTERNET-DRAFT        IPP/1.0: Security      June 12, 1997






     describes a distributed printing service. The full set of IPP
     documents includes:




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


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


































































     DeBry, Hadsell, Manchala, Riley, Wenn             [Page 2]
                       Expires December 12, 1997











     INTERNET-DRAFT        IPP/1.0: Security      June 12, 1997






     Table of Contents


     1.0 Introduction .........................................4
     2.0 Security Threats and Attacks .........................4
        2.1 Threats ...........................................5
        2.2 Methods of Attack .................................5
     3.0 Internet Printing ....................................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
           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
        5.1 Create-Job .......................................11
        5.2 Send-Document ....................................11
        5.3 Print-Job ........................................11
        5.4 Cancel-Job .......................................11
        5.5 Validate .........................................12
        5.6 Get-Jobs .........................................12
        5.7 Get-Attributes ...................................12
        5.8 Print-URI ........................................12
        5.9 Send-URI .........................................12
     6.0 Comments on Existing Security Technologies ..........12
        6.1 Recommended Security Mechanisms ..................14
     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 Authors' Addresses ..................................21
     












     DeBry, Hadsell, Manchala, Riley, Wenn             [Page 3]
                       Expires December 12, 1997











     INTERNET-DRAFT        IPP/1.0: Security      June 12, 1997








     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] and Digest Access Authentication [rfc2069]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.


     2.0 Security Threats and Attacks
     DeBry, Hadsell, Manchala, Riley, Wenn             [Page 4]
                       Expires December 12, 1997











     INTERNET-DRAFT        IPP/1.0: Security      June 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.




     DeBry, Hadsell, Manchala, Riley, Wenn             [Page 5]
                       Expires December 12, 1997











     INTERNET-DRAFT        IPP/1.0: Security      June 12, 1997






     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
     DeBry, Hadsell, Manchala, Riley, Wenn             [Page 6]
                       Expires December 12, 1997











     INTERNET-DRAFT        IPP/1.0: Security      June 12, 1997






     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.


     DeBry, Hadsell, Manchala, Riley, Wenn             [Page 7]
                       Expires December 12, 1997











     INTERNET-DRAFT        IPP/1.0: Security      June 12, 1997






     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.


     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 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 no
     security mechanisms are required to access the documents to be
     printed.


     3.4.2 Message Protection During Transmission


     DeBry, Hadsell, Manchala, Riley, Wenn             [Page 8]
                       Expires December 12, 1997











     INTERNET-DRAFT        IPP/1.0: Security      June 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).


     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], S-HTTP and PGP/MIME.


     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.


     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 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.


     Authentication: Authentication is the process of proving who a
     user or system is, and may apply to individual identities, roles,
     DeBry, Hadsell, Manchala, Riley, Wenn             [Page 9]
                       Expires December 12, 1997











     INTERNET-DRAFT        IPP/1.0: Security      June 12, 1997






     or groups. Authentication may be done with traditional methods
     such as passwords or challenge-response mechansisms, 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 person is not charged when someone issues a print request.


     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:


     DeBry, Hadsell, Manchala, Riley, Wenn             [Page 10]
                       Expires December 12, 1997











     INTERNET-DRAFT        IPP/1.0: Security      June 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 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


     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 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 combines the functions of CreateJob and SendDocument,
     therefore
     authentication, authorization, and message protection are all
     required.


     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.
     DeBry, Hadsell, Manchala, Riley, Wenn             [Page 11]
                       Expires December 12, 1997











     INTERNET-DRAFT        IPP/1.0: Security      June 12, 1997








     5.5 Validate


     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 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.


     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 asynchronous notification require any security?


     6.0 Comments on existing security technologies




     DeBry, Hadsell, Manchala, Riley, Wenn             [Page 12]
                       Expires December 12, 1997











     INTERNET-DRAFT        IPP/1.0: Security      June 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:  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.


     HTTP 1.1 Digest Access Authentication, RFC 2069:  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.


     DeBry, Hadsell, Manchala, Riley, Wenn             [Page 13]
                       Expires December 12, 1997











     INTERNET-DRAFT        IPP/1.0: Security      June 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 implementations provide the
     following, which are suitable for use with HTTP 1.1.


     - No Security - nothing is required
     - Message Protection during transmission
       - 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
     depend upon the security services provided by the Printer and the
     selection made by the client. This requires that the right
     handshake messages be passed. These are described in more detail
     in the Appendix.


     Directory and Printer attributes are required so that an end user
     can query the level of security supported, but these are yet to
     be defined.












     DeBry, Hadsell, Manchala, Riley, Wenn             [Page 14]
                       Expires December 12, 1997











     INTERNET-DRAFT        IPP/1.0: Security      June 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:
     DeBry, Hadsell, Manchala, Riley, Wenn             [Page 15]
                       Expires December 12, 1997











     INTERNET-DRAFT        IPP/1.0: Security      June 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


     DeBry, Hadsell, Manchala, Riley, Wenn             [Page 16]
                       Expires December 12, 1997











     INTERNET-DRAFT        IPP/1.0: Security      June 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:
     Kerberos
     GSS-API
     S/Key


     Handshaking protocol:
     1. Client sends data
     2. Server returns success* with additional data (challenge).
     Multiple authentication (s)* (Only one - 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 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 be done on either messages from the
     client or from the server.
     DeBry, Hadsell, Manchala, Riley, Wenn             [Page 17]
                       Expires December 12, 1997











     INTERNET-DRAFT        IPP/1.0: Security      June 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 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,
     DeBry, Hadsell, Manchala, Riley, Wenn             [Page 18]
                       Expires December 12, 1997











     INTERNET-DRAFT        IPP/1.0: Security      June 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


     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 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)




































     DeBry, Hadsell, Manchala, Riley, Wenn             [Page 19]
                       Expires December 12, 1997











     INTERNET-DRAFT        IPP/1.0: Security      June 12, 1997






     8.0 References:


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


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


     [draft-sasl] J. Myers, _Simple Authentication and Security Layer
     (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.






























































     DeBry, Hadsell, Manchala, Riley, Wenn             [Page 20]
                       Expires December 12, 1997











     INTERNET-DRAFT        IPP/1.0: Security      June 12, 1997






     9.0 Authors' Addresses


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


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


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


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


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




     Other Contributors


     Scott Isaacson, Novell
     Carl-Uno Manros, Xerox












     DeBry, Hadsell, Manchala, Riley, Wenn             [Page 21]
                       Expires December 12, 1997

--=====================_867305750==_
Content-Type: text/plain; charset="us-ascii"




Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: manros at cp10.es.xerox.com
--=====================_867305750==_--



More information about the Ipp mailing list