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计算的是否一样。