RFC4982 日本語訳
4982 Support for Multiple Hash Algorithms in CryptographicallyGenerated Addresses (CGAs). M. Bagnulo, J. Arkko. July 2007. (Format: TXT=20961 bytes) (Updates RFC3972) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Bagnulo Request for Comments: 4982 UC3M Updates: 3972 J. Arkko Category: Standards Track Ericsson July 2007
Bagnuloがコメントのために要求するワーキンググループM.をネットワークでつないでください: 4982のUC3Mアップデート: 3972年のJ.Arkkoカテゴリ: 標準化過程エリクソン2007年7月
Support for Multiple Hash Algorithms in Cryptographically Generated Addresses (CGAs)
複数の細切れ肉料理アルゴリズムのサポートは中で暗号でアドレスを作りました。(CGAs)
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 IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
Abstract
要約
This document analyzes the implications of recent attacks on commonly used hash functions on Cryptographically Generated Addresses (CGAs) and updates the CGA specification to support multiple hash algorithms.
このドキュメントは、Cryptographically Generated Addresses(CGAs)で一般的に使用されたハッシュ関数に対する最近の攻撃の含意を分析して、複数の細切れ肉料理アルゴリズムを支持するためにCGA仕様をアップデートします。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Impact of Collision Attacks in CGAs . . . . . . . . . . . . . . 2 4. Options for Multiple Hash Algorithm Support in CGAs . . . . . . 3 4.1. Where to Encode the Hash Function? . . . . . . . . . . . . 4 5. CGA Generation Procedure . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . . 7
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 用語. . . . . . . . . . . . . . . . . . . . . . . . . . 2 3。 衝突の影響はCGAs. . . . . . . . . . . . . . 2 4で攻撃されます。 倍数のためのオプションはCGAs. . . . . . 3 4.1でアルゴリズムサポートを論じ尽くします。 どこで、ハッシュ関数をコード化しますか? . . . . . . . . . . . . 4 5. CGA世代手順. . . . . . . . . . . . . . . . . . . 6 6。 IANA問題. . . . . . . . . . . . . . . . . . . . . . 6 7。 セキュリティ問題. . . . . . . . . . . . . . . . . . . . 7 8。 承認. . . . . . . . . . . . . . . . . . . . . . . 7 9。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1。 引用規格. . . . . . . . . . . . . . . . . . . 7 9.2。 有益な参照. . . . . . . . . . . . . . . . . . 7
Bagnulo & Arkko Standards Track [Page 1] RFC 4982 Multiple Hash Support in CGAs July 2007
Bagnulo&Arkko規格は2007年7月にCGAsで[1ページ]RFC4982倍数細切れ肉料理サポートを追跡します。
1. Introduction
1. 序論
Recent attacks to currently used hash functions have motivated a considerable amount of concern in the Internet community. The recommended approach [6] [10] to deal with this issue is first to analyze the impact of these attacks on the different Internet protocols that use hash functions and second to make sure that the different Internet protocols that use hash functions are capable of migrating to an alternative (more secure) hash function without a major disruption in the Internet operation.
現在中古のハッシュ関数に対する最近の攻撃はインターネットコミュニティで重要なかなりの量を動機づけました。 この問題に対処するお勧めのアプローチ[6][10]はインターネット操作における大きな混乱なしでハッシュ関数を使用する異なったインターネットプロトコルがハッシュ関数であることを確実にするのに代替手段にわたることができる(より安全な)ハッシュ関数と2番目を使用する異なったインターネットプロトコルに対するこれらの攻撃の影響を最初に、分析することになっています。
This document performs such analysis for the Cryptographically Generated Addresses (CGAs) defined in [2]. The first conclusion of the analysis is that the security of the protocols using CGAs is not affected by the recently available attacks against hash functions. The second conclusion of the analysis is that the hash function used is hard coded in the CGA specification. This document updates the CGA specification [2] to enable the support of alternative hash functions. In order to do so, this document creates a new registry managed by IANA to register the different hash algorithms used in CGAs.
このドキュメントは[2]で定義されたCryptographically Generated Addresses(CGAs)のためにそのような分析を実行します。 分析の最初の結論はCGAsを使用するプロトコルのセキュリティがハッシュ関数に対する最近利用可能な攻撃で影響を受けないということです。 分析の2番目の結論は使用されるハッシュ関数がCGA仕様でコード化されていた状態で困難であるということです。 このドキュメントは、代替のハッシュ関数のサポートを可能にするためにCGA仕様[2]をアップデートします。 そうして、このドキュメントは、CGAsで使用される異なった細切れ肉料理アルゴリズムを登録するためにIANAによって管理された新しい登録を作成します。
2. Terminology
2. 用語
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 RFC 2119 [1].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[1]で説明されるように本書では解釈されることであるべきですか?
3. Impact of Collision Attacks in CGAs
3. CGAsでの衝突攻撃の影響
Recent advances in cryptography have resulted in simplified attacks against the collision-free property of certain commonly used hash functions [6] [10], including SHA-1 that is the hash function used by CGAs [2]. The result is that it is possible to obtain two messages, M1 and M2, that have the same hash value with much less than 2^(L/2) attempts. We will next analyze the impact of such attacks in the currently proposed usages of CGAs.
暗号における最近の進歩はある一般的に使用されたハッシュ関数[6][10]の無衝突の特性に対する簡易型の攻撃をもたらしました、CGAs[2]によって使用されたハッシュ関数であるSHA-1を含んでいて。 結果が2つのメッセージ、M1、およびM2を入手するのが可能であるということである、それには、はるかに2未満^(L/2)試みがある同じハッシュ値があります。 私たちは次に、CGAsの現在提案された使用法によるそのような攻撃の影響を分析するために望んでいます。
As we understand it, the attacks against the collision-free property of a hash function mostly challenge the application of such hash functions, for the provision of non-repudiation capabilities. This is because an attacker would be capable to create two different messages that result in the same hash value and it can then present any of the messages interchangeably (for example after one of them has been signed by the other party involved in the transaction). However, it must be noted that both messages must be generated by the same party.
私どもが理解しているところではそれ、ハッシュ関数の無衝突の特性に対する攻撃はそのようなハッシュ関数の適用にほとんど挑戦します、非拒否能力の支給のために。 攻撃者は次に、メッセージのどれかを提示できるという2つの異なったメッセージを互換性を持って、作成できるでしょう(例えば、それらの1つがもう片方の取引の当事者によって取引にサインされた後に)、したがって、これはそうです。 しかしながら、両方のメッセージが同じパーティーによって発生しなければならないことに注意しなければなりません。
Bagnulo & Arkko Standards Track [Page 2] RFC 4982 Multiple Hash Support in CGAs July 2007
Bagnulo&Arkko規格は2007年7月にCGAsで[2ページ]RFC4982倍数細切れ肉料理サポートを追跡します。
As far as we understand, current usages of CGAs does not include the provision of non-repudiation capabilities, so attacks against the collision-free property of the hash function do not enable any useful attack against CGA-based protocols.
私たちが分かる限り、CGAsの現在の使用法が非拒否能力の支給を含んでいないので、ハッシュ関数の無衝突の特性に対する攻撃はCGAベースのプロトコルに対して少しの役に立つ攻撃も可能にしません。
Current usages of the CGAs are basically oriented to prove the ownership of a CGA and then bind it to alternative addresses that can be used to reach the original CGA. This type of application of the CGA include:
CGAsの現在の使用法は、オリジナルのCGAに達するようにCGAの所有権を立証して、次に、使用できる代替アドレスにそれを縛るために基本的に適応します。 このタイプのCGAの適用は:
o The application of CGAs to protect the shim6 protocol [7]. In this case, CGAs are used as identifiers for the established communications. CGA features are used to prove that the owner of the identifier is the one that is providing the alternative addresses that can be used to reach the initial identifier. This is achieved by signing the list of alternative addresses available in the multihomed host with the private key of the CGA.
o shim6プロトコル[7]を保護するCGAsのアプリケーション。 この場合、CGAsは確立したコミュニケーションに識別子として使用されます。 CGAの特徴は、識別子の所有者が初期の識別子に達するのに使用できる代替アドレスを提供しているものであると立証するのに使用されます。 これは、「マルチ-家へ帰」っているホストでCGAの秘密鍵で利用可能な代替アドレスのリストにサインすることによって、達成されます。
o The application of CGAs to secure the IPv6 mobility support protocol [8] as proposed in [9]. In this case, the CGAs are used as Home Addresses and they are used to prove that the owner of the Home Address is the one creating the binding with the new Care-off Address. Similarly to the previous case, this is achieved by signing the Binding Update message carrying the Care-off Address with the private key of the CGA.
o [8] [9]で提案されるようにIPv6移動性サポートプロトコルを保証するCGAsのアプリケーション。 この場合、CGAsはホームAddressesとして使用されます、そして、彼らは、ホームAddressの所有者が新しい下にCare Addressとの結合を作成するものであると立証するのに使用されます。 同様に、先の事件に、これは、CGAの秘密鍵で下にCare Addressを運びながらBinding Updateメッセージにサインすることによって、達成されます。
o The application of CGA to Secure Neighbour Discovery [4]. In this case, the CGA features are used to prove the address ownership, so that it is possible to verify that the owner of the IP address is the one that is providing the layer 2 address information. This is achieved by signing the layer 2 address information with the private key of the CGA.
o Secure Neighbourディスカバリー[4]へのCGAのアプリケーション。 この場合、CGAの特徴はアドレス所有権を立証するのに使用されます、IPアドレスの所有者が2アドレス情報を層に供給しているものであることを確かめるのが可能であるように。 これは、層2のアドレス情報とCGAの秘密鍵を契約することによって、達成されます。
Essentially, all the current applications of CGAs rely on CGAs to protect a communication between two peers from third party attacks and not to provide protection from the peer itself. Attacks against the collision-free property of the hash functions suppose that one of the parties is generating two messages with the same hash value in order to launch an attack against its communicating peer. Since CGAs are not currently used to providing this type of protection, it is then natural that no additional attacks are enabled by a weaker collision resistance of the hash function.
本質的には、CGAsのすべての現在のアプリケーションが、第三者攻撃から2人の同輩のコミュニケーションを保護して、同輩自身から保護を提供しないようにCGAsを当てにします。 ハッシュ関数の無衝突の特性に対する攻撃は、パーティーのひとりが同輩を伝えないように攻撃を開始するために同じハッシュ値で2つのメッセージを発生させていると思います。 CGAsが現在このタイプの保護を提供するのに使用されないので、どんな追加攻撃もハッシュ関数の、より弱い衝突抵抗で可能にされないのは、その時、当然です。
4. Options for Multiple Hash Algorithm Support in CGAs
4. CGAsでの複数の細切れ肉料理アルゴリズムサポートのためのオプション
CGAs, as currently defined in [2], are intrinsically bound to the SHA-1 hash algorithm and no other hash function is supported.
現在[2]で定義されるCGAsは本質的にSHA-1細切れ肉料理アルゴリズムに縛られます、そして、他のハッシュ関数は全く支持されません。
Bagnulo & Arkko Standards Track [Page 3] RFC 4982 Multiple Hash Support in CGAs July 2007
Bagnulo&Arkko規格は2007年7月にCGAsで[3ページ]RFC4982倍数細切れ肉料理サポートを追跡します。
Even though the attacks against the collision-free property of the hash functions do not result in new vulnerabilities in the current applications of CGAs, it seems wise to enable multiple hash function support in CGAs. This is mainly for two reasons: first, potential future applications of the CGA technology may be susceptible to attacks against the collision-free property of SHA-1. Supporting alternative hash functions would allow applications that have stricter requirements on the collision-free property to use CGAs. Second, one lesson learned from the recent attacks against hash functions is that it is possible that one day we need to start using alternative hash functions because of successful attacks against other properties of the commonly used hash functions. Therefore, it seems wise to modify protocols in general and the CGAs in particular to support this transition to alternative hash functions as easy as possible.
ハッシュ関数の無衝突の特性に対する攻撃はCGAsの現在のアプリケーションにおける新しい脆弱性をもたらしませんが、CGAsでの複数のハッシュ関数サポートを可能にするのは賢明に思えます。 これは主に2つの理由であります: まず最初に、CGA技術の潜在的将来のアプリケーションはSHA-1の無衝突の特性に対する攻撃に影響されやすいかもしれません。 代替のハッシュ関数を支持するのに、無衝突の所有地に関する、より厳しい要件を持っているアプリケーションはCGAsを使用できるでしょう。 2番目に、ハッシュ関数に対して最近の攻撃から学習された1つのレッスンはある日私たちが、うまくいっている攻撃のために一般的に使用されたハッシュ関数の他の特性に対して代替のハッシュ関数を使用し始める必要があるのが、可能であるということです。 したがって、代替のハッシュ関数へのこの変遷をできるだけたやすく支持するように一般に、プロトコルと特にCGAsを変更するのは賢明に思えます。
4.1. Where to Encode the Hash Function?
4.1. どこで、ハッシュ関数をコード化しますか?
The next question we need to answer is where to encode the hash function that is being used. There are several options that can be considered:
私たちが、答える必要があるという次の質問はどこで使用されているハッシュ関数をコード化するかということです。 考えることができるいくつかのオプションがあります:
One option would be to include the hash function used as an input to the hash function. This basically means to create an extension to the CGA Parameter Data Structure, as defined in [3], that codifies the hash function used. The problem is that this approach is vulnerable to bidding down attacks or downgrading attacks as defined in [10]. This means that even if a strong hash function is used, an attacker could find a CGA Parameter Data Structure that uses a weaker function but results in an equal hash value. This happens when the original hash function H1 and CGA Parameters Data Structure indicating H1 result in value X, and another hash function H2 and CGA Parameters Data Structure indicating H2 also result in the same value X.
1つのオプションは入力としてハッシュ関数に使用されるハッシュ関数を含むだろうことです。 これは、[3]で定義されるように拡大をCGA Parameter Data Structureに作成することを基本的に意味して、それは使用されるハッシュ関数を成文化します。 問題はこのアプローチを攻撃の下側に入札するのに傷つきやすいか[10]で定義されるように攻撃を格下げするということです。 これは、強いハッシュ関数が使用されていても、攻撃者が等しいハッシュ値により弱い機能にもかかわらず、結果を使用するCGA Parameter Data Structureを見つけるかもしれないことを意味します。 元のハッシュ関数H1とH1を示すCGA Parameters Data Structureが値Xをもたらすと、これは起こります、そして、また、別のハッシュ関数H2とH2を示すCGA Parameters Data Structureが同じ値Xをもたらします。
In other words, the downgrading attack would work as follows: suppose that Alice generates a CGA CGA_A using the strong hash function HashStrong and using a CGA Parameter Data Structure CGA_PDS_A. The selected hash function HashStrong is encoded as an extension field in the CGA_PDS_A. Suppose that by using a brute force attack, an attacker X finds an alternative CGA Parameter Data Structure CGA_PDS_X whose hash value, by using a weaker hash function, is CGA_A. At this point, the attacker can pretend to be the owner of CGA_A and the stronger hash function has not provided additional protection.
言い換えれば、格下げ攻撃は以下の通り働いているでしょう: アリスが強いハッシュ関数HashStrongを使用して、CGA Parameter Data Structure CGA_PDSを使用することでCGA CGAを発生させると仮定してください。 選択されたハッシュ関数HashStrongはCGA_PDSの拡大分野としてコード化されます。 総当たり攻撃を使用することによって、攻撃者Xが、代替のCGA Parameter Data Structure CGAが、より弱いハッシュ関数を使用することによってハッシュ値がCGAである_PDS_Xであることがわかると仮定してください。 ここに、攻撃者は、CGAの所有者であるふりをすることができます、そして、より強いハッシュ関数は追加保護を前提としていません。
The conclusion from the previous analysis is that the hash function used in the CGA generation must be encoded in the address itself.
前の分析からの結論はアドレス自体でCGA世代に使用されるハッシュ関数をコード化しなければならないということです。
Bagnulo & Arkko Standards Track [Page 4] RFC 4982 Multiple Hash Support in CGAs July 2007
Bagnulo&Arkko規格は2007年7月にCGAsで[4ページ]RFC4982倍数細切れ肉料理サポートを追跡します。
Since we want to support several hash functions, we will likely need at least 2 or 3 bits for this.
いくつかのハッシュ関数を支持したいと思うので、私たちはおそらく少なくとも2か3ビットをこれに必要とするでしょう。
One option would be to use more bits from the hash bits of the interface identifier. However, the problem with this approach is that the resulting CGA is weaker because less hash information is encoded in the address. In addition, since those bits are currently used as hash bits, it is impossible to make this approach backward compatible with existent implementations.
1つのオプションはインタフェース識別子の細切れ肉料理ビットからの、より多くのビットを使用するだろうことです。 しかしながら、このアプローチに関する問題は、より少ない細切れ肉料理情報がアドレスでコード化されるので結果として起こるCGAが、より弱いということです。 さらに、それらのビットが現在細切れ肉料理ビットとして使用されるので、それは後方に目下の実現と互換性があった状態でこのアプローチをするのが不可能です。
Another option would be to use the "u" and the "g" bits to encode this information, but this is probably not such a good idea since those bits have been honoured so far in all interface identifier generation mechanisms, which allow them to be used for the original purpose (for instance we can still create a global registry for unique interface identifiers). Finally, another option is to encode the hash value used in the Sec bits. The Sec bits are used to artificially introduce additional difficulty in the CGA generation process in order to provide additional protection against brute force attacks. The Sec bits have been designed in a way that the lifetime of CGAs are extended, when it is feasible to attack 59-bits long hash values. However, this is not the case today, so in general CGA will have a Sec value of 000. The proposal is to encode in the Sec bits, not only information about brute force attack protection but also to encode the hash function used to generate the hash. So for instance, the Sec value 000 would mean that the hash function used is SHA-1 and the 0 bits of hash2 (as defined in RFC 3972) must be 0. Sec value of 001 could be that the hash function used is SHA-1 and the 16 bits of hash2 (as defined in RFC 3972) must be zero. However, the other values of Sec could mean that an alternative hash function needs to be used and that a certain amount of bits of hash2 must be zero. The proposal is not to define any concrete hash function to be used for other Sec values, since it is not yet clear that we need to do so nor is it clear which hash function should be selected.
別のオプションがこの情報をコード化するのに「u」と「g」ビットを使用するだろうことですが、それらのビットが今までのところすべてのインタフェース識別子世代メカニズム(それらが初心に使用されるのを許容する)で尊敬されたので(例えば、私たちはまだユニークなインタフェース識別子のためのグローバルな登録を作成できます)、これはたぶんそのような名案ではありません。 最終的に、別のオプションはSecビットで使用されるハッシュ値をコード化することです。 Secビットは、総当たり攻撃に対する追加保護を提供するために人工的にCGA発生経過における追加困難を導入するのに使用されます。 SecビットはCGAsの寿命が拡張されている方法で設計されています、59ビットの長いハッシュ値を攻撃するのが可能であるときに。 しかしながら、今日これがそうでないので、CGAには、一般に、000のSec値があるでしょう。 総当たり攻撃保護の情報だけではなく、Secビットのエンコードには提案がありますが、ハッシュ関数をコード化するのは以前は細切れ肉料理をよく発生させてもいましたも。 あまりに例えば、Sec値000は、使用されるハッシュ関数がSHA-1であることを意味するでしょう、そして、hash2(RFC3972で定義されるように)の0ビットは0であるに違いありません。 001の値が使用されるハッシュ関数がSHA-1とhash2の16ビット(RFC3972で定義されるように)であるということであるかもしれない秒はゼロであるに違いありません。 しかしながら、Secの他の値は代替のハッシュ関数が、使用される必要があって、hash2のある量のビットがゼロであるに違いないことを意味するかもしれません。 提案は他のSec値に使用されるために少しの具体的なハッシュ関数も定義しないことです、私たちが、そうする必要があって、それがどのハッシュ関数が選択されるべきであるかが明確でないことが、まだ明確でないので。
Note that since there are only 8 Sec values, it may be necessary to reuse Sec values when we run out of unused Sec values. The scenario where such an approach makes sense is where there are some Sec values that are no longer being used because the resulting security has become weak. In this case, where the usage of the Sec value has long been abandoned, it would be possible to reassign the Sec values. However, this must be a last resource option, since it may affect interoperability. This is because two implementations using different meanings of a given Sec value would not be able to interoperate properly (i.e., if an old implementation receives a CGA generated with the new meaning of the Sec value, it will fail and the same for a new implementation receiving a CGA generated with the old meaning of the Sec value). In case the approach of reassigning a Sec
8つのSec値しかないので、私たちが未使用のSec値を使い果たすとき、Sec値を再利用するのが必要であるかもしれないことに注意してください。 そのようなアプローチが理解できるシナリオは結果として起こるセキュリティが弱くなったのでもう使用されていないいくつかのSec値があるところです。 この場合、Sec価値の用法が長い間捨てられているところでSec値を再選任するのは可能でしょう。 しかしながら、相互運用性に影響するかもしれないので、これは最後の手段オプションであるに違いありません。 与えられたSec価値の異なった意味を使用する2つの実現は適切に共同利用できないでしょう(すなわち、古い実現がSec価値の新しい意味で発生するCGAを受けて、失敗して、CGAを受ける新しい実現のための同じくらいが老人でSec価値の意味を発生させたなら)、したがって、これはそうです。 場合における、Secを再選任するアプローチ
Bagnulo & Arkko Standards Track [Page 5] RFC 4982 Multiple Hash Support in CGAs July 2007
Bagnulo&Arkko規格は2007年7月にCGAsで[5ページ]RFC4982倍数細切れ肉料理サポートを追跡します。
value is followed, a long time is required between the deprecation of the old value and the reassignment in order to prevent misinterpretation of the value by old implementations.
値に続かれていて、長い時間が、古い実現による価値の誤解を防ぐのに古い価値の不賛成と再割当ての間で必要です。
An erroneous interpretation of a reused Sec value, both on the CGA owner's side and the CGA verifier's side, would have the following result, CGA verification would fail in the worst case and both nodes would have to revert to unprotected IPv6 addresses. This can happen only with obsolete CGA parameter sets, which would be considered insecure anyway. In any case, an implementation must not simultaneously support two different meanings of a Sec value.
CGA所有者の側とCGA検証の側における再利用されたSec価値の誤った解釈には、以下の結果があるでしょう、そして、CGA検証は最悪の場合には失敗するでしょう、そして、両方のノードは保護のないIPv6アドレスに戻らなければならないでしょう。 これは単に時代遅れのCGAパラメタセットで起こることができます。(セットはとにかく不安定な状態で考えられるでしょう)。 どのような場合でも、実現は同時に、Sec価値の2つの異なった意味を支持してはいけません。
5. CGA Generation Procedure
5. CGA世代手順
The SEC registry defined in the IANA considerations section of this document contains entries for the different Sec values. Each of these entries points to an RFC that defines the CGA generation procedure that MUST be used when generating CGAs with the associated Sec value.
このドキュメントのIANA問題部で定義されたSEC登録は異なったSec値のためのエントリーを含んでいます。 それぞれのこれらのエントリーは関連Sec値でCGAsを発生させるとき用いなければならないCGA世代手順を定義するRFCを示します。
It should be noted that the CGA generation procedure may be changed by the new procedure not only in terms of the hash function used but also in other aspects, e.g., longer Modifier values may be required if the number of 0s required in hash2 exceed the currently defined bound of 112 bits. The new procedure (which potentially involves a longer Modifier value) would be described in the RFC pointed to by the corresponding Sec registry entry.
CGA世代手順が使用されるハッシュ関数で変えられるだけではなく、他の局面でも新しい手順によって変えられるかもしれないことに注意されるべきであり、例えば、hash2で必要である0の数が112ビットの現在定義されたバウンドを超えるなら、より長いModifier値が必要であるかもしれません。 新しい手順(潜在的により長いModifier値を伴う)は対応するSec登録エントリーで示されたRFCで説明されるでしょう。
In addition, the RFC that defines the CGA generation procedure for a Sec value MUST explicitly define the minimum key length acceptable for CGAs with that Sec value. This is to provide a coherent protection both in the hash and the public key techniques.
さらに、Sec値のためにCGA世代手順を定義するRFCは明らかにCGAsにおいて、そのSec値で許容できる最小のキー長を定義しなければなりません。 これは、細切れ肉料理と公開鍵のテクニックに一貫性を持っている保護を供給するためのものです。
6. IANA Considerations
6. IANA問題
This document defines a new registry entitled "CGA SEC" for the Sec field defined in RFC 3972 [2] that has been created and is maintained by IANA. The values in this name space are 3-bit unsigned integers.
このドキュメントは作成されて、IANAによって維持されるRFC3972[2]で定義された新しい登録秒のための題している「CGA SEC」分野を定義します。 この名前スペースの値は3ビットの符号のない整数です。
Initial values for the CGA Extension Type field are given below; future assignments are to be made through Standards Action [5]. Assignments consist of a name, the value, and the RFC number where the CGA generation procedure is defined.
CGA Extension Type分野への初期の値を以下に与えます。 将来の課題はStandards Action[5]を通して作られていることです。 CGA世代手順が定義されるところで課題は名前、値、およびRFC番号から成ります。
Bagnulo & Arkko Standards Track [Page 6] RFC 4982 Multiple Hash Support in CGAs July 2007
Bagnulo&Arkko規格は2007年7月にCGAsで[6ページ]RFC4982倍数細切れ肉料理サポートを追跡します。
The following initial values are assigned in this document:
以下の初期の値は本書では割り当てられます:
Name | Value | RFCs -------------------+-------+------------ SHA-1_0hash2bits | 000 | 3972, 4982 SHA-1_16hash2bits | 001 | 3972, 4982 SHA-1_32hash2bits | 010 | 3972, 4982
名前| 値| RFCs-------------------+-------+------------ SHA-1_0hash2bits| 000 | 3972、4982SHA-1_16hash2bits| 001 | 3972、4982SHA-1_32hash2bits| 010 | 3972, 4982
7. Security Considerations
7. セキュリティ問題
This document is about security issues and, in particular, about protection against potential attacks against hash functions.
このドキュメントはハッシュ関数に対する安全保障問題と起こり得るかもしれない攻撃に対する特に保護に関するものです。
8. Acknowledgements
8. 承認
Russ Housley, James Kempf, Christian Vogt, Pekka Nikander, and Henrik Levkowetz reviewed and provided comments about this document.
ラスHousley、ジェームス・ケンフ、クリスチャンのフォークト、ペッカNikander、およびHenrik Levkowetzはこのドキュメントに関してコメントを見直して、提供しました。
Marcelo Bagnulo worked on this document while visiting Ericsson Research Laboratory Nomadiclab.
マルセロBagnuloはエリクソン研究所Nomadiclabを訪問している間、このドキュメントに取り組みました。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[2] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
[2] 香気(T.)が「暗号で、アドレス(CGA)を作った」、RFC3972、3月2005日
[3] Bagnulo, M. and J. Arkko, "Cryptographically Generated Addresses (CGA) Extension Field Format", RFC 4581, October 2006.
[3]BagnuloとM.とJ.Arkko、「暗号で、生成アドレス(CGA)拡大は形式をさばく」RFC4581、2006年10月。
[4] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[4]ArkkoとJ.とケンフとJ.とZill、B.とP.Nikander、「安全な隣人発見(発信する)」、RFC3971、2005年3月。
9.2. Informative References
9.2. 有益な参照
[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[5]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[6] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes in Internet Protocols", RFC 4270, November 2005.
[6] ホフマンとP.とB.シュナイアー、「暗号に対する攻撃はインターネットでプロトコルを論じ尽くす」RFC4270、2005年11月。
Bagnulo & Arkko Standards Track [Page 7] RFC 4982 Multiple Hash Support in CGAs July 2007
Bagnulo&Arkko規格は2007年7月にCGAsで[7ページ]RFC4982倍数細切れ肉料理サポートを追跡します。
[7] Nordmark, E. and M. Bagnulo, "Multihoming L3 Shim Approach", Work in Progress, July 2005.
[7] 「マルチホーミングL3詰め物のアプローチ」というNordmark、E.、およびM.Bagnuloは進歩、2005年7月に働いています。
[8] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[8] ジョンソンとD.とパーキンス、C.とJ.Arkko、「IPv6"、RFC3775、2004年6月の移動性サポート。」
[9] Arkko, J., "Applying Cryptographically Generated Addresses and Credit-Based Authorization to Mobile IPv6", Work in Progress, June 2006.
[9] Arkko、J.、「暗号で生成アドレスとクレジットベースの認可をモバイルIPv6"に適用して、進歩、2006年6月に働いてください。」
[10] Bellovin, S. and E. Rescorla, "Deploying a New Hash Algorithm", NDSS '06, February 2006.
[10]BellovinとS.とE.レスコラ、「新しい細切れ肉料理アルゴリズムを配備します」、NDSS'06、2006年2月'。
Authors' Addresses
作者のアドレス
Marcelo Bagnulo Universidad Carlos III de Madrid Av. Universidad 30 Leganes, Madrid 28911 SPAIN
マルセロBagnulo UniversidadカルロスIII deマドリードAv。 Universidad30マドリード28911レガネス(スペイン)
Phone: 34 91 6249500 EMail: marcelo@it.uc3m.es URI: http://www.it.uc3m.es
以下に電話をしてください。 34 91 6249500はメールされます: marcelo@it.uc3m.es ユリ: http://www.it.uc3m.es
Jari Arkko Ericsson Jorvas 02420 Finland
ヤリArkkoエリクソンJorvas02420フィンランド
EMail: jari.arkko@ericsson.com
メール: jari.arkko@ericsson.com
Bagnulo & Arkko Standards Track [Page 8] RFC 4982 Multiple Hash Support in CGAs July 2007
Bagnulo&Arkko規格は2007年7月にCGAsで[8ページ]RFC4982倍数細切れ肉料理サポートを追跡します。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Bagnulo & Arkko Standards Track [Page 9]
Bagnulo&Arkko標準化過程[9ページ]
一覧
スポンサーリンク