802.11R无线交互

1. 专有名词

2. 说明

Beacon（信标）帧是一种由AP周期发送的广播帧，AP通过周期发送Beacon帧来声明某个802.11网络的存在。STA（无线客户端）收到Beacon帧后可以得知该网络的存在，从而调整加入该网络所必需的参数。

Beacon中包含了大量的信息，本系列技术总结文档每一篇都是由Beacon报文中的一个具体字段入手，由此展开给出该字段相关的协议介绍，Beacon报文组帧规则以及相关的问题记录。

本篇通过Beacon帧中的MD字段解读802.11r协议。

3. 802.11r协议解读

IEEE802.11r(Fast BSS Transition)定义了STA在同一移动域 (MD)中的不同AP之间漫游时的交互细则，提供了实现BSS快速切换的标准。802.11r快速漫游实现方法为：STA首次关联MD内的AP时，利用802.1x认证获得的主会话密钥（MSK，由于该密钥为认证者和申请者共享，也称为成对主密钥PMK）和MD内各个AP的R1KH_ID计算出不同的PMK_R1分发给MD内的其它AP；STA切换AP时，STA直接利用之前发送到目标AP上的PMK_R1协商出成对临时密钥(PTK)和组临时密钥(GTK)，以此缩短漫游切换时间，避免再重复进行耗时的802.1x认证。

802.11r协议主要描述了四个部分的内容：密钥管理、FT初始化关联、快速切换和新增的信息元素。

4. 密钥管理

4.1. 密钥结构

在RSN（802.11i）的基础上，802.11r提出了三层密钥的结构和计算方法，而传统的RSN则是两层密钥结构。RSN通过认证者（对于自治式WLAN而言就是AP，对于分布式WLAN一般是AC）,申请者（无线STA）共享的主会话密钥(PMK,在进行802.1X验证时获得)进行展开，获得组临时密钥(GTK)和PTK。因此，RSN的密钥只分两层：除了作为秘密根源的PMK，就是通过PMK计算而来的PTK。

802.11r则将密钥管理分为三层，三层密钥分别为PMK_R0，PMK_R1，PTK。PMK_R0和PMK_R1的计算是80211r特有的。

PTK的计算方式与80211i的计算方式也有所不同，80211i是通过伪随机函数（PRF）展开PMK来获得PTK，而80211r则是通过密钥派生函数（KDF）来展开PMK，KDF函数实际上是PRF的变种。

PMK_R0为第一层密钥，它由MSK（PMK）或PSK推演出来，由PMK_R0密钥持有者保存（即R0_KH和S0_KH）。

PMK_R1为第二层密钥，它由R0KH和S0KH共同推演而来，由PMK_R1密钥持有者保存（即R1KH和S1KH）。

PTK为第三层密钥，它是由R1KH和S1KH共同推演而来。R0KH和R1KH为认证者端的结构，与之对应的S0KH和S1KH为客户端的结构。

R0KH和R1KH为认证者一端的密钥管理实体，PMK_R0和PMK_R1的计算由R0KH控制。R0KH同时还要负责提供PMK_R1给R1KH，PTK的计算由R1KH控制。

S0KH和S1KH为申请者(无线STA)一端的密钥管理实体，S0KH与S1KH的功能与R0KH，R1KH相对应。

R0KH-ID是R0KH的标识（NAS_ID），ROKH_ID是当前关联AP的标识，R1KH_ID为目标AP的表示，在跟目标AP协商关联时，需要用到上一个关联AP的R0KH_ID，所有才会有初始化关联之后有个R0KH_ID的分发，后续有重新获取R0KH_ID的请求，后文中有介绍。按IEEE标准为1-48字节长，可由厂商自定义，R1KH-ID是认证者的MAC地址。

S0KH-ID和S1KH-ID都为申请者(无线STA)的MAC地址。

图1 802.11r三层密钥结构

4.2. 密钥计算公式

802.11r密钥具体计算方法请参考IEEE802.11r-2008

5. 密钥的分发和索取

为了实现STA切换AP时的快速漫游，802.11r规定，在STA初次与MD进行初始化关联后，认证者在合适的时候（对此802.11r文档没有明确说明，从状态机上看应该是计算出PTK之后，再为其他R1KH计算分发PMK_R1），需要遍历MD中的所有R1KH_ID（检查MD中有记录的认证者MAC）并计算出相关的PMK_R1发往MD内的所有R1KHs，此后STA在进行漫游时，可以通过事先配发的PMK_R1计算出PTK，避免再进行费时的802.1x认证。

PMK_R1的计算分发由R0KH完成。

5.1. 密钥计算过程:略

5.2. 密钥计算流程

1. 如果WLAN网络采用的是802.1x认证方式，R0KH就根据认证交互过程中从radius认证服务器那得到的主会话密钥(MSK)计算出PMK_R0；如果是采用PSK方式则直接根据PSK进行计算。当认证成功后，R0KH删除MD中以前存有的与S0KH有关的PMK_R0、PMK_R1的安全关联，然后ROKH再计算出来的新的PMK_R0、PMKR0name和PMK_R1，并使新的PMK_R1对于STA将要关联的AP的RIKH有效，给与PMK_R1安全关联。

2. R0KH同时根据MD内的不同R1KH_ID计算出PMK_R1，并将它传给同一MD中的所有R1KHs。PMK R1s是用来计算成对临时密钥(PTK)的。R1KH接收到PMK_R1时就会删除以前的PMK_R1的安全关联，以及它所计算出的PTKSAs。

PMK_R0，PMK_R1，PTK的生命周期取决于进行802.1x验证时得到的MSK的情况，其长度不能超过MSK本身的生命周期。

PMK-R1的计算流程如下：

由于每个R1KH_ID在MD中的唯一性，每个AP计算出的PMK_R1是不同的，因此对于每一个STA，在不同的R1KH里保存的PMK_R1也是唯一的。但对应的PMK_R0则是一样的。

密钥的索取机制发生的条件为漫游时目的AP的R1KH密钥管理实体上没有找到STA要求的PMK_R1。这种情况可能是MD中临时添加了新的AP，或者R0KH密钥管理实体分发密钥时MD中的某个AP没有启动，而不是因为链路不通，或链路不安全。此时R1KH密钥管理实体会根据STA发出的R0KH_ID字段找到R0KH密钥管理实体索取PMK_R1。此时R0KH密钥管理实体会根据发出请求的R1KH_ID推演出PMK_R1和PMKR1Name存储在R1KH密钥管理实体中。

总结式理解：组网要求加密方式相同，同一个AP的不同频段，ESS网络的不同AC都有自己的MAC，且唯一，MD中记录这个ESS/BSSID的R1KH_ID，然后ROKH+SOKH计算出PMK_R1，R0KH将PMK_R1分发给所有R1KHs，保证同一个MD中所有AP/AC都有个与该STA对应的PMKH_R1，当获取不到PMK_R1时，可能新增了AP或者MD中的这个AP挂了，因为PMK_R1有根据MAC地址计算，所有PMK_R1唯一。漫游时，获取到PMK_R1后基本上可以确定具体的STA切换到具体某个AP上了，装载PTK就漫游成功了。所有要特别注意初始关联，会有信息登记到MDIE。

PMK_R1信息会更新在认证端（漫游目的AP携带），包含申请者（STA）的信息，当申请者漫游到某个AP时，根据事先已经获取的PMK_R1计算PTK，这样就顺利的关联成功，减少了握手的时间。

6. FT初始化关联

FT初始化关联是指STA要接入MD中AP的第一次关联，是后面进行快速漫游切换的前提。如果STA支持802.11r，它就会在(Re)Association_Requese帧中加入移动区域信息单元(MDIE)；如果支持IEEE802.11i就会加入健壮安全网络信息单元(RSNIE)。当IEEE802.1x认证通过后(如果是PSK方式则没有这一步)，STA和AP就会进行4次握手。握手完毕后IEEE 802.1x的受控端口打开，FT的三层密钥结构建立。

6.1. 集中式WLAN的初始化关联流程（支持RSN）

1. AP在Beacon帧和Probe Response帧里添加所属移动域的信息（MDIE）和RSNIE，告知STA本AP的相关信息；

2. STA与AP进行802.11链路认证，认证方法为OPEN，而不是shared key或FT（FT验证算法只用于Over_the_air方式的快速切换）；

3. STA进行关联操作，如果STA支持80211r则会在关联报文中添加MDIE，如果支持80211i则添加RSNIE，AP收到assoc req帧后会拿这两个信息元素和自身的MDIE，RSNIE对比（也就是写入Beacon帧里的MDIE），如果不一致会导致关联失败，关联成功后，AP向STA发送assoc resp帧，并告知STA其R0KH_ID和R1KH_ID。为以后生产三层密钥（PMK_R0，PMK_R1，PTK）做准备；

4. 关联成功后则进行802.1x的验证（为PSK则跳过这个步骤），802.1x验证完成后认证者将MSK发给STA（由于该MSK由双方共享，故也称为PMK）。

5. 收到MSK后的R0KH和S0KH开始计算PMK_R0和PMKR0Name，同时废除以前的，与当前STA相关的PMK_R0安全关联，随后遍历MD内的R1KH_ID计算出PMK_R1安全关联并发布给所有的R1KH（FT-PMK-R1-SA-PUSH）。

6. 在FT-INIT-GET-R1_SA阶段，R1KH从R0KH获取到PMK_R1后，随后计算随机值Anonce，接下来开始四次握手。

6.2. FT初始关联中的四次握手

1. R1KH进入FT-PTK-START阶段后，向工作站发出EAPOL_Key帧，内含随机值Anonce，这一帧不加密，但不用担心被篡改，因为一旦Anonce被篡改，那么STA和AP上计算出的PTK一定不一样。

2. STA接收该帧时，S1KH已经计算出PMK_R1，随后S1KH计算出本地随机值Snonce，并根据式3.7计算出PTK，计算完毕后，STA向AP发送一个EAPOL-KEY帧，附带自己的Snonce，PMKR1Name，MDIE，FTIE。这一帧也不加密，但附带了MIC校对，篡改内容会导致校验失败。同时MDIE，FTIE必须和Assoc response帧内的MDIE，FTIE相同。

3. AP根据STA发来的snonce由3.7计算出PTK。AP会在第三次握手中将组临时密钥（GTK）发过去，这一帧经过加密，因为此时双方拥有公共的PTK。第三次握手时附带的PMKR1Name和第二次握手时发送的PMKR1name必须相同。

4. STA解密后收到GTK，同时发送带MIC的确认帧，802.1x受控端口打开，STA可以正常访问网络了，如果PTKSA超期，STA需要重新进行FT初始化关联。

备注：本举例仅说明了集中式网络中的初始化关联流程。

当TIE(keylife time)期满后，需要重新初始化关联过程；

当AP给STA发送过Deauthentication或disassociate帧时，若要再关联，仍需进行初始化关联过程；

若初始化关联后，客户端的EAPOL状态机触发了一个EAPOL start包，STA需要进行初始化关联过程。

7. 快速BSS切换（FT）

从切换方式来讲，FT可以分为Over_the_ds和Over_the_air方式。

Over_the_air方式：STA直接和target AP通信。

Over_the_ds方式：STA通过current AP与target AP通信。

从切换协议来讲，可以分为FT protocol和带资源请求的FT协议（FT resource request protocol）两种。

7.1. Over_the_air FT protocol in an RSN

图5 Over_the_air快速切换流程

STA在和TargetAP进行FT时，首先进行auth验证交互：
步骤一：Auth报文中的FTAA代表该验证请求帧的验证算法为FT，而不是Open和shared key；帧中的MDIE必须和Target AP自身的MDIE一致，否则会导致验证失败；同样的，如果PMKR0name不可用或者R0KH（这里的R0KH_ID必须是进行初始化关联阶段所获得的R0KH_ID）不可达，同样会报错。

目标AP的R1KH利用PMKR0Name和帧中的其它信息计算出PMKR1Name。如果AP没有PMKR1Name标识的Key（PMK_R1），R1KH就会从STA指示的R0KH获得这个Key。目标AP收到一个新的PMK_R1后就会删除以前的PMK_R1安全关联以及它计算出的PTKSAs。STA和目标AP计算PTK和PTKName时需要用到PMK_R1，PMKR1Name，ANonce和SNonce。认证完成后，若是在TIE(Reassociate Deadline )时间到期前未收到重关联帧，那么目标AP就要将PTKSA删除。如果目标AP在重关联时间[TIE(Reassociate Deadline )]到期前没有从STA那里收到Reassociation Request帧，AP就将PTKSA删除。

如果目标AP经过计算找不到PMK_R1，则向R0KH发送请求，R0KH计算出PMK_R1后，将PMK_R1SA发给R1KH。R1KH随后计算随机值Anonce，并通过3.7式计算出PTK，返回一个Auth response帧给工作站。

步骤二：

Auth response帧中的R0KH_ID必须和Auth request帧中的一样，都为初始化关联时的R0KH_ID。

R1KH_ID为target AP的R1KH_ID；

PMKR0name用于找到对应的PMK_R1，其余字段用于确认。

收到auth response帧后，S1KH进入利用3.7式计算出PTK，如此一来，双方都有了共同的PTK。

随后是重关联阶段:

重关联请求帧里的PMKR1Name、ANonce、SNonce、MIC值、R1KH_ID和R0KH_ID都是为了与AP端确认，AP端会将自身的值与这些信息比较，如果发现不同，关联就会失败。

Target AP收到请求帧并且验证无误的话，回复Reassoc response帧给STA，帧内带有加密后的GTK，STA可以用PTK解密获取GTK。

重关联完成后，802.1x受控端口打开。

7.2. Over_the_ds FT protocol in an RSN

图6 Over_the_ds快速切换流程

Over_the_ds快速切换的重关联阶段和Over_the_air相同，但前两个步骤不同：

STA会发送一个Action request帧给current AP，帧内包含Target AP的mac地址，current AP会转发这一帧给target AP。

Action帧由当前AP到目标AP的转发是通过有线传输的，为此IEEE802.11r专门定议了RRB(远程中继代理)帧格式。RRB帧格式的以太网类型为0x890d，接下来的字段如下图所示：

Remote FrameType字段必须为1，否则这一帧将被忽略。FT Packet Type字段0为远程请求；1为远程响应。FTAction Length字段表示FTAction Frame的长度。 APAddress字段表示发送这～帧的AP的地址。FT Action Frame字段用于封装FT Action帧。

当STA通过当前AP与目标AP通信时，首先是将所要发的内容封装在Action 管理帧中，目的地址为目标AP的地址。当前AP收到这一Action帧时就对这一帧 进行分析发现不是给自己的就进行转发。当前AP将Action帧封装在一个以太网 类型为0x890d的以太网中，并插入了当前AP的地址，然后通过以太网转发给目 标AP。这样，目标AP收到这一帧后就知道是由哪个AP转发的Action帧，于是目标AP也按照同时的帧格式将回复帧发给当前AP。当前AP收到帧后将封装在里面 的Action帧提出来转发给STA。

密钥计算方式和Over_the_air相同。

报文实例：暂无，后续补充

8. MDIE

图7 Beacon报文中的MDIE：暂无3

一般可以将一个ESS看做一个移动域(MD)，具体到产品实现可以将一个AC与其控制下的所有具有相同SSID的AP及所有关联到这些AP上的STA看做一个移动域。MDIE字段用于标识该移动域的ID与性能。如果AP支持802.11r，这个字段被AP添加到Beacon帧和Probe resp帧里，在关联请求关联响应以及密钥协商报文中该字段也会出现。该元素格式如下：

除了Element ID用于标识MDIE自身，Length字段用来表示MD字段长度。剩余字段被设置为3字节，MDID用来标识MD，最后一个字节用来标识MD的性能和策略。

MDID字段：2字节，用于标识区分同一个SSID下面几个不同的MD（mobility domain）。

FT Capability and Policy字段：1字节，用于宣称MD策略和性能

B0置1，代表该MD通过over_the_DS的方法执行快速转换，华为AP不支持over_DS;

B0置0，代表该MD通过over_the_Air的方式执行快速转换，华为AP仅支持over_Air;

B1置1，代表“带资源请求的FT协议”，华为AP当前不支持TSPEC，因此暂不支持；

B2预留未使用。

9. FTIE（快速转换信息元素）

图8 AP关联响应报文中的FTIE

FTIE元素传递与密钥协商有关的信息，如完整性校验值(MIC)、认证者端的随机数(ANonce)、STA端的随机数(SNonce)、GTK、R1KH_ID和R0KH_ID。这个信息元素的格式如下图：

其中MICcontrol字段有2个字节，格式定义如下

MIC control中的information element count子字段表示包含在消息完整性计算中信息元素的个数。如果字段值为0就说明没有消息完整性校验值。

MIC字段为16字节的MIC值。MIC计算需要下面的数据：STA的MAC、目标AP的MAC、Transaction序号、RSNIE的内容、MDIE的内容和FTIE的内容。

ANonce字段和SNonce字段分别为R1KH和S1KH选择的32字节长度随机数。

Optional Parameter字段的格式如图所示：

Subelement ID取值表：

R1KH-ID表示R1KH的标识，R1KH-ID被ROKH和SOKH用于计算PMK-R1s,

GTK字段为已经加密的组临时密钥，出现在3/4报文中，抓包为密文无法解析，具体格式如下图：

Key length表示key的长度，不包括可能的padding字段，

RSC域包含当前安装的GTK的接收序列数，RSC(Receive Sequence Counter)，RSC给出了GTK当前的消息号，以便STA重组MPDUs，如果RSC的长度不足8个字节，后位全部补0，并且TSC或PN号的最低标志位在RSC的首位字节。“The RSC field value for TKIP is the TSC and is stored in the first 6 octets; for CCMP, it is the PN and is stored in the first 6 octets. For WEP, the RSC value is set to 0 on transmit and is not used at the receiver.”

10. TIE（超时间隔信息元素）

TIE是超时时间间隔信息元素，存在于3/4报文中，密文无法解析。该字段用来指示时间间隔和超时。TIE字段格式如下：

Length取5。Time Interval Value是长度32比特的整数。

Time interval type字段取值不固定，取不同值时候的含义如下表所列。

Reassociation deadline interval用于控制FT漫游时终端的auth与reassoc流程之间的时延，0表示无时延限制；协议默认值为1000*1024us，约1s；超时则删除已生成的PTK；

Key lifetime interval用来表示秘钥老化时长，协议默认值为1209600s，即14天；根据协议R0\R1\PTK的liftime应相同；

下面介绍的报文当前产品尚不支持，仅从协议分析。没有实际抓包。

11. Action帧

802.11r规定的Action帧分为四类：请求（request），回复（response），确认（confirm），应答（Ack），Action帧主要用于Over_the_DS类型的快速切换,代替Over_the_Air模式下的Auth帧。

11.1. FT Request 帧：

该帧用于STA发给Current AP，用于进行Over_the_DS的切换，Current AP收到该帧后会将其转发给Target AP。格式如下：

STAADDR：工作站的mac地址；

Target AP address：要切换的AP的mac地址；

帧主体组成：

11.2. FT response帧

FT response帧作为Target AP对于FT Request帧的应答，由Target AP发给Current AP，再转发给STA。格式如下：

前四个字段格式同上，status code字段用于通报检查结果，格式如下：

如果status code数值为0，表示检查没有问题，FT Response 帧主体将包含以下三个字段：

11.3. FT Confirm帧

FT Confirm帧是目标AP对接收的Snouce的RSN确认，并且指示着GTKSA的可用性。帧结构如下：

基本信息位与上相同，FT Confirm帧主体除了同样包含RSN /Mobility Domain/ Fast BSS Transition信息位，还多了一个RIC信息位。RIC Data IE（RDIE）

一个RIC（resource information container）可以看做一系列的资源请求或者资源回复（resource response），每个资源请求或回复则由一个RDIE组成，格式如下：

长度设置为4；

RDIE Identifier用于在一个RIC里标识一个RDIE

Resource Description Count用于说明该RDIE可用的资源描述符数量

Status Code 参见FT response帧中的Status code信息表。

RIC Descriptor information element

该元素在带资源请求的快速切换期间与RDIE配套使用，用于兑现AP申请的资源。

字段长度视variable parameters字段而变；

Resource type字段取值见下表

最后一个字段包含申请的block。

RIC（资源信息容器）（Resource information container

在前面提到过，一个RIC是由一系列的资源请求或资源回复组成的。包括一个或多个Resource Request，格式如下：

每个Resource Request包含一个RDIE，每个RDIE后包含一个或多个RIC Descriptor3 802.11r使用约束

802.11r仅支持WPA2（1x、PSK）和open两种安全策略；

802.11r需要终端侧配合，终端和AP均支持才可以使用，当前仅三星和苹果部分手机支持802.11r；

业界已确认部分不支持802.11r的传统终端在开启了802.1r的VAP下会接入失败，解决方案是：终端侧升级驱动版本或者AP侧配置两个相同SSID的VAP（一个开启802.11r另外一个关闭）；

产品当前暂不支持TSPEC，所以11r协议中的resource request机制也暂不支持；

当前AP不支持802.11r的Over–the-DS方式；

同时使能802.11r和802.1x重认证时候，iPhone手机在重认证完成后秘钥协商阶段采用了非11r的方式，导致协商失败而掉线重上线；

使能802.11r和802.1x重认证时候，三星note4手机，在漫游到新AP后，设备发起重认证请求，终端没有回应，重传几次都没有回应后认证超时，终端掉线重上线。

11.4. FT ACK帧

FT ACK是当前关联的AP对STA的FT Confirm帧的响应。 帧类型跟上述信息基本一致，不在附录，请参考802.11r协议中帧类型中的内容。