idnits 2.17.1 draft-ietf-ipp-security-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-26) 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 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 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 400 has weird spacing: '...s which the...' == Line 652 has weird spacing: '...edge of each ...' -- 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 (June 12, 1997) is 9815 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) No issues found here. Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT 3 Roger deBry 4 IBM Corporation 5 Jerry Hadsell 6 IBM Corporation 7 Daniel Manchala 8 Xerox Corporation 9 Xavier Riley 10 Xerox Corporation 11 John Wenn 12 Xerox Corporation 13 June 12, 1997 15 Internet Printing Protocol/1.0: Security 16 draft-ietf-ipp-security-00.txt 18 Status of this memo 20 This document is an Internet-Draft. Internet-Drafts are working 21 documents of the Internet Engineering Task Force (IETF), its 22 areas, and its working groups. Note that other groups may also 23 distribute working documents as Internet-Drafts. Internet-Drafts 24 are draft documents valid for a maximum of six months and may be 25 updated, replaced, or obsoleted by other documents at any time. 26 It is inappropriate to use Internet-Drafts as reference material 27 or to cite them other than as "work in progress." 29 To learn the current status of any Internet-Draft, please check 30 the "1id-abstracts.txt" listing contained in the Internet-Drafts 31 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net 32 (Europe), 33 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 34 ftp.isi.edu (US West Coast). 36 Abstract 38 This document is one of a set of documents which together 39 describe all aspects of a new Internet Printing Protocol (IPP). 40 IPP is an application level protocol that can be used for 41 distributed printing on the Internet. The protocol is heavily 42 influenced by the printing model introduced in the Document 43 Printing Application (ISO/IEC 10175 DPA) standard, which 44 Expires December 12, 1997 45 describes a distributed printing service. The full set of IPP 46 documents includes: 48 Internet Printing Protocol/1.0: Requirements 49 Internet Printing Protocol/1.0: Model and Semantics 50 Internet Printing Protocol/1.0: Security 51 Internet Printing Protocol/1.0: Protocol Specification 52 Internet Printing Protocol/1.0: Directory Schema 54 This documentis the `Internet Printing Protocol/1.0: Security' 55 document. 57 Expires December 12, 1997 58 Table of Contents 60 1.0 Introduction .........................................4 61 2.0 Security Threats and Attacks .........................4 62 2.1 Threats ...........................................5 63 2.2 Methods of Attack .................................5 64 3.0 Internet Printing ....................................6 65 3.1 Printer and Client in the Same Security Domain ....7 66 3.2 Printer and client in Different Security Domains ..7 67 3.3 Print-by-Reference ................................7 68 3.3.1 Unprotected Documents ........................8 69 3.3.2 Protected Documents ..........................8 70 3.4 Common Security Scenarios .........................8 71 3.4.1 No Security ..................................8 72 3.4.2 Message Protection During Transmission .......8 73 3.4.3 Client Authentication and Authorization ......9 74 3.4.4 Mutual Authentication, Authorization and Message 75 Protection ...................................9 76 4.0 Security Services ....................................9 77 5.0 Applying security to IPP operations .................10 78 5.1 Create-Job .......................................11 79 5.2 Send-Document ....................................11 80 5.3 Print-Job ........................................11 81 5.4 Cancel-Job .......................................11 82 5.5 Validate .........................................12 83 5.6 Get-Jobs .........................................12 84 5.7 Get-Attributes ...................................12 85 5.8 Print-URI ........................................12 86 5.9 Send-URI .........................................12 87 6.0 Comments on Existing Security Technologies ..........12 88 6.1 Recommended Security Mechanisms ..................14 89 7.0 Appendix - Specific Features of Various Technologies 15 90 7.1 S/MIME: (Secure/Multipurpose Internet Mail Ext.)..15 91 7.2 Transport Layer Security 1.0 (TLS) ...............15 92 7.3 SASL (Simple Authentication and Security Layer) ..16 93 7.4 Digest Access Authentication .....................17 94 8.0 References ..........................................20 95 9.0 Authors' Addresses ..................................21 97 Expires December 12, 1997 98 1.0 Introduction 100 The purpose of this document is to describe security 101 considerations for the Internet Printing Protocol (IPP). Internet 102 Printing is the application of Internet technology to network 103 printing. Using Internet technology, users want to be able to 104 locate printers, install and configure printer software, query 105 printers for capabilities and status, and submit and track print 106 jobs. The Internet Printing Protocol defines the network 107 interface for many of these functions. 109 It is required that the Internet Printing Protocol be able to 110 operate within a secure environment. Wherever possible, IPP ought 111 to make use of existing security protocols and services. IPP will 112 not invent new security features when the requirements described 113 in this document can be met by existing protocols and services. 114 Examples of such services include Transport Layer Security 115 (TLS)[draft-tls] and Digest Access Authentication [rfc2069]in 116 HTTP. 118 It is difficult to anticipate the security risks that might exist 119 in any given IPP environment. For example, if IPP is used within 120 a given corporation over a private network, the risks of 121 exposing print data may be low enough that the corporation will 122 choose not to use encryption on that data. However, if the 123 connection between the client and the Printer is over a public 124 network, the client may wish to protect the content of the 125 information during transmission through the network with 126 encryption. 128 Furthermore, the value of the information being printed may vary 129 from one use of the protocol to the next. Printing payroll 130 checks, for example, would have a different value than printing 131 public information from a file. 133 Since we cannot anticipate the security levels or the specific 134 threats that any given IPP print administrator may be concerned 135 with, IPP must be capable of operating with different security 136 mechanisms and security policies as required by the individual 137 installation. Security policies might vary from very strong, to 138 very weak, to none at all, and corresponding security mechanisms 139 will be required. 141 2.0 Security Threats and Attacks 142 Expires December 12, 1997 143 Before discussing security services specifically as they relate 144 to IPP, it will be useful to quickly discuss and categorize 145 security threats in a general way and discuss the means by which 146 these threats are carried out. 148 2.1 Threats 150 Security threats fall into the following broad categories: 152 Resource stealing: The unauthorized use of facilities, such as 153 printers, specific printer features, media, fonts, or logos etc. 154 resulting in some value to the perpetrator. 156 Vandalism: Similar to resource stealing, but usually without gain 157 to the perpetrator. Often results in denial of service to other 158 authorized users. 160 Leakage: The acquisition of information by unauthorized 161 interceptors during transmission. 163 Tampering: The interception and altering of information during 164 transmission. 166 2.2 Methods of Attack 168 The methods by which security violations can be perpetrated 169 depend upon obtaining access to existing communication channels 170 or establishing channels that masquerade as connections to a user 171 with some desired authority. These methods are: 173 Masquerading: Submission of print jobs or performing other IPP 174 operations using the identity and password of another user 175 without their authority, or by using an access token or 176 capability after the authorization to use it has expired. 178 Eavesdropping: Obtaining copies of documents and job instructions 179 without authority, either directly from the network or by 180 examining information that is inadequately protected in storage. 182 Document tampering: Intercepting documents or other print job 183 related information and altering their contents before passing 184 them on to the printer or print server. 186 Expires December 12, 1997 187 Replaying: Intercepting and storing print jobs or documents, and 188 have them submitted again later. Example: Stock Certificate 189 Printing. Protection against replaying requires the use of a 190 nonce and/or time stamp. 192 Spamming: Sending irrelevant or nonsensical print jobs or other 193 IPP operations to a printer or print server with the objective of 194 overloading the system and preventing legal users from getting 195 service. 197 Malicious Document Content Code: Sending documents that contain 198 malicious code which will bring the printer software into a loop 199 or even ruin hardware components in the print device. Example: 200 Using PostScript as a programming language to run the printer 201 into an infinite loop. 203 3.0 Internet Printing Environments 205 It is now important to understand how the threats and attacks we 206 have discussed above apply to the various environments in which 207 IPP will operate. 209 The IPP Model encapsulates the important elements required for 210 printing into three simple objects, the Printer, the Job, and the 211 Document. The Printer represents the functions associated with a 212 physical output device along with the spooling, scheduling, and 213 multiple output device management often associated with a print 214 server. An IPP client uses the IPP protocol to invoke operations 215 on IPP objects on other network nodes. 217 The initial security needs of IPP are derived from two primary 218 considerations. First, the printing environments described in 219 this document take into account the fact that the client, the 220 Printer, and the document to be printed may all exist in 221 different security domains. When objects are in different 222 security domains the requirements for authentication and message 223 protection are much stronger than when they are in the same 224 domain. 226 Secondly, the sensitivity and value of the content being printed 227 will vary. For example, a publicly available document does not 228 require the same level of privacy that a payroll document 229 requires. There are at least two parties that have an interest in 230 the value of the information being printed, the person asking to 231 have the information printed and the person who originated the 232 Expires December 12, 1997 233 information. This brings into the picture the need to worry about 234 copyrights and protection of the content. 236 Security attacks are now described for the following IPP 237 environments. Where examples are provided they should be 238 considered illustrative of the environment and not an exhaustive 239 set. Not all of these environments will necessarily be addressed 240 in initial implementations of IPP. 242 3.1 Client and Printer in the Same Security Domain 244 This environment is typical of internal networks where 245 traditional office workers print the output of personal 246 productivity applications on shared work-group printers, or where 247 batch applications print their output on large production 248 printers. Although the identity of the user may be trusted in 249 this environment, a user might want to protect the content of a 250 document against such attacks as eavesdropping, replaying or 251 tampering. 253 3.2 Client and Printer in Different Security Domains 255 Examples of this environment include printing a document created 256 by the client on a publicly available printer, such as at a 257 commercial print shop; or printing a document remotely on a 258 business partner's printer. This latter operation is functionally 259 equivalent to sending the document to the business partner as a 260 facsimile. Printing sensitive information on a Printer in a 261 different security domain requires strong security measures. In 262 this environment authentication of the printer is required as 263 well as protection against unauthorized use of print resources. 264 Since the document crosses security domains, protection against 265 eavesdropping and document tampering are also required. It will 266 also be important in this environment to protect Printers against 267 spamming and malicious document content code. 269 3.3 Print by Reference 271 When the document is not stored on the client, printing can be 272 done by reference. That is, the print request can contain a 273 reference, or pointer, to the document instead of the actual 274 document itself. If the client physically gets the document 275 before it prints it, then this defaults to one of the previous 276 cases. 278 Expires December 12, 1997 279 3.3.1 Unprotected Documents 281 In many cases, documents to be printed are literally available to 282 anyone. Documents, such as this Internet Draft which are stored 283 on anonymous FTP sites, are good examples of this. No security 284 mechanisms are required to protect access to these document. 286 3.3.2 Protected Documents 288 Clearly, there are cases where the nature of a document requires 289 that access to it be protected by some authentication and/or 290 authorization mechanism, or where the right to print the document 291 must be paid for. This would be the case for sensitive or 292 confidential information, or where documents are copyrighted or 293 sold for profit. Unauthorized access to content is a major 294 concern in this environment. Protection against eavesdropping, 295 document tampering and unauthorized access to the document are 296 also concerns if the content is sensitive. 298 3.4 Common Security Scenarios 300 As discussed earlier in this document,we cannot anticipate the 301 security levels or the specific threats that any given IPP print 302 administrator may be concerned with. Security policies might vary 303 from very strong, to very weak, to none at all, and corresponding 304 security mechanisms will be required. In this section we will 305 describe what we believe to be four common usage scenarios. 307 1) No security at all 308 2) Message protection during transmission 309 3) Client authentication and authorization 310 4) Mutual authentication, authorization, and message protection 312 3.4.1 No Security 314 If the server requires no authorization and the client wants no 315 message protection the client can send the print job, i.e., the 316 job content and the job attributes without invoking any security 317 mechanisms. The printer will print the job for the client. Print 318 by reference also works well in this environment as long no 319 security mechanisms are required to access the documents to be 320 printed. 322 3.4.2 Message Protection During Transmission 324 Expires December 12, 1997 325 There are two types of security that could be used to provide 326 message protection. These are channel security and object 327 security. In the first case, the transport medium must be made 328 secure by mutual authentication. Then everything between the 329 client and server is encrypted by the transport medium. The 330 transport medium can be either of the following: transport layer 331 security (TLS) or network layer security (IPSec). 333 In the case of object security, each object is encrypted and sent 334 over either a secure or an insecure channel. The recipient has 335 the corresponding key to decrypt the object and get the contents. 336 The most widely used object security mechanisms are S/MIME 337 [draft-smime], S-HTTP and PGP/MIME. 339 3.4.3 Client Authentication and Authorization 341 This scenario requires client authentication which may also be 342 used for authorization. A user ID and password may be used for 343 authorization purposes, and may be encrypted by the lower 344 security layer. S/MIME and TLS are good examples of this. TLS 345 supports both one sided and mutual authentication and can also be 346 used in this scenario. 348 3.4.4 Mutual Authentication, Authorization and Message Protection 350 This scenario requires mutual authentication and message 351 protection. TLS and Secure Sockets Layer version 3 (SSL3) are 352 good channel level security providers in this category. 354 4.0 Security Services 356 Now that we have decribed the security threats that exist in the 357 various environments in which IPP may operate, we will discuss 358 the security services that are generally available to counter 359 these threats. Security in general encompasses the software and 360 hardware functionality to deliver the following services: 362 Authorization: Only authorized users should be able to gain 363 access to systems, applications, data or services. Authorization 364 may be based on authenticated identity, location, time of day, 365 role, possession of a physical device or token, or other 366 criterion. 368 Authentication: Authentication is the process of proving who a 369 user or system is, and may apply to individual identities, roles, 370 Expires December 12, 1997 371 or groups. Authentication may be done with traditional methods 372 such as passwords or challenge-response mechansisms, or with 373 publicly recognized methods such as certificates. 375 Message Protection: Access control protects data when it is 376 within a secure system environment. However, when data must 377 travel outside of a secure system, such as across a public 378 network, it needs to be protected. Message protection includes 379 the following: 381 Data origin authentication guarantees that the data originates 382 from an identified source. 384 Privacy protection guarantees that the data cannot be observed 385 except by authorized parties. 387 Integrity protection guarantees that the data cannot be 388 undetectably modified except by authorized parties. 390 Non-repudiation protection guarantees that actions taken on data 391 cannot be denied by the subjects performing those actions. 393 Liability: Responsibility of the user for the printed content. 394 This holds the user accountable for making payments, usage of 395 special resources like transparencies, color printing, etc. The 396 printer is also responsible for the services performed and will 397 be held responsible for it. 399 Provability of Service: The printer should be able to prove that 400 it performed correctly according to the job attributes which the 401 client/user had indeed issued. Example: The printer should be 402 able to prove that the job request was indeed a monochrome when 403 the user claims it issued a color copy. Provability of service 404 requires non-repudiation. 406 Payment and Accounting System: The Printer should insure that the 407 wong person is not charged when someone issues a print request. 409 5.0 Applying Security to IPP Operations 411 An IPP client uses the IPP protocol to invoke operations on 412 remote Printer and Job objects. We now need to understand which 413 security services are required for the various IPP operations. 414 The IPP Operations are: 416 Expires December 12, 1997 417 Create-Job - Create an instance of a Job object 418 Send-Document - Append enclosed data to a Job object 419 Print-Job - Print the enclosed job, with attributes 420 Cancel-Job - Cancel a previously submitted print job 421 Validate - Validate attributes for a specific object 422 Get-Jobs - Return job queue information for a Printer object 423 Get-Attributes - Return attribute information for a Printer or 424 Job object 425 Print-URI - Print a document by reference 426 Send-URI - Append enclosed document reference to a Job object 428 Every time a new connection with a Printer Object or with a Job 429 Object is opened a new security context must established. An 430 administrator may set up different security requirements for 431 different operations, i.e. a user may be able to query a printer, 432 but not submit a job. Once a Job is created, the same (or 433 greater) level of security will be required to perform additional 434 operations on that job. 436 5.1 Create-Job 438 When creating a print job, authentication of the client and the 439 Printer are primary security considerations. Client 440 authentication, along with authorization, protects against 441 unauthorized use of print resources. Printer authentication 442 guarantees the identitity of the remote Printer. 444 5.2 Send-Document 446 When sending document content to the Printer, message protection 447 is the primary security service required. 449 5.3 Print-Job 451 PrintJob combines the functions of CreateJob and SendDocument, 452 therefore 453 authentication, authorization, and message protection are all 454 required. 456 5.4 Cancel-Job 458 Cancel-Job is only used to cancel a job. An end user may only be 459 allowed to cancel his or her own print jobs. Therefore 460 authentication is required to protection against unauthorized 461 cancellation of a job. 462 Expires December 12, 1997 463 5.5 Validate 465 Validate is used to validate the attributes of a remote object. 466 Administrators may choose to restrict the ability for certain end 467 users to see the attributes of a Printer, so authentication and 468 authorization are required services. 470 5.6 Get-Jobs 472 The level of security associated with the GetJobs operation 473 depends on the policy set by an administrator. One common policy 474 is for the complete job queue to be returned to anyone who asks. 475 This policy requires no security. For more secure Printers, a 476 common policy is to list details only on the print jobs owned by 477 the end user, while giving little or no details about other jobs. 478 This policy requires client authentication and authorization to 479 match the client to the print jobs. 481 5.7 Get-Attributes 483 An administrator should be able to establish the level of 484 security associated with getting the attributes of a printer. 486 5.8 Print-URI 488 Print-URI is like Print-Job except that only a reference to the 489 document to be printed is sent in the request. Thus the Printer 490 must fetch the document from the given URI in order to print the 491 job. In IPP version 1.0 we only allow unprotected (see section 492 3.3.1) documents to be printed by reference. Additional, as yet 493 undefined security mechanisms are required to print a protected 494 document by reference. 496 5.9 Send-URI 498 Send-URI is like send-Document except that only a reference to 499 the document to be printed is sent in the request. This operation 500 has the same security concerns as Print-URI. 502 Issue: Does asynchronous notification require any security? 504 6.0 Comments on existing security technologies 506 Expires December 12, 1997 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: This seems to be 529 winning mind share in the IETF, but is really only a security 530 feature negotiation protocol and does not provide any security 531 services in itself. Hence quite limited usefulness for IPP. 533 HTTP 1.1 Digest Access Authentication, RFC 2069: 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 PEM - Privacy Enhanced Mail. Specified in IEF RFCs 1421-1424. It 543 was an early standard for securing email that specified a message 544 format and a hierarchy structure for certification authorities 545 (CAs). 547 MOSS - MIME Object Security Services. Offers the same 548 functionality as PEM, but does not force a single trust model, 549 and allows the identification of users by names that don't have 550 any relationship to X.500, such as E-mail addresses. 552 Expires December 12, 1997 553 IPSec - IP Security is an IETF standards track protocol for 554 security on the IP layer. It consists of two separate mechanisms. 555 The IP Authentication Header (AH) and the IP Encapsulating 556 Security Payload (ESP). They can be used together or separately. 557 The IP Authentication header provides integrity and 558 authentication of IP datagrams. The IP Encapsulating Security 559 Payload provides integrity, authentication and privacy. IPSec 560 allows for either host keys or user keys to be used in security. 561 IPSec can satisfy the IPP requirements for integrity and privacy. 562 IPP Authentication, however, would require both IPSec use user 563 keys and that the IPP application request use their own IPSec 564 security association. Both requirements are recommended by IPSec 565 but are not required. 567 6.1 Recommended Security Mechanisms 569 In order to provide security for the four common usage scenarios 570 defined earlier, we recommend that implementations provide the 571 following, which are suitable for use with HTTP 1.1. 573 - No Security - nothing is required 574 - Message Protection during transmission 575 - TLS 576 - IPSec 577 - Client authentication and authorization 578 - HTTP 1.1 Digest access authentication 579 - TLS 580 - Mutual authentication, authorization and message protection 581 - TLS 583 The security protocol used by a particular IPP operation will 584 depend upon the security services provided by the Printer and the 585 selection made by the client. This requires that the right 586 handshake messages be passed. These are described in more detail 587 in the Appendix. 589 Directory and Printer attributes are required so that an end user 590 can query the level of security supported, but these are yet to 591 be defined. 593 Expires December 12, 1997 594 7.0 Appendix - Specific Features of various technologies 596 7.1 S/MIME: (Secure/Multipurpose Internet Mail Extensions) 598 Security services and features offered: 599 Sender Authentication is provided using digital signatures. The 600 recipient reads the sender's digital signature. Non-repudiation 601 of origin is also achieved using digital signatures. 602 Privacy (using encryption). 603 Integrity is achieved by using hashing to detect message 604 tampering. 605 Provides anonymity by using anonymous e-mailers and gateways. The 606 digital signature and the original message are placed in an 607 encrypted digital envelope. 608 Supports DES, Triple-DES, RC2. 609 X.509 digital certificates supported. 610 Supports PKCS #7(cryptographic message formatting, architecture 611 for certificate-based key management) and #10(message for 612 certification request). 614 Usage, implementation and interoperability: 615 Used to securely transmit e-mail messages in MIME format. 616 Public domain mailer RIPEM available. 617 RSA's toolkit TIPEM (Toolkit for Interoperable Privacy Enhanced 618 Messaging) can be used to build S/MIME clients. It includes C 619 object code for digital envelopes, digital signatures and digital 620 certificate operations. 621 Any two packages that implement S/MIME can communicate securely. 622 Compatible with IMAP (Internet Message Access Protocol - RFC 623 1730). 624 S/MIME works both on the Internet or any other e-mail 625 environment. 627 7.2 Transport Layer Security 1.0 (TLS) 629 TLS is a two layered protocol. The lower level TLS Record 630 Protocol that sits on top of TCP and the TLS Handshake Protocol. 631 The TLS Handshake protocol consists of a suite of three sub 632 protocols which are used to allow peers to agree upon security 633 parameters for the record layer, authenticate themselves, 634 instantiate negotiated security parameters, and report error 635 conditions to each other. TLS is application protocol 636 independent. It is based on SSL v3. 638 Security services and features offered: 639 Expires December 12, 1997 640 Privacy: (optional). Uses symmetric keys. Encryption done by the 641 TLS Record Protocol. The keys are generated for each connection 642 by the TLS Handshake Protocol. 643 Integrity: Using keyed MAC. Hash functions (SHA, MD5) are used 644 for MAC computations. 645 Authentication (Both one-sided and Mutual): The TLS Handshake 646 Protocol uses public key cryptography. Encryption algorithms are 647 negotiated. 649 Usage, implementation and interoperability: 650 Interoperability: Independent applications can be developed 651 utilizing TLS and successfully exchange cryptographic parameters 652 without knowledge of each others code. Cannot inter-operate with 653 SSL 3.0 654 Extensibility: New encryption methods can be incorporated as 655 necessary. 656 Efficiency: To reduce the number of sessions that need to be 657 established from scratch, TLS provides session caching scheme. 658 Other operations: Compression, fragmentation is done by the TLS 659 Record Protocol. 661 Handshake protocol steps: 662 Exchange hello messages to agree on algorithms, exchange random 663 values, and check for session resumption. 664 Exchange the necessary cryptographic parameters to allow the 665 client and server to agree on a premaster secret. 666 Exchange certificates and cryptographic information to allow the 667 client and server to authenticate themselves. 668 Generate a master secret from the premaster secret and exchanged 669 random values. 670 Provide security parameters to the record layer. 671 Allow the client and server to verify that their peer has 672 calculated the same security parameters and that the handshake 673 occurred without tampering by an attacker. 675 Note: The https protocol uses port 443 regardless of which 676 security protocol version (TLS, SSL2, SSL3) it is using. 677 Star (*) indicates optional messages. 679 7.3 SASL (Simple Authentication and Security Layer) 681 SASL provides a method for adding authentication support to 682 connection-based protocols. A command for identifying and 683 authenticating a user and for (optionally) negotiating a security 685 Expires December 12, 1997 686 layer for subsequent protocol interactions is included with a 687 protocol. 689 Security services and features offered: 690 (These are layers that SASL would call. One of these could be 691 selected.) 692 No security 693 Integrity 694 Privacy 696 Security mechanisms: 697 Kerberos 698 GSS-API 699 S/Key 701 Handshaking protocol: 702 1. Client sends data 703 2. Server returns success* with additional data (challenge). 704 Multiple authentication (s)* (Only one - the latest security 705 layer 706 exists during multiple authentication). 707 4. Registration procedures.* 709 Note: SASL is not relevant for HTTP based protocols, but could be 710 relevant to IPP, if IPP decides to later define an IPP specific 711 protocol. 713 7.4 Digest Access Authentication [rfc2069] 715 Digest Access Authentication is a proposed standard for weak 716 authentication in HTTP 1.1. It is intended as a replacement for 717 Basic Access Authentication found in HTTP 1.0. While Digest 718 authentication is on the weak end of the security spectrum, it is 719 a considerable improvement over the completely insecure Basic 720 authentication. 722 Security services and features offered: 723 a. Client Authentication is provided for by a client 724 username/password pair. A hash of the username/password (and 725 other information) is sent from the client to the server. How the 726 username/password is created is outside the protocol. 727 b. Integrity (optional) is provided for by a hash of the entity 728 body, username/password, selected entity headers (and other 729 information). This can be done on either messages from the 730 client or from the server. 731 Expires December 12, 1997 732 c. By default, the hash uses MD5. However, there are provisions 733 for other algorithms. 734 d. Digest authentication is vulnerable to replay attacks, man- 735 in-the-middle attacks, server spoofing, and attacks on the stored 736 password on the server. Well chosen implementations can 737 minimize, but not eliminate the vulnerability. 739 Usage, implementation and interoperability: 740 a. This is used by web servers and clients to pass 741 authentication information. 742 b. This is a proposed feature addition to HTTP 1.1. As such, it 743 is limited to HTTP 1.1 implementations (currently a small 744 number). 745 c. Different implementations have proven interoperable. 747 Handshake protocol steps: 748 a. Client asks for an access-protected object and an acceptable 749 Authorization header is not sent. 750 b. The Server responds with a "401 Unauthorized" status code, 751 and a WWW-Authenticate header. The header has the fields: 752 * realm - a string indicating the context for the 753 authorization 754 * domain [optional] - a list of URIs the authentication is 755 used for 756 * nonce - a data string used in authentication 757 * opaque [optional] - a data string supplied by the server 758 * stale [optional] - a flag indicating the previous effort 759 used a stale nonce 760 * algorithm [optional] - a token indicating the hash algorithm 761 to use 762 c. The Client then asks the User for the username/password (if 763 needed). It then calculates the needed information and retries 764 the request with a Authorization header. The header has the 765 fields: 766 * username - the string supplied by the user 767 * realm - the value supplied by the server 768 * nonce - the value supplied by the server 769 * uri - the URI requested 770 * response - the response hash (see below) 771 * digest [optional] - the digest hash (see below), used for 772 integrity checking 773 * algorithm [optional] - the algorithm used 774 * opaque - the value supplied by the server 775 d. If authorization is granted, the Server responds with result 776 of query, 777 Expires December 12, 1997 778 optionally including a AuthenticationInfo header. The header has 779 the fields: 780 * nextnonce [optional] - the nonce the client should use for 781 the next request 782 * digest [optional] - the digest hash (see below) used for 783 integrity checking. 785 Calculation of hashes 787 The response hash uses the values of username, realm, password, 788 nonce, HTTP method, and URI. It is calculated by: 789 response = Hash(Hash(A1) ":" nonce ":" Hash(A2)) 790 A1 = username ":" realm ":" password 791 A2 = method ":" URI 793 The digest hash uses the values of username, realm, password, 794 nonce, HTTP method, date, URI, content-type, content-length, 795 content-encoding, last-modified, expires, and the entity body. 796 The values of content-type, content-length, content-encoding, 797 last-modified and expires are all taken from the HTTP headers, 798 and are blank if not defined. The digest hash can be sent.by 799 either the client or the server. The digest hash is calculated 800 by: 801 digest = Hash(Hash(A1) ":" nonce ":" method ":" date ":" 802 entity-info ":"Hash(entity-body)) 803 entity-info = Hash(URI ":" content-type ":" content-length ":" 804 content-encoding ":" last-modified ":" expires) 806 Expires December 12, 1997 807 8.0 References: 809 [rfc2069] J. Franks, P. Hallam-Baker, J. Hostetler, P. Leach, A. 810 Luotonen, E. Sink, L. Stewart, _An Extension to HTTP: Digest 811 Access Authentication_, RFC-2069, Jan 1997. 813 [draft-smime] S. Dusse, _S/MIME Message Specification_, , April 1997. 819 [draft-tsl] T. Dierks, C. Allen, _The TLS Protocol_, , March 24, 1997. 822 Expires December 12, 1997 823 9.0 Authors' Addresses 825 Roger deBry 826 HUC/003G 827 IBM Corporation 828 P.O. Box 1900 829 Boulder, CO 80301-9191 830 rdebry@us.ibm.com 832 Jerry Hadsell 833 1130 834 IBM Corporation 835 Rt. 100 836 Somers, N.Y. 10589 837 hadsell@us.ibm.com 839 Daniel Manchala 840 Xerox Corporation 841 701 Aviation Blvd. 842 El Segundo, CA 90245 843 manchala@cp10.es.xerox.com 845 Xavier Riley 846 Xerox Corporation 847 701 Aviation Blvd. 848 El Segundo, CA 90245 849 xriley@cp10.es.xerox.com 851 John Wenn 852 Xerox Corporation 853 701 Aviation Blvd. 854 El Segundo, CA 90245 855 jwenn@cp10.es.xerox.com 857 Other Contributors 859 Scott Isaacson, Novell 860 Carl-Uno Manros, Xerox 862 Expires December 12, 1997