[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
ipsec.list
keyが鍵だったりキーだったり秘密鍵だったりするのを「鍵」に統一して
いただけますか?
itojun
Index: index.list
===================================================================
RCS file: /cvsroot/htdocs/ja/Documentation/network/ipsec/index.list,v
retrieving revision 1.2
diff -u -r1.2 index.list
--- index.list 2000/12/20 04:58:24 1.2
+++ index.list 2001/01/12 16:20:05
@@ -55,7 +55,7 @@
<ul>
<li>Authentication Header (AH): 強い暗号チェックサムをパケットに付加することによってパケットの信頼性を保証します。
AHのついたパケットを受け取りチェックサムが正常なら、
- <em>あなたとpeerが秘密鍵を共有し他の誰もがキーを知らないなら、</em>
+ <em>あなたとpeerが鍵を共有し他の誰もが鍵を知らないなら、</em>
2つのことについて確信できるでしょう。
<ul>
<li>パケットはpeerによって作成され、パケットは偽造されていません。
@@ -67,31 +67,31 @@
<li>Encapsulating Security Payload (ESP): 暗号化アルゴリズムで暗号化されたパケットを機密性を保証します。
ESPでパケットを受け取って、解読に成功したなら
パケットが途中で盗聴されていないと確信できるでしょう。
- <em>あなたとpeerが秘密鍵を共有し、他の誰もがキーを知らないなら。</em>
+ <em>あなたとpeerが鍵を共有し、他の誰もが鍵を知らないなら。</em>
<li>IP payload compression (IPcomp): ESPがパケットに暗号化サービスを提供します。
しかし、暗号化は(ppp compressionのように)伝走路上の圧縮に打撃的な影響を与える傾向があります。
IPcompはESP(IPcompだけを使うことができる)によって暗号化を行う前にパケットを圧縮する方法を提供します。
- <li>Internet Key Exchange (IKE): これまで書いたように、AHとESPはpeerと秘密鍵を共有することが必要となります。
- 遠い場所との通信のために、秘密理にキーを交渉する方法を提供する必要があります。
+ <li>Internet Key Exchange (IKE): これまで書いたように、AHとESPはpeerと鍵を共有することが必要となります。
+ 遠い場所との通信のために、秘密理に鍵を交渉する方法を提供する必要があります。
IKEはそれを可能にします。
</ul>
AH、ESP、IPcompはカーネルに実装されています。
IKEはユーザーランドでデーモンプロセスとして実装されています。
-カーネルとユーザーランドは、キー管理テーブルを通して協調しています。
+カーネルとユーザーランドは、鍵管理テーブルを通して協調しています。
<p>
-IKEはオプションです。AH/ESPのために手作業で秘密鍵を構成することができます。
-しかし、永久に同じ秘密鍵を使うことができないことを理解して下さい。
-もし長い間同じ秘密鍵を使うなら、トラフィックが危険にさらされる可能性がますます高くなります。
+IKEはオプションです。AH/ESPのために手作業で鍵を構成することができます。
+しかし、永久に同じ鍵を使うことができないことを理解して下さい。
+もし長い間同じ鍵を使うなら、トラフィックが危険にさらされる可能性がますます高くなります。
<p>
-NOTE: <strong>IPsecプロトコルのセキュリティーは秘密鍵の機密性如何です。
+NOTE: <strong>IPsecプロトコルのセキュリティーは鍵の機密性如何です。
</strong>
-もし秘密鍵が危険にさらされるなら、IPsecプロトコルは安全であり得ません。
-設定ファイル、キーデータベースファイルのパーミッションあるいは情報漏洩につながるかも知れないさまざまなことに注意して下さい。
+もし鍵が危険にさらされるなら、IPsecプロトコルは安全であり得ません。
+設定ファイル、鍵データベースファイルのパーミッションあるいは情報漏洩につながるかも知れないさまざまなことに注意して下さい。
<pre>
@@ -215,8 +215,8 @@
</ol>
<ENTRY>sample_esp 設定例: ホスト間の暗号化
-もしマニュアルで設定した秘密鍵でホスト間の暗号化(トランスポートモード)を行うなら、
-下記の構成で充分です。マニュアルでキーを設定するために<a href="http://www.flame.org/cgi-bin/uncgi/hman?page=setkey&sect=8">setkey(8)</a>を
+もしマニュアルで設定した鍵でホスト間の暗号化(トランスポートモード)を行うなら、
+下記の構成で充分です。マニュアルで鍵を設定するために<a href="http://www.flame.org/cgi-bin/uncgi/hman?page=setkey&sect=8">setkey(8)</a>を
使用します。
<pre>
#! /bin/sh
@@ -231,20 +231,20 @@
</pre>
<p>
-最初の2つの行は、ESPで使用する秘密鍵を設定しています。
+最初の2つの行は、ESPで使用する鍵を設定しています。
4番目の数字は SPI(セキュリティー・パラメーター・インデックス)と呼ばれています。
-この値はESPパケットに付加され、受信した側でパケットから秘密鍵を見つけるために送られます。
+この値はESPパケットに付加され、受信した側でパケットから鍵を見つけるために送られます。
この値はノード上でユニークである必要があります。
<ul>
- <li>10.1.1.1から20.1.1.1に、秘密鍵<tt>hogehoge</tt>で、DES-CBCアルゴリズムを使います。
+ <li>10.1.1.1から20.1.1.1に、鍵<tt>hogehoge</tt>で、DES-CBCアルゴリズムを使います。
トラフィックは SPI値9876によって識別されます。
- <li>20.1.1.1から10.1.1.1に、秘密鍵<tt>mogamoga</tt>で、DES-CBCアルゴリズムを使います。
+ <li>20.1.1.1から10.1.1.1に、鍵<tt>mogamoga</tt>で、DES-CBCアルゴリズムを使います。
トラフィックは SPI値10000によって識別されます。
</ul>
<p>
最終行はノードのパケット毎のIPsecポリシーを設定しています。
-この設定で、node(10.1.1.1)からpeer(20.1.1.1)に送られるパケットは暗号化されます。秘密鍵はカーネル内部
+この設定で、node(10.1.1.1)からpeer(20.1.1.1)に送られるパケットは暗号化されます。鍵はカーネル内部
で構成されます。
この設定は、20.1.1.1から10.1.1.1に届く暗号化されていないパケットを禁止していません。
もし暗号化されていないパケットを拒否したい場合、次の行を追加して下さい。
@@ -264,14 +264,14 @@
<p>
-上記の例は人間が読むことができる秘密鍵を使います。
-しかしながら、人間が読むことができる秘密鍵の使用がバイナリーキーより危険であることから、
-実際のオペレーションでは、バイナリーキーを使用する方がいいでしょう。
+上記の例は人間が読むことができる鍵を使います。
+しかしながら、人間が読むことができる鍵の使用がバイナリー鍵より危険であることから、
+実際のオペレーションでは、バイナリー鍵を使用する方がいいでしょう。
<p>
-キーの長さはアルゴリズムによって決定されます。
-des-cbcでは、秘密鍵は64ビット(=8バイト)でなければなりません。
-もしそれより短いまたは長いキーを指定するなら、<a href="http://www.flame.org/cgi-bin/uncgi/hman?page=setkey&sect=8">setkey(8)</a>はエラーになるでしょう。
+鍵の長さはアルゴリズムによって決定されます。
+des-cbcでは、鍵は64ビット(=8バイト)でなければなりません。
+もしそれより短いまたは長い鍵を指定するなら、<a href="http://www.flame.org/cgi-bin/uncgi/hman?page=setkey&sect=8">setkey(8)</a>はエラーになるでしょう。
<ENTRY>sample_ah 設定例: ホスト間の認証
ESPと同じように、AHを設定することができます。
@@ -289,7 +289,7 @@
<p>
<ENTRY>sample_both 設定例: ホスト間の暗号化+認証
-もしAHとESP双方で秘密鍵を設定した場合、双方とも使うことができます。
+もしAHとESP双方で鍵を設定した場合、双方とも使うことができます。
IPsecのドキュメントでは、AHの後にESPを適用することを推奨しています 。
<pre>
#! /bin/sh
@@ -308,7 +308,7 @@
<ENTRY>sample_vpn 設定例: VPN
(to be written)
-<ENTRY>config_ike IKEによるAH/ESPキーの設定
+<ENTRY>config_ike IKEによるAH/ESP鍵の設定
(to be written)
<ENTRY>conformance 標準化、互換性への適合
@@ -331,7 +331,7 @@
IPsecの知識がありユーザーランドのコードを書きたいなら、あなたはIPsecプラットフォーム間のAPI互換性について知りたくなるしょう。
<p>
-我々はカーネル内に秘密鍵データベースを操作するためにRFC2367 PF_KEY APIを持っています。
+我々はカーネル内に鍵データベースを操作するためにRFC2367 PF_KEY APIを持っています。
このAPIの基本的な部分は他のUNIXベースのIPsecスタック上で利用可能であり、そしてある程度(例えば、OpenBSDが同様にPF_KEY APIを実行する)の互換性があるかも知れません。
かめIPsecスタックが、他のグループがそうするのと同じように、ある特定の方法でこれを拡張します。
拡張された部分は他の(非かめ)IPsecスタックと両立できません。
@@ -351,11 +351,11 @@
<ul>
<li>NetBSD-current は1999年12月下旬にかめIPsecスタックを取り込んでいます。
<li>FreeBSD-current は1999年12月初旬にかめIPsecスタックを取り込んでいます。
- <li>マニュアルでのipsecキー設定、 AH/ESPオペレーションまたは
+ <li>マニュアルでのipsec鍵設定、 AH/ESPオペレーションまたは
ipsec_set_policy(3) APIはカーネルにおける相違はありません。
<li>PF_KEYソケット、libipsec API、PF_KEYラッパー関数などには違いがあります。
直接PK_KEYソケットを操作する
- (racoon(8)のようなIKEデーモンやsetkey(8)のようなキー設定プログラム)
+ (racoon(8)のようなIKEデーモンやsetkey(8)のような鍵設定プログラム)
アプリケーションを実装する際に、その違いは辛いかもしれません。
</ul>