idnits 2.17.1 draft-freed-gatesec-03.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 138: '... (1) MUST provide the ability to tun...' RFC 2119 keyword, line 158: '... (2) MUST provide the ability to tak...' RFC 2119 keyword, line 161: '... gateways SHOULD NOT remove the ...' RFC 2119 keyword, line 162: '... gateways SHOULD keep the signat...' RFC 2119 keyword, line 171: '... (3) SHOULD provide the ability to s...' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 243 has weird spacing: '...rnished to ot...' == Line 244 has weird spacing: '...herwise expla...' == Line 246 has weird spacing: '...without restr...' == Line 247 has weird spacing: '... notice and t...' == Line 248 has weird spacing: '...ivative works...' == (4 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 1998) is 9354 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '2' on line 51 == Unused Reference: 'RFC-822' is defined on line 197, but no explicit reference was found in the text == Unused Reference: 'RFC-1123' is defined on line 206, but no explicit reference was found in the text == Unused Reference: 'RFC-2049' is defined on line 221, but no explicit reference was found in the text ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) Summary: 12 errors (**), 0 flaws (~~), 11 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Ned Freed 3 Internet Draft 5 Gateways 6 and 7 MIME Security Multiparts 9 September 1998 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are 14 working documents of the Internet Engineering Task Force 15 (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months. Internet-Drafts may be updated, replaced, or obsoleted 21 by other documents at any time. It is not appropriate to use 22 Internet-Drafts as reference material or to cite them other 23 than as a "working draft" or "work in progress". 25 To view the entire list of current Internet-Drafts, please 26 check the "1id-abstracts.txt" listing contained in the 27 Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), 28 ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern 29 Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East 30 Coast), or ftp.isi.edu (US West Coast). 32 Copyright (C) The Internet Society (1998). All Rights 33 Reserved. 35 1. Abstract 37 This document examines the problems associated with use of 38 MIME security multiparts and gateways to non-MIME 39 environments. A set of requirements for gateway behavior are 40 defined which provide facilities necessary to properly 41 accomodate the transfer of security multiparts through 42 gateways. 44 2. Requirements Notation 46 This document occasionally uses terms that appear in capital 47 letters. When the terms "MUST", "MUST NOT", "SHOULD", "SHOULD 48 NOT", and "MAY" appear capitalized, they are being used to 49 indicate particular requirements of this specification. A 50 discussion of the meanings of the terms "MUST", "SHOULD", and 51 "MAY" appears in RFC 1123 [2]; the terms "MUST NOT" and 52 "SHOULD NOT" are logical extensions of this usage. 54 3. The Problem 56 Security multiparts [RFC-1847] provide an effective way to add 57 integrity and confidentiality services to protocols that 58 employ MIME objects [RFC-2045, RFC-2046]. Difficulties arise, 59 however, in heterogeneous environments involving gateways to 60 environments that don't support MIME. Specifically: 62 (1) Security services have to be applied to MIME objects in 63 their entirety. Failure to do so can lead to security 64 exposures. 66 For example, a signature that covers only object data 67 and not the object's MIME labels would allow someone to 68 tamper with the labels in an undetectable fashion. 69 Similarly, failure to encrypt MIME label information 70 exposes information about the content that could 71 facilitate traffic analysis. 73 Composite MIME objects (e.g., multipart/mixed, 74 message/rfc822) also have to be secured as a unit. 75 Again, failure to do so may facilitate tampering, 76 reveal important information unnecessarily, or both. 78 (2) Gateways that deal with MIME objects have to be able to 79 convert them to non-MIME formats. 81 For example, gateways often have to transform MIME 82 labelling information into other forms. MIME type 83 information may end up being expressed as a file 84 extension or as an OID. 86 Gateways also have to take apart composite MIME objects 87 into their component parts, converting the resulting 88 set of parts into whatever form the non-MIME 89 environments uses for composite objects. Failure to do 90 so makes the objects unusable in any environment that 91 doesn't support MIME. In many cases this also means 92 that multi-level MIME structures have to be converted 93 into a sequential list of parts. 95 (3) Security services have to be deployed in an end-to-end 96 fashion. Failure to do so again can lead to security 97 exposures. 99 An integrity service deployed at something other than a 100 connection end point means a region exists between the 101 point where the integrity service is applied and the 102 actual end point where object tampering is possible. A 103 confidentiality service deployed at something other 104 than a connection end point means a region exists where 105 the object is transferred in the clear. And worse, 106 distributed private keys are usually necessary whenever 107 someone other than the originator applies an integrity 108 service or someone other than the recipient removes a 109 confidentiality service, which in turn may make theft 110 of private key information a possibility. 112 All of these issues can be addressed, of course. For 113 example, it may be possible to use multiple overlapping 114 security services to assure that no exposure exists 115 even though there is no end-to-end security per se. And 116 keys can be distributed in a secure fashion. However, 117 such designs tend to be quite complex, and complexity 118 in a security system is highly undesireable. 120 The preceeding three requirments are fundamentally in 121 conflict: It is possible to satisfy two of them at once, but 122 not all three at once. 124 In fact the conflict is even worse than it first appears. In 125 most situations of this sort some sort of compromise is 126 possible which, while not satisfying any of the requirements 127 completely, does optimize some sort of average of all the 128 requirements. Such a solution does not exist in this case, 129 however, because many real world situations exist where any 130 one of these requirements absolutely must be satisfied. 132 4. Solving the Problem 134 Since the previously described problem doesn't allow for a 135 single solution the only viable approach is to require that 136 gateways provide multiple solutions. In particular, gateways 138 (1) MUST provide the ability to tunnel multipart/signed and 139 multipart/encrypted objects as monolithic entities if 140 there is any chance whatsoever that MIME capabilities 141 exist on the non-MIME side of the gateway. No changes 142 to content of the multipart are permitted, even when 143 the content is itself a composite MIME object. 145 This option must be provided so that entities behind 146 the gateway that are capable of processing security 147 multiparts and their MIME content will work properly. 148 As mentioned previously, situations exist where 149 application security requirements are absolute and must 150 be accomodated, even when meeting them causes problems 151 for other agents. 153 Exceptions are allowed only when there is no 154 possibility of MIME support on one side of the gateway. 155 For example, a gateway to a voice messaging system may 156 have no useful way to represent a signed MIME object. 158 (2) MUST provide the ability to take apart multipart/signed 159 objects, exposing the content (and in the process 160 ruining the signature). When this approach is selected, 161 gateways SHOULD NOT remove the signature. Instead, 162 gateways SHOULD keep the signature intact and add to it 163 a note that it will probably be invalid for checking 164 the message contents, but may still be contain valuable 165 information about the sender. 167 This option must be provided so that entities behind 168 the gateway which are incapable of processing MIME will 169 work properly. 171 (3) SHOULD provide the ability to select between the 172 previous two options on per-user basis. 174 (4) MAY provide facilities to check signatures and decrypt 175 encrypted content. Such facilities MUST NOT be enabled 176 by default; the potential security exposure involved 177 has to be assessed before such capabilities can be 178 used. 180 (5) MAY provide facilities to sign and/or encrypt material 181 passing from the non-MIME side to the MIME side of the 182 gateway. Again, such facilities MUST NOT be enabled by 183 default; the potential security exposure involved in 184 the transfer of unsecured content within the 185 application domain behind the gateway has to be 186 assessed before such capabilities can be used. 188 A gateway which complies with the above requirements is 189 considered to be security multiparts compliant. 191 5. Security Considerations 193 This entire document is about security. 195 6. References 197 [RFC-822] 198 Crocker, D., "Standard for the Format of ARPA Internet 199 Text Messages", RFC 822, August, 1982. 201 [RFC-1847] 202 Galvin, J., Murphy, S., Crocker, S., Freed, N., " 203 Security Multiparts for MIME: Multipart/Signed and 204 Multipart/Encrypted", RFC 1847, October 1995. 206 [RFC-1123] 207 Braden, R., Editor, "Requirements for Internet Hosts -- 208 Application and Support", RFC 1123, October 1989. 210 [RFC-2045] 211 Freed, N. and Borenstein, N., "Multipurpose Internet Mail 212 Extensions (MIME) Part One: Format of Internet Message 213 Bodies", RFC 2045, Innosoft, First Virtual Holdings, 214 December 1996. 216 [RFC-2046] 217 Freed, N. and Borenstein, N., "Multipurpose Internet Mail 218 Extensions (MIME) Part Two: Media Types", RFC 2046, 219 Innosoft, First Virtual Holdings, December 1996. 221 [RFC-2049] 222 Freed, N. and Borenstein, N., "Multipurpose Internet Mail 223 Extensions (MIME) Part Five: Conformance Criteria and 224 Examples", RFC 2049, Innosoft, FIrst Virtual Holdings, 225 December 1996. 227 7. Author's Address 229 Ned Freed 230 Innosoft International, Inc. 231 1050 Lakes Drive 232 West Covina, CA 91790 233 USA 234 tel: +1 626 919 3600 fax: +1 626 919 3614 235 email: ned.freed@innosoft.com 237 8. Full Copyright Statement 239 Copyright (C) The Internet Society (1998). All Rights 240 Reserved. 242 This document and translations of it may be copied and 243 furnished to others, and derivative works that comment on or 244 otherwise explain it or assist in its implementation may be 245 prepared, copied, published and distributed, in whole or in 246 part, without restriction of any kind, provided that the 247 above copyright notice and this paragraph are included on all 248 such copies and derivative works. However, this document 249 itself may not be modified in any way, such as by removing 250 the copyright notice or references to the Internet Society or 251 other Internet organizations, except as needed for the purpose 252 of developing Internet standards in which case the procedures 253 for copyrights defined in the Internet Standards process must 254 be followed, or as required to translate it into languages 255 other than English. 257 The limited permissions granted above are perpetual and will 258 not be revoked by the Internet Society or its successors or 259 assigns. 261 This document and the information contained herein is provided 262 on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 263 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 264 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE 265 USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 266 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 267 PARTICULAR PURPOSE.