From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2480.txt | 339 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 339 insertions(+) create mode 100644 doc/rfc/rfc2480.txt (limited to 'doc/rfc/rfc2480.txt') diff --git a/doc/rfc/rfc2480.txt b/doc/rfc/rfc2480.txt new file mode 100644 index 0000000..3d160b0 --- /dev/null +++ b/doc/rfc/rfc2480.txt @@ -0,0 +1,339 @@ + + + + + + +Network Working Group N. Freed +Request for Comments: 2480 Innosoft International, Inc. +Category: Standards Track January 1999 + + + Gateways and MIME Security Multiparts + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1999). All Rights Reserved. + +1. Abstract + + This document examines the problems associated with use of MIME + security multiparts and gateways to non-MIME environments. A set of + requirements for gateway behavior are defined which provide + facilities necessary to properly accomodate the transfer of security + multiparts through gateways. + +2. Requirements Notation + + This document occasionally uses terms that appear in capital letters. + When the terms "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" + appear capitalized, they are being used to indicate particular + requirements of this specification. A discussion of the meanings of + the terms "MUST", "SHOULD", and "MAY" appears in RFC 1123 [2]; the + terms "MUST NOT" and "SHOULD NOT" are logical extensions of this + usage. + +3. The Problem + + Security multiparts [RFC-1847] provide an effective way to add + integrity and confidentiality services to protocols that employ MIME + objects [RFC-2045, RFC-2046]. Difficulties arise, however, in + heterogeneous environments involving gateways to environments that + don't support MIME. Specifically: + + (1) Security services have to be applied to MIME objects in + their entirety. Failure to do so can lead to security + exposures. + + + +Freed Standards Track [Page 1] + +RFC 2480 Gateways and MIME Security Multiparts January 1999 + + + For example, a signature that covers only object data and not + the object's MIME labels would allow someone to tamper with + the labels in an undetectable fashion. Similarly, failure to + encrypt MIME label information exposes information about the + content that could facilitate traffic analysis. + + Composite MIME objects (e.g., multipart/mixed, message/rfc822) + also have to be secured as a unit. Again, failure to do so + may facilitate tampering, reveal important information + unnecessarily, or both. + + (2) Gateways that deal with MIME objects have to be able to + convert them to non-MIME formats. + + For example, gateways often have to transform MIME labelling + information into other forms. MIME type information may end up + being expressed as a file extension or as an OID. + + Gateways also have to take apart composite MIME objects into + their component parts, converting the resulting set of parts + into whatever form the non-MIME environments uses for + composite objects. Failure to do so makes the objects unusable + in any environment that doesn't support MIME. In many cases + this also means that multi-level MIME structures have to be + converted into a sequential list of parts. + + (3) Security services have to be deployed in an end-to-end + fashion. Failure to do so again can lead to security + exposures. + + An integrity service deployed at something other than a + connection end point means a region exists between the point + where the integrity service is applied and the actual end + point where object tampering is possible. A confidentiality + service deployed at something other than a connection end + point means a region exists where the object is transferred in + the clear. And worse, distributed private keys are usually + necessary whenever someone other than the originator applies + an integrity service or someone other than the recipient + removes a confidentiality service, which in turn may make + theft of private key information a possibility. + + All of these issues can be addressed, of course. For example, + it may be possible to use multiple overlapping security + services to assure that no exposure exists even though there + is no end-to-end security per se. And keys can be distributed + in a secure fashion. However, such designs tend to be quite + complex, and complexity in a security system is highly + + + +Freed Standards Track [Page 2] + +RFC 2480 Gateways and MIME Security Multiparts January 1999 + + + undesireable. + + The preceeding three requirments are fundamentally in conflict: It is + possible to satisfy two of them at once, but not all three at once. + + In fact the conflict is even worse than it first appears. In most + situations of this sort some sort of compromise is possible which, + while not satisfying any of the requirements completely, does + optimize some sort of average of all the requirements. Such a + solution does not exist in this case, however, because many real + world situations exist where any one of these requirements absolutely + must be satisfied. + +4. Solving the Problem + + Since the previously described problem 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 content of the + multipart are permitted, even when the content is itself a + composite MIME object. + + This option must be provided so that entities behind the + gateway that are capable of processing security multiparts and + their MIME content will work properly. As mentioned + previously, situations exist where application security + requirements are absolute and must be accomodated, even when + meeting them causes problems for other agents. + + Exceptions are allowed only when there is 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 to it a note that it will probably be + invalid for checking the message contents, but may still be + contain valuable information about the sender. + + + + + + +Freed Standards Track [Page 3] + +RFC 2480 Gateways and MIME Security Multiparts January 1999 + + + This option must be provided so that entities behind the + gateway which are incapable of processing MIME will work + properly. + + (3) SHOULD provide the ability to select between the previous two + options on per-user basis. + + (4) MAY provide facilities to check signatures and decrypt + encrypted content. Such facilities MUST NOT be enabled by + default; the potential security exposure involved has to be + assessed before such capabilities can be used. + + (5) MAY provide facilities to sign and/or encrypt material passing + from the non-MIME side to the MIME side of the gateway. Again, + such facilities MUST NOT be enabled by default; the potential + security exposure involved in the transfer of unsecured + content within the application domain behind the gateway has + to be assessed before such capabilities can be used. + + A gateway which complies with the above requirements is considered to + be security multiparts compliant. + +5. Security Considerations + + This entire document is about security. + + + + + + + + + + + + + + + + + + + + + + + + + + +Freed Standards Track [Page 4] + +RFC 2480 Gateways and MIME Security Multiparts January 1999 + + +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 + + + + + + + + + + + + + + + + +Freed Standards Track [Page 5] + +RFC 2480 Gateways and MIME Security Multiparts January 1999 + + +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. + + + + + + + + + + + + + + + + + + + + + + + + +Freed Standards Track [Page 6] + -- cgit v1.2.3