Network Working Group Ned Freed
Internet Draft <draft-freed-gatesec-00.txt>
Gateways
and
MIME Security Multiparts
November 1997
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are
working documents of the Internet Engineering Task Force
(IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months. Internet-Drafts may be updated, replaced, or obsoleted
by other documents at any time. It is not appropriate to use
Internet-Drafts as reference material or to cite them other
than as a "working draft" or "work in progress".
To learn the current status of any Internet-Draft, please
check the 1id-abstracts.txt listing contained in the
Internet-Drafts Shadow Directories on ds.internic.net (US East
Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast),
or munnari.oz.au (Pacific Rim).
The current draft of this memo reflects comments received
during the last call period. In particular, a reference to RFC
2119 has been added, as have some directives on how to handle
character sets with embedded language tagging facilities.
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 satisfactory facilities to accomodate
the transfer of security multiparts through gateways.
Internet Draft Gateways and Security Multiparts November 1997
2. Requirements notation
This document occasionally uses terms that appear in capital
letters. When the terms "MUST", "SHOULD", "MUST NOT", "SHOULD
NOT", and "MAY" appear capitalized, they are being used to
indicate particular requirements of this specification. A
discussion of the meanings of these terms appears in RFC 2119
[3].
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.
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 be
exploited by an eavesdropper.
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
Expires May 1998 [Page 2]
Internet Draft Gateways and Security Multiparts November 1997
set of parts into whatever form the non-MIME
environments uses for composite objects. Failure to do
so makes the objects unusable. In many cases this means
that multi-level MIME structures having 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 window exists where object
tampering is possible. A confidentiality service
deployed at something other than a connection end point
means a window exists where the object is transferred
in the clear. And worse, distibuted keys are usually
necessary whenever someone other than the originator
applies an integrity service or someone other than the
recipient removes a confidentiality service.
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.
4. Solving the Problem
Since the previously described problem doesn't allow for a
single solution the only viable approach is to require that
Expires May 1998 [Page 3]
Internet Draft Gateways and Security Multiparts November 1997
gateways provide multiple solutions. In particular, gateways
(1) MUST provide the ability to tunnel multipart/signed and
multipart/encrypted objects as monolithic entities. No
changes to content of the multipart are permitted.
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.
(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 remove the signature entirely and
replace it with a note indicating its removal.
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 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
Expires May 1998 [Page 4]
Internet Draft Gateways and Security Multiparts November 1997
This entire document is about security.
6. References
[RFC-822]
Crocker, D., "Standard for the Format of ARPA Internet
Text Messages", RFC 822 August, 1982.
[RFC-1847]
Galvin, J., Murphy, S., Crocker, S., Freed, N., "
Security Multiparts for MIME: Multipart/Signed and
Multipart/Encrypted", RFC 1847, October 1995.
[RFC-2045]
Freed, N. and Borenstein, N., "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, Innosoft, First Virtual Holdings,
December 1996.
[RFC-2046]
Freed, N. and Borenstein, N., "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
Innosoft, First Virtual Holdings, December 1996.
[RFC-2049]
Freed, N. and Borenstein, N., "Multipurpose Internet Mail
Extensions (MIME) Part Five: Conformance Criteria and
Examples", RFC 2049, Innosoft, FIrst Virtual Holdings,
December 1996.
[RFC-2119]
Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
7. Author Address
Ned Freed
Innosoft International, Inc.
1050 Lakes Drive
West Covina, CA 91790
USA
tel: +1 626 919 3600 fax: +1 626 919 3614
email: ned.freed@innosoft.com
Expires May 1998 [Page 5]
Internet Draft Gateways and Security Multiparts November 1997
Expires May 1998 [Page 6]