複数のリモート ユーザーがプライベート ネットワークにアクセスできるように IKEv2 VPN ゲートウェイを構成したいと思います。
レスポンダーが自己署名証明書を使用して自身を認証するテスト設定があります。イニシエーターはユーザー名とパスワードを使用して認証します。
いくつかの問題:
- 証明書は複雑すぎます。適切な PKI を設定しないので、各クライアントに配布して信頼されるように構成する必要がある自己署名証明書は、事前共有キー (PSK) と同等になり、生成と管理がかなり困難になります。
- イニシエーターが認証されるのみユーザー名とパスワードによって構成されるため、外部の攻撃者が弱いパスワードや侵害されたパスワードを簡単に推測することができます。
適切なPKIを導入する以外に、私は以下を実行することを好みます共通のPSK によるイニシエーター ホストとレスポンダー ホストの認証。このキーはすべてのユーザーに安全に配布されます。外部の攻撃者は PSK を持っていないため、弱いパスワードや侵害されたパスワードではアクセスできません。ユーザー名とパスワードの認証により、既存のディレクトリ システムに対して特定のユーザーを識別して承認することができ、ユーザーごとに一意のキーを生成して配布する必要はありません。
IKEv2ではそのようなことは可能でしょうか？私が知る限り、IKEv1ではXauthを通じて可能でした。しかしIKEv2ではそうではないようです。ざっと読んだところ、RFC 5996、セクション 2.16ただし、そうではないようです。ユーザー名とパスワードの認証は、何らかの EAP メソッドを通じて行われ、次のようになります。
イニシエーターは、IKE_AUTH 交換の最初のメッセージから AUTH ペイロードを省略することで、EAP を使用する意思を示します。(AUTH ペイロードは非 EAP 認証に必須であるため、このドキュメントの残りの部分ではオプションとしてマークされていないことに注意してください。)
これは、イニシエーターが EAP (ユーザー名とパスワード) または PSK のいずれか 1 つだけを使用できることを示唆しているようです。
質問は IKEv2 プロトコルに関するものですが、応答側を strongswan で実装するつもりなので、追加の専門知識があればいただければ幸いです。
答え1
IKEV2のクライアント認証とサーバー認証は無関係です。理論上は、サーバーをPSKで認証し、クライアントをEAPで認証することができます。ただし、RFCでは次のように述べられているEAP認証に関して:
IKEは、公開鍵署名と共有秘密を使用した認証に加えて、RFC 3748 [EAP]で定義された方法を使用した認証もサポートしています。通常、これらの方法は非対称（サーバーに対して認証するユーザー向けに設計）であり、相互ではない場合があります。このため、これらのプロトコルは通常、イニシエーターをレスポンダーに認証するために使用されます。そして、応答側から発信側への公開鍵署名ベースの認証と組み合わせて使用する必要がある。。
したがって、PSK サーバー認証と EAP クライアント認証を組み合わせることは、RFC に準拠していません。ただし、strongSwan を使用して設定することは可能です。ただし、ほとんどのクライアントではこの組み合わせが許可されないことに注意してください。
多くのロードウォリアー クライアントは、実際には PSK 認証をまったくサポートしていません。これは、理論上は PSK を知っているすべてのクライアントがサーバーを偽装できるため、同じ PSK が複数のクライアントで使用されると、このようなシナリオで潜在的なセキュリティ リスクが発生するためです。
レスポンダーが自己署名証明書を使用して自身を認証するテスト設定があります。
なぜ使わないのか暗号化しましょう?
イニシエーターはユーザー名とパスワードのみで認証されるため、外部の攻撃者は弱いパスワードや侵害されたパスワードを簡単に推測することができます。
PSKを使用してサーバーを認証しても、それは変わりません。これに対処するには、クライアント認証に2番目の要素を追加する必要があります（つまり、最初に証明書またはPSKを使用してからEAPを実行します）。ただし、これには次のサポートが必要です。RFC 4739多くのクライアントではこれが欠けています (ただし、strongSwan はこれをサポートしています)。