次の方法で共有


ネットワーク アクセスの拡張認証プロトコル (EAP)

拡張認証プロトコル (EAP) は、セキュリティで保護されたネットワーク アクセス テクノロジのためにさまざまな認証方法を使用できるようにする認証フレームワークです。 これらのテクノロジの例としては、IEEE 802.1X を使用したワイヤレス アクセス、IEEE 802.1X を使用した有線アクセス、仮想プライベート ネットワーク (VPN) などの Point-to-Point プロトコル (PPP) 接続などがあります。 EAP は、MS-CHAP v2 などの特定の認証方法ではなく、ネットワーク ベンダーが EAP メソッドと呼ばれている新しい認証方法を開発してアクセス クライアントと認証サーバーにインストールできるようにするフレームワークです。 EAP フレームワークは、もともと RFC 3748 によって定義され、他のさまざまな RFC と標準によって拡張されています。

認証方法

トンネリングされた EAP メソッド内で使用される EAP 認証方法は、一般に 内部メソッド または EAP の種類と呼ばれます。 内部メソッドとして設定されるメソッドの構成設定は、外部 メソッド として使用する場合と同じです。 この記事では、EAP の次の認証方法に固有の構成情報について説明します。

EAP トランスポート層セキュリティ (EAP-TLS): 相互認証のために証明書と組み合わせて TLS を使用する標準ベースの EAP メソッド。 Windows では "スマート カードまたはその他の証明書 (EAP-TLS)" と表示されます。 EAP-TLS は、別の EAP メソッドの内部メソッド として、またはスタンドアロンの EAP メソッドとして展開できます。

Tip

証明書ベースの EAP-TLS を使用する EAP メソッドは、通常、最高レベルのセキュリティを提供します。 たとえば、EAP-TLS は、WPA3-Enterprise 192 ビット モードで利用できる唯一の EAP メソッドです。

EAP-Microsoft チャレンジ ハンドシェイク認証プロトコル バージョン 2 (EAP-MSCHAP v2): Microsoft が定義した EAP メソッド。認証にユーザー名とパスワードを使用する MSCHAP v2 認証プロトコルをカプセル化します。 Windows では "セキュリティで保護されたパスワード (EAP-MSCHAP v2)" と表示されます。 EAP-MSCHAPv2 は、VPN のスタンドアロンの方法として使用できますが、有線/ワイヤレス接続の 内部メソッド としてのみ使用できます。

Warning

MSCHAPv2 ベースの接続は、NTLMv1 と同様の攻撃を受ける可能性があります。 Windows 11 Enterprise バージョン 22H2 (ビルド 22621) では、Windows Defender Credential Guard が有効になりますが、これにより MSCHAPv2 ベースの接続で問題が発生する可能性があります。

保護された EAP (PEAP): Microsoft が定義した EAP メソッド。TLS トンネル内の EAP をカプセル化します。 通常は保護されない可能性がある内部の EAP メソッドが、TLS トンネルによってセキュリティで保護されます。 Windows では、内部メソッドとして EAP-TLS と EAP-MSCHAP v2 がサポートされています。

EAP-トンネル トランスポート層セキュリティ (EAP-TTLS): これは RFC 5281 によって説明されており、別の内部認証メカニズムを使用して相互認証を実行する TLS セッションをカプセル化します。 この内部メソッドには、EAP-MSCHAP v2 などの EAP プロトコル、またはパスワード認証プロトコル (PAP) などの EAP 以外のプロトコルのいずれかを指定できます。 Windows Server 2012 では、EAP-TTLS を含めることは、クライアント側 (Windows 8) でのみサポートされます。 現時点では、NPS では EAP-TTLS はサポートされていません。 クライアントのサポートにより、EAP-TTLS をサポートする一般的に展開された RADIUS サーバーとの相互運用が可能になります。

EAP-Subscriber Identity Module (EAP-SIM)、EAP-Authentication and Key Agreement (EAP-AKA)、EAP-AKA Prime (EAP-AKA'): これはさまざまな RFC によって説明されており、SIM カードを使用した認証を有効にし、顧客がモバイル ネットワーク オペレーターからワイヤレス ブロードバンド サービス プランを購入したときに実装されます。 通常、プランの一環として、SIM 認証用に事前に構成されたワイヤレス プロファイルが顧客に提供されます。

トンネル EAP (TEAP): これは RFC 7170 によって説明されており、セキュリティで保護された TLS トンネルを確立し、そのトンネル内で他の EAP メソッドを実行するトンネリングされた EAP メソッドです。 EAP チェーンをサポートします。つまり、1 つの認証セッション内でマシンとユーザーを認証します。 Windows Server 2022 では、TEAP を含めることは、クライアント側 (Windows 10 バージョン 2004 (ビルド 19041)) でのみサポートされます。 現時点では、NPS では TEAP はサポートされていません。 クライアントのサポートにより、TEAP をサポートする一般的に展開された RADIUS サーバーとの相互運用が可能になります。 Windows では、内部メソッドとして EAP-TLS と EAP-MSCHAP v2 がサポートされています。

次の表に、一般的な EAP メソッドとその IANA 割り当てメソッドの種類番号を示します。

EAP メソッド IANA 割り当て 番号 Windows のネイティブ サポート
MD5-Challenge (EAP-MD5) 4
ワンタイム パスワード (EAP-OTP) 5
汎用トークン カード (EAP-GTC) 6
EAP-TLS 13
EAP-SIM 18
EAP-TTLS 21
EAP-AKA 23
PEAP 25
EAP-MSCHAP v2 26
保護されたワンタイム パスワード (EAP-POTP) 32
EAP-FAST 43
事前共有キー (EAP-PSK) 47
EAP-IKEv2 49
EAP-AKA' 50
EAP-EKE 53
TEAP 55
EAP-NOOB 56

EAP プロパティの構成

802.1X で認証されたワイヤード (有線) アクセスとワイヤレス アクセス用の EAP のプロパティには、次の方法でアクセスできます。

  • グループ ポリシーで、有線ネットワーク (IEEE 802.3) ポリシーとワイヤレス ネットワーク (IEEE 802.11) ポリシーの拡張を構成する。
    • コンピューターの構成>ポリシー>Windows の設定>セキュリティ設定
  • Intune (Wi-Fi/Wired) などのモバイル デバイス管理 (MDM) ソフトウェアの使用
  • クライアント コンピューター上で有線またはワイヤレス接続を手動で構成する。

仮想プライベート ネットワーク (VPN) 接続用の EAP のプロパティには、次の方法でアクセスできます。

  • Intune などのモバイル デバイス管理 (MDM) ソフトウェアの使用
  • クライアント コンピューター上で VPN 接続を手動で構成する。
  • 接続マネージャー管理キット (CMAK) を使用して VPN 接続を構成する。

EAP プロパティの構成の詳細については、「Windows で EAP プロファイルと設定を構成する」を参照してください。

EAP の XML プロファイル

さまざまな接続の種類に使用されるプロファイルは XML ファイルであり、その接続の構成オプションが含まれます。 接続の種類はそれぞれ、特定のスキーマに従います。

ただし、EAP を使用するように構成されている場合、各プロファイル スキーマには子要素 EapHostConfig 要素があります。

  • 有線/ワイヤレス: EapHostConfigEAPConfig 要素の子要素です。 MSM > セキュリティ (ワイヤーレス/ワイヤーレス) >OneX> EAPConfig
  • VPN: EapHostConfigNativeProfile > Authentication > Eap > Configuration の子要素です

この構成構文は、「グループ ポリシー: ワイヤレス/有線プロトコル拡張機能」の仕様で定義されています。

Note

さまざまな構成の GUI では、技術的に使用できるすべてのオプションが常に表示されるわけではありません。 たとえば、Windows Server 2019 以前では UI で TEAP を構成できません。 ただし、多くの場合、以前に構成された既存の XML プロファイルをインポートできます。

この記事の残りの部分では、グループ ポリシー/コントロール パネル UI の EAP 固有の部分と XML 構成オプションの間のマッピングと設定について説明します。

XML プロファイルの構成の詳細については、 XML プロファイルを参照してください。 EAP 設定を含む XML プロファイルの使用例については、「Web サイト経由での Wi-Fi プロファイルのプロビジョニング」を参照してください。

セキュリティ設定

次の表では、802.1X を使用するプロファイルの構成可能なセキュリティ設定について説明します。 これらの設定は OneX にマップされます。

Setting XML 要素 Description
ネットワークの認証方法の選択: EAPConfig 認証に使用する EAP メソッドを選択できます。 「認証方法の構成設定」と「携帯電話認証の構成設定」を参照してください。
プロパティ 選択した EAP メソッドのプロパティ ダイアログを開きます。
認証モード authMode 認証に使用する資格情報の種類を指定します。 サポートされている値を次に示します。

1. ユーザー認証またはコンピューター認証
2. コンピューター認証
3. ユーザー認証
4. ゲスト認証

このコンテキストにおける "コンピューター" は、他の参考資料では "マシン" を意味します。 machineOrUser は Windows の既定値です。
[認証エラーの最大数] maxAuthFailures 一連の資格情報に対して許容される認証エラーの最大数を指定します。既定値は 1 です。
このネットワークへの後続の接続のためにユーザー情報をキャッシュします cacheUserData 同じネットワークへの後続の接続のためにユーザーの資格情報をキャッシュするかどうかを指定します。既定値は true です。

高度なセキュリティ設定 > IEEE 802.1X

[詳細な 802.1X 設定を適用する] がオンになっている場合、次のすべての設定が構成されます。 オフになっている場合は、既定の設定が適用されます。 XML では、すべての要素は省略可能であり、指定されていない場合は既定値が使用されます。

Setting XML 要素 Description
EAPOL 開始メッセージの最大数 maxStart サプリカント (Windows クライアント) が認証システムが存在しないと判断する前に、認証システム (RADIUS サーバー) に送信できる EAPOL-Start メッセージの最大数を指定します。既定値は 3 です。
開始期間 (秒) startPeriod 802.1X 認証プロセスを開始するために EAPOL-Start メッセージが送信されるまで待機する期間 (秒単位) を指定します。既定値は 5 です。
保持期間 (秒) heldPeriod 認証の再試行が失敗した後に待機する期間 (秒単位) を指定します。既定値は 1 です。
認証期間 (秒) authPeriod 認証システムが存在しないとみなす前に、認証システム (RADIUS サーバー) からの応答を待機する期間 (秒単位) を指定します。既定値は 18 です。
Eapol-Start メッセージ supplicantMode EAPOL-Start メッセージに使用される送信方法を指定します。 サポートされている値を次に示します。

1. 送信しない (inhibitTransmission)
2. 送信する (includeLearning)
3. IEEE 802.1X に従って送信する (compliant)

このコンテキストにおける "コンピューター" は、他の参考資料では "マシン" を意味します。 compliant は Windows の既定値であり、ワイヤレス プロファイルの唯一の有効なオプションです。

[詳細なセキュリティ設定] > [シングル サインオン]

次の表では、シングル サインオン (SSO) (旧称は Pre-Logon Access Provider (PLAP)) の設定について説明します。

Setting XML 要素 Description
このネットワークに対するシングル サインオンを有効にする singleSignOn このネットワークで SSO を有効にするかどうかを指定します。既定値は false です。 ネットワークに必要ない場合は、プロファイルで singleSignOn を使用しないでください。
ユーザーの直前に実行する

ユーザーの直後に実行する
type SSO を実行するタイミング (ユーザーのログオン前またはログオン後のいずれか) を指定します。
接続の最大遅延 (秒) maxDelay SSO 試行が失敗するまでの最大遅延 (秒単位) を指定します。既定値は 10 です。
シングル サインオン中に追加のダイアログの表示を許可する allowAdditionalDialogs SSO 中に EAP ダイアログの表示を許可するかどうかを指定します。既定値は false です。
このネットワークでは異なる VLAN を使用して、コンピュータおよびユーザーの資格情報での認証を実行します userBasedVirtualLan デバイスによって使用される仮想 LAN (VLAN) がユーザーの資格情報に基づいて変更されるかどうかを指定します。既定値は false です。

認証方法の構成設定

Caution

トンネリングされた EAP メソッド (PEAP など) と非トンネリング EAP メソッド (EAP-MSCHAP v2 など) に対して、同じ種類の認証方法を許可するようにネットワーク アクセス サーバーが構成されている場合、セキュリティ上の脆弱性が発生する可能性があります。 トンネリングされた EAP メソッドと (保護されていない) EAP の両方を展開する場合は、同じ認証の種類を使用しないでください。 たとえば、PEAP-TLS を展開する場合は、EAP-TLS も同時に展開しないでください。トンネルによる保護を必要な場合、トンネルの外部でもメソッドの実行を許可しても意味がありません。

次の表では、各認証方法の構成設定について説明します。

UI の EAP-TLS 設定は EapTlsConnectionPropertiesV1 にマップされ、 EapTlsConnectionPropertiesV2EapTlsConnectionPropertiesV3 によって拡張されます。

Setting XML 要素 Description
自分のスマート カードを使う CredentialsSource>SmartCard 認証要求を行っているクライアントがネットワーク認証のためにスマート カードの証明書を提示することを指定します。
このコンピューターの証明書を使用する CredentialsSource>CertificateStore 認証を行っているクライアントが、[現在のユーザー] または [ローカル コンピューター] の証明書ストアにある証明書を使用するように指定します。
単純な証明書の選択を使う (推奨) SimpleCertSelection Windows がユーザー操作なしで認証用の証明書を自動的に選択するか (可能な場合)、または Windows でユーザーが証明書を選択するためのドロップダウンを表示するかを指定します。
Advanced [証明書の選択を構成] ダイアログ ボックスが開きます。
サーバー検証オプション
この接続で別のユーザー名を使う DifferentUsername 証明書のユーザー名と異なる認証用のユーザー名を使用するかどうかを指定します。

[証明書の選択を構成] に関する構成設定を次に示します。 これらの設定では、クライアントが認証に適切な証明書を選択するために使用する条件を定義します。 この UI は TLSExtensions>FilteringInfo にマップされます。

Setting XML 要素 Description
証明書発行者 CAHashListEnabled="true" 証明書発行者によるフィルターを有効にするかどうかを指定します。

証明書発行者拡張キー使用法 (EKU) の両方が有効になっている場合、両方の条件を満たす証明書のみが、クライアントをサーバーに対して認証するために有効と見なされます。
ルート証明機関 IssuerHash 対応する認証機関 (CA) 証明書がローカル コンピューター アカウントの [信頼されたルート証明機関] または [中間証明機関] の証明ストアに存在する場合、すべての発行者の名前の一覧が表示されます。 これには次のものが含まれます。

  • すべてのルート証明機関と中間証明機関。
  • コンピューターに存在する有効な証明書 (有効期限が切れていない証明書や失効していない証明書など) に対応する発行者のみが含まれます。
  • 認証を許可する最終的な証明書の一覧には、この一覧で選択されたいずれかの発行者が発行した証明書のみが含まれます。

  • XML では、これは証明書の SHA-1 サムプリント (ハッシュ) です。
    拡張キー使用法 (EKU) [すべての目的]、[クライアント認証]、[AnyPurpose]、またはこれらの任意の組み合わせを選択できます。 組み合わせを選択すると、3 つの条件の少なくとも 1 つを満たす証明書すべてが、サーバーに対してクライアントを認証するために有効と見なされます。 EKU フィルターが有効になっている場合、1 つの項目を選択する必要があります。それ以外の場合は、[拡張キー使用法 (EKU)] チェックボックスがオフになります。
    すべての目的 AllPurposeEnabled この項目を選択すると、 All Purpose EKU を持つ証明書が、クライアントをサーバーに対して認証するための有効な証明書と見なされることを指定します。 すべての目的のオブジェクト識別子 (OID) が0または空です。
    クライアント認証 ClientAuthEKUListEnabled="true" (> EKUMapInList > EKUName) クライアント認証 EKU を持つ証明書と、指定された EKU の一覧が、クライアントをサーバーに対して認証するための有効な証明書と見なされることを指定します。 クライアント認証のオブジェクト識別子 (OID) が1.3.6.1.5.5.7.3.2
    AnyPurpose AnyPurposeEKUListEnabled="true" (> EKUMapInList > EKUName) AnyPurpose EKU を持つすべての証明書と指定された EKU の一覧が、クライアントをサーバーに対して認証するための有効な証明書と見なされることを指定します。 AnyPurpose のオブジェクト識別子 (OID) が1.3.6.1.4.1.311.10.12.1
    Add EKUMapping > EKUMap > EKUName/EKUOID [ EKU の選択 ] ダイアログ ボックスを開きます。これにより、標準、カスタム、またはベンダー固有の EKU を クライアント認証 または AnyPurpose リストに追加できます。

    [EKU の選択] ダイアログ ボックスで [追加] または [編集] を選択すると、[EKU の追加/編集] ダイアログ ボックスが開き、次の 2 つのオプションが表示されます。

    1. EKU の名前を入力する - カスタム EKU の名前を入力する場所が用意されています。
    2. EKU の OID を入力する - EKU の OID を入力する場所が用意されています。 数字、区切り記号、. のみを使用できます。 ワイルド カードを使用でき、その場合、階層に含まれるすべての子 OID が許可されます。

    たとえば、1.3.6.1.4.1.311.* と入力すると、1.3.6.1.4.1.311.421.3.6.1.4.1.311.42.2.1 が許可されます。
    Edit 追加したカスタム EKU を編集できます。 既定の事前定義された EKU は編集できません。
    Remove 選択した EKU を クライアント認証 または AnyPurpose リストから削除します。

    サーバー証明書の検証

    多くの EAP メソッドには、クライアントがサーバーの証明書を検証するためのオプションが含まれています。 サーバー証明書が検証されていない場合、クライアントは正しいサーバーと通信しているかどうかを確認できません。 これにより、クライアントが無意識のうちに不正なネットワークに接続する可能性など、セキュリティ リスクにさらされることになります。

    Note

    Windows では、サーバー証明書に サーバー認証 EKU が必要です。 この EKU のオブジェクト識別子 (OID) は 1.3.6.1.5.5.7.3.1 です。

    次の表に、各 EAP メソッドに適用できるサーバー検証オプションを示します。 Windows 11 では、サーバー検証ロジックがより一貫性のあるものに更新されました。 詳細については、「Windows 11 での更新されたサーバー証明書の検証動作」を参照してください。 これらが競合する場合は、次の表の説明に従って Windows 10 以前の動作を確認してください。

    Setting XML 要素 Description
    証明書を検証してサーバーの ID を検証する EAP-TLS:
    PerformServerValidation

    PEAP:
    PerformServerValidation
    この項目は、クライアント コンピューターに提示されたサーバー証明書が次の条件を満たしていることをクライアントが検証することを指定します。

  • 正しい署名
  • 署名の有効期限が切れていない
  • 信頼されたルート証明機関 (CA) によって発行されました

  • このチェック ボックスをオフにすると、クライアント コンピューターで認証プロセス中にサーバーの ID を検証できなくなります。 サーバー認証を行わないと、許可されていないネットワークに知らずに接続してしまうなど、ユーザーは重大なセキュリティ上の危険にさらされます。
    次のサーバーに接続する EAP-TLS:
    ServerValidation>ServerNames

    PEAP:
    ServerValidation>ServerNames

    EAP-TTLS:
    ServerValidation>
    ServerNames

    TEAP:
    ServerValidation>
    ServerNames
    ネットワークの認証および承認を行うリモート認証ダイヤルイン ユーザー サービス (RADIUS) サーバーの名前を指定できるようにします。

    各 RADIUS サーバー証明書のサブジェクト フィールドに表示されるとおり名前を入力するか、正規表現 (正規表現) を使用してサーバー名を指定する必要があります。

    正規表現の完全な構文を使用してサーバー名を指定できますが、正規表現をリテラル文字列と区別するために、指定する文字列に * を少なくとも 1 つ含める必要があります。 たとえば、RADIUS サーバー nps.*\.example\.com または nps1.example.com を指定するために nps2.example.com を指定できます。 また、; を含めて複数のサーバーを分離することもできます。

    RADIUS サーバーが指定されていない場合、クライアントは、RADIUS サーバー証明書が信頼されたルート CA から発行されたことのみを確認します。
    信頼されたルート証明機関 EAP-TLS:
    ServerValidation>TrustedRootCA

    PEAP:
    ServerValidation>TrustedRootCA

    EAP-TTLS:
    ServerValidation>
    TrustedRootCAHashes

    TEAP:
    ServerValidation>
    TrustedRootCAHashes
    信頼されたルート証明機関の一覧を表示します。 一覧は、コンピューターにインストールされている信頼されたルート CA およびユーザーの証明書ストアから作成されます。 サプリカントがサーバー (ネットワーク ポリシー サーバー (NPS) が実行されているサーバーやプロビジョニング サーバーなど) を信頼するかどうかを決定するために使用する、信頼されたルート CA 証明書を指定できます。 信頼されたルート CA が選択されていない場合は、RADIUS サーバーのコンピューター証明書が、インストールされている信頼されたルート CA によって発行されたものであるかどうかが 802.1X クライアントにより検証されます。 1 つ以上の信頼されたルート CA が選択されている場合は、RADIUS サーバーのコンピューター証明書が、選択されている信頼されたルート CA によって発行されたものであるかどうかが 802.1X クライアントにより検証されます。

    信頼されたルート CA が選択されていない場合、RADIUS サーバー証明書が信頼されたルート CA から発行されたかどうかがクライアントによって検証されます。

    公開キー基盤 (PKI) がネットワーク上にあり、CA を使用して RADIUS サーバーに証明書を発行している場合は、信頼されたルート CA の一覧に CA 証明書が自動的に追加されます。 また、Microsoft 以外のベンダーから CA 証明書を購入することもできます。 Microsoft 以外の一部の信頼されたルート CA では、購入した証明書を [信頼されたルート証明機関] 証明書ストアに自動的にインストールするソフトウェアが提供されています。 この場合、この信頼されたルート CA は、信頼されたルート CA の一覧に自動的に表示されます。

    クライアント コンピューターの [現在のユーザー] および [ローカル コンピューター][信頼されたルート証明機関] 証明書ストアにない信頼されたルート CA 証明書を指定しないでください。 クライアント コンピューターにインストールされていない証明書を指定すると、認証は失敗します。

    XML では、これは証明書の SHA-1 サムプリント (ハッシュ) (TEAP の場合は SHA-256) です。

    サーバー検証のユーザー プロンプト

    次の表では、各 EAP メソッドで使用できるサーバー検証ユーザー プロンプト オプションについて説明します。 サーバー証明書が信頼されていない場合、これらのオプションによって次のことが決定されます。

    • 接続は直ちに失敗します。
    • ユーザーは、接続を手動で受け入れるか拒否するように求められます。
    Setting XML 要素
    新しいサーバーまたは信頼された証明機関を承認するようユーザーに求めない ServerValidation>DisableUserPromptForServerValidation

    サーバー証明書が正しく構成されていない場合、まだ信頼されていない場合、またはその両方の場合 (有効な場合) に、その証明書を信頼するように求めるプロンプトがユーザーに表示されないようにします。 ユーザー エクスペリエンスを簡素化し、攻撃者によって配置されたサーバーをユーザーが誤って信頼することがないように、このチェックボックスをオンにすることをお勧めします。

    携帯電話認証の構成設定

    EAP-SIM、EPA-AKA、EPA-AKA' の構成設定をそれぞれ次に示します。

    EAP-SIM は RFC 4186 で定義されています。 EAP Subscriber Identity Module (SIM) は、第 2 世代モバイル ネットワーク Global System for Mobile Communications (GSM) サブスクライバー ID モジュール (SIM) を使用した認証とセッション キーの配布に使用されます。

    UI の EAP-SIM 設定は EapSimConnectionPropertiesV1 にマップされます。

    Item XML 要素 Description
    強力な暗号キーを使用する UseStrongCipherKeys このチェック ボックスをオンにすると、プロファイルに強力な暗号化が使用されます。
    仮の ID を使用できる場合は、実際の ID をサーバーに送信しない DontRevealPermanentID このチェック ボックスをオンにすると、クライアントを介した固定 ID のサーバー要求に仮の ID が設定される場合、クライアントは認証に失敗します。 ユーザーの実際の ID または固定 ID が認証時に公開されることがないように、仮の ID が ID プライバシーに使用されます。
    ProviderName XML でのみ使用できます。認証に許可されているプロバイダー名を示す文字列です。
    領域の使用を有効にする 国土=true 領域名を入力する場所です。 [領域の使用を有効にする] をオンにした場合にこのフィールドを空白にすると、3GPP (3rd Generation Partnership Project) 標準の 23.003 V6.8.0 で説明されているように、領域 3gpp.org を使用して IMSI (International Mobile Subscriber Identity) から領域が派生します。
    領域の指定 Realm 領域名を入力する場所です。 [領域の使用を有効にする] が有効になっている場合は、この文字列が使用されます。 このフィールドが空の場合は、派生領域が使用されます。

    WPA3-Enterprise 192 ビット モード

    WPA3-Enterprise 192 ビット モードは、ワイヤレス接続に特定の高度なセキュリティ要件を強制して、最低 192 ビットのセキュリティを提供する WPA3-Enterprise の特別なモードです。 これらの要件は、Commercial National Security Algorithm (CNSA) Suite、CNSSP 15 に準拠しています。これは、米国国家安全保障局 (NSA) によって機密情報や極秘情報を保護するために承認された一連の暗号アルゴリズムです。 192 ビット モードは、"Suite B モード" と呼ばれることもあります。これは、2016 年に CNSA によって置き換えられた NSA Suite B 暗号化仕様への参照です。

    WPA3-Enterprise モードと WPA3-Enterprise 192 ビット モードは両方とも、Windows 10 バージョン 2004 (ビルド 19041) と Windows Server 2022 以降で使用できます。 ただし、Windows 11 では、WPA3-Enterprise が別の認証アルゴリズムとして選ばれました。 XML では、これは authEncryption 要素で指定されます。

    次の表に、CNSA Suite に必要なアルゴリズムを示します。

    Algorithm Description Parameters
    高度暗号化標準 (AES) 暗号化に使用される対称ブロック暗号 256 ビット キー (AES-256)
    Elliptic Curve Diffie-Hellman (ECDH) キー交換 共有シークレット (キー) の確立に使用される非対称アルゴリズム 384 ビット素数曲線 (P-384)
    楕円曲線デジタル署名アルゴリズム (ECDSA) デジタル署名に使用される非対称アルゴリズム 384 ビット素数曲線 (P-384)
    セキュア ハッシュ アルゴリズム (SHA) 暗号化ハッシュ関数 SHA-384
    Diffie-Hellman (DH) キー交換 共有シークレット (キー) の確立に使用される非対称アルゴリズム 3072 ビットの剰余
    Rivest-Shamir-Adleman (RSA) デジタル署名または鍵の確立に使用される非対称アルゴリズム 3072 ビットの剰余

    CNSA の要件に準拠するために、WPA3-Enterprise 192 ビット モードでは、次の制限付き暗号スイートでの EAP-TLS の使用が義務付けられています。

    • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

      • 384 ビット素数曲線を使用した ECDHE と ECDSA P-384
    • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 / TLS_DHE_RSA_AES_256_GCM_SHA384

      • 384 ビット素数曲線を使用した ECDHE P-384

      • RSA >= 3072 ビットの剰余

    Note

    P-384 は secp384r1 または nistp384 とも呼ばれます。 P-521 などの他の楕円曲線は許可されません。

    SHA-384 は、ハッシュ関数の SHA-2 ファミリに含まれます。 SHA-512 や SHA3-384 などの他のアルゴリズムやバリアントは許可されません。

    Windows では、WPA3-Enterprise 192 ビット モードに対して TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 および TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 暗号スイートのみがサポートされています。 TLS_DHE_RSA_AES_256_GCM_SHA384 暗号スイートはサポートされていません。

    TLS 1.3 は新しい簡素化された TLS スイートを使用しており、そのうち TLS_AES_256_GCM_SHA384 のみが WPA3-Enterprise 192 ビット モードと互換性があります。 TLS 1.3 では (EC)DHE が必須であり、ECDSA または RSA 証明書に加えて AES-256 AEAD および SHA384 ハッシュが許可されているため、TLS_AES_256_GCM_SHA384TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 および TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 と同等です。 ただし、 RFC 8446 では、TLS 1.3 準拠アプリケーションで P-256 がサポートされている必要があります。これは CNSA によって禁止されています。 そのため、WPA3-Enterprise 192 ビット モードは TLS 1.3 に完全に準拠することはできません。 ただし、TLS 1.3 と WPA3-Enterprise 192 ビット モードとの相互運用性に関する既知の問題はありません。

    WPA3-Enterprise 192 ビット モード用にネットワークを構成するには、Windows では、前述の要件を満たす証明書と共に EAP-TLS を使用する必要があります。

    こちらも参照ください