RFC 2480

RFC 2480: Gateways and MIME Security Multiparts 🎀

okay bestie, here's the title block tea ☕✨ This is RFC 2480, called "Gateways and MIME Security Multiparts," written by N. Freed of Innosoft International, Inc. It's on the Standards Track and dates from January 1999 📅. The header doesn't list anything it obsoletes or updates, so there's no drama there 💅

---

Status of this Memo 📜

This is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🦋 For the current standardization state and status, check the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈

Copyright Notice ©️

Copyright (C) The Internet Society (1999). All Rights Reserved. 💜

1. Abstract 🌸

okay so this doc looks at the problems that show up when you use MIME security multiparts with gateways that lead to non-MIME environments 🧚 It sets out a group of requirements for gateway behaviour, so that security multiparts can actually get through gateways properly 🎀

2. Requirements Notation 💖

this doc sometimes uses words in ALL CAPS 👀 When the terms "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" show up capitalised like that, they're flagging specific requirements of this spec 🔥 The meaning of "MUST", "SHOULD", and "MAY" is discussed in RFC 1123 [2], and "MUST NOT" and "SHOULD NOT" are just logical extensions of that usage 🫶

3. The Problem 😭

so security multiparts [RFC-1847] are a really good way to add integrity and confidentiality to protocols that use MIME objects [RFC-2045, RFC-2046] ✨ BUT it gets messy in mixed environments where you've got gateways talking to places that don't support MIME 💀 Specifically:

1. Security services have to cover MIME objects in their entirety. If you don't, you open up security holes 🙈

Like, a signature that only covers the object data and not the object's MIME labels would let someone mess with the labels without anyone noticing 😱 Same deal with encryption: if you don't encrypt the MIME label info, it leaks details about the content that could help with traffic analysis 👀

Composite MIME objects (e.g., multipart/mixed, message/rfc822) also have to be secured as a single unit 🍓 Otherwise you might make tampering easier, reveal stuff you didn't need to, or both 💅

2. Gateways that handle MIME objects have to be able to convert them to non-MIME formats. 🔄

For example, gateways often have to turn MIME labelling info into other forms, so MIME type info can end up as a file extension or an OID 🧚

Gateways also have to break composite MIME objects into their component parts, then convert that set of parts into whatever form the non-MIME environment uses for composite objects 🎀 If they don't, the objects are unusable anywhere that doesn't support MIME 😭 And a lot of the time that means multi-level MIME structures have to get flattened into a sequential list of parts 🌈

3. Security services have to be deployed end-to-end. Doing it any other way can also open up security holes 💔

An integrity service applied at something other than a connection end point creates a gap between where it's applied and the actual end point, which is where tampering is possible 👀 A confidentiality service applied somewhere other than a connection end point means there's a region where the object gets transferred in the clear 😬 And worse, distributed private keys are usually needed whenever someone other than the originator applies an integrity service, or someone other than the recipient removes a confidentiality service. That in turn could make theft of private key info a real possibility 😱

Okay, so all of this can be fixed, of course 🫶 You could use multiple overlapping security services so there's no exposure even without true end-to-end security, and keys can be distributed securely. BUT those designs tend to be super complex, and complexity in a security system is highly undesirable 💀

The three requirements above are fundamentally in conflict: you can satisfy two of them at once, but not all three at once 💔

It's even worse than it first looks ngl 😭 In most situations like this, you can find some compromise that doesn't fully satisfy any of the requirements but does optimise some sort of average across all of them 🌸 That doesn't work here, though, because plenty of real-world situations exist where any one of these requirements absolutely must be satisfied 🔥

4. Solving the Problem 🧚

okay so since the problem we just described doesn't allow for a single solution, the only viable approach is to require that gateways provide multiple solutions 🌈 In particular, gateways:

1. MUST provide the ability to tunnel multipart/signed and multipart/encrypted objects as monolithic entities if there is any chance whatsoever that MIME capabilities exist on the non-MIME side of the gateway 💅 No changes to the content of the multipart are permitted, even when that content is itself a composite MIME object 🚫

This option must be provided so that entities behind the gateway that can process security multiparts and their MIME content will work properly ✨ As mentioned before, there are situations where application security requirements are absolute and have to be accommodated, even when meeting them causes problems for other agents 😭

Exceptions are allowed only when there's no possibility of MIME support on one side of the gateway 🍓 For example, a gateway to a voice messaging system may have no useful way to represent a signed MIME object 🎀

2. MUST provide the ability to take apart multipart/signed objects, exposing the content (and in the process ruining the signature) 💔 When this approach is selected, gateways SHOULD NOT remove the signature 🙅‍♀️ Instead, gateways SHOULD keep the signature intact and add a note saying it will probably be invalid for checking the message contents, but may still contain valuable information about the sender 🫶

This option must be provided so that entities behind the gateway that can't process MIME will work properly 🌸

3. SHOULD provide the ability to select between the previous two options on a per-user basis. 💖
4. MAY provide facilities to check signatures and decrypt encrypted content. Such facilities MUST NOT be enabled by default, because the potential security exposure has to be assessed before anyone uses those capabilities 🚨
5. MAY provide facilities to sign and/or encrypt material passing from the non-MIME side to the MIME side of the gateway. Again, these facilities MUST NOT be enabled by default 🛑 The potential security exposure from transferring unsecured content inside the application domain behind the gateway has to be assessed before anyone uses those capabilities 👀

A gateway that complies with the above requirements is considered to be security multiparts compliant 👑

5. Security Considerations 🔐

This entire document is about security. 💀🔥 Every single bit of it matters, bestie, so treat it like the main character it is 👑

6. References 📚

• [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August, 1982.
• [RFC-1847] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995.
• [RFC-1123] Braden, R., Ed., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.
• [RFC-2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, December 1996.
• [RFC-2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, December 1996.
• [RFC-2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, December 1996.

7. Author's Address 📮

Ned Freed
Innosoft International, Inc.
1050 Lakes Drive
West Covina, CA 91790
USA

Phone: +1 626 919 3600
Fax:   +1 626 919 3614
EMail: ned.freed@innosoft.com

8. Full Copyright Statement 🌈

Copyright (C) The Internet Society (1999). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. ✨