RFC4894 日本語訳
4894 Use of Hash Algorithms in Internet Key Exchange (IKE) and IPsec.P. Hoffman. May 2007. (Format: TXT=22899 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group P. Hoffman Request for Comments: 4894 VPN Consortium Category: Informational May 2007
コメントを求めるワーキンググループP.ホフマン要求をネットワークでつないでください: 4894年のVPN共同体カテゴリ: 情報の2007年5月
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).
IETFが信じる著作権(C)(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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 IKEv1とIKEv2. . . . . . . . . . . . . . . . . . 2 3では、論じ尽くします。 IPsec. . . . . . . . . . . . . . . . . . . . . . . 3 4では、論じ尽くします。 IKEv1とIKEv2. . . . . . . . . . . . . 3 5のPKIX証明書。 暗号の機能. . . . . . . . . . . . . . . 3 5.1を選びます。 異なった暗号の機能. . . . . . . . . . . . 4 5.2。 プロトコル. . . . 4 5.3での暗号の機能を指定します。 認証. . . 5 6における暗号の機能を指定します。 変化. . . . . . . . . . . . . . . . . . . . . . 6 6.1を示しました。 プロトコル. . . . . . . . . . . 6 6.2のために変化を示しました。 作成者. . . . . . . . . . . . 7 7のために変化を示しました。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 7 8。 有益な参照. . . . . . . . . . . . . . . . . . . . 8付録A.承認. . . . . . . . . . . . . . . . . . . 10
Hoffman Informational [Page 1] RFC 4894 IKE and IPsec Hash Use May 2007
ホフマン情報[1ページ]のRFC4894IKEとIPsec細切れ肉料理は2007年5月を使用します。
1. Introduction
1. 序論
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[超能力]、および[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"は「1インチのIKEv1と協定の過程の位相を合わせてください。」だけ、について言及します。 「IKEv2"はイケ_SA_INITとイケ_AUTH交換について言及します。」 "IPsec"はAuthentication Header(AH)かEncapsulating Security有効搭載量(超能力)で要約されたIPを示します。
2. Hashes in IKEv1 and IKEv2
2. 中では、IKEv1とIKEv2を論じ尽くします。
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の両方が擬似ランダム機能(PRFs)としてハッシュ関数を使用できます。 PRFsへの入力はいつも相手があらかじめ予測できない創始者と応答者の両方からの一回だけの値を含んでいます。 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で論じ尽くす、保全保護として、イケ_SA_INIT Exchangeの後のすべてのメッセージのために、使用されます。 これらが論じ尽くす、Hashedメッセージ立証コード(HMACs)では、使用されます。 [HMAC-減少]で説明されるように、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
IKEv1とIKEv2の両方には、デジタル署名を使用する認証モードがあります。 使用がサインされるメッセージのユニークなダイジェストを作るために論じ尽くすデジタル署名。 現在の知られている攻撃、衝突する2つのメッセージを作成できる唯一のパーティーと共にIKE実体があります。
Hoffman Informational [Page 2] RFC 4894 IKE and IPsec Hash Use May 2007
ホフマン情報[2ページ]のRFC4894IKEとIPsec細切れ肉料理は2007年5月を使用します。
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.
それはメッセージを発生させます。 [目標衝突]で示されるように、攻撃者は同じ署名を持っている異なったアイデンティティがある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.
Network Access Translator(NAT)縦断サポートと共に[NAT T]で説明されるようにIKEv1を使用できます。 IKEv2はこのNAT縦断サポートを含んでいます。 これらのケースの両方では、ハッシュ関数は、創始者、そして/または、応答者によって使用されたIPアドレスをあいまいにするのに使用されます。 ここのハッシュ関数はどんな知られている衝突減少攻撃にも影響されやすくはありません。
3. Hashes in IPsec
3. 中では、IPsecを論じ尽くします。
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はパケットを認証するのにハッシュ関数を使用します。 超能力がそれ自身の認証を使用しているとき、超能力に、同じくらいは本当です。 IPsecの両方の用途のために、ハッシュ関数は論じ尽くされたMACs(HMACs)でいつも使用されます。 [HMAC-減少]で説明されるように、HMACsで使用されるMD5は偽造に影響されやすいです、そして、HMACで使用される完全なSHA-1が偽造に影響されやすいと疑われます。 それをだましたいために正統のパケット認証を作成する人の理由は知られていません。
4. PKIX Certificates in IKEv1 and IKEv2
4. IKEv1とIKEv2のPKIX証明書
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実現で引き継がれるでしょう。
5. Choosing Cryptographic Functions
5. 暗号の機能を選びます。
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.
最近、プロトコルにおける1回のパーティーが、最初のパーティーが、2番目のパーティーがどの暗号の機能を使用するのを好むかを相手に言う能力に関して、より多くの議論がIETFにありました。 [展開]で議論は一部拍車をかけられました。 その紙はハッシュ関数に焦点を合わせますが、それはまた、他の暗号の機能に関連しています。
Hoffman Informational [Page 3] RFC 4894 IKE and IPsec Hash Use May 2007
ホフマン情報[3ページ]のRFC4894IKEとIPsec細切れ肉料理は2007年5月を使用します。
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 どの種類の暗号の関数が相手の公開鍵証明書で使用されるべきであるかを相手に示唆する能力
5.1. Different Cryptographic Functions
5.1. 異なった暗号の機能
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はハッシュ関数が使用されている(すなわち、衝突減少攻撃にどんな敏感さも持っているあらゆる場所の)あらゆる重要な場所に既に異なったハッシュ関数を許容します。
5.2. Specifying Cryptographic Functions in the Protocol
5.2. プロトコルでの暗号の機能を指定します。
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.
暗号の機能の選択を許すプロトコルがすべてのパーティーが使用されるためにどの機能が行くことであるかに同意する方法を必要とします。 安全な電子メールなどのいくつかのプロトコルで、創始者は単に1セットの暗号の機能を選ぶことができます。 応答者が、機能が使用したのを理解していないなら、トランスミッションは失敗します。 他のプロトコルは、2回のパーティーが、どの暗号の機能が使用されるかに同意するのを許容します。 パーティー(「提案者」)がそれが使用しても構わないと思っているすべての機能を記載するプロトコルに、「交渉」という用語は不適当です、そして、これは時々「交渉」と呼ばれますが、相手(「選択者」)は単に使用されるものを選びます。
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
新しい暗号の機能を導入するとき、1回のパーティーが、彼らが新しい機能を使用できると相手に言いたがっているかもしれません。 それが新しい機能を使用したがっている提案者であるなら、状況は簡単です: 提案者はことによると単に新しい機能をリストに追加します。
Hoffman Informational [Page 4] RFC 4894 IKE and IPsec Hash Use May 2007
ホフマン情報[4ページ]のRFC4894IKEとIPsec細切れ肉料理は2007年5月を使用します。
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は提案者にすべての機能を記載させます。 どちらも、選択者は、それが提案されなかったどの機能を使用したかもしれないかを指定できます、どちらかうまくいっているか失敗のSecurity Association(SA)設立で。
5.3. Specifying Cryptographic Functions in Authentication
5.3. 認証における暗号の機能を指定します。
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回のパーティーに異なった暗号の機能がある複数の証明書か署名がある場合にだけ、暗号の機能を指定する問題は関連しています。 このセクションでは、用語「提案者」と「選択者」は前項と異なった意味を持っています。
Hoffman Informational [Page 5] RFC 4894 IKE and IPsec Hash Use May 2007
ホフマン情報[5ページ]のRFC4894IKEとIPsec細切れ肉料理は2007年5月を使用します。
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).
提案者はいくつかのプロトコルで複数の証明書か署名を送ることができます、提案者が他のプロトコルでただ一つの証明書か署名を送ることができるだけですが。 提案者は、いくつかのプロトコルで、複数の証明書を送りますが、それに対してアドバイスします、証明書がかなり大きい場合があるなら(特にカリフォルニアが多くの情報を証明書に積むとき)。
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]は、提案者へのすべての証明書には同じアイデンティティがなければならないと言うことによってこれを制限するよう提案します。
6. Suggested Changes
6. 提案された変化
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に関してこれらの領域の両方について説明します。
6.1. Suggested Changes for the Protocols
6.1. プロトコルのための提案された変化
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への変化があることが望まれています。 IKEv1とIKEv2を変える必要はなくて、PKIXへのいくつかの変化がIKEv1とIKEv2で使用可能であるかもしれません。 PKIXへの他の変化はそれらを取り入れるためにIKEv1とIKEv2に釣り銭がいるかもしれませんが、PKIXへの変化が成立させられるまで、それは知られていないでしょう。
Hoffman Informational [Page 6] RFC 4894 IKE and IPsec Hash Use May 2007
ホフマン情報[6ページ]のRFC4894IKEとIPsec細切れ肉料理は2007年5月を使用します。
6.2. Suggested Changes for Implementors
6.2. 作成者のための提案された変化
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の使用を禁止などなどの変更を行う必要はありません。 [IKEv2Algs]と[IPsecAlgs]でIKEv2とIPsecのための義務的で提案されたアルゴリズムを与えます。
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細切れ肉料理アルゴリズムを契約される証明書の使用を許すと強く考えるべきです。また、同様に、それらの作成者は、識別のための複数の証明書の発信を許すと強く考えるべきです。
7. Security Considerations
7. セキュリティ問題
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部はハッシュ関数のセキュリティに関する多くのその他の詳細を与えます。
Hoffman Informational [Page 7] RFC 4894 IKE and IPsec Hash Use May 2007
ホフマン情報[7ページ]のRFC4894IKEとIPsec細切れ肉料理は2007年5月を使用します。
8. Informative References
8. 有益な参照
[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とのその使用」、RFC3566、9月2003日
[AES-PRF] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE)", RFC 4434, February 2006.
[AES-PRF] ホフマン、P.、「インターネット・キー・エクスチェンジプロトコル(IKE)のためのAES-XCBC-PRF-128アルゴリズム」、RFC4434、2006年2月。
[AH] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[ああ] ケント、S.、「IP認証ヘッダー」、RFC4302、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.
[超能力] ケント、S.、「セキュリティ有効搭載量(超能力)を要約するIP」、RFC4303、2005年12月。
[HashAttacks] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes in Internet Protocols", RFC 4270, November 2005.
[HashAttacks] ホフマンとP.とB.シュナイアー、「暗号に対する攻撃はインターネットでプロトコルを論じ尽くす」RFC4270、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-減少]のコンティーニ、S.、およびYL。 殷と、「細切れ肉料理衝突を使用するHMACとNMACに対する偽造と部分的なキーリカバリー攻撃」と、暗号理論ePrintは報告します。2006年9月の2006/319。
[IKEv1] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[IKEv1]ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。
[IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[IKEv2] コーフマン、C.、エド、「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」、RFC4306、12月2005日
[IKEv2Algs] Schiller, J., "Cryptographic Algorithms for use in the Internet Key Exchange Version 2", RFC 4307, December 2005.
[IKEv2Algs]シラー、J.、「暗号のAlgorithms、インターネット・キー・エクスチェンジでは、2005インチ年12月にバージョン2インチ、RFC4307を使用してください。
[IPsecAlgs] Eastlake, D., "Cryptographic Algorithm Implementation Requirements For ESP And AH", RFC 4305, December 2005.
そして、[IPsecAlgs]イーストレーク、D.、「超能力のための暗号アルゴリズム実現要件、ああ、」、RFC4305、12月2005日
[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縦断の交渉」、RFC3947、2005年1月。
Hoffman Informational [Page 8] RFC 4894 IKE and IPsec Hash Use May 2007
ホフマン情報[8ページ]のRFC4894IKEとIPsec細切れ肉料理は2007年5月を使用します。
[PKI4IPsec] Korver, B., "The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX", Work in Progress, April 2007.
B.と、「IKEv1/ISAKMPのインターネットIPセキュリティPKIプロフィール、IKEv2、およびPKIX」という[PKI4IPsec]Korverは進歩、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] ケリー、S.、およびS.フランケル(「IPsecとHMAC-SHA-256、HMAC-SHA-384、およびHMAC-SHA-512を使用します」、RFC4868)は2007がそうするかもしれません。
[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.deウエガー)は「MD5のための衝突と異なったアイデンティティのための衝突しているX.509証明書を狙います」、Cryptology ePrint Report2006/360、2006年10月。
Hoffman Informational [Page 9] RFC 4894 IKE and IPsec Hash Use May 2007
ホフマン情報[9ページ]のRFC4894IKEとIPsec細切れ肉料理は2007年5月を使用します。
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、Arjen Lenstra、およびパシEronenによって特に、されました。
Author's Address
作者のアドレス
Paul Hoffman VPN Consortium 127 Segre Place Santa Cruz, CA 95060 US
ポールホフマンVPN共同体127セグレ・Placeカリフォルニア95060サンタクルス(米国)
EMail: paul.hoffman@vpnc.org
メール: paul.hoffman@vpnc.org
Hoffman Informational [Page 10] RFC 4894 IKE and IPsec Hash Use May 2007
ホフマン情報[10ページ]のRFC4894IKEとIPsec細切れ肉料理は2007年5月を使用します。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Hoffman Informational [Page 11]
ホフマンInformationalです。[11ページ]
一覧
スポンサーリンク