< draft-freed-gatesec-02.txt   draft-freed-gatesec-03.txt >
Network Working Group Ned Freed Network Working Group Ned Freed
Internet Draft <draft-freed-gatesec-02.txt> Internet Draft <draft-freed-gatesec-03.txt>
Gateways Gateways
and and
MIME Security Multiparts MIME Security Multiparts
August 1998 September 1998
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are This document is an Internet-Draft. Internet-Drafts are
working documents of the Internet Engineering Task Force working documents of the Internet Engineering Task Force
(IETF), its areas, and its working groups. Note that other (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet- groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months. Internet-Drafts may be updated, replaced, or obsoleted months. Internet-Drafts may be updated, replaced, or obsoleted
by other documents at any time. It is not appropriate to use by other documents at any time. It is not appropriate to use
Internet-Drafts as reference material or to cite them other Internet-Drafts as reference material or to cite them other
than as a "working draft" or "work in progress". than as a "working draft" or "work in progress".
To view the entire list of current Internet-Drafts, please check To view the entire list of current Internet-Drafts, please
the "1id-abstracts.txt" listing contained in the Internet-Drafts check the "1id-abstracts.txt" listing contained in the
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net Internet-Drafts Shadow Directories on ftp.is.co.za (Africa),
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East
(US West Coast). Coast), or ftp.isi.edu (US West Coast).
Copyright (C) The Internet Society (1998). All Rights Copyright (C) The Internet Society (1998). All Rights
Reserved. Reserved.
1. Abstract 1. Abstract
This document examines the problems associated with use of This document examines the problems associated with use of
MIME security multiparts and gateways to non-MIME MIME security multiparts and gateways to non-MIME
environments. A set of requirements for gateway behavior are environments. A set of requirements for gateway behavior are
defined which provide facilities necessary to properly defined which provide facilities necessary to properly
accomodate the transfer of security multiparts through accomodate the transfer of security multiparts through
gateways. gateways.
2. Requirements Notation 2. Requirements Notation
This document occasionally uses terms that appear in capital This document occasionally uses terms that appear in capital
letters. When the terms "MUST", "SHOULD", "MUST NOT", "SHOULD letters. When the terms "MUST", "MUST NOT", "SHOULD", "SHOULD
NOT", and "MAY" appear capitalized, they are being used to NOT", and "MAY" appear capitalized, they are being used to
indicate particular requirements of this specification. A indicate particular requirements of this specification. A
discussion of the meanings of these terms appears in [RFC- discussion of the meanings of the terms "MUST", "SHOULD", and
2119]. "MAY" appears in RFC 1123 [2]; the terms "MUST NOT" and
"SHOULD NOT" are logical extensions of this usage.
3. The Problem 3. The Problem
Security multiparts [RFC-1847] provide an effective way to add Security multiparts [RFC-1847] provide an effective way to add
integrity and confidentiality services to protocols that integrity and confidentiality services to protocols that
employ MIME objects [RFC-2045, RFC-2046]. Difficulties arise, employ MIME objects [RFC-2045, RFC-2046]. Difficulties arise,
however, in heterogeneous environments involving gateways to however, in heterogeneous environments involving gateways to
environments that don't support MIME. Specifically: environments that don't support MIME. Specifically:
(1) Security services have to be applied to MIME objects in (1) Security services have to be applied to MIME objects in
skipping to change at page 3, line 7 skipping to change at page 3, line 8
labelling information into other forms. MIME type labelling information into other forms. MIME type
information may end up being expressed as a file information may end up being expressed as a file
extension or as an OID. extension or as an OID.
Gateways also have to take apart composite MIME objects Gateways also have to take apart composite MIME objects
into their component parts, converting the resulting into their component parts, converting the resulting
set of parts into whatever form the non-MIME set of parts into whatever form the non-MIME
environments uses for composite objects. Failure to do environments uses for composite objects. Failure to do
so makes the objects unusable in any environment that so makes the objects unusable in any environment that
doesn't support MIME. In many cases this also means doesn't support MIME. In many cases this also means
that multi-level MIME structures having to be converted that multi-level MIME structures have to be converted
into a sequential list of parts. into a sequential list of parts.
(3) Security services have to be deployed in an end-to-end (3) Security services have to be deployed in an end-to-end
fashion. Failure to do so again can lead to security fashion. Failure to do so again can lead to security
exposures. exposures.
An integrity service deployed at something other than a An integrity service deployed at something other than a
connection end point means a region exists between the connection end point means a region exists between the
point where the integrity service is applied and the point where the integrity service is applied and the
actual end point where object tampering is possible. A actual end point where object tampering is possible. A
confidentiality service deployed at something other confidentiality service deployed at something other
than a connection end point means a region exists where than a connection end point means a region exists where
the object is transferred in the clear. And worse, the object is transferred in the clear. And worse,
distibuted private keys are usually necessary whenever distributed private keys are usually necessary whenever
someone other than the originator applies an integrity someone other than the originator applies an integrity
service or someone other than the recipient removes a service or someone other than the recipient removes a
confidentiality service, which in turn may make theft confidentiality service, which in turn may make theft
of private key information a possibility. of private key information a possibility.
All of these issues can be addressed, of course. For All of these issues can be addressed, of course. For
example, it may be possible to use multiple overlapping example, it may be possible to use multiple overlapping
security services to assure that no exposure exists security services to assure that no exposure exists
even though there is no end-to-end security per se. And even though there is no end-to-end security per se. And
keys can be distributed in a secure fashion. However, keys can be distributed in a secure fashion. However,
skipping to change at page 4, line 15 skipping to change at page 4, line 15
4. Solving the Problem 4. Solving the Problem
Since the previously described problem doesn't allow for a Since the previously described problem doesn't allow for a
single solution the only viable approach is to require that single solution the only viable approach is to require that
gateways provide multiple solutions. In particular, gateways gateways provide multiple solutions. In particular, gateways
(1) MUST provide the ability to tunnel multipart/signed and (1) MUST provide the ability to tunnel multipart/signed and
multipart/encrypted objects as monolithic entities if multipart/encrypted objects as monolithic entities if
there is any chance whatsoever that MIME capabilities there is any chance whatsoever that MIME capabilities
exist on the non-MIME side of the gateway. No changes exist on the non-MIME side of the gateway. No changes
to content of the multipart are permitted, even when to content of the multipart are permitted, even when
the content is itself a composite MIME object. the content is itself a composite MIME object.
This option must be provided so that entities behind This option must be provided so that entities behind
the gateway that are capable of processing security the gateway that are capable of processing security
multiparts and their MIME content will work properly. multiparts and their MIME content will work properly.
As mentioned previously, situations exist where As mentioned previously, situations exist where
security requirements are absolute and must be application security requirements are absolute and must
accomodated, even when the price of meeting them causes be accomodated, even when meeting them causes problems
problems for other agents. for other agents.
Exceptions are allowed only when there is no Exceptions are allowed only when there is no
possibility of MIME support on one side of the gateway. possibility of MIME support on one side of the gateway.
For example, a gateway to a voice messaging system may For example, a gateway to a voice messaging system may
have no useful way to represent a signed MIME object. have no useful way to represent a signed MIME object.
(2) MUST provide the ability to take apart multipart/signed (2) MUST provide the ability to take apart multipart/signed
objects, exposing the content (and in the process objects, exposing the content (and in the process
ruining the signature). When this approach is selected ruining the signature). When this approach is selected,
gateways SHOULD remove the signature entirely and gateways SHOULD NOT remove the signature. Instead,
replace it with a note indicating that it was removed. 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 This option must be provided so that entities behind
the gateway which are incapable of processing MIME will the gateway which are incapable of processing MIME will
work properly. work properly.
(3) SHOULD provide the ability to select between the (3) SHOULD provide the ability to select between the
previous two options on per-user basis. previous two options on per-user basis.
(4) MAY provide facilities to check signatures and decrypt (4) MAY provide facilities to check signatures and decrypt
encrypted content. Such facilities MUST NOT be enabled encrypted content. Such facilities MUST NOT be enabled
by default; the potential security exposure involved by default; the potential security exposure involved
has to be assessed before such capabilities can be has to be assessed before such capabilities can be
used. used.
(5) MAY provide facilities to sign and/or encrypt material (5) MAY provide facilities to sign and/or encrypt material
passing from the non-MIME side to the MIME side of the passing from the non-MIME side to the MIME side of the
gateway. Again, such facilities MUST NOT be enabled by gateway. Again, such facilities MUST NOT be enabled by
default; the potential security exposure involved in default; the potential security exposure involved in
the transfer of unsecured content within the gateway the transfer of unsecured content within the
has to be assessed before such capabilities can be application domain behind the gateway has to be
used. assessed before such capabilities can be used.
A gateway which complies with the above requirements is A gateway which complies with the above requirements is
considered to be security multiparts compliant. considered to be security multiparts compliant.
5. Security Considerations 5. Security Considerations
This entire document is about security. This entire document is about security.
6. References 6. References
[RFC-822] [RFC-822]
Crocker, D., "Standard for the Format of ARPA Internet Crocker, D., "Standard for the Format of ARPA Internet
Text Messages", RFC 822, August, 1982. Text Messages", RFC 822, August, 1982.
[RFC-1847] [RFC-1847]
Galvin, J., Murphy, S., Crocker, S., Freed, N., " Galvin, J., Murphy, S., Crocker, S., Freed, N., "
Security Multiparts for MIME: Multipart/Signed and Security Multiparts for MIME: Multipart/Signed and
Multipart/Encrypted", RFC 1847, October 1995. Multipart/Encrypted", RFC 1847, October 1995.
[RFC-1123]
Braden, R., Editor, "Requirements for Internet Hosts --
Application and Support", RFC 1123, October 1989.
[RFC-2045] [RFC-2045]
Freed, N. and Borenstein, N., "Multipurpose Internet Mail Freed, N. and Borenstein, N., "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, Innosoft, First Virtual Holdings, Bodies", RFC 2045, Innosoft, First Virtual Holdings,
December 1996. December 1996.
[RFC-2046] [RFC-2046]
Freed, N. and Borenstein, N., "Multipurpose Internet Mail Freed, N. and Borenstein, N., "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, Extensions (MIME) Part Two: Media Types", RFC 2046,
Innosoft, First Virtual Holdings, December 1996. Innosoft, First Virtual Holdings, December 1996.
[RFC-2049] [RFC-2049]
Freed, N. and Borenstein, N., "Multipurpose Internet Mail Freed, N. and Borenstein, N., "Multipurpose Internet Mail
Extensions (MIME) Part Five: Conformance Criteria and Extensions (MIME) Part Five: Conformance Criteria and
Examples", RFC 2049, Innosoft, FIrst Virtual Holdings, Examples", RFC 2049, Innosoft, FIrst Virtual Holdings,
December 1996. December 1996.
[RFC-2119]
Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
7. Author's Address 7. Author's Address
Ned Freed Ned Freed
Innosoft International, Inc. Innosoft International, Inc.
1050 Lakes Drive 1050 Lakes Drive
West Covina, CA 91790 West Covina, CA 91790
USA USA
tel: +1 626 919 3600 fax: +1 626 919 3614 tel: +1 626 919 3600 fax: +1 626 919 3614
email: ned.freed@innosoft.com email: ned.freed@innosoft.com
 End of changes. 13 change blocks. 
27 lines changed or deleted 31 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/