RFC 4902

Integrity, Privacy, and Security in Open Pluggable Edge Services (OPES) for SMTP

📅 published May 2007, from ietf

RFC 4902: Integrity, Privacy, and Security in Open Pluggable Edge Services (OPES) for SMTP 🎀

okay bestie, this one is all about how email gets messed with by OPES boxes in the middle and what could go wrong 🧚 it's a little bit of a legacy doc, so grab a snack and let's go ✨

Here's the title block, the tea on who wrote it and what it is:

  • Series: Network Working Group 💜
  • Author: M. Stecher, Secure Computing 🫶
  • Category: Informational 🌸
  • Date: May 2007 📅
  • Obsoletes or updates: the header doesn't list anything it obsoletes or updates, so this one stands on its own 🦋

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 (C) The IETF Trust (2007).

Abstract 🌈

OPES is application agnostic, which means the framework itself doesn't care what protocol it's on. Application-specific adaptations are what extend it. Earlier work focused on HTTP, and the SMTP work was still in progress. These protocols are fundamentally different in how data flows, so the existing OPES requirements and IAB considerations need a second look to see how well they fit SMTP adaptation. This document looks at the integrity of SMTP and of mail messages adapted by OPES systems, and at the privacy and security issues that come up when OPES is adapted to SMTP. It also lists requirements that must be considered when creating the "SMTP adaptation with OPES" document.

The point of this document is to capture all of this before the current OPES working group shuts down. It's meant as input for later working groups or individual contributors who might pick up the OPES/SMTP work down the road 💅

Table of Contents 🗂️

   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

1. Introduction 🚀

OPES is built on top of application layer transports, so its security may depend on the specifics of the transport. OPES designs are guided by the IAB considerations for OPES document [2], and those considerations get revisited here in the context of the SMTP protocol 🧐

Section 3 of the OPES SMTP use cases document [6] maps some email and SMTP elements to the OPES names used in this document 💖

1.1. Differences between Unidirectional and Bidirectional Application Protocols 🔄

The IAB listed considerations for Open Pluggable Edge Services (OPES) in [2], and OPES treatment of those considerations has been discussed in [3]. Both documents use HTTP as the example underlying protocol for OPES flows. They focus on web protocols that have requests and responses in the classic form, where a client sends a request to a server and the server replies with a response of the same protocol within a single protocol transaction.

RFC 3914 [3] already points out that other protocols may not fit in this context. For example, Section 5.3 says, "Moreover, some application protocols may not have explicit responses..."

With 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, which is very different from the web protocols we've handled before, like HTTP 😭 For example, OPES bypass has so far been defined by the data consumer requesting an OPES bypass by adding information to the application protocol request. The OPES system can then react to the bypass request in both the application request and response. With SMTP, the data consumer (the email recipient) cannot request in-band that OPES bypass their messages.

The IAB considerations need to be revisited, and special requirements may be needed for OPES handling of SMTP 🫶

1.2. Non-Standardized SMTP Adaptations at SMTP Gateways 🚪

A large number of email filters are deployed at SMTP gateways today. In fact, every use case listed in "OPES SMTP Use Cases" [6] is already deployed, often in non-standardized ways. That opens up a bunch of integrity, privacy, and security concerns that nobody has addressed, and SMTP itself doesn't offer any real measures to detect and defend against compromised implementations 💀

OPES will most likely not be able to solve these issues completely, but it should at least be able to improve the situation to some extent ✨

1.3. Non-OPES Issues of SMTP 📭

The SMTP specifications [4] require that NDRs (Non-Delivery Reports) be sent to the originator of an undeliverable mail that an SMTP server has already accepted. But it has become common practice for some kinds of mail (spam, worms) to be silently dropped without sending an NDR. That's a violation of the MUST statement of SMTP (see Section 3.7 of [4]) 😤

While a web user notices if a resource can't be fetched, neither the email sender nor the email recipient may notice that an email was never delivered. These kinds of issues already exist and were not introduced by OPES 🙈

1.4. Opportunities of OPES/SMTP to Address Some Issues 🌟

Adding SMTP adaptations with OPES lets us define a standardized way to do SMTP gateway filtering. Filtering services can be offloaded to callout servers, which helps address a number of the integrity, privacy, and security issues. OPES offers methods to add OPES tracing information and to request a bypass of filtering, so it can make email gateway filtering a more reliable and standardized function 🍓 But OPES won't make email delivery via SMTP a reliable communication, so let's not oversell it 💅

1.5. Limitations of OPES in Regards to Fixing SMTP Issues ⚠️

The biggest concerns when you add OPES services to a network flow are that compromised, misconfigured, or faulty OPES systems may change messages so the consumer can no longer read them, or messages may stop being delivered at all 😱

Defining a standard way to mark mails that have been handled by OPES systems is pretty simple, and it doesn't require new techniques from SMTP gateways. They already MUST leave tracing information by adding "Received" headers to mails. So recipients who get broken mail have a fair chance of finding the compromised OPES system by using the trace information. There's still no guarantee, because the email may have been broken in a way that makes even the tracing information unreadable. But the chance is better than with other protocols such as HTTP, because most email clients let the user display mail headers, while many browsers have no way to show the HTTP headers that might include tracing info 🦋

Email that can't be delivered because a compromised OPES system blocked legitimate mail MUST result in an NDR being sent to the originator of the mail, according to the SMTP specifications [4]. OPES should not be forced to fix the fact that NDRs are not reliable over SMTP 🫠

2. Terminology 📖

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [1]. When they're used with their normative meanings, these keywords will be all uppercase. Lowercase uses of these words are normal prose and carry no normative meaning 🤓

3. Integrity, Privacy, and Security Considerations 🔐

3.1. Tracing Information in OPES/SMTP 🔍

Tracing OPES operations is an important requirement for OPES systems 💜 Tracing information added to email should follow a similar syntax and structure to what's defined for OPES/HTTP in HTTP Adaptation with Open Pluggable Edge Services [5], and it should use the same guidelines that the SMTP specifications [4] define for "Received" headers. (We don't specify here whether "Received" headers would be used to carry the OPES information, or whether new trace headers should be defined, such as OPES-System and OPES-Via.)

OPES/SMTP specifications that define tracing requirements MUST be compliant with the general OPES tracing requirements defined in OPES Entities & End Points Communication [12], but they 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 calls; and that it must ensure the tracing information hasn't been deleted by an OPES service before it forwards the SMTP message 🎀

Trace information can then be seen by mail recipients once the mail message reaches them 👀

Mail that can't be delivered, or that gets blocked by the OPES service, will either be rejected or fail to be delivered after an SMTP server has already accepted it. In the latter case, the SMTP specifications [4] 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 the originator can find out why and where the mail was rejected 💌

3.2. Bypass in OPES/SMTP ✨

okay so picture this: a mail message gets rejected or can't be delivered, and an NDR gets sent back 📬. now the originator of that message might want to bypass the OPES system that blocked it, bestie 🙈

and if the recipient gets a mail with OPES trace information on it, they might want a non-OPES version of the message 🎀 there's no direct in-band request from the recipient back to the OPES system tho, so instead the recipient can contact the sender and ask her to send the message again and add a bypass request for the OPES system 💌 not every OPES system is allowed to fulfill a bypass request though, depending on its policy. like, malware scanners should not be bypassed 🛡️ but other OPES services are good candidates, such as language translation of the email message 🌍 a recipient could bypass translation once they've noticed the translated result doesn't meet their expectations and they'd rather have the original message 💅

an OPES system MAY also define out-of-band methods to request a bypass 🦋 for example, a web interface, or an email message sent to the server that creates a white list entry for the sender/recipient pair. ngl the example here is giving quarantine vibes: email systems keep a copy of the original email in a quarantine queue and only send the recipient a block notification, plus either a direct link or a digest notification, so they can retrieve the original message from quarantine 📦 these out-of-band methods are typically offered by spam filters today 🧚

OPES MUST implement methods to request a bypass 🔥 but there cannot be a guarantee that the bypass request will be approved, bestie. the security needs of the receiver or the receiver's network may demand that certain filters must not be bypassed (such as virus scanners) 🔒 in general, the receiver should be able to configure a client centric OPES system. so the receiver should be able to indicate if they want a non-OPES version when one is available 🫶

bypass request data could be added to the mail message or within the SMTP dialog 💜 but bypass request data added to the mail message cannot bypass OPES services that operate on other SMTP dialog commands, which are sent before the mail message has been received (such as RCPT commands) 💀

bypass request data sent using an ESMTP extension as part of the SMTP dialog may not reach the OPES system if intermediate SMTP relays don't support those bypass request commands and don't forward that information 😭 it's giving relay drama.

3.3. Compatibility with Cryptographic Protection Mechanisms 🔐

okay the big question here is cryptography 🌸 it can be used to assure message privacy, to authenticate the originator of messages, and to detect message modification 💖 there are standard methods for achieving some or all of these protections for generic messages ([9], [10], [11]), and these can be used to protect SMTP data without changing the SMTP protocol ✨

but the content of encrypted mail messages cannot be inspected by OPES systems, because only the intended recipient has the information needed for decryption 🙈 the IAB and others have suggested that users might want to share that information with OPES systems, which would permit decryption by intermediates. ngl, for most cryptographic systems that work with email, this would mean end users sharing their most valuable keys, basically their "identities", with OPES machines 😭 some key management systems, especially ones with centralized administrative control of keys, might have trust models where that 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, so that some semblance of "end-to-end" privacy is maintained 🎀

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 that particular message, and send it back to the OPES box 🦋 this would perhaps ease 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, though 🌈

message protection systems generally include some message integrity mechanisms, so 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 it can be accomplished through either symmetric or asymmetric cryptography ✨ with symmetric cryptography, the key sharing problem is exactly similar to the encryption case we just talked about. 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 🔁

asymmetric cryptography is more complicated, bestie 😵‍💫 the message integrity is tied to the sender's public key. anyone who can get the sender's public key can check for a message modification, but no one except the sender can compute the sender's signature on a modified message 🔏 so 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 authentication of the original message and authentication of the OPES modifications. this assumes the OPES box had a digital signature identity and key 🔑 one method for doing this is outlined in [13], but to our knowledge this method is not in any standard 📚

there are security risks associated with sharing cryptographic keys that implementers have to address. because this is not a simple task, it is not a requirement for OPES/SMTP 🚨

4. Protocol Requirements for OPES/SMTP 📋

in addition to other documents listing requirements for OPES, the discussion in this document implies specific requirements for designing and implementing SMTP adaptations with OPES 💅 here they are:

  • OPES Systems MUST add tracing headers to mail messages 🏷️
  • If an email message that has been accepted by an OPES system cannot be delivered, the non-delivery report MUST include trace information of the OPES system 📨
  • The OPES/SMTP specifications MUST define a bypass request option that can be included in mail messages 🎀
  • The OPES/SMTP specifications MUST define a bypass request option as an extension for SMTP dialogs 🧚

5. IAB Considerations for OPES/SMTP 🌸

this section lists the IAB considerations for OPES [2] and summarizes how OPES/SMTP addresses them 💖

the IAB recommends that all OPES services be explicitly authorized by one of the application-layer end-hosts (that is, either the data consumer application or the data provider application). for OPES/SMTP, this means consent of either the email message sender or the recipient 💌

the application agnostic architecture of OPES [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 🚩

5.2. IAB Consideration (2.2) IP-Layer Communications 🌐

the IAB recommends that OPES processors must be explicitly addressed at the IP layer by the end user (data consumer application) 🎯

this requirement has been addressed by the architecture requirements in Section 2.1 of [7], and has been further clarified in Section 2.2 of [3] ✨

5.3. IAB Consideration (3.1) Notification 🔔

"The overall OPES framework needs to assist content providers in detecting and responding to client-centric actions by OPES intermediaries that are deemed inappropriate by the content provider" [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 requirement 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 😭

5.4. IAB Consideration (3.2) Notification 👀

"The overall OPES framework should assist end users in detecting the behavior of OPES intermediaries, potentially allowing them to identify imperfect or compromised intermediaries" [2].

this is addressed in Section 3.1 and by the first tracing requirement in Section 4. it's worth noting that some email systems do not make the email headers available to the end user, even though 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 end users in a different way 🧐

5.5. IAB Consideration (3.3) Non-Blocking 🚪

"If there exists a "non-OPES" version of content available from the content provider, the OPES architecture must not prevent users from retrieving this "non-OPES" version from the content provider" [2].

for OPES/SMTP, this has been discussed in Section 3.2 and is addressed by the two bypass requirements of Section 4 🦋

5.6. IAB Consideration Application Layer Addresses (4.x) 📬

while "most application layer addressing revolves around URIs" (section 8 of [2]), SMTP uses email addresses, for which the considerations only apply to some degree 💭

the SMTP use cases document [6] 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 [4] 🔀

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 🏷️

5.7. IAB Consideration (5.1) Privacy 🕵️‍♀️

this consideration recommends that the overall OPES framework must provide mechanisms for end users to determine the privacy policies that were used by OPES intermediaries 🔍

the application agnostic part for OPES has been discussed in Section 10 of [3]. email-specific trace information that will be added to OPES/SMTP according to the requirements in Section 4 may raise additional privacy issues that MUST be added to the privacy policy description of the OPES system 🙈

5.8. IAB Consideration Encryption 🔒

"If OPES was compatible with end-to-end encryption, this would effectively ensure that OPES boxes would be restricted to ones that are known, trusted, explicitly addressed at the IP layer, and authorized (by the provision of decryption keys) by at least one of the ends" [2].

this has been discussed in Section 3.3 💖

6. Security Considerations 🔒✨

okay bestie, security is where we get serious 🥺 the doc itself talks about the security stuff for OPES/SMTP. the big-picture OPES threats are covered in Security Threats for OPES [8] 🛡️

and remember Section 3.3 ("Compatibility with Cryptographic Protection Mechanisms")? it says an OPES system could eventually end up dealing with cryptographic keys 🔑 that brings up real security issues, like keeping the keys available and storing them safely, and the implementer must handle those 💀

7. References 📚

7.1. Normative References

[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[2] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002.

[3] Barbir, A. and A. Rousskov, "Open Pluggable Edge Services (OPES) Treatment of IAB Considerations", RFC 3914, October 2004.

7.2. Informative References

[4] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.

[5] Rousskov, A. and M. Stecher, "HTTP Adaptation with Open Pluggable Edge Services (OPES)", RFC 4236, November 2005.

[6] Stecher, M. and A. Barbir, "Open Pluggable Edge Services (OPES) SMTP Use Cases", RFC 4496, May 2006.

[7] Barbir, A., Penno, R., Chen, R., Hofmann, M., and H. Orman, "An Architecture for Open Pluggable Edge Services (OPES)", RFC 3835, August 2004.

[8] 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.

[9] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001.

[10] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.

[11] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup Language) XML-Signature Syntax and Processing", RFC 3275, March 2002.

[12] Barbir, A., "Open Pluggable Edge Services (OPES) Entities and End Points Communication", RFC 3897, September 2004.

[13] Orman, H., "Data Integrity for Mildly Active Content", Proceedings of the Third Annual International Workshop on Active Middleware Services, p.73, August 2001.

Appendix A. Acknowledgements 🫶

huge thank yous to everyone who gave input and feedback on this doc, you're all iconic 💖 extra special thanks to Hilarie Orman for her input and suggestions, especially for the content of Section 3.3 ("Compatibility with Cryptographic Protection Mechanisms") 🧚

Author's Address 🖊️

Martin Stecher Secure Computing Corporation Vattmannstr. 3 33100 Paderborn Germany

EMail: martin.stecher@webwasher.com URI: http://www.securecomputing.com/

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 on 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 on whether any license under such rights might or might not be available, and it doesn't claim to have made any independent effort to identify any such rights. info on how RFC documents handle rights can be found in BCP 78 and BCP 79.

copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users to use these proprietary rights 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 needed to implement this standard. send that info to the IETF at ietf-ipr@ietf.org 📩

Acknowledgement 💜

funding for the RFC Editor function is currently provided by the Internet Society 🌸

📦 where this page comes from