Network Working Group P. Hoffman
Request for Comments: 4894 VPN Consortium
Category: Informational May 2007
Use of Hash Algorithms in Internet Key Exchange (IKE) and IPsec
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
Abstract
抽象
This document describes how the IKEv1 (Internet Key Exchange version 1), IKEv2, and IPsec protocols use hash functions, and explains the level of vulnerability of these protocols to the reduced collision resistance of the MD5 and SHA-1 hash algorithms.
この文書は、IKEv1の（インターネット鍵交換バージョン1）、IKEv2の、およびIPsecプロトコルは、ハッシュ関数を使用して、MD5とSHA-1ハッシュアルゴリズムの削減衝突耐性にこれらのプロトコルの脆弱性のレベルを説明する方法を説明します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Hashes in IKEv1 and IKEv2 . . . . . . . . . . . . . . . . . . 2
3. Hashes in IPsec . . . . . . . . . . . . . . . . . . . . . . . 3
4. PKIX Certificates in IKEv1 and IKEv2 . . . . . . . . . . . . . 3
5. Choosing Cryptographic Functions . . . . . . . . . . . . . . . 3
5.1. Different Cryptographic Functions . . . . . . . . . . . . 4
5.2. Specifying Cryptographic Functions in the Protocol . . . . 4
5.3. Specifying Cryptographic Functions in Authentication . . . 5
6. Suggested Changes . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Suggested Changes for the Protocols . . . . . . . . . . . 6
6.2. Suggested Changes for Implementors . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. Informative References . . . . . . . . . . . . . . . . . . . . 8
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 10
Recently, attacks on the collision-resistance properties of MD5 and SHA-1 hash functions have been discovered; [HashAttacks] summarizes the discoveries. The security community is now reexamining how various Internet protocols use hash functions. The goal of this reexamination is to be sure that the current usage is safe in the face of these new attacks, and whether protocols can easily use new hash functions when they become recommended.
最近では、MD5とSHA-1ハッシュ関数の衝突抵抗特性に対する攻撃が発見されています。 [HashAttacks]の発見をまとめました。セキュリティコミュニティは現在、さまざまなインターネット・プロトコルは、ハッシュ関数を使用する方法を見直しています。この見直しの目標は、現在の使用量がこれらの新しい攻撃の顔に安全であること、そして彼らが推奨になったときのプロトコルは簡単に新しいハッシュ関数を使用できるかどうかを確認することです。
Different protocols use hash functions quite differently. Because of this, the IETF has asked for reviews of all protocols that use hash functions. This document reviews the many ways that three protocols (IKEv1 [IKEv1], IKEv2 [IKEv2], and IPsec [ESP] and [AH]) use hash functions.
異なるプロトコルは全く異なるハッシュ関数を使用します。このため、IETFは、ハッシュ関数を使用するすべてのプロトコルのレビューを求めています。この文書では、3つのプロトコル（IKEv1の[IKEv1の]、のIKEv2 [IKEv2の]、およびIPsec [ESP]と[AH]）は、ハッシュ関数を使用する多くの方法を検討します。
In this document, "IKEv1" refers to only "Phase 1" of IKEv1 and the agreement process. "IKEv2" refers to the IKE_SA_INIT and IKE_AUTH exchanges. "IPsec" refers to IP encapsulated in either the Authentication Header (AH) or Encapsulating Security Payload (ESP).
この文書では、「IKEv1のは、」のみのIKEv1の「フェーズ1」と合意のプロセスを意味します。 「IKEv2の」は、IKE_SA_INIT及びIKE_AUTH交換を指します。 「IPsecは、」認証ヘッダー（AH）またはカプセル化セキュリティペイロード（ESP）のいずれかでカプセル化されたIPを指します。
Both IKEv1 and IKEv2 can use hash functions as pseudo-random functions (PRFs). The inputs to the PRFs always contain nonce values from both the initiator and the responder that the other party cannot predict in advance. In IKEv1, the length of this nonce is at least 64 bits; in IKEv2, it is at least 128 bits. Because of this, the use of hash functions in IKEv1 and IKEv2 are not susceptible to any known collision-reduction attack.
IKEv1とIKEv2の両方は、擬似ランダム関数（のPRF）としてハッシュ関数を使用することができます。 PRFへの入力は、常に相手が事前に予測できないことを、イニシエータとレスポンダーの両方からのナンス値が含まれています。 IKEv1のでは、このナンスの長さは、少なくとも64ビットです。 IKEv2の中には、少なくとも128ビットです。このため、IKEv1のとIKEv2の中にハッシュ関数を使用すると、任意の既知の衝突軽減攻撃を受けません。
IKEv1 also uses hash functions on the inputs to the PRF. The inputs are a combination of values from both the initiator and responder, and thus the hash function here is not susceptible to any known collision-reduction attack.
IKEv1のもPRFへの入力にハッシュ関数を使用しています。入力は、イニシエータとレスポンダーの双方からの値の組み合わせであるため、ここでは、ハッシュ関数は、任意の既知の衝突軽減攻撃を受けにくいです。
In IKEv2, hashes are used as integrity protection for all messages after the IKE_SA_INIT Exchange. These hashes are used in Hashed Message Authentication Codes (HMACs). As described in [HMAC-reduction], MD5 used in HMACs is susceptible to forgery, and it is suspected that full SHA-1 used in HMAC is susceptible to forgery. There is no known reason for the person who creates legitimate integrity protection to want to spoof it.
IKEv2のでは、ハッシュはIKE_SA_INIT交換後すべてのメッセージの完全性保護として使用されています。これらのハッシュがハッシュ・メッセージ認証コード（HMACs）で使用されています。 [HMAC-還元]に記載されているように、HMACsに使用MD5は、偽造に対して感受性であり、完全SHA-1 HMACで使用されるが、偽造に対して感受性であることが疑われます。それを偽装したい合法的な完全性保護を作成した人には知られている理由はありません。
Both IKEv1 and IKEv2 have authentication modes that use digital signatures. Digital signatures use hashes to make unique digests of the message being signed. With the current known attacks, the only party that can create the two messages that collide is the IKE entity that generates the message. As shown in [Target-collisions], an attacker can create two different Public Key Infrastructure using X.509 (PKIX) certificates with different identities that have the same signatures.
IKEv1のとIKEv2の両方がデジタル署名を使用する認証モードを持っています。デジタル署名は、署名されたメッセージのユニークなダイジェストを作成するためにハッシュを使用します。現在の既知の攻撃では、衝突する2つのメッセージを作成することができる唯一の政党は、メッセージを生成IKEエンティティです。 [ターゲットコリジョン]に示すように、攻撃者は、同じシグネチャを有する異なるアイデンティティとX.509（PKIX）証明書を使用して、2つの異なる公開鍵インフラストラクチャを作成することができます。
IKEv1 has two modes, "public key encryption" and "revised public key encryption", that use hashes to identify the public key used. The hash function here is used simply to reduce the size of the identifier. In IKEv2 with public-key certificates, a hash function is used for similar purposes, both for identifying the sender's public key and the trust anchors. Using a collision-reduction attack, an individual could create two public keys that have the same hash value. This is not considered to be a useful attack because the key generator holds both private keys.
IKEv1の2つのモード、「公開鍵暗号」と「改訂された公開鍵暗号」があり、その使用は、使用される公開鍵を識別するためにハッシュします。ここでハッシュ関数は、識別子のサイズを小さくするために単に使用されています。公開鍵証明書でのIKEv2では、ハッシュ関数は、同様の目的のために、両方の送信者の公開鍵と信頼アンカーを識別するために使用されます。衝突軽減攻撃を使用して、個人が同じハッシュ値を持つ2つの公開鍵を作成することができます。キージェネレータは両方の秘密鍵を保持しているので、これは便利な攻撃であるとは考えられません。
IKEv1 can be used together with Network Access Translator (NAT) traversal support, as described in [NAT-T]; IKEv2 includes this NAT traversal support. In both of these cases, hash functions are used to obscure the IP addresses used by the initiator and/or the responder. The hash function here is not susceptible to any known collision-reduction attack.
[NAT-T]で説明されるようにIKEv1のは、ネットワーク・アクセス・トランスレータ（NAT）トラバーサルサポートと一緒に使用することができます。 IKEv2のは、このNATトラバーサルのサポートが含まれています。これらの場合の両方において、ハッシュ関数は、開始剤及び/又は応答者によって使用されるIPアドレスを不明瞭にするために使用されます。ここでは、ハッシュ関数は、任意の既知の衝突軽減攻撃を受けやすいではありません。
AH uses hash functions for authenticating packets; the same is true for ESP when ESP is using its own authentication. For both uses of IPsec, hash functions are always used in hashed MACs (HMACs). As described in [HMAC-reduction], MD5 used in HMACs is susceptible to forgery, and it is suspected that full SHA-1 used in HMAC is susceptible to forgery. There is no known reason for the person who creates legitimate packet authentication to want to spoof it.
AHは、パケットを認証するため、ハッシュ関数を使用しています。同じことは、ESPが独自の認証を使用しているESPのために真です。 IPsecの両方の用途のために、ハッシュ関数は、常に、ハッシュのMAC（HMACs）で使用されています。 [HMAC-還元]に記載されているように、HMACsに使用MD5は、偽造に対して感受性であり、完全SHA-1 HMACで使用されるが、偽造に対して感受性であることが疑われます。それを偽装したい正当なパケット認証を作成した人には知られている理由はありません。
Some implementations of IKEv1 and IKEv2 use PKIX certificates for authentication. Any weaknesses in PKIX certificates due to particular ways hash functions are used, or due to weaknesses in particular hash functions used in certificates, will be inherited in IKEv1 and IKEv2 implementations that use PKIX-based authentication.
IKEv1のとIKEv2の一部の実装では、認証のためのPKIX証明書を使用しています。ハッシュ関数が使用される特定の方法に、またはによる証明書で使用される特定のハッシュ関数の弱点にPKIX証明書の任意の弱点は、PKIXベースの認証を使用するのIKEv1とIKEv2の実装に継承されます。
Recently, there has been more discussion in the IETF about the ability of one party in a protocol to tell the other party which cryptographic functions the first party prefers the second party to use. The discussion was spurred in part by [Deploying]. Although that paper focuses on hash functions, it is relevant to other cryptographic functions as well.
最近では、最初の当事者は第二者が使用することを好む暗号機能を相手に伝えるためのプロトコルでは一方の当事者の能力についてIETFでの多くの議論がありました。議論は[展開]によって部分的に拍車をかけました。その紙は、ハッシュ関数に焦点を当てているが、それは同様に他の暗号機能に関連しています。
There are (at least) three distinct subtopics related to choosing cryptographic functions in protocols:
プロトコルに暗号化機能を選択することに関連した（少なくとも）3つの異なるサブトピックがあります。
o The ability to pick between different cryptographic functions instead of having just one specified in the protocol
代わりに、ただ一つのプロトコルで指定有する異なる暗号機能の間で選択する能力O
o If there are multiple functions, the ability to agree on which function will be used in the main protocol
複数の機能がある場合はO、どの機能に合意する能力は、メインプロトコルで使用されます
o The ability to suggest to the other party which kinds of cryptographic functions should be used in the other party's public key certificates
暗号機能の種類は、相手の公開鍵証明書で使用されるべき相手に提案する機能O
Protocols that use cryptographic functions can either specify a single function, or can allow different functions. Protocols in the first category are susceptible to attack if the specified function is later found to be too weak for the stated purpose; protocols in the second category can usually avoid such attacks, but at a cost of increased protocol complexity. In the IETF, protocols that allow a choice of cryptographic functions are strongly preferred.
暗号化機能を使用するプロトコルは、単一の関数を指定するか、または異なる機能を可能にすることができます。最初のカテゴリでプロトコルが指定された関数は、後に述べられた目的のためにあまりにも弱いことが発見された場合、攻撃を受けやすいです。第二のカテゴリー内のプロトコルは、通常、このような攻撃を避けるが、増加したプロトコルの複雑さを犠牲にすることができます。 IETFでは、暗号化機能の選択を許可するプロトコルが強く好まれます。
IKEv1, IKEv2, and IPsec already allow different hash functions in every significant place where hash functions are used (that is, in every place that has any susceptibility to a collision-reduction attack).
IKEv1の、IKEv2の、およびIPsecは、すでに（つまり、衝突軽減攻撃への感受性を持っているすべての場所で、ある）ハッシュ関数が使用されているすべての重要な場所で異なるハッシュ関数を可能にします。
Protocols that allow a choice of cryptographic functions need to have a way for all parties to agree on which function is going to be used. Some protocols, such as secure electronic mail, allow the initiator to simply pick a set of cryptographic functions; if the responder does not understand the functions used, the transmission fails. Other protocols allow for the two parties to agree on which cryptographic functions will be used. This is sometimes called "negotiation", but the term "negotiation" is inappropriate for protocols in which one party (the "proposer") lists all the functions it is willing to use, and the other party (the "chooser") simply picks the ones that will be used.
暗号化機能の選択を許可するプロトコルは、すべての当事者が使用されようとしているどの機能に同意するための方法を持っている必要があります。安全な電子メールなど一部のプロトコルは、イニシエータは、単に暗号化機能のセットを選択することができます。応答者が使用する機能を理解していない場合は、送信が失敗します。両当事者は、暗号機能が使用されるに同意するために他のプロトコルを許可します。これは、「交渉」と呼ばれるが、用語「交渉は」一方の当事者（「提案者」）は、すべての使用して喜んで機能、およびその他の当事者（「チュー」）、単にピックを一覧表示しているプロトコルには不適切です使用されるもの。
When a new cryptographic function is introduced, one party may want to tell the other party that they can use the new function. If it is the proposer who wants to use the new function, the situation is easy: the proposer simply adds the new function to its list, possibly removing other parallel functions that the proposer no longer wants to use.
新しい暗号化機能が導入されている場合、一方の当事者は、彼らが新しい機能を使用することができ、相手に伝えたいことがあります。それは新しい関数を使用したい提案者であれば、状況は簡単です：提案者は、単に、おそらく提案者は、もはや使用することを望んでいる他のパラレル機能を削除する、そのリストに新しい機能が追加されます。
On the other hand, if it is the chooser who wants to use the new function and the proposer didn't list it, the chooser may want to signal the proposer that they are capable of using the new function or the chooser may want to say that it is only willing to use the new function. If a protocol wants to handle either of these cases, it has to have a way for the chooser to specify this information to the proposer in its acceptance and/or rejection message.
それは新しい関数を使用したいチューで、提案者は、それをリストアップしていない場合一方、チューは、彼らが言いたいことがあり、新たな機能やチューを使用することができる提案を通知することもできます新しい関数を使用するだけで喜んでいます。プロトコルは、これらの例のいずれかを処理したい場合、それはその受諾および/または拒否メッセージで提案者にこの情報を指定するためのチューための方法を持っている必要があります。
It is not clear from a design standpoint how important it might be to let the chooser specify the additional functions it knows. As long as the proposer offers all the functions it wants to use, there is no reason for the chooser to say "I know one you don't know". The only place where the chooser is able to signal the proposer with different functions is in protocols where listing all the functions might be prohibitive, such as where they would add additional round trips or significant packet length.
それはチューはそれは知っている追加機能を指定できるようにするかもしれませんどのように重要な設計の観点から明らかではありません。限り、提案者はそれを使用したいすべての機能を提供していますように、「私はあなたが知らないものを知っている」と言うためにチューのための理由はありません。チューは異なる機能を持つ提案を通知することができます唯一の場所は、そのような彼らは、追加のラウンドトリップまたは重大なパケット長を追加する場所として、すべての機能が法外であるかもしれないリストのプロトコルです。
IKEv1 and IKEv2 allow the proposer to list all functions. Neither allows the chooser to specify which functions that were not proposed it could have used, either in a successful or unsuccessful Security Association (SA) establishment.
IKEv1とIKEv2のは、提案者は、すべての機能を一覧表示することができます。どちらも成功したか失敗したセキュリティアソシエーション（SA）の確立のいずれかで、それが使用されている可能性が提案されなかった機能を指定するためにチューすることができません。
Passing public key certificates and signatures used in authentication creates additional issues for protocols. When specifying cryptographic functions for a protocol, it is an agreement between the proposer and the chooser. When choosing cryptographic functions for public key certificates, however, the proposer and the chooser are beholden to functions used by the trusted third parties, the certification authorities (CAs). It doesn't really matter what either party wants the other party to use, since the other party is not the one issuing the certificates.
認証に使用する公開鍵証明書と署名を渡すと、プロトコルのための追加の問題を作成します。プロトコルの暗号化機能を指定する場合、それは提案者とセレクタとの間の契約です。公開鍵証明書の暗号化機能を選択すると、しかし、提案者とチューは、信頼できる第三者機関、証明機関（CA）によって使用される機能への恩義あります。本当に、他の当事者が証明書を発行するものではありませんので、いずれかの当事者が、相手方が使用することを望んでいるかは重要ではありません。
In this discussion, the term "certificate" does not necessarily mean a PKIX certificate. Instead, it means any message that binds an identity to a public key, where the message is signed by a trusted third party. This can be non-PKIX certificates or other types of cryptographic identity-binding structures that may be used in the future.
この議論では、用語「証明書」は、必ずしもPKIX証明書を意味するものではありません。代わりに、メッセージは、信頼できる第三者によって署名された公開鍵に身元を結合する任意のメッセージを意味します。これは、非PKIX証明書または将来的に使用できる暗号化身元結合構造の他の種類のことができます。
The question of specifying cryptographic functions is only relevant if one party has multiple certificates or signatures with different cryptographic functions. In this section, the terms "proposer" and "chooser" have a different meaning than in the previous section.
一方の当事者が異なる暗号化機能を持つ複数の証明書や署名を持っている場合は、暗号化機能を指定するという問題がのみ有効です。このセクションでは、用語「提案者」と「チュー」は、前のセクションでは異なる意味を持ちます。
Here, both parties act as proposers of the identity they want to use and the certificates with which they are backing up that identity, and both parties are choosers of the other party's identity and certificate.
ここでは、両当事者は、彼らが使用するアイデンティティの提案者と、彼らはそのアイデンティティをバックアップしているとの証明書として機能し、両当事者は、相手の身元と証明書のチューされています。
Some protocols allow the proposer to send multiple certificates or signatures, while other protocols only allow the proposer to send a single certificate or signature. Some protocols allow the proposer to send multiple certificates but advise against it, given that certificates can be fairly large (particularly when the CA loads the certificate with lots of information).
いくつかのプロトコルは他のプロトコルのみ提案が単一の証明書又は署名を送信することを可能にしながら、提案者は、複数の証明書又は署名を送信することを可能にします。一部のプロトコルは、証明書（CAが多くの情報を持つ証明書をロードする場合は特に）かなり大きくなる可能性があることを考えると、提案者が複数の証明書を送ったが、それに対して助言することができます。
IKEv1 and IKEv2 allow both parties to list all the certificates that they want to use. [PKI4IPsec] proposes to restrict this by saying that all the certificates for a proposer have to have the same identity.
IKEv1とIKEv2のは、両当事者は、彼らが使用するすべての証明書を一覧表示することができます。 [PKI4IPsec]発案者のためのすべての証明書が同じIDを持っている必要がありますと言って、これを制限することを提案しています。
In investigating how protocols use hash functions, the IETF is looking at (at least) two areas of possible changes to individual protocols: how the IETF might need to change the protocols, and how implementors of current protocols might change what they do. This section describes both of these areas with respect to IKEv1, IKEv2, and IPsec.
プロトコルは、ハッシュ関数を使用する方法調査では、IETFが見ている（少なくとも）個々のプロトコルへの可能な変更の二つの領域：IETFがプロトコルを変更する必要がありますどのように、どのように現在のプロトコルの実装者は、彼らが何をすべきか変更される場合があります。このセクションでは、のIKEv1、IKEv2の、およびIPsecに対するこれらの領域の両方を記載しています。
Protocols might need to be changed if they rely on the collision-resistance of particular hash functions. They might also need to be changed if they do not allow for the agreement of hash functions because it is expected that the "preferred" hash function for different users will change over time.
彼らは、特定のハッシュ関数の衝突抵抗に依存している場合のプロトコルを変更する必要があります。別のユーザーのための「好ましい」ハッシュ関数は、時間の経過とともに変化することが予想されるので、彼らはハッシュ関数の合意を許可しない場合、彼らはまた、変更する必要があります。
IKEv1 and IKEv2 already allow for the agreement of hash functions for both IKE and IPsec, and thus do not need any protocol change.
IKEv1とIKEv2のは、すでにIKEとIPsecの両方のためのハッシュ関数の契約を可能にし、従って任意のプロトコルの変更を必要としません。
IKEv1 and IKEv2, when used with public key authentication, already allow each party to send multiple PKIX certificates, and thus do not need any protocol change.
公開鍵認証で使用した場合のIKEv1とIKEv2のは、既に任意のプロトコルの変更を必要としないため、各当事者は、複数のPKIX証明書を送信することができ、そして。
There are known weaknesses in PKIX with respect to collision-resistance of some hash functions. Because of this, it is hoped that there will be changes to PKIX fostered by the PKIX Working Group. Some of the changes to PKIX may be usable in IKEv1 and IKEv2 without having to change IKEv1 and IKEv2. Other changes to PKIX may require changes to IKEv1 and IKEv2 in order to incorporate them, but that will not be known until the changes to PKIX are finalized.
いくつかのハッシュ関数の衝突耐性に関してPKIXで知られている弱点があります。このため、PKIXワーキンググループによって育まPKIXへの変更があることが期待されています。 PKIXへの変更のいくつかはのIKEv1とIKEv2のを変更することなくのIKEv1とIKEv2のに使用可能です。 PKIXへのその他の変更は、それらを組み込むためにIKEv1のとIKEv2のへの変更を必要とするかもしれないが、PKIXへの変更が確定されるまで、それは知られることはありません。
As described in earlier sections, IKE and IPsec themselves are not susceptible to any known collision-reduction attacks on hash functions. Thus, implementors do not need to make changes such as prohibiting the use of MD5 or SHA-1. The mandatory and suggested algorithms for IKEv2 and IPsec are given in [IKEv2Algs] and [IPsecAlgs].
以前のセクションで説明したように、IKEおよびIPsec自体はハッシュ関数の任意の既知の衝突軽減攻撃を受けません。したがって、実装者は、MD5やSHA-1の使用を禁止するなどの変更を加える必要はありません。 IKEv2およびIPsecのために必須と提案アルゴリズムは、[は、ipsecalgs] [IKEv2Algs]で与えられています。
Note that some IKE and IPsec users will misunderstand the relevance of the known attacks and want to use "stronger" hash functions. Thus, implementors should strongly consider adding support for alternatives, particularly the AES-XCBC-PRF-128 [AES-PRF] and AES-XCBC-MAC-96 [AES-MAC] algorithms, as well as forthcoming algorithms based on the SHA-2 family [SHA2-HMAC].
いくつかのIKEおよびIPsecのユーザーが既知の攻撃の関連性を誤解し、「強い」のハッシュ関数を使用する必要があることに注意してください。従って、実装が強くSHA-に基づいて代替、特にAES-XCBC-PRF-128 [AES-PRF]およびAES-XCBC-MAC-96 [AES-MAC】アルゴリズム、ならびに今後のアルゴリズムのサポートを追加することを検討すべきです2家族[SHA2-HMAC]。
Implementations of IKEv1 and IKEv2 that use PKIX certificates for authentication may be susceptible to attacks based on weaknesses in PKIX. It is widely expected that PKIX certificates in the future will use hash functions other than MD5 and SHA-1. Implementors of IKE that allow certificate authentication should strongly consider allowing the use of certificates that are signed with the SHA-256, SHA-384, and SHA-512 hash algorithms. Similarly, those implementors should also strongly consider allowing the sending of multiple certificates for identification.
認証のためのPKIX証明書を使用のIKEv1とIKEv2のの実装は、PKIXの弱点に基づく攻撃を受ける可能性があります。広く将来的にはPKIX証明書は、MD5とSHA-1以外のハッシュ関数を使用することが期待されます。証明書による認証を許可するIKEの実装者は強くSHA-256、SHA-384で署名された証明書、およびSHA-512ハッシュアルゴリズムの使用を可能に検討すべきです。同様に、これらの実装も強く識別のために複数の証明書を送信できるように検討すべきです。
This entire document is about the security implications of reduced collision-resistance of common hash algorithms for the IKE and IPsec protocols.
この文書全体ではIKEおよびIPsecプロトコルのための共通のハッシュアルゴリズムの削減衝突耐性のセキュリティへの影響についてです。
The Security Considerations section of [HashAttacks] gives much more detail about the security of hash functions.
[HashAttacks]のSecurity Considerations部は、ハッシュ関数の安全性について多くの詳細を提供します。
[AES-MAC] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec", RFC 3566, September 2003.
[AES-MAC]フランケル、S.およびH.ハーバート、 "AES-XCBC-MAC-96アルゴリズムとIPsecでの使用"、RFC 3566、2003年9月。
[AES-PRF] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE)", RFC 4434, February 2006.
[AES-PRF]ホフマン、P.、RFC 4434、2006年2月 "インターネット鍵交換プロトコル（IKE）のためのAES-XCBC-PRF-128アルゴリズム"。
[AH] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[AH]ケント、S.、 "IP認証ヘッダー"、RFC 4302、2005年12月。
[Deploying] Bellovin, S. and E. Rescorla, "Deploying a New Hash Algorithm", NDSS '06, February 2006.
[展開] Bellovin氏、S.およびE.レスコラ、 "新しいハッシュアルゴリズムを展開する"、NDSS '06、2006年2月。
[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[ESP]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4303、2005年12月。
[HashAttacks] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes in Internet Protocols", RFC 4270, November 2005.
[HashAttacks]ホフマン、P.とB.シュナイアー、 "インターネットプロトコルで暗号化ハッシュに対する攻撃"、RFC 4270、2005年11月。
[HMAC-reduction] Contini, S. and YL. Yin, "Forgery and Partial Key-Recovery Attacks on HMAC and NMAC Using Hash Collisions", Cryptology ePrint Report 2006/319, September 2006.
[HMAC-還元】Contini、S.及びYL。殷、「ハッシュ衝突を使用して偽造し、HMACとNMAC上の部分キー回復攻撃」、暗号学ePrintのレポート319分の2006、2006年9月。
[IKEv1] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[IKEv1の]ハーキンズ、D.とD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。
[IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[IKEv2の]カウフマン、C.、エド。、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、2005年12月。
[IKEv2Algs] Schiller, J., "Cryptographic Algorithms for use in the Internet Key Exchange Version 2", RFC 4307, December 2005.
[IKEv2Algs]シラー、J.、 "インターネット鍵交換バージョン2で使用する暗号化アルゴリズム"、RFC 4307、2005年12月。
[IPsecAlgs] Eastlake, D., "Cryptographic Algorithm Implementation Requirements For ESP And AH", RFC 4305, December 2005.
[詳細は、ipsecalgs]イーストレイク、D.、 "ESPとAHのための暗号アルゴリズム実装要件"、RFC 4305、2005年12月。
[NAT-T] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, "Negotiation of NAT-Traversal in the IKE", RFC 3947, January 2005.
[NAT-T] Kivinen、T.、Swander、B.、Huttunen、A.、およびV.ボルペ、 "IKEにおけるNATトラバーサルのネゴシエーション"、RFC 3947、2005年1月。
[PKI4IPsec] Korver, B., "The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX", Work in Progress, April 2007.
[PKI4IPsec]コーバー、B.、進歩、2007年4月にワーク "のIKEv1 / ISAKMP、IKEv2の、およびPKIXのインターネットIPセキュリティPKIプロファイル"。
[SHA2-HMAC] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 With IPsec", RFC 4868, May 2007.
"IPsecでHMAC-SHA-256を使用して、HMAC-SHA-384、およびHMAC-SHA-512" [SHA2-HMAC]ケリー、S.とS.フランケル、RFC 4868、2007年5月。
[Target-collisions] Stevens, M., Lenstra, A., and B. de Weger, "Target Collisions for MD5 and Colliding X.509 Certificates for Different Identities", Cryptology ePrint Report 2006/360, October 2006.
[ターゲット-衝突]スティーブンス、M.、Lenstra、A.、およびB.デWegerの、 "MD5のターゲットの衝突と異なるアイデンティティのためのX.509証明書を衝突"、暗号学ePrintのレポート360分の2006、2006年10月。
Appendix A. Acknowledgments
付録A.謝辞
Tero Kivinen helped with ideas in the first version of this document. Many participants on the SAAG and IPsec mailing lists contributed ideas in later versions. In particular, suggestions were made by Alfred Hoenes, Michael Richardson, Hugo Krawczyk, Steve Bellovin, David McGrew, Russ Housley, Arjen Lenstra, and Pasi Eronen.
TERO Kivinenは、このドキュメントの最初のバージョンでアイデアを手伝ってくれました。 SAAGとIPsecメーリングリスト上の多くの参加者がそれ以降のバージョンでアイデアを貢献しました。特に、提案はアルフレッドHoenes、マイケル・リチャードソン、ヒューゴKrawczyk、スティーブBellovin氏、デビッドマグリュー、ラスHousley、アリエン・レンストラ、およびパシEronenによって作られました。
Author's Address
著者のアドレス
Paul Hoffman VPN Consortium 127 Segre Place Santa Cruz, CA 95060 US
ポール・ホフマンVPNコンソーシアム127セグレ場所サンタクルス、CA 95060米国
EMail: paul.hoffman@vpnc.org
メールアドレス：paul.hoffman@vpnc.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。