无线/移动 : "无线, LAN (WLAN)"

漫游和法塞特安全漫游在CUWN的802.11 WLAN

2015 年 8 月 28 日 - 机器翻译
其他版本: PDFpdf | 英语 (2015 年 4 月 23 日) | 反馈

简介

描述不同种类的无线漫游和法塞特安全漫游方法可用为IEEE 802.11 (WLAN)支持本文Cisco Unified无线网络无线LAN (CUWN)。

本文不提供所有关于每个方法如何工作或他们如何的特定配置。本文主要目的将描述多种技术联机之间的差异、他们的优点和限制和帧交换在每个方法。提供WLAN控制器(WLC)调试示例,并且无线数据包捕获用于为了分析和解释为描述的每个漫游方法发生的事件。

贡献用Jeal希门尼斯, Cisco TAC工程师。 

先决条件

要求

Cisco 建议您了解以下主题:

  • IEEE 802.11 WLAN基本
  • IEEE 802.11 WLAN安全
  • IEEE 802.1X/EAP基础

使用的组件

本文档中的信息根据Cisco WLAN控制器软件版本7.4,但是描述的大多debug输出和行为也许适用于支持讨论的方法的所有软件版本。

本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始(默认)配置。如果您使用的是真实网络,请确保您已经了解所有命令的潜在影响。

背景信息

在不同的法塞特安全漫游方法的说明可用为WLAN给前,知道WLAN关联过程工作,并且如何是重要的一正常漫游事件如何发生,当没有在服务集标识(SSID)配置的安全。

当802.11无线客户端连接对接入点(AP),在开始通过流量(无线数据帧)前,必须首先通过基本802.11开放式系统认证过程。然后,必须完成关联过程。设想开放式系统认证过程作为“连接电缆”在客户端选择的AP。这是非常重要了解,因为它总是选择的无线客户端哪个AP更喜欢,并且根据在变化在供应商之间的多个要素的决策。这就是为什么客户端通过发送验证帧开始此进程对选定AP,如显示的以后在这中文档。AP不能请求您建立连接。

一旦开放式系统认证过程顺利地完成与从AP (“连接的电缆的一答复”),关联过程根本完成建立客户端和AP之间的链路的802.11 Layer2 (L2)协商。AP分配关联ID到客户端,如果连接是成功的,若被设定并且准备它为了通过流量或执行一个高级安全方法在SSID。开放式系统认证过程包括两管理帧以及关联过程。验证与关联帧是无线管理帧,不是数据帧,基本上是用于连接进程的那个与AP。

这是无线帧的捕获通过空气为此进程:

注意: 如果要得知关于802.11无线探测和在Wireshark/颜色的过滤器用于在本文出现的捕获,请访问呼叫802.11嗅探器捕获分析的Cisco支持社区发表物。

无线客户端开始与验证帧和AP回复用另一验证帧。客户端然后发送关联申请帧,并且AP在一回复完成用关联响应桢。如显示从DHCP信息包,一旦802.11开放式系统验证与关联进程通过,客户端开始通过数据帧。在这种情况下,没有在SSID配置的安全方法,因此客户端立即开始发送没有加密的数据帧(在这种情况下DHCP)。

如显示的以后在本文,如果安全在SSID启用,有高级验证和加密握手帧特定安全方法的,在关联答复之后和在发送任何客户端的流量数据帧前,例如DHCP、地址解析服务(ARP)和应用程序数据包,加密。数据帧可能只发送,直到客户端充分地验证,并且加密密钥根据配置的安全方法协商。

根据上一个捕获,这您在client命令WLC的调试输出中看到的消息,当无线客户端开始一个新的关联对WLAN时:

*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调试显示在本文是client命令的调试,并且示例只表示一些相关消息,不是整个输出。欲了解更详细的信息关于此debug命令,请参考呼叫了解无线局域网控制器的(WLCs)调试客户端的本文。

这些消息显示关联申请和响应桢;因为此握手迅速发生在CUWN的AP级最初的验证帧没有被记录在WLC。

当客户端漫游,什么信息出现?客户端总是交换四管理帧在一连接的建立对AP,归结于关联的客户端建立,或者漫游事件的。客户端每次只只有一已建立连接对一个AP。在帧交换的唯一的差异在对WLAN基础设施的一个新连接和漫游事件之间是漫游事件的关联帧呼叫Reassociation帧,表明客户端从另一个AP实际上漫游没有尝试设立一个新的关联到WLAN。这些帧能包含使用为了协商漫游事件的不同的元素;这取决于设置,但是那些详细信息是超出本文的范围。

这是帧交换的示例:

这些消息在debug输出中出现:

*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配置以L2高级安全在基本802.11开放式系统验证顶部时,然后更多帧为最初的关联要求和,当漫游时。为802.11 WLAN标准化和实现的两个最普通的安全方法在本文描述:

  • WPA/WPA2-PSK (预先共享密钥) -客户端的验证有预共享密匙的。
  • WPA/WPA2-EAP (可扩展的认证协议) -客户端的验证以802.1X/EAP方法为了通过使用一个认证服务器验证更多安全凭证,例如证书、用户名和密码和令牌。

知道是重要的,即使这两个方法(PSK和EAP)验证/验证客户端用不同的方式,两个基本上使用同样WPA/WPA2规则密钥管理进程。安全是否是WPA/WPA2-PSK或WPA/WPA2-EAP,叫作WPA/WPA2 4方式握手的进程开始在WLC/AP和客户端之间的关键协商有一会话密钥的(MSK)作为原始密钥材料,一旦客户端验证与使用的特定认证方法。

这是进程的摘要:

  1. MSK派生从EAP验证相位,当802.1X/EAP使用时安全,或者从PSK,当WPA/WPA2-PSK使用作为安全方法时。
  2. 从此MSK,客户端和WLC/AP成对地派生主密钥(PMK),并且WLC/AP生成组主密钥(GMK)。
  3. 一旦这两主密钥准备好,客户端和WLC/AP启动是说明的以后在与一些屏幕截图的本文并且调试)的WPA/WPA2 4方式握手(与主密钥作为实际加密密钥的协商的种子。
  4. 那些最终加密密钥成对地叫作临时密钥(PTK)和组临时密钥(GTK)。PTK从PMK派生并且用于为了加密有客户端的单播帧。组临时密钥(GTK)从GMK在此特定SSID/AP派生和用于为了加密组播/广播。

WPA/WPA2-PSK

当WPA-PSK或WPA2-PSK通过临时密钥完整性协议(TKIP)或高级加密标准(AES)执行加密的时,客户端必须通过叫作WPA 4方式握手的进程两个的最初的关联并且,当漫游时。如以前解释,这基本上是密钥管理进程用于为了WPA/WPA2能派生加密密钥。然而,当PSK执行时,也用于为了验证客户端有加入一有效的预先共享密钥WLAN。当WPA或WPA2与PSK执行时,此捕获显示最初的关联过程:

如显示,在802.11开放式系统验证与关联进程,那里是从WPA 4方式握手后的四EAPOL帧,由与message-1的AP启动,并且由有message-4的客户端完成。在成功的握手以后,客户端开始通过数据帧(例如DHCP),这就是为什么在这种情况下加密与从4方式握手派生的密钥(您看不到实际内容和流量类型从无线捕获)。

注意:EAPOL帧用于为了传输所有密钥管理帧和802.1X/EAP验证帧通过空气在AP和客户端之间;他们传送作为无线数据帧。

这些消息在debug输出中出现:

*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.

当漫游时,客户端基本上跟随同一帧交换, WPA 4方式握手要求为了派生有新的AP的新建的加密密钥。这归结于标准设立的安全原因和事实新的AP不认识原始密钥。唯一的差异是有再聚集帧而不是关联帧,如此捕获所显示, :

您在debug输出中看到同样消息,但是从客户端的第一数据包是再聚集而不是关联,如显示和以前解释。

WPA/WPA2-EAP

当802.1X/EAP方法用于为了验证一安全SSID的时客户端,有要求的帧,在客户端开始通过流量前。这些额外的帧用于为了验证客户机证书的,并且从属在EAP方法,也许在四和二十帧之间。这些来在关联/再聚集以后,但是在WPA/WPA2 4方式握手前,因为认证阶段派生作为种子使用的MSK最终加密密钥生成在密钥管理进程(4方式握手)。

当与PEAPv0/EAP-MSCHAPv2的WPA执行时,此无线捕获显示在AP和无线客户端之间的空气交换的帧的示例在最初的关联:

有时此交换显示更多或较少帧,取决于多个要素,例如EAP方法,重新传输由于问题,客户端行为(例如在本例中的两标识请求,因为客户端发送EAPOL开始,在AP发送第一标识请求)后,或者,如果客户端已经交换证书用服务器。每当SSID为802.1X/EAP方法配置,有更多帧(验证),并且,需要更多时间,在客户端开始发送数据帧前。

这是调试消息的摘要:

*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和拉普之间和与认证服务器和其他原因。

这是调试消息的摘要此漫游事件的(基本上和上一个部分一样,因此这些消息进一步没有描述) :

*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安全结构工作的方法。当安全在WLAN/SSID时,使用为了防止应用程序/服务影响在延迟一正常漫游事件,多个法塞特安全漫游方法由WiFi行业开发并且实现为了加速漫游进程。客户端面对若干延迟,当他们继续通过流量时,当漫游在AP之间通过高层次安全的部署在WLAN时的。这归结于安全设置要求的EAP验证和密钥管理帧交换,如以前解释。

请注意法塞特安全漫游是此术语用于由行业关于加速漫游进程方法/方案的实施,当安全在WLAN时配置。 为WLAN是可用的,和CUWN在下一部分支持的不同的法塞特安全漫游方法/机制,解释。

法塞特安全漫游与CCKM

Cisco Centralized Key Management (CCKM)是在企业WLAN开发和实现的第一个法塞特安全漫游方法,创建由思科,解决方案使用为了缓和至今解释的延迟,当802.1X/EAP安全在WLAN时使用。因为这是思科专有协议, (的Cisco WLAN基础设备和无线客户端只支持从多个供应商)是Cisco兼容扩展(CCX) -兼容为CCKM。

CCKM可以实现与所有不同的加密方法可用为WLAN,包括:WEP、TKIP和AES。它也支持与用于WLAN的大多802.1X/EAP认证方法,从属在设备支持的CCX版本。

注意:对于在CCX规格的不同的版本支持的功能内容的一概述(支持的包括EAP方法),请参考CCX版本和功能文档,并且验证您的无线客户端支持的确切的CCX版本(如果他们是CCX兼容),因此您能确认安全方法您希望使用与CCKM是否可以实现。

此无线捕获提供帧的示例交换在最初的关联,当您执行CCKM与TKIP作为加密时和PEAPv0/EAP-MSCHAPv2作为802.1X/EAP方法。这基本上是同一交换,好象与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的法塞特安全漫游的种子信息,通过4方式握手类似于那WPA/WPA2,为了派生单播(PTK)和组播/与第一个AP的广播的(GTK)加密密钥。

当漫游时,大差值被注意。在这种情况下, CCKM客户端发送单个再聚集请求帧对AP/WLC (包括MIC和一个顺序地增加的随机数),并且提供足够的信息(包括新的AP MAC地址- BSSID-)为了派生新的PTK。使用此再聚集请求, 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.

如显示的,法塞特安全漫游执行,当避免EAP验证帧和更加4方式握手,因为新的加密密钥仍然派生时,但是根据CCKM协商方案。这完成与客户端和WLC和信息早先缓存的漫游再聚集帧。

与CCKM的FlexConnect

  • 当您使用在FlexConnect设置时的CCKM,行为正确地是相同的象以前解释(在法塞特安全漫游期间),只要对的AP客户端漫游属于同一FlexConnect组的地方。
  • CCKM运转与中央印制厂或本地认证的此方式FlexConnect设置的,只要AP在已连接模式(与中央或本地交换)。

与CCKM的专业人员

  • CCKM是在企业WLAN主要部署的最快速的法塞特安全漫游方法。 客户端不需要在密钥管理握手去为了派生新建的密钥,当在AP之间的一个移动发生时在此WLAN的客户端一生期间和从未再要求执行一全双工802.1X/EAP验证与新的AP。
  • CCKM支持所有加密方法可用在802.11标准(WEP、TKIP和AES)内,除在传统客户端仍然使用的一些传统思科专有方法之外。

与CCKM的缺点

  • CCKM是思科专有方法,对Cisco WLAN基础设施和CCX无线客户端限制实施和支持。
  • CCX版本5不广泛采用,因此许多CCX无线客户端不支持与WPA2/AES的CCKM (主要,因为大多数已经支持与WPA/TKIP的CCKM,仍然非常安全)。

法塞特安全漫游与WPA2 PMKID高速缓冲存储

成对地WPA2主密钥ID (PMKID)高速缓冲存储或者粘贴关键高速缓冲存储(SKC),是在802.11i安全附录内的IEEE 802.11standard建议的第一个法塞特安全漫游方法,主要目的将标准化WLAN的一个高级安全设施。当此安全实现,法塞特安全漫游技术被添加,当一个可选方法的WPA2设备为了改进漫游。

这是可能的,因为,在客户端充分地EAP验证时候,客户端和认证服务器派生MSK,用于为了派生PMK。这用于,种子WPA2 4方式握手为了派生使用会话的最终单播加密密钥(PTK) (直到客户端漫游对另一个AP或会话超时);因此,此方法防止EAP验证相位,当漫游时,因为再利用客户端和AP缓存的原始PMK。客户端必须只通过WPA2 4方式握手为了派生新建的加密密钥。

此方法不广泛部署作为推荐的802.11标准的法塞特安全漫游方法主要由于这些原因:

  • 可选和所有WPA2设备不支持此方法,因为802.11i附录的目的不关系到法塞特安全漫游,并且IEEE在另一附录已经工作标准化法塞特安全漫游WLAN的(802.11r,是被覆盖的以后在本文)。
  • 此方法有在其实施的一个大限制:无线客户端可只进行法塞特安全漫游,当漫游回到他们以前验证/连接的AP时。

使用此方法,所有AP的最初的关联是正如一正常首次验证对WLAN,认证服务器和4方式握手的整个802.1X/EAP验证密钥生成的必须发生,在客户端能发送数据帧前,如此屏幕截图所显示, :

调试显示EAP验证帧交换和方法的其余一样在最初的验证对WLAN,当一些输出被添加关于使用的关键高速缓冲存储技术这里。因为同一信息为客户端的验证认证服务器的每次基本上交换这些debug输出没有被削减为了显示主要最新信息,没有整个EAP帧交换。这至今被展示,并且关联用在数据包捕获显示的EAP验证帧,大多EAP消息从为了简化的debug输出如此删除:

*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和无线客户端缓存安全关联的PMKs已经设立。所以,如果无线客户端漫游对它从未关联的新的AP,客户端必须再次表演全双工EAP验证,如客户端漫游对新的AP的此无线捕获所显示:

然而,如果无线客户端漫游回到一个上一个关联/验证发生的AP,然后客户端发送列出多个PMKIDs,通知从所有缓存的AP PMKs AP客户端以前验证的再聚集请求帧。所以,因为也有为此客户端缓存的一PMK的客户端漫游回到AP,然后客户端不需要通过EAP重新鉴别为了派生一新的PMK。客户端通过WPA2 4方式握手为了派生新的瞬变加密密钥:

注意:此捕获不显示从客户端的第一802.11开放式系统验证帧,但是这不归结于实现的方法,因为此帧总是要求。原因是此特定帧没有由用于的适配器或无线数据包捕获软件捕获为了探测此示例的通过空气帧,但是象这样被留下在教育目的示例。注意有可能性这也许发生,当您执行通过空气数据包捕获时;一些帧也许由捕获未命中,但是实际上交换在客户端和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

与WPA2 PMKID高速缓冲存储/粘贴的FlexConnect关键高速缓冲存储

  • 当您使用在FlexConnect设置时的此方法,可能工作,并且行为也许似乎类似于什么以前解释,如果使用中央验证回到WLC (与中央或本地交换);然而, FlexConnect不支持此SKC方法。
  • 与本地传送方式AP的CUWN正式只支持此方法,不在FlexConnect或其他模式。

与WPA2 PMKID高速缓冲存储/粘贴的专业人员关键高速缓冲存储 

此方法可以由自治独立报AP实现本地,不用一个集中化设备的需要管理被缓存的密钥。

与WPA2 PMKID高速缓冲存储/粘贴的缺点关键高速缓冲存储

  • 如被提及前在本文,此方法的主要限制是客户端可只进行法塞特安全漫游,当漫游回到以前关联/已验证的AP时。如果漫游对新的AP,客户端必须再完成全双工EAP验证。
  • 无线客户端和AP必须记住缓存在每新证书派生的所有PMKs,因此此功能对一定数量的PMKs通常被限制。因为此限制由标准不是明晰定义,供应商能定义在他们的SKC实施的不同的限额。例如, Cisco WLAN控制器能当前缓存从一个客户端的PMKs八的AP。如果客户端漫游对超过八AP每会话,最旧的AP从缓存列表删除为了存储新被缓存的条目。
  • 可选和许多WPA2设备仍然不支持此方法;因此,此方法广泛没有采用并且部署。
  • 不支持SKC,当您执行控制器之间漫游时,发生,当您移动在不同的WLCs管理的AP之间,即使他们在同样移动组。

法塞特安全漫游与积极的关键高速缓冲存储

积极的关键高速缓冲存储(PKC)或机会主义的关键高速缓冲存储(OKC)基本上是以前描述的WPA2 PMKID高速缓存方法的增强,是它为什么也被命名Proactive/机会主义的PMKID高速缓冲存储。因此,请注意不是802.11标准定义的一个法塞特安全漫游方法和许多设备不支持这。

此技术只允许无线客户端和WLAN基础设施缓存客户端关联的寿命的一PMK有此WLAN的(派生从MSK,在初始802.1X/EAP验证用认证服务器)后,既使当漫游在使用作为在所有WPA2 4方式握手的种子的多个AP之间,因为他们全都共享原始PMK。这仍然要求,正在SKC,为了生成新建的加密密钥,在客户端重新关联与AP时候。为了使共享的AP从客户端会话的此一原始PMK,他们必须全部在某类管理控制下,用缓存并且分配所有的原始PMK AP的一个集中化设备。这类似于CUWN, WLC进行所有的此工作拉普在其控制下,并且使用移动组为了处理在多个WLCs之间的此PMK;因此,这是在自治AP环境的一个限制。

使用此方法,正在PMKID高速缓冲存储(SKC),所有AP的最初的关联是一正常首次验证对WLAN,您必须完成整个802.1X/EAP验证认证服务器和4方式握手密钥生成的,在您能发送数据帧前。这是说明此的屏幕截图:

debug输出基本上显示EAP验证帧交换和在本文描述的方法的其余一样在最初的验证对WLAN (如捕获所显示),与关系到关键高速缓冲存储技术使用由WLC这里一些输出的新增内容一起。此debug输出也被削减为了显示仅相关信息:

*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/PKC 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

使用此方法,无线客户端和WLC (所有管理的AP)缓存最初设立安全关联的一原始PMK。基本上,在无线客户端连接对特定AP时候, PMKID被切细根据:客户端MAC地址、AP MAC地址(WLAN的BSSID)和PMK派生与该AP。所以,因为PKC/OKC缓存所有的同样原始PMK AP和特定客户端,当此客户端(关于)联合对另一个AP,更改为了切细新的PMKID是新的AP MAC地址的唯一的值。

当客户端启动漫游对新的AP并且发送再聚集请求帧时,添加在WPA2 RSN信息元素的PMKID,如果要通知AP一被缓存的PMK使用法塞特安全漫游;当它已经认识BSSID (AP)的MAC地址的漫游的地方,然后客户端切细在此再聚集请求使用的新的PMKID。当AP收到从客户端时的此请求,也切细与已经有的值的PMKID (被缓存的PMK、客户端MAC地址和其自己的AP MAC地址),并且回应确认PMKIDs匹配的成功的再聚集答复。被缓存的PMK可以使用作为开始WPA2 4方式握手为了派生新的加密密钥的种子(跳过的EAP) :

在此捕获,从客户端的再聚集请求帧选择并且展开,以便您能看到帧的更多详细信息。MAC地址信息并且坚固的安全性网络(RSN,根据802.11i ?WPA2)信息元素,关于用于此关联的WPA2设置的信息显示(突出显示是从被切细的公式获取的PMKID)。

这是WLC调试摘要此法塞特安全漫游方法的与OKC/PKC :

*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 PKC/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 PKC/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,然而PKC/OKC,如以前解释。此处CCKM是WLC的名称用于那些输出,例如处理值为了计算PMKID功能的名称。

与积极/机会主义的关键高速缓冲存储的FlexConnect

  • 当您使用在FlexConnect设置时的此方法,行为正确地是相同的象以前解释(当您进行法塞特安全漫游)时,只要对的AP客户端漫游属于同一FlexConnect组的地方。

    注意:此设置也许工作,如果AP不在同一FlexConnect组,但是这不是一个推荐或支持的设置。

  • 此方法工作,只有当执行中央验证回到WLC (与中央或本地交换);它不工作,如果进行在FlexConnect设置的本地认证,因此意味着全双工802.1X/EAP验证必须再出现。因此,它,当FlexConnect AP在独立模式时,不支持。

与WPA2积极/机会主义的关键高速缓冲存储的专业人员

  • 无线客户端和WLAN基础设施不需要记住多个PMKIDs,然而缓存从最初的验证的一原始PMK到WLAN。然后您必须改作适当的PMKID (使用在再聚集请求)要求以每个AP安全关联为了验证法塞特安全漫游。
  • 这里,无线客户端进行法塞特安全漫游对在同样WLAN/SSID的新的AP,即使未曾关联与该AP (在SKC的不是案件)。只要客户端执行初始802.1X/EAP验证与处理所有的PMK缓存的AP客户端漫游的集中化部署管理的一个AP,然后没有其他全双工认证没有为客户端寿命的其余在此WLAN的要求。

与WPA2积极/机会主义的关键高速缓冲存储的缺点

  • 此方法在所有AP在对缓存和共享从客户端会话的一原始PMK负责。的某类管理控制下的一个集中化环境只部署(例如WLAN控制器)所以,这是在自治AP环境的一个限制。
  • 在此方法应用的技术在802.11标准没有被建议也没有描述,因此许多WPA2设备仍然不支持。所以,此方法广泛没有采用也没有部署。

法塞特安全漫游与802.11r

根据802.11r附录的法塞特安全漫游技术(正式命名快速BSS转换由802.11标准和叫作FT)是802.11标准的IEEE正式批准的(在2008)第一种方法作为解决方案执行在AP之间的快速转变(基本服务集或BSSs),清楚地定义了关键层级使用,当您处理并且缓存在WLAN时的密钥。然而,其采用慢,主要由于其他解决方案已经可用,当快速转变实际上要求,例如与VoWLAN实施,当使用与以前解释的其中一个方法在本文。有当前支持某些FT选项仅的一些个设备(由2013)。

此技术比其他方法,当引入在不同的设备PMKs的新概念和多层(有一个不同的角色的每个设备被缓存)和提供是复杂解释法塞特安全漫游的更加选项。所以,摘要提供关于实现与每选项联机的此方法和方式。

802.11r是与SKC和PKC/OKC不同,主要由于这些原因:

  • 握手消息传送(例如PMKID、ANonce和SNonce交换)发生在802.11验证帧或在操作帧而不是再聚集帧。不同于PMKID高速缓存方法,分开的4方式握手相位,运载,在(关于)后关联消息交换,避免。在客户端充分地漫游/重新关联与此新建的AP前,与新的AP的关键握手开始。
  • 它为快速地漫游握手提供两个方法:在AIR和在分布式系统(DS)。
  • 802.11r有关键层级更多层。
  • 当此协议避免密钥管理的4方式握手,当客户端漫游(时生成新的加密密钥- PTK和GTK-,不用此握手需要),可能为与PSK的WPA2设置也应用,并且不仅,当802.1X/EAP使用验证时。这加速漫游这些设置的, EAP或4方式握手交换不发生。

使用此方法,无线客户端执行一最初的验证WLAN基础设施,当连接被建立对第一个AP时,并且进行法塞特安全漫游,当漫游在同一个FT移动性域的AP之间时。

这是其中一个新概念,基本上是指AP使用同样SSID (是公认的扩展服务设置或ESS)并且处理同样FT密钥。这类似于至今解释的其他方法。AP处理FT移动性域密钥的方式根据一个集中化设置通常,例如WLC或移动组;然而,此方法在自治AP环境可能也实现。

这是关键层级的摘要:

  • MSK在客户端请求方和认证服务器仍然派生从初始802.1X/EAP认证阶段(转接从认证服务器到验证器(WLC),一旦验证是成功的)。此MSK,类似在其他方法,使用,种子FT密钥层级。当您使用WPA2-PSK而不是EAP验证方法时, PSK基本上是此MSK。
  • 主密钥R0 (PMK-R0)从MSK成对地派生,是FT密钥层级的第一层的密钥。此PMK-R0的关键持有人是WLC和客户端。
  • 启用密钥,成对地呼叫一主密钥R1 (PMK-R1),从PMK-R0派生,并且关键持有人是WLC和保持PMK-R0的AP管理的客户端。
  • FT密钥层级的第三和最后一层密钥是PTK,是用于的最终密钥为了加密802.11单播数据帧(类似于使用WPA/TKIP或WPA2/AES)的其他方法。此PTK在FT派生从PMK-R1,并且关键持有人是WLC和AP管理的客户端。

注意:从属在WLAN供应商和实施设置(例如自治AP、FlexConnect或者Mesh), WLAN基础设施也许用不同的方式转接和处理密钥。它可能均等更改关键持有人的角色,但是,因为那是超出本文的范围,根据关键层级摘要的示例以前给是下个重点。差异实际上不是的那了解进程,除非实际上需要分析详细基础设备(和他们的代码)为了发现软件问题。

通过空气快速BSS的转换

使用此方法,所有AP的第一个关联是一正常首次验证对WLAN,认证服务器和4方式握手的整个802.1X/EAP验证密钥生成的必须出现,在数据帧发送前,如此屏幕截图所显示, :

主要区别是:

  • 认证密钥管理协商跟正常WPA/WPA2有些不同,因此一些额外信息用于为了执行此协商,当支持FT时的WLAN基础设施的关联发生。如捕获所显示,从客户端的关联申请帧选择,并且RNS信息元素的AKM字段突出显示为了显示此客户端要执行在802.1X/EAP的FT。
  • 并且显示移动性域信息元素(一部分的FT),其中FT功能,并且Policy字段指示快速BSS转换是否完成的通过空气或在- DS,当快速地漫游时(指示通过空气在此捕获)。
  • 另一信息元素也添加(快速BSS转换或FT IE,是描述的以后在本文)与要求为了执行FT验证顺序,当FT漫游时的信息。
  • 密钥生成不同的归结于关键层级,因此,即使FT 4方式握手看起来类似于WPA/WPA2 4方式握手,实际上是有些不同的在内容。

调试基本上显示EAP验证帧交换和方法的其余一样在最初的验证对WLAN (如被注意从捕获),但是关系到关键高速缓冲存储技术使用由WLC被添加的一些输出;因此,此debug输出被削减为了显示仅相关信息: 

*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输出此处,另外的调试与调试客户端一起启用,是调试ft事件enable (event)

这是一个最初的关联的捕获和调试对WLAN,当您执行FT与WPA2-PSK (而不是802.1X/EAP方法)时,其中从AP的关联响应桢选择为了显示快速BSS转换信息元素(突出显示)。需要的某些关键信息为了执行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方式握手位置派生新建的动态加密密钥的方法的一更有效的。

当一快速BSS转换通过空气以802.1X/EAP安全执行时,下个捕获显示交换的帧。从客户端的开放式系统验证帧AP的选择为了发现要求开始FT密钥协商的FT协议信息元素。这用于为了派生与新的AP的新的PTK (根据PMK-R1)。显示验证算法的字段突出显示为了显示此客户端不执行一简单开放式系统验证,但是一快速BSS转换:

这是从WLC的debug输出,当此FT漫游事件发生在802.1X/EAP时:

*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

这是显示一快速BSS转换通过空气以WPA2-PSK安全,从AP的最终再聚集响应桢到客户端选择为了显示关于此FT交换的更多详细信息的捕获:

这是debug输出,当此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

如捕获所显示,一旦快速BSS转换协商在WLAN的最初的关联,使用,并且要求为漫游的四帧(从客户端的开放式系统验证,从AP的开放式系统验证,再聚集请求和再聚集答复)基本上使用,当FT 4方式握手为了派生新的PTK (单播加密密钥)和GTK (组播/广播的加密密钥)。

这替代品对于通常发生的4方式握手,在这些帧交换后,并且在这些帧的FT内容和密钥协商基本上是相同的您是否使用802.1X/EAP或PSK作为安全方法。如捕获所显示, AKM字段是主要区别,确认客户端是否执行FT与PSK或802.1X。所以,请注意这四帧通常没有关键协商的此种安全信息,但是,只有当客户端FT漫游时,如果802.11r实现并且协商在客户端和WLAN基础设施之间在最初的关联。

在的快速BSS转换- DS

802.11r允许快速BSS转换另一个实施, FT漫游由有新的AP的客户端启动客户端在漫游- DS (分布式系统)和不通过空气。在这种情况下, FT操作帧用于为了启动关键协商而不是开放式系统验证帧。

基本上,一旦客户端决定它也许漫游到更加好的AP,客户端发送FT行动请求帧对在漫游前当前连接的原始AP。客户端指示BSSID (MAC地址希望对FT的)目标AP请漫游。原始AP传送此FT行动请求帧对在分布式系统(通常有线基础架构)的目标AP,并且目标AP响应给客户端用FT操作响应桢(也在DS,因此它能最终发送它通过空气对客户端)。一旦此FT操作帧交换是成功的,客户端完成FT漫游;客户端发送再聚集请求对目标AP (通过空气这次的),并且收到从新的AP的再聚集答复为了确认漫游和最终密钥派生。

总之,有协商快速BSS转换和派生新建的加密密钥的四帧,但是此处开放式系统验证帧用FT行动请求/响应桢替代,交换与在分布式系统的目标AP有当前AP的。此方法为安全方法802.1X/EAP和PSK也是有效,所有支持的由Cisco无线LAN控制器;然而,从此在-不支持DS转换,并且实现由大多WiFi行业的无线客户端(并且,因为帧交换和debug输出基本上是相同的),示例在本文没有提供。反而,此镜像用于为了形象化在- DS的快速BSS转换:

与802.11r的FlexConnect

  • 当您使用在FlexConnect设置时的此方法,行为正确地是相同的象以前解释(当您进行法塞特安全漫游)时,并且的AP客户端漫游不需要属于同一FlexConnect组的地方。
  • 此方法工作,只有当回到WLC的中央验证(与中央或本地交换)执行;如果在FlexConnect设置的本地认证进行,它不工作。因此,它,当FlexConnect AP在独立模式时,不支持。

与802.11r的专业人员

  • 此方法是第一该用途一关键层级明晰定义由在802.11标准的IEEE作为附录(802.11r),因此这些FT技术的实施是兼容在供应商之间和没有不同的解释。
  • 802.11r允许是有用,从属于您的需要的多个技术(通过空气和在- DS,为802.1x/EAP安全和为PSK安全)。
  • 无线客户端进行法塞特安全漫游对新的AP在同样WLAN/SSID,即使未曾关联与该AP和没有需要保存多个PMKIDs。
  • 这是允许更加快速漫游以PSK安全的第一个法塞特安全漫游方法,并且避免要求,当漫游在与WPA/WPA2 PSK时的AP之间的4方式握手。当此安全方法实现时,法塞特安全漫游方法的主要目的将避免802.1X/EAP握手;然而,为了PSK安全漫游事件加速与802.11r通过避免4方式握手。

与802.11r的缺点

  • 有实际上支持快速BSS转变的一些个无线客户端设备,并且在大多数情况下,他们不支持所有技术可用在802.11r。
  • 由于事实这些实施是非常新的,没有从雷亚尔德蒙特罗伊制作环境的足够的测试结果或足够的调试结果为了寻址也许出现的可能的警告。
  • 当您配置WLAN/SSID为了使用其中任一个FT方法时,然后支持802.11r只有的无线客户端能连接到此WLAN/SSID。FT设置对于客户端不是可选的,如此不支持802.11r必须连接一分开的WLAN/SSID FT根本没有配置的那些无线客户端。

结论

  • 记住客户端总是决定漫游到特定AP的那个,并且WLC/AP不能为客户端决定此。一旦考虑它应该漫游,漫游事件由无线客户端启动。
  • 请注意非常法塞特安全漫游方法开发为了加速漫游进程的WLAN,当您移动在AP之间时,如果WLAN/SSID有启用的安全。当安全不到位时,没什么加速,因为客户端AP交换总是要求,当漫游在AP之间时的无线管理帧,在数据帧发送前(从客户端的开放式系统验证,从AP的开放式系统验证,再聚集请求和再聚集答复)。所以,这不能移动其中任一更加快速。如果遇到漫游问题没有安全,则没有改进漫游的快速地漫游方法,只有方法为了确认WLAN/SSID设置和设计是否是适当为了无线客户端站点能相应地漫游在AP覆盖信元之间。
  • 802.11r/FT实现与WPA2-PSK为了加速漫游事件以此安全通过避免4方式握手,如解释在802.11r部分内。
  • 当AP在独立模式时,法塞特安全漫游方法都在设置的FlexConnect不工作。
  • 所有方法有他们的优点和缺点,但是在末端,您必须总是验证,如果无线客户端站点支持您要执行的特定方法,并且,如果Cisco WLAN基础设施支持可用所有的方法。因此,无线客户端实际上支持连接对特定WLAN/SSID的您必须选择佳方法。例如,在请支持与CCKM的WPA2/AES的一些部署您也许通过802.11r/FT创建与CCKM的一WLAN/SSID Cisco无线IP电话的(,但是不是802.11r),然后与WPA2/AES的另一WLAN/SSID支持此法塞特安全漫游方法的无线客户端的(或请使用OKC/PKC,如果这是支持什么)。
  • 如果无线客户端不支持其中任一法塞特安全漫游方法联机,则您也许需要接受事实那些客户端永远将试验在本文解释的延迟,当漫游在WLAN/SSID的AP之间以802.1X/EAP能导致在客户端apps/服务的中断)的安全时(。
  • 所有方法,除了SKC (WPA2 PMKID高速缓冲存储),为法塞特安全漫游支持在不同的WLCs管理的AP之间(漫游的控制器之间),只要他们在同样移动组。

相关信息


相关的思科支持社区讨论

思科支持社区是您提问、解答问题、分享建议以及与工作伙伴协作的论坛。


Document ID: 116493