[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.127, available from https://tools.ietf.org/tools/rfcmarkup/