idnits 2.17.1 draft-debry-ipp-sec-00.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-04-19) 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 == The page length should not exceed 58 lines per page, but there was 11 longer pages, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 177 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 387 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 (September 25, 1997) is 9703 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: '11' is mentioned on line 460, but not defined == Missing Reference: '12' is mentioned on line 489, but not defined == Missing Reference: '13' is mentioned on line 521, but not defined == Missing Reference: '14' is mentioned on line 551, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Unexpected draft version: The latest known version of draft-hickman-netscape-ssl is -00, but you're referring to -01. -- Possible downref: Normative reference to a draft: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 1777 (ref. '6') (Obsoleted by RFC 3494) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '7') -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Obsolete normative reference: RFC 2069 (ref. '9') (Obsoleted by RFC 2617) Summary: 15 errors (**), 0 flaws (~~), 7 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET_DRAFT 3 4 Roger deBry 5 IBM Corporation 6 Jerry Hadsell 7 IBM Corporation 8 Daniel Manchala 9 Xerox Corporation 10 Xavier Riley 11 Xerox Corporation 13 March 25, 1997 Expires September 25, 1997 15 Internet Printing Protocol/1.0: Security 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 areas, 21 and its working groups. Note that other groups may also distribute 22 working documents as Internet-Drafts. Internet-Drafts are draft 23 documents valid for a maximum of six months and may be updated, 24 replaced, or obsoleted by other documents at any time. It is 25 inappropriate to use Internet-Drafts as reference material or 26 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 (Europe), 31 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 32 ftp.isi.edu (US West Coast). 34 Abstract 36 This document is one of a set of documents which together describe 37 all aspects of a new Internet Printing Protocol (IPP). IPP is an 38 application level protocol that can be used for distributed 39 printing on the Internet. The protocol is heavily influenced by 40 the printing model introduced in the Document Printing Application 41 (ISO/IEC 10175 DPA) standard, which describes a distributed printing 42 service. The full set of IPP documents includes: 44 Internet Printing Protocol/1.0: Requirements 45 Internet Printing Protocol/1.0: Model and Semantics 46 Internet Printing Protocol/1.0: Security 47 Internet Printing Protocol/1.0: Protocol Specification 48 Internet Printing Protocol/1.0: Directory Schema 50 deBry draft-debry-ipp-sec-00.txt [1] 51 This document deals with the security considerations for IPP. 53 Table of Contents 55 1.0 Introduction 57 2.0 Internet Printing Environments 58 2.1 Client, content and printer in the same security domain 59 2.2 Client and printer in one security domain, content in another 60 2.3 Client and content in one security domain, printer in another 61 2.4 Printer and content in one security domain, client in another 62 2.5 Printer, content and client all in different security domains 63 3.0 Security Services 64 3.1 Basic concepts 65 3.5 Miscellaneous 66 4.0 IPP Security threats and methods of attack 67 4.1 Threats 68 4.2 Methods of attack 69 4.3 Quality of service 70 5.0 Attacks vs. security services 71 6.0 Quality of service vs. security services 72 7.0 Required security services provided by current security methods 73 8.0 Further references. 74 9.0 Author's Address 75 10.0 Other Contributors 77 1.0 Introduction 79 It is required that the Internet Printing Protocol be able to operate 80 within a secure environment. Wherever possible, IPP ought to make use 81 of existing security protocols and services. IPP will not invent new 82 security features when the requirements described in this document can 83 be met by existing protocols and services. Examples of such services 84 include Secure Sockets (SSL), Digest Access Authentication in HTTP, 85 and the Content MD-5 Header Field in MIME. 87 It is difficult to anticipate the security risks that might exist in 88 any given IPP environment. For example, if IPP is used within a given 89 corporation over a private network, the risks of exposing print data 90 may be low enough that the corporation will choose to not use 91 encryption on that data. However, if the connection between the 92 client and the Printer is over a public network, the client may wish 93 to protect the content of the information during transmission through 94 the network with encryption. 96 Furthermore, the value of the information being printed may vary from 97 one use of the protocol to the next. Printing payroll checks, for 99 deBry draft-debry-ipp-sec-00.txt [2] 100 example, might have a different value than printing public information 101 from a file. 103 Since we cannot anticipate the security levels or the specific threats 104 that any given IPP print administrator may be concerned with, IPP must 105 be capable of operating with different security mechanisms and 106 security policies as required by the individual installation. Security 107 policies might vary from very strong, to very weak, to none at all, 108 and corresponding security mechanisms will be required. 110 This document will describe the various environments within which IPP 111 must operate. It will then introduce security related terminology used 112 in this document, describe the various security services available and 113 the possible threats and methods of attack. Finally, it will provide a 114 mapping of threats to services and discuss how existing security 115 methods address these requirements. 117 2.0 Internet Printing Environments 119 The printing environments described in this section must take into 120 account the fact that the client, the Printer, and the document to be 121 printed may all exist in separate security domains. This is 122 complicated by the fact that IPP allows documents to be included in 123 the print request or they may be printed by reference. When printing 124 by reference a Printer may fetch the document from the client, but 125 more often the document will be on another network node. Furthermore, 126 there are at least two parties that have an interest in the value of 127 the information being printed: 129 the client: the person asking to have the information printed 131 the author: the person who originated the information. This brings 132 into the picture the need to worry about copyrights and protection 133 of the content. 135 This requires consideration of the following Internet printing 136 environments. Where examples are provided they should be considered 137 illustrative of the environment and not an exhaustive set. 139 2.1 Client, Content and Printer in the same security domain 141 This environment would be typical of the traditional office where 142 users print the output of office applications on shared work-group 143 printers, or where batch applications print their output on large 144 production printers. Documents may be included in a print request 146 deBry draft-debry-ipp-sec-00.txt [3] 147 or printed by reference. Depending upon company policies security 148 could range from none to very secure. 150 2.2 Client and Printer in one security domain, Content in another 152 In this environment, printing can only be done by reference (If the 153 client has already obtained the content, then it is in the client's 154 security domain). Examples of this environment include printing a 155 document, such as software documentation, from a publicly available 156 source on the Internet; or a copy of a contract or purchase order from 157 a business partner, on a local Printer. Controlling access to content 158 would be a major concern in this environment. 160 2.3 Client and Content in one security domain, Printer in another 162 Examples of this environment include printing a document created by 163 the client on a publicly available printer, such as at a commercial 164 print shop; or printing a contract on a business partner's printer. 165 This latter operation would be functionally equivalent to sending the 166 contract to the business partner as a facsimile. Documents may be 167 included in the print request or printed by reference. Some 168 credentials are required for the printer to fetch a document not in 169 it's security domain. 171 2.4 Printer and Content in one security domain, Client in another 173 Printing in this environment is by reference only. Examples would 174 include an employee at home connecting to his office through the 175 Internet to print a document on a printer at work, or a student 176 using the Internet to connect to the college library and asking 177 to have the results of a literature search printed on the library's 178 printer. Authentication of the user and controlling access to print 179 resources would be major concerns in this environment. 181 2.5 Printer, Content, and Client all in different security domains 183 Printing in this environment is by reference only. Examples include a 184 person at home using the Internet to print a document from a remote 185 site, at a commercial print shop. Authentication and controlling 186 access to content and to print resources would be concerns in this 187 environment. 189 deBry draft-debry-ipp-sec-00.txt [4] 190 3.0 Security Services 192 This section introduces common security terms used in this paper. 194 3.1 Basic Concepts 196 AAA: Overall term for security. The three A's are generally taken to 197 be 199 Authentication, Authorization, and Auditing although it may mean 200 Authentication, Authorization & Accounting in some contexts. 202 Security Domain: Security domain refers to the domain within which a 203 specific set of security policies and mechanisms define access to 204 resources within that domain. 206 Authentication: The process of reliably determining the identity of a 207 communicating party. There are three classic ways of authenticating 208 oneself: something you know, something you have and something you are. 209 The two entities involved in the communication could use the following 210 two ways to authenticate themselves. 212 Single entity authentication. Only one of the entities is 213 authenticated by the other. In the case of IPP this may either by the 214 end user or the Printer. 216 Mutual authentication. Both the parties authenticate each other. 218 Authorization: The granting of rights to a user, program or process to 219 access a resource such as a Printer. Authorization may also apply to 220 content being printed or to protect a resource from unauthorized use. 221 This can be achieved by the use of access control lists (ACL) or 222 capabilities. 224 Auditing: Keep a record of events that might have some significance, 225 such as when a Printer is used and by whom. To record independently 226 and later examine system activity. Audit data is generally used for 227 security concerns (e.g. intrusion detection and consistency checks). 229 Accounting: Keep a record of events that might have some significance, 230 such as when access to a Printer occurred, who accessed it, what print 231 resources were used. Accounting data is generally used for commercial 232 concerns (e.g. billing and charges). 234 deBry draft-debry-ipp-sec-00.txt [5] 235 3.2 Security Service Attributes 237 Anonymity: The ability to communicate so that the other principal 238 can't find out the identity of the sender. 240 Integrity: Keeping information from corruption or unauthorized 241 modification either maliciously or accidentally. Integrity protects 242 against forgery or tampering. Many document printing applications, 243 such as payroll, absolutely require integrity. 245 Non-Repudiation: There is proof who sent a message that a recipient 246 can show to a third party and the third party can independently verify 247 the source. 249 Confidentiality: Protection from the unauthorized disclosure of print 250 data, both during transport, in storage, and on the printer. 252 3.3 Encryption Concepts 254 Encryption: To scramble information so that only someone knowing the 255 appropriate secret can obtain the original information. This might 256 apply to the document being printed, or to the entire print request. 258 Nonce: In order to prevent an attacker from launching a replay attack, 259 a very large random number or sequence number that is different every 260 time the cryptographic protocol is run is used. A nonce can also be 261 created from a time stamp that indicates the current date and time 262 up to milliseconds accuracy. 264 Public Key: Dual key (RSA/PGP style) cryptography. Uses two different 265 keys, either one for encryption and the other for decryption. Also 266 called a asymmetric cryptography. 268 Secret Key: Single key cryptography. Also called symmetric 269 cryptography. 271 Session Key: A short lived Secret Key used by two principals for the 272 purpose of secure communications between them. 274 3.4 Authorization Concepts 276 ACL: Access Control List. A list of the subjects authorized to access 277 a Printer, a print resource, or a document. The list usually indicates 278 what type of access is allowed for each user. 280 deBry draft-debry-ipp-sec-00.txt [6] 281 Groups: A named set of users, created for convenience in stating 282 authorization policy. 284 Roles: A specific function a principal plays with respect to another 285 principal. Examples include a print administrator, a printer operator, 286 or an end-user. If a principal has multiple functions with respect to 287 another principal, it has multiple roles (e.g. A person can have both 288 administrator and operator roles for a Printer). 290 Capability: An identifier that specifies an object, such as a Printer, 291 and the access rights for the subject who possess the capability. See 292 also "Certificate / Ticket / Token" 294 Proxy Agent: A principal that has been authorized to work on the 295 behalf of another. 297 Proxy: A token that grants the rights of a principal to another. 299 Restricted Proxy: A token that grants the rights of a principal to 300 another while placing restrictions on the privileges granted. 302 Certificate / Ticket / Token: Different names for a object used to 303 grant privileges. While these terms have individual meanings in 304 specific contexts (Kerberos generates tickets, physical objects 305 are tokens), there is no general agreement on how they differ. 306 We will use Certificate / Ticket / Token largely interchangeably. 307 Capability & Proxy are related terms, but with narrower focus. 309 CRL: Certificate Revocation List. A list of revoked certificates. 311 3.5 Miscellaneous 313 Denial of Service: An action that prevents a system or its 314 resources from functioning efficiently and reliably. 316 4.0 IPP Security Threats and Methods of Attack 318 The purpose of a security system is to restrict access to information 319 and resources to just those users which are authorized to have access. 320 To produce a system that is demonstrably secure against specific 321 threats, it is useful to classify the threats and methods of attack by 322 which each of them may be achieved. 324 deBry draft-debry-ipp-sec-00.txt [7] 325 4.1 Threats 327 Security threats for IPP fall into the following broad categories: 329 Resource stealing: The unauthorized use of facilities, such as 330 printers, specific printer features, media, fonts, or logos etc. 331 resulting in some value to the perpetrator. 333 Vandalism: Similar to resource stealing, but usually without gain to 334 the perpetrator. Often results in denial of service to other 335 authorized users. 337 Leakage: The acquisition of information by unauthorized interceptors 338 during transmission. 340 Tampering: The interception and altering of information during 341 transmission. 343 4.2 Methods of Attack 345 The methods by which security violations can be perpetrated in the IPP 346 environment depend upon obtaining access to existing communication 347 channels or establishing channels that masquerade as connections to 348 a user with some desired authority. These methods are: 350 Masquerading: Submission of print jobs or performing other IPP 351 operations using the identity and password of another user without 352 their authority, or by using an access token or capability after the 353 authorization to use it has expired. 355 Eavesdropping: Obtaining copies of documents and job instructions 356 without authority, either directly from the network or by examining 357 information that is inadequately protected in storage. 359 Document tampering: Interception documents or other print job related 360 information and altering their contents before passing them on to the 361 printer or print server. 363 Replaying: Intercepting and storing print jobs or documents, and have 364 them submitted again later. Example: Stock Certificate Printing. 366 Spamming: Sending irrelevant or nonsensical print jobs or other IPP 367 operations to a printer or print server with the objective of 368 overloading the system and prevent legal users to get service. 370 Malicious Document Content Code: Sending documents that contain 372 deBry draft-debry-ipp-sec-00.txt [8] 373 malicious code which will bring the printer software into a loop 374 or even ruin hardware components in the print device. Example: Using 375 PostScript as a programming language to run the printer into an 376 infinite loop. 378 4.3 Quality of Service 380 Liability: Responsibility of the user for the printed content. This 381 holds the user accountable for making payments, usage of special 382 resources like transparencies, color printing, etc. The printer is 383 also responsible for the services performed and will be held 384 responsible for it. 386 Provability of Service: The printer should be able to prove that it 387 performed correctly according to the job attributes which the 388 client/user had indeed issued. Example: The printer should be able 389 to prove that the job request was indeed a monochrome when the user 390 claims it issued a color copy. 392 Payment and Accounting System: It is a mistake to charge the wrong 393 person when someone has issued a print request. 395 deBry draft-debry-ipp-sec-00.txt [9] 396 5.0 Attacks Vs. Security Services 398 The following table defines how the services described here address 399 security attacks. A (C) in the table refers to client side services, 400 an (S) server side services. CA = Client Authentication, SA = Server 401 Authentication, DC = Data Confidentiality, DI = Data Integrity, NR = 402 Non-repudiation, TS = Time Stamp and Nonce. 404 Attacks\Services CA SA DC DI NR TS 406 Masquerading 407 1. User/Client Yes 408 (Incorrect source - 409 misuse of resources) 411 2. Printer/Server Yes Yes Yes (S) 412 (Incorrect destination) 414 Eavesdropping Yes 416 Document Tampering 417 1. incorrect rendering Yes 418 of data and job attributes 420 2. guarantee security Yes Yes 421 marks (watermarking, 422 fingerprinting, security 423 banners) 425 Replaying Yes 427 Denial of Service Yes Yes(C) Yes 428 (Spamming) 430 Document Malicious 431 Content Code 432 1. corruption of hardware Yes Yes Yes 433 resources 434 2. corruption of printer Yes Yes 435 software 437 deBry draft-debry-ipp-sec-00.txt [10] 438 6.0 Quality of Service vs. Security Services 440 The following table defines how the services described here address 441 security attacks. A (C) in the table refers to client side services, 442 an (S) server side services. CA = Client Authentication, SA = Server 443 Authentication, DC = Data Confidentiality, DI = Data Integrity, NR = 444 Non-repudiation, TS = Time Stamp and Nonce. 446 Qual of Service/Services CA SA DC DI NR TS 448 Liability for 449 1. printed content Yes Yes 450 2. for services Yes Yes 451 performed 453 Provability of Yes(S) Yes 454 service 456 Defeating payment Yes Yes(C) Yes 457 or accounting 458 system 460 deBry draft-debry-ipp-sec-00.txt [11] 461 7.0 Required Security Services provided by current security methods 463 The following table describes how current security methods address 464 the requirements discussed in this paper. Security methods would be 465 invoked by standard means, i.e. IPP would use the URL 466 https://www.xyz.com/printer-1 to name a printer that requires SSL. 468 Requirements HTTP/1.1 SSL (V2) SSL (V3) LDAP 469 Authentication 470 single entity Yes Yes No 471 mutual No No Yes 473 Authorization 474 ACL -- -- -- 475 Capability -- -- -- 477 Non-repudiation 479 Integrity -- Yes Yes 481 Confidentiality -- Yes Yes 483 Administration 484 Certificate 485 Mgmt. -- -- -- Yes 487 Secure Comm. 489 deBry draft-debry-ipp-sec-00.txt [12] 490 8.0 References 492 [1] C. Kaufmann, R. Perlman and M. Speciner, Network Security 494 [2] D. Russell and G.T. Gabgemi Sr., Computer Security Basics 496 [3] A. Freier, P. Karlton and P. Kocher, The SSL Protocol Version 3.0, 498 [4] K. Hickman and T. Elgamal, The SSL Protocol, Internet Draft < 499 draft-hickman-netscape-ssl-01.txt> (deleted), February 1995 501 [5] X.500: The Directory -- Overview of Concepts, Models, and Service, 502 CCITT Recommendation X.500, December 1988 504 [6] W. Yeoung, T. Howes, and S. Kille, Lightweight Directory Access 505 Protocol, RFC 1777, 03/28/1995. (Work is alos underway in the 506 IETF to produce an extended version of LDAP.) 508 [7] R. Rivest, The MD5 Message Digest Algorithm, RFC 1321, April 1992 510 [8] M. Mahl, T. Howes, S. Kille, Lightweight Directory Access Protocol 511 (v3), Work in progress, Internet Draft 512 , October 22, 1996 514 [9] J, Franks, P. Hallam-Baker, J. Hostetler, P. Leach, A. Luotonen, 515 E. Sink, and L. Stewart, An Extension to HTTP: Digest Access 516 Authentication, RFC 2069, January 1997 518 [10] J. Myers and M. Rose, The Content MD-5 Header Field, RFC 1864, 519 October 1995 521 deBry draft-debry-ipp-sec-00.txt [13] 522 9.0 Author's Address 524 Roger deBry 525 HUC/003G 526 IBM Corporation 527 P.O. Box 1900 528 Boulder, CO 80301-9191 530 Jerry Hadsell 531 1130 532 IBM Corporation 533 Rt. 100 534 Somers, N.Y. 10589 536 Daniel Manchala 537 Xerox Corporation 538 701 Aviation Blvd. 539 El Segundo, CA 90245 541 Xavier Riley 542 Xerox Corporation 543 701 Aviation Blvd. 544 El Segundo, CA 90245 546 10.0 Other Contributors 548 Scott Isaacson 549 Carl-Uno Manros 551 deBry draft-debry-ipp-sec-00.txt [14]