idnits 2.17.1 draft-ietf-opes-smtp-security-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 475. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 452. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 459. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 465. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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 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: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 22, 2006) is 6426 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) ** Downref: Normative reference to an Informational RFC: RFC 3238 (ref. '2') ** Downref: Normative reference to an Informational RFC: RFC 3914 (ref. '3') -- Obsolete informational reference (is this intentional?): RFC 2821 (ref. '4') (Obsoleted by RFC 5321) Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Open Pluggable Edge Services M. Stecher 3 Internet-Draft Secure Computing 4 Expires: March 26, 2007 September 22, 2006 6 Integrity, privacy and security in OPES for SMTP 7 draft-ietf-opes-smtp-security-01 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on March 26, 2007. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 The Open Pluggable Edge Services (OPES) framework is application 41 agnostic. Application specific adaptations extend that framework. 42 Previous work has focussed on HTTP and work for SMTP is in progress. 43 These protocols differ fundamentally in the way data flows and it 44 turns out that existing OPES requirements and IAB considerations for 45 OPES need to be reviewed with regards to how well they fit for SMTP 46 adaptation. This document analysis aspects about the integrity of 47 SMTP and mail message adaptation by OPES systems and privacy and 48 security issues when the OPES framework is adapted to SMTP and lists 49 requirements that must be considered when creating the "SMTP 50 adaptation with OPES" document. 52 Table of Contents 54 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.1 Differences between unidirectional and bidirectional 57 application protocols . . . . . . . . . . . . . . . . . . 4 58 2.2 Non-standardized SMTP adaptations at SMTP gateways . . . . 4 59 2.3 Non-OPES issues of SMTP . . . . . . . . . . . . . . . . . 4 60 2.4 Opportunities of OPES/SMTP to address some issues . . . . 5 61 2.5 Limitations of OPES in regards to fixing SMTP issues . . . 5 62 3. Integrity, privacy and security considerations . . . . . . . . 6 63 3.1 Tracing info in OPES/SMTP . . . . . . . . . . . . . . . . 6 64 3.2 Bypass in OPES/SMTP . . . . . . . . . . . . . . . . . . . 6 65 3.3 Compatibility with end-to-end encryption and signatures . 7 66 4. Protocol requirements for OPES/SMTP . . . . . . . . . . . . . 8 67 5. IAB Considerations for OPES/SMTP . . . . . . . . . . . . . . . 9 68 5.1 IAB Consideration (2.1) One-Party Consent . . . . . . . . 9 69 5.2 IAB Consideration (2.2) IP-Layer Communications . . . . . 9 70 5.3 IAB Consideration (3.1) Notification . . . . . . . . . . . 9 71 5.4 IAB Consideration (3.2) Notification . . . . . . . . . . . 9 72 5.5 IAB Consideration (3.3) Non-Blocking . . . . . . . . . . . 10 73 5.6 IAB Consideration Application Layer Addresses (4.x) . . . 10 74 5.7 IAB Consideration (5.1) Privacy . . . . . . . . . . . . . 10 75 5.8 IAB Consideration Encryption . . . . . . . . . . . . . . . 11 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 77 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 7.1 Normative References . . . . . . . . . . . . . . . . . . . 13 79 7.2 Informative References . . . . . . . . . . . . . . . . . . 13 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13 81 Intellectual Property and Copyright Statements . . . . . . . . 14 83 1. Terminology 85 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in [1]. When used with 88 the normative meanings, these keywords will be all uppercase. 89 Occurrences of these words in lowercase comprise normal prose usage, 90 with no normative implications. 92 2. Introduction 94 2.1 Differences between unidirectional and bidirectional application 95 protocols 97 The IAB listed considerations for Open Pluggable Edge Services (OPES) 98 in [2] and OPES treatment of those considerations has been discussed 99 in [3]. Both documents make use of HTTP as an example for the 100 underlying protocol in OPES flows, and focus on web protocols that 101 have requests and responses in the classic form (client sends a 102 request to a server that replies with a response of the same protocol 103 within a single protocol transaction). 105 RFC 3914 [3] already indicates that other protocols may not fit in 106 this context, for example in section 5.3: "Moreover, some application 107 protocols may not have explicit responses...". 109 When using SMTP there are still client and server applications and 110 requests and responses handled within SMTP, but email messages are 111 sent by the data provider to the recipients (data consumers) without 112 a previous request; on that abstraction layer, email delivery via 113 SMTP is a unidirectional process and different from the previously 114 handled web protocols such as HTTP. For example: Bypass has been 115 defined for OPES so far by allowing the data consumer to request an 116 OPES bypass by adding information to the application protocol 117 request; the OPES system can then react on the bypass request in both 118 the application request and response. For SMTP, the data consumer 119 (email recipient) cannot request in-band that the OPES bypass 120 handling of his/her messages. 122 The IAB considerations need to be revisited and special requirements 123 may be needed for OPES handling of SMTP. 125 2.2 Non-standardized SMTP adaptations at SMTP gateways 127 A large number of email filters are deployed at SMTP gateways today; 128 in fact all usecases listed in "OPES SMTP Use Cases" [6] are already 129 deployed, often in non standardized ways. This opens a number of 130 integrity, privacy and security concerns that are not addressed, and 131 SMTP itself does not provide effective measures to detect and defend 132 against compromised implementations. 134 OPES will most likely not be able to solve these issues completely, 135 but at least might be able to improve the situaton to some extent. 137 2.3 Non-OPES issues of SMTP 139 The SMTP specifications [4] require that NDRs (Non Delivery Reports) 140 be sent to the originator of an undeliverable mail that has been 141 accepted by an SMTP server. But it has become common practice for 142 some sorts of mail (spam, worms) to be silently dropped without 143 sending an NDR, a violation of the MUST statement of SMTP (see 144 section 3.7 of [4]). While the user of a web protocol notices if a 145 resource cannot be fetched, neither the email sender nor email 146 recipient may notice that an email was not delivered. These kind of 147 issues already exist and are not introduced by OPES. 149 2.4 Opportunities of OPES/SMTP to address some issues 151 Adding SMTP adaptations with OPES allows us to define a standardized 152 way for SMTP gateway filtering, to offload filtering services to 153 callout servers and address a number of the integrity, privacy and 154 security issues. OPES offers methods to add OPES tracing information 155 and to request bypass of filtering, and by that can make email 156 gateway filtering a more reliable and standardized function. But 157 OPES won't make email delivery via SMTP a reliable communication. 159 2.5 Limitations of OPES in regards to fixing SMTP issues 161 The biggest concerns when adding OPES services to a network flow are 162 that compromised, misconfigured or faulty OPES systems may change 163 messages in a way that the consumer can no longer read them or that 164 messages are not longer delivered at all. 166 Defining a standard way to mark mails that have been handled by OPES 167 systems is fairly simple and does not require new techniques by SMTP 168 gateways; they already today MUST leave tracing information by adding 169 "Received" headers to mails. Therefore, recipients receiving broken 170 mail have a fair chance of finding the compromised OPES system by 171 using the trace information. There is still no guarantee, as the 172 email have been broken in a way that makes even the tracing 173 information unreadable; but the chance will be even better than with 174 other protocols such as HTTP, because most email clients allow the 175 user to display mail headers, while many browsers have no mechanism 176 to show the HTTP headers that might include tracing info. 178 Email that cannot be delivered because a compromised OPES system 179 prevented the delivery of legitimate mail, MUST result in a an NDR to 180 be sent to the originator of the mail according to the SMTP 181 specifications [4]. OPES should not be forced to fix the issue that 182 NDRs are not reliable over SMTP. 184 3. Integrity, privacy and security considerations 186 3.1 Tracing info in OPES/SMTP 188 Tracing is an important requirement for OPES systems. Tracing 189 information added to mails should follow a similar syntax and 190 structure to that defined for OPES/HTTP in HTTP Adaptation with Open 191 Pluggable Edge Services [5], and with the same guidelines as the SMTP 192 specifications [4] define for the "Received" headers. 194 Trace information is then seen by mail recipients when the mails 195 reach the recipient. Mail that cannot be delivered or that is 196 blocked by the OPES service will either be rejected or cannot be 197 delivered after it has been accepted by an SMTP server. In the 198 latter case SMTP specifications [4] require that a NDR MUST be sent 199 to the originator; OPES requires that if a NDR is sent that the 200 report MUST also contain information about the OPES system so that 201 the sender gets informed. If an email is rejected, an OPES system 202 MUST also include trace data in the SMTP response so that the 203 originator can find out why and where the mail was rejected. 205 3.2 Bypass in OPES/SMTP 207 If a mail message was rejected or could not be delivered (and a NDR 208 was sent), the originator of the message may want to bypass the OPES 209 system that blocked the message. 211 If the recipient of a message receives a mail with OPES trace 212 information, he may want to receive a non-OPES version of the 213 message. Although there is no direct in-band request from the 214 recipient back to the OPES system, the recipient can contact the 215 sender and ask her to send the message again and to add a bypass 216 request for the OPES system. 218 An OPES system MAY also define out-of-band methods to request a 219 bypass, for example a web interface or an email message sent to it 220 that results in the creation of a white list entry for the sender/ 221 recipient pair. Examples for these out-of-band methods are email 222 systems that keep a copy of the original email in a quarantaine queue 223 and only send the recipient a block notification plus either a direct 224 link, or a digest notification with the ability to retrieve the 225 original message from quarantaine. 227 OPES MUST implement methods to request a bypass but there cannot be a 228 guarantee that the bypass request will be approved. The security 229 needs of the receiver or the receiver's network may demand that 230 certain filters must not by bypassed (such as virus scanners for 231 example). In general, the receiver should be able to configure a 232 client centric OPES system, i.e. the receiver should be able to 233 indicate if he/she wants to receive a non-OPES version if the OPES 234 service would result in rejection of the email. 236 Bypass requests could be added to the mail message or within the SMTP 237 dialog. Bypass request data added to the mail message cannot bypass 238 OPES services that operate on other SMTP dialog commands, which are 239 sent before the mail message has been received (such as RCPT 240 commands). 242 Bypass request data sent at the beginning of a SMTP dialog may not 243 reach the OPES system if intermediate SMTP relays do not support 244 those bypass request commands and don't forward that information. 246 3.3 Compatibility with end-to-end encryption and signatures 248 End-to-end email encryption is a proven technology, although the 249 majority of mails are still sent unencrypted. Encrypting and signing 250 email messages is done on the content of the mail and would be 251 transparent to SMTP. Encrypted mail messages can either be used to 252 prevent OPES systems from inspecting or modifying the content, or it 253 can be used as an explicit approval to filter the mail by the OPES 254 system, if keys for decryption of the message are made available to 255 the OPES system. Signing of mails can be used to trace whether 256 content has been changed by intermediates. 258 There are security risks associated with storing cryptographic keys 259 that must be addressed by implementors. Because this is not a simple 260 task, it is only suggested as an option, not as a requirement for 261 OPES/SMTP. 263 4. Protocol requirements for OPES/SMTP 265 In addition to other documents listing requirements for OPES, the 266 discussion in this document implies specific requirements for 267 designing and implementing SMTP adaptations with OPES: 269 o OPES Systems MUST add tracing headers to mail messages 271 o If an email message that has been accepted by an OPES system 272 cannot be delivered, the non delivery report MUST include trace 273 information of the OPES system. 275 o The OPES/SMTP specifications MUST define a bypass request option 276 that can be included in mail messages. 278 o The OPES/SMTP specifications MUST define a bypass request option 279 as an extension for SMTP dialogs. 281 5. IAB Considerations for OPES/SMTP 283 This section lists the IAB considerations for OPES [2] and summarizes 284 how OPES/SMTP addresses them. 286 5.1 IAB Consideration (2.1) One-Party Consent 288 The IAB recommends that all OPES services be explicitly authorized by 289 one of the application-layer end-hosts (that is, either the data 290 consumer application or the data provider application). For OPES/ 291 SMTP this means consent of either the email message sender or the 292 recipient. 294 The application agnostic architecture of OPES [7] requires that "OPES 295 processors MUST be consented to by either the data consumer or data 296 provider application" (OPES processor is the email gateway for OPES/ 297 SMTP). This cannot prevent the consent-less introduction of OPES 298 processors by incompliant OPES entities. 300 5.2 IAB Consideration (2.2) IP-Layer Communications 302 The IAB recommends that OPES processors must be explicitly addressed 303 at the IP layer by the end user (data consumer application). 305 This requirement has been addressed by the architecture requirements 306 in section 2.1 of [7] and has been further clarified in section 2.2 307 of [3]. 309 5.3 IAB Consideration (3.1) Notification 311 "The overall OPES framework needs to assist content providers in 312 detecting and responding to client-centric actions by OPES 313 intermediaries that are deemed inappropriate by the content provider" 314 [2]. 316 For OPES/SMTP this translates into assistance for the email message 317 sender to detect and respond to recipient-centric actions that are 318 deemed inappropriate by the sender. 320 This has been addressed in Section 3.1 and by the second tracing 321 requirements in Section 4. As discussed in Section 2.3 OPES/SMTP 322 cannot prevent that NDRs are not sent or get blocked before reaching 323 the sender of the original message. 325 5.4 IAB Consideration (3.2) Notification 327 "The overall OPES framework should assist end users in detecting the 328 behavior of OPES intermediaries, potentially allowing them to 329 identify imperfect or compromised intermediaries" [2]. 331 This is addressed in Section 3.1 and by the first tracing requirement 332 in Section 4. It must be noted that some email systems do not make 333 the email headers available to the end user although the headers 334 belong to the payload that is transferred via SMTP. Building an OPES 335 architecture with those email systems should be avoided or requires 336 that the tracing information is made available to the end users in a 337 different way. 339 5.5 IAB Consideration (3.3) Non-Blocking 341 "If there exists a "non-OPES" version of content available from the 342 content provider, the OPES architecture must not prevent users from 343 retrieving this "non-OPES" version from the content provider" [2]. 345 For OPES/SMTP this has been discussed in Section 3.2 and is addressed 346 by the two bypass requirements of Section 4. 348 5.6 IAB Consideration Application Layer Addresses (4.x) 350 While "most application layer addressing revolves around URIs" 351 (section 8 of [2]), SMTP uses email addresses, for which the 352 considerations apply to some degree only. 354 The SMTP use cases document [6] includes a use case for Mail 355 Rerouting and Address Rewriting. Alias and email list address 356 resolution are standard function of an email gateway described in 357 [4]. 359 Translating the reference validity consideration regarding inter- and 360 intra-document reference validity to SMTP, OPES services mapping 361 internal to external email addresses MUST ensure to properly map 362 addresses in all affected email headers. 364 5.7 IAB Consideration (5.1) Privacy 366 This consideration recommends that the overall OPES framework must 367 provide for mechanisms for end users to determine the privacy 368 policies of OPES intermediaries. 370 The application agnostic part for OPES and has been discussed in 371 section 10 of [3]. Email specific trace information that will be 372 added to OPES/SMTP according to the requirements in Section 4 may 373 raise additional privacy issues that MUST be added to the privacy 374 policy description of the OPES system. 376 5.8 IAB Consideration Encryption 378 "If OPES was compatible with end-to-end encryption, this would 379 effectively ensure that OPES boxes would be restricted to ones that 380 are known, trusted, explicitly addressed at the IP layer, and 381 authorized (by the provision of decryption keys) by at least one of 382 the ends" [2]. 384 This has been discussed in Section 3.3. 386 6. Security Considerations 388 The document itself discusses security considerations of OPES/SMTP. 389 General security threats of OPES are described in Security Threats 390 for OPES [8] 392 Section 3.3 (about compatibility with end-to-end encryption) mentions 393 that an OPES system could be approved to inspect encrypted mails by 394 making keys available for decryption. It must be noted that an 395 implementation of the decryption key handling raises security issues 396 (such as availability and storage of cryptographic keys) that must be 397 addressed by the implementer. 399 7. References 401 7.1 Normative References 403 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 404 Levels", BCP 14, RFC 2119, March 1997. 406 [2] Floyd, S. and L. Daigle, "IAB Architectural and Policy 407 Considerations for Open Pluggable Edge Services", RFC 3238, 408 January 2002. 410 [3] Barbir, A. and A. Rousskov, "Open Pluggable Edge Services (OPES) 411 Treatment of IAB Considerations", RFC 3914, October 2004. 413 7.2 Informative References 415 [4] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 416 April 2001. 418 [5] Rousskov, A. and M. Stecher, "HTTP Adaptation with Open 419 Pluggable Edge Services (OPES)", RFC 4236, November 2005. 421 [6] Stecher, M. and A. Barbir, "Open Pluggable Edge Services (OPES) 422 SMTP Use Cases", RFC 4496, May 2006. 424 [7] Barbir, A., Penno, R., Chen, R., Hofmann, M., and H. Orman, "An 425 Architecture for Open Pluggable Edge Services (OPES)", RFC 3835, 426 August 2004. 428 [8] Barbir, A., Batuner, O., Srinivas, B., Hofmann, M., and H. 429 Orman, "Security Threats and Risks for Open Pluggable Edge 430 Services (OPES)", RFC 3837, August 2004. 432 Author's Address 434 Martin Stecher 435 Secure Computing Corporation 436 Vattmannstr. 3 437 33100 Paderborn 438 Germany 440 Email: martin.stecher@webwasher.com 441 URI: http://www.securecomputing.com/ 443 Intellectual Property Statement 445 The IETF takes no position regarding the validity or scope of any 446 Intellectual Property Rights or other rights that might be claimed to 447 pertain to the implementation or use of the technology described in 448 this document or the extent to which any license under such rights 449 might or might not be available; nor does it represent that it has 450 made any independent effort to identify any such rights. Information 451 on the procedures with respect to rights in RFC documents can be 452 found in BCP 78 and BCP 79. 454 Copies of IPR disclosures made to the IETF Secretariat and any 455 assurances of licenses to be made available, or the result of an 456 attempt made to obtain a general license or permission for the use of 457 such proprietary rights by implementers or users of this 458 specification can be obtained from the IETF on-line IPR repository at 459 http://www.ietf.org/ipr. 461 The IETF invites any interested party to bring to its attention any 462 copyrights, patents or patent applications, or other proprietary 463 rights that may cover technology that may be required to implement 464 this standard. Please address the information to the IETF at 465 ietf-ipr@ietf.org. 467 Disclaimer of Validity 469 This document and the information contained herein are provided on an 470 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 471 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 472 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 473 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 474 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 475 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 477 Copyright Statement 479 Copyright (C) The Internet Society (2006). This document is subject 480 to the rights, licenses and restrictions contained in BCP 78, and 481 except as set forth therein, the authors retain all their rights. 483 Acknowledgment 485 Funding for the RFC Editor function is currently provided by the 486 Internet Society.