[要約] 要約：RFC 6273は、Secure Neighbor Discovery（SEND）ハッシュの脅威分析に関するものであり、IPv6ネットワークにおけるセキュリティの問題を調査しています。目的：このRFCの目的は、SENDプロトコルのセキュリティ上の脆弱性を特定し、それに対する対策を提案することです。

Internet Engineering Task Force (IETF)                          A. Kukec
Request for Comments: 6273                          University of Zagreb
Category: Informational                                      S. Krishnan
ISSN: 2070-1721                                                 Ericsson
                                                                S. Jiang
                                            Huawei Technologies Co., Ltd
                                                               June 2011

The Secure Neighbor Discovery (SEND) Hash Threat Analysis

安全な隣人ディスカバリー（送信）ハッシュ脅威分析

Abstract

概要

This document analyzes the use of hashes in Secure Neighbor Discovery (SEND), the possible threats to these hashes and the impact of recent attacks on hash functions used by SEND. The SEND specification currently uses the SHA-1 hash algorithm and PKIX certificates and does not provide support for hash algorithm agility. This document provides an analysis of possible threats to the hash algorithms used in SEND.

この文書は、安全な近隣発見（送信）でのハッシュの使用、これらのハッシュに対する脅威の可能性、および送信者が使用したハッシュ機能に対する最近の攻撃の影響を分析します。送信仕様は現在、SHA-1ハッシュアルゴリズムとPKIX証明書を使用しており、ハッシュアルゴリズムの俊敏性をサポートしていません。このドキュメントは、送信で使用されるハッシュアルゴリズムに対する脅威の可能性の分析を提供します。

Status of This Memo

本文書の位置付け

This document is not an Internet Standards Track specification; it is published for informational purposes.

このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。

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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。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/rfc6273.

このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6273で取得できます。

Copyright Notice

著作権表示

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

Copyright（c）2011 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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。

Table of Contents

目次 

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
   2.  Impact of Collision Attacks on SEND . . . . . . . . . . . . . . 3
     2.1.  Attacks against CGAs Used in SEND . . . . . . . . . . . . . 3
     2.2.  Attacks against PKIX Certificates in Authorization
           Delegation Discovery Process  . . . . . . . . . . . . . . . 3
     2.3.  Attacks against the Digital Signature in the SEND RSA
           Signature Option  . . . . . . . . . . . . . . . . . . . . . 4
     2.4.  Attacks against the Key Hash Field of the SEND RSA
           Signature Option  . . . . . . . . . . . . . . . . . . . . . 4
   3.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 5
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
     6.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
     6.2.  Informative References  . . . . . . . . . . . . . . . . . . 5
1. Introduction
1. はじめに

SEND [RFC3971] uses the SHA-1 hash algorithm [SHA1] to generate the contents of the Key Hash field and the Digital Signature field of the RSA Signature option. It also indirectly uses a hash algorithm (SHA-1, MD5, etc.) in the PKIX certificates [RFC5280] used for router authorization in the Authorization Delegation Discovery (ADD) process. Recently there have been demonstrated attacks against the collision free property of such hash functions [SHA1-COLL] and attacks on the PKIX X.509 certificates that use the MD5 hash algorithm [X509-COLL]. The document analyzes the impacts of these attacks on SEND and it recommends mechanisms to make SEND resistant to such attacks.

Send [RFC3971]は、SHA-1ハッシュアルゴリズム[SHA1]を使用して、キーハッシュフィールドの内容とRSA署名オプションのデジタル署名フィールドを生成します。また、承認委任ディスカバリー（ADD）プロセスでルーター認証に使用されるPKIX証明書[RFC5280]で、ハッシュアルゴリズム（SHA-1、MD5など）を間接的に使用します。最近、このようなハッシュ関数[SHA1-COLL]の衝突自由特性に対する攻撃と、MD5ハッシュアルゴリズム[X509-COLL]を使用するPKIX X.509証明書に対する攻撃が実証されています。ドキュメントは、これらの攻撃が送信に与える影響を分析し、そのような攻撃に耐性を送るメカニズムを推奨しています。

2. Impact of Collision Attacks on SEND
2. 送信に対する衝突攻撃の影響

[RFC4270] summarizes a study that assesses the threat of the aforementioned attacks on the use of cryptographic hashes in Internet protocols. This document analyzes the hash usage in SEND following the approach recommended by [RFC4270] and [NEW-HASHES].

[RFC4270]は、インターネットプロトコルでの暗号化ハッシュの使用に関する前述の攻撃の脅威を評価する研究をまとめたものです。このドキュメントは、[RFC4270]および[新しいハッシュ]によって推奨されるアプローチに従って、送信のハッシュ使用量を分析します。

The following sections discuss the various aspects of hash usage in SEND and determine whether they are affected by the attacks on the underlying hash functions.

次のセクションでは、送信におけるハッシュ使用のさまざまな側面について説明し、基礎となるハッシュ関数の攻撃によって影響を受けるかどうかを判断します。

2.1. Attacks against CGAs Used in SEND
2.1. 送信で使用されるCGAに対する攻撃

Cryptographically Generated Addresses (CGAs) are defined in [RFC3972] and are used to securely associate a cryptographic public key with an IPv6 address in the SEND protocol. Impacts of collision attacks on current uses of CGAs are analyzed in [RFC4982]. The basic idea behind collision attacks, as described in Section 4 of [RFC4270], is on the non-repudiation feature of hash algorithms. However, CGAs do not provide non-repudiation features. Therefore, as [RFC4982] points out CGA-based protocols, including SEND, are not affected by collision attacks on hash functions. If pre-image attacks were to become feasible, an attacker can find new CGA Parameters that can generate the same CGA as the victim. This class of attacks could be potentially dangerous since the security of SEND messages relies on the strength of the CGA.

暗号化されたアドレス（CGA）は[RFC3972]で定義されており、暗号化プロトコルの暗号化された公開キーをIPv6アドレスに安全に関連付けるために使用されます。CGAの現在の使用に対する衝突攻撃の影響は、[RFC4982]で分析されています。[RFC4270]のセクション4で説明されているように、衝突攻撃の背後にある基本的なアイデアは、ハッシュアルゴリズムの非和解機能に関するものです。ただし、CGAは非和解機能を提供しません。したがって、[RFC4982]を指摘しているように、送信を含むCGAベースのプロトコルは、ハッシュ機能に対する衝突攻撃の影響を受けません。イメージ前の攻撃が実現可能になった場合、攻撃者は被害者と同じCGAを生成できる新しいCGAパラメーターを見つけることができます。送信メッセージのセキュリティはCGAの強さに依存しているため、このクラスの攻撃は潜在的に危険です。

2.2. Attacks against PKIX Certificates in Authorization Delegation Discovery Process
2.2. 承認委任の発見プロセスにおけるPKIX証明書に対する攻撃

To protect Router Discovery, SEND requires that routers be authorized to act as routers. Routers are authorized by provisioning them with certificates from a trust anchor, and the hosts are configured with the trust anchor(s) used to authorize routers. Researchers demonstrated attacks against PKIX certificates with MD5 signatures in 2005 [NEW-HASHES], in 2007 [X509-COLL] [STEV2007] [SLdeW2007], and in 2009 [SSALMOdeW2009] [SLdeW2009]. An attacker can take advantage of these vulnerabilities to obtain a certificate with a different identity and use the certificate to impersonate a router. For this attack to succeed, the attacker needs to predict the content of all fields (some of them are human-readable) appearing before the public key, including the serial number and validity periods. Even though a relying party cannot verify the content of these fields, the CA can identify the forged certificate, if necessary.

ルーターの発見を保護するために、送信ではルーターがルーターとして機能することを許可する必要があります。ルーターは、トラストアンカーからの証明書をプロビジョニングすることにより承認され、ホストはルーターの承認に使用されるトラストアンカーで構成されます。研究者は、2005年[New-hashes]、2007年[X509-COLL] [STEV2007] [SLDEW2007]、および2009年[SSALMODEW2009] [SLDEW2009]のMD5署名によるPKIX証明書に対する攻撃を実証しました。攻撃者は、これらの脆弱性を利用して、異なる身元を持つ証明書を取得し、証明書を使用してルーターになりすまします。この攻撃を成功させるには、攻撃者は、シリアル番号や妥当性期間を含む公開鍵の前に現れるすべてのフィールドの内容（それらの一部は人間が読み取り可能です）を予測する必要があります。頼っている当事者はこれらのフィールドのコンテンツを検証することはできませんが、CAは必要に応じて偽造証明書を識別できます。

2.3. Attacks against the Digital Signature in the SEND RSA Signature Option
2.3. 送信RSA署名オプションのデジタル署名に対する攻撃

The digital signature in the RSA Signature option is produced by signing, with the sender's private key, the SHA-1 hash over certain fields in the Neighbor Discovery message as described in Section 5.2 of [RFC3971]. It is possible for an attacker to come up with two different Neighbor Discovery messages m and m' that result in the same value in the Digital Signature field. Since the structure of the Neighbor Discovery messages is well defined, it is not practical to use this vulnerability in real world attacks.

RSA署名オプションのデジタル署名は、[RFC3971]のセクション5.2で説明されているように、SHA-1ハッシュであるNeighbor DiscoveryメッセージのSHA-1ハッシュであるSHA-1ハッシュとともに、署名によって作成されます。攻撃者が2つの異なるネイバーディスカバリーメッセージmとm 'を思いつく可能性があり、デジタル署名フィールドで同じ値になります。近隣発見メッセージの構造は明確に定義されているため、この脆弱性を現実世界の攻撃で使用することは実用的ではありません。

2.4. Attacks against the Key Hash Field of the SEND RSA Signature Option
2.4. 送信RSA署名オプションのキーハッシュフィールドに対する攻撃

The SEND RSA signature option described in Section 5.2 of [RFC3971] defines a Key Hash field. This field contains a SHA-1 hash of the public key that was used to generate the CGA. To use a collision attack on this field, the attacker needs to come up with another public key (k') that produces the same hash as the real key (k). But the real key (k) is already authorized through a parallel mechanism (either CGAs or router certificates). Hence, collision attacks are not possible on the Key Hash field. Pre-image attacks on the Key Hash field are not useful for the same reason (any other key that hashes into the same Key Hash value will be detected due to a mismatch with the CGA or the router certificate).

[RFC3971]のセクション5.2で説明されている送信RSA署名オプションは、キーハッシュフィールドを定義します。このフィールドには、CGAを生成するために使用された公開キーのSHA-1ハッシュが含まれています。このフィールドに衝突攻撃を使用するには、攻撃者は、実際のキー（k）と同じハッシュを生成する別の公開キー（k '）を考え出す必要があります。しかし、実際のキー（k）は、並列メカニズム（CGAまたはルーター証明書のいずれか）を通じて既に承認されています。したがって、主要なハッシュフィールドでは衝突攻撃は不可能です。キーハッシュフィールドに対する画像前の攻撃は、同じ理由で有用ではありません（CGAまたはルーター証明書の不一致により、同じキーハッシュ値にハッシュする他のキーが検出されます）。

3. Conclusion
3. 結論

Current attacks on hash functions do not constitute any practical threat to the digital signatures used in SEND (both in the RSA signature option and in the X.509 certificates). Attacks on CGAs, as described in [RFC4982], will compromise the security of SEND and they need to be addressed by encoding the hash algorithm information into the CGA as specified in [RFC4982].

ハッシュ関数に対する現在の攻撃は、送信で使用されるデジタル署名に対する実際的な脅威を構成するものではありません（RSA署名オプションとX.509証明書の両方）。[RFC4982]に記載されているように、CGAへの攻撃は送信のセキュリティを損なうため、[RFC4982]で指定されているように、ハッシュアルゴリズム情報をCGAにエンコードすることで対処する必要があります。

4. Security Considerations
4. セキュリティに関する考慮事項

This document analyzes the impact that the attacks against hash functions have on SEND. It concludes that the only practical attack on SEND stems from a successful attack on an underlying CGA. It does not add any new vulnerabilities to SEND.

このドキュメントは、ハッシュ関数に対する攻撃が送信に与える影響を分析します。それは、基礎となるCGAへの成功した攻撃による送信ステムに対する唯一の実用的な攻撃は、結論付けています。送信する新しい脆弱性は追加されません。

5. Acknowledgements
5. 謝辞

The authors would like to thank Lars Eggert, Pete McCann, Julien Laganier, Jari Arkko, Paul Hoffman, Pasi Eronen, Adrian Farrel, Dan Romascanu, Tim Polk, Richard Woundy, Marcelo Bagnulo, and Barry Leiba for reviewing earlier versions of this document and providing comments to make it better.

著者は、ラース・エガート、ピート・マッキャン、ジュリアン・ラガニエ、ジャリ・アークコ、ポール・ホフマン、パシ・エロネン、エイドリアン・ファレル、ダン・ロマスカヌ、ティム・ポーク、リチャード・ウッキング、マルセロ・バグヌロ、バリー・ライバに感謝します。それを改善するためにコメントを提供します。

6. References
6. 参考文献
6.1. Normative References
6.1. 引用文献

[NEW-HASHES] Bellovin, S. and E. Rescorla, "Deploying a New Hash Algorithm", November 2005.

[New-Hashes] Bellovin、S。およびE. Rescorla、「新しいハッシュアルゴリズムの展開」、2005年11月。

[RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes in Internet Protocols", RFC 4270, November 2005.

[RFC4270] Hoffman、P。およびB. Schneier、「インターネットプロトコルにおける暗号化ハッシュへの攻撃」、RFC 4270、2005年11月。

[RFC4982] Bagnulo, M. and J. Arkko, "Support for Multiple Hash Algorithms in Cryptographically Generated Addresses (CGAs)", RFC 4982, July 2007.

[RFC4982] Bagnulo、M。およびJ. Arkko、「暗号化されたアドレス（CGA）の複数のハッシュアルゴリズムのサポート」、RFC 4982、2007年7月。

6.2. Informative References
6.2. 参考引用

[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.

[RFC3971] Arkko、J.、Ed。、Kempf、J.、Zill、B。、およびP. Nikander、「Secure Neighbor Discovery（Send）」、RFC 3971、2005年3月。

[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.

[RFC3972]オーラ、T。、「暗号化されたアドレス（CGA）」、RFC 3972、2005年3月。

[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.

[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、およびW. Polk、 "Internet X.509公開キーインフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル"、RFC 5280、2008年5月。

[SHA1] NIST, FIPS PUB 180-1, "Secure Hash Standard", April 1995.

[Sha1] Nist、Fips Pub 180-1、「Secure Hash Standard」、1995年4月。

[SHA1-COLL] Wang, X., Yin, L., and H. Yu, "Finding Collisions in the Full SHA-1. CRYPTO 2005: 17-36", 2005.

[Sha1-Coll] Wang、X.、Yin、L。、およびH. Yu、「Full Sha-1。Crypto2005：17-36で衝突を発見」、2005。

[SLdeW2007] Stevens, M., Lenstra, A., de Weger, B., "Chosen-prefix Collisions for MD5 and Colliding X.509 Certificates for Different Identities". EuroCrypt 2007.

[SLDEW2007] Stevens、M.、Lenstra、A.、De Weger、B。、「MD5のCosen-Prefix衝突、およびX.509の異なるアイデンティティの衝突X.509証明書」。EuroCrypt 2007。

[SLdeW2009] Stevens, M., Lenstra, A., de Weger, B., "Chosen-prefix Collisions for MD5 and Applications, Journal of Cryptology", 2009, <http://deweger.xs4all.nl/ papers/%5B42%5DStLedW-MD5-JCryp%5B2009%5D.pdf>.

[SLDEW2009] Stevens、M.、Lenstra、A.、De Weger、B。、「Md5およびApplicationsのChosen-Prefix衝突、Journal of Cryptology」、2009、<http://deweger.xs4all.nl/ Papers/％5B42％5DSTLEDW-MD5-JCRYP％5B2009％5D.PDF>。

[SSALMOdeW2009] Stevens, M., Sotirov, A., Appelbaum, J., Lenstra, A., Molnar, D., Osvik, D., and B. de Weger., "Short chosen-prefix collisions for MD5 and the creation of a rogue CA certificate, Crypto 2009", 2009.

[SSALMODEW2009] Stevens、M.、Sotirov、A.、Appelbaum、J.、Lenstra、A.、Molnar、D.、Osvik、D.、およびB. De Weger。、 "MD5およびThe The Short Chosen-Prefix衝突衝突Rogue Ca証明書の作成、Crypto 2009 "、2009年。

[STEV2007] Stevens, M., "On Collisions for MD5", <http://www.win.tue.nl/hashclash/ On%20Collisions%20for%20MD5%20-%20M.M.J.%20Stevens.pdf>.

[Stev2007] Stevens、M。、「Md5の衝突について」、<http://www.win.tue.nl/hashclash/

[X509-COLL] Stevens, M., Lenstra, A., and B. Weger, "Chosen-Prefix Collisions for MD5 and Colliding X.509 Certificates for Different Identities. EUROCRYPT 2007: 1-22", 2007.

[X509-Coll] Stevens、M.、Lenstra、A。、およびB. Weger、「MD5の選択された衝突およびさまざまなアイデンティティの衝突X.509証明書。Eurocrypt2007：1-22 "、2007。

Authors' Addresses

著者のアドレス

Ana Kukec University of Zagreb Unska 3 Zagreb Croatia

アナ・クケックザグレブ大学UNSKA 3ザグレブクロアチア 

   EMail: ana.kukec@fer.hr

Suresh Krishnan Ericsson 8400 Decarie Blvd. Town of Mount Royal, QC Canada

Suresh Krishnan Ericsson 8400 Decarie Blvd.QCカナダのマウントロイヤルの町 

   EMail: suresh.krishnan@ericsson.com

Sheng Jiang Huawei Technologies Co., Ltd Huawei Building, No.3 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District, Beijing P.R. China

Sheng Jiang Huawei Technologies Co.、Ltd Huawei Building、No.3 Xinxi Rd。、Shang-Di Information Industry Base、Hai-Dian District、Beijing P.R. China 

   EMail: jiangsheng@huawei.com