Network Working Group M. Stecher Request for Comments: 4902 Secure Computing Category: Informational May 2007 Integrity, Privacy, and Security in Open Pluggable Edge Services (OPES) for SMTP Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The IETF Trust (2007).
AbstractThe Open Pluggable Edge Services (OPES) framework is application agnostic. Application-specific adaptations extend that framework. Previous work has focused on HTTP and work for SMTP is in progress. These protocols differ fundamentally in the way data flows, and it turns out that existing OPES requirements and IAB considerations for OPES need to be reviewed with regards to how well they fit for SMTP adaptation. This document analyzes aspects about the integrity of SMTP and mail message adaptation by OPES systems and about privacy and security issues when the OPES framework is adapted to SMTP. It also lists requirements that must be considered when creating the "SMTP adaptation with OPES" document. The intent of this document is to capture this information before the current OPES working group shuts down. This is to provide input for subsequent working groups or individual contributors that may pick up the OPES/SMTP work at a later date.
1. Introduction ....................................................3 1.1. Differences between Unidirectional and Bidirectional Application Protocols ........................3 1.2. Non-Standardized SMTP Adaptations at SMTP Gateways .........3 1.3. Non-OPES Issues of SMTP ....................................4 1.4. Opportunities of OPES/SMTP to Address Some Issues ..........4 1.5. Limitations of OPES in Regards to Fixing SMTP Issues .......4 2. Terminology .....................................................5 3. Integrity, Privacy, and Security Considerations .................5 3.1. Tracing Information in OPES/SMTP ...........................5 3.2. Bypass in OPES/SMTP ........................................6 3.3. Compatibility with Cryptographic Protection Mechanisms .....7 4. Protocol Requirements for OPES/SMTP .............................8 5. IAB Considerations for OPES/SMTP ................................9 5.1. IAB Consideration (2.1) One-Party Consent ..................9 5.2. IAB Consideration (2.2) IP-Layer Communications ............9 5.3. IAB Consideration (3.1) Notification .......................9 5.4. IAB Consideration (3.2) Notification ......................10 5.5. IAB Consideration (3.3) Non-Blocking ......................10 5.6. IAB Consideration Application Layer Addresses (4.x) .......10 5.7. IAB Consideration (5.1) Privacy ...........................10 5.8. IAB Consideration Encryption ..............................11 6. Security Considerations ........................................11 7. References .....................................................11 7.1. Normative References ......................................11 7.2. Informative References ....................................11 Appendix A. Acknowledgements ......................................13
2], and those considerations are revisited here in the context of the SMTP protocol. Section 3 of the OPES SMTP use cases document  maps some email and SMTP elements to OPES names that are used in this document. 2] and OPES treatment of those considerations has been discussed in . Both documents make use of HTTP as an example for the underlying protocol in OPES flows, and focus on web protocols that have requests and responses in the classic form (client sends a request to a server that replies with a response of the same protocol within a single protocol transaction). RFC 3914  already indicates that other protocols may not fit in this context, for example in Section 5.3, "Moreover, some application protocols may not have explicit responses...". When using SMTP there are still client and server applications, and requests and responses handled within SMTP, but email messages are sent by the data provider to the recipients (data consumers) without a previous request. At that abstraction layer, email delivery via SMTP is a unidirectional process and different from the previously handled web protocols such as HTTP. For example, bypass has been defined for OPES, so far, by the data consumer requesting an OPES bypass by adding information to the application protocol request; the OPES system can then react on the bypass request in both the application request and response. For SMTP, the data consumer (email recipient) cannot request in-band that the OPES bypass handling of his/her messages. The IAB considerations need to be revisited and special requirements may be needed for OPES handling of SMTP. 6] are already deployed, often in non-standardized ways. This opens a number of integrity, privacy, and security concerns that are not
addressed, and SMTP itself does not provide effective measures to detect and defend against compromised implementations. OPES will most likely not be able to solve these issues completely, but at least should be able to improve the situation to some extent. 4] require that NDRs (Non-Delivery Reports) be sent to the originator of an undeliverable mail that has been accepted by an SMTP server. But it has become common practice for some sorts of mail (spam, worms) to be silently dropped without sending an NDR, a violation of the MUST statement of SMTP (see Section 3.7 of ). While the user of a web protocol notices if a resource cannot be fetched, neither the email sender nor email recipient may notice that an email was not delivered. These kind of issues already exist and are not introduced by OPES.
Email that cannot be delivered, because a compromised OPES system prevented the delivery of legitimate mail, MUST result in a an NDR to be sent to the originator of the mail according to the SMTP specifications . OPES should not be forced to fix the issue that NDRs are not reliable over SMTP. 1]. When used with the normative meanings, these keywords will be all uppercase. Occurrences of these words in lowercase comprise normal prose usage, with no normative implications. 5], and with the same guidelines as the SMTP specifications  defined for the "Received" headers. (We do not specify here whether "Received" headers would be used to carry the OPES information, or new trace headers should be defined, such as OPES-System and OPES-Via.) OPES/SMTP specifications defining tracing requirements MUST be compliant with the general OPES tracing requirements defined in OPES Entities & End Points Communication , but MAY further restrict those. For example, they might require the following: that the OPES processor must add tracing information for the OPES system before calling the first callout server; that it has to augment the tracing information with additional data if necessary after the message returns from each service it is calling; and that it must ensure that the tracing information has not been deleted by an OPES service before it forwards the SMTP message. Trace information can then be seen by mail recipients when the mail message reaches the recipient. Mail that cannot be delivered or that is blocked by the OPES service will either be rejected or cannot be delivered after it has been accepted by an SMTP server. In the latter case, SMTP specifications  require that an NDR MUST be sent to the originator; OPES further requires that an NDR generated due to OPES processing MUST also contain information about the OPES system so that the sender gets
informed. If an email is rejected at the SMTP protocol level due to OPES processing, an OPES system MUST also include trace data in the SMTP response so that the originator can find out why and where the mail was rejected.
Bypass request data sent using an ESMTP extension as part of the SMTP dialog may not reach the OPES system if intermediate SMTP relays do not support those bypass request commands and don't forward that information. 9], , ), and these can be used to protect SMTP data without changing the SMTP protocol. The content of encrypted mail messages cannot be inspected by OPES systems because only the intended recipient has the information necessary for decryption. The IAB and others have suggested that users might want to share that information with OPES systems, thus permitting decryption by intermediates. For most cryptographic systems that are compatible with email, this would require end users to share their most valuable keys, in essence their "identities", with OPES machines. Some key management systems, particularly those which have centralized administrative control of keys, might have trust models in which such sharing would be sensible and secure. After decrypting the message, an OPES box that modified the content would be faced with the task of re-encrypting it in order to maintain some semblance of "end-to-end" privacy. If OPES/SMTP had a way to interact with end users on a per-message basis, it might be possible to communicate cryptographic key information from individual messages to end users, have them compute the message encrypting key for particular message, and to send that back to the OPES box. This would perhaps ameliorate the need to share a user's "master" message decrypting key with the OPES box. This kind of communication has not been defined for OPES. Message protection systems generally include some message integrity mechanisms by which a recipient can check for a message modification that may have occurred after the sender released the message. This protection can be applied to encrypted or plaintext messages and can be accomplished through either symmetric or asymmetric cryptography. In the case of symmetric cryptography, the key sharing problem is exactly similar to the encryption case discussed previously. If the OPES box modified the content, then the message integrity (or authentication) code would have to be recalculated and included with the modified message.
For asymmetric cryptography the situation is more complicated. The message integrity is tied to the sender's public key, and although anyone who can get the sender's public key can also check for a message modification, no one but the sender can compute the sender's signature on a modified message. Thus, an OPES system could not modify messages and have them appear to come from the purported sender. The notion of sharing the sender's signing key with the OPES system is unpalatable because few trust models would be compatible with sharing digital identities across organization boundaries. However, if the OPES system doing the modification were under the control of the sender's local administration, the sharing might be sensible (as discussed for decryption, above). OPES/SMTP systems could present modified content showing the modified regions in a form that permits the authentication of the original message and authentication of the OPES modifications (assuming the OPES box had a digital signature identity and key). One method for doing this is outlined in , but to our knowledge this method is not in any standard. There are security risks associated with sharing cryptographic keys that must be addressed by implementers. Because this is not a simple task, it is not a requirement for OPES/SMTP.
2] and summarizes how OPES/SMTP addresses them. 7] requires that "OPES processors MUST be consented to by either the data consumer or data provider application" (OPES processor is the email gateway for OPES/ SMTP). This cannot prevent the consent-less introduction of OPES processors by noncompliant OPES entities. Section 2.1 of  and has been further clarified in Section 2.2 of . 2]. For OPES/SMTP this translates into assistance for the email message sender to detect and respond to recipient-centric actions that are deemed inappropriate by the sender. This has been addressed in Section 3.1 and by the second tracing requirements in Section 4. As discussed in Section 1.3, OPES/SMTP cannot fix cases where NDRs are not sent or get blocked before reaching the sender of the original message.
2]. This is addressed in Section 3.1 and by the first tracing requirement in Section 4. It must be noted that some email systems do not make the email headers available to the end user, although the headers belong to the payload that is transferred via SMTP. Building an OPES architecture with those email systems should be avoided or requires that the tracing information be made available to the end users in a different way. 2]. For OPES/SMTP, this has been discussed in Section 3.2 and is addressed by the two bypass requirements of Section 4. section 8 of ), SMTP uses email addresses, for which the considerations only apply to some degree. The SMTP use cases document  includes a use case for Mail Rerouting and Address Rewriting. Alias and email list address resolution are standard functions of an email gateway described in . Translating the reference validity consideration regarding inter- and intra-document reference validity to SMTP, OPES services mapping internal to external email addresses MUST ensure the proper mapping of addresses in all affected email headers. Section 10 of . Email-specific trace information that will be added to OPES/SMTP according to the requirements in Section 4 may raise
 Stecher, M. and A. Barbir, "Open Pluggable Edge Services (OPES) SMTP Use Cases", RFC 4496, May 2006.  Barbir, A., Penno, R., Chen, R., Hofmann, M., and H. Orman, "An Architecture for Open Pluggable Edge Services (OPES)", RFC 3835, August 2004.  Barbir, A., Batuner, O., Srinivas, B., Hofmann, M., and H. Orman, "Security Threats and Risks for Open Pluggable Edge Services (OPES)", RFC 3837, August 2004.  Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001.  Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.  Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup Language) XML-Signature Syntax and Processing", RFC 3275, March 2002.  Barbir, A., "Open Pluggable Edge Services (OPES) Entities and End Points Communication", RFC 3897, September 2004.  Orman, H., "Data Integrity for Mildly Active Content", Proceedings of the Third Annual International Workshop on Active Middleware Services, p.73, August 2001.
Section 3.3 ("Compatibility with Cryptographic Protection Mechanisms"). http://www.securecomputing.com/
Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at firstname.lastname@example.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.