联想的认证协议是我写的这几个802.1x实现里面相对简单的版本,没有太多古古怪怪的信息头信息尾部。 我们学校并没有使用过联想协议的认证系统,而是受了一位网友的邀请才写的,所以我连联想官方客户端的样子都没看到过,一直是由那网友抓包后发送过来,而我猜测地将其套入到此前我写的神州数码的认证程序里面,经过几天的调试,确实能用,虽然并不完全了解认证报文的每个细节。 PT实现的联想Linux客户端项目主页:http://code.google.com/p/zlevoclient/ 以下的说明是基于EAP协议过程的补充描述,如果不清楚EAP,可先读深入了解校园网802.1x认证的EAP协议(1)——EAP的总体流程。 认证过程报文的细节描述: EAPOL-Start、EAPOL-Logoff设置长度为0的协议包头,然后紧接6个意义不明的字节(可能是版本号之类),直接复制即可: {0x00, 0x00, 0x2f, 0xfc, 0x03, 0x00}; EAP-RESPONSE-Identity长度为5(头部) + username_length,无特别,跟EAP标准一致, EAP-RESPONSE-MD5_Challenge长度为6(头部) + 16(MD5值) + username_length,在MD5值之后,先紧接用户名,然后是4字节的本机IP地址,以及9个意义不明的字节,直接复制:{0x00, 0x00, 0x2f, 0xfc, 0x00, 0x03, 0x01, 0x01, 0x00}; EAPOL-KEEP-ALIVE当认证成功后,需要每60秒发送一次该报文,否则会断线;该报文的b:EAPOL 报文类型为0xFC,帧长值为12,其携带信息的前8字节在实际中似乎是随机变化,找不出其规律,不过实际上全部设0也可;后4字节则是本机IP。 在部分版本中,如吉林大学珠海学院,每隔5分钟(可能就在第五个EAPOL-KEEP-ALIVE发出之后)服务器会重新发来EAP-REQUEST-Identity,程序需要正确应答,特别要设置各个应答报文中的e:EAP通信id。 关于服务器返回的数据包,Success和Failure通常包含有中文编码的信息,标志是,EAP报文结束后,紧接0x00002ffc(大概0x18、0x19),其后接着是一个字节的报文长度,再后就是gb2312编码的中文信息。 由于协助我测试的湖南人文科技学院的网友他们的系统是纯手工设置网卡IP的,所以我也不清楚是否有像其他品牌的协议那样有动态静态IP位之类的信息位,如果发现这个版本的程序不能通过认证,可以自己抓包分析,或邮件联系PT。
zRuijie4GZHU Google Code:http://code.google.com/p/zruijie4gzhu/ 其实这个项目的目标不是非常明确,至少到目前为止,能在Linux下的使用的锐捷兼容客户端已经有mystar、 ruijieclient、mentoHust(还有很多,单纯Google Code上以“锐捷”为标签的就一堆了……),还有基于QT、pygtk开发的图形界面程序,可谓百花齐放,再开发一个版本出来理由似乎不太充分,只是为了一些美中不足:比如最有实力的mentoHust,其能支持到锐捷最新的3.7版本的协议,却不是开源方案;mystar则是年久失修,已经不能兼容现在的协议(不过其留下的代码让后来的开发者得到很大的指引,在此对作者Rijndael&byhh表示敬意);至于此前一直使用的Ruijieclient,其实也有点问题,一直掉线,查看上网明细,每次在线都只有1分29秒就被踢了,说明协议兼容问题。虽说Ruijieclient有“智能重连”功能,但是重连跟掉线是两回事,不能说会重连就说解决了掉线问题,花心思研究协议才是正道。 也许也就在于类似问题的出发点不同吧,虽然PT加入了Ruijieclient的项目,但一直没有参加过代码开发,毕竟一提出任何意见就互相反对的人之间很难合作,所以考完试后就花了一天时间,把锐捷协议移植到PT的“z-框架”下。虽然分析下来这个兼容问题是小事情,就是所谓的serial number的初始值以及success key的提取位不对,不过我实在不喜欢Ruijieclient的框架了,而且对自己熟悉的“z-框架”代码维护起来有快感的多。 “z-框架”是指PT依次开发神州数码、联想、锐捷几个客户端一直沿用下来的一些模式,所以zRuijie4GZHU的代码理论上跟其他锐捷相关程序是没什么相似的。除了从mystar里面沿用过来的两个数组照样copy外,PT把mystar开发时候通过反汇编得出来的Alog、Blog算法函数都重写了一次,比原来汇编式的代码的效率和可读性要高得多(分析过程中发现原来有几行的代码是多余的),两个函数摘抄在本文后面,希望对其他的锐捷开发者有用。 zRuijie4GZHU的目标应该跟Ruijieclient这些不同,Ruijieclient是面向通用的锐捷协议,要做到全球通用其实难度不小的,而zRuijie4GZHU,也正如其名,是为广州大学的锐捷而兼容的,如果能在其他学校使用,那估计是意外。 PT的开发理念是K.I.S.S,zRuijie4GZHU没有什么复杂概念,比如DHCP,只有是和不是DHCP模式,没有什么0、1、2、3模式,更没有配置文件,软件是执行文件和脚本的统一体,缺一不可。 OK,有需要的用户可以查看项目wiki的用户手册吧,下面是PT改写的锐捷Ablog和Blog算法函数: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 /* * [...]
各地的校园网认证有很多种品牌,正因为EAP可扩展的特点,基本上每个品牌的认证方案都会互不相同。从商业角度考虑,当使用了某个品牌的认证系统后,很可能就不能使用其他牌子的交换机了;而对用户来说,这不仅带来了以后维护的问题,还因为各个厂商开发的EAP客户端的投入不同,质量良莠不齐,占用内存大、限制多(比如有些为了防止用户开代理,加入多网卡检测,结果用户就不能使用虚拟机、手机GPRS Modem等)、不支持非Win平台。 这就是我们研究这些厂商自定义的EAP协议的意义。 PT实现的神州数码Linux客户端项目主页:http://code.google.com/p/zdcclient/ 以下的说明是基于EAP协议过程的补充描述,如果不清楚EAP,可先读深入了解校园网802.1x认证的EAP协议(1)——EAP的总体流程。 神州数码的私有信息尾结构神州数码协议里面最特别的地方是有一段46字节的信息,其位于EAP报文后,属于EAPOL报文的尾端部分,在发往服务器的EAP_RESPONSE_IDENTITY和EAP_RESPONSE_MD5_Challenge两种报文里面都需要附上该46字节的信息以供验证。
EAP(Extensible Authentication Protocol),是一个普遍使用的认证机制,详细介绍可见Wikipedia。本文介绍的,是被广泛使用在国内高校校园网的认证机制使用的EAP协议,暂不具体地说明某个品牌的私有协议如何如何,而是从整体角度看EAP协议如何工作,从一个第三方Supplicant客户端的开发者角度解释EAP的通信机制。在后续的章节将继续介绍PT接触过的几种认证协议中,国内的“标准践踏者们”如何实现各种变态的认证协议。 文中出现的术语和名词,基本参考了RFC 3748的相关描述,以及Wireshark软件对相关报文的解释用词。 认证过程简述: 主机向服务器(多播或广播地址)发送EAPOL-Start 服务器向主机发送EAP-REQUEST-Identity要求验证身份的请求 主机向服务器发送EAP-RESPONSE-Identity回应 服务器向主机发送EAP-REQUEST-MD5_Challenge要求验证密码的MD5校验值 主机向服务器发送EAP-RESPONSE-MD5_Challenge回应 服务器向主机发送EAP-Success 保持连接的通信... 当然这只是一般过程,如果在任何时候服务器发来EAP-Failure数据包,都表示整个认证过程终止。 Supplicant主机 服务器 ----------- ------------- |------------------------------>| | 1. EAPOL-Start | | | |<------------------------------| | 2. EAP-REQUEST-Identity | | | |------------------------------>| | 3. EAP-RESPONSE-Identity | | | |<------------------------------| | 4. EAP-REQUEST-MD5_Challenge | | | |------------------------------>| | 5. EAP-RESPONSE-MD5_Challenge | | | |<------------------------------| [...]
Page optimized by WP Minify WordPress Plugin