IKEv1 のハイブリッド認証を IKEv2 のユーザー認証へ移す方法
ハイブリッドモードはゲートウェイの証明とユーザーの証明を分けていた。IKEv2 への移行はその分離を保つが、交換、EAP 方式、証明書の検証は変わる。
サーバー証明書を求め、その後にユーザー名を求める旧式の VPN プロファイルは、ひとつの交換の中に二つの認証イベントを抱えており、その形はそれを導入したプロトコルより長く生き残る。IKEv1 のハイブリッドモードはまさにこのために作られ、ゲートウェイは公開鍵で自分を証明し、ユーザーは後から XAuth で自分を証明する。IKEv2 は同じ二段階の考えを別の仕組みで表し、移行が失敗するのはまさにその違いの部分である。どのバージョン番号も一方を他方に変換することはなく、古いオプション名を新しいプロファイルに写すと、交渉はするが何も認証しないクライアントができあがる。
ハイブリッドモードが IKEv1 の内部で行っていたこと
ハイブリッドプロファイルでは、応答側が第一フェーズ の交換を自身の証明書で署名し、開始側は意図的に証明書を提示しない。したがって身元の証明は非対称であり、これがゲートウェイに既存の PKI を保たせ、ユーザーにディレクトリのパスワードを保たせた。第一フェーズ が完了すると、XAuth は要求と応答として動作し、すでに暗号化された ISAKMP チャネルの中でユーザー名とパスワードの属性を運ぶ。
信頼がどこに落ちるかに注目してほしい。証明書はクライアントがどのゲートウェイに到達したかに答える、XAuth はどのユーザーがアクセスを望むかに答える。どちらも他方を代替せず、任意のサーバー証明書を受け入れるよう設定されたクライアントは、最初の答えを黙って捨てている。ハイブリッドというラベルは、事前共有鍵を使うアグレッシブモードと XAuth の組み合わせにも使われ、同じ利用者体験だが別の構成なので、名前ではなくプロファイルを読むべきである。どちらの変種も標準にならなかった草案に由来するため、二つのベンダーがハイブリッドモードを実装しても互いに接続できないことがある。
IKEv2 が同じ二つの証明に至る仕組み
IKEv2 は作業を IKE_SA_INIT と IKE_AUTH に分ける。最初の交換は身元を一切使わずに提案と鍵を合意し、二番目は IDi、IDr、そして AUTH ペイロードを運ぶ。EAP の下では、開始側の最初の AUTH ペイロードは空のまま送られ、応答側が証明書と署名で先に認証し、その後 EAP の会話が IKE_AUTH メッセージの中で進む。
これを安全にしている仕組みは鍵素材である。成功した EAP 方式はセッション鍵を導出し、開始側の最後の AUTH ペイロードはそれから計算されるので、ユーザーの証明とトンネルの鍵が結びつく。XAuth には同等のものがなく、その属性は第一フェーズ の後に届き、鍵には何も寄与しない。この隙間こそ IKEv2 の枠組みが埋めるために設計されたものであり、動作する IKEv2 ログインが何かを尋ねる前にサーバー証明書を検証するのはそのためだ。
この順序は有用な診断にもなる。クライアントが証明書を見せる前に資格情報について不平を言うなら、それは IKEv2 の EAP 交換をまったく行っていない。
三つの身元を分けておく
三つの身元が一つのフィールドに潰れると移行は失敗する。クライアントが検証するゲートウェイの身元があり、通常は証明書の subject か SAN にある DNS 名である。EAP で提示されるユーザーの身元があり、ドメインログイン、アドレス、あるいは明示的な EAP 身元文字列かもしれない。そして、そのユーザーをネットワークとルートに対応づける認可の源がある。
strongSwan の swanctl 構文はその分離を可視化する：接続はゲートウェイに remote { auth = pubkey } を、ユーザーに local { auth = eap-mschapv2 } を設定し、EAP の身元は別に運ばれる。
新しいプロファイルのユーザー身元が古い XAuth 属性と異なる場合、たとえば短い名前ではなく UPN を使う場合、認証サーバーは未知のユーザーを見ることになり、障害はパスワードの誤りに見える。資格情報を確認する前に身元文字列を確認してほしい。
オプションを対応づけ、そのうえで罠を予期する
対応づけは短く、どの行にも認証の時点でだけ現れる罠がある。
| Legacy hybrid element | IKEv2 equivalent | Where it bites |
|---|---|---|
| Gateway certificate, no client certificate | Responder authenticated with pubkey, initiator with EAP | The server needs an EAP method configured, not just a certificate |
| XAuth username and password | EAP-MSCHAPv2 or an inner method | Password policy and account format differ from the old directory field |
| XAuth attribute replies | IKEv2 configuration payload | Attribute numbering is unrelated; nothing is renamed |
| Proxy IDs from quick mode | TS_i and TS_r in IKE_AUTH | Narrowing on the responder can leave an IKE SA with no child SA |
どの行も単なる改名ではなく、構成ペイロードは型付きの属性リストでアドレスとリゾルバーを届けるが、XAuth の属性空間は独自の発明だった。両者を交換可能とみなすことが、プロファイルがゲートウェイの決して送らない設定を要求する結末につながる。
トラフィックセレクターには独自の警告が必要だ。IKEv1 は関心のあるトラフィックをクイックモード交換に結びついたプロキシ ID で表したが、IKEv2 は IKE_AUTH の間にセレクターを交渉し、応答側がそれを狭めることがある。不一致は子 SA を持たない確立済みの IKE SA を生み、一部のクライアントはそれを嬉しそうに接続済みと表示する。
古い接続を境界として扱う
RFC 9395 は IKEv1 を非推奨としたので旧式のハイブリッド接続は日付のついた互換性の境界であり、土台ではない。切り替えの間は両方のプロファイルを並行して動かすべきで、重要なのは新しいプロファイルが上がるかどうかではなく、同じユーザーが同じ端末で同じ資源に届くかどうかだからだ。
証明書の検証は最後まで厳格に保つ。クライアントが自分の証明書を提示しなくなると、ハンドシェイクが通るまでサーバー検証を緩めたくなるが、それは残った唯一の証明を緑のアイコンと引き換えにすることになる。
古いプロファイルを引退させる前に四つを書き留める：EAP 方式、身元文字列、認可の源、そしてサポートが終わる日付である。