RFC4359 日本語訳
4359 The Use of RSA/SHA-1 Signatures within Encapsulating SecurityPayload (ESP) and Authentication Header (AH). B. Weis. January 2006. (Format: TXT=26989 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Weis Request for Comments: 4359 Cisco Systems Category: Standards Track January 2006
コメントを求めるワーキンググループB.ウィス要求をネットワークでつないでください: 4359年のシスコシステムズカテゴリ: 標準化過程2006年1月
The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(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.
このメモは、RFC4302で説明されるようにRFC4303と改訂されたIP Authentication Header(AH)で説明されるように改訂されたIP Encapsulating Security有効搭載量(超能力)の中でRSAデジタル署名アルゴリズムの使用を認証アルゴリズムと説明します。 秘密鍵メソッド(例えば、HMAC)がこの資産を提供しないとき、RSAなどのデジタル署名アルゴリズムの使用はアプリケーションにおけるデータ発生源認証を提供します。 1つの例はIPマルチキャストパケットの送付者を認証する超能力とAHの使用です。
Weis Standards Track [Page 1] RFC 4359 RSA/SHA-1 Signatures within ESP and AH January 2006
ああ、超能力の中のウィス標準化過程[1ページ]RFC4359RSA/SHA-1署名と2006年1月
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
1. 序論…2 2. アルゴリズムとモード…3 2.1. 主要なサイズ議論…4 3. パフォーマンス…5 4. 超能力暗号メカニズムとの相互作用…6 5. Key Management問題…6 6. セキュリティ問題…7 6.1. 盗聴…7 6.2. 再演してください…7 6.3. メッセージ挿入…8 6.4. 削除…8 6.5. 変更…8 6.6. 中央でやれやれ…8 6.7. サービス妨害…8 7. IANA問題…9 8. 承認…10 9. 参照…10 9.1. 標準の参照…10 9.2. 有益な参照…10
1. Introduction
1. 序論
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.
Security有効搭載量(超能力)[超能力]とAuthentication Header(AH)[AH]がヘッダーであるとカプセル化するのをユニキャストトラフィックとグループ(例えば、IPv4とIPv6マルチキャスト)トラフィックの両方を保護するのに使用できます。 ユニキャストトラフィックが保護されたら、実体、変換([HMAC-SHA]などの)が十分である1組のHMACの間では、データ発生源認証を立証してください。 コミュニケーションにかかわる2つの実体だけがキーに近づく手段を持っているので、HMACはそのシナリオで十分な防護物です、そして、HMAC構造物のキー所有物の証拠は送付者を認証します。 しかしながら、超能力とAHがグループトラフィックを認証するとき、すべてのグループのメンバーが単一のHMACキーを共有するので、この特性はもう持ちこたえません。 グループ場合では、送付者のアイデンティティは唯一確立されません、主要な所有者のどれかには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").
非対称のアルゴリズムで、送付者は1組のキーを生成します。それの1つは決して共有されません(「秘密鍵」と呼ばれます)。他のグループのメンバーにその1つをそれを分配します(「公開鍵」と呼ばれます)。
Weis Standards Track [Page 2] RFC 4359 RSA/SHA-1 Signatures within ESP and AH January 2006
ああ、超能力の中のウィス標準化過程[2ページ]RFC4359RSA/SHA-1署名と2006年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.
このメモはデータ発生源認証を提供するために超能力とAH認証機構としてどうRSAデジタル署名を適用できるかを説明します。
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"、「必須NOT」が「必要です」、“SHALL"、「」、"SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
2. Algorithm and Mode
2. アルゴリズムとモード
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 Public Key Algorithm[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 SHOULD、それが利用可能であるときはいつも、使用されてください。 RSAデジタル署名アルゴリズムで使用される署名ハッシュアルゴリズムとしてSHA-1[SHA]を使用しなければなりません。
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.
超能力に指定されると、Integrity Check Value(ICV)はサイズにおいてRSA係数と等しいです、RSA係数が8ビットの倍数であるなら。 この場合ICV MUST、ICVが8ビットの倍数であるようにもののゼロを合わせるように設定された1〜7ビットで、prependedされます。 RSA係数が8ビットの倍数でないときに、この仕様は出力S[RSA、セクション8.1.1](RSASSA-PSS)と[RSA、セクション8.2.1](RSASSA-PKCS1-v1_5)に合っています。 どんな内在している超能力ICV Paddingビットも必要ではありません。
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に指定されると、ICVはRSA係数のサイズにおいて等しいです、RSA係数が32ビット(IPv4)か64ビット(IPv6)[AH、セクション2.6]の倍数であるなら。 この場合明白なICV Paddingビットが適当に大きさで分けられた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
RSA公開鍵の分配メカニズムとその交換間隔はグループ方針問題です。 超能力かAH Security Association(SA)の生涯があるはかない主要な組の使用はRECOMMENDEDです。 このお勧めの方針はRSAの展示を抑えます。
Weis Standards Track [Page 3] RFC 4359 RSA/SHA-1 Signatures within ESP and AH January 2006
ああ、超能力の中のウィス標準化過程[3ページ]RFC4359RSA/SHA-1署名と2006年1月
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.
秘密鍵によって署名されるデータの生涯までの秘密鍵。 また、これは主要な組の有効期間を取り消すか、または伝える必要性を取り除きます。
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.
デジタル署名世代は説明されたコネ(RSASSA-PSS)と[RSA、セクション8.2.1](RSASSA-PKCS1- v1_5)[RSA、セクション8.1.1]として実行されます。 AHか超能力パケット[AH、セクション3.3.3]の認証された部分、[超能力、セクション3.3.2)はメッセージMとして使用されます。(それは、署名世代機能に通過されます)。 署名者のRSA秘密鍵がK.Summarizingとして通過されて、署名発生経過は、認証されたパケットバイトのSHA-1ハッシュを計算して、秘密鍵を使用することでSHA-1ハッシュに署名して、指定されたRSAがタイプをコード化している結果をコード化します。 このプロセスは値Sをもたらします。(それは、ICVとしてAHと超能力で知られています)。
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.
デジタル署名検証は説明されたコネ(RSASSA-PSS)と[RSA、セクション8.2.2](RSASSA-PKCS1-v1_5)[RSA、セクション8.1.2]として実行されます。 領収書で、S. AHか超能力パケットの認証された部分がメッセージMとして使用されるとき、ICVは検証機能に渡されて、RSA公開鍵は(n、e)として通過されます。 検証関数は、概要では、認証されたパケットバイトのSHA-1ハッシュを計算して、ICVでSHA-1がハッシュであると解読して、それを有効にします。適切なコード化は、適用されて、正しかったです。 2つのSHA-1ハッシュが比較されます、そして、それらが同じであるなら、合法化はうまくいっています。
2.1. Key Size Discussion
2.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は最大の長さの選択された係数サイズが使用されるべきである時間をまとめます。 これらの推薦がこれらのドキュメントが発表されたときよく見られた加工費や、メモリや、暗号の分析法などの要素に基づいていることに注意してください。 それらの要素が変化するとき、主要な生涯の選択はそれらを考慮に入れるべきです。
Weis Standards Track [Page 4] RFC 4359 RSA/SHA-1 Signatures within ESP and AH January 2006
ああ、超能力の中のウィス標準化過程[4ページ]RFC4359RSA/SHA-1署名と2006年1月
Number of Recommended Maximum Modulus Bits Lifetime ------------ ------------------- 768 1 week 1024 1 year
お勧めの最大の係数ビット生涯の数------------ ------------------- 768 1024 1週間1年
Table 1. RSA Key Use Lifetime Recommendations
1を見送ってください。 RSAキーは生涯推薦を使用します。
3. Performance
3. パフォーマンス
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.
HMACアルゴリズムと比べて、RSAの非対称の主要なアルゴリズムは処理時間で非常に高価です。しかしながら、加工費は時間がたつにつれて、下がります。 より速いメインプロセッサは配布されています、そして、より速いソフトウェア実行は開発されています、そして、アルゴリズムのハードウェア加速サポートは、より一般的になっています。
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デジタル署名を作成して、確かめるのに必要である処理に影響します。 アプリケーションに必要である係数のサイズを決定するために注意するべきです。 秘密鍵によって保護されたネットワークトラフィックが攻撃者が秘密鍵を発見するためにかけるそれが見積もられているより少ない時間流れる限り、より小さい係数サイズは選ばれるかもしれません。 この寿命はしばらく署名しているデータを保存するほとんどの公開鍵アプリケーションよりかなりわずかです。 しかし、デジタル署名が送付者検証目的にだけ使用されるので、別の文脈で弱いと考えられる係数は満足できるかもしれません。
Weis Standards Track [Page 5] RFC 4359 RSA/SHA-1 Signatures within ESP and AH January 2006
ああ、超能力の中のウィス標準化過程[5ページ]RFC4359RSA/SHA-1署名と2006年1月
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.
認証タグとしてのデジタル署名の追加は多くのバイトをパケットに加えます。 これは超能力かAHでカプセルに入れられたパケットが断片化されるかもしれない可能性を広げます。
4. Interaction with the ESP Cipher Mechanism
4. 超能力暗号メカニズムとの相互作用
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].
明白なICVを含んでいる超能力Combined ModeアルゴリズムでRSA署名アルゴリズムを使用できません。 Combined ModeアルゴリズムはESP ICV分野を加えるでしょう。(別々の認証アルゴリズムの使用はそれでESP ICV分野を加えることができません)。 そのようなアルゴリズムに関する1つの例が超能力ガロア/カウンタModeアルゴリズム[AES-GCM]です。
5. Key Management Considerations
5. Key Management問題
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.
Authentication Key Length SA Attributeを使用して、RSA署名の使用を交渉するかぎ管理メカニズムは方針交渉の間、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.
また、Signature Encoding Algorithm SA Attributeを使用して、RSA署名の使用を交渉するかぎ管理メカニズムは方針交渉の間、コード化メソッドを含まなければなりません。
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公開鍵が、パケットの保全について確かめるためになければなりません。 いつがグループかぎ管理システム(例えば、RFC3547[GDOI])、公開鍵と共にSHOULDを使用したか。主要なダウンロード方針の一部として、送ります。 グループであるなら、主要なダウンロード方針の一部として複数の送付者、それぞれの送付者SHOULDの公開鍵を送りましたか?
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に得るこの変換の使用はNOT RECOMMENDEDです。 対状SAs(インターネット・キー・エクスチェンジ[IKEV2]によって交渉されるように)の場合では、HMAC変換でデータ発生源認証を達成できます。 RSA署名の性能影響がHMACより通常大きいので、対状接続にこの変換を使用する値は限られています。
Weis Standards Track [Page 6] RFC 4359 RSA/SHA-1 Signatures within ESP and AH January 2006
ああ、超能力の中のウィス標準化過程[6ページ]RFC4359RSA/SHA-1署名と2006年1月
6. Security Considerations
6. セキュリティ問題
This document provides a method of authentication for ESP and AH using digital signatures. This feature provides the following protections:
このドキュメントは、デジタル署名を使用することで認証のメソッドを超能力と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署名が超能力と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.
2010年にSHA-1は段階的に廃止される予定でした、敵がおよそ18カ月後にパワーを計算するのを倍にすることができる安定した科学技術の進歩のため。 SHA-1を取り替えながら重要性を強調しますが、SHA-1に対する最近の攻撃は、その日[SHA-COMMENTS]以前それを取り替えながら、動機づけていません。 これの使用はその日付SHOULDの後に変形します。分析で、長引く適合に関して先行されています。
6.1. Eavesdropping
6.1. 盗聴
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署名認証方法で使用される超能力暗号でその機能を扱わなければなりません。 RSA署名自体によって立ち聞きする者から保護される必要はありません。
6.2. Replay
6.2. 再生
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].
このドキュメントは反射攻撃を扱いません。 望まれているなら、その機能は[超能力]と[AH]で定義されるように超能力とAH一連番号の使用で扱われます。
Weis Standards Track [Page 7] RFC 4359 RSA/SHA-1 Signatures within ESP and AH January 2006
ああ、超能力の中のウィス標準化過程[7ページ]RFC4359RSA/SHA-1署名と2006年1月
6.3. Message Insertion
6.3. メッセージ挿入
This document directly addresses message insertion attacks. Inserted messages will fail authentication and be dropped by the receiver.
このドキュメントは、メッセージ挿入が攻撃であると直接扱います。 挿入されたメッセージは、認証に失敗して、受信機によって下げられるでしょう。
6.4. Deletion
6.4. 削除
This document does not address deletion attacks. It is concerned only with validating the legitimacy of messages that are not deleted.
このドキュメントは、削除が攻撃であると扱いません。 それは削除されないメッセージの合法性を有効にするだけに関係があります。
6.5. Modification
6.5. 変更
This document directly addresses message modification attacks. Modified messages will fail authentication and be dropped by the receiver.
このドキュメントは、メッセージ変更が攻撃であると直接扱います。 変更されたメッセージは、認証に失敗して、受信機によって下げられるでしょう。
6.6. Man in the Middle
6.6. 中央でやれやれ
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係数サイズを選ばなければなりません。
6.7. Denial of Service
6.7. サービス妨害
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処理規則に従って、超能力とAHパケットの受信機は、SAデータベースでSecurity Associationを見上げることによって、始まります。 1つが見つけられるなら、パケットの超能力か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.
超能力かAHパケットが有効なSAをシステムに合わせて、また、有効な一連番号を持っているのをさせる攻撃者は、受信機に超能力か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マルチキャストグループにメッセージを送るなら、パケットを受けたすべてのグループのメンバーは同時に、攻撃される予定でしょうに。
Weis Standards Track [Page 8] RFC 4359 RSA/SHA-1 Signatures within ESP and AH January 2006
ああ、超能力の中のウィス標準化過程[8ページ]RFC4359RSA/SHA-1署名と2006年1月
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.
認証に超能力かAHの中で認証にHMAC変換を使用することでRSA署名を使用しながら、超能力かAHをカプセル化することによって、ほとんどの攻撃者に対してこの攻撃を緩和できます。 この場合、HMAC変換は最初に有効にされるでしょう、そして、攻撃者がHMACキーを所有していない限り、デジタル署名は全く攻撃者パケットの上で評価されないでしょう。 しかしながら、攻撃者がHMACキーを所有しているなら(例えば、攻撃者はSAを使用するグループの正統のメンバーです)、DoS攻撃を緩和できません。
7. IANA Considerations
7. IANA問題
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変換識別子」名で必要です。 ニーモニックは「ああ、_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登録で必要です。 属性のクラスは「認証キー長」と呼ばれるべきです、そして、それはVariableタイプであるべきです。
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:
2番目の「IPSECセキュリティ協会属性」が、RSA署名を通過するのにタイプをコード化しながら、ISAKMP登録で必要です。 属性のクラスは「アルゴリズムをコード化する署名」と呼ばれるべきです、そして、それはBasicタイプであるべきです。 以下の規則は、属性の値を定義するのに当てはまります:
Name Value ---- ----- Reserved 0 RSASSA-PKCS1-v1_5 1 RSASSA-PSS 2
名前値---- ----- 予約された0RSASSA-PKCS1-v1_5 1RSASSA-PSS2
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]で定義されるStandards Actionのため新しい値を加えなければなりません。 値61440-65535は私用のためにあって、それら自身の目的のために実装で割り当てるかもしれません。
Weis Standards Track [Page 9] RFC 4359 RSA/SHA-1 Signatures within ESP and AH January 2006
ああ、超能力の中のウィス標準化過程[9ページ]RFC4359RSA/SHA-1署名と2006年1月
8. Acknowledgements
8. 承認
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とデヴィッド・マグリューは適切な主要なサイズに関するアドバイスを提供しました。 また、スコットFluhrerは主要な生涯に関するアドバイスを提供しました。 イアン・ジャクソン、スティーブ・ケント、およびRanカネッティは多くの役に立つコメントを提供しました。 サム・ハートマン、ラスHousley、およびLakshminth Dondetiはこのドキュメントの開発における貴重な指導を提供しました。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[AH] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[ああ] ケント、S.、「IP認証ヘッダー」、RFC4302、2005年12月。
[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[超能力] ケント、S.、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC4303、2005年12月。
[ISAKMP-REG] http://www.iana.org/assignments/isakmp-registry
[ISAKMP-レッジ] 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.、「Indicate Requirement LevelへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[RFC3552]レスコラ、E.とB.Korver、「セキュリティ問題に関するテキストをRFCに書くためのガイドライン」BCP72、2003年7月のRFC3552。
[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インチ、RFC3447、2月2003日
[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パブ180-2: Secure Hash Standard、8月2002日の http://csrc.nist.gov/ 刊行物/fips/fips180-2/fips180-2.pdfのための仕様。
9.2. Informative References
9.2. 有益な参照
[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におけるガロア/カウンタモード(GCM)の使用」、RFC4106、2005年6月。
[GDOI] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, December 2002.
2002年12月の[GDOI]BaugherとM.とウィスとB.とHardjono、T.とH.ハーニー、「解釈のグループドメイン」RFC3547。
[HMAC-SHA] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.
そして、[HMAC-SHA] マドソン、C.、およびR.グレン、「超能力の中のHMAC-SHA-1-96の使用、ああ、」、RFC2404、11月1998日
Weis Standards Track [Page 10] RFC 4359 RSA/SHA-1 Signatures within ESP and AH January 2006
ああ、超能力の中のウィス標準化過程[10ページ]RFC4359RSA/SHA-1署名と2006年1月
[IKEV2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[IKEV2] コーフマン、C.、「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」、RFC4306、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問題部に書くためのガイドライン」BCP26、RFC2434(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、「急速に回ってください。そうすれば、RSAはサイズを合わせる」RSA研究所Technical Note、 http://www.rsasecurity.com/rsalabs/ node.asp--2004年5月6日、イド=2003。
[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-コメント] NISTは安全な論じ尽くす機能とSHA-1によって提供された継続的なセキュリティに対する最近のCryptanalytic攻撃のコメントに事情を知らせます、8月、2004 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.
[振り回します] 「回転デバイスで大きい数を因数分解し」て、シャミル、A.、およびE.Tromerは進歩、2003年2月9日に働いています。
Author's Address
作者のアドレス
Brian Weis Cisco Systems 170 W. Tasman Drive, San Jose, CA 95134-1706, USA
ブライアンウィスシスコシステムズ170w.タスマンDrive、サンノゼ、カリフォルニア95134-1706、米国
Phone: (408) 526-4796 EMail: bew@cisco.com
以下に電話をしてください。 (408) 526-4796 メールしてください: bew@cisco.com
Weis Standards Track [Page 11] RFC 4359 RSA/SHA-1 Signatures within ESP and AH January 2006
ああ、超能力の中のウィス標準化過程[11ページ]RFC4359RSA/SHA-1署名と2006年1月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントは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 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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 provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Weis Standards Track [Page 12]
ウィス標準化過程[12ページ]
一覧
スポンサーリンク