idnits 2.17.1 draft-melnikov-mmhs-authorizing-users-10.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 (January 22, 2016) is 3017 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.melnikov-smime-msa-to-mda' is defined on line 422, but no explicit reference was found in the text ** 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 January 22, 2016 5 Expires: July 25, 2016 7 Message Authorizing Email Header Field and its use for Draft & Release 8 draft-melnikov-mmhs-authorizing-users-10 10 Abstract 12 This document describes a procedure for when an Military Message 13 Handling System (MMHS) message is composed by one user and is only 14 released to the mail transfer system when one or more authorizing 15 users authorize release of the message by adding the MMHS- 16 Authorizing-Users header field. The resulting message can be 17 optionally signed by the sender and/or reviewer, allowing recipients 18 to verify both the original signature (if any) and review signatures. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on July 25, 2016. 37 Copyright Notice 39 Copyright (c) 2016 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 56 3. Draft and Release procedure . . . . . . . . . . . . . . . . . 3 57 3.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 58 3.2. Handling of Initial Message Submission by MSA . . . . . . 3 59 3.3. Review by Authorizing User(s) . . . . . . . . . . . . . . 4 60 3.3.1. Processing of Encrypted Messages . . . . . . . . . . 5 61 3.3.2. Authorizing S/MIME signatures . . . . . . . . . . . . 5 62 3.4. Role of other Messaging Agents at the sender's domain . . 5 63 3.4.1. MDA at the sender's domain . . . . . . . . . . . . . 5 64 3.4.2. Border MTA at the sender's domain . . . . . . . . . . 6 65 4. MMHS-Authorizing-Users header field . . . . . . . . . . . . . 6 66 5. Updated MIXER mapping . . . . . . . . . . . . . . . . . . . . 6 67 5.1. Mapping from RFC 5322/MIME to X.400 . . . . . . . . . . . 6 68 5.2. Mapping from X.400 to RFC 5322/MIME . . . . . . . . . . . 7 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 71 7.1. Forged Header Fields . . . . . . . . . . . . . . . . . . 8 72 7.2. Intentionally Malformed Header Fields . . . . . . . . . . 8 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 75 8.2. Informative References . . . . . . . . . . . . . . . . . 9 76 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 10 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 79 1. Introduction 81 In some secure environments email messages can't be released to the 82 MTS (Message Transfer System) and, thus delivered to recipients, 83 unless they are authorized by one or more authorizing users (e.g. 84 Releasing Officers or Release Authorities). This document describes 85 how this mechanism can be realized by an additional Internet Email 86 [RFC5322] header field and optionally protected using S/MIME 87 [RFC5750] [RFC5751] or DKIM [RFC6376]. 89 This document describes a procedure for how an email message composed 90 by one user can be released to the MTS when one or more authorizing 91 users authorize and optionally countersign the message. The MMHS- 92 Authorizing-Users header field (see Section 4) communicates which 93 user(s) authorized the message. If S/MIME signed, the resulting 94 message allows recipients to verify both the original (if any) and 95 counter signatures. The original S/MIME signature generated by the 96 sender (if any) is unaffected by additional S/MIME review signatures. 98 2. Conventions Used in This Document 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC2119]. 104 The formal syntax uses the Augmented Backus-Naur Form (ABNF) 105 [RFC5234] notation including the core rules defined in Appendix B of 106 RFC 5234 [RFC5234]. Terms not defined in this document are taken 107 from [RFC5322]. 109 3. Draft and Release procedure 111 3.1. Terminology 113 Drafter: Any email user that composes a message (Draft Message) 114 needing authorisation before it is released to its intended 115 recipients. 117 Authorizing User (also Releaser or Authorizer): The mailbox of a user 118 or a group of users that must inspect and authorise the release of 119 Draft Message before it can be sent. An organization may require 120 more than one Authorizing User to authorize release of a Draft 121 Message. 123 3.2. Handling of Initial Message Submission by MSA 125 The original email message to be sent doesn't include the MMHS- 126 Authorizing-Users header field. It may or may not include sender's 127 S/MIME signature. 129 The message to be sent is first submitted over SMTP [RFC6409]. The 130 specific mechanism for how it arrives to authorizing user(s) is not 131 specified in this document. One possibility is for the Message 132 Submission Agent (MSA) to redirect all email messages not addressed 133 to authorizing users and not submitted by authorizing users to a 134 preconfigured mailbox(es) that can be accessed by authorizing 135 user(s). Another possibility is for the MSA to redirect all email 136 messages without the MMHS-Authorizing-Users header field and/or 137 corresponding S/MIME review signatures to a preconfigured mailbox(es) 138 that can be accessed by authorizing user(s). 140 In order to prevent a malicious sender from bypassing or altering 141 Draft and Release procedure, MSA MUST check that MMHS-Authorizing- 142 Users header field (if present) is syntactically valid, contains 143 email addresses of entities authorized to act as authorizing users 144 and, when review signatures are used, that every entity listed has 145 one or more matching review signature (or signature) which is valid. 147 3.3. Review by Authorizing User(s) 149 Each user agent that is used by an authorized user MUST perform the 150 following steps (if there are multiple authorizing users, these steps 151 are repeated for each): 153 1. Verify the origination of the message. The exact mechanism to do 154 that is out of scope for this document, but one example is by 155 verifying the S/MIME signature and making sure that it matches 156 the sender of the message, as described in [RFC5750] [RFC5751]. 157 Another example is by verifying a DKIM signature [RFC6376] that 158 covers From/Sender header fields. 160 2. Check if the message already contains the MMHS-Authorizing-Users 161 header field with the email address of the authorizing user. 162 (This can happen, for example, if email system is misconfigured 163 and thus contains a loop, or if a malicious sender or attacker is 164 trying to affect authorization procedure.) If the message 165 doesn't contain the email address of the authorizing user in the 166 MMHS-Authorizing-Users header field, then go to the next step. 167 If MMHS-Authorizing-Users header field contains the email address 168 of the authorizing user, verify validity of the header field (for 169 example by checking for S/MIME signature/review signature or for 170 DKIM signature). If the validity of the MMHS-Authorizing-Users 171 header field can be verified, go to step 5 below. Otherwise 172 strip the MMHS-Authorizing-Users header field or return the 173 message to sender (bounce). 175 3. Allow the authorizing user to review content of the message. 176 Some of the checks can be automated (for example search for 177 keywords). (See Section 3.3.1 for additional considerations.) 178 If based on the check the authorizing user is happy to release 179 the message to MTS (or to the next authorizing user, if multiple 180 authorizations are required), the UA SHOULD enable the 181 authorizing user to protect additions to the MMHS-Authorizing- 182 Users header field, for example by allowing to add S/MIME review 183 signature (if S/MIME is used for protecting MMHS-Authorizing- 184 Users header field. See Section 3.3.2 for more details). If the 185 authorizing user wants to reject the message, it SHOULD be 186 returned to sender with an explanatory note or can be discarded. 187 The authorizing user can also choose to forward the message to 188 another authorizing user for approval. 190 4. If there is an existing MMHS-Authorizing-Users header field 191 containing the email address of the authorizing user, skip this 192 step. Otherwise, insert a new MMHS-Authorizing-Users header 193 field (if absent) containing the email address of the authorizing 194 user or append the email address of the authorizing user to the 195 end of the existing MMHS-Authorizing-Users header field. 197 5. The (possibly) updated email message is either released to the 198 MTS, or to the next authorizing user, as per email system 199 configuration. Note that if the authorizing user updates the 200 message in a manner that invalidates existing S/MIME/DKIM 201 signature(s), the authorizing user becomes the Drafter, and need 202 to reapply any protections. 204 3.3.1. Processing of Encrypted Messages 206 Any encrypted message sent in an environment where Draft and Release 207 procedure is in force needs to be also encrypted to all authorizing 208 users, so that they can perform review of the message. A message 209 that can't be decrypted by an authorizing user MUST be returned to 210 sender. 212 3.3.2. Authorizing S/MIME signatures 214 If S/MIME were not used, the Authorizing User can become the original 215 signer of the message. 217 If a message is signed multiple times (for example using different 218 cryptographic algorithms), all of the signatures that can be verified 219 by an authorizing user SHOULD be signed with a review signature 220 (authorizing signatures). A recipient of the message can consider 221 any chain of review signatures that matches MMHS-Authorizing-Users 222 header field values as valid, only if all signatures in the chain 223 verify. 225 When triple wrapping [RFC2634] is used, authorizing signatures are 226 applied to the outer level, so that it can be verified by MTAs 227 without the need to decrypt content. 229 3.4. Role of other Messaging Agents at the sender's domain 231 3.4.1. MDA at the sender's domain 233 If a message being sent is to be delivered within the sender's 234 domain, Message Delivery Agents (MDAs) are responsible for ensuring 235 that the message was properly authorized by authorizing user(s), as 236 determined by the sender's domain email system configuration. They 237 verify presence and validity of MMHS-Authorizing-Users header field 238 in the message, as well as validity of associated signatures on the 239 message. 241 Note that the above requirements don't apply to direct delivery to 242 any user designated as an Authorizing User. 244 3.4.2. Border MTA at the sender's domain 246 Sender's domain border MTAs are responsible for ensuring that all 247 messages that leave sender's domain were properly authorized by 248 authorizing user(s), as determined by the sender's domain email 249 system configuration. They verify presence and validity of MMHS- 250 Authorizing-Users header field in outgoing messages, as well as 251 validity of associated signatures on the message. 253 4. MMHS-Authorizing-Users header field 255 The MMHS-Authorizing-Users header field specifies the list of 256 authorizing users (or entities(*)) that countersigned this email 257 message (for example using S/MIME) before it was authorized for 258 release to MTS. Each user/entity is described by her/his/its email 259 address. 261 (*) Note that in some environments identities of authorizing users 262 are required to be hidden from recipients of email messages, so upon 263 receipt MMHS-Authorizing-Users might contain an email address 264 associated with a group of possible users. 266 The MMHS-Authorizing-Users header field specified in this document 267 MUST NOT appear more than once in message headers. (An email message 268 that contains multiple MMHS-Authorizing-Users is malformed. An agent 269 processing such malformed message SHOULD either return it to sender 270 (if possible) or fix the message so that it only contains one copy of 271 the header field.) 273 MMHS-Authorizing-Users = "MMHS-Authorizing-Users:" 274 mailbox-list CRLF 276 mailbox-list = 278 5. Updated MIXER mapping 280 This section updates MIXER mapping specified in [RFC2156]. 282 5.1. Mapping from RFC 5322/MIME to X.400 284 In the absence of the MMHS-Authorizing-Users header field, From and 285 Sender header fields are mapped to their X.400 equivalents as 286 specified in [RFC2156]. 288 If MMHS-Authorizing-Users header field is present: 290 1. The first From header field address is mapped to 291 IPMS.Heading.originator if there is no Sender header field and 292 the remaining From header field addresses + the MMHS-Authorizing- 293 Users header field address(es) are mapped to 294 IPMS.Heading.authorizing-users. If a Sender header field is 295 present, the From header field address(es) and the MMHS- 296 Authorizing-Users header field address(es) are mapped to 297 IPMS.Heading.authorizing-users. 299 2. The Sender header field (if present) is mapped to 300 IPMS.Heading.originator. 302 5.2. Mapping from X.400 to RFC 5322/MIME 304 Mapping from X.400 to Internet is controlled by whether or not a 305 particular message is considered to be a military message. A message 306 is considered to be a military message (as defined by ACP 123 307 [ACP123] and also specified in STANAG 4406 [STANAG-4406]) if there 308 are any MMHS heading extensions present. Alternatively, this MAY be 309 done by configuration (i.e. all messages can be considered to be 310 military messages). 312 For non military messages, mapping from X.400 as specified in 313 [RFC2156] is used. 315 For military messages, the following mapping is used: 317 1. IPMS.Heading.originator is mapped to From header field. 319 2. The IPMS.Heading.authorizing-users is mapped to MMHS-Authorizing- 320 Users header field. 322 6. IANA Considerations 324 IANA is requested to add the MMHS-Authorizing-Users header field 325 specified in Section 4 to the "Provisional Message Header Field 326 Names", defined by Registration Procedures for Message Header Fields 327 [RFC3864]. The registration template is as follows: 329 Header field name: MMHS-Authorizing-Users 331 Applicable protocol: mail ([RFC5322]) 333 Status: provisional 335 Author/Change controller: Alexey Melnikov 336 Specification document(s): [[RFC XXXX]] 338 Related information: 340 7. Security Considerations 342 7.1. Forged Header Fields 344 A malicious sender may add/change an MMHS-Authorizing-Users header 345 field to bypass or alter the message authorization procedure invoked 346 for messages with no MMHS-Authorizing-Users header field. For that 347 reason it is important for agents and clients that rely on the 348 validity of the MMHS-Authorizing-Users header field to also verify 349 the review signature (or a similar protection mechanism), that 350 confirms that a particular person or entity authorized release of a 351 message. 353 7.2. Intentionally Malformed Header Fields 355 It is possible for an attacker to add an MMHS-Authorizing-Users 356 header field that is extraordinarily large or otherwise malformed in 357 an attempt to discover or exploit weaknesses in header field parsing 358 code. Implementations MUST thoroughly verify all such header fields 359 received from MTAs and be robust against intentionally as well as 360 unintentionally malformed header fields. 362 8. References 364 8.1. Normative References 366 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 367 Requirement Levels", BCP 14, RFC 2119, 368 DOI 10.17487/RFC2119, March 1997, 369 . 371 [RFC2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): 372 Mapping between X.400 and RFC 822/MIME", RFC 2156, 373 DOI 10.17487/RFC2156, January 1998, 374 . 376 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 377 DOI 10.17487/RFC5322, October 2008, 378 . 380 [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", 381 STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, 382 . 384 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 385 Specifications: ABNF", STD 68, RFC 5234, 386 DOI 10.17487/RFC5234, January 2008, 387 . 389 [RFC2634] Hoffman, P., Ed., "Enhanced Security Services for S/MIME", 390 RFC 2634, DOI 10.17487/RFC2634, June 1999, 391 . 393 [RFC5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 394 Mail Extensions (S/MIME) Version 3.2 Certificate 395 Handling", RFC 5750, DOI 10.17487/RFC5750, January 2010, 396 . 398 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 399 Mail Extensions (S/MIME) Version 3.2 Message 400 Specification", RFC 5751, DOI 10.17487/RFC5751, January 401 2010, . 403 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 404 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 405 RFC 6376, DOI 10.17487/RFC6376, September 2011, 406 . 408 [ACP123] "Common Messaging strategy and procedures", ACP 123(B), 409 May 2009. 411 8.2. Informative References 413 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 414 Procedures for Message Header Fields", BCP 90, RFC 3864, 415 DOI 10.17487/RFC3864, September 2004, 416 . 418 [STANAG-4406] 419 "STANAG 4406 Edition 2: Military Message Handling System", 420 STANAG 4406 Ed. 2, March 2005. 422 [I-D.melnikov-smime-msa-to-mda] 423 Ottaway, W. and A. Melnikov, "Domain-based signing and 424 encryption using S/MIME", draft-melnikov-smime-msa-to- 425 mda-04 (work in progress), March 2014. 427 Appendix A. Acknowledgements 429 Many thanks for reviews and text provided by Steve Kille, Jim Schaad, 430 Russ Housley, David Wilson and Chris Bonatti. 432 Some text in this document was copied from RFC 7001. 434 Author's Address 436 Alexey Melnikov 437 Isode Ltd 438 14 Castle Mews 439 Hampton, Middlesex TW12 2NP 440 UK 442 EMail: Alexey.Melnikov@isode.com