[要約] RFC 6008は、異なる暗号化結果を区別するためのAuthentication-Results登録に関するものであり、その目的は、電子メールの認証結果をより詳細に報告することです。
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.
このメモは、Authentication-Results：メッセージヘッダーフィールドのプロパティのレジストリを更新して、複数結果レポートがメッセージの1つ以上の暗号署名を区別できるようにし、特定の結果をそれらが表す署名に関連付けます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
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.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
[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.
[AUTHRES]は、電子メールメッセージの新しいヘッダーフィールドを定義しました。このヘッダーフィールドは、メッセージ認証の結果を機械可読形式で表示します。その仕様には、[DKIM]によって提供されたものなど、2つの暗号署名の結果がどちらも明確な方法で結果を報告できる手段がありませんでした。
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.
幸い、[AUTHRES]はレポートプロパティのIANAレジストリを作成し、この問題を簡単に修正できるようにしました。したがって、このメモは、結果を特定のデジタル署名に関連付けることができる追加のレポートプロパティを登録します。
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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [キーワード]で説明されているように解釈されます。
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.
メッセージには、[DKIM]などの一般的な送信者認証メカニズムの複数の署名を含めることができます。たとえば、DomainKeys Identified Mail（DKIM）署名者は、2つ以上の異なるメッセージ正規化アルゴリズムを使用して署名を適用し、転送中の破損に対するそれぞれの耐性を判断できます。
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.
サポートされている "ptype.property"の組み合わせ（[AUTHRES]のABNFを参照）を適用することにより、登録された値のいずれかで署名がすべて一意であれば、結果を特定の署名に関連付けることができます。 header.d "または" header.i "の値）。ただし、これは保証されていません。単一の署名エージェントは、他の署名パラメーターを変えながら、同じ「d =」値を持つ複数の署名を添付するという実用的な理由があるかもしれません。これは、検証時に「dkim = pass」と「dkim = fail」の結果が同時に得られる可能性があることを意味しますが、これは明らかにあいまいです。
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.
SHA1とSHA256の一般的な使用中の衝突は一般的ではなく（[HASH-ATTACKS]を参照）、RSA鍵署名メカニズムは一般的な部分文字列の生成に対して回復力があります。したがって、メッセージの暗号化署名の実際のデジタル署名は、そのような一意の識別に理想的なプロパティです。ただし、デジタル署名全体を[AUTHRES]ヘッダーフィールドに含める必要はなく、どの結果がどの署名に対応するかを識別するだけです。署名はほぼ常に異なるため、結果を明確にするために必要なのは、署名の最初の数バイトのみであることが予想されます。
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.
このメモは、[AUTHRES]の公開時に作成されたIANAの「Email Authentication Methods」レジストリに「header.b」レポート項目を追加します。ヘッダーフィールドのこのアイテムに関連付けられた値は、結果がリレーされるデジタル署名（DKIM-Signatureの「b =」タグ）の最初の8文字以上である必要があり、報告されている結果の中でユニークです。デジタル署名の全長が8文字未満の場合は、署名全体を含める必要があります。このアイテムの値と署名自体の照合は、大文字と小文字を区別する必要があります。
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.
評価エージェントがこのあいまいさを排除するタグを使用しているにもかかわらず、同じ信頼されたauthserv-idからの同じ署名について不均等な認証結果が提供されることを観察した場合、そのエージェントはそのような結果をすべて無視する必要があります（SHOULD）。
Per [IANA-CONSID], the following item is added to the "Email Authentication Methods" registry:
[IANA-CONSID]ごとに、次の項目が「Email Authentication Methods」レジストリに追加されます。
+------------+----------+--------+----------------+-----------------+
| Method | Defined | ptype | property | value |
+------------+----------+--------+----------------+-----------------+
| dkim | RFC4871 | header | b | full or partial |
| | | | | value of |
| | | | | signature "b" |
| | | | | tag |
+------------+----------+--------+----------------+-----------------+
[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:
[AUTHRES]は、このヘッダーフィールドの使用に関する一般的なセキュリティの考慮事項について説明しました。この新しいptypeとプロパティの組み合わせを追加または処理するときは、次の新しいセキュリティの考慮事項が適用されます。
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.
これは、新しいセキュリティの問題を導入するのではなく、元の仕様のセキュリティの弱点を修正するために見ることができます。以前はあいまいで、あいまいになっているか、悪いことに誤解されていた可能性がある結果から、有用な情報を取得できるようになりました。
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.
攻撃者は有効な署名をコピーして、送信中のメッセージに追加し、その一部を変更する可能性があります。これにより、 "b ="文字列全体を使用して結果を区別しようとしても、同じ "header.b"値に対して2つの結果が提供される可能性があります。この攻撃により、あいまいな結果が中継され、「成功」した結果に与えられていたはずのメリットが無力化され、有効なメッセージの配信に影響が及ぶ可能性があります。
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.
ただし、この方法で偽陰性（「失敗」）を生成できることは注目に値しますが、このような攻撃によって偽陽性（「合格」）を作成することは非常に困難です。したがって、慎重な実装では、その場合の偽陰性を破棄できます。
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 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.
長さが8文字未満の署名を使用して新しい署名スキームを導入する場合、セクション4では、署名全体を使用する必要があることを指定しています。このような場合の明らかな懸念は、署名スキーム自体が衝突する傾向があるため、このフィールドによって報告される値が役に立たなくなることです。このような場合、リスクはこのメカニズムではなく衝突の可能性によって作成されます。さらに、セクション4では、結果が発生した場合は結果を無視して、あいまいな結果の適用を防ぐことを推奨しています。
[AUTHRES] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 5451, April 2009.
[AUTHRES] Kucherawy、M。、「メッセージ認証ステータスを示すメッセージヘッダーフィールド」、RFC 5451、2009年4月。
[DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", RFC 4871, May 2007.
[DKIM] Allman、E.、Callas、J.、Delany、M.、Libbey、M.、Fenton、J。、およびM. Thomas、「DomainKeys Identified Mail（DKIM）Signatures」、RFC 4871、2007年5月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月。
[HASH-ATTACKS] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes in Internet Protocols", RFC 4270, November 2005.
[ハッシュ攻撃] Hoffman、P。およびB. Schneier、「インターネットプロトコルにおける暗号化ハッシュへの攻撃」、RFC 4270、2005年11月。
[IANA-CONSID] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[IANA-CONSID] Narten、T。およびH. Alvestrand、「RFCでIANAに関する考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
This section presents an example of the use of this new item header field to indicate unambiguous authentication results.
このセクションでは、この新しい項目ヘッダーフィールドを使用して、明確な認証結果を示す例を示します。
A message that had two DKIM signatures applied by the same domain, one of which failed:
同じドメインによって2つのDKIM署名が適用されたメッセージの1つが失敗しました：
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
例1：最初の署名時に追加された複数の署名からのヘッダーフィールドレポート結果
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.
ここでは、作成者の管理ドメイン（ADMD）によって2回署名されたメッセージの例を示します。 1つの署名は「リラックスした」ヘッダー正規化を使用し、もう1つの署名は「単純な」ヘッダー正規化を使用しました。どちらも「単純な」ボディの正規化を使用しました。
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.
おそらく、2つのシグネチャでカバーされた5つのヘッダーフィールドの1つが変更されたため、前者のシグネチャはパスしましたが、後者のシグネチャは検証に失敗しました。特に、[DKIM]の「緩和された」ヘッダー正規化はヘッダー内の空白の変更に対して耐性がありますが、「シンプル」はそうではなく、後者はこの例で失敗したものです。
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.
このメモによって登録されたアイテムにより、評価モジュールは、どのDKIM結果がどの署名に対応するかを決定できます。結果の "header.b"部分がないと、どちらが成功し、どれが失敗したかは不明です。
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.
著者は、この提案に対するレビューと建設的な批評のために、Dave Crocker、Tony Hansen、Eliot Lear、S。Moonesamy、およびAlessandro Veselyを認めたいと思います。
Author's Address
著者のアドレス
Murray S. Kucherawy Cloudmark, Inc. 128 King St., 2nd Floor San Francisco, CA 94107 US
Murray S. Kucherawy Cloudmark、Inc.128 King St.、2nd Floor San Francisco、CA 94107 US
Phone: +1 415 946 3800
EMail: msk@cloudmark.com