CUWNでの802.11 WLANおよび高速セキュアローミングの特定の方式

はじめに

このドキュメントでは、ユニファイドワイヤレスネットワーク(CUWN)上のIEEE 802.11ワイヤレスLAN(WLAN)で使用可能なワイヤレスおよび高速セキュアローミングのタイプについて説明します。

前提条件

要件

次の項目に関する知識があることが推奨されます。

• IEEE 802.11 WLAN の基本
• IEEE 802.11 WLAN のセキュリティ
• IEEE 802.1X/EAP の基本

使用するコンポーネント

このドキュメントの情報は、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、アドレス解決プロトコル(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 つのセキュリティ方式について説明します。

• WPA/WPA2-PSK（事前共有キー）：事前共有キーによるクライアントの認証。
• WPA/WPA2-EAP（Extensible Authentication Protocol）：802.1X/EAP 方式によるクライアントの認証。認証サーバの使用により、証明書、ユーザ名とパスワード、トークンなどの追加の安全なクレデンシャルを確認する。

これらの 2 つの方式（PSK および EAP）は、クライアントを認証および確認する方法は異なりますが、キー管理プロセスには基本的に同じ WPA/WPA2 ルールが使用されていることを認識することが重要です。

セキュリティが WPA/WPA2-PSK であっても WPA/WPA2-EAP であっても、使用される特定の認証方式でクライアントが確認されると、WPA/WPA2 の 4 方向ハンドシェイクと呼ばれるプロセスにより、WLC/AP とクライアント間のキー ネゴシエーションが、マスター セッション キー（MSK）を元のキー マテリアルとして開始されます。

プロセスの概要を次に示します。

1. MSK は、セキュリティ方式として 802.1X/EAP が使用される場合は EAP 認証のフェーズから、WPA/WPA2-PSK が使用される場合は PSK から、それぞれ導出されます。
2. この MSK から、クライアントと WLC/AP は ペアワイズ マスター キー（PMK）を導出し、WLC/AP はグループ マスター キー（GMK）を生成します。
3. これらの2つのマスターキーの準備が整うと、クライアントとWLC/APは、実際の暗号キーのネゴシエーションのシードとしてマスターキーを使用して、WPA/WPA2の4方向のハンドシェイク（このドキュメントで後述するいくつかの画面イメージとデバッグを使用）を開始します。
4. これらの最終的な暗号キーは、ペアワイズ一時キー（PTK）およびグループ一時キー（GTK）と呼ばれています。 PTK は、PMK から導出され、クライアントでユニキャスト フレームを暗号化するために使用されます。グループ一時キー（GTK）は、GMK から導出され、当該の SSID/AP でマルチキャスト/ブロードキャストを暗号化するために使用されます。

WPA/WPA2-PSK

暗号化のために 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 が元のキーを認識しないことです。唯一の違いは、次の図に示すように、アソシエーションフレームではなく再関連付けフレームがあることです。

デバッグ出力に表示されるメッセージは同じですが、クライアントからの最初のパケットは、すでに説明したように、関連付けではなく再関連付けです。

WPA/WPA2-EAP

802.1X/EAP 方式を使用してクライアントの認証を安全な SSID で行う場合、クライアントがトラフィックを渡し始める前に、さらに多くのフレームが必要になります。

これらの追加フレームは、クライアントクレデンシャルを認証するために使用され、EAP方式によって、4 ～ 20フレームの間で使用できます。

これらは、関連付けまたは再関連付けの後、かつ、WPA/WPA2 の 4 方向ハンドシェイクの前に来ます。その理由は、キー管理プロセス（4 方向ハンドシェイク）において最終的な暗号キーを生成するためのシードとして使用される MSK は、認証フェーズから導出されるためです。

次の図に、PEAPv0/EAP-MSCHAPv2によるWPAが実行される際に、初期関連付けで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 into Connecting 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 でサポートされているさまざまな高速セキュア ローミングの方式およびスキームについて説明します。

CCKM を使用しての高速セキュア ローミング

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バージョンを確認して、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クライアントは1つの再関連付け要求フレーム（MICと連続して増加するランダム番号を含む）をAP/WLCに送信し、新しい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 によって以前にキャッシュされた情報によって完了します。

FlexConnect での CCKM の使用

• 中央認証がサポートされています。これには、ローカルおよび中央のデータスイッチングが含まれます。APは同じFlexConnectグループに属している必要があります。
• Flex Local Authenticationがサポートされています。接続モードでは、キャッシュをAPからコントローラに配布した後、FlexConnectグループ内の残りのAPに配布できます。
• スタンドアロンモードがサポートされます。キャッシュがすでにAP上にある場合（以前の配布による）、高速ローミングが機能します。スタンドアロンモードの新しい認証は、高速セキュアローミングをサポートしていません。

CCKM の長所

• CCKM は、エンタープライズ WLAN で最も多く導入されている、最速の高速セキュア ローミング方式です。 クライアントは、AP 間の移動の際に新しい鍵を導出するためにキー管理のハンドシェイクを行う必要がなく、当該の WLAN でのクライアントのライフタイム中は、新しい AP で 再度 802.1X/EAP 認証を実行する必要がありません。
• CCKM では、レガシー クライアントで引き続き使用されているシスコ独自のレガシー方式に加え、802.11 標準規格の範囲で使用できるすべての暗号化方式（WEP、TKIP、および AES）をサポートしています。

CCKM の短所

• CCKM はシスコ独自の方式であるため、導入およびサポートは、Cisco WLAN インフラストラクチャおよび CCX ワイヤレス クライアントに限られます。
• CCXバージョン5は広く採用されていないため、WPA2/AESを使用したCCKMは多くのCCXワイヤレスクライアントでサポートされていません（主な理由は、ほとんどのクライアントがすでにWPA/TKIPを使用したCCKMをサポートしているため、これはまだ非常に安全です）。

PMKID キャッシング/Sticky Key Caching を使用しての高速セキュア ローミング

Pairwise think Key ID(PMKID)キャッシング、つまり、Sticky Key Caching(SKC)は、WLAN用に高レベルのセキュリティを標準化することを主な目的とした802.11iセキュリティ修正案のIEEE 802.11標準によって推奨された、最初の高速セキュアローミングの方法です。この高速セキュア ローミング手法は、WPA2 デバイスに向けた任意の方法として、このセキュリティが実行されているときのローミングを改善するために追加されました。

これが可能なのは、クライアントと認証サーバは、クライアントが完全に EAP 認証されるたびに、PMK の導出に使用される MSK を導出するためです。

これは、（クライアントが別のAPにローミングするか、セッションが時間切れになるまで）セッションに使用される最終的なユニキャスト暗号キー(PTK)を導出するためにWPA2の4方向ハンドシェイクのシードとして使用されます。したがって、この方法は、クライアントとAPによってキャッシュされた元のPMKを再利用するため、ローミング時のEAP認証フェーズを防止します。新しい暗号キーを導出するためにクライアントで必要となるのは、WPA2 の 4 方向ハンドシェイクを実行することだけです。

この方式は、802.11 標準規格で推奨される高速セキュア ローミング方式として広く導入されているわけではありません。その主な理由は次のとおりです。

• この方式はオプションであり、すべてのWPA2デバイスでサポートされているわけではありません。802.11i修正の目的は高速セキュアローミングではなく、WLAN（802.11r。これについては、このドキュメントで後述します）の高速セキュアローミングを標準化するためにIEEEが別の修正に既に取り組んでいるためです。
• この方式には、実装に関して大きな制限があります。無線クライアントは、以前に認証および接続したAPにローミングする場合にのみ、高速セキュアローミングを実行できます。

この方式では、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；無線）フレームを調べるために使用されるWireless Packet Image Softwareでは、この特定のフレームがイメージされないためです。ただし、この例では、参考のために、このようなイメージが残されています。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

FlexConnect での PMKID キャッシング/Sticky Key Caching の使用

• FlexConnectセットアップでこの方式を使用すると、機能する可能性があり、中央認証（中央スイッチングまたはローカルスイッチングのいずれか）をWLCに戻して使用する場合、動作は前述の説明と似ているように見えます。ただし、このSKC方式はFlexConnectではサポートされていません。
• この方式は、ローカル モード AP を有する CUWN でのみ正式にサポートされており、FlexConnect やその他のモードではサポートされていません。

PMKID キャッシング/Sticky Key Caching の長所 

この方式は、キャッシュされたキーを管理する集中型デバイスを使用せず、自律型の独立した AP を使用してローカルに導入することができます。

PMKID キャッシング/Sticky Key Caching の短所

• このドキュメントで前に説明したように、この方式の主な制約は、クライアントが高速セキュア ローミングを実行できるのは、以前に関連付けおよび認証が実行された AP にローミングする場合のみであることです。新しい AP にローミングするときは、クライアントは、EAP 認証の全体を再度完了する必要があります。
• ワイヤレス クライアントと AP は、新しい認証のたびに導出されるすべての PMK を記憶する必要があるため、この機能は通常、キャッシュされる PMK の数に制限されます。この制限は標準規格によって明確に定義されていないため、ベンダーは、それぞれの SKC 導入でさまざまな制限を定義することができます。たとえば、Cisco WLAN コントローラでは現在、PMK のキャッシュができる AP の数は、1 クライアントにつき 8 つまでとなっています。クライアントが 1 セッションにおいてローミングした AP の数が 8 を超えると、新たにキャッシュされたエントリを保存するため、最も古い AP がキャッシュ リストから削除されます。
• この方式はオプションであり、多くのWPA2デバイスではまだサポートされていないため、広く採用および導入されているわけではありません。
• SKC は、AP が同じモビリティ グループに属する場合であっても、コントローラ間のローミングが実行されるときはサポートされません。コントローラの間ローミングとは、異なる WLC で管理されている AP の間を移動する場合に発生するものです。

Opportunistic Key Caching を使用しての高速セキュア ローミング

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に似ています。したがって、これは自律型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情報要素に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 を計算するために値を処理する機能の名前のようなものです。

FlexConnect での Opportunistic Key Caching の使用

• 中央認証がサポートされています。これには、ローカルおよび中央のデータスイッチングが含まれます。APが同じFlexConnectグループの一部である場合、高速セキュアローミングはAPによって実行され、それ以外の場合、高速セキュアローミングはコントローラによって実行されます。
  

  注：この設定は、APが同じFlexConnectグループ上にない場合でも機能しますが、これは推奨またはサポートされている設定ではありません。

• Flex Local Authenticationがサポートされています。接続モードでは、キャッシュをAPからコントローラに配布した後、FlexConnectグループ内の残りのAPに配布できます。 
• スタンドアロンモードがサポートされます。 キャッシュがすでにAP上にある場合（以前の配布による）、高速セキュアローミングが動作します。スタンドアロンモードの新しい認証は、高速セキュアローミングをサポートしていません。

Opportunistic Key Caching の長所

• ワイヤレス クライアントと WLAN インフラストラクチャは、複数の PMKID を記憶する必要がなく、WLAN への初期認証から 1 つの 元の PMK をキャッシュするだけで済みます。その後、高速セキュア ローミングの検証を行うため、各 AP のセキュアな関連付けに必要な、適切な PMKID（再関連付け要求に使用される）を再ハッシュする必要があります。
• ここで、ワイヤレス クライアントは、新しい AP への高速セキュア ローミングを、（SKC とは違って）その AP に関連付けされたことがない場合でも、同じ WLAN/SSID で実行します。 クライアントのローミング先となるすべての AP の PMK キャッシュが処理される集中型の導入によって管理されている AP のいずれか 1 つに対して初回の 802.1X/EAP 認証を行っていれば、クライアントは、この WLAN でのライフタイムが終わるまで、全体的な認証を再度行う必要はありません。

Opportunistic Key Caching の短所

• この方式は、集中型の環境、つまり、クライアント セッションから 1 つの元の PMK をキャッシュして共有する役割を担う何らかの管理制御（WLAN コントローラなど）の下にすべての AP が置かれる環境にのみ導入されます。したがって、この方式は、自律型 AP の環境に限定されます。
• この方式に適用される手法は、802.11 規格では提案も記述もされていません。したがって、サポートはデバイスごとに大きく異なります。にもかかわらず、この方式は、802.11r の登場までに比較的多く採用されています。

「Proactive Key Caching」という用語について

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 インフラストラクチャにより、他の方式においてさまざまな方法で対応されています。

事前認証の短所

• PMK は AP ごとに 1 つずつであるため、クライアントが保持できる事前認証可能な AP の数が制限されます。
• クライアントが新しい AP との事前認証を行うたびに EAP 認証全体の交換が行われるため、ネットワークと認証サーバへの負荷が大きくなります。
• この方式はあまり採用されていないため（OKC のほうが多く採用されています）、ほとんどのワイヤレス クライアントはこの方式をサポートしていません。

802.11r を使用しての高速セキュア ローミング

802.11r 修正版に基づく高速セキュア ローミング手法（802.11 標準規格での正式名称は高速 BSS 移行、別名 FT）は、IEEE が AP（Basic Service Set（BSS））間の高速移行を実行するためのソリューションとして 802.11 規格で初めて（2008 年）正式に承認した方式であり、WLAN でキーを処理およびキャッシュする際に使用されるキー階層を明確に定義しています。ただし、その採用はあまり進んでいません。主な理由は、高速移行が実際に必要なときに使用可能なソリューションは、すでにほかにもあることです（このドキュメントですでに説明した方式のいずれかの VoWLAN 導入での使用など）。現在（2013 年まで）、何らかの FT オプションをサポートしているデバイスはごく少数です。

この手法は、新しい概念や、さまざまなデバイス（役割が異なる各デバイス）でキャッシュされる PMK の複数のレイヤが導入されていることから、他の方式より説明が複雑になります。また、高速セキュア ローミングのさらなるオプションを提供します。したがって、この方式については、方式の説明と使用可能な各オプションを伴う導入方法を概略的にまとめます。

802.11r は、SKC および OKC とは次の点が異なります。

• ハンドシェイク メッセージング（PMKID、ANonce、および SNonce の交換など）は、再関連付けフレームではなく、802.11 認証フレームまたはアクション フレームで行われます。PMKID キャッシング方式とは異なり、（再）関連付けメッセージの交換後に実行される別途の 4 方向ハンドシェイク フェーズは回避されます。新しい AP によるキー ハンドシェイクは、クライアントによる新しい AP へのローミングまたは関連付けが完全に行われる前に開始されます。
• 高速ローミングハンドシェイクには、Over the Air(OVER-AIR)とDistribution System（DS；分散システム）の2つの方式が用意されています。
• 802.11r は、キー階層のレイヤが他の方式より多くなっています。
• このプロトコルは、クライアントがローミングする際にキー管理のための 4 方向ハンドシェイクを回避する（このハンドシェイクを必要とせずに新しい暗号キー（PTK および GTK）を生成する）ため、認証に 802.1X/EAP を使用する場合だけでなく、PSK を使用する WPA2 セットアップにも適用することができます。これにより、これらの EAP または 4 方向ハンドシェイクの交換が行われないセットアップでは、ローミングがさらに高速化されます。

この方式では、ワイヤレス クライアントは、WLAN インフラストラクチャに対する初期認証を、最初の AP への接続が確立されたときに 1 回だけ行って、同じ FT モビリティ ドメインの AP 間でローミングを行う際に高速セキュア ローミングを実行します。

FT モビリティ ドメインとは、新しい概念の 1 つで、基本的には、同じ SSID を使用する複数の AP（Extended Service Set または ESS と呼ばれます）で、同じ FT キーを使用するものを指します。

これは、これまでに説明した他の方式と似ています。APがFTモビリティドメインキーを処理する方法は、通常、WLCやモビリティグループなどの集中型セットアップに基づいています。ただし、この方法は自律型AP環境にも実装できます。

キー階層の概要を次に示します。

• MSK は、ここでも、クライアント サプリカントと認証サーバについて、初回の 802.1X/EAP 認証フェーズから導出されます（認証が成功すると、認証サーバからオーセンティケータ（WLC）に転送されます）。 この MSK は、他の方式の場合と同様、FT キー階層のシードとして使用されます。EAP 認証方式ではなく WPA2-PSK を使用する場合、基本的に PSK はこの MSK です。
• ペアワイズ マスター キー R0（PMK-R0）は、FT キー階層の最初のレベルのキーである MSK から導出されます。この PMK-R0 のキー ホルダーは、WLC とクライアントです。
• 2 番目のレベルのキーは、ペアワイズ マスター キー R1（PMK-R1）と呼ばれ、PMK-R0 から導出されます。このキー のホルダーは、クライアントと、PMK-R0 を持つ WLC によって管理される AP です。
• FT キー階層の 3 番目かつ最終レベルのキーは、PTK です。これは、802.11 ユニキャストのデータ フレームを暗号化するために使用される最終的なキーです（WPA/TKIP または WPA2/AES を使用する他の方式と同様です）。 この PTK は、FT では、PMK-R1 から導出されます。キー ホルダーは、クライアントと、WLC によって管理される AP です。

注:WLANベンダーと実装設定（Autonomous AP、FlexConnect、メッシュなど）によっては、WLANインフラストラクチャは異なる方法でキーを転送および処理できます。キーホルダーの役割を変更することさえできますが、このドキュメントの適用範囲外であるため、前述のキー階層の要約に基づく例に次の焦点を当てます。違いは、ソフトウェアの問題を検出するためにインフラストラクチャ デバイス（およびコード）を詳しく分析することが実際に必要でない限り、実際には、プロセスの理解にはそれほど関連しません。

Over-the-Air での高速 BSS 移行

この方式では、APへの最初の関連付けは、WLANへの通常の初回認証です。そこでは、次の画面イメージに示すように、データフレームが送信される前に、認証サーバに対する802.1X/EAP認証全体と、キー生成のための4方向ハンドシェイクが行われる必要があります。

主な違いは次のとおりです。

• 認証キー管理ネゴシエーションが通常の WPA/WPA2 とは若干異なるため、FT をサポートする WLAN インフラストラクチャへの関連付けが行われるときに、このネゴシエーションを行うための追加情報が使用されます。図に示すように、このクライアントが802.1X/EAP経由でFTを実行することを望んでいることを示すために、クライアントからの関連付け要求フレームが選択され、RNS情報要素のAKMフィールドが強調表示されます。
• また、次のモビリティドメインの情報要素（FTの一部）も示されています。ここで、FTの機能およびポリシーフィールドは、高速ローミングの際に高速BSS移行がOver-the-AirまたはOver-the-DSのいずれで完了したかを示しています（この図ではOver-the-Airを示しています）。
• FT ローミング時に FT 認証シーケンスを実行するのに必要な情報を持つ別の情報要素（このドキュメントで後述する 高速 BSS 移行または FT IE）も追加されています。
• キー階層のため、キー生成が異なります。そのため、FT の 4 方向ハンドシェイクは WPA/WPA2 の 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, and follows 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での高速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セキュリティを使用したOver-the-Airでの高速BSS移行を示す図を次に示します。ここでは、この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 インフラストラクチャの間でネゴシエートされます。

Over-the-DS での高速 BSS 移行

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 移行を視覚化する次の図を示します。

FlexConnect での 802.11r の使用

• 中央認証がサポートされています。これには、ローカルおよび中央のデータスイッチングが含まれます。APは同じFlexConnectグループに属している必要があります。
• ローカル認証はサポートされていません。
• スタンドアロンモードはサポートされていません。

802.11r の長所

• この方式は、IEEE が 802.11 標準規格修正版（802.11r）で明確に定義するキー階層を使用する最初の方式です。そのため、これらの FT 手法の実装は、ベンダー間の互換性が高く、解釈の齟齬もありません。
• 802.11r により、必要に応じて有用な複数の手法が可能になります（Over-the-Air と Over-the-DS、802.1x/EAP セキュリティと PSK セキュリティ）。
• ワイヤレス クライアントは、新しい AP への高速セキュア ローミングを、その AP との関連付けを行ったことがなくても、同じ WLAN/SSID で、複数の PMKID を保存する必要なく実行します。
• この方式は、PSK セキュリティが使用される場合であっても高速なローミングが可能な最初の高速セキュア ローミング方式であり、WPA/WPA2 PSK の使用時に AP 間でローミングするときに必要な 4 方向ハンドシェイクが不要です。高速セキュアローミング方式の主な目的は、このセキュリティ方式が実装される際に802.1X/EAPハンドシェイクを回避することですが、PSKセキュリティの場合、4ウェイハンドシェイクが回避されると、802.11rによってさらにローミングイベントが高速化されます。

802.11r の短所

• 高速 BSS 移行を実際にサポートするワイヤレス クライアント デバイスは少数であり、ほとんどの場合、これらのデバイスは、802.11r で使用可能な手法をすべてサポートしているわけではありません。
• これらの実装は非常に新しいため、発生する可能性のある注意事項に対処するには、実際の実稼働環境でのテスト結果やデバッグ結果が不十分です。
• WLAN/SSID をいずれかの FT 方式を使用するために設定する場合、その WLAN/SSID に接続できるのは、802.11r をサポートするワイヤレス クライアントのみです。FT の設定はクライアントが選択するものではないため、802.11r をサポートしないワイヤレス クライアントは、FT がまったく設定されていない別の WLAN/SSID と接続する必要があります。

適応型802.11r

• 一部のレガシークライアントは、「混合モード」でも802.11rが有効になっているWLAN/SSIDと関連付けることができません（802.11rをサポートし、サポートしていない同じSSIDクライアントで関連付けできることを希望します）。 これは、Robust Security Network Information Element(RSN IE)の解析を担当するクライアントサプリカントのドライバが古く、IEの追加のAKMスイートを認識していない場合に発生します。この制限により、クライアントは802.11rサポートをアドバタイズするWLANにアソシエーション要求を送信できません。そのため、802.11rクライアント用に1つのWLAN/SSIDを設定し、802.11rをサポートしないクライアント用に別のWLAN/SSIDを設定する必要があります。

• この問題を解決するために、シスコワイヤレス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方式を実行できます。

• 802.11rが実際には有効になっていない（したがって他の802.11r以外のクライアントが正常に接続できる）WLAN/SSIDで802.11rを実行するためにiOS10デバイスに導入されたこの新機能に関する詳細なドキュメントは、『Cisco Wireless LANのCisco IOSデバイスに関するエンタープライズベストプラクティス』にあります。

まとめ

• 特定の AP にローミングすることを決定するのは常にクライアントであり、WLC/AP がクライアントに代わって決定することはできないことに注意してください。ローミングイベントは、ローミングが必要であると判断された時点で、ワイヤレスクライアントによって開始されます。
• WLC は、同じ WLAN/SSID で、ほとんどまたはすべての FSR（高速セキュア ローミング）方式の組み合わせを一括してサポートしています。ただし、これは通常機能しないことに注意してください。サポートの可否や、サポート対象であると WLC がアドバタイズしようとしているものを理解することは、クライアントの動作（モバイル デバイス間で大きく異なる）に多大に依存するためです。1 つだけの SSID で相互運用性を達成することは、通常、それで解決される以上の問題があるため、推奨されません。これが本当に必要な場合は、このWLANで使用されるすべての可能なクライアントを使用した詳細なテストを完了する必要があります。
• 高速セキュア ローミング方式を開発する目的は、WLAN/SSID にセキュリティを有効にした状態で AP 間を移動する際に WLAN ローミング プロセスを高速化することであることを理解することが非常に重要です。セキュリティが実行されていない場合、クライアントと AP がデータ フレームの送信前に行うことは、AP 間のローミング時に常に必要であるワイヤレス管理フレーム（クライアントからのオープン システム認証、AP からのオープン システム認証、再関連付け要求、および再関連付け応答）の交換だけなので、高速化の対象がありません。 したがって、これ以上高速化することはできません。セキュリティがない状態でローミングの問題が発生した場合、高速ローミング方式でローミングを改善することはできません。ワイヤレス クライアント ステーションが AP カバレッジ セルの間で適宜ローミングできるように WLAN/SSID が適切にセットアップおよび設計されているか確認することしか方法はありません。
• 802.11r/FTは、802.11rのセクションで説明されているように、このセキュリティでローミングイベントを高速化し、4方向ハンドシェイクを回避するために、WPA2-PSKで実装されます。
• すべての方式にはそれぞれ長所と短所がありますが、最終的には、導入する方式がワイヤレス クライアント ステーションでサポートされているかどうか、使用可能なすべての方式が Cisco WLAN インフラストラクチャでサポートされているかどうかを必ず確認する必要があります。そのため、特定の WLAN/SSID に接続するワイヤレス クライアントによって実際にサポートされている最適な方式を選択する必要があります。たとえば、一部の導入では、Cisco Wireless IP Phone（CCKMではWPA2/AESをサポートするが、802.11rではサポートしない）に対してCCKMを使用してWLAN/SSIDを作成し、この高速セキュアローミング方式をサポートするワイヤレスクライアント（サポートされている場合はOKCを使用）に対して802.11r/FTを使用してしてする別のWLAN/SSIDを作成できます。
• ワイヤレスクライアントが使用可能な高速セキュアローミング方式のいずれもサポートしていない場合、802.1X/EAPセキュリティを使用したWLAN/SSID(SSID)上のAP間でのローミング時に、これらのクライアントが常にこのドキュメントで説明されている遅延を実験できるという事実を受け入れる必要があります（これにより、クライアントのアプリケーションやサービスが中断される可能性があります）。
• SKC（WPA2 PMKID キャッシング）を除くすべての方式は、AP が同じモビリティ グループにある限り、さまざまな WLC によって管理される AP 間の高速セキュア ローミング（コントローラ間ローミング）でサポートされています。
• CUWNでは、802.1X/EAP認証をWPA/WPA2に使用する場合、この記事で説明されているさまざまな高速セキュアローミング(FSR)方式をすべて完全にサポートしています。CUWNでは、高速ローミング方式がほとんど必要ないPSK(WPA2-Personal)が使用される場合に、WPA2-RSNで動作する方式(CCKM、PMKID Caching/SKC、OKC/PKC)では高速セキュアローミングをサポートしていません。ただし、CUWNでは、PSKを使用するWPA2-FT(802.11r)の場合に高速セキュアローミング(FSR)をサポートしています。これについても、この記事で説明しています。

関連情報

• 802.11r BSS Fast Transition導入ガイド
• シスコのテクニカルサポートとダウンロード