[要約] RFC 4894は、IKEおよびIPsecでのハッシュアルゴリズムの使用に関するガイドラインを提供します。その目的は、セキュリティプロトコルで使用されるハッシュアルゴリズムの選択と設定に関するベストプラクティスを定義することです。
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
インターネットキーエクスチェンジ（IKE）および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）The IETF Trust（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への入力には、相手が事前に予測できないイニシエーターとレスポンダーの両方からのNonCE値が常に含まれています。IKEV1では、この非CEの長さは少なくとも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 Exchange後のすべてのメッセージの整合性保護としてハッシュが使用されます。これらのハッシュは、ハッシュされたメッセージ認証コード（HMACS）で使用されます。[HMAC-Reduction]で説明されているように、HMACSで使用されるMD5は偽造の影響を受けやすく、HMACで使用される完全なSHA-1は偽造の影響を受けやすいと疑われています。合法的な整合性保護を作成している人がそれを吹き込みたいと思う理由は知られていない。
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エンティティです。[Target-Collisions]に示されているように、攻撃者は、同じ署名を持つ異なるIDを持つ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つのモードがあり、ハッシュを使用して使用される公開キーを識別します。ここでのハッシュ関数は、単に識別子のサイズを減らすために使用されます。Public-Key証明書を使用した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.
IKEV1は、[NAT-T]で説明されているように、ネットワークアクセストランスレーター（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-Reduction]で説明されているように、HMACSで使用されるMD5は偽造の影響を受けやすく、HMACで使用される完全なSHA-1は偽造の影響を受けやすいと疑われています。合法的なパケット認証を作成している人が、それを吹き込みたいと思う理由は知られていません。
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証明書の弱点は、Hash関数を使用する特定の方法、または証明書で使用される特にハッシュ関数の弱点により、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では、第一党が第二党が使用することを好む暗号化関数が他方の当事者に伝えるプロトコルの一方の当事者の能力について、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 プロトコルで1つだけを指定する代わりに、異なる暗号機能を選択する機能
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.
暗号化関数を使用するプロトコルは、単一の関数を指定するか、異なる関数を許可することができます。最初のカテゴリのプロトコルは、指定された関数が後で規定されている目的には弱すぎることがわかった場合、攻撃の影響を受けやすくなります。2番目のカテゴリのプロトコルは、通常、そのような攻撃を回避できますが、プロトコルの複雑さが増加するコストで避けます。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.
暗号化関数の選択を可能にするプロトコルは、すべての関係者がどの関数を使用するかに同意する方法を持つ必要があります。安全な電子メールなどの一部のプロトコルにより、イニシエーターは単に一連の暗号化関数を選択できるようにします。レスポンダーが使用した関数を理解していない場合、送信は失敗します。他のプロトコルにより、2つの当事者がどの暗号化関数が使用されるかについて同意することができます。これは「交渉」と呼ばれることもありますが、「ネゴシエーション」という用語は、1つの当事者（「提案者」）が使用するすべての機能をリストし、もう一方の当事者（「Chooser」）が単に選択するプロトコルには不適切です。使用されるもの。
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.
認証で使用される公開キーの証明書と署名を通過すると、プロトコルに追加の問題が発生します。プロトコルの暗号化関数を指定する場合、それは提案者と選択者との間の合意です。ただし、公開キー証明書の暗号化関数を選択する場合、提案者と選択者は、信頼できる第三者である認定当局（CAS）が使用する機能に見られます。他の当事者が証明書を発行するものではないため、どちらの当事者が他の当事者を使用することを望んでいることは本当に問題ではありません。
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.
暗号化関数を指定するという問題は、1つの当事者が異なる暗号化関数を持つ複数の証明書または署名を持っている場合にのみ関連します。このセクションでは、「提案者」と「選択者」という用語は、前のセクションとは異なる意味を持っています。
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は（少なくとも）個々のプロトコルの可能性のある変更の2つの領域を検討しています。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の必須および提案されたアルゴリズムは、[IKEV2ALGS]および[IPSECALGS]に与えられます。
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ユーザーは、既知の攻撃の関連性を誤解し、「より強力な」ハッシュ関数を使用したいことに注意してください。したがって、実装者は、特にAES-XCBC-PRF-128 [AES-PRF]およびAES-XCBC-MAC-96 [AES-MAC]アルゴリズム、およびSHA-に基づく今後のアルゴリズムのサポートを追加することを強く検討する必要があります。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]のセキュリティに関する考慮事項セクションは、ハッシュ関数のセキュリティに関する詳細を示しています。
[AES-MAC] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec", RFC 3566, September 2003.
[AES-MAC] Frankel、S。およびH. Herbert、「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] Hoffman、P。、「インターネットキーエクスチェンジプロトコル（IKE）のAES-XCBC-PRF-128アルゴリズム」、RFC 4434、2006年2月。
[AH] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[AH] Kent、S。、「IP認証ヘッダー」、RFC 4302、2005年12月。
[Deploying] Bellovin, S. and E. Rescorla, "Deploying a New Hash Algorithm", NDSS '06, February 2006.
[展開] Bellovin、S。およびE. Rescorla、「新しいハッシュアルゴリズムの展開」、NDSS '06、2006年2月。
[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[ESP] Kent、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] Hoffman、P。and B. Schneier、「インターネットプロトコルにおける暗号化ハッシュへの攻撃」、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-Reduction] Contini、S。およびYL。Yin、「ハッシュ衝突を使用したHMACおよびNMACに対する偽造および部分的なキー回復攻撃」、Cryptology Eprint Report 2006/319、2006年9月。
[IKEv1] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[IKEV1] Harkins、D。およびD. Carrel、「The Internet Key Exchange（IKE）」、RFC 2409、1998年11月。
[IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[IKEV2] Kaufman、C.、ed。、「Internet Key Exchange（IKEV2）Protocol」、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] Eastlake、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. Volpe、「IKEにおけるNat-Traversalの交渉」、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] Korver、B。、「IKEV1/ISAKMP、IKEV2、およびPKIXのインターネットIPセキュリティPKIプロファイル」、2007年4月、進行中の作業。
[SHA2-HMAC] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 With IPsec", RFC 4868, May 2007.
[SHA2-HMAC] Kelly、S。およびS. Frankel、「HMAC-SHA-256、HMAC-SHA-384、およびHMAC-SHA-512を使用してIPSECを使用して」、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.
[ターゲットコリジション] Stevens、M.、Lenstra、A。、およびB. De Weger、「MD5のターゲット衝突およびさまざまなアイデンティティの衝突X.509証明書」、Cryptology Eprint Report 2006/360、2006年10月。
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メーリングリストの多くの参加者は、後のバージョンでアイデアを提供しました。特に、アルフレッド・ホーネス、マイケル・リチャードソン、ヒューゴ・クローチク、スティーブ・ベロヴィン、デビッド・マクグリュー、ラス・ハウスリー、アルジェン・レンストラ、パシ・エロネンが提案を行った。
Author's Address
著者の連絡先
Paul Hoffman VPN Consortium 127 Segre Place Santa Cruz, CA 95060 US
ポールホフマンVPNコンソーシアム127セグレプレイスサンタクルス、カリフォルニア州95060米国
EMail: paul.hoffman@vpnc.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。