Browse Prior Art Database

Gateways and MIME Security Multiparts (RFC2480)

IP.com Disclosure Number: IPCOM000003060D
Original Publication Date: 1999-Jan-01
Included in the Prior Art Database: 2019-Feb-11
Document File: 6 page(s) / 8K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

N. Freed: AUTHOR

Related Documents

10.17487/RFC2480: DOI

Abstract

This document examines the problems associated with use of MIME security multiparts and gateways to non-MIME environments. [STANDARDS-TRACK]

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 30% of the total text.

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 int...

Processing...
Loading...