忆龙2009:从802.1x客户端状态机看微软验证客户端的变化

       802.1x标准经过IEEE标准化组织的修订，目前已经出台了802.1x-2004规范，相比802.1x-2001，在一些细节方面进行了修订。部分状态机做了调整，其中，指导验证客户端开发的SUPPLICANT的状态机也进行了修改，这直接会影响到802.1x客户端软件的具体实现。针对windows xp系统，我们将对supplicant backend 状态机所进行的一些修改，来认识微软公司对其客户端所进行的修改。

 

       802.1x定义了很多种类型的状态机，包括：TIMER、AUTHENTICATOR、SUPPLICANT、REAUTHENTICATION、CONTROLLED DIRECTION等，今天我们只讨论SUPPLICANT的BACKEND状态机所进行的一些部分修改。

 

       使用过windows xp自带802.1x验证客户端的都知道，该客户端集成在网络连接中，用户无法通过类似“AUTHENTICATION”按钮主动发起认证。验证过程需要通过交换机发出的EAP-IDENTITY REQUEST报文来触发。为了适应微软客户端的这个特点，各个交换机厂家在其交换机上设计了组播触发功能及DHCP触发功能。

 

       所谓组播触发功能，就是开启了802.1x功能的交换机，会周期性主动向端口发送EAP-IDENTITY REQUEST报文，由于该报文的目的地址是01-80-c2-00-00-03，属于组播MAC的范围，因此通常将该功能叫做组播触发。如下图所示，在802.1x-2001规范时，微软的客户端在收到该报文后，会弹出一个用户名密码输入界面（UI界面），用户可以在此输入用户名及密码，然后完成验证，此时状态机处于REQUEST状态。

 

       很明显，如果交换机不主动发出这个报文，那么用户将没有机会输入用户名及密码，也就无法完成802.1x的身份验证过程。

 

       一次典型的组播触发过程如下：

      （1）PC<----EAP-IDENTITY REQUEST<----SWITCH，交换机进行组播触发

       弹出UI界面等待用户输入正确的用户名及密码

      （2）PC---->EAP-IDENTITY RESPONSE---->SWITCH，客户端进行响应，将身份信息发给交换机

       交换机检测到该报文，说明用户希望上线

      （3）PC<----EAP-IDENTITY REQUEST<----SWITCH，交换机建立该用户的相关信息，并再次向用户发出请求

      （4）PC---->EAP-IDENTITY RESPONSE---->SWITCH，客户端立即进行响应，将身份信息发给交换机，此时不会再弹出UI界面，用户不需再次输入用户名密码

      （5）PC<----EAP-MD5 CHALLENGE REQUEST<----SWITCH，交换机向客户端发出挑战报文，继续验证过程

      （6）PC---->EAP-MD5 CHALLENGE RESPONSE---->SWITCH，客户端回应挑战报文

      交换机根据这些信息完成AAA验证，如果验证成功，则向用户回应成功报文。

      （7）PC<----EAP-SUCCESS<----SWITCH，验证成功，用户上线。

 

       与此类似，DHCP触发功能完成的也是类似的功能。当用户采用DHCP方式动态获取IP地址时，会向交换机发出DHCP DISCOVER报文，交换机收到该报文后，知道用户已经开机，需要上线完成身份认证，因此主动向连着该用户PC的端口发出EAP-IDENTITY REQUEST报文，同样，xp收到该报文后也会弹出用户名密码窗口。验证过程与上面七步基本一样，只需要在第一步前增加一步：PC---->DHCP DISCOVER---->SWITCH，其它过程是完全一样的。

 

       与组播触发不同的是，组播触发是交换机周期性向使能了802.1x功能的端口发送EAP-IDENTITY REQUEST报文，此时对应的端口下可能并没有希望上线认证的用户，因此其目的MAC为上述提到的BPDU MAC；而通过DHCP触发的认证请求，交换机已经明确知道用户的MAC地址，因此该EAP-IDENTITY REQUEST报文为单播报文。

 

       在windows xp sp2之前，这种设计是有益的。如果没有这样的设计，交换机将无法与微软的验证客户端配合使用。

 

       在用户输入正确的用户名及密码之后，PC向交换机发送EAP-IDENTITY RESPONSE报文。该报文携带了用户的身份信息。从下图我们看到，在802.1x-2001规范中，这时状态机处于RESPONSE状态，我们注意到，在这个状态下，如果再次收到EAP-IDENTITY REQUEST报文（图中aReq），状态会再次变迁到REQUEST状态。

 

 

 

 

 

 

        从windows xp sp3开始，微软的验证客户端进行了修改，这主要也是为了适应802.1x-2004规范。我们注意到（如下图），从RESPONSE状态已经无法直接回到REQUEST状态。而且，微软对收到EAP-IDENTITY REQUEST 报文有了更明确的处理原则（在xp sp3版本之前并无此约定）：无论何时（除了已经保存了用户名密码信息之外），只要收到EAP-IDENTITY REQUEST报文，都需要弹出UI界面，提示用户输入用户名及密码。

 

       微软这种改变有什么好处吗？原来，在xp sp2时，即使收到EAP-IDENTITY REQUEST报文，通常只会在第一次弹出UI界面，如果用户在此次验证过程中失败，此后会根据EAP-IDENTITY REQUEST随机性地弹出该UI界面，这样对于用户来说，感觉就是微软的的密码界面很难控制，不知道究竟什么时候会弹出，很多用户因此会无所适从。有时需要将网线从端口上拔出或禁用并重新启用网络连接才能再次弹出UI界面以完成验证过程。这种设计给用户造成了很大的困扰。

 

       802.1x-2001规范对于有初始用户界面，主动发起EAP-START报文的客户端来说并没有什么问题，但是对于像微软这样的设计，就比较难以满足要求了，802.1x-2004对此进行了修改，此修改并不会影响其它第三方有初始用户界面的客户端。但对于微软验证客户端却意义重大。

 

      按此修改的xp sp3不再会有用户找不到用户名密码输入窗的窘况。

 

 

 

 

        这种修改意味着交换机组播触发及DHCP触发功能的终结。从windows xp sp3开始，为了适应微软客户端而专门设计的这些功能也将失去了意义。而且，如果用户使用xp sp3验证客户端，交换机同时开启了组播触发功能，还会对验证流程产生不利的影响。在前面的博文：windows xp sp3 新版802.1x客户端默认属性改变引起的认证失败，已经有描述，这里不再详述。