Individual submission M. Chew Internet-Draft Google, Inc. Updates: 5451, 6376 (if approved) M. Kucherawy Intended status: Standards Track Cloudmark, Inc. Expires: August 23, 2012 February 20, 2012 Original-Authentication-Results Header Field draft-kucherawy-original-authres-00 Abstract This memo defines a message header field for relaying message authentication results. The new field differs from the existing Authentication-Results message header field in that it is specifically used to relay message authentication results from one administrative domain to another. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 23, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as Chew & Kucherawy Expires August 23, 2012 [Page 1] Internet-Draft Original-Auth-Results Header Field February 2012 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Email Architecture . . . . . . . . . . . . . . . . . . . . 3 3. Handling Sequence . . . . . . . . . . . . . . . . . . . . . . . 4 4. Definition . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Adding the Header Field . . . . . . . . . . . . . . . . . . . . 5 6. Processing the Header Field . . . . . . . . . . . . . . . . . . 5 7. DKIM Functional Extension . . . . . . . . . . . . . . . . . . . 5 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 9.1. Trust Is Subjective . . . . . . . . . . . . . . . . . . . . 6 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 10.1. Normative References . . . . . . . . . . . . . . . . . . . 6 10.2. Informative References . . . . . . . . . . . . . . . . . . 6 Appendix A. Original-Authentication-Results Examples . . . . . . . 7 A.1. Relayed Authentication Results . . . . . . . . . . . . . . 8 A.2. Relaying Original Results . . . . . . . . . . . . . . . . . 9 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . . 9 Chew & Kucherawy Expires August 23, 2012 [Page 2] Internet-Draft Original-Auth-Results Header Field February 2012 1. Introduction [AUTHRES] defines a new header field for email that presents the results of a message authentication effort in a machine-readable format. It thus introduced a mechanism for relaying message-level authentication results from a mail server running on a border system to internal hosts. This created a trusted channel between border mail servers and internal agents relaying the results of that authentication work. That document also created rules for ensuring those data can be trusted by specifying under what circumstances instances of that field should be removed prior to delivery. Some sites wish to take into consideration such authentication results claimed by trusted intermediaries, effectively extending the trusted channel to specific external entities. Although [AUTHRES] includes support for this notion, this separate mechanism is simpler, more robust, and requires no changes to existing authentication infrastructure. Therefore, this document defines a new field called Original- Authentication-Results. The content of the field is identical to that specified in [AUTHRES]. This field is required to be unique, appearing only once in a message, and thus it is possible to determine conclusively whether or not it is included in the part of the header covered by a signature. The presence of multiple instances of this field in a message would be an indication of either an implementation error or the injection of a fraudulent claim. This "single instance" constraint enables the relaying of the results of message authentication work as it was received for the first time by a participating MTA. The relationship between [AUTHRES] and this header field is analogous to the relationship between [SMTP] and [MSA]. 2. Definitions 2.1. Keywords The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS]. 2.2. Email Architecture Readers are encouraged to be familiar with the material found in [EMAIL-ARCH]. Some terms used in this memo are defined there. Chew & Kucherawy Expires August 23, 2012 [Page 3] Internet-Draft Original-Auth-Results Header Field February 2012 3. Handling Sequence This section describes the intended use of the field by all parties being considered. Suppose a user A sends an email to mailing list B. The message is signed with [DKIM]. Upon arrival at B, the MTA evaluates A's DKIM signature, producing a result. The mailing list at B alters the message in some way that causes the DKIM signature become invalid. B then relays the message to all of the mailing list's current subscribers, which includes C. Upon arrival at C, the message again has its DKIM signatures evaluated, but this time it fails. Any privileged treatment at C that would normally be afforded a message signed by A is lost because of the mailing list software's alterations of the original. If, however, C could declare that it trusts that B's email infrastructure properly implements DKIM and is also otherwise generally secure, then any statements by B about A's signature could be trusted. This means C could once again give A's mail preferential treatment as long as it arrived at B with a still-valid DKIM signature. The header field introduced here provides a mechanism to make such a statement, and provides the rules under which the claims made by B can be believed and applied. 4. Definition This memo adds a new header field to the "Permanent Message Header Field Registry", as follows: Header field name: Original-Authentication-Results Applicable protocol: mail Status: standard Author/Change controller: IETF Specification document(s): [this memo] Related information: [AUTHRES] Chew & Kucherawy Expires August 23, 2012 [Page 4] Internet-Draft Original-Auth-Results Header Field February 2012 5. Adding the Header Field A processing agent adding this field SHOULD NOT add this field if one already exists, as presumably any earlier handling agents were closer to the origination of the message. If it does, it MUST remove all existing instances of this field before adding a new one. The syntax of this field MUST conform to [AUTHRES] and its extensions. This header field SHOULD be prepended to the existing header rather than being added any other place in the header so that some idea of where or when it was added can be determined. It SHOULD be handled as trace information as defined in [SMTP]. The added field MUST be included in the portion of the header of the message covered by a signature added by that agent's ADMD, using [DKIM] or another mechanism of equivalent or stronger security semantics. The "d=" of the added signature MUST match the authserv-id (see Section 2.3 of [AUTHRES]) included in the header field being added. 6. Processing the Header Field An agent receiving a message with more than one instance of this field MUST ignore all of them. The field MUST also be ignored if it is not covered by a signature added by the trusted third party named in the authserv-id portion of the field. The choice of which external parties' authentication results are to be trusted is entirely an operational one and not specified here. Presumably this is enabled explicitly and only by prior arrangement after appropriate dialogue and system auditing has been done. If this field is observed on a message and appears not to have been added by a trusted agent, it MUST be ignored. An instance of this header field that satisfies these restrictions SHOULD be treated as semantically equivalent to an [AUTHRES] field added by the evaluating ADMD. 7. DKIM Functional Extension The function defined by [DKIM] accepts a message as input and includes the following as its outputs: 1. A result as to the outcome of the validation attempt of each signature (e.g. pass or fail, possibly with a more descriptive error code); Chew & Kucherawy Expires August 23, 2012 [Page 5] Internet-Draft Original-Auth-Results Header Field February 2012 2. The name of the domain that attached each signature, namely the value of the "d=" tag in each signature; 3. Optionally, the name of the signing identity found in the signature, namely the value of the "i=" tag in each signature. To satisfy the signature requirement specified in Section 4, a DKIM API would need to be extended to include an indication of whether or not the header field defined by this memo was covered by a signature. 8. IANA Considerations IANA is requested to add this new field, as defined in Section 4, to the Email Permanent Header Field Registry. 9. Security Considerations This section discusses security issues regarding the handling of this new header field. 9.1. Trust Is Subjective A malicious sender could generate a message compliant with this specification, asserting that the original message authenticates from some valued domain. Recipients will need to be sure to separately vet the list of domains they trust, and perhaps do periodic audits of both the list and the other ADMDs on it. 10. References 10.1. Normative References [AUTHRES] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 5451, April 2009. [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 10.2. Informative References [DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", RFC 4871, May 2007. [EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009. [MSA] Gellens, R. and J. Klensin, "Message Submission", Chew & Kucherawy Expires August 23, 2012 [Page 6] Internet-Draft Original-Auth-Results Header Field February 2012 RFC 6409, November 2011. [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008. Appendix A. Original-Authentication-Results Examples This section presents an example of the use of this new header field to indicate trustable message authentication results added by an intermediary. Chew & Kucherawy Expires August 23, 2012 [Page 7] Internet-Draft Original-Auth-Results Header Field February 2012 A.1. Relayed Authentication Results A message that contains basic relayed authentication information: Authentication-Results: border.example.org; dkim=pass header.d=example.net; dkim=fail header.d=example.com DKIM-Signature: a=rsa-sha256; c=relaxed/simple; s=test; d=example.net; h=From:Date:To:Subject:Message-Id:Authentication-Results; bh=8hsafun...9813=; b=xkBnyZcOz...dscC5j9eAw0q2yFz43aYD8== Authentication-Results: lists.example.net; dkim=pass header.d=example.com Received: from mail-router.example.com (mail-router.example.com [192.0.2.250]) by lists.example.net (8.11.6/8.11.6) with ESMTP id g11Lkr60042377; Fri, Feb 15 2002 17:19:22 -0800 DKIM-Signature: a=rsa-sha256; c=relaxed/simple; s=test; d=example.com; h=From:Date:To:Subject:Message-Id; bh=sa98djf...ffdf=; b=BvC+mpYILJo...u1n6RUcGxJs0LULya8Kg== Received: from internal-0-2-1.example.com (internal-0-2-1.example.com [192.0.2.1]) by mail-router.example.com (8.11.6/8.11.6) with ESMTP id g1G0r1kA003489; Fri, Feb 15 2002 17:19:07 -0800 From: sender@example.com Date: Fri, Feb 15 2002 16:54:30 -0800 To: sample-list@example.net Message-Id: <12345.abc@example.com> Subject: [sample] here's a sample Hello! Goodbye! An example showing a message that transited a list and shows the authentication work done enroute This is an example of a message that went from an author domain (example.com) via a mailing list called sample@example.net, which then relayed the message to receiver@example.org, who is subscribed to that list. The original message was validated by the list server, as reflected in an Authentication-Results field added by the list software. Since the list software is configured to add a tag prefix to the Chew & Kucherawy Expires August 23, 2012 [Page 8] Internet-Draft Original-Auth-Results Header Field February 2012 Subject: field, the DKIM signature from example.com is invalidated. However, the Authentication-Results added at example.net is asserting that the original signature was valid when it was received. To assert the validity of that claim, the new Authentication-Results field is signed as well. Finally, example.org, which explicitly trusts example.net in this illustration, can believe that the original message contained a valid signature from example.com. [now explain what problem isn't covered here] A.2. Relaying Original Results A message that contains relayed authentication information that can be trusted: (example message) [describe what's going on in the example] [now explain how this solves the problem] Appendix B. Acknowledgements The author wishes to acknowledge the following for their review and constructive criticism of this proposal: Dave Crocker Authors' Addresses Monica Chew Google, Inc. 345 Spear St. San Francisco, CA 94105 US Phone: +1 650 253 0000 EMail: mmc@google.com Chew & Kucherawy Expires August 23, 2012 [Page 9] Internet-Draft Original-Auth-Results Header Field February 2012 Murray S. Kucherawy Cloudmark, Inc. 128 King St., 2nd Floor San Francisco, CA 94107 US Phone: +1 415 946 3800 EMail: msk@cloudmark.com Chew & Kucherawy Expires August 23, 2012 [Page 10]