idnits 2.17.1 draft-melnikov-mmhs-authorizing-users-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 03, 2013) is 3950 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'FWS' is mentioned on line 160, but not defined ** Obsolete normative reference: RFC 5750 (Obsoleted by RFC 8550) ** Obsolete normative reference: RFC 5751 (Obsoleted by RFC 8551) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Melnikov 3 Internet-Draft Isode Ltd 4 Intended status: Informational July 03, 2013 5 Expires: January 04, 2014 7 MMHS Draft and Release using S/MIME 8 draft-melnikov-mmhs-authorizing-users-00 10 Abstract 12 This document describes a procedure for when an MMHS message is 13 composed by one user and is only released to the mail transfer system 14 when one or more authorizing users authorize release of the message 15 by adding the MMHS-Authorizing-Users header field. The resulting 16 message can be optionally countersigned, allowing recipients to 17 verify both the original signature (if any) and countersignatures. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on January 04, 2014. 36 Copyright Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Conventions Used in This Document . . . . . . . . . . . . . . 2 55 3. Draft and Release procedure . . . . . . . . . . . . . . . . . 3 56 4. MMHS-Authorizing-Users header field . . . . . . . . . . . . . 4 57 5. Updated MIXER mapping . . . . . . . . . . . . . . . . . . . . 4 58 5.1. Mapping from RFC 5322/MIME to X.400 . . . . . . . . . . . 4 59 5.2. Mapping from X.400 to RFC 5322/MIME . . . . . . . . . . . 5 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 61 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 62 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 65 9.2. Informative References . . . . . . . . . . . . . . . . . 6 66 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 6 68 1. Introduction 70 In some secure environments email messages can't be released to the 71 MTS (Mail Transfer System) and, thus delivered to recipients, unless 72 they are authorized by one or more Releasing Officers. This document 73 describes how this mechanism can be realized by an additional 74 [RFC5322] header field and optionally using S/MIME [RFC5750] and 75 [RFC5751]. 77 This document describes a procedure for how an email message composed 78 by one user can be released to the MTS when one or more authorizing 79 users authorize and optionally countersign the message. The header 80 communicates which users authorized the message. If signed, the 81 resulting message allows recipients to verify both the original (if 82 any) and counter S/MIME signatures. The list of authorizing users is 83 specified in the MMHS-Authorizing-Users header field Section 4. The 84 original S/MIME signature generated by the sender (if any) should be 85 unaffected by additional S/MIME countersignatures. 87 2. Conventions Used in This Document 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in [RFC2119]. 92 The formal syntax uses the Augmented Backus-Naur Form (ABNF) 93 [RFC5234] notation including the core rules defined in Appendix B of 94 RFC 5234 [RFC5234]. Terms not defined in this document are taken 95 from [RFC5322]. 97 3. Draft and Release procedure 99 The original email message to be sent may or may not include sender's 100 S/MIME signature. It doesn't include the MMHS-Authorizing-Users 101 header field. [[Is this true? Is there any use for specifying a 102 value for the MMHS-Authorizing-Users header field before the message 103 is countersigned?]] 105 The document to be sent is first submitted over SMTP [RFC5322]. The 106 specific mechanism for how it arrives to authorizing user(s) is not 107 specified in this document. One possibility is for the Submission 108 MSA to redirect all email messages without the MMHS-Authorizing-Users 109 header field and/or corresponding S/MIME countersignatures to a 110 preconfigured mailbox that can be accessed by authorizing user(s). 112 Each user agent that is used by an authorized user has to perform the 113 following steps: 115 1. Verify authenticity of the message. The exact mechanism to do 116 that is out of scope for this document, but one example is by 117 verifying the S/MIME signature and making sure that it matches 118 the sender of the message, as described in [RFC5750] [RFC5751]. 120 2. Check if the message already contains the MMHS-Authorizing-Users 121 header field with the email address of the authorizing user. If 122 yes, verify validity of the header field (for example by checking 123 for S/MIME countersignature). If the validity of the MMHS- 124 Authorizing-Users header field containing the email address of 125 the authorizing user can be verified, go to step 5 below. 126 Otherwise strip the MMHS-Authorizing-Users header field. 128 3. Allow the authorizing user to review content of the message. 129 Some of the checks can be automated (for example search for 130 keywords). If based on the check the authorizing user is happy 131 to release the message to MTS (or to the next authorizing user, 132 if multiple authorizations are required), the UA should 133 optionally enable the authorizing user to add S/MIME 134 countersignature. If the authorizing user wants to block the 135 message, it can be discarded or returned to sender, and no 136 further steps from this list should take place. 138 4. If there is an existing MMHS-Authorizing-Users header field 139 containing the email address of the authorizing user, skip this 140 step. Othrwise insert a new MMHS-Authorizing-Users header field 141 (if absent) containing the email address of the authorizing user 142 or append the email address of the authorizing user to the end of 143 the existing MMHS-Authorizing-Users header field. 145 5. The (possibly) updated email message is either released to the 146 MTS, or to the next authorizing user, as per email system 147 configuration. 149 4. MMHS-Authorizing-Users header field 151 The MMHS-Authorizing-Users header field specifies the list of 152 authorizing users that countersigned this email message (using S/ 153 MIME) before it was authorized for release to MTS. Each user is 154 described by her/his email address. 156 The MMHS-Authorizing-Users header field specified in this document 157 MUST NOT appear more than once in message headers. 159 MMHS-Authorizing-Users = "MMHS-Authorizing-Users:" 160 [FWS] address-list [FWS] CRLF 162 address-list = 164 5. Updated MIXER mapping 166 This section updates MIXER mapping specified in [RFC2156]. 168 5.1. Mapping from RFC 5322/MIME to X.400 170 In the absence of the MMHS-Authorizing-Users header field, From and 171 Sender header fields are mapped to their X.400 equivalents as 172 specified in [RFC2156]. 174 If MMHS-Authorizing-Users header field is present: 176 1. The first From header field address is mapped to 177 IPMS.Heading.originator if there is no Sender header field and 178 the remaining From header field addresses + the MMHS-Authorizing- 179 Users header field address(es) are mapped to IPMS.Heading 180 .authorizing-users. If a Sender header field is present, the 181 From header field address(es) and the MMHS-Authorizing-Users 182 header field address(es) are mapped to IPMS.Heading.authorizing- 183 users. 185 2. The Sender header field (if present) is mapped to 186 IPMS.Heading.originator. 188 5.2. Mapping from X.400 to RFC 5322/MIME 190 Mapping from X.400 to Internet is controlled by whether or not a 191 particular message is considered to be a military message. A message 192 is considered to be a military message (as defined by ACP 123 193 [ACP123] and also specified in STANAG 4406 [STANAG-4406]) if there 194 are any MMHS heading extensions present. Alternatively, this MAY be 195 done by configuration (i.e. all messages can be considered to be 196 military messages). 198 For non military messages, mapping from X.400 as specified in 199 [RFC2156] is used. 201 For military messages, the following mapping is used: 203 1. IPMS.Heading.originator is mapped to From header field. 205 2. The IPMS.Heading.authorizing-users is mapped to MMHS-Authorizing- 206 Users header field. 208 6. IANA Considerations 210 IANA is requested to add the MMHS-Authorizing-Users header field 211 specified in Section 4 to the "Permanent Message Header Field 212 Registry", defined by Registration Procedures for Message Header 213 Fields [RFC3864]. 215 7. Security Considerations 217 TBD 219 8. Open Issues 220 Netnews Approved header field has the same syntax and semantics as 221 the one described here. Should it be used (and be formally 222 registered for email) instead? 224 Allow use of MMHS-Authorized-Users/Approved for specifying who should 225 authorize release of the message (as opposed to just for recording of 226 who authorized release so far)? 228 9. References 230 9.1. Normative References 232 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 233 Requirement Levels", BCP 14, RFC 2119, March 1997. 235 [RFC2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): 236 Mapping between X.400 and RFC 822/MIME", RFC 2156, January 237 1998. 239 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 240 October 2008. 242 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 243 Specifications: ABNF", STD 68, RFC 5234, January 2008. 245 [RFC5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 246 Mail Extensions (S/MIME) Version 3.2 Certificate 247 Handling", RFC 5750, January 2010. 249 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 250 Mail Extensions (S/MIME) Version 3.2 Message 251 Specification", RFC 5751, January 2010. 253 [ACP123] CCEB, ., "Common Messaging strategy and procedures", ACP 254 123, May 2009. 256 9.2. Informative References 258 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 259 Procedures for Message Header Fields", BCP 90, RFC 3864, 260 September 2004. 262 [STANAG-4406] 263 NATO, ., "STANAG 4406 Edition 2: Military Message Handling 264 System", STANAG 4406, March 2005. 266 Appendix A. Acknowledgements 267 Many thanks for reviews and text provided by Steve Kille and David 268 Wilson. 270 Author's Address 272 Alexey Melnikov 273 Isode Ltd 274 5 Castle Business Village 275 36 Station Road 276 Hampton, Middlesex TW12 2BX 277 UK 279 EMail: Alexey.Melnikov@isode.com