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

適用対象: Windows Server 2022、Windows Server 2019、Windows Server 2016、Windows Server 2012 R2、Windows Server 2012、Windows 11、Windows 10、Windows 8.1

拡張認証プロトコル (EAP) は、セキュリティで保護されたネットワーク アクセス テクノロジのためにさまざまな認証方法を使用できるようにする認証フレームワークです。 これらのテクノロジの例としては、IEEE 802.1X を使用したワイヤレス アクセス、IEEE 802.1X を使用した有線アクセス、仮想プライベート ネットワーク (VPN) などのポイントツーポイント プロトコル (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 メソッドとして展開できます。

ヒント

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

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

警告

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

保護された EAP (PEAP): TLS トンネル内に EAP をカプセル化する Microsoft が定義した EAP メソッド。 TLS トンネルは、それ以外の方法では保護されない可能性のある、内部 EAP メソッドをセキュリティで保護します。 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'): 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/有線) などのモバイル デバイス管理 (MDM) ソフトウェアの使用
  • クライアント コンピューターで、ワイヤード (有線) 接続またはワイヤレス接続を手動で構成する。

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

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

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

EAP の XML プロファイル

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

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

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

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

注意

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

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

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

セキュリティ設定

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

設定 XML 要素 説明
ネットワーク認証方法を選択します。 EAPConfig 認証に使用する EAP メソッドを選択できます。 認証方法の構成設定モバイル認証の構成設定に関するページをご覧ください。
プロパティ 選択した EAP メソッドのプロパティ ダイアログを開きます。
認証モード authMode 認証に使用する資格情報の種類を指定します。 次の値がサポートされています:

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

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

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

[詳細な 802.1X 設定を適用する] がオンになっている場合、次のすべての設定が構成されます。 オフになっている場合は、既定の設定が適用されます。 XML では、すべての要素はオプションであり、存在しない場合は既定が使用されます。

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

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

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

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

次の表では、シングル サインオン (SSO) (以前はログオン前アクセス プロバイダー (PLAP) と呼ばれていました) の設定について説明します。

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

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

認証方法の構成設定

注意事項

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

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

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

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

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

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

[証明書発行者][拡張キー使用法 (EKU)] の両方が有効になっている場合、両方の条件を満たす証明書のみがサーバーに対してクライアントを認証するために有効な証明書と見なされます。

Root Certification Authorities (ルート証明機関) IssuerHash 対応する認証機関 (CA) 証明書がローカル コンピューター アカウントの [信頼されたルート証明機関] または [中間証明機関] の証明ストアに存在する場合、すべての発行者の名前の一覧が表示されます。 これには次のものが含まれます

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

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

[拡張キー使用法 (EKU)] [すべての目的][クライアント認証][任意の目的]、またはこれらの組み合わせを選択できます。 組み合わせを選択すると、3 つの条件の少なくとも 1 つを満たす証明書すべてが、サーバーに対してクライアントを認証するために有効と見なされます。 EKU フィルターが有効になっている場合、1 つの項目を選択する必要があります。それ以外の場合は、[拡張キー使用法 (EKU)] チェックボックスがオフになります。
[すべての目的] AllPurposeEnabled この項目をオンにすると、EKU が [すべての目的] になっている証明書が、サーバーに対してクライアントを認証するために有効と見なされます。 [すべての目的] のオブジェクト識別子 (OID) は 0 または空です。
クライアント認証 ClientAuthEKUListEnabled="true" (> EKUMapInList > EKUName) EKU が [クライアント認証] になっている証明書と、指定された一覧の EKU が、サーバーに対してクライアントを認証するために有効と見なされます。 [クライアント認証] のオブジェクト識別子は (OID) は 1.3.6.1.5.5.7.3.2 です。
AnyPurpose AnyPurposeEKUListEnabled="true" (> EKUMapInList > EKUName) EKU が [AnyPurpose] になっているすべての証明書と、指定された一覧の EKU が、サーバーに対してクライアントを認証するために有効と見なされます。 [AnyPurpose] のオブジェクト識別子 (OID) は 1.3.6.1.4.1.311.10.12.1 です。
[追加] 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 が許可されます。

編集 追加したカスタム EKU を編集できます。 既定の事前定義された EKU は編集できません。
Remove 選択した EKU を [クライアント認証] または [AnyPurpose] の一覧から削除します。

サーバーの検証

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

注意

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

次の表に、各 EAP メソッドに適用できるサーバー検証オプションを示します。 Windows 11 では、サーバー検証ロジックが更新され、一貫性が向上しました (Windows 11 でのサーバー証明書検証動作の更新をご覧ください)。 これらが競合する場合、次の表の説明は Windows 10 以前の動作について説明します。

設定 XML 要素 説明
Verify the server's identity by validating the certificate (証明書を検証してサーバーの ID を検証する) EAP-TLS:
PerformServerValidation

PEAP:
PerformServerValidation
この項目では、クライアントがクライアント コンピューターに提示されたサーバーの証明書について、署名が正しいこと、有効期限が切れていないこと、および信頼されたルート証明機関 (CA) によって発行されたものであることを検証するように指定します。

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

[次のサーバーに接続する] EAP-TLS:
ServerValidation>ServerNames

PEAP:
ServerValidation>ServerNames

EAP-TTLS:
ServerValidation>
ServerNames

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

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

正規表現の完全な構文を使用してサーバー名を指定できますが、正規表現をリテラル文字列と区別するために、指定する文字列に * を少なくとも 1 つ含める必要があります。 たとえば、RADIUS サーバー nps1.example.com または nps2.example.com を指定するために nps.*\.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 メソッドに適用できるサーバー検証ユーザー プロンプト オプションを示します。 信頼されていないサーバー証明書の場合は、次のいずれかのオプションが使用されます。

  • 接続が直ちに失敗するか、または
  • ユーザーが手動で接続を承認または拒否できるようにします。
設定 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 要素 説明
[強力な暗号キーを使用する] UseStrongCipherKeys このチェック ボックスをオンにすると、プロファイルに強力な暗号化が使用されます。
[仮の ID を使用できる場合は、実際の ID をサーバーに送信しない] DontRevealPermanentID このチェック ボックスをオンにすると、クライアントを介した固定 ID のサーバー要求に仮の ID が設定される場合、クライアントは認証に失敗します。 ユーザーの実際の ID または固定 ID が認証時に公開されることがないように、仮の ID が ID プライバシーに使用されます。
ProviderName XML でのみ使用できます。認証に許可されているプロバイダー名を示す文字列です。
[領域の使用を有効にする] Realm=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 の特別なモードです。 これらの要件は、商用国家安全保障アルゴリズム (CNSA) スイート、CNSSP 15 に準拠しています。CNSA は、米国国家安全保障局 (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 に必要なアルゴリズムを示します。

アルゴリズム 説明 パラメーター
高度暗号化標準 (AES) 暗号化に使用される対称ブロック暗号 256 ビット キー (AES-256)
楕円曲線Diffie-Hellman (ECDH) キー交換 共有シークレット (キー) の確立に使用される非対称アルゴリズム 384 ビット素数曲線 (P-384)
楕円曲線デジタル署名アルゴリズム (ECDSA) デジタル署名に使用される非対称アルゴリズム 384 ビット素数曲線 (P-384)
セキュア ハッシュ アルゴリズム (SHA) 暗号ハッシュ関数 SHA-384
IKE Diffie-Hellman キー交換 共有シークレット (キー) の確立に使用される非対称アルゴリズム 3072 ビットの剰余
リベスト・シャミール・エイドルマン (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 ビット剰余

注意

P-384 は secp384r1 または nistp384 としても知られています。 P-521 などの他の楕円曲線は許可されません。

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

Windows では、WPA3 エンタープライズ 192 ビット モードのTLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384TLS_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 を必要とし、AES-256 AEAD と SHA384 ハッシュと共に ECDSA または RSA 証明書を許可するため、TLS_AES_256_GCM_SHA384TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384TLS_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 を使用する必要があります。

その他の資料