802.1x
五.802.1X协议的状态
802.1x作为一个认证协议，在实现的过程中有很多状态，此图就是其中的一种。
1）认证发起
认证的发起可以由用户主动发起，也可以由认证系统发起。当认证系统探测到未经过认证的用户使用网络，就会主动发起认证；用户端则可以通过客户端软件向认证系统发送EAPOL-Start报文发起认证。
A）由认证系统发起的认证
当认证系统检测到有未经认证的用户使用网络时，就会发起认证。在认证开始之前，端口的状态被强制为未认证状态。
如果客户端的身份标识不可知，则认证系统会发送EAP-Request/Identity报文，请求客户端发送身份标识。这样，就开始了典型的认证过程。
客户端在收到来自认证系统的EAP-Request报文后，将发送EAP-Response报文响应认证系统的请求。
认证系统支持定期的重新认证，可以随时对一个端口发起重新认证的过程。如果端口状态为已认证状态，则当认证系统发起重新认证时，该端口通过认证，那么状态保持不便；如果未通过认证，则端口的状态改变为未认证状态
B）由客户端发起认证
如果用户要上网，则可以通过客户端软件主动发起认证。客户端软件会向认证系统发送EAPOL-Start报文主动发起认证。
认证系统在收到客户端发送的EAPOL-Start报文后，会发送EAP-Request/Identity报文响应用户请求，要求用户发送身份标识，这样就启动了一个认证过程。
2）退出已认证态
有几种方式可以造成认证系统把端口状态从已认证状态改变成未认证状态。
客户端未通过认证服务器的认证
由于管理性的控制端口始终处于未认证状态，而不管是否通过认证。
与端口对应的MAC地址出现故障（管理性禁止或硬件故障）
客户端与认证系统之间的连接失败，造成认证超时
重新认证超时
客户端未响应认证系统发起的认证请求
客户端发送EAPOL-Logoff报文，主动下线
退出已认证状态的直接结果就是导致用户下线，如果用户要继续上网则要再发起一个认证过程。
为什么要专门提供一个EAPOL-Logoff机制，是处于如下安全的考虑。
当一个用户从一台终端退出后，很可能其他用户不通过发起一个新的登录请求，就可以利用该设备访问网络。提供专门的退出机制，以确保用户与认证系统专有的会话进程被中止，可以防止用户的访问权限被他人盗用。通过发送EAPOL-Logoff报文，可以使认证系统将对应的端口状态改变为未认证状态。
3）重新认证（根据时间）
为了保证用户和认证系统之间的链路处于激活状态，而不因为用户端设备发生故障造成异常死机，从而影响对用户计费的准确性，认证系统可以定期发起重新认证过程，该过程对于用户是透明的，也即用户无需再次输入用户名/密码。
重新认证由认证系统发起，时间是从最近一次成功认证后算起。重新认证可以激活或关闭，协议状态参数reAuthEnabled控制是否定期进行重新认证。重新认证的时间由参数reAuthPeriod控制，默认值为3600秒（一个小时）而且默认重新认证是关闭的。
重新认证的时间设定需要认真的规划，认证系统对端口进入的MAC地址的检测能力会影响到该时间的设定。如果对MAC地址的检测比较可靠，则重新认证时间可以设长一些。
4）认证报文丢失重传
对于认证系统和客户端之间通信的EAP报文，如果发生丢失，由认证系统负责进行报文的重传。在设定重传的时间时，考虑网络的实际环境，通常会认为认证系统和客户端之间报文丢失的几率比较低以及传送延迟低，因此一般通过一个超时计数器来设定，默认重传时间为30秒钟。
对于有些报文的丢失重传比较特殊，如EAPOL-Star报文的丢失,由客户端负责重传；而对于EAP-Failure和EAP-Success报文，由于客户端无法识别，认证系统不会重传。如果EAP-Failure或EAP-Success报文发生丢失，则客户端会在auth-While计数器超时后，自动转变为CONNECTING状态。
由于对用户身份合法性的认证最终由认证服务器执行，认证系统和认证服务器之间的报文丢失重传也很重要。
另外注意，对于用户的认证，在执行802.1x认证时，只有认证通过后，才有DHCP发起（如果配置为DHCP的自动获取） 和IP分配的过程。由于客户终端配置了DHCP自动获取，则可能在未启动802.1x客户端之前，就发起了DHCP的请求，而此时认证系统处于禁止通行状态，这样认证系统会丢掉初始化的DHCP帧，同时会触发认证系统发起对用户的认证。
由于DHCP请求超时过程为64秒，所以如果802.1x认证过程能在这64秒内完成，则DHCP请求不会超时，能顺利完成地址请求；如果终端软件支持认证后再执行一次DHCP，就不用考虑64秒的超时限制。
