idnits 2.17.00 (12 Aug 2021) /tmp/idnits30806/draft-kucherawy-original-authres-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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC6376, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC5451, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5451, updated by this document, for RFC5378 checks: 2004-09-10) -- 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 (February 20, 2012) is 3736 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) ** Obsolete normative reference: RFC 5451 (ref. 'AUTHRES') (Obsoleted by RFC 7001) -- Obsolete informational reference (is this intentional?): RFC 4871 (ref. 'DKIM') (Obsoleted by RFC 6376) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual submission M. Chew 3 Internet-Draft Google, Inc. 4 Updates: 5451, 6376 (if approved) M. Kucherawy 5 Intended status: Standards Track Cloudmark, Inc. 6 Expires: August 23, 2012 February 20, 2012 8 Original-Authentication-Results Header Field 9 draft-kucherawy-original-authres-00 11 Abstract 13 This memo defines a message header field for relaying message 14 authentication results. The new field differs from the existing 15 Authentication-Results message header field in that it is 16 specifically used to relay message authentication results from one 17 administrative domain to another. 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 August 23, 2012. 36 Copyright Notice 38 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.2. Email Architecture . . . . . . . . . . . . . . . . . . . . 3 57 3. Handling Sequence . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. Definition . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 5. Adding the Header Field . . . . . . . . . . . . . . . . . . . . 5 60 6. Processing the Header Field . . . . . . . . . . . . . . . . . . 5 61 7. DKIM Functional Extension . . . . . . . . . . . . . . . . . . . 5 62 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 63 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 64 9.1. Trust Is Subjective . . . . . . . . . . . . . . . . . . . . 6 65 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 10.1. Normative References . . . . . . . . . . . . . . . . . . . 6 67 10.2. Informative References . . . . . . . . . . . . . . . . . . 6 68 Appendix A. Original-Authentication-Results Examples . . . . . . . 7 69 A.1. Relayed Authentication Results . . . . . . . . . . . . . . 8 70 A.2. Relaying Original Results . . . . . . . . . . . . . . . . . 9 71 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . . 9 73 1. Introduction 75 [AUTHRES] defines a new header field for email that presents the 76 results of a message authentication effort in a machine-readable 77 format. It thus introduced a mechanism for relaying message-level 78 authentication results from a mail server running on a border system 79 to internal hosts. This created a trusted channel between border 80 mail servers and internal agents relaying the results of that 81 authentication work. That document also created rules for ensuring 82 those data can be trusted by specifying under what circumstances 83 instances of that field should be removed prior to delivery. 85 Some sites wish to take into consideration such authentication 86 results claimed by trusted intermediaries, effectively extending the 87 trusted channel to specific external entities. Although [AUTHRES] 88 includes support for this notion, this separate mechanism is simpler, 89 more robust, and requires no changes to existing authentication 90 infrastructure. 92 Therefore, this document defines a new field called Original- 93 Authentication-Results. The content of the field is identical to 94 that specified in [AUTHRES]. This field is required to be unique, 95 appearing only once in a message, and thus it is possible to 96 determine conclusively whether or not it is included in the part of 97 the header covered by a signature. The presence of multiple 98 instances of this field in a message would be an indication of either 99 an implementation error or the injection of a fraudulent claim. This 100 "single instance" constraint enables the relaying of the results of 101 message authentication work as it was received for the first time by 102 a participating MTA. 104 The relationship between [AUTHRES] and this header field is analogous 105 to the relationship between [SMTP] and [MSA]. 107 2. Definitions 109 2.1. Keywords 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [KEYWORDS]. 115 2.2. Email Architecture 117 Readers are encouraged to be familiar with the material found in 118 [EMAIL-ARCH]. Some terms used in this memo are defined there. 120 3. Handling Sequence 122 This section describes the intended use of the field by all parties 123 being considered. 125 Suppose a user A sends an email to mailing list B. The message is 126 signed with [DKIM]. Upon arrival at B, the MTA evaluates A's DKIM 127 signature, producing a result. The mailing list at B alters the 128 message in some way that causes the DKIM signature become invalid. B 129 then relays the message to all of the mailing list's current 130 subscribers, which includes C. Upon arrival at C, the message again 131 has its DKIM signatures evaluated, but this time it fails. Any 132 privileged treatment at C that would normally be afforded a message 133 signed by A is lost because of the mailing list software's 134 alterations of the original. 136 If, however, C could declare that it trusts that B's email 137 infrastructure properly implements DKIM and is also otherwise 138 generally secure, then any statements by B about A's signature could 139 be trusted. This means C could once again give A's mail preferential 140 treatment as long as it arrived at B with a still-valid DKIM 141 signature. 143 The header field introduced here provides a mechanism to make such a 144 statement, and provides the rules under which the claims made by B 145 can be believed and applied. 147 4. Definition 149 This memo adds a new header field to the "Permanent Message Header 150 Field Registry", as follows: 152 Header field name: Original-Authentication-Results 154 Applicable protocol: mail 156 Status: standard 158 Author/Change controller: IETF 160 Specification document(s): [this memo] 162 Related information: [AUTHRES] 164 5. Adding the Header Field 166 A processing agent adding this field SHOULD NOT add this field if one 167 already exists, as presumably any earlier handling agents were closer 168 to the origination of the message. If it does, it MUST remove all 169 existing instances of this field before adding a new one. 171 The syntax of this field MUST conform to [AUTHRES] and its 172 extensions. 174 This header field SHOULD be prepended to the existing header rather 175 than being added any other place in the header so that some idea of 176 where or when it was added can be determined. It SHOULD be handled 177 as trace information as defined in [SMTP]. 179 The added field MUST be included in the portion of the header of the 180 message covered by a signature added by that agent's ADMD, using 181 [DKIM] or another mechanism of equivalent or stronger security 182 semantics. The "d=" of the added signature MUST match the 183 authserv-id (see Section 2.3 of [AUTHRES]) included in the header 184 field being added. 186 6. Processing the Header Field 188 An agent receiving a message with more than one instance of this 189 field MUST ignore all of them. The field MUST also be ignored if it 190 is not covered by a signature added by the trusted third party named 191 in the authserv-id portion of the field. 193 The choice of which external parties' authentication results are to 194 be trusted is entirely an operational one and not specified here. 195 Presumably this is enabled explicitly and only by prior arrangement 196 after appropriate dialogue and system auditing has been done. If 197 this field is observed on a message and appears not to have been 198 added by a trusted agent, it MUST be ignored. 200 An instance of this header field that satisfies these restrictions 201 SHOULD be treated as semantically equivalent to an [AUTHRES] field 202 added by the evaluating ADMD. 204 7. DKIM Functional Extension 206 The function defined by [DKIM] accepts a message as input and 207 includes the following as its outputs: 209 1. A result as to the outcome of the validation attempt of each 210 signature (e.g. pass or fail, possibly with a more descriptive 211 error code); 213 2. The name of the domain that attached each signature, namely the 214 value of the "d=" tag in each signature; 216 3. Optionally, the name of the signing identity found in the 217 signature, namely the value of the "i=" tag in each signature. 219 To satisfy the signature requirement specified in Section 4, a DKIM 220 API would need to be extended to include an indication of whether or 221 not the header field defined by this memo was covered by a signature. 223 8. IANA Considerations 225 IANA is requested to add this new field, as defined in Section 4, to 226 the Email Permanent Header Field Registry. 228 9. Security Considerations 230 This section discusses security issues regarding the handling of this 231 new header field. 233 9.1. Trust Is Subjective 235 A malicious sender could generate a message compliant with this 236 specification, asserting that the original message authenticates from 237 some valued domain. Recipients will need to be sure to separately 238 vet the list of domains they trust, and perhaps do periodic audits of 239 both the list and the other ADMDs on it. 241 10. References 243 10.1. Normative References 245 [AUTHRES] Kucherawy, M., "Message Header Field for Indicating 246 Message Authentication Status", RFC 5451, April 2009. 248 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 249 Requirement Levels", BCP 14, RFC 2119, March 1997. 251 10.2. Informative References 253 [DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, 254 J., and M. Thomas, "DomainKeys Identified Mail (DKIM) 255 Signatures", RFC 4871, May 2007. 257 [EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", RFC 5598, 258 July 2009. 260 [MSA] Gellens, R. and J. Klensin, "Message Submission", 261 RFC 6409, November 2011. 263 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 264 October 2008. 266 Appendix A. Original-Authentication-Results Examples 268 This section presents an example of the use of this new header field 269 to indicate trustable message authentication results added by an 270 intermediary. 272 A.1. Relayed Authentication Results 274 A message that contains basic relayed authentication information: 276 Authentication-Results: border.example.org; 277 dkim=pass header.d=example.net; 278 dkim=fail header.d=example.com 279 DKIM-Signature: a=rsa-sha256; c=relaxed/simple; s=test; 280 d=example.net; 281 h=From:Date:To:Subject:Message-Id:Authentication-Results; 282 bh=8hsafun...9813=; 283 b=xkBnyZcOz...dscC5j9eAw0q2yFz43aYD8== 284 Authentication-Results: lists.example.net; dkim=pass 285 header.d=example.com 286 Received: from mail-router.example.com 287 (mail-router.example.com [192.0.2.250]) 288 by lists.example.net (8.11.6/8.11.6) 289 with ESMTP id g11Lkr60042377; 290 Fri, Feb 15 2002 17:19:22 -0800 291 DKIM-Signature: a=rsa-sha256; c=relaxed/simple; s=test; 292 d=example.com; h=From:Date:To:Subject:Message-Id; 293 bh=sa98djf...ffdf=; 294 b=BvC+mpYILJo...u1n6RUcGxJs0LULya8Kg== 295 Received: from internal-0-2-1.example.com 296 (internal-0-2-1.example.com [192.0.2.1]) 297 by mail-router.example.com (8.11.6/8.11.6) 298 with ESMTP id g1G0r1kA003489; 299 Fri, Feb 15 2002 17:19:07 -0800 300 From: sender@example.com 301 Date: Fri, Feb 15 2002 16:54:30 -0800 302 To: sample-list@example.net 303 Message-Id: <12345.abc@example.com> 304 Subject: [sample] here's a sample 306 Hello! Goodbye! 308 An example showing a message that transited a list and shows the 309 authentication work done enroute 311 This is an example of a message that went from an author domain 312 (example.com) via a mailing list called sample@example.net, which 313 then relayed the message to receiver@example.org, who is subscribed 314 to that list. 316 The original message was validated by the list server, as reflected 317 in an Authentication-Results field added by the list software. 319 Since the list software is configured to add a tag prefix to the 320 Subject: field, the DKIM signature from example.com is invalidated. 321 However, the Authentication-Results added at example.net is asserting 322 that the original signature was valid when it was received. To 323 assert the validity of that claim, the new Authentication-Results 324 field is signed as well. 326 Finally, example.org, which explicitly trusts example.net in this 327 illustration, can believe that the original message contained a valid 328 signature from example.com. 330 [now explain what problem isn't covered here] 332 A.2. Relaying Original Results 334 A message that contains relayed authentication information that can 335 be trusted: 337 (example message) 339 [describe what's going on in the example] 341 [now explain how this solves the problem] 343 Appendix B. Acknowledgements 345 The author wishes to acknowledge the following for their review and 346 constructive criticism of this proposal: Dave Crocker 348 Authors' Addresses 350 Monica Chew 351 Google, Inc. 352 345 Spear St. 353 San Francisco, CA 94105 354 US 356 Phone: +1 650 253 0000 357 EMail: mmc@google.com 358 Murray S. Kucherawy 359 Cloudmark, Inc. 360 128 King St., 2nd Floor 361 San Francisco, CA 94107 362 US 364 Phone: +1 415 946 3800 365 EMail: msk@cloudmark.com