idnits 2.17.1 draft-ietf-ipp-security-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-29) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1.0 Introduction' ) ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 164 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [4], [5], [6], [7], [8], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 579: '...tor, IPP servers MUST generate a 401 (...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 386 has weird spacing: '...s which the...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 29, 1997) is 9740 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 627 looks like a reference -- Missing reference section? '2' on line 630 looks like a reference -- Missing reference section? '4' on line 638 looks like a reference -- Missing reference section? '5' on line 641 looks like a reference -- Missing reference section? '6' on line 644 looks like a reference -- Missing reference section? '7' on line 647 looks like a reference -- Missing reference section? '3' on line 634 looks like a reference -- Missing reference section? '8' on line 650 looks like a reference Summary: 14 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT 2 Roger deBry 3 IBM Corporation 4 Jerry Hadsell 5 IBM Corporation 6 Daniel Manchala 7 Xerox Corporation 8 Xavier Riley 9 Xerox Corporation 10 John Wenn 11 Xerox Corporation 12 July 29, 1997 14 Internet Printing Protocol/1.0: Security 15 draft-ietf-ipp-security-01.txt 17 Status of this memo 19 This document is an Internet-Draft. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its 21 areas, and its working groups. Note that other groups may also 22 distribute working documents as Internet-Drafts. Internet-Drafts 23 are draft documents valid for a maximum of six months and may be 24 updated, replaced, or obsoleted by other documents at any time. 25 It is inappropriate to use Internet-Drafts as reference material 26 or to cite them other than as "work in progress." 28 To learn the current status of any Internet-Draft, please check 29 the "1id-abstracts.txt" listing contained in the Internet-Drafts 30 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net 31 (Europe) munnari.oz.au (Pacific Rim), ds.internic.net (US East 32 Coast), or ftp.isi.edu (US West Coast). 34 Abstract 36 This document is one of a set of documents which together 37 describe all aspects of a new Internet Printing Protocol (IPP). 38 IPP is an application level protocol that can be used for 39 distributed printing on the Internet. The protocol is heavily 40 influenced by the printing model introduced in the Document 41 Printing Application (ISO/IEC 10175 DPA) standard, which 42 describes a distributed printing service. The full set of IPP 43 documents includes: 45 Requirements for an Internet Printing Protocol 46 Internet Printing Protocol/1.0: Model and Semantics 47 Internet Printing Protocol/1.0: Security 48 Internet Printing Protocol/1.0: Protocol Specification 49 Internet Printing Protocol/1.0: Directory Schema 51 This document is the `Internet Printing Protocol/1.0: Security' 52 document. 54 Table of Contents 56 1.0 Introduction .........................................4 57 2.0 Security Threats and Attacks .........................5 58 2.1 Threats ...........................................5 59 2.2 Methods of Attack .................................5 60 3.0 Internet Printing Environments........................6 61 3.1 Printer and Client in the Same Security Domain ....7 62 3.2 Printer and client in Different Security Domains ..7 63 3.3 Print-by-Reference ................................7 64 3.3.1 Unprotected Documents ........................8 65 3.3.2 Protected Documents ..........................8 66 3.4 Common Security Scenarios .........................8 67 3.4.1 No Security ..................................8 68 3.4.2 Message Protection During Transmission .......9 69 3.4.3 Client Authentication and Authorization ......9 70 3.4.4 Mutual Authentication, Authorization and Message 71 Protection ...................................9 72 4.0 Security Services ....................................9 73 5.0 Applying security to IPP operations .................11 74 5.1 Create-Job .......................................11 75 5.2 Send-Document ....................................11 76 5.3 Print-Job ........................................11 77 5.4 Cancel-Job .......................................12 78 5.5 Validate .........................................12 79 5.6 Get-Jobs .........................................12 80 5.7 Get-Attributes ...................................12 81 5.8 Print-URI ........................................12 82 5.9 Send-URI .........................................12 83 5.10 Get-Operations...................................13 84 5.11 Asynchronous Notification .......................13 85 6.0 Comments on Existing Security Technologies ..........13 86 6.1 Recommended Security Mechanisms ....................14 87 6.2 Firewall Consideration..............................15 88 7.0 References ..........................................17 89 8.0 Authors' Addresses ..................................18 90 1.0 Introduction 92 The purpose of this document is to describe security 93 considerations for the Internet Printing Protocol (IPP). Internet 94 Printing is the application of Internet technology to network 95 printing. Using Internet technology, users want to be able to 96 locate printers, install and configure printer software, query 97 printers for capabilities and status, and submit and track print 98 jobs. The Internet Printing Protocol defines the network 99 interface for many of these functions. 101 It is required that the Internet Printing Protocol be able to 102 operate within a secure environment. Wherever possible, IPP ought 103 to make use of existing security protocols and services. IPP will 104 not invent new security features when the requirements described 105 in this document can be met by existing protocols and services. 106 Examples of such services include Transport Layer Security 107 (TLS)[1] and Basic Authentication[2] and Digest Access 108 Authentication[3]in HTTP. 110 It is difficult to anticipate the security risks that might exist 111 in any given IPP environment. For example, if IPP is used within 112 a given corporation over a private network, the risks of 113 exposing print data may be low enough that the corporation will 114 choose not to use encryption on that data. However, if the 115 connection between the client and the Printer is over a public 116 network, the client may wish to protect the content of the 117 information during transmission through the network with 118 encryption. 120 Furthermore, the value of the information being printed may vary 121 from one use of the protocol to the next. Printing payroll 122 checks, for example, would have a different value than printing 123 public information from a file. 125 Since we cannot anticipate the security levels or the specific 126 threats that any given IPP print administrator may be concerned 127 with, IPP must be capable of operating with different security 128 mechanisms and security policies as required by the individual 129 installation. Security policies might vary from very strong, to 130 very weak, to none at all, and corresponding security mechanisms 131 will be required. 133 2.0 Security Threats and Attacks 135 Before discussing security services specifically as they relate 136 to IPP, it will be useful to quickly discuss and categorize 137 security threats in a general way and discuss the means by which 138 these threats are carried out. 140 2.1 Threats 142 Security threats fall into the following broad categories: 144 Resource stealing: The unauthorized use of facilities, such as 145 printers, specific printer features, media, fonts, or logos etc. 146 resulting in some value to the perpetrator. 148 Vandalism: Similar to resource stealing, but usually without gain 149 to the perpetrator. Often results in denial of service to other 150 authorized users. 152 Leakage: The acquisition of information by unauthorized 153 interceptors during transmission. 155 Tampering: The interception and altering of information during 156 transmission. 158 2.2 Methods of Attack 160 The methods by which security violations can be perpetrated 161 depend upon obtaining access to existing communication channels 162 or establishing channels that masquerade as connections to a user 163 with some desired authority. These methods are: 165 Masquerading: Submission of print jobs or performing other IPP 166 operations using the identity and password of another user 167 without their authority, or by using an access token or 168 capability after the authorization to use it has expired. 170 Eavesdropping: Obtaining copies of documents and job instructions 171 without authority, either directly from the network or by 172 examining information that is inadequately protected in storage. 174 Document tampering: Intercepting documents or other print job 175 related information and altering their contents before passing 176 them on to the printer or print server. 178 Replaying: Intercepting and storing print jobs or documents, and 179 have them submitted again later. Example: Stock Certificate 180 Printing. Protection against replaying requires the use of a 181 nonce and/or time stamp. 183 Spamming: Sending irrelevant or nonsensical print jobs or other 184 IPP operations to a printer or print server with the objective of 185 overloading the system and preventing legal users from getting 186 service. 188 Malicious Document Content Code: Sending documents that contain 189 malicious code which will bring the printer software into a loop 190 or even ruin hardware components in the print device. Example: 191 Using PostScript as a programming language to run the printer 192 into an infinite loop. 194 3.0 Internet Printing Environments 196 It is now important to understand how the threats and attacks we 197 have discussed above apply to the various environments in which 198 IPP will operate. 200 The IPP Model encapsulates the important elements required for 201 printing into three simple objects, the Printer, the Job, and the 202 Document. The Printer represents the functions associated with a 203 physical output device along with the spooling, scheduling, and 204 multiple output device management often associated with a print 205 server. An IPP client uses the IPP protocol to invoke operations 206 on IPP objects on other network nodes. 208 The initial security needs of IPP are derived from two primary 209 considerations. First, the printing environments described in 210 this document take into account the fact that the client, the 211 Printer, and the document to be printed may all exist in 212 different security domains. When objects are in different 213 security domains the requirements for authentication and message 214 protection are much stronger than when they are in the same 215 domain. 217 Secondly, the sensitivity and value of the content being printed 218 will vary. For example, a publicly available document does not 219 require the same level of privacy that a payroll document 220 requires. There are at least two parties that have an interest in 221 the value of the information being printed, the person asking to 222 have the information printed and the person who originated the 223 information. This brings into the picture the need to worry about 224 copyrights and protection of the content. 226 Security attacks are now described for the following IPP 227 environments. Where examples are provided they should be 228 considered illustrative of the environment and not an exhaustive 229 set. Not all of these environments will necessarily be addressed 230 in initial implementations of IPP. 232 3.1 Client and Printer in the Same Security Domain 234 This environment is typical of internal networks where 235 traditional office workers print the output of personal 236 productivity applications on shared work-group printers, or where 237 batch applications print their output on large production 238 printers. Although the identity of the user may be trusted in 239 this environment, a user might want to protect the content of a 240 document against such attacks as eavesdropping, replaying or 241 tampering. 243 3.2 Client and Printer in Different Security Domains 245 Examples of this environment include printing a document created 246 by the client on a publicly available printer, such as at a 247 commercial print shop; or printing a document remotely on a 248 business partner's printer. This latter operation is functionally 249 equivalent to sending the document to the business partner as a 250 facsimile. Printing sensitive information on a Printer in a 251 different security domain requires strong security measures. In 252 this environment authentication of the printer is required as 253 well as protection against unauthorized use of print resources. 254 Since the document crosses security domains, protection against 255 eavesdropping and document tampering are also required. It will 256 also be important in this environment to protect Printers against 257 spamming and malicious document content code. 259 3.3 Print by Reference 261 When the document is not stored on the client, printing can be 262 done by reference. That is, the print request can contain a 263 reference, or pointer, to the document instead of the actual 264 document itself. If the client physically gets the document 265 before it prints it, then this defaults to one of the previous 266 cases. 268 3.3.1 Unprotected Documents 270 In many cases, documents to be printed are literally available to 271 anyone. Documents, such as this Internet Draft which are stored 272 on anonymous FTP sites, are good examples of this. No security 273 mechanisms are required to protect access to these documents. 275 3.3.2 Protected Documents 277 Clearly, there are cases where the nature of a document requires 278 that access to it be protected by some authentication and/or 279 authorization mechanism, or where the right to print the document 280 must be paid for. This would be the case for sensitive or 281 confidential information, or where documents are copyrighted or 282 sold for profit. Unauthorized access to content is a major 283 concern in this environment. Protection against eavesdropping, 284 document tampering and unauthorized access to the document are 285 also concerns if the content is sensitive. 287 3.4 Common Security Scenarios 289 As discussed earlier in this document, we cannot anticipate the 290 security levels or the specific threats that any given IPP print 291 administrator may be concerned with. Security policies might vary 292 from very strong, to very weak, to none at all, and corresponding 293 security mechanisms will be required. In this section we will 294 describe what we believe to be four common usage scenarios. 296 1) No security at all 297 2) Message protection during transmission 298 3) Client authentication and authorization 299 4) Mutual authentication, authorization, and message protection 301 3.4.1 No Security 303 If the server requires no authorization and the client wants no 304 message protection the client can send the print job, i.e., the 305 job content and the job attributes without invoking any security 306 mechanisms. The printer will print the job for the client. Print 307 by reference also works well in this environment as long as no 308 security mechanisms are required to access the documents to be 309 printed. 311 3.4.2 Message Protection During Transmission 313 There are two types of security that could be used to provide 314 message protection. These are channel security and object 315 security. In the first case, the transport medium must be made 316 secure by mutual authentication. Then everything between the 317 client and server is encrypted by the transport medium. The 318 transport medium can be either of the following: transport layer 319 security (TLS) or network layer security (IPSec)[4]. 321 In the case of object security, each object is encrypted and sent 322 over either a secure or an insecure channel. The recipient has 323 the corresponding key to decrypt the object and get the contents. 324 The most widely used object security mechanisms are S/MIME [5], 325 S-HTTP [6] and PGP/MIME [7]. 327 3.4.3 Client Authentication and Authorization 329 This scenario requires client authentication which may also be 330 used for authorization. A user ID and password may be used for 331 authorization purposes, and may be encrypted by the lower 332 security layer. S/MIME and TLS are good examples of this. TLS 333 supports both one sided and mutual authentication. 335 3.4.4 Mutual Authentication, Authorization and Message Protection 337 This scenario requires mutual authentication and message 338 protection. TLS and Secure Sockets Layer version 3 (SSL3) are 339 good channel level security providers in this category. 341 4.0 Security Services 343 Now that we have described the security threats that exist in the 344 various environments in which IPP may operate, we will discuss 345 the security services that are generally available to counter 346 these threats. Security in general encompasses the software and 347 hardware functionality to deliver the following services: 349 Authorization: Only authorized users should be able to gain 350 access to systems, applications, data or services. Authorization 351 may be based on authenticated identity, location, time of day, 352 role, possession of a physical device or token, or other 353 criterion. 355 Authentication: Authentication is the process of proving who a 356 user or system is, and may apply to individual identities, roles, 357 or groups. Authentication may be done with traditional methods 358 such as passwords or challenge-response mechanisms, or with 359 publicly recognized methods such as certificates. 361 Message Protection: Access control protects data when it is 362 within a secure system environment. However, when data must 363 travel outside of a secure system, such as across a public 364 network, it needs to be protected. Message protection includes 365 the following: 367 Data origin authentication guarantees that the data originates 368 from an identified source. 370 Privacy protection guarantees that the data cannot be observed 371 except by authorized parties. 373 Integrity protection guarantees that the data cannot be 374 undetectably modified except by authorized parties. 376 Non-repudiation protection guarantees that actions taken on data 377 cannot be denied by the subjects performing those actions. 379 Liability: Responsibility of the user for the printed content. 380 This holds the user accountable for making payments, usage of 381 special resources like transparencies, color printing, etc. The 382 printer is also responsible for the services performed and will 383 be held responsible for it. 385 Provability of Service: The printer should be able to prove that 386 it performed correctly according to the job attributes which the 387 client/user had indeed issued. Example: The printer should be 388 able to prove that the job request was indeed a monochrome when 389 the user claims it issued a color copy. Provability of service 390 requires non-repudiation. 392 Payment and Accounting System: The Printer should insure that the 393 wrong person is not charged when someone issues a print request. 395 5.0 Applying Security to IPP Operations 397 An IPP client uses the IPP protocol to invoke operations on 398 remote Printer and Job objects. We now need to understand which 399 security services are required for the various IPP operations. 400 The IPP Operations are: 402 Create-Job - Create an instance of a Job object 403 Send-Document - Append enclosed data to a Job object 404 Print-Job - Print the enclosed job, with attributes 405 Cancel-Job - Cancel a previously submitted print job 406 Validate-Job - Validate attributes for a specific object 407 Get-Jobs - Return job queue information for a Printer object 408 Get-Attributes - Return attribute information for a Printer or 409 Job object 410 Print-URI - Print a document by reference 411 Send-URI - Append enclosed document reference to a Job object 412 Get-Operations - Return IPP operations supported by the server 414 Every time a new connection with a Printer Object or with a Job 415 Object is opened a new security context must established. An 416 administrator may set up different security requirements for 417 different operations, i.e. a user may be able to query a printer, 418 but not submit a job. Once a Job is created, the same (or 419 greater) level of security will be required to perform additional 420 operations on that job. 422 5.1 Create-Job 424 When creating a print job, authentication of the client and the 425 Printer are primary security considerations. Client 426 authentication, along with authorization, protects against 427 unauthorized use of print resources. Printer authentication 428 guarantees the identity of the remote Printer. 430 5.2 Send-Document 432 When sending document content to the Printer, message protection 433 is the primary security service required. 435 5.3 Print-Job 437 Print-Job combines the functions of Create-Job and Send-Document, 438 therefore authentication, authorization, and message protection 439 are all required. 441 5.4 Cancel-Job 443 Cancel-Job is only used to cancel a job. An end user may only be 444 allowed to cancel his or her own print jobs. Therefore 445 authentication is required to protection against unauthorized 446 cancellation of a job. 448 5.5 Validate-Job 450 Validate is used to validate the attributes of a remote object. 451 Administrators may choose to restrict the ability for certain end 452 users to see the attributes of a Printer, so authentication and 453 authorization are required services. 455 5.6 Get-Jobs 457 The level of security associated with the Get-Jobs operation 458 depends on the policy set by an administrator. One common policy 459 is for the complete job queue to be returned to anyone who asks. 460 This policy requires no security. For more secure Printers, a 461 common policy is to list details only on the print jobs owned by 462 the end user, while giving little or no details about other jobs. 463 This policy requires client authentication and authorization to 464 match the client to the print jobs. 466 5.7 Get-Attributes 468 An administrator should be able to establish the level of 469 security associated with getting the attributes of a printer. 470 How security affects which attributes are returned is a policy 471 decision and outside the scope of IPP. 473 5.8 Print-URI 475 Print-URI is like Print-Job except that only a reference to the 476 document to be printed is sent in the request. Thus the Printer 477 must fetch the document from the given URI in order to print the 478 job. In IPP version 1.0 we only allow unprotected (see section 479 3.3.1) documents to be printed by reference. Additional, as yet 480 undefined security mechanisms are required to print a protected 481 document by reference. 483 5.9 Send-URI 485 Send-URI is like send-Document except that only a reference to 486 the document to be printed is sent in the request. This operation 487 has the same security concerns as Print-URI. 489 5.10 Get-Operations 491 An administrator should be able to establish the level of 492 security required for someone to see the operations supported on 493 a Printer. 495 5.11 Asynchronous Notification 497 When submitting a print job, a user may include an attribute 498 which describes the address and method to be used for notifying 499 the user of Printer events such as job completion. Notification 500 is outside the scope of IPP and includes such methods as email 501 and ftp. When security mechanisms are employed in delivering 502 asynchronous notifications, security levels should be consistent 503 with those used in submitting the original print job. 505 6.0 Comments on existing security technologies 507 TLS - Transport Layer Security: Seems OK, is near completion in 508 the IETF and existing SSL product are probably compliant, or can 509 be made compliant without much effort. TLS Provides channel level 510 security. 512 SSL 2 and SSL 3 - Secure Socket Layer: Proprietary solution 513 initially by Netscape, but TLS is very close. Provides channel 514 level security. 516 PGP/MIME - Pretty Good Privacy MIME variant: The original PGP is 517 widely deployed (but not much liked by the US government). The 518 PGP/MIME version is now being worked on but is still not out, not 519 yet stable, and not yet implemented and deployed. PGP/MIME 520 provides object level security. 522 S/MIME - Secure MIME: Currently a private implementation from 523 RSA. Although coming out as product from a number of vendors, 524 unlikely to make it on the IETF standards track unless RSA 525 decides to release their proprietary products as open standards. 526 S/MIME provides object level security. 528 SASL - Simple Authentication and Session Layer [7]: This 529 security feature negotiation protocol and does not provide any 530 security services in itself. Hence quite limited usefulness for 531 IPP. 533 HTTP 1.1 Digest Access Authentication: This provides 534 some limited security services, mainly only client side 535 authentication. It transmits a cryptographic digest derived from 536 the user name, password, and a server generated challenge. 538 SHTTP - Secure HTTP: Although on the IETF standards track, this 539 seems to lack some important features and does not seem to go 540 anywhere in the market place. 542 IPSec - IP Security is an IETF standards track protocol for 543 security on the IP layer. It consists of two separate mechanisms. 544 The IP Authentication Header (AH) and the IP Encapsulating 545 Security Payload (ESP). They can be used together or separately. 546 The IP Authentication header provides integrity and 547 authentication of IP datagrams. The IP Encapsulating Security 548 Payload provides integrity, authentication and privacy. IPSec 549 allows for either host keys or user keys to be used in security. 550 IPSec can satisfy the IPP requirements for integrity and privacy. 551 IPP Authentication, however, would require both IPSec use user 552 keys and that the IPP application request use their own IPSec 553 security association. Both requirements are recommended by IPSec 554 but are not required. 556 6.1 Recommended Security Mechanisms 558 IPP implementations should provide a range of security options to 559 meet the needs of different installations and user populations. 560 The specific security services employed will be established by a 561 site administrator. The mechanisms used to establish these 562 services and to define user IDs and passwords to the system are 563 implementation defined and outside the scope of IPP. 565 The security protocol used by a particular IPP operation will 566 depend upon the security services implemented on the Printer, the 567 security policy established by a site administrator, and the 568 selection made by the client. This requires that the right 569 handshake messages be passed to invoke the selected security 570 service. These are described in the references for each security 571 mechanism and are normally invoked by the client. Two printer 572 attributes, message-protection-supported and authentication- 573 authorization-supported are provided to help the end user know 574 what to expect in terms of security. These attributes should also 575 appear in the directory entry for each Printer. 577 When utilizing HTTP 1.1 as a transport for IPP, the security 578 considerations outlined in HTTP 1.1 apply. When set by an 579 administrator, IPP servers MUST generate a 401 (Unauthorized) 580 response code to request client authentication and IPP clients 581 should correctly respond with the proper Authorization header. 582 Both basic authentication and digest authentication flavors of 583 authentication should be supported. The administrator chooses 584 which type(s) of authentication to accept. Digest authentication 585 is a more secure method and is always preferred to basic 586 authentication. 588 For secure communication (privacy in particular), IPP should be 589 run using a secure communications channel. Both TLS and IPSec 590 provide secure communications channels and provide for mutual 591 authentication. The secure communications channel must be 592 initiated prior to running the IPP protocol. There is no 593 mechanism for bootstrapping a secure communication channel from 594 within the IPP protocol itself. 596 It is possible to combine a secure communication channel with 597 either Basic or Digest Authentication. 599 6.2 Firewall Considerations 601 Firewalls mostly play a role of enforcing corporate security 602 policies, beyond that established for individual servers within 603 the firewall. For example, an IPP Printer may be set up to report 604 back features to anyone. This is allowable as long as the user 605 is behind the firewall, but may be prohibited if the user is 606 outside of the firewall. 608 Thus, the firewall acts as a proxy for all IPP Printers behind 609 the firewall and intercepts all incoming HTTP POSTs from the 610 outside. Firewall software may then respond appropriately, based 611 on the established security policy: It could pass the message 612 along to the Printer, close the connection, or respond with some 613 error response. This could be done on an operation by operation 614 basis. Likewise, the IPP Printer responses would be filtered by 615 the firewall software before passing them back to the external 616 client. 618 Firewall software could additionally filter requests based on job 619 attributes, so, for example, only jobs specifying a single copy 620 or only duplex jobs could be printed. However, it is very 621 unlikely that firewall software would check for features 622 specified in the actual document content, i.e. in the page 623 description language. 625 7.0 References: 627 [1] T. Dierks, C. Allen, "The TLS Protocol", , March 24, 1997. 630 [2] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, 631 T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", 632 RFC 2068, January 1997 634 [3] J. Franks, P. Hallam-Baker, J. Hostetler, P. Leach, A. 635 Luotonen, E. Sink, L. Stewart, "An Extension to HTTP: Digest 636 Access Authentication", RFC-2069, Jan 1997. 638 [4] R. Atkinson, "Security Architecture for the Internet 639 Protocol, RFC 1825", August 1995 641 [5] S. Dusse, "S/MIME Message Specification", , March 1997 647 [7] M. Elkins, "MIME Security with Pretty Good Privacy (PGP)" 648 RFC 2015, October 1996 650 [8] J. Myers, "Simple Authentication and Security Layer 651 (SASL)", , April 1997. 653 8.0 Authors' Addresses 655 Roger deBry 656 HUC/003G 657 IBM Corporation 658 P.O. Box 1900 659 Boulder, CO 80301-9191 660 rdebry@us.ibm.com 662 Jerry Hadsell 663 1130 664 IBM Corporation 665 Rt. 100 666 Somers, N.Y. 10589 667 hadsell@us.ibm.com 669 Daniel Manchala 670 Xerox Corporation 671 701 Aviation Blvd. 672 El Segundo, CA 90245 673 manchala@cp10.es.xerox.com 675 Xavier Riley 676 Xerox Corporation 677 701 Aviation Blvd. 678 El Segundo, CA 90245 679 xriley@cp10.es.xerox.com 681 John Wenn 682 Xerox Corporation 683 701 Aviation Blvd. 684 El Segundo, CA 90245 685 jwenn@cp10.es.xerox.com 687 Other Contributors 689 Scott Isaacson, Novell 690 Carl-Uno Manros, Xerox