この製品のドキュメントセットは、偏向のない言語を使用するように配慮されています。このドキュメントセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブ ランゲージの取り組みの詳細は、こちらをご覧ください。
シスコは世界中のユーザにそれぞれの言語でサポート コンテンツを提供するために、機械と人による翻訳を組み合わせて、本ドキュメントを翻訳しています。ただし、最高度の機械翻訳であっても、専門家による翻訳のような正確性は確保されません。シスコは、これら翻訳の正確性について法的責任を負いません。原典である英語版(リンクからアクセス可能)もあわせて参照することを推奨します。
このドキュメントでは、ユニファイドワイヤレスネットワーク(CUWN)上のIEEE 802.11ワイヤレスLAN(WLAN)で使用可能なワイヤレスおよび高速セキュアローミングのタイプについて説明します。
次の項目に関する知識があることが推奨されます。
このドキュメントの情報は、Cisco WLANコントローラソフトウェアバージョン7.4に基づくものです。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
このドキュメントの情報は、Cisco WLANコントローラソフトウェアバージョン7.4に基づいていますが、ここで説明するデバッグ出力と動作の大部分は、ここで説明する方式をサポートするソフトウェアバージョンであれば、どれにでも適用できます。ここで説明するすべての方式の詳細は、最新のCisco WLANコントローラコード(この記事が更新されるまでにバージョン8.3まで)でも同じです。
このドキュメントでは、Cisco Unified Wireless Network(CUWN)でサポートされている IEEE 802.11 ワイヤレス LAN(WLAN)で使用可能な、さまざまなタイプのワイヤレス ローミングおよび高速セキュア ローミングの方式について説明します。
このドキュメントでは、各方式の動作方法や設定方法の詳細については説明していません。このドキュメントの主な目的は、使用可能なさまざまな手法の違い、それぞれの利点と制約、および各方式でのフレーム交換について説明することです。WLANコントローラ(WLC)のデバッグの例を示し、ワイヤレスパケットイメージを使用して、説明されている各ローミング方式で発生するイベントを分析して説明します。
WLAN で使用できるさまざまな高速セキュア ローミング方式の説明の前に、WLAN 関連付けプロセスはどのように動作するか、サービス セット識別子(SSID)でセキュリティが設定されていない場合は通常どのようなローミング イベントが発生するか、理解することが重要です。
802.11 ワイヤレス クライアントは、アクセス ポイント(AP)に接続する際、トラフィック(ワイヤレス データ フレーム)を渡し始める前に、基本的な 802.11 オープン システム認証プロセスを通過する必要があります。次に、関連付けプロセスを完了する必要があります。オープンシステム認証プロセスは、クライアントが選択するAPのケーブル接続に似ています。これは非常に重要なポイントです。なぜなら、どのAPを優先するかを選択するのは常にワイヤレスクライアントであり、決定はベンダーによって異なる複数の要因に基づいて行われるからです。そのため、このプロセスは、このドキュメントで後述するように、クライアントが選択した AP に認証フレームを送信することで開始されます。接続の確立を AP の側から要求することはできません。
オープン システム認証プロセスが AP からの応答(「ケーブルが接続されたこと」)で正常に完了すると、関連付けプロセスにより、クライアントと AP 間のリンクを確立する 802.11 レイヤ 2(L2)のネゴシエーションが実質的に終了します。接続が正常に完了すると、AP は、クライアントに関連付け ID を割り当て、トラフィックを渡すことや、SSID に高レベル セキュリティ方式が設定されていればそれを実行することができるよう準備します。オープン システム認証プロセスは、2 つの管理フレームと関連付けプロセスで構成されています。認証フレームと関連付けフレームは、データ フレームではなくワイヤレス管理フレームであり、基本的に AP での接続プロセスに使用されるものです。
このプロセスの無線フレームの画像を次に示します。
注:802.11ワイヤレススニフィングと、Wiresharkでこのドキュメントに表示されるイメージに使用されるフィルタ/色については、シスコサポートコミュニティの投稿『802.11スニファイメージの分析』を参照してください。
ワイヤレス クライアントが認証フレームで開始し、AP が別の認証フレームで応答します。すると、クライアントが関連付け要求フレームを送信し、AP が関連付け要求フレームで応答して終了します。DHCP パケットが示すとおり、802.11 オープン システム認証プロセスと関連付けプロセスを通過すると、クライアントはデータ フレームを渡し始めます。このケースでは、SSID にはセキュリティ方式が設定されていないため、クライアントは、暗号化されないデータ フレーム(この例では、DHCP)の送信をただちに開始します。
このドキュメントで後述するように、SSIDでセキュリティがイネーブルになっている場合、アソシエーション応答の直後およびクライアントトラフィックのデータフレームが送信される前に、DHCP、Address Resolution Protocol(ARP;アドレス解決プロトコル)、アプリケーションパケットなどの特定のセキュリティ方式に対する高レベルの認証および暗号化ハンドシェイクフレームが存在し、暗号化されます。データ フレームは、設定されているセキュリティ方式に基づいてクライアントが完全に認証され、暗号キーがネゴシエートされるまで、送信できません。
前の図に基づいて、ワイヤレスクライアントがWLANへの新しい関連付けを開始したときのWLCのdebug clientコマンドの出力に表示されるメッセージを次に示します。
*apfMsConnTask_0: Jun 21 18:55:14.221: 00:40:96:b7:ab:5c
Association received from mobile on BSSID 84:78:ac:f0:68:d0
!--- This is the Association Request from the wireless client
to the selected AP.
*apfMsConnTask_0: Jun 21 18:55:14.222: 00:40:96:b7:ab:5c
Sending Assoc Response to station on BSSID 84:78:ac:f0:68:d0
(status 0) ApVapId 1 Slot 0
!--- This is the Association Response from the AP to the client.
注:このドキュメントに示す出力に使用されるWLCのデバッグは、debug clientコマンドです。例では、出力全体ではなく、関連するメッセージの一部のみを示しています。このdebugコマンドの詳細については、『ワイヤレスLANコントローラ(WLC)でのデバッグクライアントについて』を参照してください。
これらのメッセージは、関連付け要求フレームと応答フレームを示します。このハンドシェイクはCUWNのAPレベルで迅速に発生するため、初期認証フレームはWLCに記録されません。
クライアントがローミングする際には、どのような情報が表示されるでしょうか。クライアントは、AP への接続が確立されると常に、クライアントの関連付けの確立またはローミング イベントに起因する 4 つの管理フレームを交換します。クライアントが 1 度に確立する AP との接続は、1 つの AP との 1 つの接続のみです。WLAN インフラストラクチャへの新しい接続の場合とローミング イベントの場合で、フレーム交換に関する相違は 1 点のみです。それは、ローミング イベントの関連付けフレームが再関連付けフレームと呼ばれる点です。これは、クライアントが別の AP からローミングするときには、実際には WLAN への新しい関連付けの確立を試行していないことを意味しています。これらのフレームには、ローミングイベントのネゴシエートに使用されるさまざまな要素を含めることができます。これは設定によって異なりますが、これらの詳細については、このドキュメントでは説明しません。
フレーム交換の例を次に示します。
デバッグ出力には次のメッセージが表示されます。
*apfMsConnTask_2: Jun 21 19:02:19.709: 00:40:96:b7:ab:5c
Reassociation received from mobile on BSSID 84:78:ac:f0:2a:90
!--- This is the Reassociation Request from the wireless client
to the selected AP.
*apfMsConnTask_2: Jun 21 19:02:19.710: 00:40:96:b7:ab:5c
Sending Assoc Response to station on BSSID 84:78:ac:f0:2a:90
(status 0) ApVapId 1 Slot 0
!--- This is the Reassociation Response from the AP to the client.
上に示すように、クライアントが新しい AP に再関連付け要求を送信し、その AP から再関連付け応答を受信すると、ローミング イベントが正常に実行されます。クライアントにはすでに IP アドレスがあるため、最初のデータ フレームは ARP パケット用です。
ローミングイベントが予想される一方で、クライアントが再関連付け要求ではなく関連付け要求(このドキュメントで前述したイメージやデバッグに似ていくつかのイメージやデバッグから確認できます)を送信した場合、クライアントは実際にはローミングを行っていません。クライアントは、切断が行われたかのように WLAN への新しい関連付けを開始し、初めからの再接続を試行します。このことは、クライアントがカバレッジ エリアから退出した後に関連付けを開始するのに十分な信号品質を持つ AP を見つけた場合など、複数の理由で発生します。しかし通常は、クライアント側の問題(ドライバ、ファームウェア、またはソフトウェアの問題のためにクライアントがローミング イベントを開始しない)が考えられます。
注:問題の原因を特定するには、ワイヤレスクライアントのベンダーに問い合わせてください。
SSID に基本的な 802.11 オープン システム認証に加えて L2 のより高レベルのセキュリティが設定されている場合、初回関連付けやローミングのためには、さらに多くのフレームが必要になります。このドキュメントでは、802.11 WLAN 向けに標準化および導入されている最も一般的な 2 つのセキュリティ方式について説明します。
これらの 2 つの方式(PSK および EAP)は、クライアントを認証および確認する方法は異なりますが、キー管理プロセスには基本的に同じ WPA/WPA2 ルールが使用されていることを認識することが重要です。セキュリティが WPA/WPA2-PSK であっても WPA/WPA2-EAP であっても、使用される特定の認証方式でクライアントが確認されると、WPA/WPA2 の 4 方向ハンドシェイクと呼ばれるプロセスにより、WLC/AP とクライアント間のキー ネゴシエーションが、マスター セッション キー(MSK)を元のキー マテリアルとして開始されます。
プロセスの概要を次に示します。
暗号化のために Temporal Key Integrity Protocol(TKIP)または Advanced Encryption Standard(AES)を使用して WPA-PSK または WPA2-PSK を実行する際、クライアントは、初回関連付けとローミング両方の際に、WPA 4 方向ハンドシェイクと呼ばれるプロセスを実行する必要があります。すでに説明したように、これは、基本的には WPA/WPA2 が暗号キーを導出できるようにするため使用されるキー管理プロセスです。ただし、PSK が実行される際には、クライアントが WLAN に接続するために有効な事前共有キーを持っていることを確認するためにも使用されます。次の図に、WPAまたはWPA2とPSKを実行した場合の初期関連付けプロセスを示します。
上に示すように、802.11 オープン システム認証および関連付けプロセスの後に、WPA 4 方向ハンドシェイクからの 4 つの EAPOL フレーム(AP による message-1 で開始し、クライアントによる message-4 で終了)があります正常なハンドシェイクの後、クライアントはデータフレーム(DHCPなど)を渡し始めます。この場合、データフレームは4方向ハンドシェイクから取得されたキーで暗号化されます(ワイヤレスイメージから実際のコンテンツとトラフィックのタイプを確認できない理由です)。
注:EAPOLフレームは、APとクライアント間ですべてのキー管理フレームと802.1X/EAP認証フレームを地上波で伝送するために使用され、ワイヤレスデータフレームとして送信されます。
デバッグ出力には次のメッセージが表示されます。
*apfMsConnTask_0: Jun 21 19:30:05.172: 00:40:96:b7:ab:5c
Association received from mobile on BSSID 84:78:ac:f0:68:d1
*apfMsConnTask_0: Jun 21 19:30:05.173: 00:40:96:b7:ab:5c
Sending Assoc Response to station on BSSID 84:78:ac:f0:68:d1
(status 0) ApVapId 2 Slot 0
!--- The Association handshake is finished.
*dot1xMsgTask: Jun 21 19:30:05.178: 00:40:96:b7:ab:5c
Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c
state INITPMK (message 1), replay counter
00.00.00.00.00.00.00.00
!--- Message-1 of the WPA/WPA2 4-Way handshake is sent
from the WLC/AP to the client.
*Dot1x_NW_MsgTask_4: Jun 21 19:30:05.289: 00:40:96:b7:ab:5c
Received EAPOL-Key from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 19:30:05.289: 00:40:96:b7:ab:5c
Received EAPOL-key in PTK_START state (message 2)
from mobile 00:40:96:b7:ab:5c
!--- Message-2 of the WPA/WPA2 4-Way handshake is successfully
received from the client.
*Dot1x_NW_MsgTask_4: Jun 21 19:30:05.290: 00:40:96:b7:ab:5c
Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c
state PTKINITNEGOTIATING (message 3), replay counter
00.00.00.00.00.00.00.01
!--- Message-3 of the WPA/WPA2 4-Way handshake is sent
from the WLC/AP to the client.
*Dot1x_NW_MsgTask_4: Jun 21 19:30:05.309: 00:40:96:b7:ab:5c
Received EAPOL-Key from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 19:30:05.310: 00:40:96:b7:ab:5c
Received EAPOL-key in PTKINITNEGOTIATING state (message 4)
from mobile 00:40:96:b7:ab:5c
!--- Message-4 (final message) of the WPA/WPA2 4-Way handshake
is successfully received from the client, which confirms
the installation of the derived keys. They can now be used in
order to encrypt data frames with current AP.
ローミング時には、クライアントは基本的に同じフレーム交換を追跡します。このフレーム交換では、新しいAPで新しい暗号キーを取得するためにWPAの4方向のハンドシェイクが必要です。その理由は、標準規格によって確立されているセキュリティ上の理由と、新しい AP が元のキーを認識しないことです。唯一の違いは、次の図に示すように、アソシエーションフレームではなく再関連付けフレームがあることです。
デバッグ出力に表示されるメッセージは同じですが、クライアントからの最初のパケットは、すでに説明したように、関連付けではなく再関連付けです。
802.1X/EAP 方式を使用してクライアントの認証を安全な SSID で行う場合、クライアントがトラフィックを渡し始める前に、さらに多くのフレームが必要になります。これらの余分なフレームは、クライアントクレデンシャルを認証するために使用され、EAP方式によって、4 ~ 20フレームの間で使用できます。これらは、関連付けまたは再関連付けの後、かつ、WPA/WPA2 の 4 方向ハンドシェイクの前に来ます。その理由は、キー管理プロセス(4 方向ハンドシェイク)において最終的な暗号キーを生成するためのシードとして使用される MSK は、認証フェーズから導出されるためです。
次の図に、WPAとPEAPv0/EAP-MSCHAPv2が実行される際に、初期関連付けでAPとワイヤレスクライアントの間で無線で交換されるフレームの例を示します。
この交換では、フレームの数が異なることがあります。これには、EAP 方式の種類、問題発生による再送信、クライアントの動作(この例では、AP が最初の ID 要求を送信した後にクライアントが EAPOL START を送信したことによる 2 件の ID 要求)、またはクライアントがすでにサーバと証明書を交換しているかどうかなど、複数の要因があります。802.1X/EAP 方式のために SSID を設定すると、必ず、フレーム(認証用)が多くなるため、クライアントがデータ フレームの送信を開始するまでにより多くの時間がかかります。
デバッグ メッセージの要約を次に示します。
*apfMsConnTask_0: Jun 21 23:41:19.092: 00:40:96:b7:ab:5c
Association received from mobile on BSSID 84:78:ac:f0:68:d8
*apfMsConnTask_0: Jun 21 23:41:19.094: 00:40:96:b7:ab:5c
Sending Assoc Response to station on BSSID 84:78:ac:f0:68:d8
(status 0) ApVapId 9 Slot 0
!--- The Association handshake is finished.
*dot1xMsgTask: Jun 21 23:41:19.098: 00:40:96:b7:ab:5c
Sending EAP-Request/Identity to mobile 00:40:96:b7:ab:5c
(EAP Id 1)
!--- The EAP Identity Request is sent to the client once it is
associated in order to begin the higher-level authentication
process. This informs the client that an identity to start
this type of 802.1X/EAP authentication must be provided.
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.226: 00:40:96:b7:ab:5c
Received EAPOL START from mobile 00:40:96:b7:ab:5c
!--- The wireless client decides to start the EAP authentication
process, and informs the AP with an EAPOL START data frame.
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.227: 00:40:96:b7:ab:5c
Sending EAP-Request/Identity to mobile 00:40:96:b7:ab:5c
(EAP Id 2)
!--- WLC/AP sends another EAP Identity Request to the client.
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.235: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.235: 00:40:96:b7:ab:5c
Received Identity Response (count=2) from mobile 00:40:96:b7:ab:5c
!--- The client responds with an EAP Identity Response on an EAPOL
frame.
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.301: 00:40:96:b7:ab:5c
Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.301: 00:40:96:b7:ab:5c
Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
(EAP Id 3)
!--- Once the WLC/AP sends the client response to the Authentication
Server on a RADIUS Access-Request packet, the server responds
with a RADIUS Access-Challenge in order to officially start the
EAP negotiation, handshake, and authentication with the client
(sometimes with mutual authentication, dependent upon the EAP
method). This response received by the WLC/AP is sent to the client.
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.344: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.344: 00:40:96:b7:ab:5c
Received EAP Response from mobile 00:40:96:b7:ab:5c
(EAP Id 3, EAP Type 25)
!--- The client responds with an EAP Response on an EAPOL frame, which
is sent to the Authentication Server on a RADIUS Access-Request
packet. The server responds with another RADIUS Access-Challenge.
This process continues, dependent upon the EAP method (the exchange
of certificates when used, the building of TLS tunnels, validation
of client credentials, client validation of server identity when
applicable). Hence, the next few messages are basically the same on
the WLC/AP side, as this acts as a "proxy" between the client and
the Authentication Server exchanges.
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.347: 00:40:96:b7:ab:5c
Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.347: 00:40:96:b7:ab:5c
Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
(EAP Id 4)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.375: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.375: 00:40:96:b7:ab:5c
Received EAP Response from mobile 00:40:96:b7:ab:5c
(EAP Id 4, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.377: 00:40:96:b7:ab:5c
Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.377: 00:40:96:b7:ab:5c
Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
(EAP Id 5)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.403: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.403: 00:40:96:b7:ab:5c
Received EAP Response from mobile 00:40:96:b7:ab:5c
(EAP Id 5, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.404: 00:40:96:b7:ab:5c
Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.404: 00:40:96:b7:ab:5c
Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
(EAP Id 6)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.414: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.414: 00:40:96:b7:ab:5c
Received EAP Response from mobile 00:40:96:b7:ab:5c
(EAP Id 6, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.421: 00:40:96:b7:ab:5c
Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.421: 00:40:96:b7:ab:5c
Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
(EAP Id 7)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.425: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.425: 00:40:96:b7:ab:5c
Received EAP Response from mobile 00:40:96:b7:ab:5c
(EAP Id 7, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.427: 00:40:96:b7:ab:5c
Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.427: 00:40:96:b7:ab:5c
Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
(EAP Id 8)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.434: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.434: 00:40:96:b7:ab:5c
Received EAP Response from mobile 00:40:96:b7:ab:5c
(EAP Id 8, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.436: 00:40:96:b7:ab:5c
Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.436: 00:40:96:b7:ab:5c
Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
(EAP Id 9)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.440: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.440: 00:40:96:b7:ab:5c
Received EAP Response from mobile 00:40:96:b7:ab:5c
(EAP Id 9, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.442: 00:40:96:b7:ab:5c
Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.442: 00:40:96:b7:ab:5c
Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
(EAP Id 10)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.449: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.449: 00:40:96:b7:ab:5c
Received EAP Response from mobile 00:40:96:b7:ab:5c
(EAP Id 10, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.452: 00:40:96:b7:ab:5c
Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.452: 00:40:96:b7:ab:5c
Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
(EAP Id 11)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.457: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.457: 00:40:96:b7:ab:5c
Received EAP Response from mobile 00:40:96:b7:ab:5c
(EAP Id 11, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.459: 00:40:96:b7:ab:5c
Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.459: 00:40:96:b7:ab:5c
Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
(EAP Id 13)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.469: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.469: 00:40:96:b7:ab:5c
Received EAP Response from mobile 00:40:96:b7:ab:5c
(EAP Id 13, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.472: 00:40:96:b7:ab:5c
Processing Access-Accept for mobile 00:40:96:b7:ab:5c
!--- The authentication finishes and is successful for this client,
so the RADIUS Server sends a RADIUS Access-Accept to the WLC/AP.
This RADIUS Access-Accept comes with the special attributes
that are assigned to this client (if any are configured on the
Authentication Server for this client). This Access-Accept also
comes with the MSK derived with the client in the EAP
authentication process, so the WLC/AP installs it in order to
initiate the WPA/WPA2 4-Way handshake with the wireless client.
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.473: 00:40:96:b7:ab:5c
Sending EAP-Success to mobile 00:40:96:b7:ab:5c
(EAP Id 13)
!--- The accept/pass of the authentication is sent to the client as
an EAP-Success message.
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.473: 00:40:96:b7:ab:5c
Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c
state INITPMK (message 1), replay counter
00.00.00.00.00.00.00.00
!--- Message-1 of the WPA/WPA2 4-Way handshake is sent from the
WLC/AP to the client.
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.481: 00:40:96:b7:ab:5c
Received EAPOL-Key from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.481: 00:40:96:b7:ab:5c
Received EAPOL-key in PTK_START state (message 2)
from mobile 00:40:96:b7:ab:5c
!--- Message-2 of the WPA/WPA-2 4-Way handshake is successfully
received from the client.
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.481: 00:40:96:b7:ab:5c
Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c
state PTKINITNEGOTIATING (message 3), replay counter
00.00.00.00.00.00.00.01
!--- Message-3 of the WPA/WPA2 4-Way handshake is sent from the
WLC/AP to the client.
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.487: 00:40:96:b7:ab:5c
Received EAPOL-Key from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.487: 00:40:96:b7:ab:5c
Received EAPOL-key in PTKINITNEGOTIATING state (message 4)
from mobile 00:40:96:b7:ab:5c
!--- Message-4 (final message) of the WPA/WPA2 4-Way handshake
is successfully received from the client, which confirms the
installation of the derived keys. They can now be used in
order to encrypt data frames with the current AP.
ワイヤレスクライアントがここで通常のローミングを実行する場合(高速セキュアローミング方式を実装しない通常の動作)、クライアントはまったく同じプロセスを実行し、図に示すように認証サーバに対して完全な認証を実行する必要があります。唯一の違いは、クライアントは、実際には別の AP からローミングしていることを再関連付け要求を使用して新しい AP に通知しますが、それでも、全体的な確認と新しいキーの生成を実行する必要があることです。
上に示すように、クライアントが新しい AP にローミングしたときにフレーム数が(前述した複数の要因によって)初期認証よりも少ない場合であっても、データ フレームを渡し続けるためには、(ローミング前にトラフィックがアクティブに送信されていた場合であっても)EAP 認証と WPA キー管理プロセスを完了する必要があります。そのため、クライアントで遅延の影響を受けやすいアプリケーション(音声トラフィック アプリケーション、タイムアウトの影響を受けやすいアプリケーションなど)がアクティブになっている場合、音声の途切れやアプリケーションの切断などの問題がローミング時にユーザに感知されることがあります。これは、クライアントがデータ フレームの送受信を続行するためのプロセスにかかる時間によって異なります。この遅延は、RF環境、クライアントの数、WLCとLAP間のラウンドトリップ時間、認証サーバとのラウンドトリップ時間、およびその他の理由によって長くなる可能性があります。
このローミング イベントのデバッグ メッセージの要約を次に示します(前に示したデバッグと基本的に同じであるため、これらのメッセージの詳細は説明しません)。
*apfMsConnTask_2: Jun 21 23:47:54.872: 00:40:96:b7:ab:5c
Reassociation received from mobile on BSSID 84:78:ac:f0:2a:98
*apfMsConnTask_2: Jun 21 23:47:54.874: 00:40:96:b7:ab:5c
Sending Assoc Response to station on BSSID 84:78:ac:f0:2a:98
(status 0) ApVapId 9 Slot 0
*dot1xMsgTask: Jun 21 23:47:54.879: 00:40:96:b7:ab:5c
Sending EAP-Request/Identity to mobile 00:40:96:b7:ab:5c
(EAP Id 1)
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.895: 00:40:96:b7:ab:5c
Received EAPOL START from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.895: 00:40:96:b7:ab:5c
dot1x - moving mobile 00:40:96:b7:ab:5c intoConnecting
state
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.895: 00:40:96:b7:ab:5c
Sending EAP-Request/Identity to mobile 00:40:96:b7:ab:5c
(EAP Id 2)
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.922: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.922: 00:40:96:b7:ab:5c
Received Identity Response (count=2) from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.929: 00:40:96:b7:ab:5c
Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.929: 00:40:96:b7:ab:5c
Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
(EAP Id 3)
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.941: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.941: 00:40:96:b7:ab:5c
Received EAP Response from mobile 00:40:96:b7:ab:5c
(EAP Id 3, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.943: 00:40:96:b7:ab:5c
Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.943: 00:40:96:b7:ab:5c
Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
(EAP Id 4)
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.954: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.954: 00:40:96:b7:ab:5c
Received EAP Response from mobile 00:40:96:b7:ab:5c
(EAP Id 4, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.956: 00:40:96:b7:ab:5c
Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.957: 00:40:96:b7:ab:5c
Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
(EAP Id 7)
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.976: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.976: 00:40:96:b7:ab:5c
Received EAP Response from mobile 00:40:96:b7:ab:5c
(EAP Id 7, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.978: 00:40:96:b7:ab:5c
Processing Access-Accept for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.978: 00:40:96:b7:ab:5c
Sending EAP-Success to mobile 00:40:96:b7:ab:5c
(EAP Id 7)
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.978: 00:40:96:b7:ab:5c
Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c
state INITPMK (message 1), replay counter
00.00.00.00.00.00.00.00
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.995: 00:40:96:b7:ab:5c
Received EAPOL-Key from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.995: 00:40:96:b7:ab:5c
Received EAPOL-key in PTK_START state (message 2)
from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.995: 00:40:96:b7:ab:5c
Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c
state PTKINITNEGOTIATING (message 3), replay counter
00.00.00.00.00.00.00.01
*Dot1x_NW_MsgTask_4: Jun 21 23:47:55.005: 00:40:96:b7:ab:5c
Received EAPOL-Key from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:55.005: 00:40:96:b7:ab:5c
Received EAPOL-key in PTKINITNEGOTIATING state (message 4)
from mobile 00:40:96:b7:ab:5c
802.1X/EAP および WPA/WPA2 のセキュリティ フレームワークは、このように動作します。アプリケーションやサービスが通常のローミング イベントによる遅延の影響を受けないようにするため、WiFi 業界では、WLAN/SSID でのセキュリティが使用されているときのローミング プロセスを高速化することを目指し、さまざまな高速セキュア ローミング方式が開発および導入されています。WLAN で高レベル セキュリティを導入すると、AP 間でローミングしながらトラフィックを渡し続ける際に、クライアントには多少の遅延が発生します。この原因は、すでに説明したように、セキュリティのセットアップにより、EAP 認証およびキー管理フレーム交換が必要とされることです。
高速セキュア ローミングとは、単に「WLAN でセキュリティが設定されているときのローミング プロセスを高速化するための方式やスキームの導入」を指して業界で使用されている用語であることを理解することが重要です。 次の項では、WLAN で使用でき、CUWN でサポートされているさまざまな高速セキュア ローミングの方式およびスキームについて説明します。
Cisco Centralized Key Management(CCKM)は、WLAN で 802.1X/EAP セキュリティを使用する場合に、これまでに説明した遅延を緩和するソリューションとしてシスコが作成した、エンタープライズ WLAN で開発および導入された最初の高速セキュア ローミング方式です。これは、シスコの独自プロトコルであるため、CCKM に関して Cisco Compatible Extension(CCX)と互換可能な Cisco WLAN インフラストラクチャのデバイスおよびワイヤレス クライアント(複数のベンダー)でのみサポートされています。
CCKMは、WEP、TKIP、AESなど、WLANで使用できるさまざまな暗号化方式をすべて使用して実装できます。また、デバイスでサポートされている CCX のバージョンによっては、WLAN で使用される 802.1X/EAP 認証方式のほとんどをサポートしています。
注:CCX仕様の異なるバージョンでサポートされている機能の内容(サポートされているEAP方式を含む)の概要については、『CCXのバージョンと機能』を参照し、ワイヤレスクライアントでサポートされている正確なCCXバージョン(CCX互換の場合)を確認して、CCKMで使用するセキュリティ方式を実装できるかどうかを確認してください。
次のワイヤレスイメージは、暗号化としてTKIPを使用してCCKMを実行し、802.1X/EAP方式としてPEAPv0/EAP-MSCHAPv2を実行する場合の初期関連付け時に交換されるフレームの例を示しています。これは、基本的に PEAPv0/EAP-MSCHAPv2 とともに WPA/TKIP を実行した場合と同じ交換ですが、ここでは、クライアントがローミングする必要があるときには高速セキュア ローミングを実行するため、別のキー階層とキャッシュ方式を使用するように、クライアントとインフラストラクチャの間の CCKM がネゴシエートされています。
デバッグ メッセージの要約を次に示します(出力を減らすため、一部の EAP 交換を削除しています)。
*apfMsConnTask_0: Jun 25 15:41:41.507: 00:40:96:b7:ab:5c
Association received from mobile on BSSID 84:78:ac:f0:68:d3
!--- This is the Association Request from the client.
*apfMsConnTask_0: Jun 25 15:41:41.507: 00:40:96:b7:ab:5c
Processing WPA IE type 221, length 22 for mobile
00:40:96:b7:ab:5c
*apfMsConnTask_0: Jun 25 15:41:41.507: 00:40:96:b7:ab:5c
CCKM: Mobile is using CCKM
!--- The WLC/AP finds an Information Element that claims CCKM
support on the Association request that is sent from the client.
*apfMsConnTask_0: Jun 25 15:41:41.507: 00:40:96:b7:ab:5c
Setting active key cache index 8 ---> 8
!--- This is the key cache index for this client, which is set temporally.
*apfMsConnTask_0: Jun 25 15:41:41.508: 00:40:96:b7:ab:5c
Sending Assoc Response to station on BSSID 84:78:ac:f0:68:d3
(status 0) ApVapId 4 Slot 0
!--- The Association Response is sent to the client.
*dot1xMsgTask: Jun 25 15:41:41.513: 00:40:96:b7:ab:5c
Sending EAP-Request/Identity to mobile 00:40:96:b7:ab:5c
(EAP Id 1)
!--- An EAP Identity Request is sent to the client once it is
associated in order to begin the higher-level authentication
process. This informs the client that an identity to start
this type of 802.1X/EAP authentication must be provided.
Further EAP messages are not described, as they are basically
the same as the ones previously-explained.
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.536: 00:40:96:b7:ab:5c
Received EAPOL START from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.536: 00:40:96:b7:ab:5c
Sending EAP-Request/Identity to mobile 00:40:96:b7:ab:5c
(EAP Id 2)
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.546: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.546: 00:40:96:b7:ab:5c
Received EAP Response packet with mismatching id
(currentid=2, eapid=1) from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.550: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.550: 00:40:96:b7:ab:5c
Received Identity Response (count=2) from mobile
00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.555: 00:40:96:b7:ab:5c
Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.555: 00:40:96:b7:ab:5c
Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
(EAP Id 3)
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.594: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.594: 00:40:96:b7:ab:5c
Received EAP Response from mobile 00:40:96:b7:ab:5c
(EAP Id 3, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.840: 00:40:96:b7:ab:5c
Processing Access-Accept for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.841: 00:40:96:b7:ab:5c
Creating a PKC PMKID Cache entry for station 00:40:96:b7:ab:5c
(RSN 0)<br/ >
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.841: 00:40:96:b7:ab:5c
Setting active key cache index 8 ---> 8
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.841: 00:40:96:b7:ab:5c
Setting active key cache index 8 ---> 0
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.841: 00:40:96:b7:ab:5c
CCKM: Create a global PMK cache entry
!--- WLC creates a global PMK cache entry for this client,
which is for CCKM in this case.
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.841: 00:40:96:b7:ab:5c
Sending EAP-Success to mobile 00:40:96:b7:ab:5c
(EAP Id 13)
!--- The client is informed of the successful EAP authentication.
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.841: 00:40:96:b7:ab:5c
Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c state
INITPMK(message 1),replay counter 00.00.00.00.00.00.00.00
!--- Message-1 of the initial 4-Way handshake is sent from the
WLC/AP to the client.
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.858: 00:40:96:b7:ab:5c
Received EAPOL-Key from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.858: 00:40:96:b7:ab:5c
Received EAPOL-key in PTK_START state (message 2) from mobile
00:40:96:b7:ab:5c
!--- Message-2 of the initial 4-Way handshake is received
successfully from the client.
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.858: 00:40:96:b7:ab:5c
CCKM: Sending cache add
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.858: CCKM: Sending CCKM PMK
(Version_1) information to mobility group
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.858: CCKM: Sending CCKM PMK
(Version_2) information to mobility group
!--- The CCKM PMK cache entry for this client is shared with
the WLCs on the mobility group.
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.858: 00:40:96:b7:ab:5c
Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c
state PTKINITNEGOTIATING (message 3), replay counter
00.00.00.00.00.00.00.01
!--- Message-3 of the initial 4-Way handshake is sent from the
WLC/AP to the client.
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.866: 00:40:96:b7:ab:5c
Received EAPOL-Key from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.866: 00:40:96:b7:ab:5c Received
EAPOL-key in PTKINITNEGOTIATING state (message 4) from mobile
00:40:96:b7:ab:5c
!--- Message-4 (final message) of this initial 4-Way handshake
is received successfully from the client, which confirms the
installation of the derived keys. They can now be used in order
to encrypt data frames with the current AP.
CCKMでは、WLANへの最初の関連付けは通常のWPA/WPA2と似ており、MSK(ここではネットワークセッションキー(NSK)とも呼ばれます)がクライアントとRADIUSサーバの間で相互に生成されます。このプライマリ鍵は、認証が成功した後にサーバからWLCに送信され、このWLANとのクライアント関連付けのライフタイムの間、すべての後続の鍵を導出する基盤としてキャッシュされます。ここから、WLCとクライアントは、CCKMに基づく高速セキュアローミングに使用されるシード情報を取得します。これは、最初のAPでユニキャスト(PTK)とマルチキャスト/ブロードキャスト(GTK)の暗号キーを取得するために、WPA/WPA2と同様の4方向のハンドシェイクを実行します。
大きな違いは、ローミング時に明らかになります。この場合、CCKMクライアントはAP/WLCに単一の再関連付け要求フレーム(MICと順次増加するランダム番号を含む)を送信し、新しいPTKを取得するために十分な情報(新しいAP MACアドレス-BSSID-を含む)を提供します。WLC と新しい AP は、新しい PTK を導出するための 十分な情報もこの再関連付け要求から得られるため、再関連付け応答で応答するのみです。これで、次の図に示すように、クライアントは引き続きトラフィックを渡すことができます。
このローミング イベントの WLC デバッグの要約を次に示します。
*apfMsConnTask_2: Jun 25 15:43:33.749: 00:40:96:b7:ab:5c
CCKM: Received REASSOC REQ IE
*apfMsConnTask_2: Jun 25 15:43:33.749: 00:40:96:b7:ab:5c
Reassociation received from mobile on BSSID
84:78:ac:f0:2a:93
*apfMsConnTask_2: Jun 25 15:43:33.750: 00:40:96:b7:ab:5c
Processing WPA IE type 221, length 22 for mobile
00:40:96:b7:ab:5c
*apfMsConnTask_2: Jun 25 15:43:33.750: 00:40:96:b7:ab:5c
CCKM: Mobile is using CCKM
!--- The Reassociation Request is received from the client,
which provides the CCKM information needed in order to
derive the new keys with a fast-secure roam.
*apfMsConnTask_2: Jun 25 15:43:33.750: 00:40:96:b7:ab:5c
Setting active key cache index 0 ---> 8
*apfMsConnTask_2: Jun 25 15:43:33.750: 00:40:96:b7:ab:5c
CCKM: Processing REASSOC REQ IE
*apfMsConnTask_2: Jun 25 15:43:33.750: 00:40:96:b7:ab:5c
CCKM: using HMAC MD5 to compute MIC
!--- WLC computes the MIC used for this CCKM fast-roaming
exchange.
*apfMsConnTask_2: Jun 25 15:43:33.750: 00:40:96:b7:ab:5c
CCKM: Received a valid REASSOC REQ IE
*apfMsConnTask_2: Jun 25 15:43:33.751: 00:40:96:b7:ab:5c
CCKM: Initializing PMK cache entry with a new PTK
!--- The new PTK is derived.
*apfMsConnTask_2: Jun 25 15:43:33.751: 00:40:96:b7:ab:5c
Setting active key cache index 8 ---> 8
*apfMsConnTask_2: Jun 25 15:43:33.751: 00:40:96:b7:ab:5c
Setting active key cache index 8 ---> 8
*apfMsConnTask_2: Jun 25 15:43:33.751: 00:40:96:b7:ab:5c
Setting active key cache index 8 ---> 0
*apfMsConnTask_2: Jun 25 15:43:33.751: 00:40:96:b7:ab:5c
Creating a PKC PMKID Cache entry for station
00:40:96:b7:ab:5c (RSN 0) on BSSID 84:78:ac:f0:2a:93
!--- The new PMKID cache entry is created for this new
AP-to-client association.
*apfMsConnTask_2: Jun 25 15:43:33.751: 00:40:96:b7:ab:5c
CCKM: using HMAC MD5 to compute MIC
*apfMsConnTask_2: Jun 25 15:43:33.751: 00:40:96:b7:ab:5c
Including CCKM Response IE (length 62) in Assoc Resp to mobile
*apfMsConnTask_2: Jun 25 15:43:33.751: 00:40:96:b7:ab:5c
Sending Assoc Response to station on BSSID 84:78:ac:f0:2a:93
(status 0) ApVapId 4 Slot 0
!--- The Reassociation Response is sent from the WLC/AP to
the client, which includes the CCKM information required
in order to confirm the new fast-roam and key derivation.
*dot1xMsgTask: Jun 25 15:43:33.757: 00:40:96:b7:ab:5c
Skipping EAP-Success to mobile 00:40:96:b7:ab:5c
!--- EAP is skipped due to the fast roaming, and CCKM does not
require further key handshakes. The client is now ready to
pass encrypted data frames on the new AP.
上に示すように、新しい暗号キーが引き続き導出されていますが、CCKMネゴシエーションスキームに基づいているため、EAP認証フレームが回避され、さらに4方向ハンドシェイクが実行される間に、高速セキュアローミングが実行されます。高速セキュア ローミングは、ローミングの再アソシエーション フレームと、クライアントおよび WLC によって以前にキャッシュされた情報によって完了します。
Pairwise think Key ID(PMKID)キャッシング、つまりSticky Key Caching(SKC)は、802.11iセキュリティ修正案のIEEE 802.11標準によって提案された最初の高速セキュアローミング方式であり、主な目的はWLAN用に高レベルのセキュリティを標準化することです。この高速セキュア ローミング手法は、WPA2 デバイスに向けた任意の方法として、このセキュリティが実行されているときのローミングを改善するために追加されました。
これが可能なのは、クライアントと認証サーバは、クライアントが完全に EAP 認証されるたびに、PMK の導出に使用される MSK を導出するためです。これは、(クライアントが別のAPにローミングするか、セッションが期限切れになるまで)セッションに使用される最終的なユニキャスト暗号キー(PTK)を導出するために、WPA2の4方向ハンドシェイクのシードとして使用されます。したがって、この方法は、クライアントとAPによってキャッシュされた元のPMKを再利用するため、ローミング時のEAP認証フェーズを防止します。新しい暗号キーを導出するためにクライアントで必要となるのは、WPA2 の 4 方向ハンドシェイクを実行することだけです。
この方式は、802.11 標準規格で推奨される高速セキュア ローミング方式として広く導入されているわけではありません。その主な理由は次のとおりです。
この方式では、APへの初期関連付けは、WLANへの通常の初回認証と同様に、次の画面イメージに示すように、クライアントがデータフレームを送信する前に、認証サーバに対する802.1X/EAP認証全体とキー生成のための4方向ハンドシェイクが実行される必要があります。
デバッグでは、ここで使用するキー キャッシング手法に関する出力が追加されており、他の方式での WLAN への初期認証時に同じ EAP 認証フレーム交換が行われていることがわかります。これらのデバッグ出力は、EAP フレーム交換の全体を示すものではなく、新しい情報を中心に示すために抜粋したものです。このようにした理由は、認証サーバに対するクライアントの認証が行われるたびに交換される情報は、基本的に同じであるためです。これは、これまでに示されたものであり、パケットイメージに示されているEAP認証フレームと関連付けられているため、わかりやすくするために、ほとんどのEAPメッセージがデバッグ出力から削除されています。
*apfMsConnTask_0: Jun 22 00:23:15.097: ec:85:2f:15:39:32
Association received from mobile on BSSID 84:78:ac:f0:68:d2
!--- This is the Association Request from the client.
*apfMsConnTask_0: Jun 22 00:23:15.098: ec:85:2f:15:39:32
Processing RSN IE type 48, length 20 for mobile ec:85:2f:15:39:32
!--- The WLC/AP finds an Information Element that claims PMKID
Caching support on the Association request that is sent
from the client.
*apfMsConnTask_0: Jun 22 00:23:15.098: ec:85:2f:15:39:32
Received RSN IE with 0 PMKIDs from mobile ec:85:2f:15:39:32
!--- Since this is an initial association, the Association
Request comes without any PMKID.
*apfMsConnTask_0: Jun 22 00:23:15.098: ec:85:2f:15:39:32
Setting active key cache index 8 ---> 8
*apfMsConnTask_0: Jun 22 00:23:15.099: ec:85:2f:15:39:32
Sending Assoc Response to station on BSSID 84:78:ac:f0:68:d2
(status 0) ApVapId 3 Slot 0
!--- The Association Response is sent to the client.
*dot1xMsgTask: Jun 22 00:23:15.103: ec:85:2f:15:39:32
Sending EAP-Request/Identity to mobile ec:85:2f:15:39:32
(EAP Id 1)
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.118: ec:85:2f:15:39:32
Received EAPOL EAPPKT from mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.118: ec:85:2f:15:39:32
Received Identity Response (count=1) from mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.126: ec:85:2f:15:39:32
Processing Access-Challenge for mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.126: ec:85:2f:15:39:32
Sending EAP Request from AAA to mobile ec:85:2f:15:39:32
(EAP Id 2)
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.146: ec:85:2f:15:39:32
Received EAPOL EAPPKT from mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.146: ec:85:2f:15:39:32
Received EAP Response from mobile ec:85:2f:15:39:32
(EAP Id 2, EAP Type 25)
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.274: ec:85:2f:15:39:32
Processing Access-Accept for mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.274: ec:85:2f:15:39:32
Creating a PKC PMKID Cache entry for station ec:85:2f:15:39:32
(RSN 2)
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.274: ec:85:2f:15:39:32
Setting active key cache index 8 ---> 8
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.274: ec:85:2f:15:39:32
Setting active key cache index 8 ---> 0
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.274: ec:85:2f:15:39:32
Adding BSSID 84:78:ac:f0:68:d2 to PMKID cache at index 0
for station ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.274:
New PMKID: (16)
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.274:
[0000] c9 4d 0d 97 03 aa a9 0f 1b c8 33 73 01 f1 18 f5
!--- WLC creates a PMK cache entry for this client, which is
used for SKC in this case, so the PMKID is computed with
the AP MAC address (BSSID 84:78:ac:f0:68:d2).
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.274: ec:85:2f:15:39:32
Sending EAP-Success to mobile ec:85:2f:15:39:32
(EAP Id 12)
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.275:
Including PMKID in M1 (16)
!--- The hashed PMKID is included on the Message-1 of the
WPA/WPA2 4-Way handshake.
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.275:
[0000] c9 4d 0d 97 03 aa a9 0f 1b c8 33 73 01 f1 18 f5
!--- This is the hashed PMKID.
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.275: ec:85:2f:15:39:32
Sending EAPOL-Key Message to mobile ec:85:2f:15:39:32
state INITPMK (message 1), replay counter
00.00.00.00.00.00.00.00
!--- Message-1 of the WPA/WPA2 4-Way handshake is sent from
the WLC/AP to the client.
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.284: ec:85:2f:15:39:32
Received EAPOL-Key from mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.284: ec:85:2f:15:39:32
Received EAPOL-key in PTK_START state (message 2) from mobile
ec:85:2f:15:39:32
!--- Message-2 of the WPA/WPA-2 4-Way handshake is successfully
received from the client.
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.284: ec:85:2f:15:39:32
PMK: Sending cache add
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.285: ec:85:2f:15:39:32
Sending EAPOL-Key Message to mobile ec:85:2f:15:39:32
state PTKINITNEGOTIATING (message 3), replay counter
00.00.00.00.00.00.00.01
!--- Message-3 of the WPA/WPA2 4-Way handshake is sent from
the WLC/AP to the client.
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.291: ec:85:2f:15:39:32
Received EAPOL-Key from mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.291: ec:85:2f:15:39:32
Received EAPOL-key in PTKINITNEGOTIATING state (message 4)
from mobile ec:85:2f:15:39:32
!--- Message-4 (final message) of this initial WPA/WPA2 4-Way
handshake is successfully received from the client, which
confirms the installation of the derived keys. They can
now be used in order to encrypt data frames with the current AP.
この方式では、AP とワイヤレス クライアントは、確立済みのセキュアな関連付けの PMK をキャッシュします。したがって、ワイヤレスクライアントが関連付けされていない新しいAPにローミングする場合、クライアントは新しいAPにローミングする次の図に示すように、完全なEAP認証を再度実行する必要があります。
ただし、ワイヤレス クライアントが以前に関連付け/認証が実行された AP にローミングする場合は、クライアントは、複数の PMKID をリストした再関連付け要求フレームを送信し、クライアントが以前認証を行ったすべての AP からキャッシュされた PMK を AP に通知します。したがって、クライアントは、元の AP と同様に当該クライアントのためにキャッシュされた PMK を持っている AP に再度ローミングするため、新しい PMK を導出するために EAP で再認証を行う必要はありません。新しい一時的な暗号キーを導出するためにクライアントで必要となるのは、WPA2 の 4 方向ハンドシェイクを実行することだけです。
注:この図は、クライアントからの最初の802.11オープンシステム認証フレームを示していませんが、このフレームは常に必要であるため、実装された方式が原因ではありません。この理由は、この例のアダプタまたはワイヤレスパケットイメージソフトウェアがOver-the-Air(OTA;無線)フレームをスニッフィングするために使用している場合、この特定のフレームはイメージされないためです。ただし、この例では、参考のために、このようなイメージが残されています。Over-the-Airパケットイメージを実行する場合、これが発生する可能性があることに注意してください。一部のフレームはイメージで欠落する可能性がありますが、実際にはクライアントとAPの間で交換されます。そうでないと、この例ではローミングが開始しません。
この高速セキュア ローミング方式の WLC デバッグの要約を次に示します。
*apfMsConnTask_0: Jun 22 00:26:40.787: ec:85:2f:15:39:32
Reassociation received from mobile on BSSID
84:78:ac:f0:68:d2
!--- This is the Reassociation Request from the client.
*apfMsConnTask_0: Jun 22 00:26:40.787: ec:85:2f:15:39:32
Processing RSN IE type 48, length 38 for mobile
ec:85:2f:15:39:32
!--- The WLC/AP finds an Information Element that claims PMKID
Caching support on the Association request that is sent
from the client.
*apfMsConnTask_0: Jun 22 00:26:40.787: ec:85:2f:15:39:32
Received RSN IE with 1 PMKIDs from mobile
ec:85:2f:15:39:32
!--- The Reassociation Request from the client comes with
one PMKID.
*apfMsConnTask_0: Jun 22 00:26:40.787:
Received PMKID: (16)
*apfMsConnTask_0: Jun 22 00:26:40.788:
[0000] c9 4d 0d 97 03 aa a9 0f 1b c8 33 73 01 f1 18 f5
!--- This is the PMKID that is received.
*apfMsConnTask_0: Jun 22 00:26:40.788: ec:85:2f:15:39:32
Searching for PMKID in MSCB PMKID cache for mobile
ec:85:2f:15:39:32
!--- WLC searches for a matching PMKID on the database.
*apfMsConnTask_0: Jun 22 00:26:40.788: ec:85:2f:15:39:32
Found an cache entry for BSSID 84:78:ac:f0:68:d2 in
PMKID cache at index 0 of station ec:85:2f:15:39:32
*apfMsConnTask_0: Jun 22 00:26:40.788: ec:85:2f:15:39:32
Found a valid PMKID in the MSCB PMKID cache for mobile
ec:85:2f:15:39:32
!--- The WLC validates the PMKID provided by the client,
and confirms that it has a valid PMK cache for this
client-and-AP pair.
*apfMsConnTask_0: Jun 22 00:26:40.788: ec:85:2f:15:39:32
Setting active key cache index 1 ---> 0
*apfMsConnTask_0: Jun 22 00:26:40.788: ec:85:2f:15:39:32
Sending Assoc Response to station on BSSID
84:78:ac:f0:68:d2(status 0) ApVapId 3 Slot 0
!--- The Reassociation Response is sent to the client, which
validates the fast-roam with SKC.
*dot1xMsgTask: Jun 22 00:26:40.795: ec:85:2f:15:39:32
Initiating RSN with existing PMK to mobile
ec:85:2f:15:39:32
!--- WLC initiates a Robust Secure Network association with
this client-and-AP pair based on the cached PMK found.
Hence, EAP is avoided as per the next message.
*dot1xMsgTask: Jun 22 00:26:40.795: ec:85:2f:15:39:32
Skipping EAP-Success to mobile ec:85:2f:15:39:32
*dot1xMsgTask: Jun 22 00:26:40.795: ec:85:2f:15:39:32
Found an cache entry for BSSID 84:78:ac:f0:68:d2 in
PMKID cache at index 0 of station ec:85:2f:15:39:32
*dot1xMsgTask: Jun 22 00:26:40.795: Including PMKID in M1(16)
!--- The hashed PMKID is included on the Message-1 of the
WPA/WPA2 4-Way handshake.
*dot1xMsgTask: Jun 22 00:26:40.795:
[0000] c9 4d 0d 97 03 aa a9 0f 1b c8 33 73 01 f1 18 f5
!--- The PMKID is hashed. The next messages are the same
WPA/WPA2 4-Way handshake messages described thus far
that are used in order to finish the encryption keys
generation/installation.
*dot1xMsgTask: Jun 22 00:26:40.795: ec:85:2f:15:39:32
Sending EAPOL-Key Message to mobile ec:85:2f:15:39:32 state
INITPMK (message 1), replay counter 00.00.00.00.00.00.00.00
*Dot1x_NW_MsgTask_2: Jun 22 00:26:40.811: ec:85:2f:15:39:32
Received EAPOL-Key from mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 22 00:26:40.812: ec:85:2f:15:39:32
Received EAPOL-key in PTK_START state (message 2) from mobile
ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 22 00:26:40.812: ec:85:2f:15:39:32
PMK: Sending cache add
*Dot1x_NW_MsgTask_2: Jun 22 00:26:40.812: ec:85:2f:15:39:32
Sending EAPOL-Key Message to mobile ec:85:2f:15:39:32 state
PTKINITNEGOTIATING (message 3), replay counter
00.00.00.00.00.00.00.01
*Dot1x_NW_MsgTask_2: Jun 22 00:26:40.820: ec:85:2f:15:39:32
Received EAPOL-Key from mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 22 00:26:40.820: ec:85:2f:15:39:32
Received EAPOL-key in PTKINITNEGOTIATING state (message 4)
from mobile ec:85:2f:15:39:32
この方式は、キャッシュされたキーを管理する集中型デバイスを使用せず、自律型の独立した AP を使用してローカルに導入することができます。
Opportunistic Key Caching(OKC)は、Proactive Key Caching(PKC)とも呼ばれ(この用語は次の注で詳しく説明します)、基本的には前述のWPA2 PMKIDキャッシング方式の拡張であるため、Proactive/Opportunistic PMKIDキャッシングとも呼ばれます。したがって、標準規格 802.11 によって定義される高速セキュア ローミングの方式ではなく、多くのデバイスでサポートされていないことには注意が必要です。ただし、PMKID キャッシングと同様に WPA2-EAP と一緒に使用することができます。
この手法では、複数の AP 間でローミングする場合であっても、すべての AP が元の PMK(すべての WPA2 の 4 方向ハンドシェイクでシードとして使用される)を共有するため、ワイヤレス クライアントと WLAN インフラストラクチャは、クライアントと WLAN との関連付けのライフタイムにわたり、1 つの PMK(認証サーバでの初回の 802.1X/EAP 認証の後に MSK から導出されるもの)のみをキャッシュするだけで済みます。WPA2 の 4 方向ハンドシェイクは、SKC の場合と同様、クライアントが AP と再関連付けするたびに新しい暗号キーを生成するため、依然として必要です。複数の AP がクライアント セッションからの元の 1 つの PMK を共有するためには、元の PMK をキャッシュしてすべての AP に配布する集中型デバイスを使用し、それらの AP を何らかの管理制御下に置く必要があります。これは、WLCが制御下のすべてのLAPに対してこのジョブを実行し、複数のWLC間でこのPMKを処理するためにモビリティグループを使用するCUWNに似ています。したがって、これはAutonomous AP環境の制限です。
この方式では、PMKID キャッシング(SKC)の場合と同様、WLAN への通常の初回認証が、AP への初回関連付けとなります。そこでは、データ フレームを送信する前に、認証サーバに対する 802.1X/EAP 認証全体と、キーを生成するための 4 方向ハンドシェイクを完了する必要があります。これを示す画面イメージを次に示します。
デバッグ出力には、基本的に(図に示すように)WLANへの初期認証時に、このドキュメントで説明されているその他の方式と同じEAP認証フレーム交換が示されます。また、ここでWLCによって使用されるキーキャッシング方式に関する出力が追加されています。次のデバッグ出力も抜粋であり、関連する情報だけを示しています。
*apfMsConnTask_0: Jun 21 21:46:06.515: 00:40:96:b7:ab:5c
Association received from mobile on BSSID
84:78:ac:f0:68:d2
!--- This is the Association Request from the client.
*apfMsConnTask_0: Jun 21 21:46:06.516: 00:40:96:b7:ab:5c
Processing RSN IE type 48, length 20 for mobile
00:40:96:b7:ab:5c
!--- The WLC/AP finds an Information Element that claims
PMKID Caching support on the Association request that
is sent from the client.
*apfMsConnTask_0: Jun 21 21:46:06.516: 00:40:96:b7:ab:5c
Received RSN IE with 0 PMKIDs from mobile
00:40:96:b7:ab:5c
!--- Since this is an initial association, the Association
Request comes without any PMKID.
*apfMsConnTask_0: Jun 21 21:46:06.516: 00:40:96:b7:ab:5c
Setting active key cache index 0 ---> 8
*apfMsConnTask_0: Jun 21 21:46:06.516: 00:40:96:b7:ab:5c
Sending Assoc Response to station on BSSID
84:78:ac:f0:68:d2 (status 0) ApVapId 3 Slot
!--- The Association Response is sent to the client.
*dot1xMsgTask: Jun 21 21:46:06.522: 00:40:96:b7:ab:5
Sending EAP-Request/Identity to mobile 00:40:96:b7:ab:5c
(EAP Id 1)
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.614: 00:40:96:b7:ab:5c
Received EAPOL START from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.614: 00:40:96:b7:ab:5c
Sending EAP-Request/Identity to mobile 00:40:96:b7:ab:5c
(EAP Id 2)
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.623: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.623: 00:40:96:b7:ab:5c
Received Identity Response (count=2) from mobile
00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.630: 00:40:96:b7:ab:5c
Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.630: 00:40:96:b7:ab:5c
Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
(EAP Id 3)
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.673: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.673: 00:40:96:b7:ab:5c
Received EAP Response from mobile 00:40:96:b7:ab:5c
(EAP Id 3, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.843: 00:40:96:b7:ab:5c
Processing Access-Accept for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844: 00:40:96:b7:ab:5c
Creating a PKC PMKID Cache entry for station
00:40:96:b7:ab:5c (RSN 2)
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844: 00:40:96:b7:ab:5c
Setting active key cache index 8 ---> 8
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844: 00:40:96:b7:ab:5c
Setting active key cache index 8 ---> 0
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844: 00:40:96:b7:ab:5c
Adding BSSID 84:78:ac:f0:68:d2 to PMKID cache at index 0
for station 00:40:96:b7:ab:5
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844: New PMKID: (16)
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844:
[0000] 4e a1 7f 5a 75 48 9c f9 96 e3 a8 71 25 6f 11 d0
!--- WLC creates a PMK cache entry for this client, which is
used for OKC in this case, so the PMKID is computed
with the AP MAC address (BSSID 84:78:ac:f0:68:d2).
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844: 00:40:96:b7:ab:5c
PMK sent to mobility group
!--- The PMK cache entry for this client is shared with the
WLCs on the mobility group.
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844: 00:40:96:b7:ab:5c
Sending EAP-Success to mobile 00:40:96:b7:ab:5c (EAP Id 13)
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844: 00:40:96:b7:ab:5c
Found an cache entry for BSSID 84:78:ac:f0:68:d2 in PMKID
cache at index 0 of station 00:40:96:b7:ab:5
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844: Including PMKID
in M1 (16)
!--- The hashed PMKID is included on the Message-1 of the
WPA/WPA2 4-Way handshake.
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844:
[0000] 4e a1 7f 5a 75 48 9c f9 96 e3 a8 71 25 6f 11 d0
!--- This is the hashed PMKID. The next messages are the same
WPA/WPA2 4-Way handshake messages described thus far that
are used in order to finish the encryption keys
generation/installation.
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844: 00:40:96:b7:ab:5c
Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c state
INITPMK (message 1), replay counter 00.00.00.00.00.00.00.00
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.865: 00:40:96:b7:ab:5c
Received EAPOL-Key from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.865: 00:40:96:b7:ab:5c
Received EAPOL-key in PTK_START state (message 2)
from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.865: 00:40:96:b7:ab:5c
PMK: Sending cache add
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.865: 00:40:96:b7:ab:5c
Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c state
PTKINITNEGOTIATING (message 3), replay counter
00.00.00.00.00.00.00.01
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.889: 00:40:96:b7:ab:5c
Received EAPOL-Key from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.890: 00:40:96:b7:ab:5c
Received EAPOL-key in PTKINITNEGOTIATING state (message 4)
from mobile 00:40:96:b7:ab:5c
この方式では、ワイヤレス クライアントと(すべての管理対象 AP の)WLC は、最初に確立されたセキュアな関連付けから、元の 1 つの PMK をキャッシュします。基本的に、ワイヤレスクライアントが特定のAPに接続するたびに、クライアントのMACアドレス、APのMACアドレス(WLANのBSSID)、およびそのAPで取得されるPMKに基づいてPMKIDがハッシュされます。したがって、OKC は すべての AP と特定のクライアントのために同じ元 PMK をキャッシュするため、このクライアントが別の AP に(再)関連付けされる際に新しい PMKID をハッシュするために変更される値は、新しい AP MAC アドレスのみです。
クライアントは、新しいAPへのローミングを開始して再関連付け要求フレームを送信すると、キャッシュされたPMKが高速セキュアローミングに使用されることをAPに通知する場合、WPA2 RSN情報要素(IE)にPMKIDを追加します。ローミング先のBSSID(AP)のMACアドレスはすでに認識されており、クライアントはこの再関連付け要求で使用される新しいPMKIDをハッシュするだけです。クライアントからこの要求を受信すると、AP も、すでに保持している値(キャッシュされた PMK、クライアントの MAC アドレス、および当該 AP の MAC アドレス)を使用して PMKID をハッシュし、PMKID の一致を確認する成功の再関連付け応答で応答します。キャッシュされたPMKは、新しい暗号キーを取得するために(およびEAPをスキップするために)、WPA2の4方向ハンドシェイクを開始するシードとして使用できます。
この図では、フレームの詳細を表示できるように、クライアントからの再関連付け要求フレームが選択され、展開されています。MACアドレス情報と、802.11i - WPA2に準拠したRobust Security Network(RSN;堅牢セキュリティネットワーク)情報要素も示されています。この情報要素では、この関連付けに使用されているWPA2設定に関する情報が示されています(強調表示されているのは、ハッシュされた数式から取得されたPMKIDです)。
OKC を使用した高速セキュア ローミング方式の WLC デバッグの要約を次に示します。
*apfMsConnTask_2: Jun 21 21:48:50.562: 00:40:96:b7:ab:5c
Reassociation received from mobile on BSSID
84:78:ac:f0:2a:92
!--- This is the Reassociation Request from the client.
*apfMsConnTask_2: Jun 21 21:48:50.563: 00:40:96:b7:ab:5c
Processing RSN IE type 48, length 38 for mobile
00:40:96:b7:ab:5c
!--- The WLC/AP finds and Information Element that claims
PMKID Caching support on the Association request that
is sent from the client.
*apfMsConnTask_2: Jun 21 21:48:50.563: 00:40:96:b7:ab:5c
Received RSN IE with 1 PMKIDs from mobile
00:40:96:b7:ab:5c
!--- The Reassociation Request from the client comes with
one PMKID.
*apfMsConnTask_2: Jun 21 21:48:50.563:
Received PMKID: (16)
*apfMsConnTask_2: Jun 21 21:48:50.563:
[0000] 91 65 c3 fb fc 44 75 48 67 90 d5 da df aa 71 e9
*apfMsConnTask_2: Jun 21 21:48:50.563: 00:40:96:b7:ab:5c
Searching for PMKID in MSCB PMKID cache for mobile
00:40:96:b7:ab:5c
*apfMsConnTask_2: Jun 21 21:48:50.563: 00:40:96:b7:ab:5c
No valid PMKID found in the MSCB PMKID cache for mobile
00:40:96:b7:ab:5
!--- As the client has never authenticated with this new AP,
the WLC cannot find a valid PMKID to match the one provided
by the client. However, since the client performs OKC
and not SKC (as per the following messages), the WLC computes
a new PMKID based on the information gathered (the cached PMK,
the client MAC address, and the new AP MAC address).
*apfMsConnTask_2: Jun 21 21:48:50.563: 00:40:96:b7:ab:5c
Trying to compute a PMKID from MSCB PMK cache for mobile
00:40:96:b7:ab:5c
*apfMsConnTask_2: Jun 21 21:48:50.563:
CCKM: Find PMK in cache: BSSID = (6)
*apfMsConnTask_2: Jun 21 21:48:50.563:
[0000] 84 78 ac f0 2a 90
*apfMsConnTask_2: Jun 21 21:48:50.563:
CCKM: Find PMK in cache: realAA = (6)
*apfMsConnTask_2: Jun 21 21:48:50.563:
[0000] 84 78 ac f0 2a 92
*apfMsConnTask_2: Jun 21 21:48:50.563:
CCKM: Find PMK in cache: PMKID = (16)
*apfMsConnTask_2: Jun 21 21:48:50.563:
[0000] 91 65 c3 fb fc 44 75 48 67 90 d5 da df aa 71 e9
*apfMsConnTask_2: Jun 21 21:48:50.563:
CCKM: AA (6)
*apfMsConnTask_2: Jun 21 21:48:50.563:
[0000] 84 78 ac f0 2a 92
*apfMsConnTask_2: Jun 21 21:48:50.563:
CCKM: SPA (6)
*apfMsConnTask_2: Jun 21 21:48:50.563:
[0000] 00 40 96 b7 ab 5c
*apfMsConnTask_2: Jun 21 21:48:50.563: 00:40:96:b7:ab:5c
Adding BSSID 84:78:ac:f0:2a:92 to PMKID cache at
index 0 for station 00:40:96:b7:ab:5c
*apfMsConnTask_2: Jun 21 21:48:50.563:
New PMKID: (16)
*apfMsConnTask_2: Jun 21 21:48:50.563:
[0000] 91 65 c3 fb fc 44 75 48 67 90 d5 da df aa 71 e9
*apfMsConnTask_2: Jun 21 21:48:50.563: 00:40:96:b7:ab:5c
Computed a valid PMKID from MSCB PMK cache for mobile
00:40:96:b7:ab:5c
!--- The new PMKID is computed and validated to match the
one provided by the client, which is also computed with
the same information. Hence, the fast-secure roam is
possible.
*apfMsConnTask_2: Jun 21 21:48:50.563: 00:40:96:b7:ab:5c
Setting active key cache index 0 ---> 0
*apfMsConnTask_2: Jun 21 21:48:50.564: 00:40:96:b7:ab:5c
Sending Assoc Response to station on BSSID 84:78:ac:f0:2a:92
(status 0) ApVapId 3 Slot
!--- The Reassociation response is sent to the client, which
validates the fast-roam with OKC.
*dot1xMsgTask: Jun 21 21:48:50.570: 00:40:96:b7:ab:5c
Initiating RSN with existing PMK to mobile
00:40:96:b7:ab:5c
!--- WLC initiates a Robust Secure Network association with
this client-and AP pair with the cached PMK found.
Hence, EAP is avoided, as per the the next message.
*dot1xMsgTask: Jun 21 21:48:50.570: 00:40:96:b7:ab:5c
Skipping EAP-Success to mobile 00:40:96:b7:ab:5c
*dot1xMsgTask: Jun 21 21:48:50.570: 00:40:96:b7:ab:5c
Found an cache entry for BSSID 84:78:ac:f0:2a:92 in
PMKID cache at index 0 of station 00:40:96:b7:ab:5c
*dot1xMsgTask: Jun 21 21:48:50.570:
Including PMKID in M1 (16)
!--- The hashed PMKID is included on the Message-1 of the
WPA/WPA2 4-Way handshake.
*dot1xMsgTask: Jun 21 21:48:50.570:
[0000] 91 65 c3 fb fc 44 75 48 67 90 d5 da df aa 71 e9
!--- The PMKID is hashed. The next messages are the same
WPA/WPA2 4-Way handshake messages described thus far,
which are used in order to finish the encryption keys
generation/installation.
*dot1xMsgTask: Jun 21 21:48:50.570: 00:40:96:b7:ab:5c
Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c state
INITPMK (message 1), replay counter 00.00.00.00.00.00.00.00
*Dot1x_NW_MsgTask_4: Jun 21 21:48:50.589: 00:40:96:b7:ab:5
Received EAPOL-Key from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 21:48:50.589: 00:40:96:b7:ab:5c
Received EAPOL-key in PTK_START state (message 2) from mobile
00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 21:48:50.589: 00:40:96:b7:ab:5c
PMK: Sending cache add
*Dot1x_NW_MsgTask_4: Jun 21 21:48:50.590: 00:40:96:b7:ab:5c
Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c state
PTKINITNEGOTIATING (message 3), replay counter
00.00.00.00.00.00.00.01
*Dot1x_NW_MsgTask_4: Jun 21 21:48:50.610: 00:40:96:b7:ab:5c
Received EAPOL-Key from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 21:48:50.610: 00:40:96:b7:ab:5c
Received EAPOL-key in PTKINITNEGOTIATING state (message 4)
from mobile 00:40:96:b7:ab:5c
デバッグ出力の最初に示すように、クライアントからの再アソシエーション要求が受信された後で、PMKID が計算される必要があります。これは、PMKID を検証することで、キャッシュされた PMK が WPA2 4 ウェイ ハンドシェイクに使用され、暗号化キーが生成され、高速セキュア ローミングが完了したことを確認するために必要となります。デバッグのCCKMエントリを混同しないでください。これは、すでに説明したように、CCKMではなくOKCを実行するために使用されます。ここでの CCKM は、出力用に WLC によって使用される名前にすぎず、PMKID を計算するために値を処理する機能の名前のようなものです。
注:この設定は、APが同じFlexConnectグループ上にない場合でも機能しますが、推奨またはサポートされている設定ではありません。
Proactive Key Caching(PKC)はOKC(Opportunistic Key Caching)と呼ばれており、この2つの用語は、ここで説明する同じ方法を説明する際に同じ意味で使用されます。しかし、この用語は、2001 年の通信業界では単に古いキャッシング方式の意味で使用されていましたが、802.11i 標準規格により、「事前認証」(高速セキュア ローミングの一種。後に概略を説明します)の基盤という意味で使用されるようになりました。PKC は OKC(Opportunistic Key Caching)とも事前認証とも異なりますが、文献などで言及される PKC は、基本的には事前認証ではなく OKC を指しています。
この方式も、IEEE 802.11 標準規格の 802.11i セキュリティ修正版で提案されたものであるため、WPA2 でも動作します。しかし、この方式は、Cisco WLAN インフラストラクチャがサポートしていない唯一の高速セキュア ローミング方式です。したがって、ここでは、出力を使用せず簡単に説明するのみとします。
事前認証を使うと、ワイヤレス クライアントは、現在の AP に関連付けられた状態で、1 度に複数の AP への認証ができます。これが発生するとき、クライアントは、現在接続中の AP に EAP 認証フレームを送信しますが、この EAP 認証フレームの宛先は、クライアントが事前認証を行おうとする他の(単数または複数の)AP(ローミング先の候補となりうる近隣の AP)です。現在の AP は、これらのフレームを、分散システムを介してターゲット AP に送信します。新しい AP は、RADIUS サーバに対してこのクライアントの認証の全体を行います。それによって全体的な新しい EAP 認証 ハンドシェイクが完了し、この新しい AP は、オーセンティケータの役割を果たします。
考え方は、クライアントが近隣の AP にローミングを行う前に、それらの AP での認証と PMK 導出を実行するというものです。したがって、ローミングを実行するときには、クライアントはすでに認証されており、PMK も、AP とクライアントの間のこの新しい安全な関連付けのため、すでにキャッシュされています。したがって、クライアントが初回の再関連付け要求を送信した後は、AP と クライアントが 4 方法ハンドシェイクを行うだけで、高速ローミングができます。
事前認証のサポートをアドバタイズするRSN IEフィールドを示すAPビーコンからの画像を次に示します(これは、事前認証がサポートされていないことが確認されているCisco APからのものです)。
PMK は、AP と クライアントとの安全な関連付け 1 つにつき 1 つ存在します。このことは、AP が攻撃を受けてキーが盗まれた場合、セキュリティ上の利点とみなすことができます(キーは他の AP には使用できません)。ただし、このセキュリティ上の利点は、WLAN インフラストラクチャにより、他の方式においてさまざまな方法で対応されています。
802.11r 修正版に基づく高速セキュア ローミング手法(802.11 標準規格での正式名称は高速 BSS 移行、別名 FT)は、IEEE が AP(Basic Service Set(BSS))間の高速移行を実行するためのソリューションとして 802.11 規格で初めて(2008 年)正式に承認した方式であり、WLAN でキーを処理およびキャッシュする際に使用されるキー階層を明確に定義しています。ただし、その採用はあまり進んでいません。主な理由は、高速移行が実際に必要なときに使用可能なソリューションは、すでにほかにもあることです(このドキュメントですでに説明した方式のいずれかの VoWLAN 導入での使用など)。現在(2013 年まで)、何らかの FT オプションをサポートしているデバイスはごく少数です。
この手法は、新しい概念や、さまざまなデバイス(役割が異なる各デバイス)でキャッシュされる PMK の複数のレイヤが導入されていることから、他の方式より説明が複雑になります。また、高速セキュア ローミングのさらなるオプションを提供します。したがって、この方式については、方式の説明と使用可能な各オプションを伴う導入方法を概略的にまとめます。
802.11r は、SKC および OKC とは次の点が異なります。
この方式では、ワイヤレス クライアントは、WLAN インフラストラクチャに対する初期認証を、最初の AP への接続が確立されたときに 1 回だけ行って、同じ FT モビリティ ドメインの AP 間でローミングを行う際に高速セキュア ローミングを実行します。
FT モビリティ ドメインとは、新しい概念の 1 つで、基本的には、同じ SSID を使用する複数の AP(Extended Service Set または ESS と呼ばれます)で、同じ FT キーを使用するものを指します。これは、これまでに説明した他の方式と似ています。APがFTモビリティドメインキーを処理する方法は、通常、WLCやモビリティグループなどの集中型セットアップに基づいていますが、この方法はAutonomous AP環境にも実装できます。
キー階層の概要を次に示します。
注:WLANベンダーと実装のセットアップ(Autonomous AP、FlexConnect、メッシュなど)に応じて、WLANインフラストラクチャは異なる方法でキーを転送および処理できます。キーホルダーの役割を変更することさえできますが、これはこのドキュメントの適用範囲外であるため、前述のキー階層の概要に基づく例に次の焦点を当てます。違いは、ソフトウェアの問題を検出するためにインフラストラクチャ デバイス(およびコード)を詳しく分析することが実際に必要でない限り、実際には、プロセスの理解にはそれほど関連しません。
この方式では、APへの最初の関連付けは、WLANへの通常の初回認証です。そこでは、次の画面イメージに示すように、データフレームが送信される前に、認証サーバに対する802.1X/EAP認証全体と、キー生成のための4方向のハンドシェイクが行われる必要があります。
主な違いは次のとおりです。
デバッグには、基本的に(イメージから認識された)WLANへの初期認証時に、残りの方式と同じEAP認証フレーム交換が表示されますが、WLCで使用されるキーキャッシング方式に関する出力が追加されています。したがって、このデバッグ出力は、関連情報のみを表示するために抜粋されています。
*apfMsConnTask_0: Jun 27 19:25:23.426: ec:85:2f:15:39:32
Association received from mobile on BSSID
84:78:ac:f0:68:d6
!--- This is the Association request from the client.
*apfMsConnTask_0: Jun 27 19:25:23.427: ec:85:2f:15:39:32
Marking this mobile as TGr capable.
!--- WLC recognizes that the client is 802.11r-capable.
*apfMsConnTask_0: Jun 27 19:25:23.427: ec:85:2f:15:39:32
Processing RSN IE type 48, length 20 for mobile
ec:85:2f:15:39:32
!--- The WLC/AP finds an Information Element that claims FT
support on the Association request that is sent from the client.
*apfMsConnTask_0: Jun 27 19:25:23.427:
Sending assoc-resp station:ec:85:2f:15:39:32
AP:84:78:ac:f0:68:d0-00 thread:144be808
*apfMsConnTask_0: Jun 27 19:25:23.427:
Adding MDIE, ID is:0xaaf0
*apfMsConnTask_0: Jun 27 19:25:23.427: ec:85:2f:15:39:32
Including FT Mobility Domain IE (length 5) in Initial
assoc Resp to mobile
*apfMsConnTask_0: Jun 27 19:25:23.427: ec:85:2f:15:39:32
Sending R0KH-ID as:-84.30.6.-3
*apfMsConnTask_0: Jun 27 19:25:23.427: ec:85:2f:15:39:32
Sending R1KH-ID as 3c:ce:73:d8:02:00
*apfMsConnTask_0: Jun 27 19:25:23.427: ec:85:2f:15:39:32
Including FT IE (length 98) in Initial Assoc Resp to mobile
*apfMsConnTask_0: Jun 27 19:25:23.427: ec:85:2f:15:39:32
Sending Assoc Response to station on BSSID 84:78:ac:f0:68:d6
(status 0) ApVapId 7 Slot 0
!--- The Association Response is sent to the client once the
FT information is computed (as per the previous messages),
so this is included in the response.
*dot1xMsgTask: Jun 27 19:25:23.432: ec:85:2f:15:39:32
Sending EAP-Request/Identity to mobile ec:85:2f:15:39:32
(EAP Id 1)
!--- EAP begins, andfollows
the same exchange explained so far.
*apfMsConnTask_0: Jun 27 19:25:23.436: ec:85:2f:15:39:32
Got action frame from this client.
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.449: ec:85:2f:15:39:32
Received EAPOL EAPPKT from mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.449: ec:85:2f:15:39:32
Received Identity Response (count=1) from mobile
ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.456: ec:85:2f:15:39:32
Processing Access-Challenge for mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.456: ec:85:2f:15:39:32
Sending EAP Request from AAA to mobile ec:85:2f:15:39:32
(EAP Id 2)
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.479: ec:85:2f:15:39:32
Received EAPOL EAPPKT from mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.479: ec:85:2f:15:39:32
Received EAP Response from mobile ec:85:2f:15:39:32
(EAP Id 2, EAP Type 25)
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.627: ec:85:2f:15:39:32
Processing Access-Accept for mobile ec:85:2f:15:39:32
!--- The client is validated/authenticated by the RADIUS Server.
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.627: ec:85:2f:15:39:32
Creating a PKC PMKID Cache entry for station
ec:85:2f:15:39:32 (RSN 2)
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.627: ec:85:2f:15:39:32
Resetting MSCB PMK Cache Entry 0 for station
ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.627: ec:85:2f:15:39:32
Setting active key cache index 8 ---> 8
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.628: ec:85:2f:15:39:32
Setting active key cache index 8 ---> 0
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.628: ec:85:2f:15:39:32
Adding BSSID 84:78:ac:f0:68:d6 to PMKID cache at index 0
for station ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.628: New PMKID: (16)
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.628:
[0000] 52 b8 8f cf 50 a7 90 98 2b ba d6 20 79 e4 cd f9
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.629: ec:85:2f:15:39:32
Created PMK Cache Entry for TGr AKM:802.1x ec:85:2f:15:39:32
!--- WLC creates a PMK cache entry for this client, which is
used for FT with 802.1X in this case, so the PMKID is
computed with the AP MAC address (BSSID 84:78:ac:f0:68:d6).
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.629:
ec:85:2f:15:39:32 R0KH-ID:172.30.6.253
R1KH-ID:3c:ce:73:d8:02:00 MSK Len:48 pmkValidTime:1807
!--- The R0KH-ID and R1KH-ID are defined, as well as the PMK
cache validity period.
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.630: ec:85:2f:15:39:32
PMK sent to mobility group
!--- The FT PMK cache entry for this client is shared with the
WLCs on the mobility group.
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.630: ec:85:2f:15:39:32
Sending EAP-Success to mobile ec:85:2f:15:39:32 (EAP Id 12)
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.630: ec:85:2f:15:39:32
Found an cache entry for BSSID 84:78:ac:f0:68:d6 in PMKID
cache at index 0 of station ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.630: Including PMKID in
M1 (16)
!--- The hashed PMKID is included on the Message-1 of the
initial FT 4-Way handshake.
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.630:
[0000] 52 b8 8f cf 50 a7 90 98 2b ba d6 20 79 e4 cd f9
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.630: ec:85:2f:15:39:32
Sending EAPOL-Key Message to mobile ec:85:2f:15:39:32 state
INITPMK (message 1), replay counter 00.00.00.00.00.00.00.0
!--- Message-1 of the FT 4-Way handshake is sent from the
WLC/AP to the client.
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.639: ec:85:2f:15:39:32
Received EAPOL-Key from mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.639: ec:85:2f:15:39:32
Received EAPOL-key in PTK_START state (message 2) from
mobile ec:85:2f:15:39:32
!--- Message-2 of the FT 4-Way handshake is received
successfully from the client.
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.639: ec:85:2f:15:39:32
Calculating PMKR0Name
!--- The PMKR0Name is calculated.
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.639: ec:85:2f:15:39:32
DOT11R: Sending cache add
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.639: Adding MDIE,
ID is:0xaaf0
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.639: ec:85:2f:15:39:32
Adding TIE for reassociation deadtime:20000 milliseconds
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.639: ec:85:2f:15:39:32
Adding TIE for R0Key-Data valid time :1807
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.640: ec:85:2f:15:39:32
Sending EAPOL-Key Message to mobile ec:85:2f:15:39:32 state
PTKINITNEGOTIATING (message 3), replay counter
00.00.00.00.00.00.00.01
!--- After the MDIE, TIE for reassociation deadtime, and TIE
for R0Key-Data valid time are calculated, the Message-3
of this FT 4-Way handshake is sent from the WLC/AP to the
client with this information.
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.651: ec:85:2f:15:39:32
Received EAPOL-Key from mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.651: ec:85:2f:15:39:32
Received EAPOL-key in PTKINITNEGOTIATING state (message 4)
from mobile ec:85:2f:15:39:32
!--- Message-4 (final message) of this initial FT 4-Way handshake
is received successfully from the client, which confirms the
installation of the derived keys. They can now be used in order
to encrypt data frames with the current AP.
注:この方式をデバッグしてここに示す追加の802.11r/FT出力を表示するには、debug clientとともに追加のデバッグを有効にします。追加のデバッグはdebug ft events enableです。
802.1X/EAP方式ではなく、WPA2-PSKを使用してFTを実行する際のWLANへの初期関連付けのイメージとデバッグを次に示します。ここでは、Fast BSS Transition Information Element(強調表示)を表示するために、APからの関連付け応答フレームが選択されています。FT の 4 方向ハンドシェイクを実行するために必要となるキー 情報の一部も示されています。
*apfMsConnTask_0: Jun 27 19:29:09.136: ec:85:2f:15:39:32
Association received from mobile on BSSID
84:78:ac:f0:68:d4
*apfMsConnTask_0: Jun 27 19:29:09.137: ec:85:2f:15:39:32
Marking this mobile as TGr capable.
*apfMsConnTask_0: Jun 27 19:29:09.137: ec:85:2f:15:39:32
Processing RSN IE type 48, length 20 for mobile
ec:85:2f:15:39:32
*apfMsConnTask_0: Jun 27 19:29:09.137: Sending assoc-resp
station:ec:85:2f:15:39:32 AP:84:78:ac:f0:68:d0-00
thread:144be808
*apfMsConnTask_0: Jun 27 19:29:09.137: Adding MDIE,
ID is:0xaaf0
*apfMsConnTask_0: Jun 27 19:29:09.137: ec:85:2f:15:39:32
Including FT Mobility Domain IE (length 5) in Initial
assoc Resp to mobile
*apfMsConnTask_0: Jun 27 19:29:09.137: ec:85:2f:15:39:32
Sending R0KH-ID as:-84.30.6.-3
*apfMsConnTask_0: Jun 27 19:29:09.137: ec:85:2f:15:39:32
Sending R1KH-ID as 3c:ce:73:d8:02:00
*apfMsConnTask_0: Jun 27 19:29:09.137: ec:85:2f:15:39:32
Including FT IE (length 98) in Initial Assoc Resp to mobile
*apfMsConnTask_0: Jun 27 19:29:09.138: ec:85:2f:15:39:32
Sending Assoc Response to station on BSSID 84:78:ac:f0:68:d4
(status 0) ApVapId 5 Slot 0
*dot1xMsgTask: Jun 27 19:29:09.141: ec:85:2f:15:39:32
Creating a PKC PMKID Cache entry for station
ec:85:2f:15:39:32 (RSN 2)
*dot1xMsgTask: Jun 27 19:29:09.141: ec:85:2f:15:39:32
Resetting MSCB PMK Cache Entry 0 for station
ec:85:2f:15:39:32
*dot1xMsgTask: Jun 27 19:29:09.141: ec:85:2f:15:39:32
Setting active key cache index 8 ---> 8
*dot1xMsgTask: Jun 27 19:29:09.141: ec:85:2f:15:39:32
Setting active key cache index 8 ---> 0
*dot1xMsgTask: Jun 27 19:29:09.141: ec:85:2f:15:39:32
Adding BSSID 84:78:ac:f0:68:d4 to PMKID cache at
index 0 for station ec:85:2f:15:39:32
*dot1xMsgTask: Jun 27 19:29:09.142: New PMKID: (16)
*dot1xMsgTask: Jun 27 19:29:09.142:
[0000] 17 4b 17 5c ed 5f c7 1d 66 39 e9 5d 3a 63 69 e7
*dot1xMsgTask: Jun 27 19:29:09.142: ec:85:2f:15:39:32
Creating global PMK cache for this TGr client
*dot1xMsgTask: Jun 27 19:29:09.142: ec:85:2f:15:39:32
Created PMK Cache Entry for TGr AKM:PSK
ec:85:2f:15:39:32
*dot1xMsgTask: Jun 27 19:29:09.142: ec:85:2f:15:39:32
R0KH-ID:172.30.6.253 R1KH-ID:3c:ce:73:d8:02:00
MSK Len:48 pmkValidTime:1813
*dot1xMsgTask: Jun 27 19:29:09.142: ec:85:2f:15:39:32
Initiating RSN PSK to mobile ec:85:2f:15:39:32
*dot1xMsgTask: Jun 27 19:29:09.142: ec:85:2f:15:39:32
Found an cache entry for BSSID 84:78:ac:f0:68:d4 in
PMKID cache at index 0 of station ec:85:2f:15:39:32
*dot1xMsgTask: Jun 27 19:29:09.142: Including PMKID
in M1 (16)
*dot1xMsgTask: Jun 27 19:29:09.142:
[0000] 17 4b 17 5c ed 5f c7 1d 66 39 e9 5d 3a 63 69 e7
*dot1xMsgTask: Jun 27 19:29:09.143: ec:85:2f:15:39:32
Sending EAPOL-Key Message to mobile ec:85:2f:15:39:32
state INITPMK (message 1), replay counter
00.00.00.00.00.00.00.00
*apfMsConnTask_0: Jun 27 19:29:09.144: ec:85:2f:15:39:32
Got action frame from this client.
*Dot1x_NW_MsgTask_2: Jun 27 19:29:09.152: ec:85:2f:15:39:32
Received EAPOL-Key from mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 27 19:29:09.153: ec:85:2f:15:39:32
Received EAPOL-key in PTK_START state (message 2) from
mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 27 19:29:09.153: ec:85:2f:15:39:32
Calculating PMKR0Name
*Dot1x_NW_MsgTask_2: Jun 27 19:29:09.153: Adding MDIE,
ID is:0xaaf0
*Dot1x_NW_MsgTask_2: Jun 27 19:29:09.153: ec:85:2f:15:39:32
Adding TIE for reassociation deadtime:20000 milliseconds
*Dot1x_NW_MsgTask_2: Jun 27 19:29:09.153: ec:85:2f:15:39:32
Adding TIE for R0Key-Data valid time :1813
*Dot1x_NW_MsgTask_2: Jun 27 19:29:09.154: ec:85:2f:15:39:32
Sending EAPOL-Key Message to mobile ec:85:2f:15:39:32 state
PTKINITNEGOTIATING (message 3), replay counter
00.00.00.00.00.00.00.01
*Dot1x_NW_MsgTask_2: Jun 27 19:29:09.163: ec:85:2f:15:39:32
Received EAPOL-Key from mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 27 19:29:09.163: ec:85:2f:15:39:32
Received EAPOL-key in PTKINITNEGOTIATING state (message 4)
from mobile ec:85:2f:15:39:32
802.11r では、他の高速セキュア ローミング方式の場合と同様に、WLAN への初回関連付けが、この手法で使用されるベース キーの導出に使用される基盤になります。主な違いは、クライアントがローミングを開始する際に生じます。FTは802.1X/EAPを使用しないだけでなく、初期の802.11オープンシステム認証と再関連付けフレーム(AP間のローミング時に常に使用され、必要)を組み合わせて、FT情報を交換し、4ウェイハンドシェイクの代わりに新しい動的暗号キーを取得する、よりのより効率的ななローミング方法を実行します。
次の図は、802.1X/EAPセキュリティを使用したOver-the-AirでのFast BSS移行の実行時に交換されるフレームを示しています。FT のキー ネゴシエーションを開始するために必要な FT プロトコル情報要素を表示するため、クライアントから AP へのオープン システム認証フレームを選択しています。これは、新しい AP での新しい PTK を(PMK-R1 に基づいて)導出するために使用します。このクライアントが単なるオープン システム認証ではなく高速 BSS 移行を実行していることを示すため、認証アルゴリズムを示すフィールドを強調表示しています。
この FT ローミング イベントが 802.1X/EAP の使用時に発生したときの WLC からのデバッグ出力を次に示します。
*apfMsConnTask_2: Jun 27 19:25:48.751: ec:85:2f:15:39:32
Doing preauth for this client over the Air
!--- WLC begins FT fast-secure roaming over-the-Air with
this client and performs a type of preauthentication,
because the client asks for this with FT on the Authentication
frame that is sent to the new AP over-the-Air
(before the Reassociation Request).
*apfMsConnTask_2: Jun 27 19:25:48.751: ec:85:2f:15:39:32
Doing local roaming for destination address
84:78:ac:f0:2a:96
!--- WLC performs the local roaming event with the new AP to
which the client roams.
*apfMsConnTask_2: Jun 27 19:25:48.751: ec:85:2f:15:39:32
Got 1 AKMs in RSNIE
*apfMsConnTask_2: Jun 27 19:25:48.751: ec:85:2f:15:39:32
RSNIE AKM matches with PMK cache entry :0x3
!--- WLC receives one PMK from this client (known as AKM here),
which matches the PMK cache entry hold for this client.
*apfMsConnTask_2: Jun 27 19:25:48.751: ec:85:2f:15:39:32
Created a new preauth entry for AP:84:78:ac:f0:2a:96
*apfMsConnTask_2: Jun 27 19:25:48.751: Adding MDIE,
ID is:0xaaf0
!--- WLC creates a new preauth entry for this AP-and-Client pair,
and adds the MDIE information.
*apfMsConnTask_2: Jun 27 19:25:48.763: Processing assoc-req
station:ec:85:2f:15:39:32 AP:84:78:ac:f0:2a:90-00
thread:144bef38
*apfMsConnTask_2: Jun 27 19:25:48.763: ec:85:2f:15:39:32
Reassociation received from mobile on BSSID
84:78:ac:f0:2a:96
!--- Once the client receives the Authentication frame reply from the
WLC/AP, the Reassociation request is sent, which is received at
the new AP to which the client roams.
*apfMsConnTask_2: Jun 27 19:25:48.764: ec:85:2f:15:39:32
Marking this mobile as TGr capable.
*apfMsConnTask_2: Jun 27 19:25:48.764: ec:85:2f:15:39:32
Processing RSN IE type 48, length 38 for mobile
ec:85:2f:15:39:32
*apfMsConnTask_2: Jun 27 19:25:48.765: ec:85:2f:15:39:32
Roaming succeed for this client.
!--- WLC confirms that the FT fast-secure roaming is successful
for this client.
*apfMsConnTask_2: Jun 27 19:25:48.765: Sending assoc-resp
station:ec:85:2f:15:39:32 AP:84:78:ac:f0:2a:90-00
thread:144bef38
*apfMsConnTask_2: Jun 27 19:25:48.766: Adding MDIE,
ID is:0xaaf0
*apfMsConnTask_2: Jun 27 19:25:48.766: ec:85:2f:15:39:32
Including FT Mobility Domain IE (length 5) in
reassociation assoc Resp to mobile
*apfMsConnTask_2: Jun 27 19:25:48.766: ec:85:2f:15:39:32
Sending Assoc Response to station on BSSID 84:78:ac:f0:2a:96
(status 0) ApVapId 7 Slot 0
!--- The Reassociation response is sent to the client, which
includes the FT Mobility Domain IE.
*dot1xMsgTask: Jun 27 19:25:48.769: ec:85:2f:15:39:32
Finishing FT roaming for mobile ec:85:2f:15:39:32
!--- FT roaming finishes and EAP is skipped (as well as any
other key management handshake), so the client is ready
to pass encrypted data frames with the current AP.
*dot1xMsgTask: Jun 27 19:25:48.769: ec:85:2f:15:39:32
Skipping EAP-Success to mobile ec:85:2f:15:39:32
次の図は、WPA2-PSKセキュリティを使用したFast BSS移行(Over-the-Air)を示しています。このFT交換の詳細を表示するために、APからクライアントへの最終的な再関連付け応答フレームが選択されています。
この FT のローミング イベントが PSK の使用時に発生したときのデバッグ出力を次に示します。これは、802.1X/EAP を使用した場合のデバッグ出力と同様です。
*apfMsConnTask_2: Jun 27 19:29:29.854: ec:85:2f:15:39:32
Doing preauth for this client over the Air
*apfMsConnTask_2: Jun 27 19:29:29.854: ec:85:2f:15:39:32
Doing local roaming for destination address
84:78:ac:f0:2a:94
*apfMsConnTask_2: Jun 27 19:29:29.854: ec:85:2f:15:39:32
Got 1 AKMs in RSNIE
*apfMsConnTask_2: Jun 27 19:29:29.854: ec:85:2f:15:39:32
RSNIE AKM matches with PMK cache entry :0x4
*apfMsConnTask_2: Jun 27 19:29:29.854: ec:85:2f:15:39:32
Created a new preauth entry for AP:84:78:ac:f0:2a:94
*apfMsConnTask_2: Jun 27 19:29:29.854: Adding MDIE,
ID is:0xaaf0
*apfMsConnTask_2: Jun 27 19:29:29.867: Processing assoc-req
station:ec:85:2f:15:39:32 AP:84:78:ac:f0:2a:90-00
thread:144bef38
*apfMsConnTask_2: Jun 27 19:29:29.867: ec:85:2f:15:39:32
Reassociation received from mobile on BSSID
84:78:ac:f0:2a:94
*apfMsConnTask_2: Jun 27 19:29:29.868: ec:85:2f:15:39:32
Marking this mobile as TGr capable.
*apfMsConnTask_2: Jun 27 19:29:29.868: ec:85:2f:15:39:32
Processing RSN IE type 48, length 38 for mobile
ec:85:2f:15:39:32
*apfMsConnTask_2: Jun 27 19:29:29.869: ec:85:2f:15:39:32
Roaming succeed for this client.
*apfMsConnTask_2: Jun 27 19:29:29.869: Sending assoc-resp
station:ec:85:2f:15:39:32 AP:84:78:ac:f0:2a:90-00
thread:144bef38
*apfMsConnTask_2: Jun 27 19:29:29.869: Adding MDIE,
ID is:0xaaf0
*apfMsConnTask_2: Jun 27 19:29:29.869: ec:85:2f:15:39:32
Including FT Mobility Domain IE (length 5) in
reassociation assoc Resp to mobile
*apfMsConnTask_2: Jun 27 19:29:29.870: ec:85:2f:15:39:32
Sending Assoc Response to station on BSSID
84:78:ac:f0:2a:94 (status 0) ApVapId 5 Slot 0
*dot1xMsgTask: Jun 27 19:29:29.874: ec:85:2f:15:39:32
Finishing FT roaming for mobile ec:85:2f:15:39:32
図に示すように、WLANへの初期関連付けでFast BSS移行がネゴシエートされると、ローミングに使用および必要な4つのフレーム(クライアントからのオープンシステム認証、APからのオープンシステム認証、再関連付け要求、および再関連付け応答)が、新しいPTK(ユニキャスト暗号キー)およびGTK(マルチキャスト/ブロードキャスト暗号キー)を取得するためのFT 4ウェイハンドシェイクとして基本的に使用されます。
これは、通常はこれらのフレームの交換後に発生する 4 方向ハンドシェイクの代わりになります。これらのフレームでの FT の内容およびキー ネゴシエーションは、セキュリティ方式として 802.1X/EAP または PSK のいずれを使用する場合でも、基本的に同じです。図に示すように、AKMフィールドが主な違いであり、クライアントがPSKまたは802.1XでFTを実行するかどうかを確認します。したがって、キー ネゴシエーションのためのこのタイプのセキュリティ情報は、通常これら 4 つのフレームに含まれていないことに注意する必要があります。この情報は、802.11r が実行されている場合にクライアントが FT ローミングを行うときのみ含まれ、初回関連付けの後にクライアントと WLAN インフラストラクチャの間でネゴシエートされます。
802.11r では、高速 BSS 移行の別の実装も可能です。クライアントによる 新しい AP への FT ローミングが、Over-the-Air ではなく Over-the-DS(分散システム)で行われる実装です。この場合、キー ネゴシエーションの開始には、オープン システム認証フレームではなく FT アクション フレームが使用されます。
基本的に、クライアントは、より適切なAPにローミングできると判断すると、ローミング前に現在接続している元のAPにFTアクション要求フレームを送信します。クライアントは、FT ローミング先となるターゲット AP の BSSID(MAC アドレス)を示します。元の AP は、この FT アクション要求フレームを分散システム(通常は有線インフラストラクチャ)を介してターゲット AP に転送し、ターゲット AP は、FT アクション応答フレームでクライアントに応答します(これも DS を介するため、最終的には Over-the-Air でクライアントに送信することができます)。このFTアクションフレームの交換が成功すると、クライアントはFTローミングを完了します。クライアントは再関連付け要求をターゲットAPに送信し(今回は地上波)、ローミングと最終的なキーの導出を確認するために新しいAPから再関連付け応答を受信します。
つまり、高速 BSS 移行のネゴシエートおよび新しい暗号キーの導出を行うためには 4 つのフレームがありますが、ここでは、オープン システム認証フレームが FT アクション要求/応答フレームに置き換えられており、これらが、現在の AP とターゲット AP の間で分散システムを介して交換されます。この方式は、802.1X/EAPとPSKの両方のセキュリティ方式にも有効で、すべてCisco Wireless LAN Controllerでサポートされています。ただし、このOver-the-DS移行はWiFi業界のほとんどのワイヤレスクライアントでサポートおよび実装されていないため(フレーム交換とデバッグ出力は基本的に同じであるため)、このドキュメントでは例を示しません。その代わりに、Over-the-DS での 高速 BSS 移行を視覚化する次の図を示します。
この問題を解決するために、シスコワイヤレスLANインフラストラクチャではAdaptive 802.11r機能を導入しました。WLANレベルでFTモードがAdaptiveに設定されている場合、WLANは802.11i対応WLAN上で802.11rモビリティドメインIDをアドバタイズします。一部のApple iOS10クライアントデバイスは、80211i/WPA2 WLAN上のMDIEの存在を識別し、802.11rアソシエーションを確立するために独自のハンドシェイクを実行します。クライアントが正常な802.11rアソシエーションを完了すると、通常の802.11r対応WLANと同様にFTローミングを実行できます。FT適応型は、選択したApple iOS10(およびそれ以降)のデバイスにのみ適用されます。他のすべてのクライアントはWLANで802.11i/WPA2アソシエーションを継続でき、サポートされている適切なFSR方式を実行します。
iOS10デバイスが802.11rをWLAN/SSID上で実行する際に導入されたこの新機能に関する詳細なドキュメントについては、『CiscoワイヤレスLAN上のCisco IOSデバイスに関するエンタープライズベストプラクティス』を参照してください(802.11r以外の他のクライアントは正常に接続できます)。
改定 | 発行日 | コメント |
---|---|---|
2.0 |
09-Feb-2023 |
形式を更新し、技術情報を確認。再認定 |
1.0 |
02-Sep-2013 |
初版 |