ユースケースとリファレンスアーキテクチャ

ユースケースの概要

エンタープライズ ネットワークには、さまざまな種類のクライアントからさまざまな方法でアクセスできます。これにより、それらのデバイスへのアクセスを管理および許可する方法と、各クライアントが使用できるネットワークのリソースを定義する方法について、ある種のフェデレーションが必要になります。

アーキテクチャ:RADIUSプロトコルを使用する理由

現在、すべての中央エンタープライズ認証スキーマは、RADIUS プロトコルの使用法と、さまざまな EAP 方法を使用した強力なクライアント認証に IEEE 802.1X を使用することに基づいています。

企業では、他にも2つの認証プロトコルが使用されることがあります。

• TACACSとTACACS+は、レガシープロトコルと見なすことができます。現在でも、デバイスの管理CLIアクセスに使用されることがありますが、RADIUSを使用しても実行できます。新規導入では使用しないでください。Juniper Mist Access Assuranceは、このプロトコルをサポートしていません。
• Diameter は進化したプロトコルで、より複雑になっていますが、プロトコル ルーティングとメッセージングの堅牢性のために多くの機能が追加されています。このプロトコルの主な用途は、従来のSS7プロトコルを置き換えるためのモバイルネットワークです。Juniper Mist Access Assuranceは、このプロトコルをサポートしていません。

RADIUS プロトコルは、IETF RFC 2865 および RFC 2866 で定義されています。これは、主に3つの目的を果たします。

• 認証:ネットワークへのアクセスを求めるユーザーとデバイスの認証。認証は、単純なユーザー名とパスワードのチェック、またはロールアウトされたPKIの証明書ベースのチェック、スマートカードまたはモバイルSIMのチェックなど、さまざまなものがあります。したがって、プロトコル自体は新しい認証方法に対して拡張可能です。
• 承認:正常に認証された後のユーザーとデバイス。認証の一環として、ユーザーまたはデバイスがネットワーク全体に無制限にアクセスできるか、ネットワークへのアクセスが何らかの方法で制限されているかが決定されます。この制限が何を意味するかは、制限できるアクセスとその方法によって異なります。最も一般的な例は、エンタープライズ ネットワーク内の有線または無線クライアントに VLAN を割り当てる場合です。これは、割り当てられた VLAN によって、ユーザーがアクセスできるリソースが制限されるためです。
• アカウンティング - ユーザーとデバイスのアカウンティング。認証が実行され、承認が適用された後、ネットワークは、ネットワーク上での時間や転送されたバイトの出入りなど、クライアントのネットワーク使用状況に関する統計情報を定期的に提供します。これは、課金目的でのサービス プロバイダ ネットワークではより関連性が高く、エンタープライズ ネットワークではあまり一般的に使用されません。

RADIUSプロトコルを理解するには、次の項目が重要です。ただし、ここではプロトコルの詳細と実装方法を確認していません。さらに情報が必要な場合は、プロトコルの元の RFC またはウィキペディア の記事 を確認することを検討してください。

• このプロトコルは、交換にUDPメッセージを使用します。転送中にメッセージが失われた場合は、要求が破棄されるまで、数回の自動再送信が行われます。
• RADIUSプロトコルは本質的に拡張可能です。デフォルトの属性値ペア(AVP)はRFCで定義されていますが、ベンダーはデバイスに固有の新しいAVPを作成できます。通常、このような拡張機能は、デバイスに関するより多くの情報を共有したり、認証パラメーターを強化してより詳細な実施ポイントを提供したりするために行われます。
• ネットワークアクセスデバイスは、ネットワークのエッジの トラフィックイングレス:
  • エンタープライズネットワークでは、これはアクセススイッチまたはAPです。
  • リモートブランチ内の複数のインスタンスでも、キャンパスファブリックの最下層レベルでもかまいません。
  • デバイスがネットワーク アクセス デバイスに接続するときに使用するプロトコルは定義されていません。最も一般的には、次のように表示されます。
    • イーサネットスイッチポート上の新しいMACアドレスの出現。
    • EAP 認証を開始する有線または無線クライアント(この章で詳しく説明します)。
  • ユーザーまたはクライアントの承認の強制は、通常、このレベルで行われます。
  • ネットワーク アクセス デバイスには、すべてのメッセージを RADIUS UDP メッセージにカプセル化して RADIUS サーバーに送信する RADIUS クライアントが実装されています。
• RADIUSサーバーは通常、ネットワークの中央の場所に配置され、VPN(またはパブリックIPアドレス)を使用してネットワークアクセスデバイスからアクセス可能であり、RADIUSクライアントメッセージに受動的に応答します。
  • 冗長性上の理由から、通常は2台のRADIUSサーバーが展開されます。ただし、ネットワーク アクセス デバイスは、別の RADIUS サーバーにフェールオーバーするタイミングを選択します。
  • ベンダーが標準のRADIUS属性を拡張した場合、これらのRADIUS AVPを利用できるように、ベンダー固有の属性もベンダーのRADIUSディクショナリを介して設定する必要があります。
  • RADIUSサーバーは、クライアントの認証を確認するためのネットワーク内の意思決定ポイントです。
    • ネットワークアクセスデバイスを介して転送されるある種のクライアント資格情報を取得する。
    • 資格情報データベースからもクライアント資格情報を取得する。
    • 2 つの情報セットを比較し、それらが有効かどうかを判断し、クライアントが合格できるかどうかを判断します。
  • RADIUSサーバーには、ローカルの組み込みクレデンシャルデータベースか、標準プロトコルを使用してリモートからアクセスできるクレデンシャルデータベースがあります。これらのプロトコルは、通常、次のいずれかです。
    • OAuth2 (パブリック IdP を使用して認証する場合)。
    • ローカル(アクティブ)ディレクトリを使用する場合の Lightweight Directory Access Protocol (LDAP)。
    • SQL または HLR/HSS データベースは、より一般的には (モバイル) サービス プロバイダーによって使用されます。
  • ローカルまたはリモートの資格情報データベースには、ユーザーレコードとともに、クライアントの認証が成功したときに使用される認証プロファイルに関する情報も含まれています。
  • ユーザーの認証が正常に完了すると、RADIUS サーバーは、以下を含む可能性のある Access-Accept メッセージを返します。
    • セキュアな通信を確立するために、クライアントデバイスとネットワークアクセスデバイス間で使用される動的暗号化キーマテリアル。
    • 承認 RADIUS AVP をネットワーク アクセス デバイス上で適用し、クライアントのネットワークへのアクセスを制限します。ベンダー固有のAVPを使用して、RADIUSサーバはネットワークアクセスデバイスで認識されるものだけを送信します。

図2は、RADIUSプロトコルがネットワークのどこに実装され、どのように使用されるかを示しています。

図 3 のワークフロー例では、スイッチで MAC アドレスベースの認証を使用して、フレームワークがどのように連携するかを確認します。

1. 有線ネットワークへのアクセスを希望するデバイスは、いくつかのメッセージ(ARP/DHCPリクエスト)を送信します。
2. スイッチはポートで新しいMACアドレスを確認し、ネットワークへの以降の通信をすべてブロックします。
3. 新たに検出されたMACアドレスは、ユーザー名とパスワードに変換され、承認のためにRADIUS Access-Requestとして送信されます。他の RADIUS AVP も組み込まれています。たとえば、リクエストに関する場所(ポート情報)を記述する AVP などがあります。
4. RADIUS アクセス要求を受信すると、RADIUS サーバーは RADIUS メッセージの内容を分析し、認証の実行に必要な RADIUS AVP を抽出します。この例では、ユーザー名属性が使用され、ユーザー名に関する情報(クライアントのMACアドレスと同じ)を受信するための要求が内部クレデンシャルデータベースに送信されます。
5. 資格情報データベースは、ユーザー レコードが見つかった場合は空のパスワードを返し、有効な場合は、このクライアントに使用するパスワードと認証プロファイル (通常は文字列) を返します。
6. RADIUSサーバーは、クライアントと資格情報データベースから送信されたパスワードを比較します。これらが一致すると、スイッチへの応答としてAccess-Acceptメッセージが作成されます。認証の成功の一環として、認証プロファイルを使用して、特定のネットワーク アクセス デバイス(スイッチ)に保存されている RADIUS AVP を追加し、それらを Access-Accept メッセージに追加します。この例では、クライアントに特定のVLANを使用してもらいたいため、属性「Tunnel-Private-Group-ID」には、参照として設定されたスイッチ上のVLAN名が含まれています。
7. RADIUSサーバーは、Access-Acceptと認証情報(割り当てるVLAN)をクライアントに返します。
8. ネットワーク アクセス デバイスとして機能するスイッチは、Access-Accept メッセージを受信すると、ポートのブロックを解除することで、クライアントがネットワークとさらに通信できるようにします。スイッチが認証 RADIUS AVP も受信すると、それらも適用されます。この場合、ポートに割り当てられたデフォルトVLANは、クライアントに使用を許可したVLANに置き換えられます。
9. オプション: RADIUS Accounting-Start メッセージが作成され、RADIUS サーバーに送信されます。繰り返しますが、エンタープライズネットワークでは必要ありません。
10. オプション:RADIUSサーバーは、この情報をローカルに保存したり、何らかのデータベースに転送したりできます。
11. オプション:RADIUSサーバーは、アカウンティングメッセージを確認します。
12. これで、クライアントがネットワークにアクセスできるようになります。認証が使用されている場合、スイッチはそれを適用し、なんらかの方法でアクセスを制限します。

手記：

この例では、シンプルなMAB(MACアドレスベースの認証)を使用しています。ただし、既知のMACアドレスは、攻撃者によって簡単に再利用される可能性があります。したがって、MAB は、クライアントが 802.1X 認証をサポートしていない場合にのみ使用してください。

アーキテクチャ: 802.1X認証とは?

• ポートベースのネットワークアクセス制御の標準。
• 非常に強力な暗号化認証を提供できます。
• 常に 3 つの関係者が関与します。
  • サプリカントLANまたはWLANにアクセスしようとするデバイス。このJVDには、次のサプリカントがあります。
    • Windows 11 デスクトップ クライアント (有線または無線)
    • Linuxデスクトップクライアント(有線または無線)
  • オーセンティケータ—クライアントとネットワーク間のトラフィックを許可またはブロックできる、クライアントとネットワーク間のデータ・リンクを提供するネットワーク・アクセス・デバイス。このJVDには、次のオーセンティケータがあります。
    • ジュニパーネットワーク®スEXシリーズスイッチ
    • ジュニパー®のハイパフォーマンスアクセスポイントシリーズ
  • 認証サーバーーネットワーク アクセスの要求を受信して応答します。このJVDには、次の認証サーバーがあります。
    • Juniper Mist Access Assurance
• EAP のカプセル化方法を定義します。
  • 使用されるEAP方式は交換可能です。これらは、サプリカント(サポートするさまざまなカプセル化方法を1つずつ提供)と認証サーバー(サポートするサプリカントが提供する方法を確認する)の間でネゴシエートされます。
  • サプリカントと認証サーバー間の最も一般的なトランスポートは、EAP over LAN(EAPoL)です。NASから認証サーバーへのメッセージは、RADIUS内でトンネリングされます。
  • サプリカントは、RFC 2486 で最初に説明されているように、ネットワーク アクセス識別子(NAI)と呼ばれる使用する外側の EAP ID を選択します。これにより、受信側の認証サーバーは、ローミングクライアントに対して責任を負わない場合に備えて、別の認証サーバーに要求をプロキシできます。
  • NAS/オーセンティケータは、認証プロセス自体には関与しません。このプロセスは、サプリカントと認証サーバー間でのみ処理されます。NAS/オーセンティケータはメッセージのみを転送します。つまり、オーセンティケータが802.1Xをサポートしている場合、既知のすべてのEAPプロトコルを処理できます。問題は、サプリカントと認証サーバーの両方が特定の EAP プロトコルをサポートしているかどうかです。
  • 使用されるEAPプロトコルに基づいて、認証サーバーからオーセンティケータに送信されるAccess-Acceptメッセージには、動的に作成された暗号化キーマテリアルが含まれる場合があります。これを使用して、サプリカントとオーセンティケータの間に暗号化リンクを確立できます。最も一般的に使用されるのは、WLANアクセス用のエンタープライズグレードの動的WPA2およびWPA3暗号化です。

図 5 の例は、内部 PAP 認証方式を使用した EAP-TTLS を示しています。これには以下が含まれます。

• この EAP 方式では、エンタープライズ公開キー基盤 (PKI) を使用して、次の証明書情報を生成して事前に展開します。
  • RADIUS サーバー上のルート CA、中間署名 CA、および TLS サーバー証明書(公開鍵と秘密鍵を含む)。
  • ルート CA と、何らかのエンタープライズ デバイス管理方法を介した中間署名 CA をサプリカントに送信します。これは、サーバーが提供する証明書を検証するために必要です。
• その後、サプリカントはEAPoLメッセージの送信を開始し、オーセンティケータはRADIUSメッセージ内部を認証サーバーに転送して、以下を実行します。
  • サプリカントとRADIUSサーバーの間にセキュアなTLSトンネルを構築します。
  • TLSトンネル(下の図には示されていません)内では、ユーザー名とパスワードの資格情報が交換されます。
• 以前のMACアドレスベースの認証と同様に、これらの認証情報は認証情報データベースと交換され、認証サーバー上で検証されます。
• クレデンシャルチェックでオプションの認証が検証された場合、返されるAccess-AcceptメッセージにRADIUS AVPが追加されることがあります。この例では、使用する特定のVLANを強制します。
• 次に、オーセンティケータは、サプリカントが認証サーバーからAccess-Acceptメッセージを受信したときに、サプリカントのアクセスを開くことを監視し、受信したすべての認証パラメータを適用します(この例では、特定のVLANへのアクセスをクライアントに許可します)。

手記：

前の例との比較を容易にするために、WPA2 および WPA3 エンタープライズ WLAN クライアントで一般的な、埋め込み動的暗号化キー マテリアル配布と、サプリカントとオーセンティケータ間の暗号化リンクのその後のネゴシエーションを削除しました。

エンタープライズ ネットワークでは、技術的に可能な場合は強力な EAP 方式を使用する必要があります。下の図を確認して、最適な方法を選択できるようにしてください。

EAP を技術的に使用できない場合は、次の図に示すオプションを検討してください。

アーキテクチャ:認証器とRADIUSサーバー間でRadSecトンネルを使用する

Juniper Mist Access Assuranceソリューションは、認証器とRADIUSサーバー間のRADIUS UDPメッセージにラップされた追加のプロトコル/トンネルを使用します。

• このトンネルは、TLS V1.2 および V1.3 プロトコル (HTTPS 経由の Web サーバー接続を保護するために使用されるものなど) に基づいています。
• RADIUSサーバーへのTCP宛先ポートは2083です。
• Juniper Mist認証クラウドの一部であるRADIUSサーバーには、FQDN radsec.nac.mist.com を介してアクセスできます。
• Juniper Mist認証クラウドは、認証クラウドでTLS接続を構築できるように、証明書を作成してオーセンティケータに読み込む役割を担います。このため、Juniper Mistは組織ごとに独自のPKIを作成します。

この RadSec 設計を選択する理由には、いくつかの技術的な理由があります。

• これは、RADIUS サーバーがインターネット上でリモートである場合に、より堅牢なトランスポートです。
• 認証情報とクライアント情報は、RadSec TLSトンネルにより、盗聴や blastradius などの中間者攻撃から保護されます。これにより、RADIUS クライアントとサーバー間で定義される強力で個別の共有シークレットの必要性も緩和されます。
• エンタープライズファイアウォール管理者は、リモートUDPポートを開くよりも、TLS接続を開く方が自信があります。
• 固定FQDNを使用することで、ソリューションはグローバルDNSロードバランサーを介して最も近いJuniper Mist認証クラウドを選択できます。RadSec 終端は、常に最も近い利用可能なJuniper Mist認証クラウドに対して行われ、遅延が最適化されます。
• Juniper Mistクラウドで管理されていないサードパーティ製デバイスやジュニパー製スイッチを使用する場合は、追加のプロキシを計画する必要があります。このプロキシは、従来のオンサイトRADIUSに代わるもののように機能し、RADIUSとRadSecの間でJuniper Mist認証クラウドに向けて変換を行います。Juniper Mist™ Edge アプライアンスを使用して、このプロキシ サービスをホストできます。
• Juniper Mist RADIUSサーバーはこれらのメッセージに既存のTLSトンネルを使用できるため、RADIUS認証変更メッセージを今後使用する場合、非常に簡単に埋め込むことができます。

重要なポイントは、従来のRADIUSサーバーはもはやローカルではなく、企業VPN経由で到達可能である必要があるということです。これは現在、Juniper Mist認証クラウドオファーの機能です。また、最近ではクライアントの認証情報だけでなく、認証する必要があるため、顧客がAzure ADやOktaなどのパブリックIdPを採用し始めているため、資格情報データベースは通常ローカルではありません。これをシームレスに実現するために、RadSecのトンネルと構成は、Juniper Mist認証クラウドによって管理されます。

アーキテクチャ:Juniper Mist Access Assuranceフレームワーク

以下の図は、Juniper Mist Access Assuranceのフレームワーク全体をまとめたものです。Access Assurance管理者は、スイッチやAPの管理に使用するものと同じJuniper Mistポータルを使用し、それのみを見ることに注意してください。

この章で示したローカルRADIUSサーバとクレデンシャルデータベースを使用した最初の認証例(図3)を参照して、 図8と比較します。 図 8 の相違点に注目してください。

• Juniper Mist認証クラウドは、RadSecトンネルを構築するための証明書の作成と認証デバイスへの読み込みを監視します。
• RADIUSサーバーと認証データベースは、Juniper Mist認証クラウドに移動されました。
• 認証器とJuniper Mist Access Assurance(RADIUSサーバー)間でTLSトンネルとしてのRadSecが使用されるようになりました。
• 残りのワークフローはすべて変更されず、操作方法を変更することはありません。

図 9 は、上記の図 8 のプロキシとして Juniper Mist Edge デバイスを追加しています。これは、サードパーティ製デバイス(スイッチおよびAP)や、Juniper Mistクラウドで管理されていないジュニパーEXスイッチがある場合です。既存のRADIUSサーバーがある場合は、既存のスイッチやAPの設定を変更することなく、Mist Edgeプロキシをドロップイン交換として使用できます。

図10は、RadSecとJuniper Mist Access Assuranceを実装した場合のEAP 認証メソッドの動作を示しています。

• Juniper Mist認証クラウドは、RadSecトンネルを構築するための証明書の作成と認証デバイスへの読み込みを監視します。
• RADIUSサーバーはJuniper Mist認証クラウドに移動されました。
• 資格情報データベースはパブリック IdP に移動されました。
• TLSトンネルとしてのRadSecは、認証器とJuniper Mist Access Assurance(RADIUSサーバー)間で使用されるようになりました。
• 残りのワークフローはすべて変更されず、操作方法を変更することはありません。

図 11 では、前に示したように、上の図のプロキシとして Juniper Mist Edge デバイスが含まれていることがわかります。

支社/キャンパスファブリック設計への実装

NACソリューションは、常にクライアントがネットワークに入る場所で実行されます。認証されていないデバイスのトラフィックをブロックするか、ネットワークの最下層のエントリーレベルで認証を適用してアクセスを制限できる必要があります。設計上、NACソリューションは、ネットワークアクセス後に発生するトランスポートから独立しています。NAC ソリューションでは、転送が VLAN、VXLAN、ルーティングのいずれに基づいているかは関係ありません。次の表に、可能な順列を示します。

表1:Access Assurance実装の詳細

場所	アクセス 方式	設計	Mist Cloud 管理。	NACは 場所	RadSec サポート。	Mist Edge プロキシが必要ですか?
枝	ワイヤード	スタンドアロン ジュニパー スイッチ	はい	アクセス スイッチ	はい	いいえ
枝	ワイヤード	ジュニパーのバーチャルシャーシ	はい	アクセス スイッチ	はい	いいえ
枝	ワイヤレス	Mistアクセスポイント	はい	アクセスポイント	はい	いいえ
枝	ワイヤード	EOL ジュニパースイッチ/VC	いいえ	アクセス スイッチ	いいえ	はい
枝	ワイヤード	Juniperスイッチ/VCはMist管理対象外	いいえ	アクセス スイッチ	いいえ	はい
枝	ワイヤード	サードパーティ製スイッチ	いいえ	アクセス スイッチ	いいえ	はい
枝	ワイヤレス	サードパーティ製アクセスポイント	いいえ	アクセスポイント	いいえ	はい
CF EVPN マルチホーミング / CRB / ERB	ワイヤード	スタンドアロン ジュニパー スイッチ	はい	アクセススイッチ/ToR	はい	いいえ
CF EVPN マルチホーミング / CRB / ERB	ワイヤード	ジュニパーのバーチャルシャーシ	はい	アクセススイッチ/ToR	はい	いいえ
CF EVPN マルチホーミング / CRB / ERB	ワイヤレス	Mistアクセスポイント	はい	アクセスポイント	はい	いいえ
CF EVPN マルチホーミング / CRB / ERB	ワイヤード	EOL ジュニパースイッチ/VC	いいえ	アクセススイッチ/ToR	いいえ	はい
CF EVPN マルチホーミング / CRB / ERB	ワイヤード	Juniperスイッチ/VCはMist管理対象外	いいえ	アクセススイッチ/ToR	いいえ	はい
CF EVPN マルチホーミング / CRB / ERB	ワイヤード	サードパーティ製スイッチ	いいえ	アクセススイッチ/ToR	いいえ	はい
CF EVPN マルチホーミング / CRB / ERB	ワイヤレス	サードパーティ製アクセスポイント	いいえ	アクセスポイント	いいえ	はい
CF IP-Clos	ワイヤード	スタンドアロン ジュニパー スイッチ	はい	アクセススイッチ/リーフ	はい	いいえ
CF IP-Clos	ワイヤード	ジュニパーのバーチャルシャーシ	はい	アクセススイッチ/リーフ	はい	いいえ
CF IP-Clos	ワイヤレス	Mistアクセスポイント	はい	アクセスポイント	はい	いいえ
CF IP-Clos	ワイヤレス	サードパーティ製アクセスポイント	いいえ	アクセスポイント	いいえ	はい

図12に、Access Assuranceを使用した最も一般的な導入オプションを示します。

ネットワーク アクセス デバイスを RadSec(または Juniper Mist Edge プロキシを使用した RADIUS)用に設定した後、お客様の要件に応じた NAC ソリューションの統合を開始できます。以下は、一般的なタスクの例です。

• 現在、Juniper Mist Access Assuranceソリューションは、以下の認証方法をサポートしています。
  • パスワード認証プロトコル(PAP):主にMACアドレスベースの認証に使用されます。
  • Extensible Authentication Protocol-トランスポート層セキュリティ(EAP-TLS):サプリカントに事前に展開されたエンタープライズPKIからの証明書が必要なため、主にマシン認証に使用されます。
  • 内部認証としてのPAPを使用した拡張認証プロトコルトンネルトランスポート層セキュリティ(EAP-TTLS)—主に、ユーザー名とパスワードをIdPと照合する必要がある場合のユーザー認証に使用されます。
  • あまり一般的ではない: Protected Extensible Authentication Protocol-トランスポート層セキュリティ (PEAP-TLS) (OAuth2 などのバックエンド メソッドは NTLM ハッシュをサポートしていないため、PEAP-MS-CHAPv2 はサポートされていません)。
  • あまり一般的ではない:TLSを使用したTEAP(Tunnel Extensible Authentication Protocol)。EAP-TLS への移行を検討してください。

このリストにない方法は、お客様と話し合う必要があり、それらを使用するデバイスを変更する方法も必要です。これらの方法は、通常、レガシーデバイスによって使用されており、それらを適切にサポートするかを評価する必要があります。

• どの資格情報データベースが存在するか、およびそれらを認証および承認プロセスに統合する方法について話し合います。
  • MACアドレスベースの認証の場合、Juniper Mist Access Assuranceは許可されたMACのリストをホストします(OUIでベンダーを識別することもできます)。
  • 最も一般的に使用されるパブリック IdP には、次のものがあります。
    • Azure AD
    • Oktaは、Juniper Mist認証クラウドとIdPの間でOAuth2を活用しています。
    • Google Workspace は、Juniper Mist認証クラウドと IdP の間で LDAP over SSL(LDAPS)を活用しています。
    • OAuth2を使用しているその他のIdPについては、ジュニパーの担当者にお問い合わせください。
• 認証プロファイルの必要性と、認証プロファイルをネットワークアクセスデバイスに適用する方法(特にサードパーティベンダーの属性が使用されている場合)について説明します。
• エンタープライズPKIの必要性について議論します。
  • ほとんどのお客様は、使用できる既存の PKI を持っています。公開ルートCA、任意の中間CAを取得し、IT担当者に、Juniper Mist Access Assurance RADIUSサーバー用にTLSサーバーの公開/秘密キーをPEM形式で生成するよう依頼します。
  • 組織ごとに生成され、RadSec に使用されるJuniper Mist PKI は、サプリカントが Juniper Mist ルート CA に導入されると、EAP-TTLS に再利用できます。
  • ユーザー証明書またはマシン証明書 (EAP-TLS、PEAP-TLS、TEAP-TLS) を使用するすべてのメソッドは、顧客のモバイル デバイス管理 (MDM) によって、顧客のエンタープライズ PKI から証明書を取得することが期待されます。
• IoTデバイスは、必要な計算に大量のバッテリーを使用するため、通常、強力なEAP 認証手法を活用していないため、その必要性について話し合います。フォールバックは通常、MAC ベースの認証または MPSK for WLAN です。
• BYOD統合とポータルページの必要性について話し合います。
• 教育環境では、eduroamのようなローミングのサポートが必要になるかもしれません。
• スイッチポートで認証されるサプリカントとして機能する必要があるAPの必要性について議論します。これは、新しいファームウェアを搭載したEOL以外のジュニパーAPでサポートされています。