ネットワーク WG
Request for Comments: 2631
分類: スタンダードトラック

E. Rescorla
RTFM Inc.
1999年 6月

English

Diffie-Hellman 鍵共有法(DH 法)
(Diffie-Hellman Key Agreement Method)

このメモの位置づけ

本書は、インターネットコミュニティに対してインターネットスタンダードトラックのプロトコルを定義するとともに、それを改良するための議論や提言を求めるものである。このプロトコルの標準化状態およびステータスについては、「Internet Official Protocol Standards」 (STD 1) の最新版を参照すること。このメモの配布に制限はない。

著作権表記

Copyright (C) The Internet Society (1999). All Rights Reserved.

要旨

本書は、ANSI X9F1 ワーキング グループによって策定された ANSI X9.42 ドラフトに基づく 1つの特定の DH 法の流儀の 1つを標準化する。DH 法は、2者によって「共有された秘密(shared secret)」を共有するために使われる鍵共有アルゴリズムである。「 共有された秘密(shared secret)」を任意の数の鍵とする材料に変換するためのアルゴリズムが提供される。結果としての鍵とする材料は、対称鍵として使われる。 ここに記述した DH 法の流儀では、受信者が証明書を持つことを要求するが、起点者は、(証明書の中におかれる公開鍵とともに) 無期(static)鍵ペア、もしくは、短期(ephemeral)鍵ペアをもつ可能性がある。

目次

1.はじめに

1.1. 要件についての用語法

2. 手法の概要

2.1. 鍵共有

2.1.1. ZZ の生成
2.1.2. 鍵とする材料(Keying Material)の生成
2.1.3. KEK 算定
2.1.4. 共通鍵アルゴリズムについての鍵長
2.1.5. 公開鍵検証
2.1.6. 例 1
2.1.7. 例 2

2.2. 鍵とパラメータの要件

2.2.1. グループ パラメータ生成
2.2.1.1. p, q の生成
2.2.1.2. g の生成
2.2.2. Group Parameter 検証

2.3. Ephemeral-Static モード

2.4. Static-Static モード

謝辞

参考文献

セキュリティについての考慮事項

著者のアドレス

著作権表記全文

 

1. はじめに English

Diffie と Hellman は、[DH76] において、「共有された秘密(shared secret)」が盗聴者によって入手できないやり方で、2者が秘密を共有するための方法を記述している。この秘密は、他の(共通鍵)アルゴリズムのための暗号技術的な鍵とする材料に変換することができる。この過程については、マイナーな 流儀が数多く存在している。本書は、そのような流儀のひとつで、ANSI X9.42 仕様に基づいたものについて記述する。

1.1. 要件についての用語法 English

本書中に現れるキーワード "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "MAY"は、[RFC2119] に記述されているように解釈されるべきものである。

 

2. 手法の概要 English

DH 法は、メッセージの送信者と受信者の両方が鍵ペアをもつことを要求する。ある者の私有鍵と他者の公開鍵を組み合わせることによって、両者は、同一の 「共有された秘密の数字(shared secret number)」を算定することができる。この数値は、暗号技術的な鍵とする材料に変換することができる。その鍵とする材料は、典型的には、メッセージデータを暗号化するために使われる CEK (content-encryption key: コンテンツ暗号化鍵)を暗号化するための KEK (key-encryption key: 鍵暗号化鍵)として使われる。

2.1. 鍵共有 English

鍵共有過程の最初の段階は、ZZ と呼ばれる「共有された秘密の数字(shared secret number)」を算出することである。同一の起点者と受信者の公開鍵/秘密鍵のペアが使われた場合、同一の ZZ 値が結果となる。ZZ 値は、次に、共有される共通暗号鍵に変換される。起点者が、 無期(static)の私有鍵/公開鍵のペアを採用する場合、公開ランダム値の導入は、結果としての共通鍵は、各鍵共有と異なることを確保する。

2.1.1. ZZ の生成 English

X9.42 は、「共有された秘密(shared secret)」 ZZ が次のように生成されることを規定する。:

ZZ = g ^ (xb * xa) mod p

両者が実際に算出を行うことに注意。:

ZZ = (yb ^ xa) mod p = (ya ^ xb) mod p

ここで、^ は、べき乗(exponentiation)を表現する。

ya は、主体 a の公開鍵; ya = g ^ xa mod p
yb は、主体 b の公開鍵; yb = g ^ xb mod p
xa は、主体 a の私有鍵
xb は、主体 b の私有鍵
p は、大きな素数
q は、大きな素数
g = h^{(p-1)/q} mod p
ここで、hは、h{(p-1)/q} mod p > 1を満たす、1 < h < p-1内の任意の整数。
(gは、位数 q mod pをもつ。すなわち、g^q mod p = 1 if g != 1)
j は、p=qj + 1 となるような大きな数値 (鍵とパラメータについてのクライテリアについては、2.2 節 を参照。)

[CMS] において、受信者の鍵は、CMS RecipientIdentifier によって識別される。これは、受信者の証明書を指示する。送信者の公開鍵は、送信者の証明書を参照することによるか、公開鍵を中に含めることによって、OriginatorIdentifierOrKey フィールドを使って識別される。

2.1.2. 鍵とする材料(Keying Material)の生成 English

X9.42 は、an essentially 任意の数の鍵とする材料 を ZZ から生成するためのアルゴリズムを提供する。我々のアルゴリズムは、いくつかのオプションとしてのフィールドを強制し、他を省略することによって、そのアルゴリズムから派生している。

KM = H ( ZZ || OtherInfo)

H は、暗号技術的ハッシュ関数 SHA-1 である [FIPS-180]。ZZ は、2.1.1 節 において算出される「共有された秘密の数字(shared secret value)」である。先のゼロは、ZZ が p と同じオクテットを占めるように確保されなければならない(MUST)。例えば、p が 1024 bit である場合、ZZ の長さは、128 byte である必要がある。OtherInfo は、次の構造の DER encoding となる。:

OtherInfo ::= SEQUENCE {

keyInfo KeySpecificInfo,
partyAInfo [0] OCTET STRING OPTIONAL,
suppPubInfo [2] OCTET STRING

}

KeySpecificInfo ::= SEQUENCE {

algorithm OBJECT IDENTIFIER,
counter OCTET STRING SIZE (4..4) }

このような ASN.1 規定は、EXPLICIT タグ付けを使うことに注意。(ASN.1 において、EXPLICIT タグ付けは、IMPLICIT が明確に仕様とされていない限り、 暗黙の承認(implicit)である。)

algorithm は、この KEK とともに使われる CEK ラッピングアルゴリズムの ASN.1 アルゴリズム OID である。 これは、AlgorithmIdentifier ではなく、単に OBJECT IDENTIFIER であることに注意。パラメータは、使われない。

counter は、32 bit の数字であり、ネットワークバイト順に表現される。その初期値は、いかなる ZZ についても 1 である。 すなわち、バイト列は、00 00 00 01 (hex) であり、与えられた KEK について上記の鍵生成関数が走る度に 1 インクリメントされる。

partyAInfo は、送信者によって提供されたランダムなストリングである。CMS において、これが(OCTET STRING としてエンコードされた)UserKeyingMaterial フィールドの中のパラメータとして提供された場合、partyAInfo は、512 bit を含まなければならない(MUST)

suppPubInfo は、生成された KEK の bit 単位の長さであり、32 bit の数字としてネットワークバイト順に表現される。例: 3DES については、これは、次のバイト列になる。00 00 00 C0

KEK を生成するためには、1つ以上の KM ブロックを(適切に counter をインクリメントして)十分な材料が生成されるまで生成する。KM ブロックは、左から右に連結される。なわち、KM(counter=1) || KM(counter=2)...

この算出における秘密のエントロピーについての唯一の源泉は、ZZ であることに注意。ZZ よりも長いストリングが生成された場合においても、KEK の有効な鍵空間は、p と q のパラメータによって提起されるあらゆるセキュリティレベルの考慮事項に加えて、ZZ の大きさによって制限される。しかし、partyAInfo が各メッセージについて異なる場合、異なる KEK が各メッセージについて生成される。partyAInfo は、Static-Static モードにおいて使われなければならない(MUST)が、Ephemeral-Static モードにおいて現れる可能性がある(MAY)ことに注意。

2.1.3. KEK 算定 English

各鍵暗号化アルゴリズムは、特定の鍵長 (n) を要求する。KEK は、KM の左端の n byte を鍵にマップすることによって生成される。3DES については、192 bit の鍵とする材料を要求するが、このアルゴリズムは、2回走らなければなら ない。(K1', K2', と K3' の最初の 32 bit を生成するために)counter 値を 1として 1回、(K3 の最後の 32 bit を生成するために) counter 値を 2として 1回走らせる。 K1', K2', K3' は、次に、3 DES 鍵 K1, K2, K3 を生成するために、パリティ調整される。RC2-128 については、128 bit の鍵とする材料を要求するが、このアルゴリズムは、counter 値を 1 として 1回走り、左から 128 bit は、直接、RC2 鍵に変換される。同様に、RC2-40 については、40 bit の鍵とする材料を要求するが、このアルゴリズムは、counter 値を 1 として 1回走り、左から 40 bit が鍵として使われる。

2.1.4. 共通鍵アルゴリズムについての鍵長 English

共通鍵暗号アルゴリズムには、次の鍵長の KEK をもったものがある。

3-key 3DES 192 bit
RC2-128 128 bit
RC2-40 40 bit

RC2 の実効鍵長は、RC2 の実(real)鍵長に等しい。

2.1.5. 公開鍵検証 English

次のアルゴリズムは、受け取った公開鍵 y を検証するために使うことができる(MAY)。

  1. y が [2,p-1] の間にあることを検証する。間にない場合、その鍵は、invalid である。
  2. y^q mod p を算定する。result == 1 である場合、その鍵は、valid である。そうでない場合、その鍵は、invalid である。

公開鍵検証の主な目的は、送信者の鍵ペアについての「小さな部分群攻撃(small subgroup 攻撃)[LAW98]」を防ぐことである。Ephemeral-Static モードが使われている場合、このチェックは、必要不可欠ではない。公開鍵検証の詳細情報について、[P1363] も参照。

この手順は、継続中の特許の対象である可能性があることに注意。

2.1.6. 例 1 English

ZZ は、20 bytes 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13

鍵ラップ アルゴリズムは、3DES-EDE ラップである。

partyAInfo は、使われない。

したがって、SHA-1 の最初の呼び出しに対する入力は、次のとおり。:

00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 ; ZZ

30 1d

30 13

06 0b 2a 86 48 86 f7 0d 01 09 10 03 06 ; 3DES ラップ OID
04 04

00 00 00 01 ; Counter

a2 06

04 04 00 00 00 c0 ; 鍵長

そして、出力は、20 byte。:

a0 96 61 39 23 76 f7 04 4d 90 52 a3 97 88 32 46 b6 7f 5f 1e

SHA-1 の 2番目の呼び出しへの入力。:

00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 ; ZZ
30 1d

30 13

06 0b 2a 86 48 86 f7 0d 01 09 10 03 06 ; 3DES wrap OID
04 04

00 00 00 02 ; Counter

a2 06

04 04
00 00 00 c0 ; 鍵長

そして、出力は、20 byte。:

f6 3e b5 fb 5f 56 d9 b6 a8 34 03 91 c2 d3 45 34 93 2e 11 30

したがって、
K1'=a0 96 61 39 23 76 f7 04
K2'=4d 90 52 a3 97 88 32 46
K3'=b6 7f 5f 1e f6 3e b5 fb

注意: これらの鍵は、パリティ調整されていない。

2.1.7. 例 2 English

ZZ は、次の 20 byte。 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13

鍵ラップ アルゴリズムは、RC2-128 鍵ラップであるので、我々は、128 bit (16 bytes) の鍵とする材料を必要とする。

使われた partyAInfo は、64 byte である。

01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01
01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01
01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01
01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01

したがって、SHA-1 への入力は、次のとおり。:

00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 ; ZZ
30 61

30 13

06 0b 2a 86 48 86 f7 0d 01 09 10 03 07 ; RC2 wrap OID
04 04

00 00 00 01 ; Counter

a0 42

04 40

01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 ; partyAInfo
01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01
01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01
01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01

a2 06

04 04

00 00 00 80 ; 鍵長

出力は、20 byte。:

48 95 0c 46 e0 53 00 75 40 3c ce 72 88 96 04 e0 3e 7b 5d e9

それゆえ、K=48 95 0c 46 e0 53 00 75 40 3c ce 72 88 96 04 e0 となる。

2.2. 鍵とパラメータの要件 English

X9.42 は、グループパラメータが、p=jq + 1 の形態であることを要求する。この q は、長さは、m の大きな素数であり、j>=2 である。この形態の素数を生成するためのアルゴリズムは、補遺 A にある。(FIPS PUB 186-1[FIPS-186] と [X942] にあるアルゴリズムから派生。)

X9.42 は、私有鍵 x が、[2, (q - 2)] の間にあることを要求する。x は、この間に、ランダムに生成される必要がある。y は、g^x mod p を計算することによって算定される。このメモに準拠するためには、m の長さは、>=160 bit でなければならない(MUST)。(したがって、q の長さは、少なくとも160 bit でなければならない(MUST)。) DES よりも強い共通鍵暗号が使われた場合、より大きな m が得策である可能性がある。p の長さは、最低限、512 bit なければならない。

2.2.1. グループパラメータ生成 English

エージェントは、[FIPS-186] と [X942] から派生した次のアルゴリズムを使ってドメインパラメータ (g,p,q) を生成する必要がある(SHOULD)。このアルゴリズムが使われる場合、生成手順の正しさは、2.2.2 節 のアルゴリズムによって、第三者が検証できる。

2.2.1.1. p, q の生成 English

このアルゴリズムは、p, q ペアを生成する。この q の長さは、m であり、p の長さは、L である。

1. m' = m/160 を代入。'/'は、割り算して切り上げることを表現する。

すなわち、200/160 = 2。

2. L'= L/160 を代入。

3. N'= L/1024 を代入。

4. SEED の長さ >= m となるような任意の bit のストリング SEED を選択。

5. U = 0 を代入。

6. For i = 0 to m' - 1

U = U + (SHA1[SEED + i] XOR SHA1[(SEED + m' + i)) * 2^(160 * i)

m=160 について、これは、[FIPS-186] のアルゴリズムから派生することに注意。

U = SHA1[SEED] XOR SHA1[(SEED+1) mod 2^160 ]

5. U mod (2^m) を計算し、最上位 bit (2^(m-1) bit) と最下位 bit を 1 にすることより、q を形成する。論理演算 で書けば、 q = U OR 2^(m-1) OR 1 となる。
2^(m-1) < q < 2^m とすることに注意。

6. q が素数であることをテストするために、堅牢な素数判定アルゴリズムを使う。

7. q が素数でない場合、4 へ。

8. counter = 0 にする。

9. R = seed + 2*m' + (L' * counter) を代入。

10. V = 0 を代入。

12. For i = 0 to L'-1 do

V = V + SHA1(R + i) * 2^(160 * i)

13. W = V mod 2^L を代入。

14. X = W OR 2^(L-1) を代入。

0 <= W < 2^(L-1) であり、よって X >= 2^(L-1) であることに注意。

15. p = X - (X mod (2*q)) + 1 を代入。

16. p > 2^(L-1) である場合、p が素数であるかをテストするために「堅牢な素数判定」を使う。

そうでない場合、18 へ。

17. p が素数である場合、p, q, seed, counter を出力し、ストップ。

18. counter = counter + 1 を代入。

19. counter < (4096 * N) の場合、8 へ。

20. "failure" を出力。

注意: 「堅牢な素数判定」とは、テストを通過する非素数の可能性が、最大でも 2^-80 となるものである。[FIPS-186] は、[X942] のように、適当なアルゴリズムを提供する。

2.2.1.2. g の生成 English

この節は、( [FIPS-186] から派生した)g を生成するためのアルゴリズムを提供する。

1. j = (p - 1)/q とする。

2. h = いかなる数値を代入。 ここで、1 < h < p - 1 であり、かつ、h は、以前に試した、いかなる値とも異なる。

3. g = h^j mod p を代入。

4. g = 1 の場合、step 2 へ。

2.2.2. グループパラメータ検証 English

[PKIX] における DH 鍵についての ASN.1 は、要素 j と、グループパラメータが正しく生成されたことを検証するために鍵の受信者によって使われる可能性がある(MAY)validation-Parms を含む。2つのチェックが可能である。:

  1. p=qj + 1 であることを検証する。このことは、パラメータが X9.42 パラメータ クライテリアに適合することを実証する。
  2. 種(seed)である'seed'について、[FIPS-186] Appendix 2 の p,q 生成手順に従っている場合、'counter' = pgenCounter であるとき p が見つかることを検証する。

これは、「パラメータが、ランダムに選択され、特別な形態をもたないこと」を実証する。

「エージェントが検証情報を、その証明書において提供するか否か」は、そのエージェントと、それらの CA との間におけるローカルなことである。

2.3. Ephemeral-Static モード English

Ephemeral-Static モードにおいて、受信者は、無期(static)(かつ certified)鍵ペアをもつが、送信者は、各メッセージについて新しい鍵ペアを生成し、それをoriginatorKey 保護を使って送る。送信者の鍵が各メッセージについて新たに生成される場合、「共有された秘密(shared secret)」 ZZ は、同様に、各メッセージごとに異なり、partyAInfo は、省略できる(MAY)。それは、めったに同一のペアとなった鍵によって生成された複数の KEK が重複するように働かないからである。しかし、同一の短期的(ephemeral)な送信者鍵が複数のメッセージに使われる場合 (例: これは、性能最適化としてキャッシュされる)、分離した partyAInfo が各メッセージに使われねばならない(MUST)。この標準のすべての実装は、Ephemeral-Static モードを実装しなければならない(MUST)

「小さな部分群攻撃(small subgroup 攻撃)」に耐えるために、受信者は、2.1.5 節 に記述されたチェックを行う必要がある(SHOULD)。 相手が、受信者による復号操作の成功/失敗を判定できない場合、受信者は、このチェックを省略することを選ぶことができる(MAY)。「小さな部分群攻撃(small subgroup 攻撃)」の対象とならない鍵を生成する手法については、[LL97] も参照。

2.4. Static-Static モード English

Static-Static モードにおいて、送信者と受信者の両方は、無期(static)(かつ certified)な鍵ペアをもつ。送信者の鍵と受信者の鍵は、それゆえ、各メッセージについて同一であるので、ZZ は、各メッセージについて同一となる。それゆえ、partyAInfo は、異なるメッセージが KEK を使うことを確保するために使われ(かつ、各メッセージについて異なら) なければならない(MUST)。実装は、Static-Static モードを実装することができる(MAY)

「小さな部分群攻撃(small subgroup 攻撃)」を防ぐために、起点者と受信者の両方は、2.1.5 節 に記述された検証ステップを行うか、CA が正しく鍵の validity を検証したことを検証する必要がある(SHOULD)。「小さな部分群攻撃(small subgroup 攻撃)」の対象とならない鍵生成の手法については、[LL97] も参照。

 

謝辞 English

本書において記述した鍵共有法は、ANSI X9F1 ワーキング グループによって行われた作業に基づいている。著者は、彼らの支援について感謝したい。

著者は、また、Stephen Henson, Paul Hoffman, Russ Housley, Burt Kaliski, Brian Korver, John Linn, Jim Schaad, Mark Schertler, Peter Yee, Robert Zuccherato に、その専門的助言とレヴューについて感謝したい。

 

参考文献

[CMS] Housley, R.,
"Cryptographic Message Syntax",
RFC 2630(English), June 1999.
 
[DH76] Diffie, W. and Hellman, M.E.,
"New directions in cryptography", IEEE Trans. On Information Theory, Vol.IT-22, No.6, pp.644-654, 1976
 
[FIPS-46-1] Federal Information Processing Standards Publication (FIPS PUB) 46-1, Data Encryption Standard, Reaffirmed 1988年 1月22日 (supersedes FIPS PUB 46, 1977 January 15).
 
[FIPS-81] Federal Information Processing Standards Publication (FIPS PUB) 81, DES Modes of Operation, 1980年12月 2日.
 
[FIPS-180] Federal Information Processing Standards Publication (FIPS PUB) 180-1, "Secure Hash Standard", 1995年 4月17日.
 
[FIPS-186] Federal Information Processing Standards Publication (FIPS PUB) 186, "Digital Signature Standard", 1994年 5月19日.
 
[P1363] "Standard Specifications for Public Key Cryptography",
IEEE P1363 working group draft, 1998年, Annex D.
 
[PKIX] Housley, R., Ford, W., Polk, W. and D. Solo,
"Internet X.509 Public Key Infrastructure Certificate and CRL Profile",
RFC 2459, 1999年1月.
 
[LAW98] L. Law, A. Menezes, M. Qu, J. Solinas and S. Vanstone,
"An efficient protocol for authenticated key agreement", Technical report CORR 98-05, University of Waterloo, 1998年.
 
[LL97] C.H. Lim and P.J. Lee,
"A key recovery attack on discrete log-based schemes using a prime order subgroup", B.S. Kaliski, Jr., editor, Advances in Cryptology - Crypto '97, Lecture Notes in Computer Science, vol. 1295, 1997, Springer-Verlag, pp. 249-263.
 
[RFC2119] Bradner, S.,
"Key words for use in RFCs to Indicate Requirement Levels",
BCP 14, RFC 2119, 1997年3月.
 
[X942] "Agreement Of Symmetric Keys Using Diffie-Hellman and MQV Algorithms", ANSI draft, 1998年.
 

 

セキュリティについての考慮事項 English

このシステムにおけるセキュリティのすべては、私有鍵とする材料の守秘性によって提供される。送信者もしくは受信者のいずれかの私有鍵が開示された場合、その鍵を使って送受信されたすべてのメッセージは、不確かなものとされる。同様に、私有鍵の喪失は、その鍵を使って送ったメッセージを読むことができない結果を招く。

Static Diffie-Hellman 鍵は、「小さな部分群攻撃(small subgroup 攻撃)」に対して脆弱である。[LAW98] 実践において、この論点は、「Static-Static モードにおける両者」と「Ephemeral-Static モードにおける受信者」について起きる。2.3 節2.4 節 は、この攻撃に対して保護するための適切な実践を記述する。あるいは、それらがこの攻撃に対して耐性があるようなやり方で、鍵を生成することは可能である。[LL97] 参照。

これらの手法によって提供されるセキュリティレベルは、いくつかの要因に依存する。

これは、次のものに依存する。
- 対称鍵の長さ(典型的には、長さが l bit のとき、2^l セキュリティレベル);
- 素数 q の大きさ(2^{m/2} セキュリティレベル);
- 素数 p の大きさ(ここで、セキュリティレベルは、 準指数関数の bit 単位の大きさに従って上がる。)
良い設計原則とは、バランスがとれたシステムをもつことであり、3つすべてのセキュリティレベルが、およそ同じにする。与えられた p と q のペアから多くの鍵が派生した場合、素数については 、より高いレベルのものをもつことが賢明であろう。いずれにせよ、全体のセキュリティは、3つのレベルの最も低いものによって制限される。

 

著者のアドレス

Eric Rescorla
RTFM Inc.
30 Newell Road, #16
East Palo Alto, CA 94303

EMail: ekr@rtfm.com

翻訳者のアドレス

黒川 貴司
情報処理振興事業協会
セキュリティセンター

EMail: t-kuroka@ipa.go.jp

宮川 寧夫
情報処理振興事業協会
セキュリティセンター

EMail: miyakawa@ipa.go.jp

 

著作権表記全文

Copyright (C) The Internet Society (1999). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.