802.11R无线交互

802.11R无线交互

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协议中帧类型中的内容。

发布于 2018-12-21