ログイン
編集不可のページディスカッション情報添付ファイル
"ytoku/DocIPsec"の差分

MMA
1と14のリビジョン間の差分 (その間の編集: 13回)
2011-01-12 01:31:02時点のリビジョン1
サイズ: 3113
編集者: ytoku
コメント:
2011-01-14 04:27:16時点のリビジョン14
サイズ: 9520
編集者: ytoku
コメント:
削除された箇所はこのように表示されます。 追加された箇所はこのように表示されます。
行 1: 行 1:
= この文書の目標 =
想定する読者
 * TCP/IPと暗号に関する知識を持っているが、IPsecの知識に乏しい
 * MMAのVPNを設定したい
{{{#!wiki comment
あらかじめ履修する必要がある科目
 * ネットワーク基礎論
あらかじめ履修する事が望ましい科目
 * 暗号学概論
}}}
到達目標
 * IPsecの体系を俯瞰する
 * VPNの設定を理解できる
 * 詳細な知識が必要な時は何を調べれば良いか分かる
行 3: 行 18:
IPsecのセキュリティプロトコルとして、ペイロードの暗号化・改竄検出のためのESPと、改竄検出のためのAHがある。これらの他に鍵交換のためのIKEがあるがこれは後述する。詳細はマスタリングTCP/IP IPsec編 第1章を参照。
 ペイロード:: 積み荷。(ヘッダなどを除いた)通信の中身のこと。
IPsecのセキュリティプロトコルとして、ペイロードの暗号化・認証のためのESPと、ヘッダも含めた認証のためのAHがある。これらの他に鍵交換のためのIKEがあるがこれは後述する。詳細はマスタリングTCP/IP IPsec編 第1章を参照。
 ペイロード:: 積み荷。IPヘッダなどを除いた通信の中身のこと。ただしIP層の話をしているのでTCPヘッダなどはペイロードに含まれる。
 暗号化:: 狭義には第三者が盗聴しても通信内容を分からないようにすること。
 認証:: 以下では特に明示しない限りメッセージ認証の略として用いる。メッセージ認証とは偽造や改竄がなされていないことを確認することである。
行 6: 行 23:
 AH:: Authentication Header. ヘッダを含めて改竄されていないことをするプロトコル  AH:: Authentication Header. ヘッダを含めて証するプロトコル
行 15: 行 32:
パケットの処理方法として二つのモードがある。挙動をESPの場合で例示すると次のようになる。AHの場合も考えるともう少し複雑である。
一つは、ペイロードを暗号化してからIPヘッダを取り付ける転送モードである。転送モードはエンドポイント同士での暗号化に用いる。
もう一方は、IPパケット自体をペイロードとして暗号化して、新しいIPヘッダを取り付けるトンネルモードである。トンネルモードはルータ間の暗号化などで用いる。
パケットの処理方法として二つのモードがある。挙動をESPの場合で例示すると次のようになる。
一つは、ペイロードだけを暗号化する転送モードである。転送モードはエンドポイント同士での暗号化に用いる。
もう一方は、IPパケット自体を暗号化して、新しいIPヘッダを取り付けるトンネルモードである。トンネルモードはルータ間の暗号化などで用いる。

AHの場合はというと、転送モードでは元のパケット全体が認証の範囲となり、トンネルモードでは元のパケットの外側に新しいIPヘッダを取り付けた上で新しいヘッダを含めた全てが認証の範囲となる。
行 20: 行 39:
  * 転送モード(トランスポートモード)はペイロードが暗号化される。
  * トンネルモードはヘッダ丸ごと暗号化される。
  * トンネルモードはIPヘッダが二重になる。
  * ESP
 
* 転送モード(トランスポートモード)はペイロードが暗号化される。
   * トンネルモードは元のIPヘッダ丸ごと暗号化される。
  * AH
   * どちらのモードもパケット全体が認証される。
   * つまりトンネルモードは新しいIPヘッダさえも認証の範囲内になる。
行 25: 行 49:
IPsecにおける通信はSA(Security Association)という論理的な接続として扱われる。SAには制御用のISAKMP SAと実際の通信内容送るためのIPsec SAがあるが、IPsec SAはプロトコル別かつ一方通行であり、双方向の通信には少なくとも上りと下り計二つのSAが必要になる。 IPsecにおける通信はSA(Security Association)という論理的な接続として扱われる。実際の通信を行うためのSAはプロトコル別かつ一方通行であり、双方向の通信には少なくとも上りと下り計二つのSAが必要になる。なお、SAには実際の通信内容を送るためのSAの他にもIKEによる制御用のSAもあるが、これらの呼び方はIKEのバージョンによって異なるので後述する。
暗号化や認証に必要な鍵はSAと紐付けられることになる。
行 27: 行 52:
SAには識別のためSPIという値が割り振られている。これはセキュリティプロトコル別ある。よって、通信の一端から見るとプロトコルとSPIの組によってSAが区別できる(送信元IPアドレスが必要、あるいは逆に宛先IPアドレスが必要、という情報もあるが)。 SAには識別のためSPIという値が割り振られている。これは実装によってはセキュリティプロトコルによっての空間を持っていることもある。よって、通信の一端から見るとプロトコルとSPIの組によってSAが区別できる(送信元IPアドレスが必要、あるいは逆に宛先IPアドレスが必要、という情報もあるが)。
行 29: 行 54:
また、あるパケットをIPsecで暗号化して通信するかどうか、暗号化する場合はどのプロトコルやモードを使うかという設定をSP(Security Policy)とよぶ。 また、あるパケットをIPsecで暗号化して通信するかどうか、暗号化する場合はどのプロトコルやモードを使うかという設定をSP(Security Policy)とよぶ。なお、SPでSAを直接指定するわけではない。

SPやSAにパケットが一致するかどうかを判定するための属性の集合をセレクタと呼ぶ。ただし受信したパケットのSADに対する照合はSPIを用いて行われるのでセレクタは使用されない(そもそもこの時点ではペイロードが暗号化されているため、セレクタによっては判定できない)。セレクタはリモートIPアドレス・ローカルIPアドレス・上位層プロトコル・名前からなる。
上位層プロトコルとはTCPやICMPなどペイロードのプロトコルであり、そのプロトコルに応じた追加情報が指定できることがある。例えばTCPであればリモートポートとローカルポートが指定できる。
名前の例えばFQDNやX.500識別名などであるが、相手がその名前を持つことの確認方法は実装に任されている。
行 36: 行 65:
 セレクタ:: ルールにパケットが当てはまるかを判定するための属性の集合
----
 ポイント
  * SAは論理的な接続
  * SPは暗号化するかどうかの設定
  * セレクタはパケットを各SA,SPに割り振るための条件
----

== IKEv1 ==
SAで用いる鍵を初めとするパラメータは何らかの方法で安全に共有しなければならない。
手動で設定する方法もあるが、あまり現実的ではない。
特にリプレイ攻撃対策のカウンタが溢れた場合はSAを作り直さないといけないという制約があるので、手動でやっていては事実上リプレイ攻撃対策ができなくなる。

IKEは自動的に鍵交換を行ってSAを作成するためのプロトコルである。UDPの500番ポートを用いて通信する。
IKEにはIKEv1とIKEv2があり、これらの間には互換性がない。
なお、IKEはISAKMPとOakleyの二つのプロトコルに基づいている。
通信相手が本物かどうかを確認するためにIKEは事前共有鍵認証やデジタル署名認証などいくつかの方法を用意している。

IKEv1自体の通信を安全に行うために、パラメータの交換に入る前にIKEの通信のためのSAであるISAKMP SAを作成する必要がある。これに対して実際の通信を行うためのSAをIPsec SAと呼ぶ。つまり、通信はISAKMP SAの確立、IPsec SAの確立の順で行われる。
ISAKMP SAの作成には交換タイプと呼ばれるいくつかの方式がある。よく使われるのはメインモードとアグレッシブモードである。
メインモードはイニシエータIDを平文で送信しないので、事前共有鍵認証の場合には、鍵を特定する手段がIPアドレスしかないためにイニシエータIDはIPアドレスでなければならないという制約があり、IPアドレスが動的に変わる場合には使用できない。
一方、アグレッシブモードではイニシエータIDを最初に平文で送信してしまう。こちらのモードであればイニシエータIDが暗号化されない<<FootNote(そもそもIPアドレスと同じならば、IPヘッダを見れば分かるんじゃないかと思うのだけれど、どういう状況を想定しているんだろう)>>代わりに、イニシエータIDから鍵を特定することが出来るので固定IPアドレスでなくても使用することが出来る。
なお、IPsec SAの作成には一般にクイックモードが用いられる。

 IKE:: Internet Key Exchange. 鍵を交換してSAを生成するプロトコル
 イニシエータ:: IKEによる交換を始める側
 レスポンダ:: IKEによる交換に答える側
 メインモード:: イニシエータIDが暗号化される。ただし事前共有鍵認証では固定IPアドレスでないと使えない。
 アグレッシブモード:: イニシエータIDが暗号化されない。しかし事前共有鍵認証で動的IPアドレスでも使える。

== IKEv2 ==
IKEv2はIKEv1から大きくプロトコルが書き直されている。
まず、SAの呼び方がISAKMP SAからIKE_SAに、IPsec SAからCHILD_SAに変わった。
また、IKEv1にはいくつかの交換タイプがあったがIKEv2では統一された。イニシエータとレスポンダの間でパケットが一往復するのをExchangeとよぶ単位として、四種類のExchangeによって通信が行われる。

IKEv2でも通信相手を認証するための方法として事前共有鍵方式やRSAデジタル署名方式などが用意されているが、IKEv1と異なりイニシエータとレスポンダはおなじ方式を使用する必要がない。
行 40: 行 106:

-----

この文書の目標

想定する読者

  • TCP/IPと暗号に関する知識を持っているが、IPsecの知識に乏しい
  • MMAのVPNを設定したい

到達目標

  • IPsecの体系を俯瞰する
  • VPNの設定を理解できる
  • 詳細な知識が必要な時は何を調べれば良いか分かる

基礎知識

IPsecはIPレベルで暗号化を扱うためのプロトコル(の総体)である。 IPsecのセキュリティプロトコルとして、ペイロードの暗号化・認証のためのESPと、ヘッダも含めた認証のためのAHがある。これらの他に鍵交換のためのIKEがあるがこれは後述する。詳細はマスタリングTCP/IP IPsec編 第1章を参照。

ペイロード
積み荷。IPヘッダなどを除いた通信の中身のこと。ただしIP層の話をしているのでTCPヘッダなどはペイロードに含まれる。
暗号化
狭義には第三者が盗聴しても通信内容を分からないようにすること。
認証
以下では特に明示しない限りメッセージ認証の略として用いる。メッセージ認証とは偽造や改竄がなされていないことを確認することである。
ESP
Encapsulating Security Payload. ペイロードを暗号化・認証するプロトコル。
AH
Authentication Header. ヘッダを含めて認証するプロトコル


  • ポイント
    • ESPだけではヘッダの改竄が可能
    • AHだけでは盗聴が可能
    • ESPとAHは同時に使用することが出来る。


モード

パケットの処理方法として二つのモードがある。挙動をESPの場合で例示すると次のようになる。 一つは、ペイロードだけを暗号化する転送モードである。転送モードはエンドポイント同士での暗号化に用いる。 もう一方は、IPパケット自体を暗号化して、新しいIPヘッダを取り付けるトンネルモードである。トンネルモードはルータ間の暗号化などで用いる。

AHの場合はというと、転送モードでは元のパケット全体が認証の範囲となり、トンネルモードでは元のパケットの外側に新しいIPヘッダを取り付けた上で新しいヘッダを含めた全てが認証の範囲となる。


  • ポイント
    • トンネルモードはIPヘッダが二重になる。
    • ESP
      • 転送モード(トランスポートモード)はペイロードが暗号化される。
      • トンネルモードは元のIPヘッダ丸ごと暗号化される。
    • AH
      • どちらのモードもパケット全体が認証される。
      • つまりトンネルモードは新しいIPヘッダさえも認証の範囲内になる。


SAとSP

IPsecにおける通信はSA(Security Association)という論理的な接続として扱われる。実際の通信を行うためのSAはプロトコル別かつ一方通行であり、双方向の通信には少なくとも上りと下り計二つのSAが必要になる。なお、SAには実際の通信内容を送るためのSAの他にもIKEによる制御用のSAもあるが、これらの呼び方はIKEのバージョンによって異なるので後述する。 暗号化や認証に必要な鍵はSAと紐付けられることになる。

SAには識別のためSPIという値が割り振られている。これは実装によってはセキュリティプロトコルによって別の空間を持っていることもある。よって、通信の一端から見るとプロトコルとSPIの組によってSAが区別できる(送信元IPアドレスが必要、あるいは逆に宛先IPアドレスが必要、という情報もあるが)。

また、あるパケットをIPsecで暗号化して通信するかどうか、暗号化する場合はどのプロトコルやモードを使うかという設定をSP(Security Policy)とよぶ。なお、SPでSAを直接指定するわけではない。

SPやSAにパケットが一致するかどうかを判定するための属性の集合をセレクタと呼ぶ。ただし受信したパケットのSADに対する照合はSPIを用いて行われるのでセレクタは使用されない(そもそもこの時点ではペイロードが暗号化されているため、セレクタによっては判定できない)。セレクタはリモートIPアドレス・ローカルIPアドレス・上位層プロトコル・名前からなる。 上位層プロトコルとはTCPやICMPなどペイロードのプロトコルであり、そのプロトコルに応じた追加情報が指定できることがある。例えばTCPであればリモートポートとローカルポートが指定できる。 名前の例えばFQDNやX.500識別名などであるが、相手がその名前を持つことの確認方法は実装に任されている。

SA
Security Association. IPsecにおける論理的な接続
SAD
Security Association Database
SPI
Security Parameter Index. SAを区別する値
SP
Security Policy. パケットをIPsecで暗号化するかなどの設定
SPD
Security Policy Database
セレクタ
ルールにパケットが当てはまるかを判定するための属性の集合


  • ポイント
    • SAは論理的な接続
    • SPは暗号化するかどうかの設定
    • セレクタはパケットを各SA,SPに割り振るための条件


IKEv1

SAで用いる鍵を初めとするパラメータは何らかの方法で安全に共有しなければならない。 手動で設定する方法もあるが、あまり現実的ではない。 特にリプレイ攻撃対策のカウンタが溢れた場合はSAを作り直さないといけないという制約があるので、手動でやっていては事実上リプレイ攻撃対策ができなくなる。

IKEは自動的に鍵交換を行ってSAを作成するためのプロトコルである。UDPの500番ポートを用いて通信する。 IKEにはIKEv1とIKEv2があり、これらの間には互換性がない。 なお、IKEはISAKMPとOakleyの二つのプロトコルに基づいている。 通信相手が本物かどうかを確認するためにIKEは事前共有鍵認証やデジタル署名認証などいくつかの方法を用意している。

IKEv1自体の通信を安全に行うために、パラメータの交換に入る前にIKEの通信のためのSAであるISAKMP SAを作成する必要がある。これに対して実際の通信を行うためのSAをIPsec SAと呼ぶ。つまり、通信はISAKMP SAの確立、IPsec SAの確立の順で行われる。 ISAKMP SAの作成には交換タイプと呼ばれるいくつかの方式がある。よく使われるのはメインモードとアグレッシブモードである。 メインモードはイニシエータIDを平文で送信しないので、事前共有鍵認証の場合には、鍵を特定する手段がIPアドレスしかないためにイニシエータIDはIPアドレスでなければならないという制約があり、IPアドレスが動的に変わる場合には使用できない。 一方、アグレッシブモードではイニシエータIDを最初に平文で送信してしまう。こちらのモードであればイニシエータIDが暗号化されない1代わりに、イニシエータIDから鍵を特定することが出来るので固定IPアドレスでなくても使用することが出来る。 なお、IPsec SAの作成には一般にクイックモードが用いられる。

IKE
Internet Key Exchange. 鍵を交換してSAを生成するプロトコル
イニシエータ
IKEによる交換を始める側
レスポンダ
IKEによる交換に答える側
メインモード
イニシエータIDが暗号化される。ただし事前共有鍵認証では固定IPアドレスでないと使えない。
アグレッシブモード
イニシエータIDが暗号化されない。しかし事前共有鍵認証で動的IPアドレスでも使える。

IKEv2

IKEv2はIKEv1から大きくプロトコルが書き直されている。 まず、SAの呼び方がISAKMP SAからIKE_SAに、IPsec SAからCHILD_SAに変わった。 また、IKEv1にはいくつかの交換タイプがあったがIKEv2では統一された。イニシエータとレスポンダの間でパケットが一往復するのをExchangeとよぶ単位として、四種類のExchangeによって通信が行われる。

IKEv2でも通信相手を認証するための方法として事前共有鍵方式やRSAデジタル署名方式などが用意されているが、IKEv1と異なりイニシエータとレスポンダはおなじ方式を使用する必要がない。

References


  1. そもそもIPアドレスと同じならば、IPヘッダを見れば分かるんじゃないかと思うのだけれど、どういう状況を想定しているんだろう (1)

ytoku/DocIPsec (最終更新日時 2011-01-30 00:01:39 更新者 ytoku)