RFC3972 日本語訳
3972 Cryptographically Generated Addresses (CGA). T. Aura. March 2005. (Format: TXT=51473 bytes) (Updated by RFC4581, RFC4982) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group T. Aura Request for Comments: 3972 Microsoft Research Category: Standards Track March 2005
コメントを求めるワーキンググループT.香気要求をネットワークでつないでください: 3972年のマイクロソフト研究カテゴリ: 2005年の標準化過程行進
Cryptographically Generated Addresses (CGA)
アドレスであると暗号で生成されます。(CGA)
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 (2004).
Copyright(C)インターネット協会(2004)。
Abstract
要約
This document describes a method for binding a public signature key to an IPv6 address in the Secure Neighbor Discovery (SEND) protocol. Cryptographically Generated Addresses (CGA) are IPv6 addresses for which the interface identifier is generated by computing a cryptographic one-way hash function from a public key and auxiliary parameters. The binding between the public key and the address can be verified by re-computing the hash value and by comparing the hash with the interface identifier. Messages sent from an IPv6 address can be protected by attaching the public key and auxiliary parameters and by signing the message with the corresponding private key. The protection works without a certification authority or any security infrastructure.
このドキュメントはSecure Neighborディスカバリー(SEND)プロトコルのIPv6アドレスに主要な公共の署名を縛るためのメソッドを説明します。 暗号で、Generated Addresses(CGA)はインタフェース識別子が公開鍵と補助のパラメタから暗号の一方向ハッシュ関数を計算することによって生成されるIPv6アドレスです。 ハッシュ値を再計算して、インタフェース識別子とハッシュを比べることによって、公開鍵とアドレスの間の結合について確かめることができます。 公開鍵と補助のパラメタを添付して、対応する秘密鍵をメッセージと契約することによって、IPv6アドレスから送られたメッセージは保護できます。 保護は証明権威か少しもセキュリティインフラストラクチャなしで働いています。
Aura Standards Track [Page 1] RFC 3972 Cryptographically Generated Addresses March 2005
2005年3月にアドレスであると暗号で生成された香気標準化過程[1ページ]RFC3972
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. CGA Format . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. CGA Parameters and Hash Values . . . . . . . . . . . . . . . . 5
4. CGA Generation . . . . . . . . . . . . . . . . . . . . . . . . 6
5. CGA Verification . . . . . . . . . . . . . . . . . . . . . . . 9
6. CGA Signatures . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7.1. Security Goals and Limitations . . . . . . . . . . . . . 12
7.2. Hash Extension . . . . . . . . . . . . . . . . . . . . . 13
7.3. Privacy Considerations . . . . . . . . . . . . . . . . . 15
7.4. Related Protocols . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendices . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
A. Example of CGA Generation. . . . . . . . . . . . . . . . . 20
B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21
Full Copyright Statements. . . . . . . . . . . . . . . . . . . . . 22
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 CGAは.3 3をフォーマットします。 CGAパラメタとハッシュ値. . . . . . . . . . . . . . . . 5 4。 CGA世代. . . . . . . . . . . . . . . . . . . . . . . . 6 5。 CGA検証. . . . . . . . . . . . . . . . . . . . . . . 9 6。 CGA署名. . . . . . . . . . . . . . . . . . . . . . . . 10 7。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 12 7.1。 セキュリティ目標と制限. . . . . . . . . . . . . 12 7.2。 拡大. . . . . . . . . . . . . . . . . . . . . 13 7.3を論じ尽くしてください。 プライバシー問題. . . . . . . . . . . . . . . . . 15 7.4。 関連プロトコル. . . . . . . . . . . . . . . . . . . 15 8。 IANA問題. . . . . . . . . . . . . . . . . . . . . 16 9。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.1。 引用規格. . . . . . . . . . . . . . . . . . 17 9.2。 CGA世代に関する有益な参照. . . . . . . . . . . . . . . . . 18付録. . . . . . . . . . . . . . . . . . . . . . . . . . . . 20A.の例。 . . . . . . . . . . . . . . . . 20 B.承認. . . . . . . . . . . . . . . . . . . . . 21作者の.21のアドレスの完全な著作権宣言文。 . . . . . . . . . . . . . . . . . . . . 22
1. Introduction
1. 序論
This document specifies a method for securely associating a cryptographic public key with an IPv6 address in the Secure Neighbor Discovery (SEND) protocol [RFC3971]. The basic idea is to generate the interface identifier (i.e., the rightmost 64 bits) of the IPv6 address by computing a cryptographic hash of the public key. The resulting IPv6 address is called a cryptographically generated address (CGA). The corresponding private key can then be used to sign messages sent from the address. An introduction to CGAs and their application to SEND can be found in [Aura03] and [AAKMNR02].
このドキュメントはしっかりとSecure Neighborディスカバリー(SEND)プロトコル[RFC3971]のIPv6アドレスに暗号の公開鍵を関連づけるためのメソッドを指定します。 基本的な考え方はインタフェース識別子がIPv6アドレスの(すなわち、一番右の64ビット)であると公開鍵の暗号のハッシュを計算することによって生成することです。 結果として起こるIPv6アドレスはアドレス(CGA)であると暗号で生成されたaと呼ばれます。 そして、アドレスから送られたメッセージに署名するのに対応する秘密鍵を使用できます。 [Aura03]と[AAKMNR02]でCGAsへの紹介とSENDへの彼らの法則を見つけることができます。
This document specifies:
このドキュメントは指定します:
o how to generate a CGA from the cryptographic hash of a public key
and auxiliary parameters,
o 公開鍵と補助のパラメタの暗号のハッシュからCGAを生成する方法
o how to verify the association between the public key and the CGA,
and
o そしてどう公開鍵とCGAとの協会について確かめるか。
o how to sign a message sent from the CGA, and how to verify the
signature.
o どうCGAから送られたメッセージに署名するか、そして、どう署名について確かめるか。
Aura Standards Track [Page 2] RFC 3972 Cryptographically Generated Addresses March 2005
2005年3月にアドレスであると暗号で生成された香気標準化過程[2ページ]RFC3972
To verify the association between the address and the public key, the verifier needs to know the address itself, the public key, and the values of the auxiliary parameters. The verifier can then go on to verify messages signed by the owner of the public key (i.e., the address owner). No additional security infrastructure, such as a public key infrastructure (PKI), certification authorities, or other trusted servers, is needed.
アドレスと公開鍵との協会について確かめるために、検証は、アドレス自体、公開鍵、および補助のパラメタの値を知る必要があります。 そして、検証は、公開鍵(すなわち、アドレス所有者)の所有者によって署名されたメッセージについて確かめ続けることができます。 公開鍵認証基盤などの追加担保インフラストラクチャ(PKI)(証明当局、または他の信じられたサーバ)は、全く必要ではありません。
Note that because CGAs themselves are not certified, an attacker can create a new CGA from any subnet prefix and its own (or anyone else's) public key. However, the attacker cannot take a CGA created by someone else and send signed messages that appear to come from the owner of that address.
CGAs自身が公認されないので攻撃者がどんなサブネット接頭語とそれ自身(または、他の誰のものも)の公開鍵からも新しいCGAを作成できることに注意してください。 しかしながら、攻撃者は、そのアドレスの所有者から来るために他の誰かによって作成されたCGAを取って、現れる署名しているメッセージを送ることができません。
The address format and the CGA parameter format are defined in Sections 2 and 3. Detailed algorithms for generating addresses and for verifying them are given in Sections 4 and 5, respectively. Section 6 defines the procedures for generating and verifying CGA signatures. The security considerations in Section 7 include limitations of CGA-based security, the reasoning behind the hash extension technique that enables effective hash lengths above the 64-bit limit of the interface identifier, the implications of CGAs on privacy, and protection against related-protocol attacks.
アドレス形式とCGAパラメタ書式はセクション2と3で定義されます。 セクション4と5でそれぞれアドレスを作って、それらについて確かめるための詳細なアルゴリズムを与えます。 セクション6はCGA署名を生成して、確かめるための手順を定義します。 セクション7のセキュリティ問題はインタフェース識別子の64ビットの限界、プライバシーのCGAsの含意、および関連するプロトコル攻撃に対する保護を超えて有効なハッシュの長さを可能にするハッシュ拡大のテクニックの後ろにCGAベースのセキュリティ、推理の制限を含んでいます。
In this document, the key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as described in [RFC2119].
本書では、キーワードが解釈しなければならない、[RFC2119]で説明されるようにNOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、5月、およびOPTIONALを解釈することになっていなければなりませんか?
2. CGA Format
2. CGA形式
When talking about addresses, this document refers to IPv6 addresses in which the leftmost 64 bits of a 128-bit address form the subnet prefix and the rightmost 64 bits of the address form the interface identifier [RFC3513]. We number the bits of the interface identifier starting from bit zero on the left.
アドレスに関して話すとき、このドキュメントは128ビットのアドレスの一番左64ビットがサブネット接頭語を形成して、アドレスの一番右の64ビットがインタフェース識別子[RFC3513]を形成するIPv6アドレスを示します。 私たちは左のビットゼロから始めるインタフェース識別子のビットに付番します。
A cryptographically generated address (CGA) has a security parameter (Sec) that determines its strength against brute-force attacks. The security parameter is a three-bit unsigned integer, and it is encoded in the three leftmost bits (i.e., bits 0 - 2) of the interface identifier. This can be written as follows:
アドレス(CGA)であると暗号で生成されたAは全数探索法に対して強さを測定するセキュリティパラメタ(秒)を持っています。 セキュリティパラメタは3ビットの符号のない整数です、そして、それはインタフェース識別子の一番左3ビット(すなわち、ビット0--2)でコード化されます。 以下の通りこれを書くことができます:
Sec = (interface identifier & 0xe000000000000000) >> 61
秒=(インタフェース識別子と0xe000000000000000)の>>61
Aura Standards Track [Page 3] RFC 3972 Cryptographically Generated Addresses March 2005
2005年3月にアドレスであると暗号で生成された香気標準化過程[3ページ]RFC3972
The CGA is associated with a set of parameters that consist of a public key and auxiliary parameters. Two hash values Hash1 (64 bits) and Hash2 (112 bits) are computed from the parameters. The formats of the public key and auxiliary parameters, and the way to compute the hash values, are defined in Section 3.
CGAは1セットの公開鍵から成るパラメタと補助のパラメタに関連しています。 2ハッシュの値のHash1(64ビット)とHash2(112ビット)はパラメタから計算されます。 公開鍵と補助のパラメタの書式、およびハッシュ値を計算する方法はセクション3で定義されます。
A cryptographically generated address is defined as an IPv6 address that satisfies the following two conditions:
アドレスであると暗号で生成されたAは以下の2つの条件を満たすIPv6アドレスと定義されます:
o The first hash value, Hash1, equals the interface identifier of
the address. Bits 0, 1, 2, 6, and 7 (i.e., the bits that encode
the security parameter Sec and the "u" and "g" bits from the
standard IPv6 address architecture format of interface identifiers
[RFC3513]) are ignored in the comparison.
o 最初のハッシュ値(Hash1)はアドレスに関するインタフェース識別子と等しいです。 ビット0、1、2、6、および7(インタフェース識別子[RFC3513]の標準のIPv6アドレス体系形式からのすなわち、セキュリティパラメタSecをコード化するビットと「u」と「g」ビット)は比較で無視されます。
o The 16*Sec leftmost bits of the second hash value, Hash2, are
zero.
o 2番目のハッシュの一番左ビットが評価する16*秒、Hash2はゼロです。
The above definition can be stated in terms of the following two bit masks:
以下の2ビットのマスクに関して上の定義を述べることができます:
Mask1 (64 bits) = 0x1cffffffffffffff
Mask1(64ビット)は0x1cffffffffffffffと等しいです。
Mask2 (112 bits) = 0x0000000000000000000000000000 if Sec=0,
0xffff000000000000000000000000 if Sec=1,
0xffffffff00000000000000000000 if Sec=2,
0xffffffffffff0000000000000000 if Sec=3,
0xffffffffffffffff000000000000 if Sec=4,
0xffffffffffffffffffff00000000 if Sec=5,
0xffffffffffffffffffffffff0000 if Sec=6, and
0xffffffffffffffffffffffffffff if Sec=7
Mask2(112ビット)はSec=0であるなら0×0000000000000000000000000000と等しいです、0xffff000000000000000000000000、Sec=1、0xffffffff00000000000000000000である、Sec=2、0xffffffffffff0000000000000000である、Sec=3、0xffffffffffffffff000000000000である、Sec=4、0xffffffffffffffffffff00000000である、Sec=5、0xffffffffffffffffffffffff0000である、Sec=6と、0xffffffffffffffffffffffffffffである、Sec=7です。
A cryptographically generated address is an IPv6 address for which the following two equations hold:
アドレスであると暗号で生成されたAは以下の2つの方程式が当てはまるIPv6アドレスです:
Hash1 & Mask1 == interface identifier & Mask1
Hash2 & Mask2 == 0x0000000000000000000000000000
Hash1&Mask1=インタフェース識別子とMask1 Hash2&Mask2=0x0000000000000000000000000000
Aura Standards Track [Page 4] RFC 3972 Cryptographically Generated Addresses March 2005
2005年3月にアドレスであると暗号で生成された香気標準化過程[4ページ]RFC3972
3. CGA Parameters and Hash Values
3. CGAパラメタとハッシュ値
Each CGA is associated with a CGA Parameters data structure, which has the following format:
それぞれのCGAはCGA Parametersデータ構造に関連しています:(データ構造には、以下の形式があります)。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Modifier (16 octets) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Subnet Prefix (8 octets) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Collision Count| |
+-+-+-+-+-+-+-+-+ |
| |
~ Public Key (variable length) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Extension Fields (optional, variable length) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + 修飾語(16の八重奏)+| | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + サブネットPrefix(8つの八重奏)+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |衝突カウント| | +-+-+-+-+-+-+-+-+ | | | ~ 公共のKey(可変長)~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ 拡大フィールズ(任意の、そして、可変な長さ)~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Modifier
修飾語
This field contains a 128-bit unsigned integer, which can be any
value. The modifier is used during CGA generation to implement
the hash extension and to enhance privacy by adding randomness to
the address.
この分野は128ビットの符号のない整数を含んでいます。(それは、どんな値であるかもしれません)。 修飾語は、ハッシュ拡大を実装して、偶発性をアドレスに追加することによってプライバシーを高めるのにCGA世代の間、使用されます。
Subnet Prefix
サブネット接頭語
This field contains the 64-bit subnet prefix of the CGA.
この分野はCGAの64ビットのサブネット接頭語を含んでいます。
Collision Count
衝突カウント
This is an eight-bit unsigned integer that MUST be 0, 1, or 2.
The collision count is incremented during CGA generation to
recover from an address collision detected by duplicate address
detection.
これは0、1、または2であるに違いない8ビットの符号のない整数です。 衝突カウントは、写しアドレス検出で検出されたアドレス衝突から回復するためにCGA世代の間、増加されます。
Aura Standards Track [Page 5] RFC 3972 Cryptographically Generated Addresses March 2005
2005年3月にアドレスであると暗号で生成された香気標準化過程[5ページ]RFC3972
Public Key
公開鍵
This is a variable-length field containing the public key of the
address owner. The public key MUST be formatted as a DER-encoded
[ITU.X690.2002] ASN.1 structure of the type SubjectPublicKeyInfo,
defined in the Internet X.509 certificate profile [RFC3280]. SEND
SHOULD use an RSA public/private key pair. When RSA is used, the
algorithm identifier MUST be rsaEncryption, which is
1.2.840.113549.1.1.1, and the RSA public key MUST be formatted by
using the RSAPublicKey type as specified in Section 2.3.1 of RFC
3279 [RFC3279]. The RSA key length SHOULD be at least 384 bits.
Other public key types are undesirable in SEND, as they may result
in incompatibilities between implementations. The length of this
field is determined by the ASN.1 encoding.
これはアドレス所有者の公開鍵を含む可変長の分野です。 インターネットX.509証明書プロフィール[RFC3280]で定義されたタイプSubjectPublicKeyInfoのDERによってコード化された[ITU.X690.2002]ASN.1構造として公開鍵をフォーマットしなければなりません。 SEND SHOULDはRSA公衆/秘密鍵組を使用します。 .1、およびRSA公開鍵はそうであるに違いありません。RSAが使用されているとき、アルゴリズム識別子が1.2であるrsaEncryptionであるに違いない、.840、.113549、.1、.1、指定されるとして.1セクション2.3RFC3279[RFC3279]でRSAPublicKeyタイプを使用することによって、フォーマットされます。 RSAキー長SHOULDは少なくともそうです。384ビット。 彼らが実装の間の非互換性をもたらすかもしれないので、他の公開鍵タイプはSENDで望ましくありません。 この分野の長さはASN.1コード化で測定されます。
Extension Fields
拡大分野
This is an optional variable-length field that is not used in the
current specification. Future versions of this specification may
use this field for additional data items that need to be included
in the CGA Parameters data structure. IETF standards action is
required to specify the use of the extension fields.
Implementations MUST ignore the value of any unrecognized
extension fields.
これは現在の仕様で使用されない任意の可変長の分野です。 この仕様の将来のバージョンはCGA Parametersデータ構造に含まれる必要がある追加データ項目にこの分野を使用するかもしれません。 IETF規格動作が、拡大分野の使用を指定するのに必要です。 実装はどんな認識されていない拡大分野の値も無視しなければなりません。
The two hash values MUST be computed as follows. The SHA-1 hash algorithm [FIPS.180-1.1995] is applied to the CGA Parameters. When Hash1 is computed, the input to the SHA-1 algorithm is the CGA Parameters data structure. The 64-bit Hash1 is obtained by taking the leftmost 64 bits of the 160-bit SHA-1 hash value. When Hash2 is computed, the input is the same CGA Parameters data structure except that the subnet prefix and collision count are set to zero. The 112-bit Hash2 is obtained by taking the leftmost 112 bits of the 160-bit SHA-1 hash value. Note that the hash values are computed over the entire CGA Parameters data structure, including any unrecognized extension fields.
以下の通り2つのハッシュ値を計算しなければなりません。 SHA-1ハッシュアルゴリズム[FIPS.180-1.1995]はCGA Parametersに適用されます。 Hash1が計算されるとき、SHA-1アルゴリズムへの入力はCGA Parametersデータ構造です。 160ビットのSHA-1ハッシュ値の一番左64ビット取ることによって、64ビットのHash1を入手します。 Hash2が計算されるとき、サブネット接頭語と衝突カウントがゼロに設定されるのを除いて、入力は同じCGA Parametersデータ構造です。 160ビットのSHA-1ハッシュ値の一番左112ビット取ることによって、112ビットのHash2を入手します。 ハッシュ値がどんな認識されていない拡大分野も含む全体のCGA Parametersデータ構造に関して計算されることに注意してください。
4. CGA Generation
4. CGA世代
The process of generating a new CGA takes three input values: a 64-bit subnet prefix, the public key of the address owner as a DER-encoded ASN.1 structure of the type SubjectPublicKeyInfo, and the security parameter Sec, which is an unsigned three-bit integer. The cost of generating a new CGA depends exponentially on the security parameter Sec, which can have values from 0 to 7.
新しいCGAを生成するプロセスは3つの入力値を取ります: 64ビットのサブネット接頭語、タイプSubjectPublicKeyInfoのDERによってコード化されたASN.1構造、およびセキュリティパラメタSecとしてのアドレス所有者の公開鍵。(Secは未署名の3ビットの整数です)。 新しいCGAを生成する費用はセキュリティパラメタSecに指数関数的に依存します。(Secは0〜7まで値を持つことができます)。
Aura Standards Track [Page 6] RFC 3972 Cryptographically Generated Addresses March 2005
2005年3月にアドレスであると暗号で生成された香気標準化過程[6ページ]RFC3972
A CGA and associated parameters SHOULD be generated as follows:
CGAと関連パラメタSHOULD、以下の通り生成されてください:
1. Set the modifier to a random or pseudo-random 128-bit value.
1. 無作為であるか擬似ランダムの128ビットの値に修飾語を設定してください。
2. Concatenate from left to right the modifier, 9 zero octets, the
encoded public key, and any optional extension fields. Execute
the SHA-1 algorithm on the concatenation. Take the 112 leftmost
bits of the SHA-1 hash value. The result is Hash2.
2. 左から右まで修飾語を連結してください、そして、9は八重奏、コード化された公開鍵、およびどんな任意の拡大分野のゼロにも合っています。 連結のときにSHA-1アルゴリズムを実行してください。 SHA-1ハッシュ値の一番左112ビット取ってください。 結果はHash2です。
3. Compare the 16*Sec leftmost bits of Hash2 with zero. If they are
all zero (or if Sec=0), continue with step 4. Otherwise,
increment the modifier by one and go back to step 2.
3. Hash2の一番左ビットをゼロに16*秒たとえてください。 それらがすべてゼロ(Sec=0であるなら)であるなら、ステップ4を続行してください。 さもなければ、修飾語を1つ増加してください、そして、ステップ2に戻ってください。
4. Set the 8-bit collision count to zero.
4. 8ビットの衝突カウントをゼロに設定してください。
5. Concatenate from left to right the final modifier value, the
subnet prefix, the collision count, the encoded public key, and
any optional extension fields. Execute the SHA-1 algorithm on the
concatenation. Take the 64 leftmost bits of the SHA-1 hash value.
The result is Hash1.
5. 左から右まで最終的な修飾語値、サブネット接頭語、衝突カウント、コード化された公開鍵、およびあらゆる任意の拡大分野を連結してください。 連結のときにSHA-1アルゴリズムを実行してください。 SHA-1ハッシュ値の一番左64ビット取ってください。 結果はHash1です。
6. Form an interface identifier from Hash1 by writing the value of
Sec into the three leftmost bits and by setting bits 6 and 7
(i.e., the "u" and "g" bits) to zero.
6. Hash1から一番左3ビットにSecの値を書いて、ビット6と7(すなわち、「u」と「g」ビット)をゼロに設定することによって、インタフェース識別子を形成してください。
7. Concatenate the 64-bit subnet prefix and the 64-bit interface
identifier to form a 128-bit IPv6 address with the subnet prefix
to the left and interface identifier to the right, as in a
standard IPv6 address [RFC3513].
7. サブネット接頭語で128ビットのIPv6アドレスを左とインタフェース識別子に形成する64ビットのサブネット接頭語と64ビットのインタフェース識別子を右に連結してください、標準のIPv6アドレス[RFC3513]のように。
8. Perform duplicate address detection if required, as per [RFC3971].
If an address collision is detected, increment the collision count
by one and go back to step 5. However, after three collisions,
stop and report the error.
8. 必要なら、[RFC3971]に従って写しアドレス検出を実行してください。 アドレス衝突が検出されるなら、衝突カウントを1つ増加してください、そして、ステップ5に戻ってください。 しかしながら、3回の衝突の後に誤りを止めて、報告してください。
9. Form the CGA Parameters data structure by concatenating from left
to right the final modifier value, the subnet prefix, the final
collision count value, the encoded public key, and any optional
extension fields.
9. 左から右まで最終的な修飾語値、サブネット接頭語、最終的な衝突カウント価値、コード化された公開鍵、およびどんな任意の拡大分野も連結することによって、CGA Parametersデータ構造を形成してください。
The output of the address generation algorithm is a new CGA and a CGA Parameters data structure.
アドレス・ジェネレーションアルゴリズムの出力は、新しいCGAとCGA Parametersデータ構造です。
The initial value of the modifier in step 1 SHOULD be chosen randomly to make addresses generated from the same public key unlinkable, which enhances privacy (see Section 7.3). The quality of the random number generator does not affect the strength of the binding between
修飾語の初期の値は1SHOULDを中に踏みます。手当たりしだいに選ばれていて、同じ公開鍵から作られたアドレスを「放-可能」にしてください、プライバシーを高めるどれ(セクション7.3を見てください)。 乱数発生器の品質は間に結合の強さに影響しません。
Aura Standards Track [Page 7] RFC 3972 Cryptographically Generated Addresses March 2005
2005年3月にアドレスであると暗号で生成された香気標準化過程[7ページ]RFC3972
the address and the public key. Implementations that have no strong random numbers available MAY use a non-cryptographic pseudo-random number generator initialized with the current time of day.
アドレスと公開鍵。 利用可能などんな強い乱数も持っていない実装は現在の時刻で初期化された非暗号の疑似乱数生成器を使用するかもしれません。
For Sec=0, the above algorithm is deterministic and relatively fast. Nodes that implement CGA generation MAY always use the security parameter value Sec=0. If Sec=0, steps 2 - 3 of the generation algorithm can be skipped.
Sec=0に関しては、上のアルゴリズムは、決定論的であって、比較的速いです。 CGA世代を実装するノードはいつもセキュリティパラメタ値のSec=0を使用するかもしれません。 --Sec=0、ステップ2であるなら3つの世代アルゴリズムをスキップできます。
For Sec values greater than zero, the above algorithm is not guaranteed to terminate after a certain number of iterations. The brute-force search in steps 2 - 3 takes O(2^(16*Sec)) iterations to complete. The algorithm has been intentionally designed so that the generation of CGAs with high Sec values is infeasible with current technology.
ゼロより大きいSec値において、上のアルゴリズムは、ある数の繰り返しの後に終わるために保証されません。 ステップ2におけるブルートフォース検索--3 O(2^(16*秒))に終了する繰り返しを取ります。 アルゴリズムは、高いSec値があるCGAsの世代が現在の技術で実行不可能であるように、故意に設計されています。
Implementations MAY use optimized or otherwise modified versions of the above algorithm for CGA generation. However, the output of any modified versions MUST fulfill the following two requirements. First, the resulting CGA and CGA Parameters data structure MUST be formatted as specified in Sections 2 - 3. Second, the CGA verification procedure defined in Section 5 MUST succeed when invoked on the output of the CGA generation algorithm. Note that some optimizations involve trade-offs between privacy and the cost of address generation.
実装はCGA世代に上のアルゴリズムの最適化されたか別の方法で変更されたバージョンを使用するかもしれません。 しかしながら、どんな変更されたバージョンの出力も以下の2つの要件を実現させなければなりません。 まず最初に、データ構造をフォーマットしなければならない結果として起こるCGAとCGA Parametersはセクション2で指定しました--3。 2番目に、CGA世代アルゴリズムの出力のときに呼び出されると、セクション5で定義されたCGA検証手続は成功しなければなりません。 いくつかの最適化がアドレス・ジェネレーションのプライバシーと費用の間のトレードオフにかかわることに注意してください。
One optimization is particularly important. If the subnet prefix of the address changes but the address owner's public key does not, the old modifier value MAY be reused. If it is reused, the algorithm SHOULD be started from step 4. This optimization avoids repeating the expensive search for an acceptable modifier value but may, in some situations, make it easier for an observer to link two addresses to each other.
1つの最適化が特に重要です。 アドレス変化にもかかわらず、アドレス所有者の公開鍵のサブネット接頭語がそうしないなら、古い修飾語値は再利用されるかもしれません。 それは再利用されて、アルゴリズムはSHOULDです。ステップ4から、始められます。 この最適化で、いくつかの状況で、許容できる修飾語値のために高価な検索を繰り返すのを避けますが、観察者が2つのアドレスを互いにリンクするのが、より簡単になるかもしれません。
Note that this document does not specify whether duplicate address detection should be performed and how the detection is done. Step 8 only defines what to do if some form of duplicate address detection is performed and an address collision is detected.
このドキュメントが写しアドレス検出を実行するべきであるかどうかと、どのように検出するかを指定しないことに注意してください。 何らかの形式の写しアドレス検出が実行されて、アドレス衝突が検出される場合にだけ、ステップ8は、何をしたらよいかを定義します。
Future versions of this specification may specify additional inputs to the CGA generation algorithm that are concatenated as extension fields to the end of the CGA Parameters data structure. No such extension fields are defined in this document.
この仕様の将来のバージョンはCGA世代アルゴリズムへの拡大分野としてCGA Parametersデータ構造の終わりまで連結される追加入力を指定するかもしれません。 どんなそのような拡大分野も本書では定義されません。
Aura Standards Track [Page 8] RFC 3972 Cryptographically Generated Addresses March 2005
2005年3月にアドレスであると暗号で生成された香気標準化過程[8ページ]RFC3972
5. CGA Verification
5. CGA検証
CGA verification takes an IPv6 address and a CGA Parameters data structure as input. The CGA Parameters consist of the concatenated modifier, subnet prefix, collision count, public key, and optional extension fields. The verification either succeeds or fails.
CGA検証は入力されるようにIPv6アドレスとCGA Parametersデータ構造を取ります。 CGA Parametersは連結された修飾語、サブネット接頭語、衝突カウント、公開鍵、および任意の拡大分野から成ります。 検証は、成功するか、または失敗します。
The CGA MUST be verified with the following steps:
CGA MUST、以下のステップで、確かめられてください:
1. Check that the collision count in the CGA Parameters data
structure is 0, 1, or 2. The CGA verification fails if the
collision count is out of the valid range.
1. CGA Parametersデータ構造における衝突カウントが0、1、または2であることをチェックしてください。 有効枠の外に衝突カウントがあるなら、CGA検証は失敗します。
2. Check that the subnet prefix in the CGA Parameters data structure
is equal to the subnet prefix (i.e., the leftmost 64 bits) of the
address. The CGA verification fails if the prefix values differ.
2. CGA Parametersデータ構造におけるサブネット接頭語がアドレスのサブネット接頭語(すなわち、一番左64ビット)と等しいのをチェックしてください。 接頭語値が異なるなら、CGA検証は失敗します。
3. Execute the SHA-1 algorithm on the CGA Parameters data structure.
Take the 64 leftmost bits of the SHA-1 hash value. The result is
Hash1.
3. CGA Parametersデータ構造でSHA-1アルゴリズムを実行してください。 SHA-1ハッシュ値の一番左64ビット取ってください。 結果はHash1です。
4. Compare Hash1 with the interface identifier (i.e., the rightmost
64 bits) of the address. Differences in the three leftmost bits
and in bits 6 and 7 (i.e., the "u" and "g" bits) are ignored. If
the 64-bit values differ (other than in the five ignored bits),
the CGA verification fails.
4. アドレスに関するインタフェース識別子(すなわち、一番右の64ビット)とHash1を比べてください。 一番左3ビットとビット6と7(すなわち、「u」と「g」ビット)の違いは無視されます。 64ビットの値が異なるなら(無視された5ビットを除いて)、CGA検証は失敗します。
5. Read the security parameter Sec from the three leftmost bits of
the 64-bit interface identifier of the address. (Sec is an
unsigned 3-bit integer.)
5. アドレスの64ビットのインタフェース識別子の一番左3ビットからセキュリティパラメタSecを読んでください。 (秒は未署名の3ビットの整数です。)
6. Concatenate from left to right the modifier, 9 zero octets, the
public key, and any extension fields that follow the public key in
the CGA Parameters data structure. Execute the SHA-1 algorithm on
the concatenation. Take the 112 leftmost bits of the SHA-1 hash
value. The result is Hash2.
6. 左から右まで修飾語を連結してください、そして、9は八重奏、公開鍵、およびCGA Parametersデータ構造における公開鍵に続くどんな拡大分野のゼロにも合っています。 連結のときにSHA-1アルゴリズムを実行してください。 SHA-1ハッシュ値の一番左112ビット取ってください。 結果はHash2です。
7. Compare the 16*Sec leftmost bits of Hash2 with zero. If any one
of them is not zero, the CGA verification fails. Otherwise, the
verification succeeds. (If Sec=0, the CGA verification never
fails at this step.)
7. Hash2の一番左ビットをゼロに16*秒たとえてください。 それらのいずれがゼロでないなら、CGA検証は失敗します。 さもなければ、検証は成功します。 (Sec=0であるなら、CGA検証はこのステップで決して失敗しません。)
If the verification fails at any step, the execution of the algorithm MUST be stopped immediately. On the other hand, if the verification succeeds, the verifier knows that the public key in the CGA Parameters is the authentic public key of the address owner. The
検証がどんなステップでも失敗するなら、すぐに、アルゴリズムの実行を止めなければなりません。 他方では、検証が成功するなら、検証は、CGA Parametersの公開鍵がアドレス所有者の正統の公開鍵であることを知っています。 The
Aura Standards Track [Page 9] RFC 3972 Cryptographically Generated Addresses March 2005
2005年3月にアドレスであると暗号で生成された香気標準化過程[9ページ]RFC3972
verifier can extract the public key by removing 25 octets from the beginning of the CGA Parameters and by decoding the following SubjectPublicKeyInfo data structure.
検証は、CGA Parametersの始まりから25の八重奏を取り除いて、以下のSubjectPublicKeyInfoデータ構造を解読することによって、公開鍵を抽出できます。
Note that the values of bits 6 and 7 (the "u" and "g" bits) of the interface identifier are ignored during CGA verification. In the SEND protocol, after the verification succeeds, the verifier SHOULD process all CGAs in the same way regardless of the Sec, modifier, and collision count values. In particular, the verifier in the SEND protocol SHOULD NOT have any security policy that differentiates between addresses based on the value of Sec. That way, the address generator is free to choose any value of Sec.
インタフェース識別子のビット6と7(「u」と「g」ビット)の値がCGA検証の間無視されることに注意してください。 SENDプロトコルでは、検証が成功した後にSec、修飾語、および衝突カウント値にかかわらず同様に、検証SHOULDはすべてのCGAsを処理します。 SENDプロトコルSHOULD NOTでの検証には、特に、Secの値に基づくアドレスを区別するどんな安全保障政策もあります。 そのように、アドレス・ジェネレータは無料でSecのどんな値も選ぶことができます。
All nodes that implement CGA verification MUST be able to process all security parameter values Sec = 0, 1, 2, 3, 4, 5, 6, 7. The verification procedure is relatively fast and always requires at most two computations of the SHA-1 hash function. If Sec=0, the verification never fails in steps 6 - 7 and these steps can be skipped.
CGAが検証であると実装するすべてのノードがすべてのセキュリティパラメタ値0、1、2、3、4、5、6、Sec=7を処理できなければなりません。 検証手続は、比較的速く、SHA-1ハッシュ関数の2つの計算を高々いつも必要とします。 Sec=0であるなら、検証はステップ6に決して失敗しません--7とこれらのステップをサボることができます。
Nodes that implement CGA verification for SEND SHOULD be able to process RSA public keys that have the algorithm identifier rsaEncryption and, key length between 384 and 2,048 bits. Implementations MAY support longer keys. Future versions of this specification may recommend support for longer keys.
そして、ノード、SEND SHOULDのための道具CGA検証がアルゴリズム識別子rsaEncryptionを持っているRSA公開鍵を処理できる、384〜2,048ビットのキー長。 実装は、より長いキーを支えるかもしれません。 この仕様の将来のバージョンは、より長いキーのサポートを推薦するかもしれません。
Implementations of CGA verification MUST ignore the value of any unrecognized extension fields that follow the public key in the CGA Parameters data structure. However, implementations MUST include any such unrecognized data in the hash input when computing Hash1 in step 3 and Hash2 in step 6 of the CGA verification algorithm. This is important to ensure upward compatibility with future extensions.
CGA検証の実装はCGA Parametersデータ構造における公開鍵に続くどんな認識されていない拡大分野の値も無視しなければなりません。 しかしながら、CGA検証アルゴリズムのステップ6でステップ3におけるHash1とHash2を計算するとき、実装はハッシュ入力にそのようなどんな認識されていないデータも含まなければなりません。 これは、今後の拡大で上位互換性を確実にするために重要です。
6. CGA Signatures
6. CGA署名
This section defines the procedures for generating and verifying CGA signatures. To sign a message, a node needs the CGA, the associated CGA Parameters data structure, the message, and the private cryptographic key that corresponds to the public key in the CGA Parameters. The node also must have a 128-bit type tag for the message from the CGA Message Type name space.
このセクションはCGA署名を生成して、確かめるための手順を定義します。 メッセージに署名するために、ノードはCGA、関連CGA Parametersデータ構造、メッセージ、およびCGA Parametersの公開鍵に対応する個人的な暗号化キーを必要とします。 ノードには、スペースというCGA Message Type名からのメッセージのための128ビットのタイプタグがなければなりません。
To sign a message, a node SHOULD do the following:
メッセージ、ノードに調印するために、SHOULDは以下をします:
o Concatenate the 128-bit type tag (in network byte order) and the
message with the type tag to the left and the message to the
right. The concatenation is the message to be signed in the next
step.
o 左へのタイプタグと右へのメッセージで128ビットのタイプタグ(ネットワークバイトオーダーにおける)とメッセージを連結してください。 連結は次のステップがサインインされるメッセージです。
Aura Standards Track [Page 10] RFC 3972 Cryptographically Generated Addresses March 2005
2005年3月にアドレスであると暗号で生成された香気標準化過程[10ページ]RFC3972
o Generate the RSA signature by using the RSASSA-PKCS1-v1_5
[RFC3447] signature algorithm with the SHA-1 hash algorithm. The
private key and the concatenation created above are the inputs to
the generation operation.
o SHA-1ハッシュアルゴリズムでRSASSA-PKCS1-v1_5[RFC3447]署名アルゴリズムを使用することによって、RSA署名を生成してください。 秘密鍵と上に作成された連結は世代操作への入力です。
The SEND protocol specification [RFC3971] defines several messages that contain a signature in the Signature Option. The SEND protocol specification also defines a type tag from the CGA Message Type name space. The same type tag is used for all the SEND messages that have the Signature Option. This type tag is an IANA-allocated 128 bit integer that has been chosen at random to prevent an accidental type collision with messages of other protocols that use the same public key but that may or may not use IANA-allocated type tags.
SENDプロトコル仕様[RFC3971]はSignature Optionに署名を含むいくつかのメッセージを定義します。 また、SENDプロトコル仕様はスペースというCGA Message Type名からタイプタグを定義します。 同じタイプタグはSignature Optionを持っているすべてのSENDメッセージに使用されます。 このタイプタグは偶然のタイプ衝突を防ぐために同じ公開鍵を使用する他のプロトコルに関するメッセージで無作為に選ばれましたが、IANAによって割り当てられたタイプタグを使用するかもしれない128ビットのIANAによって割り当てられた整数です。
The CGA, the CGA Parameters data structure, the message, and the signature are sent to the verifier. The SEND protocol specification defines how these data items are sent in SEND protocol messages. Note that the 128-bit type tag is not included in the SEND protocol messages because the verifier knows its value implicitly from the ICMP message type field in the SEND message. See the SEND specification [RFC3971] for precise information about how SEND handles the type tag.
CGA、CGA Parametersデータ構造、メッセージ、および署名を検証に送ります。 SENDプロトコル仕様はSENDプロトコルメッセージでどうこれらのデータ項目を送るかを定義します。 検証がSENDメッセージのICMPメッセージタイプ分野から値をそれとなく知っているので128ビットのタイプタグがSENDプロトコルメッセージに含まれていないことに注意してください。 SENDがどうタイプタグを扱うかに関する正確な情報のためのSEND仕様[RFC3971]を見てください。
To verify a signature, the verifier needs the CGA, the associated CGA Parameters data structure, the message, and the signature. The verifier also needs to have the 128-bit type tag for the message.
署名について確かめるために、検証はCGA、関連CGA Parametersデータ構造、メッセージ、および署名を必要とします。 また、検証はメッセージのための128ビットのタイプタグを必要とします。
To verify the signature, a node SHOULD do the following:
署名、ノードについて確かめるために、SHOULDは以下をします:
o Verify the CGA as defined in Section 5. The inputs to the CGA
verification are the CGA and the CGA Parameters data structure.
o セクション5で定義されるようにCGAについて確かめてください。 CGA検証への入力は、CGAとCGA Parametersデータ構造です。
o Concatenate the 128-bit type tag and the message with the type tag
to the left and the message to the right. The concatenation is
the message whose signature is to be verified in the next step.
o 左へのタイプタグと右へのメッセージで128ビットのタイプタグとメッセージを連結してください。 連結は次のステップで確かめられる署名がことであるメッセージです。
o Verify the RSA signature by using the RSASSA-PKCS1-v1_5 [RFC3447]
algorithm with the SHA-1 hash algorithm. The inputs to the
verification operation are the public key (i.e., the RSAPublicKey
structure from the SubjectPublicKeyInfo structure that is a part
of the CGA Parameters data structure), the concatenation created
above, and the signature.
o SHA-1ハッシュアルゴリズムがあるRSASSA-PKCS1-v1_5[RFC3447]アルゴリズムを使用することによって、RSA署名について確かめてください。 検証操作への入力は、公開鍵(すなわち、CGA Parametersデータ構造の一部であるSubjectPublicKeyInfo構造からのRSAPublicKey構造)と、上に作成された連結と、署名です。
The verifier MUST accept the signature as authentic only if both the CGA verification and the signature verification succeed.
CGA検証と署名照合の両方が成功する場合にだけ、検証は、署名が正統であると受け入れなければなりません。
Aura Standards Track [Page 11] RFC 3972 Cryptographically Generated Addresses March 2005
2005年3月にアドレスであると暗号で生成された香気標準化過程[11ページ]RFC3972
7. Security Considerations
7. セキュリティ問題
7.1. Security Goals and Limitations
7.1. セキュリティ目標と制限
The purpose of CGAs is to prevent stealing and spoofing of existing IPv6 addresses. The public key of the address owner is bound cryptographically to the address. The address owner can use the corresponding private key to assert its ownership and to sign SEND messages sent from the address.
CGAsの目的はIPv6が扱う存在の横取りとスプーフィングを防ぐことです。 アドレス所有者の公開鍵は暗号でアドレスに制限されています。 アドレス所有者は、所有権を主張して、アドレスから送られたメッセージにSENDに署名するのに対応する秘密鍵を使用できます。
It is important to understand that an attacker can create a new address from an arbitrary subnet prefix and its own (or someone else's) public key because CGAs are not certified. However, the attacker cannot impersonate somebody else's address. This is because the attacker would have to find a collision of the cryptographic hash value Hash1. (The property of the hash function needed here is called second pre-image resistance [MOV97].)
CGAsが公認されないので攻撃者が任意のサブネット接頭語とそれ自身(または、他の誰かのもの)の公開鍵から新しいアドレスを作成できるのを理解しているのは重要です。 しかしながら、攻撃者は他の誰かのアドレスをまねることができません。 攻撃者は暗号のハッシュ値Hash1の衝突を見つけなければならないでしょう、したがって、これがそうです。 (ここで必要であったハッシュ関数の特性は2番目のプレイメージ抵抗[MOV97]と呼ばれます。)
For each valid CGA Parameters data structure, there are 4*(Sec+1) different CGAs that match the value. This is because decrementing the Sec value in the three leftmost bits of the interface identifier does not invalidate the address, and the verifier ignores the values of the "u" and "g" bits. In SEND, this does not have any security or implementation implications.
それぞれの有効なCGA Parametersデータ構造のために、値に合っている4*(秒+1)異なったCGAsがあります。 これはインタフェース識別子の一番左3ビットのSec値を減少させるのがアドレスを無効にしないで、検証が「u」と「g」ビットの値を無視するからです。 SENDでは、これは少しのセキュリティや実装意味も持っていません。
Another limitation of CGAs is that there is no mechanism for proving that an address is not a CGA. Thus, an attacker could take someone else's CGA and present it as a non-cryptographically generated address (e.g., as an RFC 3041 address [RFC3041]). An attacker does not benefit from this because although SEND nodes accept both signed and unsigned messages from every address, they give priority to the information in the signed messages.
CGAsの別の限界はアドレスがCGAでないと立証するためのメカニズムが全くないということです。 したがって、aが非暗号でアドレスを作ったとき(例えば、RFC3041が[RFC3041]を扱うとき)、攻撃者は、他の誰かのCGAを取って、それを提示できました。 攻撃者は、SENDノードがあらゆるアドレスから署名しているものと同様に未署名のメッセージを受け入れますが、署名しているメッセージの情報に優先的に取り扱うので、これの利益を得ません。
The minimum RSA key length required for SEND is only 384 bits. So short keys are vulnerable to integer-factoring attacks and cannot be used for strong authentication or secrecy. On the other hand, the cost of factoring 384-bit keys is currently high enough to prevent most denial-of-service attacks. Implementations that initially use short RSA keys SHOULD be prepared to switch to longer keys when denial-of-service attacks arising from integer factoring become a problem.
SENDに必要である最小のRSAキー長は384ビットにすぎません。 とても短いキーは、整数を因数分解する攻撃に被害を受け易く、強い認証か秘密保持に使用できません。 他方では、384ビットのキーを因数分解する費用は現在、ほとんどのサービス不能攻撃を防ぐことができるくらい高いです。 整数因数分解から起こるサービス不能攻撃が問題になるとき、より長いキーに切り換えるために準備されていて、初めは短いRSAキーSHOULDを使用する実装。
The impact of a key compromise on CGAs depends on the application for which they are used. In SEND, it is not a major concern. If the private signature key is compromised because the SEND node has itself been compromised, the attacker does not need to spoof SEND messages from the node. When it is discovered that a node has been compromised, a new signature key and a new CGA SHOULD be generated.
CGAsの上の主要な感染の影響は彼らが使用されているアプリケーションに依存します。 SENDでは、それは主要な関心事ではありません。 個人的な署名キーがSENDノードが感染されたので感染されるなら、それ自体が感染されて、攻撃者はSENDがノードから通信させるパロディーにどんな必要性もしません。 ノードが感染していて、a新しい署名キーとa新しいCGA SHOULDであると発見されるときには、生成されてください。
Aura Standards Track [Page 12] RFC 3972 Cryptographically Generated Addresses March 2005
2005年3月にアドレスであると暗号で生成された香気標準化過程[12ページ]RFC3972
On the other hand, if the RSA key is compromised because integer- factoring attacks for the chosen key length have become practical, the key has to be replaced with a longer one, as explained above. In either case, the address change effectively revokes the old public key. It is not necessary to have any additional key revocation mechanism or to limit the lifetimes of the signature keys.
他方では、選ばれたキー長のための整数の因数分解している攻撃が実用的になったのでRSAキーに感染するなら、キーをより長いものに取り替えなければなりません、上で説明されるように。 どちらの場合ではも、事実上、アドレス変化は古い公開鍵を取り消します。 どんな追加主要な取消しメカニズムも持っているか、または署名キーの生涯を制限するのは必要ではありません。
7.2. Hash Extension
7.2. ハッシュ拡大
As computers become faster, the 64 bits of the interface identifier will not be sufficient to prevent attackers from searching for hash collisions. It helps somewhat that we include the subnet prefix of the address in the hash input. This prevents the attacker from using a single pre-computed database to attack addresses with different subnet prefixes. The attacker needs to create a separate database for each subnet prefix. Link-local addresses are, however, left vulnerable because the same prefix is used by all IPv6 nodes.
コンピュータが、より速くなるとき、インタフェース識別子の64ビットは、攻撃者がハッシュ衝突を捜し求めるのを防ぐために十分ではありません。 私たちがハッシュ入力でアドレスのサブネット接頭語を入れるのはいくらか助かります。 これによって、攻撃者は異なったサブネット接頭語でアドレスを攻撃するのにただ一つのあらかじめ計算されたデータベースを使用できません。 攻撃者は、それぞれのサブネット接頭語のための別々のデータベースを作成する必要があります。 同じ接頭語がすべてのIPv6ノードによって使用されるので、しかしながら、リンクローカルのアドレスは被害を受け易い状態で残されます。
To prevent the CGA technology from becoming outdated as computers become faster, the hash technique used to generate CGAs must be extended somehow. The chosen extension technique is to increase the cost of both address generation and brute-force attacks by the same parameterized factor while keeping the cost of address use and verification constant. This also provides protection for link-local addresses. Introduction of the hash extension is the main difference between this document and earlier CGA proposals [OR01][Nik01][MC02].
コンピュータが、より速くなるのに応じてCGA技術が時代遅れになるのを防ぐために、どうにかCGAsを生成するのに使用されるハッシュのテクニックを広げなければなりません。 選ばれた拡大のテクニックはアドレス使用と検証の費用を一定に保っている間、同じparameterized要素でアドレス・ジェネレーションと全数探索法の両方の費用を増強することです。 また、これはリンクローカルのアドレスのための保護を提供します。 ハッシュ拡大の導入はこのドキュメントと以前のCGA提案[OR01][Nik01][MC02]の主な違いです。
To achieve the effective extension of the hash length, the input to the second hash function, Hash2, is modified (by changing the modifier value) until the leftmost 16*Sec bits of the hash value are zero. This increases the cost of address generation approximately by a factor of 2^(16*Sec). It also increases the cost of brute-force attacks by the same factor. That is, the cost of creating a CGA Parameters data structure that binds the attacker's public key with somebody else's address is increased from O(2^59) to O(2^(59+16*Sec)). The address generator may choose the security parameter Sec depending on its own computational capacity, the perceived risk of attacks, and the expected lifetime of the address. Currently, Sec values between 0 and 2 are sufficient for most IPv6 nodes. As computers become faster, higher Sec values will slowly become useful.
ハッシュの長さの有効な拡大を達成するために、2番目のハッシュ関数への入力(Hash2)はハッシュ値のビットが一番左16*秒単位でゼロになるまで変更されています(修飾語値を変えるのによる)。 これは周囲で2^(16*秒)の要素でアドレス・ジェネレーションの費用を増強します。 また、それは同じ要素で全数探索法の費用を増強します。 O(2^(59+16*秒))によってすなわち、他の誰かのアドレスで攻撃者の公開鍵を縛るCGA Parametersデータ構造を作成する費用は増強されます。 アドレス・ジェネレータはそれ自身のコンピュータの容量に依存するセキュリティパラメタSec、攻撃の知覚リスク、およびアドレスの予想された生涯を選ぶかもしれません。 現在、0と2の間のSec値はほとんどのIPv6ノードに十分です。 コンピュータが、より速くなるのに従って、より高いSec値は役に立つようにゆっくりなるでしょう。
Theoretically, if no hash extension is used (i.e., Sec=0) and a typical attacker is able to tap into N local networks at the same time, an attack against link-local addresses is N times as efficient as an attack against addresses of a specific network. The effect could be countered by using a slightly higher Sec value for link-
理論的に、どんなハッシュ拡大も使用されていなくて(すなわち、Sec=0)、典型的な攻撃者が同時にN企業内情報通信網に軽く打ち込むことができるなら、リンクローカルのアドレスに対する攻撃は特定のネットワークのアドレスに対して攻撃のN倍効率的です。 リンクにわずかに高いSec値を使用することによって、効果に対抗できるでしょう。
Aura Standards Track [Page 13] RFC 3972 Cryptographically Generated Addresses March 2005
2005年3月にアドレスであると暗号で生成された香気標準化過程[13ページ]RFC3972
local addresses. When higher Sec values (such that 2^(16*Sec) > N) are used for all addresses, the relative advantage of attacking link-local addresses becomes insignificant.
ローカルのアドレス。 より高いSec値である、(2^(16*秒)>N)がすべてのアドレスに使用されて、リンクローカルのアドレスを攻撃する相対的な利点が無意味になるようなもの。
The effectiveness of the hash extension depends on the assumption that the computational capacities of the attacker and the address generator will grow at the same (potentially exponential) rate. This is not necessarily true if the addresses are generated on low-end mobile devices, for which the main design goals are to lower cost and decrease size, rather than increase computing power. But there is no reason for doing so. The expensive part of the address generation (steps 1 - 3 of the generation algorithm) may be delegated to a more powerful computer. Moreover, this work can be done in advance or offline, rather than in real time, when a new address is needed.
ハッシュ拡大の有効性は攻撃者のコンピュータの能力とアドレス・ジェネレータが同じ(潜在的に指数)の速度で成長するという前提に依存します。 アドレスがローエンドモバイル機器(主なデザイン目標は、パワーを計算しながら増加するよりむしろ費用を下げて、サイズを減少させることである)で作られるなら、これは必ず本当であるというわけではありません。 しかし、そうする理由が全くありません。 アドレス・ジェネレーション(3つの世代1--アルゴリズムを踏む)の高価な部分をより強力なコンピュータへ代表として派遣するかもしれません。 そのうえ、この仕事があらかじめかリアルタイムでというよりむしろオフラインでできます、新しいアドレスが必要であるときに。
To make it possible for mobile nodes whose subnet prefixes change frequently to use Sec values greater than zero, we have decided not to include the subnet prefix in the input of Hash2. The result is weaker than it would be if the subnet prefix were included in the input of both hashes. On the other hand, our scheme is at least as strong as using the hash extension technique without including the subnet prefix in either hash. It is also at least as strong as not using the hash extension but including the subnet prefix. This trade-off was made because mobile nodes frequently move to insecure networks, where they are at the risk of denial-of-service (DoS) attacks (for example, during the duplicate address detection procedure).
ゼロより大きいSec値を使用するのをサブネット接頭語が頻繁に変化するモバイルノードに可能にするように、私たちは、Hash2の入力にサブネット接頭語を含んでいないと決めました。 結果はサブネット接頭語が両方のハッシュの入力に含まれていたかどうかということであるだろうより弱いです。 他方では、私たちの体系はどちらのハッシュにもサブネット接頭語を含んでいなくてハッシュ拡大のテクニックを使用するのと少なくとも同じくらい強いです。 また、それもハッシュ拡張子を使用しませんが、サブネット接頭語を含んでいるのと少なくとも同じくらい強いです。 モバイルノードが頻繁に不安定なネットワーク(サービスの否定(DoS)攻撃(例えば写しアドレス検出手順の間)のリスクにはそれらがある)に移行するので、このトレードオフをしました。
In most networks, the goal of Secure Neighbor Discovery and CGA signatures is to prevent denial-of-service attacks. Therefore, it is usually sensible to start by using a low Sec value and to replace addresses with stronger ones only when denial-of-service attacks based on brute-force search become a significant problem. If CGAs were used as a part of a strong authentication or secrecy mechanism, it might be necessary to start with higher Sec values.
ほとんどのネットワークでは、Secure NeighborディスカバリーとCGA署名の目標はサービス不能攻撃を防ぐことです。 したがって、ブルートフォース検索に基づくサービス不能攻撃が重大な問題になるときだけ、通常、低Sec値を使用することによって始まって、アドレスをより強いものに取り替えるのは分別があります。 CGAsが強い認証か秘密保持メカニズムの一部として使用されるなら、より高いSec値から始まるのが必要でしょうに。
The collision count value is used to modify the input to Hash1 if there is an address collision. It is important not to allow collision count values higher than 2. First, it is extremely unlikely that three collisions would occur and the reason is certain to be either a configuration or implementation error or a denial-of- service attack. (When the SEND protocol is used, deliberate collisions caused by a DoS attacker are detected and ignored.) Second, an attacker doing a brute-force search to match a given CGA can try all different values of a collision count without repeating the brute-force search for the modifier value. Thus, if higher values are allowed for the collision count, the hash extension technique becomes less effective in preventing brute force attacks.
アドレス衝突があれば、衝突カウント価値は、入力をHash1に変更するのに使用されます。 2より高い衝突カウント値を許容しないのは重要です。 最初に、3回の衝突が起こるのは、非常にありそうもなく、理由は構成か実装誤りか否定のどちらかであることが確かです。-サービスでは、攻撃してください。 (SENDプロトコルが使用されているとき、DoS攻撃者によって引き起こされた慎重な衝突は、検出されて、無視されます。) 2番目に、ブルートフォース検索を繰り返さないで、与えられたCGAを合わせるためにブルートフォース検索をしている攻撃者は修飾語値のために衝突カウントのすべての異価を試みることができます。 したがって、より高い値が衝突カウントのために許容されているなら、ハッシュ拡大のテクニックはブルートフォースアタックを防ぐのにおいて、より有効でなくなります。
Aura Standards Track [Page 14] RFC 3972 Cryptographically Generated Addresses March 2005
2005年3月にアドレスであると暗号で生成された香気標準化過程[14ページ]RFC3972
7.3. Privacy Considerations
7.3. プライバシー問題
CGAs can give the same level of pseudonymity as the IPv6 address privacy extensions defined in RFC 3041 [RFC3041]. An IP host can generate multiple pseudo-random CGAs by executing the CGA generation algorithm of Section 4 multiple times and by using a different random or pseudo-random initial value for the modifier every time. The host should change its address periodically as in [RFC3041]. When privacy protection is needed, the (pseudo)random number generator used in address generation SHOULD be strong enough to produce unpredictable and unlinkable values. Advice on random number generation can be found in [RFC1750].
IPv6アドレスプライバシー拡張子がRFC3041で[RFC3041]を定義したので、CGAsは同じレベルの偽名を与えることができます。 IPホストは、複数の擬似ランダムがCGAsであると複数の回と毎回修飾語に無作為であるか擬似ランダムの異なった初期の値を使用することによってセクション4のCGA世代アルゴリズムを実行することによって、生成することができます。 ホストは[RFC3041]のように定期的に住所を変更するべきです。 プライバシー保護が必要であるときに、アドレス・ジェネレーションSHOULDに使用される(疑似な)乱数発生器は、予測できない生産物に十分強く、値を「放-可能」します。 [RFC1750]で乱数発生に関するアドバイスを見つけることができます。
There are two apparent limitations to this privacy protection. However, as will be explained below, neither is very serious.
このプライバシー保護への2つの見かけの制限があります。 しかしながら、以下で説明されるように、どちらも非常に重大ではありません。
First, the high cost of address generation may prevent hosts that use a high Sec value from changing their address frequently. This problem is mitigated because the expensive part of the address generation may be done in advance or offline, as explained in the previous section. It should also be noted that the nodes that benefit most from high Sec values (e.g., DNS servers, routers, and data servers) usually do not require pseudonymity, and the nodes that have high privacy requirements (e.g., client PCs and mobile hosts) are unlikely targets for expensive brute-force DoS attacks and can make do with lower Sec values.
まず最初に、高いSec値を使用するホストはアドレス・ジェネレーションの高い費用のために頻繁に住所を変更できないかもしれません。 アドレス・ジェネレーションの高価な部分があらかじめかオフラインで完了しているかもしれないので、この問題は緩和されます、前項で説明されるように。 また、通常、高いSec値(例えば、DNSサーバ、ルータ、およびデータサーバ)から最も利益を得るノードが偽名を必要としないことに注意されるべきであり、高いプライバシー要件(例えば、クライアントPCとモバイルホスト)を持っているノードは、高価なブルートフォースDoS攻撃のためのありそうもない目標であり、下側のSec値で間に合わせることができます。
Second, the public key of the address owner is revealed in the signed SEND messages. This means that if the address owner wants to be pseudonymous toward the nodes in the local links that it accesses, it should generate not only a new address but also a new public key. With typical local-link technologies, however, a node's link-layer address is a unique identifier for the node. As long as the node keeps using the same link-layer address, it makes little sense to change the public key for privacy reasons.
2番目に、アドレス所有者の公開鍵は署名しているSENDメッセージで明らかにされます。 これは、アドレス所有者がそれがアクセスする地方のリンクのノードに向かって偽名でありたいと思うなら、新しいアドレスだけではなく、新しい公開鍵も生成するべきであることを意味します。 しかしながら、典型的な地方のリンク技術で、ノードのリンクレイヤアドレスはノードのためのユニークな識別子です。 ノードが同じリンクレイヤアドレスを使用し続ける限り、それはプライバシー理由で少ししか公開鍵を変化に理解できません。
7.4. Related Protocols
7.4. 関連プロトコル
Although this document defines CGAs only for the purposes of Secure Neighbor Discovery, other protocols could be defined elsewhere that use the same addresses and public keys. This raises the possibility of related-protocol attacks in which a signed message from one protocol is replayed in another protocol. This means that other protocols (perhaps even those designed without an intimate knowledge of SEND) could endanger the security of SEND. What makes this threat even more significant is that the attacker could create a CGA from someone else's public key and then replay signed messages from a protocol that has nothing to do with CGAs or IP addresses.
このドキュメントはSecure Neighborディスカバリーの目的のためだけにCGAsを定義しますが、ほかの場所で同じアドレスと公開鍵を使用する他のプロトコルは定義できました。 これは1つのプロトコルからの署名しているメッセージが別のプロトコルで再演される関連するプロトコル攻撃の可能性を上げます。 これは、他のプロトコル(恐らくSENDに関する詳細な知識なしで設計されたものさえ)がSENDのセキュリティを危険にさらすかもしれないことを意味します。 この脅威をさらに重要にすることは攻撃者がメッセージであると署名される他の誰かの公開鍵と当時の再生からCGAsかIPアドレスと関係ないプロトコルからCGAを作成できたということです。
Aura Standards Track [Page 15] RFC 3972 Cryptographically Generated Addresses March 2005
2005年3月にアドレスであると暗号で生成された香気標準化過程[15ページ]RFC3972
To prevent the related-protocol attacks, a type tag is prepended to every message before it is signed. The type tags are 128-bit randomly chosen values, which prevents accidental type collisions with even poorly designed protocols that do not use any type tags. Moreover, the SEND protocol includes the sender's CGA address in all signed messages. This makes it even more difficult for an attacker to take signed messages from some other context and to replay them as SEND messages.
関連するプロトコル攻撃を防ぐために、それが署名される前にタイプタグはあらゆるメッセージにprependedされます。 タイプタグは値が手当たりしだいに選ばれた128ビットです。(そのビットはどんなタイプタグも使用しない不十分に設計されたプロトコルがあっても偶然のタイプ衝突を防ぎます)。 そのうえ、SENDプロトコルはメッセージであると署名されるすべてに送付者のCGAアドレスを含んでいます。 これで、攻撃者がある他の文脈から署名している伝言を受け取て、SENDメッセージとしてそれらを再演するのはさらに難しくなります。
Finally, a strong cautionary note has to be made about using CGA signatures for purposes other than SEND. First, the other protocols MUST include a type tag and the sender address in all signed messages in the same way that SEND does. Each protocol MUST define its own type tag values as explained in Section 8. Moreover, because of the possibility of related-protocol attacks, the public key MUST be used only for signing, and it MUST NOT be used for encryption. Second, the minimum RSA key length of 384 bits may be too short for many applications and the impact of key compromise on the particular protocol must be evaluated. Third, CGA-based authorization is particularly suitable for securing neighbor discovery [RFC2461] and duplicate address detection [RFC2462] because these are network-layer signaling protocols for which IPv6 addresses are natural endpoint identifiers. In any protocol that uses other identifiers, such as DNS names, CGA signatures alone are not a sufficient security mechanism. There must also be a secure way of mapping the other identifiers to IPv6 addresses. If the goal is not to verify claims about IPv6 addresses, CGA signatures are probably not the right solution.
最終的に、強い警告的なメモはSEND以外の目的にCGA署名を使用することに関して作られていなければなりません。 まず最初に、他のプロトコルはメッセージであると署名されるすべてにSENDがするのと同じようにタイプタグと送付者アドレスを含まなければなりません。 各プロトコルはセクション8で説明されるそれ自身のタイプタグ値を定義しなければなりません。 そのうえ、関連するプロトコル攻撃の可能性のために、署名にだけ公開鍵を使用しなければなりません、そして、それは暗号化に使用されてはいけません。 2番目に、多くのアプリケーションには、最低384ビットのRSAキー長は短過ぎるかもしれません、そして、特定のプロトコルに関する主要な感染の影響を評価しなければなりません。 3番目に、これらがIPv6アドレスが自然な終点識別子であるネットワーク層シグナリングプロトコルであるので隣人発見[RFC2461]と写しアドレスが検出[RFC2462]であると機密保護するのにCGAベースの承認は特に適当です。 DNS名などの他の識別子を使用するどんなプロトコルでも、唯一のCGA署名は十分なセキュリティー対策ではありません。 また、他の識別子をIPv6アドレスに写像する安全な方法があるに違いありません。 目標がIPv6アドレスに関するクレームについて確かめないことであるなら、CGA署名はたぶん正しい解決ではありません。
8. IANA Considerations
8. IANA問題
This document defines a new CGA Message Type name space for use as type tags in messages that may be signed by using CGA signatures. The values in this name space are 128-bit unsigned integers. Values in this name space are allocated on a First Come First Served basis [RFC2434]. IANA assigns new 128-bit values directly without a review.
このドキュメントは使用のためにCGA署名を使用することによって署名されるかもしれないメッセージで新しいCGA Message Type名前スペースをタイプタグと定義します。 この名前スペースの値は128ビットの符号のない整数です。 First Come First Servedベース[RFC2434]にこの名前スペースの値を割り当てます。 IANAは直接レビューなしで新しい128ビットの値を割り当てます。
The requester SHOULD generate the new values with a strong random- number generator. Continuous ranges of at most 256 values can be requested provided that the 120 most significant bits of the values have been generated with a strong random-number generator.
リクエスタSHOULDは強い無作為の数のジェネレータで新しい値を生成します。 値の120の最上位ビットが強い乱数発生器で生成されたならば、高々256の値の連続した範囲を要求できます。
IANA does not generate random values for the requester. IANA allocates requested values without verifying the way in which they have been generated. The name space is essentially unlimited, and any number of individual values and ranges of at most 256 values can be allocated.
IANAはリクエスタのために無作為の値を生成しません。 それらが生成された方法を確かめないで、IANAは要求された値を割り当てます。 名前スペースは本質的には無制限です、そして、高々256の値のいろいろな個人価値と範囲を割り当てることができます。
Aura Standards Track [Page 16] RFC 3972 Cryptographically Generated Addresses March 2005
2005年3月にアドレスであると暗号で生成された香気標準化過程[16ページ]RFC3972
CGA Message Type values for private use MAY be generated with a strong random-number generator without IANA allocation.
CGA Message Type値は強い乱数発生器でIANA配分なしで私的使用目的で生成されるかもしれません。
This document does not define any new values in any name space.
このドキュメントはどんな名前スペースの少しの新しい値も定義しません。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[RFC3971] Arkko, J., Ed., Kempf, J., Sommerfeld, B., Zill,
B., and P. Nikander, "SEcure Neighbor Discovery
(SEND)", RFC 3971, March 2005.
[RFC3971]Arkko、J.(エド)、ケンフ、J.、ゾンマーフェルト、B.、Zill、B.、およびP.Nikander、「安全な隣人発見(発信する)」、RFC3971(2005年3月)。
[RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms
and Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 3279, April
2002.
[RFC3279] Bassham、L.、ポーク、W.、およびR.Housley、「インターネットX.509公開鍵暗号基盤証明書と証明書取消しのためのアルゴリズムと識別子は(CRL)プロフィールをリストアップします」、RFC3279、2002年4月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol
Version 6 (IPv6) Addressing Architecture", RFC
3513, April 2003.
[RFC3513]HindenとR.とS.デアリング、「インターネットプロトコルバージョン6(IPv6)アドレッシング体系」、RFC3513、2003年4月。
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo,
"Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL)
Profile", RFC 3280, April 2002.
[RFC3280] Housley、R.、ポーク、W.、フォード、W.、および一人で生活して、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)は輪郭を描く」D.、RFC3280(2002年4月)。
[ITU.X690.2002] International Telecommunications Union,
"Information Technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER),
Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER)", ITU-T Recommendation X.690,
July 2002.
[ITU.X690.2002]国際Telecommunications Union、「情報Technology--ASN.1コード化は以下を統治します」。 「基本的な符号化規則(BER)、正準な符号化規則(CER)、および顕著な符号化規則(DER)の仕様」、ITU-T推薦X.690、2002年7月。
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key
Cryptography Standards (PKCS) #1: RSA Cryptography
Specifications Version 2.1", RFC 3447, February
2003.
[RFC3447] イェンソン、J.、およびB.Kaliski、「公開鍵暗号化標準(PKCS)#1:」 RSA暗号仕様バージョン2.1インチ、RFC3447、2月2003日
[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月)。
Aura Standards Track [Page 17] RFC 3972 Cryptographically Generated Addresses March 2005
2005年3月にアドレスであると暗号で生成された香気標準化過程[17ページ]RFC3972
[FIPS.180-1.1995] National Institute of Standards and Technology,
"Secure Hash Standard", Federal Information
Processing Standards Publication FIPS PUB 180-1,
April 1995,
<http://www.itl.nist.gov/fipspubs/fip180-1.htm>.
[FIPS.180-1.1995]米国商務省標準技術局、「ハッシュ規格を保証してください」、連邦政府の情報処理規格公表FIPSパブ180-1、1995年4月、<http://www.itl.nist.gov/fipspubs/fip180-1.htm>。
9.2. Informative References
9.2. 有益な参照
[AAKMNR02] Arkko, J., Aura, T., Kempf, J., Mantyla, V.,
Nikander, P., and M. Roe, "Securing IPv6 neighbor
discovery and router discovery", ACM Workshop on
Wireless Security (WiSe 2002), Atlanta, GA USA ,
September 2002.
[AAKMNR02] Wireless Security(WiSe2002)、ジョージアアトランタ(米国)(2002年9月)のArkko、J.、Aura、T.、ケンフ、J.、Mantyla、V.、Nikander、P.、およびM.Roe、「IPv6が隣人発見とルータ発見であると機密保護します」、ACM Workshop。
[Aura03] Aura, T., "Cryptographically Generated Addresses
(CGA)", 6th Information Security Conference
(ISC'03), Bristol, UK, October 2003.
[Aura03] 香気、T.、「アドレス(CGA)であると暗号で生成された」第6情報セキュリティコンファレンス(ISC'03)、ブリストル、イギリス、2003'年10月。
[RFC1750] Eastlake, D., Crocker, S., and J. Schiller,
"Randomness Recommendations for Security", RFC
1750, December 1994.
1994年12月の[RFC1750]イーストレークとD.とクロッカー、S.とJ.シラー、「セキュリティのための偶発性推薦」RFC1750。
[MOV97] Menezes, A., van Oorschot, P., and S. Vanstone,
"Handbook of Applied Cryptography", CRC Press ,
1997.
[MOV97]メネゼスとA.とバンOorschot、P.とS.Vanstone、「適用された暗号のハンドブック」CRC Press、1997。
[MC02] Montenegro, G. and C. Castelluccia, "Statistically
unique and cryptographically verifiable identifiers
and addresses", ISOC Symposium on Network and
Distributed System Security (NDSS 2002), San Diego,
CA USA , February 2002.
[MC02] モンテネグロ、G.、およびC.Castelluccia、「統計的にユニークである、暗号で、証明可能な識別子とアドレス、」、Networkの上のISOC SymposiumとDistributed System Security(NDSS2002)、カリフォルニアサンディエゴ(米国)(2002年2月)
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6", RFC
3041, January 2001.
[RFC3041] NartenとT.とR.Draves、「IPv6"での状態がないアドレス自動構成のためのプライバシー拡大、RFC3041、2001年1月。」
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998.
[RFC2461]Narten、T.、Nordmark、E.、およびW.シンプソン、「IPバージョン6(IPv6)のための隣人発見」、RFC2461、1998年12月。
[Nik01] Nikander, P., "A scaleable architecture for IPv6
address ownership", draft-nikander-addr-ownership-
00 (work in progress), March 2001.
[Nik01]Nikander、P.、「IPv6アドレス所有権のためのスケーラブルなアーキテクチャ」、草稿-nikander-addr所有権-00(処理中の作業)、2001年3月。
[OR01] O'Shea, G. and M. Roe, "Child-proof authentication
for MIPv6 (CAM)", ACM Computer Communications
Review 31(2), April 2001.
[OR01] オシアとG.とM.Roe、「MIPv6(CAM)のための子供にとって安全な認証」、ACMコンピュータCommunications Review 31(2)、2001年4月。
Aura Standards Track [Page 18] RFC 3972 Cryptographically Generated Addresses March 2005
2005年3月にアドレスであると暗号で生成された香気標準化過程[18ページ]RFC3972
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC2462] トムソンとS.とT.Narten、「IPv6の状態がないアドレス自動構成」、RFC2462、1998年12月。
Aura Standards Track [Page 19] RFC 3972 Cryptographically Generated Addresses March 2005
2005年3月にアドレスであると暗号で生成された香気標準化過程[19ページ]RFC3972
Appendix A. Example of CGA Generation
CGA世代に関する付録A.の例
We generate a CGA with Sec=1 from the subnet prefix fe80:: and the following public key:
私たちはSec=1と共にサブネット接頭語fe80からCGAを生成します:、: 以下の公開鍵:
305c 300d 0609 2a86 4886 f70d 0101 0105 0003 4b00 3048 0241 00c2 c2f1 3730 5454 f10b d9ce a368 44b5 30e9 211a 4b26 2b16 467c b7df ba1f 595c 0194 f275 be5a 4d38 6f2c 3c23 8250 8773 c786 7f9b 3b9e 63a0 9c7b c48f 7a54 ebef af02 0301 0001
305c 300d0609 2a86 4886 f70d0101 0105 0003 4b00 3048 0241 00c2 c2f1 3730 5454f10b d9ce a368 44b5 30e9 211a 4b26 2b16 467c b7df ba1f 595c0194f275 be5a 4d38 6f2c 3c23 8250 8773c786 7f9b 3b9e 63a0 9c7b c48f 7a54 ebef af02 0301 0001
The modifier is initialized to a random value 89a8 a8b2 e858 d8b8 f263 3f44 d2d4 ce9a. The input to Hash2 is:
修飾語は無作為の値の89a8 a8b2 e858 d8b8 f263 3f44 d2d4 ce9aに初期化されます。 Hash2への入力は以下の通りです。
89a8 a8b2 e858 d8b8 f263 3f44 d2d4 ce9a 0000 0000 0000 0000 00 305c 300d 0609 2a86 4886 f70d 0101 0105 0003 4b00 3048 0241 00c2 c2f1 3730 5454 f10b d9ce a368 44b5 30e9 211a 4b26 2b16 467c b7df ba1f 595c 0194 f275 be5a 4d38 6f2c 3c23 8250 8773 c786 7f9b 3b9e 63a0 9c7b c48f 7a54 ebef af02 0301 0001
89a8 a8b2 e858 d8b8 f263 3f44 d2d4 ce9a0000 0000 0000 0000 00 305c 300d0609 2a86 4886 f70d0101 0105 0003 4b00 3048 0241 00c2 c2f1 3730 5454f10b d9ce a368 44b5 30e9 211a 4b26 2b16 467c b7df ba1f 595c0194f275 be5a 4d38 6f2c 3c23 8250 8773c786 7f9b 3b9e 63a0 9c7b c48f 7a54 ebef af02 0301 0001
The 112 first bits of the SHA-1 hash value computed from the above input are Hash2=436b 9a70 dbfd dbf1 926e 6e66 29c0. This does not begin with 16*Sec=16 zero bits. Thus, we must increment the modifier by one and recompute the hash. The new input to Hash2 is:
最初に、SHA-1ハッシュ値のビットが上記の入力から計算した112はHash2=436b 9a70 dbfd dbf1 926e 6e66 29c0です。 これは16 16*秒=ゼロ・ビットで始まりません。 したがって、私たちは修飾語を1つ増加しなければなりません、そして、recomputeはハッシュを増加します。 Hash2への新しい入力は以下の通りです。
89a8 a8b2 e858 d8b8 f263 3f44 d2d4 ce9b 0000 0000 0000 0000 00 305c 300d 0609 2a86 4886 f70d 0101 0105 0003 4b00 3048 0241 00c2 c2f1 3730 5454 f10b d9ce a368 44b5 30e9 211a 4b26 2b16 467c b7df ba1f 595c 0194 f275 be5a 4d38 6f2c 3c23 8250 8773 c786 7f9b 3b9e 63a0 9c7b c48f 7a54 ebef af02 0301 0001
89a8 a8b2 e858 d8b8 f263 3f44 d2d4 ce9b0000 0000 0000 0000 00 305c 300d0609 2a86 4886 f70d0101 0105 0003 4b00 3048 0241 00c2 c2f1 3730 5454f10b d9ce a368 44b5 30e9 211a 4b26 2b16 467c b7df ba1f 595c0194f275 be5a 4d38 6f2c 3c23 8250 8773c786 7f9b 3b9e 63a0 9c7b c48f 7a54 ebef af02 0301 0001
The new hash value is Hash2=0000 01ca 680b 8388 8d09 12df fcce. The 16 leftmost bits of Hash2 are all zero. Thus, we found a suitable modifier. (We were very lucky to find it so soon.)
新しいハッシュ値はHash2=0000 01ca 680b8388 8d09 12df fcceです。 Hash2の一番左16ビットはすべてゼロです。 したがって、私たちは適当な修飾語を見つけました。 (私たちはそれほど早くそれを見つけるとは非常に幸運でした。)
The input to Hash1 is:
Hash1への入力は以下の通りです。
89a8 a8b2 e858 d8b8 f263 3f44 d2d4 ce9b fe80 0000 0000 0000 00 305c 300d 0609 2a86 4886 f70d 0101 0105 0003 4b00 3048 0241 00c2 c2f1 3730 5454 f10b d9ce a368 44b5 30e9 211a 4b26 2b16 467c b7df ba1f 595c 0194 f275 be5a 4d38 6f2c 3c23 8250 8773 c786 7f9b 3b9e 63a0 9c7b c48f 7a54 ebef af02 0301 0001
89a8 a8b2 e858 d8b8 f263 3f44 d2d4 ce9b fe80 0000 0000 0000 00 305c 300d0609 2a86 4886 f70d0101 0105 0003 4b00 3048 0241 00c2 c2f1 3730 5454f10b d9ce a368 44b5 30e9 211a 4b26 2b16 467c b7df ba1f 595c0194f275 be5a 4d38 6f2c 3c23 8250 8773c786 7f9b 3b9e 63a0 9c7b c48f 7a54 ebef af02 0301 0001
The 64 first bits of the SHA-1 hash value of the above input are Hash1=fd4a 5bf6 ffb4 ca6c. We form an interface identifier from this by writing Sec=1 into the three leftmost bits and by setting bits 6 and 7 (the "u" and "g" bits) to zero. The new interface identifier is 3c4a:5bf6:ffb4:ca6c.
最初に、上記のSHA-1ハッシュ値のビットが入力した64はHash1=fd4a 5bf6 ffb4 ca6cです。 私たちは、これから一番左3ビットへのSec=1に書いて、ビット6と7(「u」と「g」ビット)をゼロに設定することによって、インタフェース識別子を形成します。 新しいインタフェース識別子は3c4a:5bf6:ffb4です: ca6c。
Aura Standards Track [Page 20] RFC 3972 Cryptographically Generated Addresses March 2005
2005年3月にアドレスであると暗号で生成された香気標準化過程[20ページ]RFC3972
Finally, we form the IPv6 address fe80::3c4a:5bf6:ffb4:ca6c. This is the new CGA. No address collisions were detected this time. (Collisions are very rare.) The CGA Parameters data structure associated with the address is the same as the input to Hash1 above.
最終的に、私たちはIPv6アドレスfe80を形成します:、:3c4a:5bf6:ffb4: ca6c。 これは新しいCGAです。 アドレス衝突は全く今回、検出されませんでした。 (衝突は非常にまれです。) アドレスに関連しているCGA Parametersデータ構造はHash1への上記の入力と同じです。
Appendix B. Acknowledgements
付録B.承認
The author gratefully acknowledges the contributions of Jari Arkko, Francis Dupont, Pasi Eronen, Christian Huitema, James Kempf, Pekka Nikander, Michael Roe, Dave Thaler, and other participants of the SEND working group.
作者は感謝してSENDワーキンググループのヤリArkko、フランシス・デュポン、パシEronen、クリスチャンのHuitema、ジェームス・ケンフ、ペッカNikander、マイケルRoe、デーヴThaler、および他の関係者の貢献を承諾します。
Author's Address
作者のアドレス
Tuomas Aura Microsoft Research Roger Needham Building 7 JJ Thomson Avenue Cambridge CB3 0FB United Kingdom
Tuomas香気マイクロソフト研究ロジャーニーダムBuilding7JJトムソン・アベニューケンブリッジCB3 0FBイギリス
Phone: +44 1223 479708 EMail: tuomaura@microsoft.com
以下に電話をしてください。 +44 1223 479708はメールされます: tuomaura@microsoft.com
Aura Standards Track [Page 21] RFC 3972 Cryptographically Generated Addresses March 2005
香気標準化過程[21ページ]RFC3972は2005年3月に暗号でアドレスを作りました。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
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 currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Aura Standards Track [Page 22]
香気標準化過程[22ページ]
一覧
スポンサーリンク
