$Id: report-ike.txt,v 1.1.1.1 1999/10/26 17:19:16 sakane Exp $ %Hd: Internet Key Exchange (IKE) なぜ自動鍵管理が必要か？ o IPsecなどで通信をSAで保護する時、通信するノード間で 鍵と呼ばれる秘密の情報を共有しなければならない。 o 秘密の情報をカーネルに教えるには、 管理者が互いにネゴして手で設定する。 デーモンが自動的にネゴして勝手に設定する。 o 以前のIPsecでは、マニュアルによる鍵管理を実装必須としてきたが、 手で設定するのは面倒。 SAは一方向なので管理が面倒。 DHCPやmobile-nodeに対応したい。＃できる？ な要因により、自動的な鍵管理が必須となった。 ISAKMP draft-ietf-ipsec-isakmp-10.txt July 3, 1998 o 鍵情報を交換するための枠組を定義している。 他にも SKIP, Photuris とかがある(った)。 SKIP は inband. 何故負けた？ Photuris は？ o 枠組なので悪く言うと決めなきゃならないことが多々ある。 ドラフトが散る。-> 分かりづらい。 o IPv4 でオプション、IPv6 で実装必須となっている。 IKE (元ISAKMP with Oakley) draft-ietf-ipsec-isakmp-oakley-08.txt June 1998 o 混合プロトコル Internet Security Association and Key Management Protocol 鍵交換の枠組 The OAKLEY Key Determination Protocol 認証付の鍵交換のためのペイロードの構成や情報まで定義 draft-ietf-ipsec-oakley-02.txt SKEME A Versatile Secure Key Exchange Mechanism for Internet o 認証付の鍵情報を交換するプロトコル。 IKE自身のSAの確立 他のプロトコルで使用する鍵情報の交換 o Phase 1 と Phase 2 にわけられる。 Phase 1 -> IKE の SA をネゴる Phase 2 -> IPsec の SA をネゴる o IPSEC SAを自動的に確立するには Security Architecture for the Internet Protocol draft-ietf-ipsec-arch-sec-02.txt PF_KEY Key Management API, Version 2 draft-mcdonald-pf-key-v2-05.txt A Simple IP Security API Extension to BSD Sockets draft-mcdonald-simple-ipsec-api-01.txt などと組み合わせて、よく考えないとダメ。 IKE の位置付け +------------+ +--------+ +--------------+ | DOI | | | | Application | | Definition | <----> | IKE | | Process | +------------+ --> | | |--------------| +--------------+ | +--------+ | Appl Protocol| | Key Exchange | | ^ ^ +--------------+ | Definition |<-- | | ^ +--------------+ | | | | | | |----------------| | | v | | +-------+ v v | API | +---------------------------------------------+ +-------+ | Socket Layer | | |---------------------------------------------| v | Transport Protocol (TCP / UDP) | +----------+ |---------------------------------------------| | Security | <----> | IP | | Protocol | |---------------------------------------------| +----------+ | Link Layer Protocol | +---------------------------------------------+ IPSEC-DOI ISAKMPの枠組の中での IPSEC 固有の定義 Phase 1 o ISAKMP SAを確立する。 o Main Mode と Aggressive Mode を選べる。 Main Mode ISAKMP の Identity Protection Exchangeを使用。 実装MUST Aggressive Mode ISAKMP の Aggressive Exchange を使用。 実装SHOULD ラウンドトリップを削減するために使用される。 認証方式にRSAを使用した時のみ identity が保護される。 o 暗号鍵、認証鍵の元になる情報の交換に Basic DHを使用している。 MODP(MUST), EC2N(SHOULD) o 認証アルゴリズム pre-shared key(MUST), DSS(SHOULD), RSA(SHOULD) を選べる。 ＊どれも共有の情報を既に持っているのが前提！＊ それぞれ証明書、公開鍵、共有鍵 o ハッシュアルゴリズム MD5(MUST), SHA(MUST), Tiger(SHOULD) o 暗号アルゴリズム DES(MUST), 3DES(SHOULD), IDEA, Blowfish, RC5-R16-B64, CAST Phase 1 Main Mode Authenticated With Signatures Initiator Responder ---------- ----------- 1) HDR, SA --> <-- HDR, SA 3) HDR, KE, Ni --> <-- HDR, KE, Nr 5) HDR*, IDii, [ CERT, ] SIG_I --> <-- HDR*, IDir, [ CERT, ] SIG_R 1) initiator は、SA(Proposal(Transform)) Payload を送信する。 複数の proposal を投げれる。 2) responder は、許容できるProposalを１つ選択し無修正で返答する。 嫌だったらはねる。 3),4) 共通秘密情報を得るためのDH鍵情報を交換し、DH共有鍵を得る。 この時点では、man-in-the-middle 攻撃の可能性が残る。 5),6) DH共有鍵より暗号鍵、認証鍵を作成。 SKEYID = prf(Ni | Nr, g^xy) SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0) SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1) SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2) 自己情報と署名を交換する。これにより相手が認証される。 自己情報って？ IPアドレス、E-Mailアドレス、… Phase 1 Main Mode Authenticated with Pre-Shared Key Initiator Responder ---------- ----------- 1) HDR, SA(n) --> <-- 2) HDR, SA 3) HDR, KE, Ni --> <-- 4) HDR, KE, Nr 5) HDR*, IDii, HASH_I --> <-- 6) HDR*, IDir, HASH_R 1) initiator は、SA(Proposal(Transform)) Payload を送信する。 2) responder は、許容できるProposalを１つ選択し無修正で返答する。 3),4) 共通秘密情報を得るためのDH鍵情報を交換し、DH共有鍵を得る。 この時点で man-in-the-middle 攻撃の可能性が残る。 5),6) DH共有鍵と既に所有している共通の鍵を用いて暗号鍵、認証鍵を作成。 SAと自己情報のHASHを暗号化し交換する。 これにより相手が認証される。 SKEYID = prf(pre-shared-key, Ni | Nr) SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0) SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1) SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2) HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAp | IDii) HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAp | IDir) Phase 1 Aggressive mode with a pre-shared key Initiator Responder ----------- ----------- 1) HDR, SA, KE, Ni, IDii --> <-- 2) HDR, SA, KE, Nr, IDir, HASH_R 3) HDR, HASH_I --> 1) initiator は、SA(Proposal(Transform)) Payload, 共通秘密情報を作るための鍵情報、さらに自己情報を送信する。 2) responder は、許容できるProposalを１つ選択し返答し、 共通秘密情報を作るための鍵情報、さらに自己情報とHASHを送信する。 3) 2)で受け取った情報を確認し、HASHを送信する。 Phase 1 Main Mode Authenticated With a Revised Mode of Public Key Encryption Initiator Responder ----------- ----------- HDR, SA --> <-- HDR, SA HDR, [ HASH(1), ] Pubkey_r, Ke_i, Ke_i, [<Ke_i] --> HDR, PubKey_i, Ke_r, <-- Ke_r, HDR*, HASH_I --> <-- HDR*, HASH_R SKEYID = prf(Ni | Nr, CKY-I | CKY-R) SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0) SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1) SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2) HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAp | IDii) HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAp | IDir) Phase 1 よろず o DES-CBC の weak key check を行わなければならない。 o MD5, SHA をサポートしなければならない。 o pre-shared key による認証をサポートしなければならない。 o DSS, RSA はサポートするべき o DH-Exchange の Group Type MODP (modular exponentiation group) default ECP (elliptic curve group over GF[P]) MAY o cookie の作成は、 draft-simpson-photuris-15.txt: 3.3. Cookie Generation を参考。 o ISAKMP-SAを識別するために使用するので、順序は変更してはならない。 o Initiator の proposal が修正されている場合は、それを拒否しなければ ならない。 o message id は常に 0 o ある Exchange の最中に別の Exchange を使用してはならない。 o phase 1 で使用される SA payload は、 draft-ietf-ipsec-isakmp-oakley-08.txt: 7.1 draft-ietf-ipsec-isakmp-10.txt: 3.4 を参照。 o Phase 1 の最初の IV IV = hash(g^xi | g^xr) 以降 IV = 前回暗号化したデータの後ろ8バイト Phase 2 o セキュリティプロトコルの鍵を交換する。 o ISAKMP-SAに保護される。 -> 必ずPhase 1 の後に使用。 Quick Mode 実装MUST Initiator Responder ----------- ----------- HDR*, HASH(1), SA, Ni [, KE ] [, IDui, IDur ] --> <-- HDR*, HASH(2), SA, Nr [, KE ] [, IDui, IDur ] HDR*, HASH(3) --> o ペイロードの順序は規定されない。 o Nonce Payload, Key Exchange payload(オプション) が使用される。 Key Exchange Payload を使用する事により PFS が提供される。 o その場合、DHのグループを送信しなければならない。 Phase 2 よろず o HASHの計算方法は以下の通り。 HASH(1) = prf(SKEYID_a, M-ID | SA | Ni [ | KE ] [ | IDui | IDur ]) HASH(2) = prf(SKEYID_a, M-ID | Ni | SA | Nr [ | KE ] [ | IDui | IDur ]) HASH(3) = prf(SKEYID_a, 0 | M-ID | Ni | Nr) o IV IV = hash(last CBC block of Phase 1 | M-ID) 以降 IV = 前回暗号化したデータの後ろ8バイト New Group Mode o phase 1 の直後にのみ使用される。 o 実装SHOULD o DH exchange のプライベートグループを定義する機構。 Initiator Responder ----------- ----------- HDR*, HASH(1), SA --> <-- HDR*, HASH(2), SA o default 以外の group を使いたい場合。 phase 1 の後、phase 2 の前 Informational Exchanges o phase 1 の一部, phase 2 で使用される。 Initiator Responder ----------- ----------- HDR*, HASH(1), N/D --> 今回(1998/3現在)の実装では… ISAKMP with Oakley (draft-ietf-ipsec-isakmp-oakley-05.txt)で定義される、 Main/Aggressive Mode with Pre-Shared Key を実装する。 ISAKMP の処理の詳細は draft-ietf-ipsec-isakmp-08.txt を参照する。 また IPSEC-DOI は draft-ietf-ipsec-ipsec-doi-06.txt を参照する。 暗号化モジュールは、全て SSLeay を使用する。 SSLeay-0.8.0/crypto で make 後、libcrypto.a を使用。 IPSEC Situation Identification Payload で指定される。 SIT_IDENTITY_ONLY, SIT_SECRECY, SIT_INTEGRITY がある。 SIT_IDENTITY_ONLY のみ実装する。 IPSEC Security Protocol PROTO_ISAKMP, PROTO_IPSEC_AH, PROTO_IPSEC_ESP, PROTO_IPCOMP がある。 PROTO_ISAKMP, PROTO_IPSEC_AH, PROTO_IPSEC_ESP のみ実装する。 IPSEC ISAKMP Transform KEY_OAKLEY を実装する。 IPSEC Security Association Attributes SA Life Type, SA Duration, Auth Algorithm のみを実装する。 SA Life Type, SA Duration のデフォルトは、28800 (s)(8 hours) とする。 バイト単位のLife Typeは未対応。 その後の予定 認証方式として DSS も対応するつもりである。 configurable なもの ログのレベル 再送タイマ 再送回数 最大padding長 : remote address 毎につけたい。 isakmp-sa attributes ipsec-sa attributes 主な動作 o schedule は n 秒間隔でなめる。status による処理。 signal は使わない。time() の差分で処理。 CPU負荷問題があるので、signal処理しないとダメか？ o encrypted session(ES), non-encrypted session(NES), schedule(S) テーブルをメンテナンスする。 TODO o status をあげるタイミングをよく考える。 o 再送のタイミングをずらす。 o HASH長,鍵長をかっこよく持つ。 実装中にふって湧いた疑問 ISAKMP-SAの単位問題 2つのノードにISAKMP-SAが1つだと、IPSEC-SAで1組の鍵が交換される。 どっちがInitiateするか問題 - ISAKMP-SAがexpireした時 - 同時に ISAKMP-SAネゴが始まる状態。 - IPSEC-SAを同時に交換するような状態。 お互いのInitiatorを予め決めておくか？ ＃remote address で蹴る。 ＃A, B 間のネゴ完了後、Aが再起動して ＃Aからネゴしたら B が蹴ってしまう。 ＃＃あれば使い、無ければ使う。 ISAKMP-SAが双方向に1つだと、上記問題は片付く。 しかし… IPSEC-SAが2つ出来るので2組の鍵が交換される。 全体の動作からは2組の鍵が出来ても問題無いが、気持ちが悪い… 現状は後者で実装。 draft-ietf-ipsec-isakmp-oakley-06.txt 4. Introduction The ISAKMP SA is bi-directional. That is, once established, either party may initiate Quick Mode, Informational, and New Group Mode Exchanges. Per the base ISAKMP document, the ISAKMP SA is identified by the Initiator's cookie followed by the Responder's cookie-- the role of each party in the phase 1 exchange dictates which cookie is the Initiator's. The cookie order established by the phase 1 exchange continues to identify the ISAKMP SA regardless of the direction the Quick Mode, Informational, or New Group exchange. In other words, the cookies MUST NOT swap places when the direction of the ISAKMP SA changes. ＃＃はっちゃいけないとは言ってない。 retry 中のSAの発見 はっきりさせろ。と ESP DES-HMAC_MD5 の時の鍵の計算は？ DES と HMAC_MD5 にそれぞれ鍵が必要。 1つのKEYMATからどうやって？ 多分、伸ばして切るんだと思う。 ＃同じ物を使っても良い。 padding 長 パケットの最後にpaddingしたバイト数を含めるが、 draft は padding byte length となっている。 isakmp-test.ssh.fi は入れてないっぽい。 各 mode の最後で responder 側は再送するべきか？ responder の Phase 1 の最後は再送しない？ 例えば、phase 2 において Initiator Responder SAiを送信 -- SAi --> SAiを受信 <- SAr --- SArを送信 SArを受信 HASHを送信 -- HASH -> SAirを設定 HASHを受信失敗！ HASHの再送しないんだろうか？ ＃＃initator は SAr を受けたらとにかくHASHを送る。 Aggressive mode の phase 2 の IV IV は phase 1 の最後の暗号化済パケットの 後ろ8バイトから作るが、このモードは暗号化しないから… proxy する時のIPSEC-SAのネゴ方法。 IDir とかを使う？ ＃まだ良く調べてない… phase 2 の ID ってアドレスだけ？ SUBNET タイプで ::1/128 って送るのあり？ ２つのINFOメッセージ ISAKMP_NTYPE_INVALID_MAJOR_VERSION ISAKMP_NTYPE_INVALID_MINOR_VERSION があるのは変？ version が 1.5 の時、0.3 を受けたら両方返すのか？ 3. Check the Major and Minor Version fields to confirm they are correct. If the Version field validation fails, the message is discarded and the following actions are taken: ＃＃major が違ったら minor は見ない half connection 攻撃はどうやって防ぐ？ 動的フィルタリング？ 解決した？ phase2 の HASH(1,2,3)計算の時の M-ID の order と size. network byte order で 4 octet pluto 問題 o Phase1 でSPIのフィールドを使っている。 無視。＃意図は？ o KE payload のデータの最初が 0x00 となっている。 長さが１つ多い。 o SHA1 のkeyFinishを 16 でやっている 20！ o ID のportを 0 決め打ち。さらにportを見てない。 元のデータ長が8の倍数か、否かが判別つかない o IPSEC Security Association Attributes が古い そもそも古い 再送されたパケットを受け取った時。 phase 1: nptype, status で処理済か分かる。 phase 2: status でなんとかする。 ずれるIV問題 直前に暗号化処理したパケットの一部を次回のIVとしている。 送信側は前回暗号化したパケットの一部。 受信側は前回復号化したパケットの一部。 再送は暗号化済みのパケットを使う。 ここで… 再送されたパケットを受信して、 復号化は成功する。 複合化した後エラーが起こる。or 暗号化時した後にエラーが起こる。 と、2つのノード間でIVがずれる事となり通信出来なくなる。 複合化処理する前にIVを保存してエラー、または既に処理済みのパケット の場合IVを元に戻す。 処理済みのパケットまたはエラーの場合は、IV を戻すようにする？ と言うか正常終了した時、IVを更新する？ IV = IVe = IVd なバッファを持って、 decode は IVd を使って IVe へ保存。 encode は IVe を使って IV へ保存。 処理終了後 IV = IVe = IVd。 まだ！＃＃phase 1 の最後 ２つ持つ。 isakmp-sa が expire した後、cookies は変える？ 変える。 別IPSEC-SAネゴが連続する場合。 １つのISAKMP-SA内で、同時に別々のmsgidで複数のIPSEC-SAネゴはできない。 IVがずれるので、１つのネゴが終ってから、次のネゴる。 -> 違う。M-ID を変えて別のネゴとして扱う。 ISAKMP-SA が expire した時。 - Initiator側 o IPSEC-SAネゴ中か見る。無ければ削除して再ネゴ。 あれば status に expired flag 立てる。 o IPSEC-SAをネゴ終了後、status を削除して再ネゴ。 別問題: ネゴ中にIPSEC-SAリクエストが来たら。 -> キューが必要…(-_-; o IPSEC-SAネゴ中に、ISAKMP-SAがexpireして、 IPSEC-SAネゴが終るのを待っている間に、 さらにIPSEC-SAネゴ要求が来たら？ -> やっぱりキューが必要。 - Responder側 o IPSEC-SAネゴ中か見る。無ければ削除。 あれば status に expired flag 立てる。 o IPSEC-SAをネゴ終了後、status を削除。 o SA Payload のいろいろ - EX Protocol 1 is ESP with Transform 1 as DES INITIATOR (1) DES SA NP=xx Prop NP=0, Prop#=1, ProtID=ESP, #Tran=1, SPI Tran NP=0, Tran#=1, TranID=DES, SAattr - EX Protocol 1 is AH with Transform 1 as SHA Protocol 2 is ESP with Transform 1 as DES INITIATOR (1) SHA AND DES SA NP=xx Prop NP=Prop, Prop#=1, ProtID=AH, #Tran=1, SPI Tran NP=0, Tran#=1, TranID=SHA, SAattr Prop NP=0, Prop#=1, ProtID=ESP, #Tran=1, SPI Tran NP=0, Tran#=1, TranID=DES, SAattr - EX Protocol 1 is AH with Transform 1 as SHA Protocol 2 is ESP with Transform 1 as 3DES Transform 2 as DES INITIATOR (1) SHA AND 3DES (2) SHA AND DES SA NP=xx Prop NP=Prop, Prop#=1, ProtID=AH, #Tran=1, SPI Tran NP=0, Tran#=1, TranID=SHA, SAattr Prop NP=0, Prop#=1, ProtID=ESP, #Tran=2, SPI Tran NP=Tran, Tran#=1, TranID=3DES, SAattr Tran NP=0, Tran#=2, TranID=DES, SAattr RESPONDER (1) SHA AND 3DES SA NP=xx Prop NP=Prop, Prop#=1, ProtID=AH, #Tran=1, SPI Tran NP=0, Tran#=1, TranID=SHA, SAattr Prop NP=0, Prop#=1, ProtID=ESP, #Tran=1, SPI Tran NP=0, Tran#=1, TranID=3DES, SAattr (2) SHA AND DES SA NP=xx Prop NP=Prop, Prop#=1, ProtID=AH, #Tran=1, SPI Tran NP=0, Tran#=1, TranID=SHA, SAattr Prop NP=0, Prop#=1, ProtID=ESP, #Tran=1, SPI Tran NP=0, Tran#=1, TranID=DES, SAattr - EX Proposal 1 with Protocol 1 as AH with Transform 1 as MD5 Protocol 2 as ESP with Transform 1 as 3DES Proposal 2 with Protocol 1 as ESP with Transform 1 as DES Transform 2 as 3DES INITIATOR (1) MD5 AND 3DES (2) DES (3) 3DES SA NP=xx Prop NP=Prop, Prop#=1, ProtID=AH, #Tran=1, SPI Tran NP=0, Tran#=1, TranID=MD5, SAattr Prop NP=Prop, Prop#=1, ProtID=ESP, #Tran=1, SPI Tran NP=0, Tran#=1, TranID=3DES, SAattr Prop NP=0, Prop#=2, ProtID=ESP, #Tran=2, SPI Tran NP=Tran, Tran#=1, TranID=DES, SAattr Tran NP=0, Tran#=2, TranID=3DES, SAattr RESPONDER (1) MD5 AND 3DES SA NP=xx Prop NP=Prop, Prop#=1, ProtID=AH, #Tran=1, SPI Tran NP=0, Tran#=1, TranID=MD5, SAattr Prop NP=0 Prop#=1, ProtID=ESP, #Tran=1, SPI Tran NP=0, Tran#=1, TranID=3DES, SAattr (2) DES SA NP=xx Prop NP=0, Prop#=1, ProtID=ESP, #Tran=1, SPI Tran NP=0, Tran#=1, TranID=DES, SAattr (3) 3DES SA NP=xx Prop NP=0, Prop#=1, ProtID=ESP, #Tran=1, SPI Tran NP=0, Tran#=1, TranID=3DES, SAattr o SAの決定方法 記法 draft-ietf-ipsec-isakmp-oakley-05.txt: 3.2 を参照。 HDR: ISAKMP ヘッダ。 SA: SAを定義するペイロード。 1つ以上のProposal Payload. 1つ以上のTransform Payload. initiator は複数の Proposal を提示しても良い。 responder は1つ選んで返答しなければならない。 SAp: SAペイロードから、ISAKMPヘッダを除いたもの。 KE: Key Exchange Payload. IDx: "x" の Identity Payload. "x" は initiator として "ii","ui"、responder として "ir","ur" がある。 IDのフォーマットは、DOI に定義されている。 HASH: Hash Payload. HASHの内容は、認証方法に依存する。 SIG: Signature Payload. サインすべきデータは、Exchange 依存である。 AUTH: HASH, SIG などの認証機構。 NONCE: Nonce Payload. '*': ペイロードは暗号化されていることを示す。 ISAKMPヘッダ以降は全て暗号化されていなければならない。 g^x: DH公開情報。"x" := "xi" or "xr" Nx: Nonce payload. "x" := "i" or "r"。 CERT: Certificate Payload. prf(key, msg): 疑似乱数関数。HMACなど。 SKEYID: 通信している同士のみ知る値から、新たに作成される情報。 SKEYID_e: ISAKMP-SAを保護するための情報 SKEYID_a: ISAKMP-SAを認証するための情報。 SKEYID_d: ISAKMP以外のSAを作成するために使用する情報。 y: 鍵 "y" で "x" は暗号化されている。 --> initiator から responder への通信。 <-- responder から initiator への通信。 | 結合。 [x] "x" はオプション。