Network Working Group B. Weis
Request for Comments: 4359 Cisco Systems
Category: Standards Track January 2006
The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH)
カプセル化セキュリティペイロード（ESP）と認証ヘッダー（AH）内のRSA / SHA-1署名の使用
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This memo describes the use of the RSA digital signature algorithm as an authentication algorithm within the revised IP Encapsulating Security Payload (ESP) as described in RFC 4303 and the revised IP Authentication Header (AH) as described in RFC 4302. The use of a digital signature algorithm, such as RSA, provides data origin authentication in applications when a secret key method (e.g., HMAC) does not provide this property. One example is the use of ESP and AH to authenticate the sender of an IP multicast packet.
RFC 4303改訂IP認証ヘッダ（AH）に記載のようにRFC 4302でデジタルの使用を記載したように、このメモは、改訂されたIPカプセル化セキュリティペイロード（ESP）内の認証アルゴリズムとしてRSAデジタル署名アルゴリズムの使用を記載しています秘密鍵方式（例えば、HMAC）は、このプロパティを提供していないとき、RSAなどの署名アルゴリズムは、アプリケーションでのデータ発信元認証を提供します。一つの例は、IPマルチキャストパケットの送信者を認証するESPとAHの使用です。
Table of Contents
目次
1. Introduction ....................................................2
2. Algorithm and Mode ..............................................3
2.1. Key Size Discussion ........................................4
3. Performance .....................................................5
4. Interaction with the ESP Cipher Mechanism .......................6
5. Key Management Considerations ...................................6
6. Security Considerations .........................................7
6.1. Eavesdropping ..............................................7
6.2. Replay .....................................................7
6.3. Message Insertion ..........................................8
6.4. Deletion ...................................................8
6.5. Modification ...............................................8
6.6. Man in the Middle ..........................................8
6.7. Denial of Service ..........................................8
7. IANA Considerations .............................................9
8. Acknowledgements ...............................................10
9. References .....................................................10
9.1. Normative References ......................................10
9.2. Informative References ....................................10
Encapsulating Security Payload (ESP) [ESP] and Authentication Header (AH) [AH] headers can be used to protect both unicast traffic and group (e.g., IPv4 and IPv6 multicast) traffic. When unicast traffic is protected between a pair of entities, HMAC transforms (such as [HMAC-SHA]) are sufficient to prove data origin authentication. An HMAC is sufficient protection in that scenario because only the two entities involved in the communication have access to the key, and proof-of-possession of the key in the HMAC construct authenticates the sender. However, when ESP and AH authenticate group traffic, this property no longer holds because all group members share the single HMAC key. In the group case, the identity of the sender is not uniquely established, since any of the key holders has the ability to form the HMAC transform. Although the HMAC transform establishes a group-level security property, data origin authentication is not achieved.
セキュリティペイロード（ESP）[ESP]と認証ヘッダ（AH）[AH]ヘッダーは、ユニキャストトラフィックとグループの両方を保護するために使用することができる（例えば、IPv4およびIPv6マルチキャスト）トラフィックをカプセル化します。ユニキャストトラフィックは、エンティティの対の間に保護されている場合、HMACは、データ発信元認証を証明するのに十分である（例えば[HMAC-SHA]のように）変換します。 HMACは通信のみに関与する2つのエンティティは、キーへのアクセス権を持っているので、そのシナリオでは十分な保護である、と実証の所持HMAC構築物中のキーの送信者を認証します。すべてのグループメンバーは、単一のHMACキーを共有するためしかし、ESPとAHは、グループのトラフィックを認証する場合、このプロパティは、もはや保持していません。キーホルダーのいずれかの変換HMACを形成する能力を有しているので、グループの場合には、送信者の身元を一意に、確立されていません。 HMACは、トランスフォーム・グループ・レベルのセキュリティプロパティを設定しますが、データ発信元認証が達成されません。
Some group applications require true data origin authentication, where one group member cannot successfully impersonate another group member. The use of asymmetric digital signature algorithms, such as RSA, can provide true data origin authentication.
いくつかのグループアプリケーションでは、1人のグループメンバーが正常に別のグループのメンバーになりすますことができない真のデータ発信元認証を、必要としています。 RSAなどの非対称デジタル署名アルゴリズムの使用は、真のデータ発信元認証を提供することができます。
With asymmetric algorithms, the sender generates a pair of keys, one of which is never shared (called the "private key") and one of which is distributed to other group members (called the "public key").
非対称アルゴリズムを使用すると、送信者は（「公開鍵」と呼ばれる）（「秘密鍵」と呼ばれる）が共有されることはありませんそのうちの一つの鍵のペアとの一方が他方のグループのメンバーに配布されて生成されます。
When the private key is used to sign the output of a cryptographic hash algorithm, the result is called a "digital signature". A receiver of the digital signature uses the public key, the signature value, and an independently computed hash to determine whether or not the claimed origin of the packet is correct.
秘密鍵は暗号化ハッシュアルゴリズムの出力に署名するために使用される場合、その結果は、「デジタル署名」と呼ばれています。デジタル署名の受信機は、パケットの請求元が正しいか否かを決定するために、公開鍵、署名値、及び独立して計算されたハッシュを使用します。
This memo describes how RSA digital signatures can be applied as an ESP and AH authentication mechanism to provide data origin authentication.
このメモはRSAデジタル署名は、データ発信元認証を提供するために、ESPおよびAH認証メカニズムとして適用することができる方法について説明します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
The RSA Public Key Algorithm [RSA] is a widely deployed public key algorithm commonly used for digital signatures. Compared to other public key algorithms, signature verification is relatively efficient. This property is useful for groups where receivers may have limited processing capabilities. The RSA algorithm is commonly supported in hardware.
RSA公開鍵アルゴリズム[RSA]は、一般的にデジタル署名を使用広く展開されている公開鍵アルゴリズムです。他のパブリックキーアルゴリズムと比較して、署名の検証は、比較的効率的です。このプロパティには、受信機が限られた処理能力を有することができるグループのために有用です。 RSAアルゴリズムは、一般的にハードウェアでサポートされています。
Two digital signature encoding methods are supported in [RSA]. RSASSA-PKCS1-v1_5 MUST be supported by a conforming implementation. RSASSA-PSS is generally believed to be more secure, but at the time of this writing is not ubiquitous. RSASSA-PSS SHOULD be used whenever it is available. SHA-1 [SHA] MUST be used as the signature hash algorithm used by the RSA digital signature algorithm.
2つのデジタル署名の符号化方法は、[RSA]でサポートされています。 RSASSA-PKCS1-v1_5のは準拠実装によってサポートされなければなりません。 RSASSA-PSSは、一般的に、より安全であると考えられますが、この記事の執筆時点ではユビキタスではありません。それが利用可能である時はいつでもRSASSA-PSSを使用する必要があります。 SHA-1 [SHA]はRSAデジタル署名アルゴリズムによって使用される署名ハッシュアルゴリズムとして使用しなければなりません。
When specified for ESP, the Integrity Check Value (ICV) is equal in size to the RSA modulus, unless the RSA modulus is not a multiple of 8 bits. In this case, the ICV MUST be prepended with between 1 and 7 bits set to zero such that the ICV is a multiple of 8 bits. This specification matches the output S [RSA, Section 8.1.1] (RSASSA-PSS) and [RSA, Section 8.2.1] (RSASSA-PKCS1-v1_5) when the RSA modulus is not a multiple of 8 bits. No implicit ESP ICV Padding bits are necessary.
ESPに指定されたときにRSAモジュラスは8ビットの倍数でない場合を除き、インテグリティ・チェック値（ICV）は、RSAモジュラスのサイズに等しいです。この場合、ICVは、ICVが8ビットの倍数であるようにゼロに設定1〜7ビットで付加されなければなりません。 RSAモジュラスは8ビットの倍数でない場合、この仕様は、出力S [RSA、セクション8.1.1（RSASSA-PSS）および[RSA、8.2.1項（RSASSA-PKCS1-v1_5の）に一致します。暗黙ESP ICVパディングビットは必要ありません。
When specified for AH, the ICV is equal in size of the RSA modulus, unless the RSA modulus is not a multiple of 32 bits (IPv4) or 64 bits (IPv6) [AH, Section 2.6]. In this case, explicit ICV Padding bits are necessary to create a suitably sized ICV [AH, Section 3.3.3.2.1].
AHのために指定されたときにRSAモジュラスは、32ビット（IPv4）の64ビット（IPv6）の[AH、セクション2.6]の倍数でない場合を除き、ICVは、RSAモジュラスのサイズに等しいです。この場合には、明示的なICVパディングビットは適切なサイズのICVを作成するために必要である[AH、セクション3.3.3.2.1]。
The distribution mechanism of the RSA public key and its replacement interval are a group policy matter. The use of an ephemeral key pair with a lifetime of the ESP or AH Security Association (SA) is RECOMMENDED. This recommended policy reduces the exposure of the RSA private key to the lifetime of the data being signed by the private key. Also, this obviates the need to revoke or transmit the validity period of the key pair.
RSA公開鍵の配布メカニズムとその交換周期は、グループポリシーの問題です。 ESPまたはAHセキュリティアソシエーション（SA）の寿命が短命鍵ペアの使用が推奨されます。この推奨ポリシーは、秘密鍵によって署名されたデータの寿命へのRSA秘密鍵の暴露を低減します。また、これは、鍵ペアの有効期間を取り消すまたは送信する必要がなくなります。
Digital signature generation is performed as described in [RSA, Section 8.1.1] (RSASSA-PSS) and [RSA, Section 8.2.1](RSASSA-PKCS1- v1_5). The authenticated portion of the AH or ESP packet ([AH, Section 3.3.3], [ESP, Section 3.3.2]) is used as the message M, which is passed to the signature generation function. The signer's RSA private key is passed as K. Summarizing, the signature generation process computes a SHA-1 hash of the authenticated packet bytes, signs the SHA-1 hash using the private key, and encodes the result with the specified RSA encoding type. This process results in a value S, which is known as the ICV in AH and ESP.
[RSA、セクション8.1.1（RSASSA-PSS）および[RSA、8.2.1項（RSASSA-PKCS1-のv1_5の）に記載されているように、デジタル署名の生成が行われます。 AHまたはESPパケット（[AH、3.3.3]、[ESP、3.3.2]）の認証部分は、署名生成関数に渡されたメッセージMとして使用されます。 K.要約、署名生成プロセスが認証パケットのバイトのSHA-1ハッシュを計算するように署名者のRSA秘密鍵を渡され、秘密鍵を用いて、SHA-1ハッシュに署名し、指定されたRSA符号化タイプを用いて結果を符号化します。 AHとESPにおけるICVとして知られている値S、このプロセスをもたらします。
Digital signature verification is performed as described in [RSA, Section 8.1.2] (RSASSA-PSS) and [RSA, Section 8.2.2] (RSASSA-PKCS1-v1_5). Upon receipt, the ICV is passed to the verification function as S. The authenticated portion of the AH or ESP packet is used as the message M, and the RSA public key is passed as (n, e). In summary, the verification function computes a SHA-1 hash of the authenticated packet bytes, decrypts the SHA-1 hash in the ICV, and validates that the appropriate encoding was applied and was correct. The two SHA-1 hashes are compared, and if they are identical the validation is successful.
[RSA、セクション8.1.2（RSASSA-PSS）および[RSA、セクション8.2.2（RSASSA-PKCS1-v1_5の）に記載されているように、デジタル署名の検証が行われます。受信すると、ICVは、AHまたはESPパケットの認証された部分は、メッセージMとして使用されているS.として検証関数に渡され、RSA公開鍵（N、e）のように渡されます。要約すると、検証機能は、認証されたパケットのバイトのSHA-1ハッシュを計算ICVでSHA-1ハッシュを復号し、適切な符号化が適用され、正確であったことを検証します。 2 SHA-1ハッシュを比較し、それらが同一である場合、検証は成功です。
The choice of RSA modulus size must be made carefully. If too small of a modulus size is chosen, an attacker may be able to reconstruct the private key used to sign packets before the key is no longer used by the sender to sign packets. This order of events may result in the data origin authentication property being compromised. However, choosing a modulus size larger than necessary will result in an unnecessarily high cost of CPU cycles for the sender and all receivers of the packet.
RSAモジュラスサイズの選択は慎重に行わなければなりません。モジュラスサイズの小さすぎるが選択された場合、攻撃者は鍵がパケットに署名する送信者によってもはや使用される前に、パケットに署名しないために使用される秘密鍵を再構築することができるかもしれません。このイベントの順序は、危険にさらされているデータ発信元認証プロパティをもたらすことができます。しかし、必要以上に大きなモジュラスサイズを選択すると、送信者のためのCPUサイクルを不必要に高いコストと、パケットのすべての受信機になります。
A conforming implementation MUST support a modulus size of 1024 bits.
適合実装は、1024ビットのモジュラスサイズをサポートしなければなりません。
Recent guidance [TWIRL, RSA-TR] on key sizes makes estimates as to the amount of effort an attacker would need to expend in order to reconstruct an RSA private key. Table 1 summarizes the maximum length of time that selected modulus sizes should be used. Note that these recommendations are based on factors such as the cost of processing and memory, as well as cryptographic analysis methods, which were current at the time these documents were published. As those factors change, choices of key lifetimes should take them into account.
キーのサイズに関する最近の手引き[TWIRL、RSA-TR]は、攻撃者がRSA秘密鍵を再構成するために費やす必要があるだろうな努力の量として見積りを行っています。表1は、使用されるべき係数のサイズを選択された時間の長さの最大値をまとめたものです。これらの推奨事項は、例えば、これらの文書が公開された時点での最新の処理およびメモリのコスト、ならびに暗号解析法、などの要因に基づいていることに留意されたいです。これらの要因が変化すると、キーの有効期間の選択はそれらを考慮すべきです。
Number of Recommended Maximum
Modulus Bits Lifetime
------------ -------------------
768 1 week
1024 1 year
Table 1. RSA Key Use Lifetime Recommendations
表1. RSAキーの使用寿命勧告
The RSA asymmetric key algorithm is very costly in terms of processing time compared to the HMAC algorithms. However, processing cost is decreasing over time. Faster general-purpose processors are being deployed, faster software implementations are being developed, and hardware acceleration support for the algorithm is becoming more prevalent.
RSA非対称鍵アルゴリズムはHMACアルゴリズムに比べて、処理時間の観点から非常に高価です。しかし、処理コストは、時間の経過とともに減少しています。高速汎用プロセッサが展開されて、より高速なソフトウェア実装が開発されている、およびアルゴリズムのハードウェアアクセラレーションのサポートは、より一般的になってきています。
Care should be taken that RSA signatures are not used for applications when potential receivers are known to lack sufficient processing power to verify the signature. It is also important to use this scheme judiciously when any receiver may be battery powered.
ケアは、潜在的な受信機は署名を検証するための十分な処理能力を欠いていることが知られているときにRSA署名は、アプリケーションのために使用されていないことを注意すべきです。任意の受信機の電源が電池であってもよいとき、慎重にこの方式を使用することも重要です。
The RSA asymmetric key algorithm is best suited to protect network traffic for which:
RSA非対称キーアルゴリズムは、最良のネットワークトラフィックを保護するために適しています：
o The sender has a substantial amount of processing power, and
O送信者が処理能力のかなりの量を有し、そして
o The network traffic is small enough that adding a relatively large authentication tag (in the range of 62 to 256 bytes) does not cause packet fragmentation.
ネットワークトラフィックO（62〜256バイトの範囲で）比較的大きな認証タグを追加すると、パケットの断片化を引き起こさないように十分に小さいです。
RSA key pair generation and signing are substantially more expensive operations than signature verification, but these are isolated to the sender.
RSA鍵ペア生成および署名は、実質的に署名検証よりも高価操作であるが、これらは送信者に分離されています。
The size of the RSA modulus affects the processing required to create and verify RSA digital signatures. Care should be taken to determine the size of modulus needed for the application. Smaller modulus sizes may be chosen as long as the network traffic protected by the private key flows for less time than it is estimated that an attacker would take to discover the private key. This lifetime is considerably smaller than most public key applications that store the signed data for a period of time. But since the digital signature is used only for sender verification purposes, a modulus that is considered weak in another context may be satisfactory.
RSAモジュラスのサイズは、RSAデジタル署名を作成し検証するために必要な処理に影響を与えます。ケアは、アプリケーションに必要な係数の大きさを決定するために取られるべきです。小さいモジュラスサイズは、攻撃者が秘密鍵を発見するのにかかると推定されているよりも短い時間のために秘密鍵が流れによって保護されたネットワークトラフィック限り、選択することができます。この寿命は、一定の期間のために署名データを格納し、ほとんどの公開鍵のアプリケーションよりもかなり小さいです。デジタル署名は、送信者の確認のためにのみ使用されるためしかし、別のコンテキストでは弱いと考えられる弾性率が十分であってもよいです。
The size of the RSA public exponent can affect the processing required to verify RSA digital signatures. Low-exponent RSA signatures may result in a lower verification processing cost. At the time of this writing, no attacks are known against low-exponent RSA signatures that would allow an attacker to create a valid signature using the RSAES-OAEP scheme.
RSA公開指数の大きさは、RSAデジタル署名を検証するために必要な処理に影響を与えることができます。低指数RSA署名は、より低い検証処理コストをもたらすことができます。この記事の執筆時点では、何の攻撃は、攻撃者がRSAES-OAEP方式を使用して、有効な署名を作成できるようになる低指数RSA署名に対して知られていません。
The addition of a digital signature as an authentication tag adds a significant number of bytes to the packet. This increases the likelihood that the packet encapsulated in ESP or AH may be fragmented.
認証タグなどのデジタル署名の付加は、パケットのバイトのかなりの数を加算します。これは、ESPまたはAHにカプセル化されたパケットを断片化することができる可能性を高めます。
The RSA signature algorithm cannot be used with an ESP Combined Mode algorithm that includes an explicit ICV. The Combined Mode algorithm will add the ESP ICV field, which does not allow use of a separate authentication algorithm to add the ESP ICV field. One example of such an algorithm is the ESP Galois/Counter Mode algorithm [AES-GCM].
RSA署名アルゴリズムは、明示的なICVを含むESP複合モードのアルゴリズムで使用することができません。複合モードのアルゴリズムは、独立した認証アルゴリズムの使用はESP ICVフィールドを追加することはできませんESP ICVフィールドを追加します。そのようなアルゴリズムの一例は、ESPガロア/カウンタモードアルゴリズム[AES-GCM]です。
Key management mechanisms negotiating the use of RSA signatures MUST include the length of the RSA modulus during policy negotiation using the Authentication Key Length SA Attribute. This gives a device the opportunity to decline use of the algorithm. This is especially important for devices with constrained processors that might not be able to verify signatures using larger key sizes.
RSA署名の使用を交渉する鍵管理メカニズムは、認証キー長SA属性を使用してポリシー交渉中RSAモジュラスの長さを含まなければなりません。これは、デバイスにアルゴリズムの使用を拒否する機会を与えてくれます。これは、より大きなキーサイズを使用して署名を検証することができない場合があります制約のプロセッサを搭載したデバイスのために特に重要です。
Key management mechanisms negotiating the use of RSA signatures also MUST include the encoding method during policy negotiation using the Signature Encoding Algorithm SA Attribute.
RSA署名の使用を交渉する鍵管理メカニズムはまた、署名エンコーディングアルゴリズムSA属性を使用してポリシー交渉中に符号化方法を含まなければなりません。
A receiver must have the RSA public key in order to verify integrity of the packet. When used with a group key management system (e.g., RFC 3547 [GDOI]), the public key SHOULD be sent as part of the key download policy. If the group has multiple senders, the public key of each sender SHOULD be sent as part of the key download policy.
受信機は、パケットの完全性を検証するために、RSA公開鍵を持っている必要があります。グループ鍵管理システム（例えば、RFC 3547 [GDOI]）で使用される場合、公開鍵は、鍵ダウンロードポリシーの一部として送信されるべきです。グループは、複数の送信者を持っている場合は、各送信者の公開鍵は、鍵のダウンロードポリシーの一部として送ってください。
Use of this transform to obtain data origin authentication for pairwise SAs is NOT RECOMMENDED. In the case of pairwise SAs (such as negotiated by the Internet Key Exchange [IKEV2]), data origin authentication can be achieved with an HMAC transform. Because the performance impact of an RSA signature is typically greater than an HMAC, the value of using this transform for a pairwise connection is limited.
これを利用ペアワイズSAのデータ発信元認証を取得するために変換することはお勧めしません。ペアワイズSAの場合には（インターネット鍵交換【のIKEv2]によって交渉など）、データ発信元認証変換HMACを用いて達成することができます。 RSA署名のパフォーマンスへの影響がHMACより一般的に大きいので、このペアワイズの接続のために変換を用いるの値は制限されます。
This document provides a method of authentication for ESP and AH using digital signatures. This feature provides the following protections:
この文書では、ESPとAHは、デジタル署名を使用するための認証方法を提供します。この機能は、次の保護を提供します。
o Message modification integrity. The digital signature allows the receiver of the message to verify that it was exactly the same as when the sender signed it.
Oメッセージの変更の整合性。デジタル署名は、メッセージの受信側は、それが送信者がそれに署名したときと全く同じであったことを確認することを可能にします。
o Host authentication. The asymmetric nature of the RSA public key algorithm allows the sender to be uniquely verified, even when the message is sent to a group.
Oホスト認証。 RSA公開鍵アルゴリズムの非対称性は、メッセージがグループに送信された場合でも、送信者を一意に確認することを可能にします。
Non-repudiation is not claimed as a property of this transform. At times, the property of non-repudiation may be applied to digital signatures on application-level objects (e.g., electronic mail). However, this document describes a means of authenticating network-level objects (i.e., IP packets), which are ephemeral and not directly correlated to any application. Non-repudiation is not applicable to network-level objects (i.e., IP packets).
否認防止は、この変換の財産として主張されていません。時間で、否認防止のプロパティは、アプリケーション・レベルのオブジェクト（例えば、電子メール）のデジタル署名に適用してもよいです。しかし、この文書は、任意のアプリケーションに直接相関短命とされないネットワークレベルのオブジェクト（すなわち、IPパケット）を、認証の手段を記載します。否認防止は、ネットワークレベルのオブジェクト（すなわち、IPパケット）には適用できません。
A number of attacks are suggested by [RFC3552]. The following sections describe the risks those attacks present when RSA signatures are used for ESP and AH packet authentication.
攻撃の数は、[RFC3552]によって提案されています。 RSA署名はESPとAHパケットの認証に使用されている場合は、次のセクションでは、これらの攻撃が存在するリスクを説明します。
SHA-1 has been scheduled to be phased out in 2010, due to the steady advances in technology by which an adversary can double its computing power in roughly eighteen months. Recent attacks on SHA-1 underscore the importance of replacing SHA-1, but have not motivated replacing it before that date [SHA-COMMENTS]. The use of this transform after that date SHOULD be preceded by an analysis as to its continued suitability.
SHA-1が原因敵はおよそ18ヶ月でその計算能力を倍増させることができたことにより、技術の着実な進歩に、2010年に段階的に廃止される予定されています。 SHA-1に関する最近の攻撃は[SHA-コメント] SHA-1を交換することの重要性を強調したが、その日の前にそれを交換する動機していません。その日は、その継続的適合性などの分析が先行されるべきである（SHOULD）した後、これを使用すると、変換します。
This document does not address confidentiality. That function, if desired, must be addressed by an ESP cipher that is used with the RSA signatures authentication method. The RSA signature itself does not need to be protected from an eavesdropper.
この文書では、機密性に対応していません。その機能は、所望であれば、RSA署名認証方式で使用されESP暗号によって対処されなければなりません。 RSA署名自体は盗聴者から保護する必要はありません。
This document does not address replay attacks. That function, if desired, is addressed through use of ESP and AH sequence numbers as defined in [ESP] and [AH].
この文書では、リプレイ攻撃に対処していません。 [ESP]と[AH]で定義されるように、その関数は、所望であれば、ESPおよびAHのシーケンス番号を使用することによって対処されます。
This document directly addresses message insertion attacks. Inserted messages will fail authentication and be dropped by the receiver.
この文書では、直接メッセージ挿入攻撃に対処しています。挿入されたメッセージは、認証が失敗し、受信機によって落とされます。
This document does not address deletion attacks. It is concerned only with validating the legitimacy of messages that are not deleted.
この文書は削除攻撃に対応していません。それだけで削除されていないメッセージの正当性を検証すると懸念しています。
This document directly addresses message modification attacks. Modified messages will fail authentication and be dropped by the receiver.
この文書では、直接メッセージ変更攻撃に対処しています。変更されたメッセージは、認証が失敗し、受信機によって落とされます。
As long as a receiver is given the sender RSA public key in a trusted manner (e.g., by a key management protocol), it will be able to verify that the digital signature is correct. A man in the middle will not be able to spoof the actual sender unless it acquires the RSA private key through some means.
限り、受信機は、信頼できる方法で送信者RSA公開鍵が与えられているように（例えば、鍵管理プロトコルによって）、デジタル署名が正しいことを確認することができるであろう。真ん中の人は、それが何らかの手段を通じてRSA秘密鍵を取得しない限り、実際の送信者を偽装することはできません。
The RSA modulus size must be chosen carefully to ensure that the time a man in the middle needs to determine the RSA private key through cryptanalysis is longer than the amount of time that packets are signed with that private key.
RSAモジュラスサイズは真ん中の男性が暗号解読を通じてRSA秘密鍵を決定するために必要な時間が長く、パケットがその秘密鍵で署名された時間の量よりもあることを保証するために慎重に選択する必要があります。
According to IPsec processing rules, a receiver of an ESP and AH packet begins by looking up the Security Association in the SA database. If one is found, the ESP or AH sequence number in the packet is verified. No further processing will be applied to packets with an invalid sequence number.
IPsec処理規則によると、ESPとAHパケットの受信機は、SAデータベースのセキュリティアソシエーションを検索することから始まります。 1が見つかった場合、パケット内のESPまたはAHのシーケンス番号が検証されます。それ以上の処理は、無効なシーケンス番号を持つパケットに適用されません。
An attacker that sends an ESP or AH packet matching a valid SA on the system and also having a valid sequence number will cause the receiver to perform the ESP or AH authentication step. Because the process of verifying an RSA digital signature consumes relatively large amounts of processing, many such packets could lead to a denial of service (DoS) attack on the receiver.
システム上で有効なSAに一致するESPまたはAHパケットを送信し、また、有効なシーケンス番号を有する受信機は、ESPまたはAH認証ステップを実行するようになります攻撃。 RSAデジタル署名の検証プロセスは、処理の比較的大量に消費するため、多くのそのようなパケットは、受信機でサービス拒否（DoS）攻撃の拒否につながる可能性があります。
If the message was sent to an IPv4 or IPv6 multicast group, all group members that received the packet would be under attack simultaneously.
メッセージはIPv4またはIPv6マルチキャストグループに送信された場合、パケットを受信したすべてのグループメンバーが同時に攻撃を受けているでしょう。
This attack can be mitigated against most attackers by encapsulating ESP or AH using an RSA signature for authentication within ESP or AH using an HMAC transform for authentication. In this case, the HMAC transform would be validated first, and as long as the attacker does not possess the HMAC key no digital signatures would be evaluated on the attacker packets. However, if the attacker does possess the HMAC key (e.g., the attacker is a legitimate member of the group using the SA), then the DoS attack cannot be mitigated.
この攻撃は、認証に変換HMACを使用してESPまたはAH内の認証にRSA署名を使用して、ESPまたはAHをカプセル化することによって、ほとんどの攻撃に対して緩和することができます。この場合、HMACは、変換最初に検証されるであろう、そして限り、攻撃者は、HMACキーを持たないようにないデジタル署名が攻撃パケットで評価されません。攻撃者がHMAC鍵を所有している場合しかし、（例えば、攻撃者はSAを使用してグループの正規メンバーである）は、DoS攻撃を緩和することができません。
An assigned number is required in the "IPSec Authentication Algorithm" name space in the Internet Security Association and Key Management Protocol (ISAKMP) registry [ISAKMP-REG]. The mnemonic should be "SIG-RSA".
割り当てられた番号は、インターネットSecurity AssociationとKey Managementプロトコル（ISAKMP）レジストリ[ISAKMP-REG]で、「IPSecの認証アルゴリズム」名前空間に必要とされます。ニーモニックは、「SIG-RSA」にする必要があります。
An assigned number is also required in the "IPSEC AH Transform Identifiers" name space in the ISAKMP registry. Its mnemonic should be "AH_RSA".
割り当てられた番号は、ISAKMPレジストリに「IPSEC AHは、識別子の変換」名前空間に必要とされます。そのニーモニックは「AH_RSA」でなければなりません。
A new "IPSEC Security Association Attribute" is required in the ISAKMP registry to pass the RSA modulus size. The attribute class should be called "Authentication Key Length", and it should be a Variable type.
新しい「IPSECセキュリティアソシエーション属性は、」RSAモジュラスサイズを渡すためにISAKMPレジストリに必要とされます。属性クラスは、「認証キーの長さ」と呼ばれるべきである、それは変数タイプでなければなりません。
A second "IPSEC Security Association Attribute" is required in the ISAKMP registry to pass the RSA signature encoding type. The attribute class should be called "Signature Encoding Algorithm", and it should be a Basic type. The following rules apply to define the values of the attribute:
第二の「IPSECセキュリティアソシエーション属性は、」RSA署名符号化タイプを渡すためにISAKMPレジストリに必要とされます。属性クラスは、「署名符号化アルゴリズム」と呼ばれるべき、それが基本的なタイプでなければなりません。次の規則は、属性の値を定義するために適用されます。
Name Value
---- -----
Reserved 0
RSASSA-PKCS1-v1_5 1
RSASSA-PSS 2
Values 3-61439 are reserved to IANA. New values MUST be added due to a Standards Action as defined in [RFC2434]. Values 61440-65535 are for private use and may be allocated by implementations for their own purposes.
値3から61439は、IANAに予約されています。 [RFC2434]で定義された新しい値が原因標準アクションに加えなければなりません。値は61440から65535は、私的使用のためのものであり、自分自身の目的のための実装によって割り当てられることができます。
Scott Fluhrer and David McGrew provided advice regarding applicable key sizes. Scott Fluhrer also provided advice regarding key lifetimes. Ian Jackson, Steve Kent, and Ran Canetti provided many helpful comments. Sam Hartman, Russ Housley, and Lakshminth Dondeti provided valuable guidance in the development of this document.
スコットFluhrerとDavidマグリューは、該当するキーのサイズに関するアドバイスを提供しました。スコットFluhrerまた、キーの有効期間に関するアドバイスを提供しました。イアン・ジャクソン、スティーブ・ケント、およびカネッティ蘭は、多くの有益なコメントを提供しました。サム・ハートマン、ラスHousley、およびLakshminth Dondetiは、このドキュメントの開発に貴重なガイダンスを提供します。
[AH] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[AH]ケント、S.、 "IP認証ヘッダー"、RFC 4302、2005年12月。
[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[ESP]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4303、2005年12月。
[ISAKMP-REG] http://www.iana.org/assignments/isakmp-registry
[ISAKMP-REG] http://www.iana.org/assignments/isakmp-registry
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、BCP 14、RFC 2119、1997年3月 "のRFCsにおける使用のためのキーワードは、要求レベルを示すために"。
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[RFC3552]レスコラ、E.とB.コーバー、BCP 72、RFC 3552、2003年7月、 "セキュリティ上の考慮事項の書き方RFCテキストのためのガイドライン"。
[RSA] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standard (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[RSA]ジョンソン、J.とB. Kaliski、 "公開鍵暗号規格（PKCS）＃1：RSA暗号仕様バージョン2.1"、RFC 3447、2003年2月。
[SHA] FIPS PUB 180-2: Specifications for the Secure Hash Standard, August 2002. http://csrc.nist.gov/ publications/fips/fips180-2/fips180-2.pdf.
[SHA] FIPS PUB 180-2の：セキュアハッシュのための仕様標準、2002年8月http://csrc.nist.gov/出版/ FIPS / fips180-2 / fips180-2.pdf。
[AES-GCM] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 4106, June 2005.
[AES-GCM] Viega、J.とD.マグリュー、 "IPsecのカプセル化セキュリティペイロード（ESP）におけるガロア/カウンタモード（GCM）の使用"、RFC 4106、2005年6月。
[GDOI] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, December 2002.
【GDOI] Baugher、M.、ヴァイス、B.、Hardjono、T.、およびH.ハーニー、 "解釈のグループドメイン"、RFC 3547、2002年12月。
[HMAC-SHA] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.
[HMAC-SHA] Madson、C.およびR.グレン、 "ESPおよびAH内HMAC-SHA-1-96の使用"、RFC 2404、1998年11月。
[IKEV2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[IKEv2の]カウフマン、C.、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、2005年12月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[RSA-TR] B. Kaliski, "TWIRL and RSA Key Size", RSA Laboratories Technical Note, http://www.rsasecurity.com/rsalabs/ node.asp?id=2004, May 6, 2003.
[RSA-TR] B. Kaliski、 "TWIRLおよびRSAキーサイズ"、RSA研究所テクニカルノート、http://www.rsasecurity.com/rsalabs/ node.asp？ID = 2004、2003年5月6日。
[SHA-COMMENTS] NIST Brief Comments on Recent Cryptanalytic Attacks on Secure Hashing Functions and the Continued Security Provided by SHA-1, August, 2004. http://csrc.nist.gov/hash_standards_comments.pdf.
[SHA-コメント] SHA-1、8月、2004年http://csrc.nist.gov/hash_standards_comments.pdf提供セキュアハッシュ関数と続きセキュリティに関する最近の暗号分析攻撃にNISTの簡単なコメント。
[TWIRL] Shamir, A., and E. Tromer, "Factoring Large Numbers with the TwIRL Device", Work in Progress, February 9, 2003.
【TWIRL】シャミール、A.、およびE. Tromer、「くるくる回す装置と多数の因数分解」、進歩、2003年2月9日に働きます。
Author's Address
著者のアドレス
Brian Weis Cisco Systems 170 W. Tasman Drive, San Jose, CA 95134-1706, USA
ブライアン・ワイスシスコシステムズ170 W.タスマン・ドライブ、サンノゼ、CA 95134-1706、USA
Phone: (408) 526-4796 EMail: bew@cisco.com
電話：（408）526-4796 Eメール：bew@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
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 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が表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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 provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。