一つのIKEv2ログインに二つの識別情報：まずマシン、次にユーザー

クライアント証明書が検証され、最初の交換が完了し、その直後に追加の認証ラウンドに関するエラーで接続が止まる。証明書チェーンに誤りはなく、ネットワークにも変化はない。ゲートウェイは接続側に第二の証明を要求するよう設定されており、クライアントはそれを一度も送らない。誰が何をどの順序で証明するかを決めることがこの作業の全体であり、それは自分が立っている端点からポリシーを読むことから始まる。異なる種類の二つの証明を固定順に置くことは設計判断であって、チェックボックスではない。

症状：最初の証明が成功した後に失敗する

最初の交換が完了し、ログは健全に見える、ゲートウェイがEAPでユーザー識別情報を要求するまで続く。そこでハンドシェイクが停止するか、追加ラウンドを示すプロトコルエラーが返る。完全に有効なマシン証明書が、その有効性とは無関係な理由で拒否される。ポリシーは第二の証明を求めていたが、クライアントの応答はついに届かなかった。

この失敗の説明はどちらも、どこに立つかによって正しい。クライアント側からは有効な証明書を拒否するサーバーに見え、サーバー側からはログインを完了できないクライアントに見える。同じ出来事が、一方のログでは信頼の問題として、他方では能力の問題として読まれる。どちらなのかを教えるのは設定されたポリシーだけである。

拡張が加えるものと加えないもの

IKEv2には、一つのセッション内で複数の認証交換を実行するための拡張がある。RFC 4739は、ほかの順序と並んで、証明書の識別情報を証明した後にEAPで個人を認証するクライアントを概説している。文書の状態はExperimentalであり、どの実装もこの機能を提供する義務を負わない。相手が交渉するまで、対応について何も仮定してはならない。

双方が拡張をサポートし、交換の間にそれに合意する必要がある。二回目のラウンド向けに設定されたゲートウェイはクライアントに実行を強制できず、対応するクライアントもサーバーが求めない限り使用しない。この非対称性のため、失敗は能力についての明確な表明ではなく、通常はタイムアウトやプロトコルエラーとして現れる。片側の設定を読んでも、何が起きるかの半分しか分からない。

端点ごとに一つの証明が通常の形であり、これはその設計ではない。ゲートウェイが自身の証明書を示し、ユーザーがEAPで応答し、各側は相手をちょうど一回認証している。その二つの証明は反対側の端点から来るので、どちらもマシンとそれを使う人物について別個のことは何も言わない。

EAP-TLSは三つ目の形であり、これもその設計ではない。そこではクライアント証明書がEAPメソッドの内部で提示されるため、クライアントは依然として一回のIKE認証を完了する。資格情報は複数ラウンドの場合と同じに見えることがあるが、プロトコルは二回ではなく一回のラウンドを運ぶ。そのためEAP-TLSの配備から複製した設計は、二つ目の証明が期待される地点で失敗する。

同じファイルがゲートウェイ上では別に読める

同じswanctlファイルは、どこで実行されるかによって別に読め、これが人をつまずかせる部分である。ノートPCではゲートウェイが相手であり、ゲートウェイではノートPCが相手なので、local側は「私が誰か」、remote側は「誰を受け入れるか」として書く。localブロックはこの端点が自身をどう認証するかを述べ、remoteブロックはもう一方の端に何を要求するかを述べる。ブロックを二つのファイル間でコピーすると、一文字も変えずに意味が反転する。二つのファイルを比較しても、同じ語がそれぞれで反対の意味を持つため、ほとんど何も分からない。

節の位置は、ラウンド番号が上書きしない限り、その順序を決める。したがって追加のlocalまたはremote節は代替ではなく追加のラウンドを述べ、swanctl.confのリファレンスにある明示的なラウンド番号は、まさにその順序を意図的にするために存在する。それがなければ、ブロックを移動すると動作が変わる。紙の上で等価に見える二つの設定が逆の順序で振る舞うのも同じ理由である。

この順序規則が、覚えておく価値のある故障の型を生む。二つ目のremoteブロックは別の許容可能な選択肢ではなく二つ目の要求であり、だから「どちらか」と読めるポリシーが「そして次に」として振る舞う。ゲートウェイのポリシーは、登録済みマシンの証明書を受け入れた後、そのユーザーのEAP交換をその順序で要求することがある。

ラウンドと独立した要素を区別する

二つのラウンドは自動的に二つの独立した要素ではない。証明を繰り返すこと、あるいは同じ保管庫に二つの資格情報を置くことは、設計が加えるはずだった強度をもたらさない。独立性は秘密がどのように保持され、何がそれを危険にさらすかという性質であり、プロトコルが何回の交換を行うかではない。ラウンドを要素として数える設計は、自分の能力を過大に評価している。この区別が最も重要なのは、コンプライアンスの問いがログインが実際に何要素を使うかを尋ねるときである。

マシン証明書が証明するのは、受け入れられた鍵の所持だけであり、それ以上ではない。ハードウェアの証明ではなく、デバイスの健全性報告でもないので、状態情報を必要とするポリシーは別の仕組みを必要とする。subjectフィールドも、証明書を発行または登録した者が選ぶため、信頼できる在庫タグではない。設計がマシンが健全である証明を必要とするなら、その証明はマシンを測定する構成要素から来なければならない。

各ラウンドが実際に何を証明するかを、追加する前に書き留める。二つのラウンドが同じことを二回証明するとき、二つ目は保証ではなく遅延とサポートチケットを加える。そのメモは、追加のラウンドが費用に見合うかという議論を止めるものでもある。

組み合わせの規則を書き、拒否を試験する

どのマシン識別情報がどの人物と組み合わせられるかを決め、その規則を適用が生きる場所に書く。並んで置かれた二つの有効な資格情報は、組み合わせが認証の結果ではなく認可の決定であるため、組み合わせについて何も証明しない。登録記録または認証バックエンドが、組織が望む関係を適用しなければならない。

次に、未承認のマシン上の受け入れ済みユーザー、マシンの資格情報を持つ未承認ユーザー、追加ラウンドを実行できない相手という、失敗すべきものを試験する。三つすべてが静かに同じアクセスを得るなら、ポリシーは適用ではなく意図を述べている。宣言された設定は、一度も一致しなかった接続が通過した規則とまったく同じに見えるため、デーモンが報告する内容と比較する。

swanctl --list-conns
swanctl --list-sas

成功したログインだけでなく、交渉されたラウンドとそこから生じる認可を確認する。また、近道として古いIKEv1 XAuth設定に手を伸ばさず、接続が成功するまで必要なラウンドを削除するのではなく、プロトコル、役割、順序、クライアントの実際の挙動を一致させる。失敗するラウンドを削除することは、二つの証明の設計が、誰もレビューしていない一つの証明の設計に静かに変わる道である。削除は変更記録に残す。