| TOC |
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 © The Internet Society (1999). All Rights Reserved.
| TOC |
2. Requirements Notation
3. The Problem
4. Solving the Problem
5. Security Considerations
6. References (BOILERPLATE)
7. Author's Address (BOILERPLATE)
8. Full Copyright Statement (BOILERPLATE)
§ Author's Address
§ Intellectual Property and Copyright Statements
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.
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 ; the terms "MUST NOT" and "SHOULD NOT" are logical extensions of this usage.
Security multiparts [RFC1847] (Galvin, J., Murphy, S., Crocker, S., and N. Freed, “Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted,” October 1995.) 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.
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 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.
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. 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.
This entire document is about security.
This RFC contained boilerplate in this section which has been moved to the RFC2223-compliant unnumbered section "References."
This RFC contained boilerplate in this section which has been moved to the RFC2223-compliant unnumbered section "Author's Address."
This RFC contained boilerplate in this section which has been moved to the RFC2223-compliant unnumbered section "Full Copyright Statement."
|[RFC0822]||Crocker, D., “Standard for the format of ARPA Internet text messages,” STD 11, RFC 822, August 1982 (TXT).|
|[RFC1847]||Galvin, J., Murphy, S., Crocker, S., and N. Freed, “Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted,” RFC 1847, October 1995 (TXT).|
|[RFC1123]||Braden, R., “Requirements for Internet Hosts - Application and Support,” STD 3, RFC 1123, October 1989 (TXT).|
|[RFC2045]||Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies,” RFC 2045, November 1996 (TXT).|
|[RFC2046]||Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types,” RFC 2046, November 1996 (TXT).|
|[RFC2049]||Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples,” RFC 2049, November 1996 (TXT, HTML, XML).|
|Innosoft International, Inc.|
|1050 Lakes Drive|
|West Covina, CA 91790|
|Phone:||+1 626 919 3600|
|Fax:||+1 626 919 3614|
Copyright © 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.
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP 11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.