[要約] 要約：RFC 4359は、ESPとAH内でRSA/SHA-1署名の使用に関するガイドラインを提供しています。 目的：このRFCの目的は、ESPとAHにおけるRSA/SHA-1署名の使用に関する一貫性とセキュリティを確保することです。
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).
Copyright（c）The Internet Society（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とRFC 4302で説明されているように、RFC 4303および改訂されたIP認証ヘッダー（AH）に記載されているように、RSAデジタル署名アルゴリズムを改訂されたIPカプセル化セキュリティペイロード（ESP）内の認証アルゴリズムとして使用することを説明しています。RSAなどの署名アルゴリズムは、Secret Keyメソッド（HMACなど）がこのプロパティを提供しない場合、アプリケーションでデータ起源認証を提供します。1つの例は、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コンストラクトのキーの入力の証明が送信者を認証するため、そのシナリオでは十分な保護です。ただし、ESPとAHがグループトラフィックを認証する場合、すべてのグループメンバーが単一のHMACキーを共有するため、このプロパティはもはや保持されません。グループケースでは、主要な所有者のいずれかがHMAC変換を形成する能力を持っているため、送信者の身元は一意に確立されていません。HMAC Transformはグループレベルのセキュリティプロパティを確立しますが、データオリジン認証は達成されません。
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").
非対称アルゴリズムを使用すると、送信者はキーのペアを生成します。そのうちの1つは共有されず（「秘密鍵」と呼ばれます）、そのうちの1つは他のグループメンバー（「公開鍵」と呼ばれる）に配布されます。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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.
[RSA]では、2つのデジタル署名エンコードメソッドがサポートされています。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は8ビットの倍数になるように、1〜7ビットがゼロに設定されている1〜7ビットで準備する必要があります。この仕様は、RSAモジュラスが8ビットの倍数ではない場合、出力S [RSA、セクション8.1.1]（RSASA-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）の倍数ではない場合を除き、ICVのサイズはRSAモジュラスのサイズが等しい[AH、セクション2.6]。この場合、適切なサイズの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 Security Association（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として使用されます。署名者のRSA秘密キーはK.を要約すると渡されます。署名生成プロセスは、認証されたパケットバイトのSHA-1ハッシュを計算し、秘密キーを使用して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はSとして検証関数に渡されます。AHまたはESPパケットの認証された部分はメッセージMとして使用され、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モジュラスサイズの選択は慎重に作成する必要があります。弾性サイズが小さすぎる場合、攻撃者は、キーがサインパケットに使用されなくなる前に、パケットに署名するためにパケットに署名するために使用される秘密キーを再構築できる場合があります。このイベントの順序により、Data Origin Authenticationプロパティが侵害される可能性があります。ただし、必要以上に大きいモジュラスサイズを選択すると、送信者とパケットのすべての受信機の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フィールドを追加できません。このようなアルゴリズムの1つの例は、ESP Galois/Counter Modeアルゴリズム[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.
この変換を使用して、ペアワイズSASのデータ起源認証を取得することは推奨されません。ペアワイズSAS（インターネットキーエクスチェンジ[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).
非繰り返しは、この変革の財産として主張されていません。時には、非repudiationのプロパティが、アプリケーションレベルのオブジェクト（電子メールなど）のデジタル署名に適用される場合があります。ただし、このドキュメントでは、ネットワークレベルのオブジェクト（つまり、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か月でコンピューティング力を2倍にできる技術の着実な進歩のために、2010年に段階的に廃止される予定です。SHA-1に対する最近の攻撃は、SHA-1を置き換えることの重要性を強調していますが、その日付までにそれを交換する動機はありません[SHAコメント]。その日付以降のこの変換の使用は、その継続的な適合性に関する分析の前に先行する必要があります。
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データベースのセキュリティ協会を調べることから始まります。見つかった場合、パケット内の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.
この攻撃は、ESPまたはAHのRSA署名を使用してESPまたはAH内の認証を使用してHMAC変換を使用して認証に使用することにより、ほとんどの攻撃者に対して緩和できます。この場合、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".
インターネットセキュリティ協会の「IPSEC認証アルゴリズム」名スペースと主要な管理プロトコル（ISAKMP）レジストリ[ISAKMP-REG]に割り当てられた番号が必要です。ニーモニックは「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.
ISAKMPレジストリでは、RSAモジュラスサイズを渡すために、新しい「IPSECセキュリティアソシエーション属性」が必要です。属性クラスは「認証キーの長さ」と呼ばれる必要があり、可変タイプである必要があります。
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:
ISAKMPレジストリでは、RSA署名エンコーディングタイプを渡すために、2番目の「IPSECセキュリティアソシエーション属性」が必要です。属性クラスは「署名エンコードアルゴリズム」と呼ばれる必要があり、基本的なタイプである必要があります。次のルールが属性の値を定義するために適用されます。
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.
Scott FluhrerとDavid McGrewは、該当するキーサイズに関するアドバイスを提供しました。スコット・フルラーは、重要な寿命に関するアドバイスも提供しました。Ian Jackson、Steve Kent、Ran Canettiは、多くの有益なコメントを提供しました。Sam Hartman、Russ Housley、およびLakshminth Dondetiは、この文書の開発において貴重なガイダンスを提供しました。
[AH] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[AH] Kent、S。、「IP認証ヘッダー」、RFC 4302、2005年12月。
[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[ESP] Kent、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[RFC3552] Rescorla、E。およびB. Korver、「セキュリティに関する考慮事項に関するRFCテキストを書くためのガイドライン」、BCP 72、RFC 3552、2003年7月。
[RSA] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standard (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[RSA] Jonsson、J.およびB. Kaliski、 "Public-Key Cryptography Standard（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：Secure Hash Standardの仕様、2002年8月。http：//csrc.nist.gov/ Publications/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. McGrew、「セキュリティペイロードをカプセル化するIPSECでのガロア/カウンターモード（GCM）の使用（ESP）」、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.、Weis、B.、Hardjono、T。、およびH. Harney、「解釈のグループ領域」、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. Glenn、「ESPおよびAH内のHMAC-SHA-1-96の使用」、RFC 2404、1998年11月。
[IKEV2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[IKEV2] Kaufman、C。、「Internet Key Exchange（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 and RSA Key Size」、RSA Laboratories Technical Note、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-Comments] 2004年8月、SHA-1が提供する安全なハッシュ機能と継続的なセキュリティに関する最近の暗号化攻撃に関するNISTの簡単なコメント。http：//csrc.nist.gov/hash_standards_comments.pdf。
[TWIRL] Shamir, A., and E. Tromer, "Factoring Large Numbers with the TwIRL Device", Work in Progress, February 9, 2003.
[Twirl] Shamir、A。、およびE. Tromer、「Twirl Deviceを使用して多数を考慮する」、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、米国
Phone: (408) 526-4796 EMail: bew@cisco.com
電話：（408）526-4796メール：bew@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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 provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。