idnits 2.17.1 draft-melnikov-mmhs-authorizing-users-14.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 (May 4, 2016) is 2885 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 453, 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 May 4, 2016 5 Expires: November 5, 2016 7 Message Authorizing Email Header Field and its use for Draft & Release 8 draft-melnikov-mmhs-authorizing-users-14 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 November 5, 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 . . 6 63 3.4.1. MDA at the sender's domain . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . 7 67 5.1. Mapping from RFC 5322/MIME to X.400 . . . . . . . . . . . 7 68 5.2. Mapping from X.400 to RFC 5322/MIME . . . . . . . . . . . 7 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 71 7.1. Forged Header Fields . . . . . . . . . . . . . . . . . . 8 72 7.2. Intentionally Malformed Header Fields . . . . . . . . . . 9 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 75 8.2. Informative References . . . . . . . . . . . . . . . . . 10 76 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 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, the whole 151 sequence of steps below is repeated for each authorizing user): 153 1. Verify the origination of the message (From/Sender header 154 fields). The exact mechanism to do that is out of scope for this 155 document, but one example is by verifying the S/MIME signature, 156 making sure that the signature protects all header fields (i.e. 157 wrapped by message/rfc822, as described in Section 3.1 of 158 [RFC5751]) and that it matches the sender of the message, as 159 described in [RFC5750]. Another example is by verifying a DKIM 160 signature [RFC6376] (added by Drafter's MUA or MSA) that covers 161 From/Sender header fields. 163 2. Check if the message already contains the MMHS-Authorizing-Users 164 header field with the email address of the authorizing user. 165 (This can happen, for example, if email system is misconfigured 166 and thus contains a loop, or if a malicious sender or attacker is 167 trying to affect authorization procedure.) If the message 168 doesn't contain the email address of the authorizing user in the 169 MMHS-Authorizing-Users header field, then go to the next step. 170 If MMHS-Authorizing-Users header field contains the email address 171 of the authorizing user, verify validity of the header field (for 172 example by checking for S/MIME signature/review signature or for 173 DKIM signature) and also verify that the email address associated 174 with the signature matches the email address of the authorizing 175 user. If the validity of the MMHS-Authorizing-Users header field 176 can be verified, go to step 5 below. Otherwise , return the 177 message to sender (bounce) or redirect the message to a 178 designated abuse mailbox. 180 3. Allow the authorizing user to review content of the message. 181 Some of the checks can be automated (for example search for 182 keywords). (See Section 3.3.1 for additional considerations.) 183 If based on the check the authorizing user is happy to release 184 the message to MTS (or to the next authorizing user, if multiple 185 authorizations are required), the UA SHOULD enable the 186 authorizing user to protect additions to the MMHS-Authorizing- 187 Users header field, for example by allowing to add S/MIME review 188 signature (if S/MIME is used for protecting MMHS-Authorizing- 189 Users header field. See Section 3.3.2 for more details). If the 190 authorizing user wants to reject the message, it SHOULD be 191 returned to drafter with an explanatory note or MAY be discarded. 192 The authorizing user can also choose to forward the message to 193 another authorizing user for additional approval or become a new 194 Drafter of the message. If the authorizing user becomes the new 195 Drafter, its UA MUST strip any existing email addresses from the 196 MMHS-Authorizing-Users header field. 198 4. If there is an existing MMHS-Authorizing-Users header field 199 containing the email address of the authorizing user, skip this 200 step. Otherwise, insert a new MMHS-Authorizing-Users header 201 field (if absent) containing the email address of the authorizing 202 user or append the email address of the authorizing user to the 203 end of the existing MMHS-Authorizing-Users header field. 205 5. The (possibly) updated email message is either released to the 206 MTS, or to the next authorizing user, as per email system 207 configuration. Note that if the authorizing user updates the 208 message in a manner that invalidates existing S/MIME/DKIM 209 signature(s), the authorizing user becomes the Drafter, and need 210 to reapply any protections. 212 3.3.1. Processing of Encrypted Messages 214 Any encrypted message sent in an environment where Draft and Release 215 procedure is in force needs to be also encrypted to all authorizing 216 users, so that they can perform review of the message. If a User 217 Agent used by an authorizing user can't decrypt the message, it 218 SHOULD notify the sender (which can be the drafter or a previous 219 authorizing user) about the problem using a non delivery DSN or 220 through some other means. The ciphertext that cannot be decrypted by 221 the Authorizing User MAY be included in the notification to aid 222 debugging. A possible reason not to notify the sender is in order to 223 avoid Denial-of-Service attacks, for example if an attacker discovers 224 a way to inject fake messages with encryption that doesn't validate 225 in order to overflow sender's INBOX. 227 3.3.2. Authorizing S/MIME signatures 229 If S/MIME were not used, the Authorizing User can become the original 230 signer of the message. 232 If a message is signed with multiple signatures (for example using 233 different cryptographic algorithms, as described in [RFC5752]), all 234 of the signatures that can be verified by an authorizing user SHOULD 235 be signed with a review signature (authorizing signatures). A 236 recipient of the message can consider any chain of review signatures 237 that matches MMHS-Authorizing-Users header field values as valid, 238 only if all signatures in the chain verify. All of the signatures 239 that cannot be verified MUST be stripped by the Authorizing User 240 Agent. 242 When triple wrapping [RFC2634] is used, authorizing signatures are 243 applied to the outer level, so that it can be verified by MTAs 244 without the need to decrypt content. 246 3.4. Role of other Messaging Agents at the sender's domain 248 3.4.1. MDA at the sender's domain 250 If a message being sent is to be delivered within the sender's 251 domain, Message Delivery Agents (MDAs) are responsible for ensuring 252 that the message was properly authorized by authorizing user(s), as 253 determined by the sender's domain email system configuration. They 254 verify presence and validity of MMHS-Authorizing-Users header field 255 in the message, as well as validity of associated signatures on the 256 message. 258 Note that the above requirements don't apply to direct delivery to 259 any user designated as an Authorizing User. 261 3.4.2. Border MTA at the sender's domain 263 Sender's domain border MTAs are responsible for ensuring that all 264 messages that leave sender's domain were properly authorized by 265 authorizing user(s), as determined by the sender's domain email 266 system configuration. They verify presence and validity of MMHS- 267 Authorizing-Users header field in outgoing messages, as well as 268 validity of associated signatures on the message. 270 4. MMHS-Authorizing-Users header field 272 The MMHS-Authorizing-Users header field specifies the list of 273 authorizing users (or entities(*)) that countersigned this email 274 message (for example using S/MIME) before it was authorized for 275 release to MTS. Each user/entity is described by her/his/its email 276 address. 278 (*) Note that in some environments identities of authorizing users 279 are required to be hidden from recipients of email messages, so upon 280 receipt MMHS-Authorizing-Users might contain an email address 281 associated with a group of possible users. Such email addresses need 282 to have signatures that don't disclose group membership. 284 The MMHS-Authorizing-Users header field specified in this document 285 MUST NOT appear more than once in message headers. (An email message 286 that contains multiple MMHS-Authorizing-Users is malformed. An agent 287 processing such malformed message SHOULD either return it to sender 288 (if possible) or fix the message so that it only contains one copy of 289 the header field.) 290 MMHS-Authorizing-Users = "MMHS-Authorizing-Users:" 291 mailbox-list CRLF 293 mailbox-list = 295 5. Updated MIXER mapping 297 This section provides an updated version of the MIXER mapping 298 specified in [RFC2156] for MMHS applications. 300 5.1. Mapping from RFC 5322/MIME to X.400 302 In the absence of the MMHS-Authorizing-Users header field, From and 303 Sender header fields are mapped to their X.400 equivalents as 304 specified in [RFC2156]. 306 If MMHS-Authorizing-Users header field is present: 308 1. If the Sender header field is present, it is mapped to 309 IPMS.Heading.originator, otherwise the first From header field 310 address is mapped to IPMS.Heading.originator. 312 2. Map the From header field address(es) and the MMHS-Authorizing- 313 Users header field address(es) to IPMS.Heading.authorizing-users, 314 skipping the first From header field address if it was mapped to 315 IPMS.Heading.originator. 317 5.2. Mapping from X.400 to RFC 5322/MIME 319 Mapping from X.400 to Internet is controlled by whether or not a 320 particular message is considered to be a military message. A message 321 is considered to be a military message (as defined by ACP 123 322 [ACP123] and also specified in STANAG 4406 [STANAG-4406]) if there 323 are any MMHS heading extensions present. Alternatively, this MAY be 324 done by configuration (i.e. all messages can be considered to be 325 military messages). 327 For non military messages, mapping from X.400 as specified in 328 [RFC2156] is used. 330 For military messages, the following mapping is used: 332 1. IPMS.Heading.originator is mapped to From header field. 334 2. The IPMS.Heading.authorizing-users is mapped to MMHS-Authorizing- 335 Users header field. 337 6. IANA Considerations 339 IANA is requested to add the MMHS-Authorizing-Users header field 340 specified in Section 4 to the "Provisional Message Header Field 341 Names", defined by Registration Procedures for Message Header Fields 342 [RFC3864]. The registration template is as follows: 344 Header field name: MMHS-Authorizing-Users 346 Applicable protocol: mail ([RFC5322]) 348 Status: provisional 350 Author/Change controller: Alexey Melnikov 352 Specification document(s): [[RFC XXXX]] 354 Related information: 356 7. Security Considerations 358 In some military environments, the identities of authorizing users 359 are required to be hidden from recipients of email messages. This 360 can be accomplished by using a group address for the MMHS- 361 Authorizing-Users. In this way, the recipient will know that it was 362 released by an Authorizing User in that group, but the recipient will 363 not know which one of them took the action. 365 For those organizations that wish to not disclose authorizing users' 366 group membership, care must also be taken to ensure the information 367 included in the certificate used for signing email messages does not 368 disclose individuals in the group. 370 Further security considerations are described in subsections of this 371 section. 373 7.1. Forged Header Fields 375 A malicious sender may add/change an MMHS-Authorizing-Users header 376 field to bypass or alter the message authorization procedure invoked 377 for messages with no MMHS-Authorizing-Users header field. For that 378 reason it is important for agents and clients that rely on the 379 validity of the MMHS-Authorizing-Users header field to also verify 380 the review signature (or a similar protection mechanism), that 381 confirms that a particular person or entity authorized release of a 382 message. 384 7.2. Intentionally Malformed Header Fields 386 It is possible for an attacker to add an MMHS-Authorizing-Users 387 header field that is extraordinarily large or otherwise malformed in 388 an attempt to discover or exploit weaknesses in header field parsing 389 code. Implementations MUST thoroughly verify all such header fields 390 received from MTAs and be robust against intentionally as well as 391 unintentionally malformed header fields. 393 8. References 395 8.1. Normative References 397 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 398 Requirement Levels", BCP 14, RFC 2119, 399 DOI 10.17487/RFC2119, March 1997, 400 . 402 [RFC2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): 403 Mapping between X.400 and RFC 822/MIME", RFC 2156, 404 DOI 10.17487/RFC2156, January 1998, 405 . 407 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 408 DOI 10.17487/RFC5322, October 2008, 409 . 411 [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", 412 STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, 413 . 415 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 416 Specifications: ABNF", STD 68, RFC 5234, 417 DOI 10.17487/RFC5234, January 2008, 418 . 420 [RFC2634] Hoffman, P., Ed., "Enhanced Security Services for S/MIME", 421 RFC 2634, DOI 10.17487/RFC2634, June 1999, 422 . 424 [RFC5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 425 Mail Extensions (S/MIME) Version 3.2 Certificate 426 Handling", RFC 5750, DOI 10.17487/RFC5750, January 2010, 427 . 429 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 430 Mail Extensions (S/MIME) Version 3.2 Message 431 Specification", RFC 5751, DOI 10.17487/RFC5751, January 432 2010, . 434 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 435 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 436 RFC 6376, DOI 10.17487/RFC6376, September 2011, 437 . 439 [ACP123] "Common Messaging strategy and procedures", ACP 123(B), 440 May 2009. 442 8.2. Informative References 444 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 445 Procedures for Message Header Fields", BCP 90, RFC 3864, 446 DOI 10.17487/RFC3864, September 2004, 447 . 449 [STANAG-4406] 450 "STANAG 4406 Edition 2: Military Message Handling System", 451 STANAG 4406 Ed. 2, March 2005. 453 [I-D.melnikov-smime-msa-to-mda] 454 Ottaway, W. and A. Melnikov, "Domain-based signing and 455 encryption using S/MIME", draft-melnikov-smime-msa-to- 456 mda-04 (work in progress), March 2014. 458 [RFC5752] Turner, S. and J. Schaad, "Multiple Signatures in 459 Cryptographic Message Syntax (CMS)", RFC 5752, 460 DOI 10.17487/RFC5752, January 2010, 461 . 463 Appendix A. Acknowledgements 465 Many thanks for reviews and text provided by Steve Kille, Jim Schaad, 466 Russ Housley, David Wilson, Chris Bonatti and Sean Turner. 468 Some text in this document was copied from RFC 7001. 470 Author's Address 472 Alexey Melnikov 473 Isode Ltd 474 14 Castle Mews 475 Hampton, Middlesex TW12 2NP 476 UK 478 EMail: Alexey.Melnikov@isode.com