doc: Add RFC documents

1 files changed, 395 insertions, 0 deletions

diff --git a/doc/rfc/rfc6008.txt b/doc/rfc/rfc6008.txt
new file mode 100644
index 0000000..8550bf9
--- /dev/null
+++ b/doc/rfc/rfc6008.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                      M. Kucherawy
+Request for Comments: 6008                               Cloudmark, Inc.
+Category: Standards Track                                 September 2010
+ISSN: 2070-1721
+
+
+        Authentication-Results Registration for Differentiating
+                      among Cryptographic Results
+
+Abstract
+
+   This memo updates the registry of properties in Authentication-
+   Results: message header fields to allow a multiple-result report to
+   distinguish among one or more cryptographic signatures on a message,
+   thus associating specific results with the signatures they represent.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6008.
+
+Copyright Notice
+
+   Copyright (c) 2010 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
+   described in the Simplified BSD License.
+
+
+
+
+
+
+
+Kucherawy                    Standards Track                    [Page 1]
+
+RFC 6008           Auth-Results Header.b Registration     September 2010
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
+   2.  Keywords  . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
+   3.  Discussion  . . . . . . . . . . . . . . . . . . . . . . . . . . 2
+   4.  Definition  . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
+   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
+     6.1.  Improvement . . . . . . . . . . . . . . . . . . . . . . . . 4
+     6.2.  Result Forgeries  . . . . . . . . . . . . . . . . . . . . . 4
+     6.3.  New Schemes with Small Signatures . . . . . . . . . . . . . 4
+   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
+     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 5
+   Appendix A.  Authentication-Results Example . . . . . . . . . . . . 6
+     A.1.  Multiple DKIM Signatures with One Failure . . . . . . . . . 6
+   Appendix B.  Acknowledgements . . . . . . . . . . . . . . . . . . . 7
+
+1.  Introduction
+
+   [AUTHRES] defined a new header field for electronic mail messages
+   that presents the results of a message authentication effort in a
+   machine-readable format.  Absent from that specification was the
+   means by which the results of two cryptographic signatures, such as
+   those provided by [DKIM], can both have results reported in an
+   unambiguous manner.
+
+   Fortunately, [AUTHRES] created IANA registries of reporting
+   properties, enabling an easy remedy for this problem.  This memo thus
+   registers an additional reporting property allowing a result to be
+   associated with a specific digital signature.
+
+2.  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].
+
+3.  Discussion
+
+   A message can contain multiple signatures of a common sender
+   authentication mechanism, such as [DKIM].  For example, a DomainKeys
+   Identified Mail (DKIM) signer could apply signatures using two or
+   more different message canonicalization algorithms to determine the
+   resistance of each to being broken in transit.
+
+
+
+
+
+
+Kucherawy                    Standards Track                    [Page 2]
+
+RFC 6008           Auth-Results Header.b Registration     September 2010
+
+
+   By applying supported "ptype.property" combinations (cf. the ABNF in
+   [AUTHRES]), a result can be associated with a given signature
+   provided the signatures are all unique within one of the registered
+   values (e.g., all of them had unique "header.d" or "header.i"
+   values).  This is not guaranteed, however; a single signing agent
+   might have practical reasons for affixing multiple signatures with
+   the same "d=" values while varying other signature parameters.  This
+   means one could get a "dkim=pass" and "dkim=fail" result
+   simultaneously on verification, which is clearly ambiguous.
+
+   It is thus necessary either to create or to identify a signature
+   attribute guaranteed to be unique, such that it is possible to
+   unambiguously associate a result with the signature to which it
+   refers.
+
+   Collisions during general use of SHA1 and SHA256 are uncommon (see
+   [HASH-ATTACKS]), and RSA key signing mechanisms are resilient to
+   producing common substrings.  Thus, the actual digital signature for
+   a cryptographic signing of the message is an ideal property for such
+   a unique identification.  It is not, however, necessary to include
+   the entire digital signature in an [AUTHRES] header field just to
+   identify which result goes with which signature; since the signatures
+   will almost always be substantially different, it is anticipated that
+   only the first several bytes of a signature will be needed for
+   disambiguating results.
+
+4.  Definition
+
+   This memo adds the "header.b" reporting item to the IANA "Email
+   Authentication Methods" registry created upon publication of
+   [AUTHRES].  The value associated with this item in the header field
+   MUST be at least the first eight characters of the digital signature
+   (the "b=" tag from a DKIM-Signature) for which a result is being
+   relayed, and MUST be long enough to be unique among the results being
+   reported.  Where the total length of the digital signature is fewer
+   than eight characters, the entire signature MUST be included.
+   Matching of the value of this item against the signature itself MUST
+   be case-sensitive.
+
+   If an evaluating agent observes that, despite the use of this
+   disambiguating tag, unequal authentication results are offered about
+   the same signature from the same trusted authserv-id, that agent
+   SHOULD ignore all such results.
+
+
+
+
+
+
+
+
+Kucherawy                    Standards Track                    [Page 3]
+
+RFC 6008           Auth-Results Header.b Registration     September 2010
+
+
+5.  IANA Considerations
+
+   Per [IANA-CONSID], the following item is added to the "Email
+   Authentication Methods" registry:
+
+   +------------+----------+--------+----------------+-----------------+
+   |   Method   | Defined  | ptype  | property       | value           |
+   +------------+----------+--------+----------------+-----------------+
+   |    dkim    | RFC4871  | header | b              | full or partial |
+   |            |          |        |                | value of        |
+   |            |          |        |                | signature "b"   |
+   |            |          |        |                | tag             |
+   +------------+----------+--------+----------------+-----------------+
+
+6.  Security Considerations
+
+   [AUTHRES] discussed general security considerations regarding the use
+   of this header field.  The following new security considerations
+   apply when adding or processing this new ptype/property combination:
+
+6.1.  Improvement
+
+   Rather than introducing a new security issue, this can be seen to fix
+   a security weakness of the original specification: Useful information
+   can now be obtained from results that could previously have been
+   ambiguous and thus obscured or, worse, misinterpreted.
+
+6.2.  Result Forgeries
+
+   An attacker could copy a valid signature and add it to a message in
+   transit, modifying some portion of it.  This could cause two results
+   to be provided for the same "header.b" value even if the entire "b="
+   string is used in an attempt to differentiate the results.  This
+   attack could cause an ambiguous result to be relayed and possibly
+   neutralize any benefit given to a "pass" result that would have
+   otherwise occurred, possibly impacting the delivery of valid
+   messages.
+
+   It is worth noting, however, that a false negative ("fail") can be
+   generated in this way, but it is extremely difficult to create a
+   false positive ("pass") through such an attack.  Thus, a cautious
+   implementation could discard the false negative in that instance.
+
+6.3.  New Schemes with Small Signatures
+
+   Should a new signing scheme be introduced with a signature whose
+   length is less than eight characters, Section 4 specifies that the
+   entire signature must be used.  The obvious concern in such a case
+
+
+
+Kucherawy                    Standards Track                    [Page 4]
+
+RFC 6008           Auth-Results Header.b Registration     September 2010
+
+
+   would be that the signature scheme is itself prone to collisions,
+   making the value reported by this field not useful.  In such cases,
+   the risk is created by the likelihood of collisions and not by this
+   mechanism; furthermore, Section 4 recommends the results be ignored
+   if that were to occur, preventing the application of an ambiguous
+   result.
+
+7.  References
+
+7.1.  Normative References
+
+   [AUTHRES]       Kucherawy, M., "Message Header Field for Indicating
+                   Message Authentication Status", RFC 5451, April 2009.
+
+   [DKIM]          Allman, E., Callas, J., Delany, M., Libbey, M.,
+                   Fenton, J., and M. Thomas, "DomainKeys Identified
+                   Mail (DKIM) Signatures", RFC 4871, May 2007.
+
+   [KEYWORDS]      Bradner, S., "Key words for use in RFCs to Indicate
+                   Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+7.2.  Informative References
+
+   [HASH-ATTACKS]  Hoffman, P. and B. Schneier, "Attacks on
+                   Cryptographic Hashes in Internet Protocols",
+                   RFC 4270, November 2005.
+
+   [IANA-CONSID]   Narten, T. and H. Alvestrand, "Guidelines for Writing
+                   an IANA Considerations Section in RFCs", BCP 26,
+                   RFC 5226, May 2008.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kucherawy                    Standards Track                    [Page 5]
+
+RFC 6008           Auth-Results Header.b Registration     September 2010
+
+
+Appendix A.  Authentication-Results Example
+
+   This section presents an example of the use of this new item header
+   field to indicate unambiguous authentication results.
+
+A.1.  Multiple DKIM Signatures with One Failure
+
+   A message that had two DKIM signatures applied by the same domain,
+   one of which failed:
+
+        Authentication-Results: mail-router.example.net;
+              dkim=pass (good signature) header.d=newyork.example.com
+                    header.b=oINEO8hg;
+              dkim=fail (bad signature) header.d=newyork.example.com
+                    header.b=EToRSuvU
+        Received: from newyork.example.com
+                  (newyork.example.com [192.0.2.250])
+              by mail-router.example.net (8.11.6/8.11.6)
+                  for <recipient@example.net>
+                  with ESMTP id i7PK0sH7021929;
+              Fri, Feb 15 2002 17:19:22 -0800
+        DKIM-Signature: v=1; a=rsa-sha256; s=rashani;
+              d=newyork.example.com;
+              t=1188964191; c=relaxed/simple;
+              h=From:Date:To:Message-Id:Subject;
+              bh=sEu28nfs9fuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m7=;
+              b=oINEO8hgn/gnunsg ... 9n9ODSNFSDij3=
+        DKIM-Signature: v=1; a=rsa-sha256; s=rashani;
+              d=newyork.example.com;
+              t=1188964191; c=simple/simple;
+              h=From:Date:To:Message-Id:Subject;
+              bh=sEu28nfs9fuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m7=;
+              b=EToRSuvUfQVP3Bkz ... rTB0t0gYnBVCM=
+        From: sender@newyork.example.com
+        Date: Fri, Feb 15 2002 16:54:30 -0800
+        To: meetings@example.net
+        Message-Id: <12345.abc@newyork.example.com>
+        Subject: here's a sample
+
+   Example 1: Header field reporting results from multiple signatures
+   added at initial signing
+
+   Here we see an example of a message that was signed twice by the
+   author's ADministrative Management Domain (ADMD).  One signature used
+   "relaxed" header canonicalization, and the other used "simple" header
+   canonicalization; both used "simple" body canonicalization.
+
+
+
+
+
+Kucherawy                    Standards Track                    [Page 6]
+
+RFC 6008           Auth-Results Header.b Registration     September 2010
+
+
+   Presumably due to a change in one of the five header fields covered
+   by the two signatures, the former signature passed, while the latter
+   signature failed to verify.  In particular, the "relaxed" header
+   canonicalization of [DKIM] is resilient to changes in whitespace in
+   the header, while "simple" is not, and the latter is the one that
+   failed in this example.
+
+   The item registered by this memo allows an evaluation module to
+   determine which DKIM result goes with which signature.  Without the
+   "header.b" portion of the result, it is unclear which one passed and
+   which one failed.
+
+Appendix B.  Acknowledgements
+
+   The author wishes to acknowledge the following for their review and
+   constructive criticism of this proposal: Dave Crocker, Tony Hansen,
+   Eliot Lear, S. Moonesamy, and Alessandro Vesely.
+
+Author's Address
+
+   Murray S. Kucherawy
+   Cloudmark, Inc.
+   128 King St., 2nd Floor
+   San Francisco, CA  94107
+   US
+
+   Phone: +1 415 946 3800
+   EMail: msk@cloudmark.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kucherawy                    Standards Track                    [Page 7]
+