idnits 2.17.1 draft-ietf-opes-smtp-security-00.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 350. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 327. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 334. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 340. ** 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 (May 22, 2006) is 6550 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: November 23, 2006 May 22, 2006 6 Integrity, privacy and security in OPES for SMTP 7 draft-ietf-opes-smtp-security-00 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 November 23, 2006. 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 . . . . . . . . . 7 66 4. Requirements for OPES/SMTP . . . . . . . . . . . . . . . . . . 8 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 68 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 6.1 Normative References . . . . . . . . . . . . . . . . . . . 10 70 6.2 Informative References . . . . . . . . . . . . . . . . . . 10 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10 72 Intellectual Property and Copyright Statements . . . . . . . . 11 74 1. Terminology 76 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in [1]. When used with 79 the normative meanings, these keywords will be all uppercase. 80 Occurrences of these words in lowercase comprise normal prose usage, 81 with no normative implications. 83 2. Introduction 85 2.1 Differences between unidirectional and bidirectional application 86 protocols 88 The IAB listed considerations for Open Pluggable Edge Services (OPES) 89 in [2] and OPES treatment of those considerations has been discussed 90 in [3]. Both documents make use of HTTP as an example for the 91 underlying protocol in OPES flows and focus on web protocols that 92 have requests and responses in the classic form (client sends request 93 to server that replies with a response of the same protocol within a 94 single protocol transaction). 96 RFC 3914 [3] already indicates that other protocols may not fit in 97 this context, for example in section 5.3: "Moreover, some application 98 protocols may not have explicit responses...". 100 When using SMTP there are still client and server applications and 101 requests and responses handled within SMTP, but email messages are 102 sent by the data provider to the recipients (data consumers) without 103 a previous request; on that abstraction layer, email delivery via 104 SMTP is a unidirectional process and different from the previously 105 handled web protocols such as HTTP. For example: Bypass has been 106 defined for OPES so far by allowing the data consumer to request an 107 OPES bypass by adding information to the application protocol 108 request; the OPES system can then react on the bypass request in both 109 the application request and response; for SMTP the data consumer 110 (email recipient) cannot request in-band the OPES bypass of his 111 messages. 113 The IAB considerations need to be revisited and special requirements 114 may be needed for OPES handling of SMTP. 116 2.2 Non standardized SMTP adaptations at SMTP gateways 118 A large number of email filters is deployed at SMTP gateways today; 119 in fact all usecases listed in "OPES SMTP Use Cases" [6] are already 120 deployed, often in non standardized ways. This opens a number of 121 integrity, privacy and security concerns that are not addressed and 122 SMTP itself does not provide effective measures to detect and defend 123 against compromised implementations. 125 OPES will most likely not be able to solve these issues completly but 126 at least might be able to improve the situaton to some extend. 128 2.3 Non-OPES issues of SMTP 130 The SMTP specifications [4] require that NDRs (Non Delivery Reports) 131 are sent to the originator of an undeliverable mail that has been 132 accepted by an SMTP server. But it became common practice that some 133 sort of mail (spam, worms) is silently dropped without sending an NDR 134 in violation of that MUST statement of SMTP (see section 3.7 of [4]). 135 While the user of a web protocol notices if a resource cannot be 136 fetched, neither the email sender nor email recipient may notice that 137 an email was not delivered. These kind of issues already exist and 138 are not introduced by OPES. 140 2.4 Opportunities of OPES/SMTP to address some issues 142 Adding SMTP adaptations with OPES, allows to define a standardized 143 way for SMTP gateway filtering, to offload filtering services to 144 callout servers and address a number of the integrity, privacy and 145 security issues. OPES offers methods to add OPES tracing information 146 and to request bypass of filtering and by that can make email gateway 147 filtering a more reliable and standardized function. But OPES won't 148 make email delivery via SMTP a reliable communication. 150 2.5 Limitations of OPES in regards to fixing SMTP issues 152 The biggest concerns when adding OPES services to a network flow are 153 that compromised OPES systems may change messages in a way that the 154 consumer cannot longer read them or that messages are not longer 155 delivered at all. 157 Defining a standard way to mark mails that are handled by OPES 158 systems is fairly simple and does not require new techniques by SMTP 159 gateways that already today MUST leave tracing information by adding 160 "Received" headers to mails. Therefore, recipients receiving broken 161 mail have a fair chance to find the compromised OPES system by using 162 the trace information. There is still no guarantee as the email may 163 be broken in a way that makes even the tracing information 164 unreadable; but the chance will be even better than with other 165 protocols such as HTTP because most email clients allow the user to 166 display mail headers while many browsers have no instrument to show 167 the HTTP headers that may include tracing info. 169 Email that cannot be delivered because a compromised OPES system 170 prevented the delivery of legitimate mail MUST result in a an NDR to 171 be sent to the originator of the mail according to the SMTP 172 specifications [4]. OPES should not be forced to fix the issue that 173 NDRs are no reliable medium of SMTP. 175 3. Integrity, privacy and security considerations 177 3.1 Tracing info in OPES/SMTP 179 Tracing is an important requirement for OPES systems. Tracing 180 information added to mails, following a similar syntax and structure 181 as defined for OPES/HTTP in HTTP Adaptation with Open Pluggable Edge 182 Services [5] and with the same guidelines as the SMTP specifications 183 [4] define for the "Received" headers. 185 Trace information is then seen by mail recipients when the mails 186 reach the recipient. Mail that cannot be delivered or that is 187 blocked by the OPES service will either be rejected or cannot be 188 delivered after it has been accepted by an SMTP server. In the 189 latter case SMTP specifications [4] require that a NDR MUST be sent 190 to the originator; OPES requires that if a NDR is sent that report 191 MUST also contain information about the OPES system so that the 192 sender gets informed. If an email is rejected, an OPES system MUST 193 also include trace data to the SMTP response so that the originator 194 can find out why and where the mail was rejected. 196 3.2 Bypass in OPES/SMTP 198 If a mail was rejected or could not be delivered (and a NDR was 199 sent), the originator of the message may want to bypass the OPES 200 system that blocked the message. 202 If the recipient of a message receives a mail with OPES trace 203 information, he may want to receive a non-OPES version of the 204 message. Although there is no direct in-band request from the 205 recipient back to the OPES system, the recipient can contact the 206 sender and ask her to send the message again and to add a bypass 207 request for the OPES system. 209 An OPES system MAY also define out-of-band methods to request a 210 bypass, for example a web interface or an email sent to itself which 211 results in the creation of a white list entry for the sender/ 212 recipient pair. Examples for these out-of-band methods are email 213 systems that keep a copy of the original email in a quarantaine queue 214 and only send the recipient a block notification plus either a direct 215 link or a digest notification with the ability to retrieve the 216 original message from quarantaine. 218 OPES MUST implement methods to request a bypass but there cannot be a 219 guarantee that the bypass request will be approved. The security 220 needs of the receiver or the receiver's network may demand that 221 certain filters must not by bypassed (such as virus scanners for 222 example). In general, the receiver should be able to configure a 223 client centric OPES system, i.e. the receiver should be able to 224 indicate if she wants to receive a non-OPES version if the OPES 225 service would result in rejection of the email. 227 Bypass requests could be added to the mail message or within the SMTP 228 dialog. Bypass request data added to the mail message cannot bypass 229 OPES services that operate on other SMTP dialog commands, which are 230 sent before the mail message has been received (such as RCPT 231 commands). 233 Bypass request data sent at the beginning of a SMTP dialog may not 234 reach the OPES system if intermediate SMTP relays do not support 235 those bypass request commands and don't forward that information. 237 3.3 Compatibility with end-to-end encryption 239 End-to-end email encryption is a proven technology although still the 240 majority of mails are sent unencrypted. Encrpyting and signing email 241 is done on the content of mails and transparent for SMTP. Encrypted 242 mails can either be used to prevent OPES systems to inspect or modify 243 the content or it can be used as an explicit approval to filter the 244 mail by the OPES system, if keys for decryption of the message are 245 made available to the OPES system. Signing of mails can be used to 246 trace whether content has been changed by intermediates. 248 There are security risks associated with storing cryptographic keys 249 which must be addressed by implementors. Beause this is not a simple 250 task, it is only suggested as an option, not as a requirement for 251 OPES/SMTP. 253 4. Requirements for OPES/SMTP 255 In addition to other documents listing requirements for OPES, the 256 discussion in this document implies specific requirements for 257 designing and implementing SMTP adaptations with OPES: 259 o OPES Systems MUST add tracing headers to mail messages 261 o If an email that has been accepted by an OPES system cannot be 262 delivered, the non delivery report MUST include trace information 263 of the OPES system. 265 o OPES/SMTP MUST define a bypass request option that can be included 266 in mail messages 268 o OPES/SMTP MUST define a bypass request option as an extension for 269 SMTP dialogs 271 5. Security Considerations 273 The document itself discusses security considerations of OPES/SMTP. 275 Section 3.3 about compatibility with end-to-end encryption mentions 276 that an OPES system could be approved to inspect encrypted mails by 277 making keys available for decryption. It must be noted that an 278 implementation of the decryption key handling raises security issues 279 (such as availability and storage of cryptographic keys) that must be 280 addressed by the implementer. 282 6. References 284 6.1 Normative References 286 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 287 Levels", BCP 14, RFC 2119, March 1997. 289 [2] Floyd, S. and L. Daigle, "IAB Architectural and Policy 290 Considerations for Open Pluggable Edge Services", RFC 3238, 291 January 2002. 293 [3] Barbir, A. and A. Rousskov, "Open Pluggable Edge Services (OPES) 294 Treatment of IAB Considerations", RFC 3914, October 2004. 296 6.2 Informative References 298 [4] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 299 April 2001. 301 [5] Rousskov, A. and M. Stecher, "HTTP Adaptation with Open 302 Pluggable Edge Services (OPES)", RFC 4236, November 2005. 304 [6] Stecher, M. and A. Barbir, "Open Pluggable Edge Services (OPES) 305 SMTP Use Cases", RFC 4496, May 2006. 307 Author's Address 309 Martin Stecher 310 Secure Computing Corporation 311 Vattmannstr. 3 312 33100 Paderborn 313 Germany 315 Email: martin.stecher@webwasher.com 316 URI: http://www.securecomputing.com/ 318 Intellectual Property Statement 320 The IETF takes no position regarding the validity or scope of any 321 Intellectual Property Rights or other rights that might be claimed to 322 pertain to the implementation or use of the technology described in 323 this document or the extent to which any license under such rights 324 might or might not be available; nor does it represent that it has 325 made any independent effort to identify any such rights. Information 326 on the procedures with respect to rights in RFC documents can be 327 found in BCP 78 and BCP 79. 329 Copies of IPR disclosures made to the IETF Secretariat and any 330 assurances of licenses to be made available, or the result of an 331 attempt made to obtain a general license or permission for the use of 332 such proprietary rights by implementers or users of this 333 specification can be obtained from the IETF on-line IPR repository at 334 http://www.ietf.org/ipr. 336 The IETF invites any interested party to bring to its attention any 337 copyrights, patents or patent applications, or other proprietary 338 rights that may cover technology that may be required to implement 339 this standard. Please address the information to the IETF at 340 ietf-ipr@ietf.org. 342 Disclaimer of Validity 344 This document and the information contained herein are provided on an 345 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 346 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 347 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 348 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 349 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 350 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 352 Copyright Statement 354 Copyright (C) The Internet Society (2006). This document is subject 355 to the rights, licenses and restrictions contained in BCP 78, and 356 except as set forth therein, the authors retain all their rights. 358 Acknowledgment 360 Funding for the RFC Editor function is currently provided by the 361 Internet Society.