802.11r协议理解

首先阅读了相关协议内容整理出了以下的802.11r时序图所谓基础，而后会详细理解其中的每个步骤：

802.11链路认证：
1.OSA open System 基于MCA地址的身份验证
2.Shared-key authentication使用WEP 一共使用四个帧完成认证

关联过程：AP必须为STA在网络上注册，使分布式系统可以记录每一个STA的位置
为了节省时间，在AP接收到关联请求的时候会当即给STA一个关联响应，可是若是AC最后响应不容许关联，此时能够将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）作准备；

802.1X认证过程：强AP与弱AC的形式，使AC在认证过程当中是做为代理
802.11i协议定义了使用TLS链接生成的主密钥MSK（Master Secret Key）来做为PMK，所以只有采用了TLS方法的802.1X认证才可以用于无线接入。最多见的一种用法是802.1X使用PEAP+MSCHAPv2的认证方法，PEAP负责创建TLS链接并对内层认证数据加密，MSCHAPv2用于内层验证用户名和密码。
详细认证过程TBD

四次握手：使用EAPOL帧
在四次握手开始前，Client须要先关联到AP上，而且双方都须要准备好PMK以后才能开始四次握手。在前面1.3.2章节中介绍过，WPA-Personal方式双方能够直接计算出PMK，因此不须要经历图1-15的认证阶段，而WPA-Enterprise方式则须要经过802.1X认证来派生出PMK。
四次握手阶段的4个消息写做Message N(r, Nonce; GTK)，N用来表示是第几个消息，r用来表示图1-13中的Key Replay Counter，逗号以后是随机数Nonce，若是是Authenticator产生的随机数则写做ANonce，若是是Supplicant产生的随机数则写做SNonce，若是没有随机数则不写。分号以后的参数是保存在消息的Key Data字段的，GTK表示Data中的数据是组播密钥。
消息1：四次握手的第一个消息是由AP首先发给Client，携带了AP产生的随机数ANonce，由于Key Replay Counter关系到后续报文加密计算，因此须要初始化Key Replay Counter。在整个四次握手的4个消息中，消息1是惟一不带Key MIC校验参数的消息，前面讲过Key Replay Counter须要在Key MIC校验合法后才进行更新，所以Client在收到消息1后并不会更新本身的Key Replay Counter。由于消息1是可能出现重传的，Client不能由于收到消息1就更新本身的Key Replay Counter致使该值被重置。
消息2： Client收到消息1以后会产生一个本身的随机数SNonce，从前面1.3.3.1章节的公式能够看出，Client已经知道本身和AP的无线MAC地址，也知道本身和AP的随机数SNonce和ANonce，Client已经知足公式计算的全部输入参数，所以Client能够计算出单播密钥PTK，但此时Client并未将PTK安装到无线驱动中，由于AP还没有确认该PTK。而后Client须要将SNonce发送给AP，这样AP才可以根据一样的算法派生出PTK。
消息3：此时Client和AP双方都派生出了PTK，可是PTK仅用于单播报文的通讯加解密，组播和广播数据须要用到GTK密钥。由于是广播或组播通讯，通讯范围是一个AP下关联的全部Client，因此一个AP下的全部Client应该拥有一个共同的加解密密钥GTK，这个密钥由AP负责产生并按期更新，AP将密钥告知新接入的Client，所以AP还须要向Client发送消息3，将GTK放在Key Data字段中，但GTK也必须以加密的方式发送，加密密钥为消息2派生的PTK中的KEK密钥（图1-12中的KEK字段）。消息3会将Key Information中Install标记位置1，通知Client能够将密钥安装到无线驱动中。
消息4：该消息其实是对消息3的确认消息，表示Client确认收到了消息3，不然会引发消息3的重传，所以消息4除了带有Key MIC验证消息完整性外，不包含任何其余信息。Client发出消息4后，就会向无线驱动中安装PTK和GTK密钥；AP收到消息4后，也会向无线驱动中安装该Client的PTK，AP上已经在使用GTK，因此GTK无需再次安装到无线驱动中。
Client在与AP首次链接时，四次握手消息都是处于未加密的状态，可是Client与AP成功链接后仍然能够经过四次握手更新PTK和GTK，在更新的状况下，四次握手消息会看成普通报文同样来处理，EAPOL报文会被前一次协商的PTK加密。GTK能够单独进行更新，更新GTK时至关于只进行了消息3和消息4的步骤。GTK是由AP来定时更新，AP上的GTK一旦更新，就须要通知AP上全部的Client更新GTK，但此时封装GTK的EAPOL报文仍然须要被每一个Client的PTK加密，所以GTK的更新虽然是批量更新，但仍然是AP与每一个Client单播通讯。
由于每一个PTK是Client与AP之间经过四次握手协商出来的，因此当Client在不一样AP之间发生漫游时，都须要从新经过四次握手协商新的PTK，同时获取新AP的GTK。若是是WPA-Personal方式，PMK是提早准备好的，漫游时Client与新AP之间能够直接进行四次握手协商；若是是WPA-Enterprise方式，Client还须要从新进行一次802.1X认证来派生出新的PMK，才能与新AP之间进行四次握手协商，因此在WPA-Enterprise方式下漫游效率会下降，致使漫游发生时数据传输中断时间更久。
为了解决WPA-Enterprise方式下漫游慢的问题，Client能够与多个AP提早进行802.1X预认证，在漫游还没有发生时，Client就提早找扫描到的相同SSID的不一样AP进行802.1X认证，Client本身缓存每一个AP的PMK，每一个AP也提早缓存该Client的PMK，当漫游真正发生时，Client和AP都已经缓存了PMK，因此双方能够直接进行四次握手来协商出新的PTK，这样就实现了与WPA-Enterprise方式相同的漫游效率。可是802.1X预认证和缓存PMK须要Client和AP双方都支持才行，双方有任何一方不支持802.1X预认证，都不能进行WPA-Enterprise方式下的快速漫游。
即便Client和AP双方都支持802.1X预认证，要实现WPA-Enterprise方式下的快速漫游还有一些须要注意的地方，那就是802.1X认证是Client首先发起第一个报文启动认证流程，而四次握手是AP首先发起第一个报文启动协商流程，两个流程首个请求发起者不同。
从AP的角度来看，当一个Client关联上来以后，AP若是缓存了该Client的PMK，但AP不知道该Client是否也缓存了PMK可否快速进入四次握手阶段，所以AP会保持一小段静默时间，静默期间若是未收到Client发起802.1X认证，则AP进入四次握手阶段发出消息1。若是AP不支持802.1X预认证，也就不能缓存Client的PMK，当Client漫游过来后应该当即发送802.1X Identity来触发Client尽快进入802.1X认证阶段。
从Client的角度来看，当漫游到新AP后，若是Client缓存了PMK，则不主动发起802.1X报文，静静等待AP发出四次握手的消息1，若是超过了AP静默期仍然未收到四次握手的消息1，则须要放弃本地缓存的PMK，从新发起802.1X认证流程派生新的PMK。若是Client不能提早缓存PMK，则漫游后应该当即主动发起802.1X认证，AP会放弃原来缓存的PMK，经过802.1X认证来派生出新的PMK后，再进行四次握手。

probe帧：在无线网络中，probe帧是周期发送进行探测STA

Fast BSS Transmition：
快速漫游过程相比于普通的STA上线过程主要区别在于：
1.在链路认证的时候使用的是FT认证
2.快速漫游是创建在已经链接无线网络的前提下，因此发生了从新关联的过程
3.没有802.1X认证过程(PMK已经存在)
4.没有四次握手过程，密钥协商发生在重关联的过程

密钥计算公式：

XXXKey指的是PMK
PMK_R0指的是root key在AC中存放，R0KH指的是AC，R0KH-ID指的是该AC的MAC地址
PMK_R1指的是由PMK_R0和R0KH-ID派生出来的密钥在AP中存放，R1KH指的是AP，R1KH-ID指的是该AP的MAC地址
PMK_R0_Name指的是PMK_R0在AC的密钥存储表中的Index，生成方式见上图
PMK_R1_Name指的是PMK_R1在AP的密钥存储表中的Index，生成方式见上图
密钥存储表表现方式为键值对，好比（PMK_R0_Name，PMK_R0）

密钥结构：
1)PMK_R0为第一层密钥，它由MSK（PMK）或PSK推演出来，由PMK_R0密钥持有者保存（即R0KH和S0KH）。
2)PMK_R1为第二层密钥，它由R0KH和S0KH共同推演而来，由PMK_R1密钥持有者保存（即R1KH和S1KH）。
3)PTK为第三层密钥，它是由R1KH和S1KH共同推演而来。R0KH和R1KH为认证者端的结构，与之对应的S0KH和S1KH为客户端的结构。
S0KH和S1KH都是指STA

FT认证：
Auth报文中的FTAA表明该验证请求帧的验证算法为FT，而不是Open和shared key；帧中的MDIE必须和FAP自身的MDIE一致，不然会致使验证失败；一样的，若是PMKR0name不可用或者R0KH（这里的R0KH_ID必须是进行初始化关联阶段所得到的R0KH_ID）不可达，一样会报错（报错结果参见 state code）。
目标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 )时间或者重关联时间[TIE(Reassociate Deadline )]到期前未收到重关联帧，那么目标AP就要将PTKSA删除。
若是目标AP通过计算找不到PMK_R1，则向R0KH发送请求，R0KH计算出PMK_R1后，将PMK_R1SA发给R1KH。R1KH随后计算随机值Anonce，并经过3.7式计算出PTK，返回一个Auth response帧给工做站。

从新关联： 此时双方都已经计算出PTK了这里的两个帧是为了校验双方的PTK计算的是否同样。