还剩102页未读，继续阅读
本资源只提供10页预览，全部文档请下载后查看！喜欢就下载吧，查找使用更方便
文本内容:
3.无线局域网安全认证技术
3.1安全认证整体综述作为一种公共移动数据接入方式，PWLAN（公共无线局域网）的安全问题成为商业用户最关心的问题，包括合法用户身份信息假冒的安全，敏感商业信息的安全，防止黑客的攻击等等，成为影响人们使用PWLAN业务信心的关键问题目前无线局域网在全球快速发展，网络建设所采用的方法也都不尽相同，在某种程度上可以说是混乱的，在公共区域中尤为如此根据Wi-Fi联盟的资料显示，目前最普遍接入方式是基于浏览器认证，亦称作通用接入方法（UAM）通过浏览器认证，接入控制器将用户的浏览器重定位到一个本地Web服务器，其过程受TLS保护用户到UAM登陆页面进行身份认证，在发送到Web服务器的表格中输入用户名和密码这种方法的显著优点是配置简单，并且事实上移动用户只需支持Web浏览就可以访问接入系统虽然UAM简单并且易于采用，它有一些严重的缺陷1）用户的经验若用户的目的是使用诸如e-mail客户端的其它一些应用程序，进行网络访问的第一步，也就是打开浏览器，就并不习惯2）企业用户经常需要进行VPN的配置，这与访问一个本地的Web服务器是相冲突的3典型的，UAM把用户的认证信息暴露给所访问网络的Web服务器这一特征对于不愿暴露用户数据库的运营商而言是无法接受的，即使是暴露给合法的漫游伙伴4）除非用户手工检查服务器使用的证书以保护页面（用户极少这样做），用户的认证信息可能在不经意间透露给一个运行恶意无线接入点（AP）的攻击者开发接入控制器，就是为了解决PWLAN在安全认证方面的缺陷和弱点，针对PWLAN目前的现状，它背负着三大研究主题
3.
1.1三大主题
3.
1.
1.1实现WPA以及从UAM到WPA的平滑过渡技术是开发接入控制器的主题之一从最初利用ESSID、MAC限制，防止非法无线设备入侵的访问控制，到基于WEP数据加密的解决方案，再到预定为去年年底发布的
802.11i，以及从2003年12月1日起我国开始施行的WLAN产品的新标准WAPI（无线局域网鉴别和保密基础结构），无线业界一直致力于WLAN的安全性提高方面的工作那么，这么多的安全方案该采用哪种呢，下面我们具体讨论当前各种安全方案的特点1）业务组标识符（BSSID）这是人们最早使用的一种安全认证方式，即为无线接入点AP设置BSSID，强迫无线终端接入固定SSID的AP来实现接入控制2）MAC地址过滤这是一种很常用的接入控制技术，在运营商铺设的有线网络中也经常使用，即AP只允许有合法MAC地址终端接入3）有线等价安全（WEP）WEP协议是IEEE
802.11标准中提出的认证加密方法它使用RC4流密码来保证数据的保密性，通过共享密钥来实现认证，理论上增加了网络侦听，会话截获等的攻击难度4PPPoE认证PPPoE是目前使用最多的一种认证技术它的用户认证方式主要包括PAP和CHAP两种，利用明文或弱加密的方式传送口令，不适用于开放的无线环境5DHCP+WEB认证此为基于应用层的认证方式，通过http协议获取用户输入的用户名和密码，无须专门安装客户端软件，应用范围广用户名和密码以明文（采用http
1.0）或弱加密采用http
1.1中的MD5算法方法传输
6802.1x协议IEEE
802.1X协议，称为基于端口的访问控制协议（PortBasedNetworkAccessControlProtocol）是由IEEE于2001年6月提出的，符合IEEE802协议集的局域网接入控制协议，主要目的是为了解决无线局域网用户的接入认证问题，能够在利用IEEE802局域网优势的基础上提供一种对连接到局域网用户的认证和授权手段，达到接受合法用户接入，保护网络安全的目的
802.1x协议旗下的认证方式有很多种，其中大部分的认证协议支持STA和AS的相互认证，AP的身份认证由AP和AS之间设定的共享密钥完成是目前厂家支持和应用范围最广的安全认证协议7WAPI（WLANAuthenticationandPrivacyInfrastructure）中国在2003年5月份提出的无线局域网国家标准GB
15629.11这种安全机制由WAI（WLANAuthenticationInfrastructure）和WPI（WLANPrivacyInfrastruc－ture）两部分组成，WAI和WPI分别实现对用户身份的鉴别和对传输的数据加密WAI是建筑在公钥体系上的，STA和AP均需要配置公钥证书，ASU（AuthenticationServiceUnit）是证书的颁发和核实机构，也就是说，WAI实现了STA和AP的互相认证作为PWLAN来说，除了在安全方面的考量之外，面对公众的网络中用户使用的简单和容易管理也是十分重要的，这也是为什么大家公认的安全认证TLS不能被广泛接受的原因，因为证书的管理是一项烦人的工作，而强口令认证虽然安全性差，但是用户使用度却高另外，和GPRS移动网络融合的重要性（下面将会谈到），决定了SIM认证在PWLAN中的地位因此本项目考虑了以上因素，提出在接入控制器中使用WPA安全协议，它采用
802.1x为认证接入方法，AES（高级加密标准）为加密方式，是即将公布的
802.11i安全标准的子集
3.
1.
1.2实现与各类运营商后台认证系统之间的认证、授权、计费兼容是开发接入控制器的主题之二目前所采用的接入控制系统的端到端体系结构中存在一些矛盾，矛盾产生的原因是当今的经营商所用的不同的AAA后台例如，宽带接入网自然地使用RADIUS服务器，而（GSM/GPRS）蜂窝网与基于SS7的后台交互PWLAN的部署以热点地区为主，提供局部的高速数据接入，而现有的移动网络如GPRS在全国范围内部署，提供广域的窄带数据接入，因此实现WLAN和移动网络的融合，支持移动终端设备在不同移动网络之间的无缝漫游和切换而不中断已有的数据连接成为移动运营商们发展移动数据业务的亮点，必将增强移动运营商和用户开展和使用移动数据业务的弹性和自由度目前移动网络已经具有了成熟的漫游支持体系结构，拥有大量的移动用户群，所以实现WLAN和移动网络的融合将有利于PWLAN业务使用现有移动网络资源同时，对于用户来说，自从使用GSM开始，移动用户已经适应了使用SIM卡（包括后来CDMA的UIM卡）作为用户身份标志，开机上网感觉不到接入网络认证和授权过程的移动通信体验因此使用SIM卡认证实现公共接入，不但在STA端实现了简单易用，最重要的是能够充分利用的移动网络的AAA后台目前PWLAN和GPRS融合的SIM认证方式有两种，一种是手机＋密码认证方式（虚拟SIM认证方式），另一种是在
802.1x协议之上的EAP－SIM认证方式前者即用户以手机号码作为帐号，通过短消息或1860申请上网密码登陆时输入手机号码和密码即可上网，上网费用记在申请业务的手机帐号上后者则是用户将SIM卡放入SIM读卡器或者WLAN上网卡的SIM卡插槽中，登陆时不用输入用户名和密码，只需通过SIM卡中的有关信息进行认证，费用计入该SIM卡中
3.
1.
1.3实现与RSN接入点与非RSN接入点兼容是开发接入控制器的主题之三为兼容RSN及非RSN接入点设备，接入控制器EAP认证包含二种方式1）EAP终结方式EAP报文在接入控制器上被终结，EAP报文中的认证信息被提取出来之后，封装成标准Radius报文，并送到Radius服务器;2EAP透传方式接入控制器不对EAP认证报文进行特殊处理，直接送到Radius服务器认证；方式一中接入控制器作为认证者，直接和认证服务器进行认证信息交互方式二中接入控制器作为透传者，将认证信息发送给作为认证者的设备，此时只实现对用户的控制
3.
2802.1x协议
3.
2.
1802.1x协议综述
3.
2.
1.
1802.1x提出背景有线局域网通过固定线路连接组建，计算机终端通过网络接入固定位置物理端口，实现局域网接入，这里没有直接控制到端口的方法，也不需要控制到端口，这些固定位置的物理端口构成有线局域网的封闭物理空间但是，由于无线局域网的网络空间具有开放性和终端可移动性，因此很难通过网络物理空间来界定终端是否属于该网络随着无线局域网的广泛应用，如何通过端口认证来实现用户级的接入控制就成为一项非常现实的问题
802.1X正是基于这一需求而出现的一种认证技术，也就是说，对于有线局域网，该项认证没有存在的意义IEEE
802.1X协议，称为基于端口的访问控制协议（PortBasedNetworkAccessControlProtocol）是由IEEE于2001年6月提出的，符合IEEE802协议集的局域网接入控制协议，主要目的是为了解决无线局域网用户的接入认证问题，能够在利用IEEE802局域网优势的基础上提供一种对连接到局域网用户的认证和授权手段，达到接受合法用户接入，保护网络安全的目的目前，IEEE
802.1X认证协议作为业界最新的标准认证协议已经得到了很多网络设备制造商的重视，Cisco、3Com、Avaya、D-Link等纷纷组织研发力量进行基于
802.1X协议相关产品的开发作为软件厂商，微软在WindowsXP中已经整合了IEEE
802.1X客户端软件，无需要另外安装客户端软件
3.
2.
1.
2802.1x的体系结构IEEE
802.1X协议的体系结构包括三个重要的部分客户端（SupplicantSystem）、认证系统（AuthenticatorSystem）、认证服务器（AuthenticationServerSystem）客户端系统，称作申请者，一般为一个用户终端系统，该终端系统通常要安装一个客户端软件，当用户有上网需求时，通过启动这个客户端软件发起IEEE
802.1X协议的认证过程为了支持基于端口的接入控制，客户端系统需支持EAPOL协议认证系统，称作认证者，在WLAN中就是无线接入点（wirelessaccesspoint），在认证过程中只起到透传的功能，所有的认证工作在申请和认证服务器上完成认证服务器，通常采用远程接入用户认证服务（RemoteAuthenticationDial-InService，RADIUS）的服务器，该服务器可以存储有关用户的信息，通过检验客户端发送来的信息来判别用户是否有权使用网络系统提供的网络服务
802.1X标准采用现有的认证协议，即IETF提出的PPP协议的扩展----EAP（ExtensibleAuthenticationProtocol，可扩展认证协议，详见
3.5），EAP消息包含在
802.1X消息中，被称为EAPOL，即EAPoverLAN（在无线局域网中称作EAPOW，也就是EAPoverWireless），在申请者和认证者之间传输；Authenticator与AuthenticationSever间同样运行EAP协议，EAP帧中封装了认证数据，将该协议承载在其他高层次协议中，如Radius，以便穿越复杂的网络到达认证服务器（EAPRelay），称为EAPoverRADIUS图
3.
2.
1.
2.1是对
802.1X协议体系结构的生动描述图
3.
2.
1.
2.
1802.1X的体系结构认证系统和认证服务器之间的通信可以通过网络实体进行，也可以使用其他的通信通道，例如认证系统和认证服务器集成在一起，二个实体之间的通信就可以不采用EAP协议
3.
2.2端口控制原理
3.
2.
2.1逻辑端口的概念认证者对应于不同用户的端口（可以是物理端口，也可以是用户设备的MAC地址、VLAN、IP等）有两个逻辑端口控制端口（controlledport）和非控制端口（uncontrolledport）非控制端口始终处于双向连通的状态，不管是否处于授权状态都允许申请者和局域网中的其他机器进行数据交换，主要用来传递EAPOL协议帧，可保证随时接受客户端发出的认证EAPOL报文；控制端口只有在认证通过的状态下才打开，用于传递网络资源和服务，控制端口可配置为双向受控和仅输入受控两种方式，以适应不同的应用环境值得注意的是，在IEEE
802.1X协议中的“控制端口”和“非控制端口”是逻辑上的理解，设备内部并不存在这样的物理开关对每个用户而言，IEEE
802.1X协议均为其建立一条逻辑的认证通道，该逻辑通道其他用户无法使用，不存在端口打开后被其他用户利用的问题这里所说的端口是一个逻辑上的广义端口的概念的统称，并非单指物理端口，应该包含有物理端口、MAC、VLAN、IP等识别用户或用户群的标识
3.
2.
2.2端口控制原理逻辑端口有三种控制状态（参数AuthControlledPortControl），端口的控制状态决定了客户端是否能接入网络1ForceAuthorized强开，端口一直维持授权状态；2ForceUnauthorized强关，端口一直维持未授权状态；3Auto激活
802.1X，初始设置端口为未授权状态，并通知设备管理模块需要进行端口认证，这也是缺省值，后面的讨论都默认是该状态当客户机尝试连接至AP时控制端口被强制进入非授权状态，（unauthorized），在该状态下，除了
802.1X报文外不允许任何业务输入、输出当客户通过认证后，端口状态切换到授权状态（authorized），允许客户端通过端口进行正常通信，可以进行如DHCP、HTTP、FTP、SMTP、POP3等协议数据的传输图
3.
2.
2.
2.1说明了
802.1X端口控制原理由此可见，
802.1X的认证过程，就是控制系统的
802.1X逻辑端口认证状态的过程图
3.
2.
2.
2.
1802.1x端口控制原理结构示意图
3.
2.3协议实现的状态机
802.1X协议一共描述了8个状态机端口定时器状态机，认证者状态机，传输密钥状态机，重认证定时器状态机，后端服务器状态机，受控方向状态机，客户端状态机，接收密钥状态机Supplicant和Authenticator所需要实现的状态机是不同的下面的表格中列出了Supplicant和Authenticator的状态机实现规定表
3.
2.
3.1supplicant和Authenticator实现的状态机SupplicantAuthenticatorPortTimers状态机SuplicantPAE状态机SupplicantKeyTransmit状态机KeyReceive状态机PortTimers状态机AuthenticatorPAE状态机ReauthenticationTimer状态机ControlledDirections状态机AuthenticatorKeyTransmit状态机BackendAuthentication状态机KeyReceive状态机下面一一说明其中最重要的三个状态机
3.
2.
3.1Supplicant状态机图
3.
2.
3.
1.1申请者supplicant的状态机从图中可以看到，客户端的状态机一共有LOGOFF退出、DISCONNECTED（未连接）、CONNECTING（连接中）、AUTHENTICATING（认证中）、ACQUIRED（质询）、AUTHENTICATED（已认证）和HELD（保持）七个状态，实现的关键是如何根据条件判断Supplicant或Authenticator所处状态的转移下面的状态机也是如此
3.
2.
3.2Authenticator的状态机图
3.
2.
3.
2.1认证者Authenticator的状态机
3.
2.
3.3后端服务器的状态机图
3.
2.
3.
3.1后端服务器的状态机
3.3证书管理
3.
3.1证书技术初识数字证书就是标志网络用户身份信息的一系列数据，用来在网络通讯中识别通讯各方的身份，即要在Internet上解决我是谁的问题，就如同现实中我们每一个人都要拥有一张证明个人身份的身份证或驾驶执照一样，以表明我们的身份或某种资格 数字证书是由权威公正的第三方机构即CA中心签发的，以数字证书为核心的加密技术可以对网络上传输的信息进行加密和解密、数字签名和签名验证，确保网上传递信息的机密性、完整性，以及交易实体身份的真实性，签名信息的不可否认性，从而保障网络应用的安全性 数字证书采用公钥密码体制，即利用一对互相匹配的密钥进行加密、解密每个用户拥有一把仅为本人所掌握的私有密钥（私钥），用它进行解密和签名；同时拥有一把公共密钥（公钥）并可以对外公开，用于加密和验证签名当发送一份保密文件时，发送方使用接收方的公钥对数据加密，而接收方则使用自己的私钥解密，这样，信息就可以安全无误地到达目的地了，即使被第三方截获，由于没有相应的私钥，也无法进行解密通过数字的手段保证加密过程是一个不可逆过程，即只有用私有密钥才能解密在公开密钥密码体制中，常用的一种是RSA体制 用户也可以采用自己的私钥对信息加以处理，由于密钥仅为本人所有，这样就产生了别人无法生成的文件，也就形成了数字签名采用数字签名，能够确认以下两点1）保证信息是由签名者自己签名发送的，签名者不能否认或难以否认；2）保证信息自签发后到收到为止未曾作过任何修改，签发的文件是真实文件 数字证书可用于发送安全电子邮件、访问安全站点、网上证券、网上招标采购、网上签约、网上办公、网上缴费、网上税务等网上安全电子事务处理和安全电子交易活动数字证书的格式一般采用X.509国际标准由于证书能够严谨的标识个人身份，因此它被引用到了安全认证方法中来，较强口令而言，证书的保密性，数据的完整性，用户身份的确定性和不可否认性使得基于证书的认证具有更高的安全可靠性，下面就对证书作个详细的介绍，以及如何生成证书
3.
3.2证书在安全认证中的作用本项目中关于的认证的三种方法EAP－TLS，EAP－TTLS，EAP－PEAP，都引用了证书作为认证中所必须的一种信息表
3.
3.
2.1证书在不同认证方法中的作用认证证书的作用EAP－TLS客户端和认证服务器端均需要证书，用来验证彼此身份EAP－TTLS认证服务器端需要证书，用来验证服务器的身份，EAP－PEAP认证服务器端需要证书，用来验证服务器的身份，
3.
3.3证书的格式目前国际上通用的证书格式为X.509格式X.509定义了一个由X.500目录向它的用户提供的鉴别服务框架每个证书包含用户的公开密钥和用可信证书权威机构私人密钥的签名X.509定义了基于使用公开密钥证书的可选鉴别协议X.509是一个重要的标准，在X.509中定义的证书结构和鉴别协议已有了广泛的应用X.509最早于1988年发布，1993年发布了一个修订后的建议书，1995年又起草了第三版X.509基于公开密钥加密和数字签名一个可信的证书机关（CA）给每个用户分配一个唯一的名字并签发一个包含名字和用户公开密钥的证书X.509方案的核心是与每个用户联系的公开密钥证书这些用户证书采取由某些可信证书权威机构（CA）创建，由CA或用户放在目录中X.509v3证书基本字段的基本语法如下Certificate::=SEQUENCE{tbsCertificateTBSCertificate，主题和发行者的名字，与主题相联系的公开密钥，有效期和其他相关信息signatureAlgorithmAlgorithmIdentifier，含有CA签发证书使用的密码学算法标识符，必须含有与序列tbsCertificate中签名字段算法标识符同样的算法标识符signatureValueBITSTRING包括对tbsCertificate的ASN.1DER编码的数字签名，这个签名结果值然后作为BITSTRING类型的ASN.1编码，并且包括在证书的签名字段中，CA能证明在tbsCertificate字段中信息的有效性}TBSCertificate::=SEQUENCE{version
[0]EXPLICITVersionDEFAULTv1，版本字段，用于识别证书格式使用扩展时用X.509v3（值是2）；但若无扩展项，UniqueIdentifier将存在，这时使用X.509v2（值是1）；如果仅仅基本字段存在，使用版本1（版本号将在证书中删掉）serialNumberCertificateSerialNumber，CA给每一个证书分配一个序列号，CA签发的证书唯一识别signatureAlgorithmIdentifier，含有与序列CertificatesignatureAlgorithm字段同样的算法标识符issuerName，发行者字段必须含有一非空的能辨别出的名字（DN），也就是CA的名称validityValidity，时间间隔，日期证书有效期开始（notBefore）和日期证书有效期结束（notAfter）subjectName，标识，与存储在主体公开密钥字段中的公开密钥相关联的实体，也就是用户名subjectPublicKeyInfoSubjectPublicKeyInfo，携带公开密钥和密钥使用算法的标识符issuerUniqueID
[1]IMPLICITUniqueIdentifierOPTIONAL，--Ifpresent，versionshallbev2orv3subjectUniqueID
[2]IMPLICITUniqueIdentifierOPTIONAL，--Ifpresent，versionshallbev2orv3extensions
[3]EXPLICITExtensionsOPTIONAL--Ifpresent，versionshallbev3}Version::=INTEGER{v1
（0），v2
（1），v3
（2）}CertificateSerialNumber::=INTEGERValidity::=SEQUENCE{notBeforeTime，notAfterTime}Time::=CHOICE{utcTimeUTCTime，generalTimeGeneralizedTime}UniqueIdentifier::=BITSTRINGSubjectPublicKeyInfo::=SEQUENCE{algorithmAlgorithmIdentifier，subjectPublicKeyBITSTRING}Extensions::=SEQUENCESIZE（
1..MAX）OFExtensionExtension::=SEQUENCE{extnIDOBJECTIDENTIFIER，criticalBOOLEANDEFAULTFALSE，extnValueOCTETSTRING}
3.
3.4证书的生成该部分内容请参看客户端实现部分
3.4WEB认证（UAM）
3.5EAP可扩展认证协议
3.
5.1EAP认证方式综述可扩展认证协议EAP是PPP（Point-to-PointProtocol）认证中的一个通用协议，特点是EAP在链路控制阶段（LinkControlProtocol，LCP）没有选定一种认证机制，而把这一步推迟到认证阶段顾名思义，EAP可以支持多种认证机制，允许使用一个“后端”服务器来实际实现各种认证机制，认证者仅需要传送认证信息EAP协议本身具有良好的可扩展性，这使得在添加新的认证机制时丝毫不会影响现有实现的继续使用
3.
5.
1.1EAP认证过程简述EAP认证过程简述如下1在链路建立阶段完成后，认证者发送一个或多个请求（Request）数据包来对对方进行认证，该数据包中有一个类型域表明请求的类型2对方发送一个响应（Response）数据包对每一个请求做出应答响应包中的类型域与请求包中的类型域对应3认证者发送一个成功（Success）或失败（Failure）数据包结束认证阶段
3.
5.
1.1EAP特点可扩展认证协议EAP提供了灵活的链路层安全结构，特点包括1简单封装协议不依赖于IP、ACK/NAK无滑动窗结构、不采用分组，因此操作简单；2可以运行在任何链路层之上（PPP、
802.
3、
802.
5、
802.11等），具有良好的适用性；3EAP采用高层认证技术，并且支持多种IETF安全协议标准（TLS、IKE、GSS-API等），4从而降低了链路层运算资源在安全上的开销；5可方便的扩展支持未来的认证协议（如DIAMETER），具有良好的可扩展性；6可以运行于有损或无损媒体之上，包括无线媒体EAP可以应用于以下几个地方EAP/PPP，EAPOL，EAP/RADIUS，EAP/Diameter，COPS访问PIB
3.
5.2EAP协议在
802.1x中的应用
3.
5.
2.1EAPOL消息的交互过程EAP消息封装在
802.1X消息中，称作是EAPOLEAPOL并没有一个固定的交互模式，下面以申请者发起的一次性口令认证为例说明大多数情况采用的EAPOL消息的交互过程图
3.
5.
2.
1.1申请者发起的一次性口令认证如图所示，在申请者和认证者之间传输的EAPOL消息用实线表示，承载于高层协议的EAP消息用虚线表示，也可以看出，认证者完成EAP消息的重新封装（re-packaging）来传输认证消息根据采取的不同认证方法，质询（challenge）消息的数量和内容会有所不同，当申请者收到EAP-Success消息，说明认证成功可以接入LAN了
3.
5.
2.2EAPOL消息的封装EAPOL数据包的格式在
802.1X协议中规定，格式如图
3.
1.4所示02346-NPAEEthernettypeProtocolversionTypeLengthPacketBody图
3.
5.
2.
2.1EAPOL数据包格式PAEEthernettype88-8E；Protocolversion01；Type:PacketType包含有以下五种EAP-Packet00，认证信息帧，用于承载认证信息；EAPOL-Start01，认证发起帧；EAPOL-Logoff02，退出请求帧；EAPOL-Key03，密钥信息帧；EAPOL-Encapsulated-ASF-Alert04，用于支持ASF（AlertStandardForum）的Alerting消息；Length PacketBodyLength表示数据长度，也就是EAP包的长度，如果为0表示没有后面的数据域（比如EAPOL-Start和EAPOL-Logoff类型的包）；PacketBody根据不同的Type有不同的内容；其中EAPOL-Start，EAPOL-Logoff和EAPOL-Key仅在Supplicant和Authenticator间存在，在认证者和认证服务器间，EAP-Packet报文重新封装承载于Radius协议之上，以便穿越复杂的网络到达认证服务器EAPOL-Encapsulated-ASF-Alert封装与网管相关信息，例如各种告警信息，由Authenticator终结
3.
5.
2.3EAP数据包的封装EAP数据包的格式当EAPOL数据包Type域为EAP-Packet时，PacketBody为EAP数据包结构，这一结构在RFC2284PPPExtensionalAuthenticationProtocol中定义，如图
3.
1.5所示0124-NCodeIdentifierLengthData图
3.
5.
2.
3.1EAP数据包格式Code指明EAP包的类型，一共有4种Request1，请求包Response2，响应包Success3，成功包Failure4，失败包Identifier辅助进行Response和Request消息的匹配；Length EAP包的长度，包含Code、Identifier、Length和Data域的全部内容超出Length域范围的字节应该视为数据链路层填充（padding）在接收时应该被忽略掉Data由Code域决定1）Success和Failure Success数据包由认证者发送给对方，以确认认证成功认证者必须发送一个Code域为3的EAP数据包（即Success）如果认证者不能为对方进行认证（给一个或多个Request发送“不可接受”Response）则实现必须发送一个Code域为4的EAP数据包（即Failure）认证者可能希望在发送Failure之前发送几个Request以顾及到人为地打字错误实现须知因为Success和Failure数据包不被确认，所以它们有可能丢失对方必须顾及到这种情况对方可以用一个网络协议数据包（NetworkProtocolpacket）来作为可选的Success的暗示同样，收到LCPTerminate-Request可以视为收到FailureSuccess和Failure数据包的格式如下所示传输时各域从左到右依次进行012301234567890123456789012345678901+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|Code|Identifier|Length|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Code3Success;4Failure.Identifier Identifier域为一个字节，辅助匹配Response应答Identifier域必须与其正在应答的Response域中的Identifier域相匹配Length4Success和Failure类型的包没有Data域，相应的Length域的值为4；2）Request和Response数据包:Request数据包由认证者发送给对方每一个Request有一个type域来表明正在请求的类型认证者必须发送一个Code域为1的EAP数据包（即Request）在收到有效的Response数据包之前，或者在可选的重发计数器计数满（expires）之前，必须发送另外的Request数据包重新发送的Request必须保持Identifier的值不变以区别于新的RequestData域的内容依赖于Request的Type对方必须发送一个Response作为对Request的应答Response必须仅在对接收到的Request作出应答时发送，从不根据定时器重发Response中的Identifier域必须与Request中的Identifier域匹配实现须知因为认证过程经常涉及到用户输入，在决定重发策略和认证超时设定（timeout）时要谨慎建议使用重发定时器为6秒，最大重传次数为10次作为缺省值人们可能希望某些特定情况下（例如，涉及到TokenCards的时候）超时设定能更长些另外，对方必须准备好在等待用户输入时悄悄丢弃所收到的重传数据包Request和Response数据包的格式如下所示，传输时各域从左到右依次进行01245-NCodeIdentifierLengthTypeType-Data...Code:1-Request;2-Response.Identifier:Identifier域为一个字节在等待Response时根据timeout而重发的Request的Identifier域必须相同任何新的（非重发的）Request必须修改Identifier域如果对方收到了重复的Request，并且已经发送了对该Request的Response，则对方必须重发该Response如果对方在给最初的Request发送Response之前收到重复的Request（也就是说，它在等待用户输入），它必须悄悄的丢弃重复的RequestLength:Length域为两个字节，表明EAP数据包的长度，包括CodeIdentifier，Length，Type以及Type-Data等各域超出Length域的字节应视为数据链路层填充（padding），在接收时应该被忽略掉Type:Type域为一个字节该域表明了Request或Response的类型在EAP的Request或Response中必须出现且仅出现一个Type通常，Response中的Type域和Request中的Type域相同但是，Response可以有一个Nak类型，表明Request中的Type不能被对方接受当对方发送Nak来响应一个Request时，它可以暗示它所希望使用并且支持的认证类型各种Type的原始定义稍后给出Type-Data:Type-Data域随Request和相对应的Response的Type的不同而不同
3.
5.
2.4认证消息的封装TypeTypeDataType1个字节，就是
3.
5.
1.2指出的EAP认证类型1---Identity；2---Notification；3---Nak（ResponseOnly）4---MD5-Challenge；5---One-TimePassword（OTP）；6---GenericTokenCareGTC；13---TransportLayerSecurityTLS17---CiscoLightweightEAPLEAP18---SubscriberIdentificationModuleSIM21---TunneledTLSTTLS25---ProtectedEAPPEAP1）IdentityIdentify类型用来查询对方的身份通常，认证者发送该类型作为最初的Request在期望与用户进行交互的场合还可以包括一条可选的可显示的消息以给对方作出提示必须对包含Type1Identity的Request发送Response以作出响应实现须知对方可以通过用户输入获得Identity建议在Identity无效或者认证失败时认证者重发（retry）IdentityRequest以顾及到用户的打字错误建议在发送Failure应答来结束认证阶段之前最少重发IdentityRequest3次在发送新的IdentityRequest之前可以发送一个NotificationRequest来暗示认证无效（可选地，失败可以通过新的Identity中的消息来暗示）Type1Type-Data该域可以包含一条可显示的消息Response用该域来返回Identity如果Identity未知，该域长度应该为0该域不允许以null作为终结符该域的长度由Request/Response中的Length域来决定，所以null是不必要的2）Notification:NotificationType可选地由认证者用来给对方传递一条可显示的消息对方应该把这条消息显示给用户，如果无法显示则纪录（log）该消息使用它的目的是在某些紧急情况下（imperativenature）提供一条确认通知（acknowledgednotification）这样的例子包括带一个超时设定（expiration）的口令，OTP序列整数（接近0），认证失败警告等等在大多数情况下，notification不应该是必要的Type:2Type-Data:Type-Data域包含一条长度大于0字节的可显示的消息消息的长度由Request数据包中的Length域决定，消息不允许以null作为终结符必须对带有Type域为2（Notification）的Request发送一个ResponseResponse中的Type-Data域长度为0字节，Response应该立即发送（与消息显示或纪录的方法无关）3NakNak仅对Response有效，当Request中希望（desired）的认证类型不可接受时，发送Nak作为对Request的响应AuthenticationType的值为大于等于4Response中包含了对方所希望使用的认证类型Type:3Type-Data:该域必须包含一个唯一的字节，表明希望的认证类型4MD5-ChallengeMD5-ChallengeType与PPPCHAP协议（参考文献
[3]，制定了MD5算法）类似更多的实现细节应该参考PPP挑战握手认证协议RFC（参考文献
[3]）Request包含一个对对方进行“挑战”的消息，必须对这样的Request发送一个Response以作出应答Response可以为Type4（MD5-Challenge）或者Type3NakNak应答表明对方希望的认证机制类型所有的EAP实现必须支持MD5-Challenge机制Type:4Type-Data:Type-Data域的内容如下所示这些域的用法请参考PPP挑战握手认证协议5One-TimePassword（OTP）One-TimePassword系统在“One-TimePasswordSystem（参考文献
[4]）”中定义Request包含了一条包含一个OTP挑战的可显示的消息必须对这样的Request发送一个Response以作出应答Response必须为Type5OTP或Type3NakNak应答表明了对方希望使用的认证机制类型Type:5Type-Data:Type-Data域包含了该OTP挑战，为Request中的可显示消息在Response中，该域用来存放来自OTP字典（参考文献
[4]）的6个词（word）该消息不允许以null作为终结符该域的长度由Request/Reply数据包中的Length域决定6GenericTokenCareGenericTokenCardType是为要求用户输入的各种TokenCard实现定义的Request包含一条ASCII文本消息，Reply包含认证所必需的有关TokenCard信息典型地，这些信息将是由用户从TokenCard设备读取并以ASCII文本输入的信息Type:6Type-Data:Request中的Type-Data域包含了长度大于0的可显示的消息消息的长度由Request中的Length域决定，该消息不允许以null作为终结符必须对包含Type为6（GenericTokenCard）的Request发送一个Response以作为响应Response包含了认证所必需的TokenCard信息，信息的长度由Response数据包中的Length域决定
3.
5.3EAPOL-Key的封装当EAPOL数据包Type域为EAPOL-Key时，PacketBody为EAPOL-Key数据包结构，主要用于密钥管理的四步握手协议，在密钥管理部分将给出详细说明图
3.
5.
3.1形象地说明了EAPOL的消息封装#0;#0;DestinationAddress#0;SourceAddress#0;PAEethernettype#0;Protocolversion#0;Type#0;length#0;Data#0;图
3.
5.
3.1EAPOL的消息封装1EAPOL-Key消息的封装RSN的密钥管理中，申请者和认证者之间进行协商密钥，都是采用EAPOL-Key对消息进行封装其数据包格式和
802.1x中的规定一致，所不同的是密钥描述符与
802.1x及TGi的规定都有所区别下面介绍一下RSN密钥的描述格式如下图所示KeyLength2octets#0;ReplayCounter8octets#0;KeyNonce32octets#0;KeyInformation2octets#0;KeyMIC16octets#0;KeyDataNoctets#0;KeyDataLength2octets#0;DescriptorType1octet#0;EAPOL-KeyIV16octets#0;KeyRSC8octets#0;KeyID8octets#0;图
3.
5.
3.2RSN密钥描述符各域的说明如下DescriptorType1个字节，指明密钥的类型，对于RSN，值为254（十进制）KeyInformation两个字节，各位的含义说明如下Type3bitsKeyType1bitKeyindex2bitsKeyusage1bitAck1bitMIC1bitSecure1bitError1bitRequest1bitReserved4bits10-2位表示密钥描述版本号值为1，表示EAPOL-KeyMIC采用HMAC-MD5进行计算，组密钥采用RC4来加密；值为2，表示EAPOL-KeyMIC采用HMAC-MD5进行计算，组密钥采用AES-CBC加密2第3位是密钥类型标志位1表示对等密钥；0表示组密钥3第
4、5位表示包含了用于临时密钥生成的初始密钥4第6位为密钥的Tx/Rx标志位5第7位为Ack标志位，如果认证者发出的消息需要回应，则置位6第8位为MIC标志位7第9位为Secure位，如果初始的密钥交换已经完成，置位8第10位Error标志位，如果申请者对数据的整体性校验出错，置位9第11位Request标志位，在申请者向认证者发送请求四步握手开始的消息中置位10第12-15位保留KeyLength2个字节，加密/整体性校验机制所使用的密钥的长度ReplayCounter8个字节，使用无符号二进制术表示申请者端，回应认证者的EAPOL-Key消息时，使用收到的认证者端发送包中的计数器；认证者端，则以此来判断是否为申请者端的重发包KeyNonce32个字节，包含了ANonce（认证者）或者SNonce（申请者），如果无需Nonce其值为零KeyIV16个字节，包含了用来产生加密组密钥的IVKeyRSC8个字节，接收序列计数器，用于四步握手的第三条消息及组密钥更新的第一条消息其他消息中，置零KeyID目前保留，置零KeyMIC16个字节，对EAPOL包（从EAPOL协议版本域到EAPOL-Key数据域）计算MICKeyDataLength2个字节，表示密钥数据长度对于组密钥，其值和KeyLength相同；对于对等密钥，第
二、三条消息数据为RSN的IE（信息元素），数据域长度即为IE的长度第
一、四条消息数据域为空，长度即为零KeyData对于对等密钥，这个域在四步握手的第
二、三条消息中包含了RSN的IE，第
一、四两条消息则为空RSNIE中包含了组播（加密）套件（MulticastSuit）、单播（加密）套件表（UnicastSuitList）与单播（加密）套件数（UnicastSuitCount）、认证的密钥管理套件表（AuthenticatedKeyManagementSuitList）与认证的密钥管理套件数（AuthenticatedKeyManagementSuitCount）等内容格式如图
3.
5.
3.3所示SHAPE\*MERGEFORMATSHAPE\*MERGEFORMATSHAPE\*MERGEFORMATSHAPE\*MERGEFORMATSHAPE\*MERGEFORMATSHAPE\*MERGEFORMATSHAPE\*MERGEFORMATSHAPE\*MERGEFORMAT图
3.
5.
3.3RSN信息单元格式ElementID规定为十进制的37（十进制）；Length为Length域以后的单元长度，即从Version开始到单元结束的8bit字节数；Version为所支持的RSNIE的版本号，当前为Version1，即0x0001；Version域是必须包括的，多播套件、单播套件、认证密钥管理套件等域则是可选的如果不支持多播套件或单播套件，认证和密钥管理同样也是不支持的RSNIE中包含了加密的组播套件（MulticastSuit）、单播套件表（UnicastSuitList）、单播套件数（UnicastSuitCount）和认证的密钥管理套件表（AuthenticatedKeyManagementSuitList）、密钥管理套件数（AuthenticatedKeyManagementSuitCount）等内容每个套件选项的格式为认证套件选项见表5-1，表
3.
5.
3.1认证套件选项表OUIType注释00:00:000不支持认证的密钥管理协议00:00:001未指定的
802.1x认证的密钥管理协议，RSN默认值00:00:002采用共享密钥的
802.1x密钥管理协议（不支持
802.1x认证协议）00:00:003-255保留值OtherAny表
3.
5.
3.2加密套件选项表OUIType注释00:00:000无加密套件00:00:001WEP00:00:002TKIP00:00:003AES-OCB00:00:004AES-CCM，RSN默认值00:00:005-255保留值OtherAny由制造商指定例如，采用
802.1x认证的密钥管理协议，单播和组播套件为AES-CCM，不支持WEPSTA的RSNIE格式如下（16进制）0x25，0x02，0x01，0x00，//Version12EAPOLAddressinga以太网类型分配PAE以太网类型（88-8E）b以太网地址请求者和认证者相互知道对方的MAC地址使用单个地址作为目的地址c组地址请求者和认证者不知道对方的MAC地址使用PAE组地址（01-80-C2-00-00-03）作为目的地址dPAE组地址是MAC组地址保留的，因此不会被网桥转发e在共享局域网中，EAPOL可以使用，但存在安全问题
3.
5.4RADIUS的EAP扩展IETF于2000年6月发布RFC2869RADIUSExtensions将RADIUS的功能进行扩展RADIUS中的扩展认证协议（EAP/RADIUS）是将EAP消息从网络接入服务器传送到RADIUS服务器的一种认证机制通过使用EAP，RADIUS可以支持许多额外认证方案，包括智能卡（Smartcard），Kerberos，PublicKey，OneTimePasswords和其它多种为了能够支持EAP，RADIUS在原有协议的基础上增加了两个新的属性EAP消息（EAP-Message）和消息认证码（Message-Authenticator）RADIUS的EAP扩展利用RADIUS服务器在NAS和后端安全服务器之间传送封装在RADIUS内的EAP报文尽管可以利用后端服务器发展的私有协议在RADIUS服务器和后端服务器之间进行会话，但通过将EAP报文封装在RASIUS报文的EAP-Message属性内也是可能的这样的优点是RADIUS服务器为了支持EAP，不需要增加针对某种认证的代码，这些针对某种认证的代码的可以放在后端安全服务器上EAP的属性封装1）EAP-Message这个属性用来封装EAP数据包，类型代码为79，string域最长为253字节，如果EAP数据包长度大于253，可以对其进行分片，依次封装在多个EAP-Message属性中2）Message-Authenticator这个属性可以用于在使用CHAP、ARAP、EAP等认证方法的过程中，避免接入请求包被窃听在含有EAP-Message属性的数据包中，必须同时也包含Message-Authenticator，否则该数据包被认为无效而被丢弃其中属性格式中的类型代码为80，长度共18个字节，String域为16个字节的消息认证码，计算如下Message-Authenticator＝HMAC-MD5Code，Identifier，Length，RequestAuthenticator，Attributes对于Access-Request包，即对整个数据包从类型域到属性域，使用共享密钥作为key，作MD5算法Access-Challenge、Access-Reject、Access-Accept包，计算方法相同，区别Authenticator域使用收到的Access-Request、RequestAuthenticator代替，再进行ResponseAuthenticator域的计算注意计算时，属性域也要包含Message-Authenticator，所以首先将其填充0，然后再将计算结果写入该属性服务器收到接入请求后，对于含有EAP-Message属性的数据包，使用相同的算法计算Message-Authenticator，如果结果不一致，数据包被丢弃通过这个属性，服务器和客户端可以相互验证数据包，在EAP认证过程中保护有用信息，提供更好的安全性RADIUS的EAP扩展的安全性因为EAP的目的是为PPP认证提供增强的安全性，因此RADIUS安全地支持EAP是至关重要的特别地，必须解决下面的问题aEAP服务器和PPP认证者分离EAP端点相互认证，协商加密组，为随后PPP加密取得一个会话密钥是可能的因为对端和EAP客户在同一台机器上，这不是一个问题所需要的就是EAP客户模块向PPP加密模块传递一个会话密钥当EAP和RADIUS一起使用时，情况就比较复杂了，因为一般PPP认证者和EAP服务器不在同一台机器上例如，EAP服务器可能是一台后端安全服务器，或者RADIUS服务器上的一个模块在EAP服务器和PPP认证者在不同的机器上的情况下，关于安全有如下几方面的含义首先，交互认证将在对端和EAP服务器上发生，而不是在对端和认证者之间这意味着对端不可能证实它连接的NAS或隧道服务器的身份如前所述，当EAP/RADIUS被用来封装EAP报文时，从NAS或隧道服务器发往RADIUS服务器的EAP/RADIUSAccess-Request中需要Message-Authenticator属性因为Message-Authenticator属性包含一个HMAC-MD5hash项，使得RADIUS服务器有可能验证Access-Request的完整性和NAS或隧道服务器的身份类似地，从RADIUS服务器发往NAS的Access-Challenge报文也被验证并由HMAC-MD5hash项保护完整性，使得NAS或隧道服务器可以判定报文的完整性并且验证RADIUS服务器的身份此外，通过包含其它完整性保护方法来发送的EAP报文不能被欺诈的NAS或隧道服务器成功地修改EAP服务器和PPP认证者在不同的机器上引来的第二个问题是，对端和EAP服务器协商的会话密钥需要传送到认证者因此必须提供从EAP服务器到要使用密钥的认证者或隧道服务器的传送会话密钥的一个机制这个传送机制的规范超出了本文档的范围b连接劫持在这种攻击方式中，攻击者试图在NAS和RADIUS服务器之间或RADIUS服务器和后端安全服务器之间的会话中注入一些报文同RFC2865中描述的那样，RADIUS不支持加密，只有Access-Reply和Access-Challenge报文受完整性保护此外，在RFC2865中描述的完整性保护机制比一些EAP方法使用的弱，使得攻击EAP/RADIUS有可能扰乱那些方法如前所述，为了给EAP互换的所有报文提供验证，所有EAP/RADIUS报文必须使用Message-Authenticator属性来验证c中间的攻击因为RADIUS安全基于共享密钥，在认证或计费报文通过一个代理链转发的情况下不能提供端到端的安全结果，获得一个RADIUS代理控制权的攻击者将能够修改传送中的EAP报文d多数据库在许多情况下，为了提供EAP服务，后端安全服务器和RADIUS服务器一块使用除非后端安全服务器也实现RADIUS服务器的功能，否则要用两个分离的用户数据库，每一个数据库内包含有关用户安全需求的信息这意味着安全的降低，因为只要成功攻击数据库中的任何一个或攻击它们的后端数据库都可能损害安全性当使用多个用户数据库时，如果要增加一个用户，就必须进行多个操作，这就增加了出错的概率当用户信息也放在LDAP上时，危害性又被进一步放大，因为此时必须在三个地方存放用户信息为了解决这些威胁，建议合并数据库这可以通过以下途径来解决RADIUS服务器和后端安全服务器在同一个后端服务器上存储信息；后端服务器提供一个完全的RADIUS实现；或将后端安全服务器和RADIUS服务器合并到同一个机器上e协商攻击在协商攻击中，欺骗的NAS、隧道服务器、RADIUS代理或RADIUS服务器使认证对等端选择一个安全小的方法，这样欺骗者可以比较容易地得到用户密码例如，一个会话本来在通常用EAP认证，被协商攻击后，可能用CHAP或PAP认证；一个会话本来用一种EAP类型认证，被协商攻击后，可能使用一种安全系数小的EAP类型认证，如MD5以前认为很遥远的欺骗设备威胁，已经给电话公司交换系统造成了危害要使系统不受协商攻击，需要消除向下协商这可以通过以下方式实现对认证对等端而言，使用每一个连接策略，对RADIUS服务器而言，使用每一个用户策略对于认证对等端而言，认证策略应该建立在每一个连接的基础之上每一个连接策略允许呼叫一种服务时认证对等端来协商EAP，而呼叫另一种服务时协商CHAP，即使两种服务通过同一个电话号码就可以访问对于每一个连接策略，只有当期望支持EAP时，认证对等端才会试图协商EAP因此假定如果认证对等端选择EAP，那么就认为认证对等端需要哪个等级的安全如果不能提供，那么极有可能是配置错误，甚至认证对等端连接到了错误的服务器上万一NAS不能协商EAP，或NAS发送的EAP-Request与期望的不同，认证对等端必须端开连接期望协商EAP的认证对等端一定不能协商CHAP或PAP对于NAS而言，在它知道用户的身份之前，它可能无法确定一个用户是否需要EAP认证例如，共用NAS，可能对一个专卖者实现EAP，对另外一个则不实现在这些情况下，如果NAS的每一个用户必须用EAP，那么NAS必须试图为每一个呼叫协商EAP，这样可以避免能够EAP认证的客户端因用多种认证而削弱安全性如果协商了CHAP，NAS将把User-Name和CHAP-Password属性放在Access-Request报文中传给RADIUS服务器如果没有要求用户用EAP认证，那么RADIUS服务器可以用Access-Accept或Access-Reject报文响应，这要看用哪一个报文回应更合适但是，如果已经协商过了CHAP而需要EAP，那么RADIUS服务器必须回一个Access-Reject报文，而不能回应Access-Challenge/EAP-Message/EAP-Request报文认证对等端必须拒绝重新协商认证，即使是从CHAP协商到EAP如果已经协商过了EAP，但RADIUS代理或服务器不支持，那么服务器或代理必须用Access-Reject报文响应在这些情况下，NAS必须发送一个LCP-Terminate并且切断用户这是正确的行为，因为认证对等端期望协商EAP，但期望不能被满足对于支持EAP的认证对等端，如果最初已经协商了EAP，那么解决重新协商认证协议需要注意的是因RADIUS代理服务器不支持EAP而出现的问题是很难诊断的因为从一个地方拨号接入的用户（代理支持EAP）或许能够用EAP成功认证，而同一个用户从另一个地方拨号进入时（代理不支持EAP），或许始终被切断
3.6EAP认证方法
3.
6.1EAP认证类型的概括和总结
802.1x认证采用的认证方法为EAP认证方法，要实现哪种EAP类型，或者是否完全实现
802.1x，这取决于网络需要的安全级别和所希望的管理开销/功能最普遍采用的一些EAP验证类型包括EAP-MD
5、EAP-TLS、EAP-PEAP、EAP-TTLS和CiscoLEAP1）EAP-MD5（消息摘要）验证是一种提供基本级别的EAP支持的EAP验证类型对于无线LAN实施，一般建议不要使用EAP-MD-5，因为可以导出用户的密码它仅提供单向验证—不存在无线客户端和网络的相互验证并且非常重要的一点是，它没有提供方法来根据每个会话动态派生有线对等保密WEP密钥2）EAP-TLS（传输层安全）提供了基于证书的验证以及客户端和网络之间的相互验证它依赖客户端和服务器端的证书来执行验证，并可用来动态生成基于用户的和基于会话的WEP密钥，以保护WLAN客户端和接入点之间随后进行的通信EAP-TLS的一个缺点是，必须同时在客户端和服务器端管理证书对于较大的WLAN安装，这可能是一项非常繁重的任务3）EAP-TTLS（隧道传输层安全）是由FunkSoftware和Certicom公司开发的，是EAP-TLS的一种扩展此安全方法提供了一种基于证书的验证方法，并通过加密的通道（或隧道）进行客户端和网络的相互验证，还提供了一种方法来根据每个用户、每个会话动态派生WEP密钥与EAP-TLS不同的是，EAP-TTLS只需要服务器端的证书4）LEAP（轻量级可扩展验证协议）是一种主要用于CiscoAironetWLAN中的EAP验证类型它使用动态生成的WEP密钥对数据传输进行加密，并支持相互验证之前的所有者Cisco最近已将LEAP许可给其它各种制造商，允许非Cisco适配器使用LEAP5）PEAP（受保护的可扩展验证协议）提供了一种通过
802.11无线网络安全地传输验证数据的方法，包括传统基于密码的协议PEAP通过在PEAP客户端和验证服务器之间使用隧道传输来实现此目的与隧道传输层安全TTLS这一有竞争力的标准相同，PEAP也仅使用服务器端的证书验证无线LAN客户端，因而简化了安全无线LAN的实施和管理Microsoft、Cisco和RSASecurity公司共同开发了PEAP请注意，Cisco的LEAP验证服务器ACS最近增加了支持PEAP的功能详细内容可参见表
3.
6.
1.1表
3.
6.
1.1认证方式之间的比较
802.1xEAP认证方式的特点/优点MD5消息摘要5TLS传输层安全TTLS隧道传输层安全PEAP受保护的传输层安全LEAP轻量级可扩展验证协议需要客户端证书否是否否否需要服务器端证书否是是是否WEP密钥管理否是是是是检测非法AP否否否否是验证属性单向相互相互相互相互部署难度容易困难中等中等中等无线安全性最差最高高高高回顾一下以上讨论和比较表，我们可以看出1）在EAP认证中MD5的安全性最弱，因为它只进行单向验证，并且更重要的原因是它不支持自动分发和轮换WEP密钥，因此，它无法减轻手动维护WEP密钥的管理负担2）LEAP历史最长，尽管以前归Cisco所有（只能与Cisco无线适配器配合使用），但现在Cisco发放该软件许可证，其它供应商现在开始在自己的无线LAN适配器中支持LEAP3）TLS认证是安全级别最高的EAP认证，在认证中客户端和服务器端都使用到了证书，可是尽管TLS非常安全，但它要求在每个无线工作站和服务器端管理证书对于较大的WLAN安装来说，这可能是一项非常繁重的任务管理员无法忍受维护PKI基础结构通常所需要的时间和精力4）TTLS和更近的PEAP认证方式通过隧道TLS解决了证书问题，因而在客户端不需要证书在客户端看来，这种认证方法和强口令认证方式一样的方便，这就使得该认证方法常常成为用户首选的选项可以预计，在PWLAN的认证方式选用上，它集安全和方便于一身，是大家乐于使用的安全认证方法下面具体介绍各种认证方式的具体步骤
3.
6.2基于公钥证书和传输层安全协议TLS的方法EAP-TLSEAP_TTLS和EAP－PEAP
3.
6.
2.1基于公钥证书的双向认证EAP_TLS
3.
6.
2.
1.1概述EAP_TLS认证提供了一种基于证书的双向认证，除了在连接建立时主机和服务器之间分配的会话号（SessionID）之外，它需要通过安全连接在客户侧和服务器侧事先发布认证证书EAP-TLS既提供认证，又提供动态会话钥匙分发RADIUS服务器需要支持EAP-TLS认证，和认证证书的管理能力TLS支持双向认证，也就是网络（EAP-TLS服务器）认证终端用户（Client），终端用户认证网络只有在双向认证通过以后，服务器将向接入认证点发送EAP－Success消息，指示用户终端可以收发数据流这个消息同时触发了对数据流的加密，在加密密钥建立之前，终端不发送数据
3.
6.
2.
1.2TLS传输层安全协议SSL（SecureSocketLayer，安全套接层协议）是Netscape公司设计的主要应用于web的安全传输协议，在web上获得广泛应用，目前有
2.0和
3.0两个版本1999年，IETF将SSL作了标准化，即RFC2246，称其为TLS（TransportLayerSecurity，传输层安全）从技术上讲，TLS
1.0与SSL
3.0的差别非常微小，下面仅用TLS一词TLS现已被业界广泛认可，在OSI分层结构图中位于TCP和应用层协议（HTTP，SMTP，FTP）之间TLS协议分为两部分握手协议（HandshakeProtocol）和记录协议（RecordProtocol）其中HandshakeProtocol在客户和服务器双方进行保密通信前确定密钥、加密认证算法等安全参数，协议的大部分内容就是通信双方如何利用它来安全的协商出一份密钥RecordProtocol则定义了传输的格式
3.
6.
2.
1.3握手协议这是TLS中最复杂的一部分，使得服务器和客户能够相互鉴别对方的身份、协商加密和MAC算法以及用来保护在TLS记录中发送的数据的加密密钥其中又包括三个子协议（sub-protocols）握手协议，修改密文规约协议和告警协议1）握手协议由一系列在客户和服务器之间交换的报文组成报文格式如下TypeLengthDataType一共有10种类型表
3.
6.
2.
1.
3.1握手协议报文类型0hello_request1client_hello2server_hello11certificate12server_key_exchange13certificate_request14server_hello_done15certificate_verify16client_key_exchange20finsihed客户与服务器之间建立逻辑连接所需的交换有四个阶段（常用的密钥交换方法有RSA、固定的Diffe-Hellman、短暂的Diffe-Hellman、匿名Diffe-Hellman和Fortezza，下面以RSA密钥交换说明）a阶段1——建立安全能力这个阶段用于开始逻辑连接并且建立和这个连接关联的安全能力客户发起这个交换，发送client_hello报文，包含有版本、随机数、会话ID、密文族和压缩方法等参数，其中随机数是客户生成的随机结构，由32bit时间戳和安全随机数生成器生成的28字节的随机数，一共是32字节，记做client_hello.random密文族选择TLS_RSA_WITH_RC4_128_MD5和TLS_RSA_WITH_RC4_128_SHA同时在这个阶段产生48字节的预先主密码pre_master_secret；发送之后，客户等待与client_hello报文具有同样参数的server_hello报文随机数字段是服务器生成的独立于客户的随机数字段，记做server_hello.random；密文族字段包含服务器从客户建议密文族列表中选择的一个密文族，压缩字段包含了服务器从客户建议压缩列表中选择的一个压缩算法b阶段2——服务器鉴别和密钥交换服务器通过发送自己的证书certificate开始这个阶段，报文中包含一个或一个链的X.509证书服务器创建临时的RSA公开/私有密钥对，并且使用server_key_exchange报文来发送这个公开密钥，报文内容包括了这个临时RSA密钥的两个参数，加上这些参数的签名下一步向客户请求证书，certificate_request报文包括了两个参数certificate_type和certificate_authorities，证书类型指出了公开密钥算法和它的使用，第二个参数是可接受的证书管理机构名字的列表本阶段的最后一个报文是server_hello_done，由服务器发送，指示服务器的hello和相关报文的结束，在这之后，服务器将等待客户的响应，该报文没有任何参数c阶段3——客户鉴别和密钥交换一旦收到了服务器的done报文，客户验证服务器是否提供了合法的证书，检查服务器hello参数是可接受的，如果这些条件满足，客户就把一个或多个报文发送给服务器客户通过发送certificate报文来开始这个阶段，如果没有合适的证书可用，客户发送no_alert告警作为代替接下来是client_key_exchange报文，使用来自于server_key_exchange报文的临时RSA密钥对pre_master_secret进行加密在这个阶段最后，客户发送certificate_verify报文来对客户证书提供明确的验证，在handshake_message上计算MD5和SHA-1散列，并用RSA私钥对散列数据的连接进行加密握手报文指的是从客户hello开始的所有发送和接受的握手协议报文，但不包括客户hello报文该报文的目的是为了验证客户对于客户证书私有密钥的所有权，即使有人误用了该客户的证书，也将不能发送这个报文d阶段4——结束这个阶段完成安全连接的建立客户发送change_cipher_spec报文并且将挂起的Cipher_spec复制到当前的Cipher_spec，注意这个报文不是握手协议的一部分，而是使用修改密文规约协议来发送的然后，客户发送finished报文计算方法PRFmaster_secret，finished_label，MD5handshake_messages+SHA-1handshake_messages[
0..11]；其中主密码master_secret是根据pre_master_secret计算的master_secret=PRFpre_master_secret，mastersecret，ClientHello.random+ServerHello.random[
0..47]；结束标号finsihed_label对于客户是“客户结束（clientfinished）”，对于服务器是“服务器结束（serverfinished）”握手报文是目前为止来自握手报文但不包括该报文的所有数据作为对这两个报文的响应，服务器发送它自己的change_cipher_spec报文，将挂起状态迁移到当前的Cipher_Spec，并且发送它的结束报文，这时握手过程完成共享的主密码是通过密钥交换的方式为这个会话生成的一次性的48字节值创建过程分两个步骤第一，交换预先主密码；第二，双方计算出主密码对于RSA密钥交换方法，客户生成48字节的预先主密码，使用服务器的公开RSA密钥进行加密，然后发送给服务器服务器使用自己的私有密钥对密文进行解密以恢复预先主密码接着双方用同样的公式计算主密码master_secret以及会话密钥PRFmaster_secret，clientEAPencryption，ClientHello.random+ServerHello.random[
0..127]主会话密钥Master_Session_Key取上述结果的前32字节用于后面的密钥管理过程说明这里的伪随机函数PRF是采用的RFC2246“TheTLSProtocolVersion
1.0”中的定义，PRFsecretlabelseed=P_MD5S1label+seedXORP_SHA-1S2label+seed这里的S
1、S2是通过将secret分为两半得到的；2修改密文规约协议修改密文规约协议是最简单的，协议内容是由单个报文组成，该报文由值为1的单个字节组成，目的是使得挂起状态被复制到当前状态，改变了这个连接将要使用的密文族3告警协议用来将TLS有关的告警传送给对方实体这个协议的每个报文由两个字节组成级别告警第一个字节值是警告warning
（1）或致命的fatal
（2），用来传送报文的严重级别如果级别是致命的，TLS立刻中止该连接第二个字节包含了指出特定告警的代码下面列出这些告警表
3.
6.
2.
1.
3.2告警协议中的告警类型0close_notify10unexpected_message20bad_record_mac21decryption_failed22record_overflow30decompression_failure40handshake_failure42bad_certificate43unsupported_certificate44certificate_revoked45certificate_expired46certificate_unknown47illegal_parameter48unknown_ca49access_denied50decode_error51decrypt_error60export_restriction70protocol_version71insufficient_security80internal_error90user_canceled100no_renegotiation
3.
6.
2.
1.4记录协议记录协议完整的操作是接受传输的应用报文，将数据分片成可管理的块，可选的压缩数据，应用MAC，加密，增加首部，在TCP报文段中传输结果单元在无线局域网的认证中采用TLS协议，记录协议并没有用到全部操作，只是定义传输格式，附加一个首部，称作RecordHeader0123-4TypeMajorVersionMinorVersionLengthType内容类型，指明处理这个包装的数据片的高层协议20change_cipher_spec修改密文规约协议21Alert告警协议22Handshake握手协议23application_dataMajorVersion主要版本，对于TLSv
1.0，字段值为3MinorVersion次要版本，对于TLSv
1.0，字段值为1Length数据片以字节为单位的长度既提供认证，又提供动态会话密钥分发不但在无线客户端和服务器之间提供互相认证，还能提供数据完整性保护所有的无线客户端以及服务器都需要事先申请一个标准的X.509证书并安装，在认证的时候客户端和服务器要相互交换证书在交换证书的同时，客户端和服务器要协商出一个基于会话的密钥，一旦认证通过，服务器将会话密钥传给无线接入点并通知无线接入点允许该客户端使用网络服务
3.
6.
2.
1.5认证流图及认证步骤下面以较为形象的方式说明一下STA和AS之间的认证信息交互过程Supplicant#0;EAP-Request/Identity#0;Authenticator#0;AS#0;#0;#0;EAPOL-START#0;EAP-Response/Identity��MyID��#0;RADIUSAccessRequestEAP-RequestIdentity#0;RADIUSAccessChallengeEAP-Request#0;EAP-Request/TLS-Start#0;EAP-Response/TLSClientHello#0;RADIUSAccessRequestEAP-ResponseTLSClientHello#0;RADIUSAccessChallengeEAP-Request#0;EAP-RequestTLSServerHelloTLScertificateTLSserver_key_exchangeTLScertificate_requestTLSserver_hello_done#0;EAP-Response/TLScertificateTLSclient_key_exchangeTLScertificate_verifyTLSchange_cipher_specTLSfinished#0;RADIUSAccessRequestEAP-Response#0;RADIUSAccessChallengeEAP-Request#0;EAP-RequestTLSServerHelloTLScertificateTLSchange_cipher_specTLSfinished#0;EAP-Response#0;RADIUSAccessRequestEAP-Response#0;RADIUSAccessaccept#0;EAP-Success#0;#0;图
3.
6.
2.
1.
5.1TLS认证交互步骤客户端模块1客户端发起认证即发送EAPOL-START包2客户端收到将EAP-RequestID包后自己的ID信息封装在EAP-Response包中发送给认证服务器3客户端接收到EAP-TLSStart包后开始发起TLS中的握手过程的第一步:clienthello.clienthellomessage包括clienthello包的长度3个字节TLS版本号2个字节，随机数32个字节其中4个为时间戳28个为随机数，SessionID1个字节clienthello中为0一组客户端所支持的密文族（ciphersuites）每个加密算法的代号占2个字节参见RFC22464客户端收到serverhello和服务器端的证书后用大家都信任的根证书进行验证验证通过以后发送密文族修改协议否则发送告警信息5客户端发送TLS-ACK包服务端模块1认证服务器收到EAPOL-START包后回应EAP-Request包要求客户的ID信息2认证服务器收到了客户端的ID信息则在自己的数据库中搜索到了ID则发起EAP-TLS认证即发送EAP-TLSStart包3服务器端收到clienthello后开始发送握手过程的第二步其中包括serverhelloserver端证书对客户端的证书请求以及最后的serverdone包表明包全部发送结束Serverhello结构与clienthello包结构类似只是session-id部分不同它包括两部分一部分是session-id的长度占一个字节另一部分是session-id的内容最后是服务器从客户端提交的密文族中选取一个加密算法4服务器端收到密文族修改协议后发送协商号的密文族修改协议5服务器端收到TLS-ACK包后发送认证成功包
3.
6.
2.2基于公钥证书和TLS隧道的认证EAP_TTLS
3.
6.
2.
2.1概述EAP_TTLS是一种在TLS安全隧道的保护下实行的基于用户名和密码的认证方式，它的引入是为了方便不具备证书的STA进行身份验证的，因为证书的管理对于WLAN来说是一项繁重的工作，对于STA来说则使用没有强口令认证使用方便TTLS认证分为两个阶段，阶段一是STA对AS发送过来的证书的认证，如果认证通过，则建立TLS安全隧道，反之则认证失败，阶段二则是在TLS安全隧道保护下，进行目前流行的一些强口令认证，所不同的是，这些认证方式所需要的STA数据是经过SSL记录协议进行加密的，以保护用户的信息不被窃取，这也是TTLS之所以建立安全隧道的原因认证的第一阶段主要是是基于TLS握手协议，第二阶段的数据包则先是封装在AVP数据包（具体AVP数据包格式下面有详细的介绍）中，然后经过SSL记录协议加密，再经由EAP包封装TTLS在隧道协议中支持的认证方式很多，包括CHAPPAP以及所有的EAP认证方式在本项目中客户端实现了EAP－MD5，下面均以EAP－MD5作为隧道中的认证协议为例
3.
6.
2.
2.2TTLS数据包内容1阶段1TLS安全隧道建立过程在认证的第一阶段，TTLS需要建立一个TLS的安全认证隧道，此时TTLS认证和TLS认证的区别就是不需要客户端的证书，只需要客户端验证服务器的证书是否正确即可，因此在第一阶段的时候，客户端和服务器的认证数据和TLS基本相同，请参看TLS认证部分的内容2阶段2TLS安全隧道保护下的认证如上所述，在TTLS认证方法中，第二阶段中的认证数据是使用SSL记录协议层进行加密的同时，TTLS协议中引入了AVP封装格式这是为了能够在第二阶段中兼容多种认证方式所有的数据都用AVP包封装好之后再进行加密，然后再封装在EAP包中AVP包的数据包格式介绍如下表
3.
6.
2.
2.
2.1AVP包的数据包格式AVPCodeVMrrrrrrAVPLengthVendor-ID（opt）Data...AVPCode AVPcode和Vendor-ID可选标明了内置数据的属性，前256位的意义和RADIUS协议相同，256及以上的值则由Diameter定义如果使用的是EAP认证方式，则该栏的值为79（十进制）AVPFlags VVendor-Specific表示数据包中是否包含Vendor-IDM强制位，该位决定了是否强制用户端支持AVP格式r保留位（默认置0）AVPLength数据包的字节数，包括AVPcode，AVPFlagsAVPLengthVendor-ID以及data（认证数据）Vendor-ID4个字节，该位的目的是使用认证的公司能够用该位进行自身所需要的扩展，不过，必须将RADIUS，Diameter所定义的常用位留出如果该位置零，则意义和没有Vendor-ID相同Data Data域的数据就是认证数据包，以EAP－MD5为例，此处的认证数据包就是封装在EAP包中的MD5认证数据需要注意的是AVP数据包的字节数必须是4的整数倍，如果不满足该条件，就需要在一个AVP包的结尾补0，凑足4位，不过补充的0的长度是不包括在AVPLength中的
3.
6.
2.
2.3认证流图及认证步骤Supplicant#0;Authenticator#0;AS#0;AAA/H#0;#0;EAP-Request/Identity#0;EAP-Response/Identity#0;ARDIUSAccess-Request:XXX-Data-cipher-SuiteEAP-Responsepassthrough#0;ARDIUSAccess-Challenge:EAP-Request/TTLS-Start#0;EAP-Requestpassthrough#0;EAP-Response/TTLS:ClientHello#0;ARDIUSAccess-Request:EAP-Responsepassthrough#0;ARDIUSAccess-Challenge:EAP-Request/TTLS:ServerHelloCertificateServerKeyExchangeServerHelloDone#0;EAP-Requestpassthrough#0;EAP-Response/TTLS:ClientKeyExchangeChangeCipherSpecFinished#0;ARDIUSAccess-Request:EAP-Responsepassthrough#0;ARDIUSAccess-Challenge:EAP-Request/TTLS:ChangeCipherSpecFinished#0;EAP-Requestpassthrough#0;EAP-Response/TTLS:EAP-Response/IdentityXXX-Data-Cipher-Suite#0;ARDIUSAccess-Request:EAP-Responsepassthrough#0;RADIUSAccess-Request:EAP-Response/Identity#0;ARDIUSAccess-Challenge:EAP-Request/MD5-Challenge#0;ARDIUSAccess-Challenge:EAP-Request/TTLS:EAP-Request/MD5-ChallengeXXX-Data-Cipher-Suite#0;EAP-Requestpassthrough#0;EAP-Response/TTLS:EAP-Response/MD5-Challenge#0;ARDIUSAccess-Request:EAP-Responsepassthrough#0;ARDIUSAccess-Challenge:EAP-Response/MD5-Challenge#0;ARDIUSAccess-Accept#0;ARDIUSAccess-AcceptXXX-Data-Cipher-SuiteXXX-Data-Keying-MaterialEAP-Success#0;EAP-Successpassthrough#0;图
3.
6.
2.
2.
3.1TTLS认证交互步骤客户端模块1接受认证服务器发出的IDrequest包，发送客户端发出的IDresponse包（此处的IDrequest包对于服务器来说是可选的）2客户端接收到认证服务器发送TTLS-Start包后开始发起TLS中的握手过程的第一步:clienthello3客户端验证服务器发送的证书如果验证通过则发送密文族修改协定反之则发送告警信息.以下均以验证通过为例4客户端接收到服务器发送的密文族修改协定（TLS的安全隧道此时已经建立）发送TYPE为TTLS的EAP-RESPONSEID包此时采用真实的用户ID（真实用户名的格式如下username@realm此处的realm和TTLS认证的第一阶段中的用户名定义是不相同的，前者表示用户的网络，后者表示TTLS认证服务器的网络此时先前所建立的TLS安全隧道开始保护数据如果TTLS服务器搜索不到该用户，或者不支持EAP的隧道认证方法，则认证失败）5客户端收到认证服务器通知认证方式信息则发送相应的ResponseX-Challenge（X表示某认证方法）6接受到Success或者Fail信息服务器端模块1认证服务器发出的IDrequest包2认证服务器接收到客户端发出的IDresponse包，则在自己的数据库中搜索到了ID则发起TTLS认证即发送TTLS-Start包3认证服务器接收到客户端发出的clienthello包，认证服务器发送serverhello并发送自己的证书4认证服务器接收到客户端发出的密文族修改协定包，发送密文族修改协定（TLS的安全隧道此时已经建立）5认证服务器接收到客户端发出的IDresponse包，则在自己的数据库中搜索ID对应的认证方式6收到客户端发出的X-Challenge（X表示某认证方法），进行认证，成功则发Success失败则发Fail信息
3.
6.
2.3基于公钥证书和TLS隧道的认证EAP—PEAP
3.
6.
2.
3.1概述与EAP_TTLS一样，PEAP可以不需要无线网用户拥有证书就可以进行认证，并简化了无线网的安全结构保护可扩展身份认证协议PEAP和EAP-TTLS一样在EAP之上加了一个TLS层，它用TLS对话的结果来保护其他EAP方法PEAP运用TLS来认证客户这样，只有服务器需要公钥证书，而客户不需要客户和服务器交换一系列封装在TLS信息中的EAP信息，接着TLS信息被认证且运用客户和服务器协商的TLS会话密钥加密ProtectedEAPPEAP由两部分会话组成:Part1:协商TLS会话和EAP-TLS认证基本相同只是客户端证书是可选择的发送协商出的密钥用来加密PEAP认证的第二阶段的数据，从而保证数据传输的安全性Part2:若Part1中客户端没有提供认证证书（由于PEAP是提供给不具备证书的客户端进行认证的，因此这种情况占绝大多数），则开始PEAP认证的第二阶段PEAP认证与TTLS想比，第二阶段支持支持的认证协议少同样，第二阶段的EAP认证的数据交互是在TLS安全隧道中经过加密进行的也就是说，在PEAP认证的第一阶段，如果双方的TLS会话协商不成功的话，PEAP的第二阶段认证是不会实现的
3.
6.
2.
3.2PEAP数据包格式CodeIdentifierLengthTypeFlags|VerMessageLength......MessageLengthData...（EAPPackets）Code，Identifier定义和EAP协议相同Type:25PEAPFlags|Ver Flags|Ver字节包括PEAP的数据包标志位和版本号Flags|VersionLMSrrrV1V2Flags标志位L数据中包括长度项，如果是数据是分段发送，则出现在第一个包中M数据的内容不是完整的，还有更多的帧以待发送S PEAPstart包的置位符，如果为1，则说明此包是PEAP－start包，反之则不是r保留位（统一置零）Version版本号r保留位（统一置零）V1peap版本号的高位V2peap版本号的地位MessageLength:数据域的字节数Data认证的第一阶段，peap的数据域和TLS认证的数据域格式相同，从而通过TLS握手建立安全隧道在认证的第二阶段，peap的数据域为加密好的EAP认证包，与TTLS不同的是，peap的认证明文数据不要求封装在AVP包中，但是，认证结果信息必须封装在AVP包中经过加密发送，这是为了避免攻击者发送错误的认证结果信息，这是PEAP对TTLS认证安全的进一步改进
3.
6.
2.
3.3PEAP协议版本的协商由于PEAP认证协议目前处于草案阶段，有几个不同的协议版本，因此在PEAP认证的第二阶段中有个关于PEAP协议版本号的协商问题在版本协商中，认证服务器最初传送的一定是服务器的PEAP认证支持的最高版本，如果客户端支持此最高版本，则返回此版本号，反之，则返回客户端支持的最高版本号，只有在版本号协商通过的情况下，才能完成PEAP第二阶段的认证，如果服务器和客户端协商失败，则结束对话
3.
6.
2.
3.4EAP扩展认证的引入PEAP使用中引入了一种称为EAP扩展方法（TLV），（EAPtype是33），通过Result－AVP来保护认证成功和失败信息需要说明的是，收到成功的ResultAVP的用户端，必须同样的返回这个成功包否则被双方视为认证失败由于在第二阶段的PEAP认证是处于TLS安全隧道的保护中的，所以就避免了恶意攻击者嗅探到正确的认证结果信息，从而加强了认证的安全性表
3.
6.
2.
3.
4.1Result－TLV包格式M|RTLVTypeTLVLengthStatusM0–非强制TLV，1–强制TLVR保留位（统一置零）TLVType表
3.
6.
2.
3.
4.2TLV取值意义可取值意义0保留1保留2保留3-AcknowledgedResult（认证结果）因此在ResultTLV包中此项取值为3Length2Status1–Success（认证成功），2–Failure（认证失败）
3.
6.
2.
3.5认证流图及认证步骤PEAP认证的第一阶段Supplicant#0;Authenticator#0;AS#0;AAA/H#0;#0;EAP-Request/Identity#0;EAP-Response/Identity#0;ARDIUSAccess-Request:XXX-Data-cipher-SuiteEAP-Responsepassthrough#0;ARDIUSAccess-Challenge:EAP-Request/PEAP-Start#0;EAP-Requestpassthrough#0;EAP-Response/PEAP:ClientHello#0;ARDIUSAccess-Request:EAP-Responsepassthrough#0;ARDIUSAccess-Challenge:EAP-Request/PEAP:ServerHelloCertificateServerKeyExchangeServerHelloDone#0;EAP-Requestpassthrough#0;EAP-Response/PEAP:ClientKeyExchangeChangeCipherSpecFinished#0;ARDIUSAccess-Request:EAP-Responsepassthrough#0;ARDIUSAccess-Challenge:EAP-Request/PEAP:ChangeCipherSpecFinished#0;EAP-Requestpassthrough#0;EAP-Response/PEAP:EAP-Response/IdentityXXX-Data-Cipher-Suite#0;ARDIUSAccess-Request:EAP-Responsepassthrough#0;ARDIUSAccess-Request:EAP-Response/Identity#0;ARDIUSAccess-Challenge:EAP-Request/MD5-Challenge#0;ARDIUSAccess-Challenge:EAP-Request/PEAP:EAP-Request/MD5-ChallengeXXX-Data-Cipher-Suite#0;EAP-Requestpassthrough#0;EAP-Response/PEAP:EAP-Response/MD5-Challenge#0;ARDIUSAccess-Request:EAP-Responsepassthrough#0;ARDIUSAccess-Challenge:EAP-Response/MD5-Challenge#0;ARDIUSAccess-Accept#0;ARDIUSAccess-AcceptXXX-Data-Cipher-SuiteXXX-Data-Keying-MaterialEAP-Success#0;EAP-Successpassthrough#0;图
3.
6.
2.
3.
5.1PEAP认证交互步骤客户端模块1客户端发出的IDresponse包这儿的ID交换是可选择的不是必须的2客户端接收到PEAP-Start包后开始发起TLS中的握手过程的第一步:clienthello3客户端收到serverhello和服务器证书.则用大家都信任的根证书进行验证如果验证通过，则发送密文族修改协定反之则发送告警信息.以下均以验证通过为例4客户端收到协商好的密文族修改协定则发送TYPE为PEAP的EAP-RESPONSE包，内容为空（TLS的安全通道此时已经建立）5客户端收到服务器的IDrequest包后将自己的ID信息封装在IDresponse包中发送（MyID是客户端的域名，该用户名的传送与否是可选的，通常的作用是引导认证者将客户端的包根据此MyID发送到相应的认证服务器）6客户端收到EAP-X包后如果支持EAP-X认证方式则发送Response如果不支持则发送NAK包7客户端收到确认EAP-X包后确认EAP-X8客户端收到EAP-TLV包后发送EAP-TLV包回应包其中包含认证信息服务器端模块1认证服务器发出IDrequest包2认证服务器收到了客户端发出的IDresponse包在自己的数据库中搜索到了ID则发起PEAP认证即发送PEAP-Start包其中version号为23认证服务器收到clienthello包.发送serverhello并发送自己的证书4服务器收到密文族修改协定则发送协商好的密文族修改协定5认证服务器发出的IDrequest包此时的ID是后面采取的EAP认证方式中所需要的ID号6认证服务器收到了客户端发出的IDresponse包在自己的数据库中搜索到了ID则在安全通道上发起EAP-X认证这儿的X为MD5OTP等EAP认证方式中的一种由服务器自己选取一般的情况下推荐使用MD5认证方式7认证服务器收到客户端同意的EAP-X认证方式.发送确认EAP-X包8认证服务器收到客户端确认的EAP-X包后发送EAP-TLV包TLV是用来在服务器和客户端传递参数的一种方法9认证服务器收到客户端的认证信息验证通过此时认证完毕
3.
6.3口令（强口令）认证方式EAP_MD5CiscoLEAP
3.
6.
3.1基于消息摘要的EAP－MD
53.
6.
3.
1.1概述EAP-MD5方式通过RADIUS服务器提供简单的集中用户认证在这种方式下，RADIUS服务器不需要证书或者安装在无线工作站中的其它安全信息用户注册时，RADIUS服务器只是检查用户名和口令，如果匹配，就通知无线访问点允许该客户端访问网络服务EAP-MD5只提供认证，因此为安全起见，应该与标准的
802.11安全协议WEP/WEP2组合使用，采用40位/128位共享密钥实现加密EAP-MD5是一种单向认证机制，只能保证客户端到服务器的认证，并不保证服务器到客户端的认证
3.
6.
3.
1.2认证步骤及认证流图Supplicant#0;EAP-Request/Identity#0;Authenticator#0;AS#0;#0;#0;EAPOL-START#0;EAP-Response/Identity��MyID��#0;RADIUSAccessRequestEAP-RequestIdentity#0;RADIUSAccessChallengeEAP-Request#0;EAP-Request/MD5-Start#0;EAP-Response/Md5Challenge#0;RADIUSAccessRequestEAP-ResponseMD5Challenge#0;#0;RADIUSAccessaccept#0;EAP-Success#0;图
3.
6.
3.
1.
2.1MD5认证交互步骤客户端模块1）接受认证服务器发出的IDrequest包，发送客户端发出的IDresponse包2）客户端接收到认证服务器发送MD5-Start包后开始发起MD5-Challenge3）接受到Success或者Fail信息服务器端模块4）认证服务器发出的IDrequest包5）认证服务器接收到客户端发出的IDresponse包，则在自己的数据库中搜索到了ID则发起MD5认证即发送MD5-Start包6）认证服务器接收到客户端发出的MD5-Challenge包，进行认证，成功则发Success失败则发Fail信息
3.
6.
3.2支持双方认证的强口令EAP－LEAP
3.
6.
3.
2.1概述LEAP又称为轻量级扩展身份认证协议是Cisco在无线领域取得成功的关键之一LEAP（轻量级可扩展验证协议）是一种主要用于CiscoAironetWLAN中的EAP验证类型它使用在每一次会话过程中动态生成的WEP密钥对数据传输进行加密，并支持相互验证对无线传输的数据来说，采用不断变换的密钥和用户的认证，提供了更大的安全在LEAP认证中，STA和AS都需要产生8个字节的随机数，用不同的加密算法来验证彼此的身份
3.
6.
3.
2.2LEAP认证所需信息PC发送给AP的8个字节的随机数PR24个字节的NtChallengeResponsePCNtPasswordHashUnicodePW由STA将自己的密码加密，发送给AS等待验证APC AP发送的8个字节的随机数MPPEHSAH16个字节md4CalcNtPasswordHashUnicodePWAPR24个字节的ChallengeResponseAPCMPPEHASH，由AS将STA的密码加密，然后将得到的字符串发给STA，等待验证
3.
6.
3.
2.3认证步骤及流图Supplicant#0;EAP-Request/Identity#0;Authenticator#0;AS#0;#0;#0;EAPOL-START#0;EAP-Response/Identity��MyID��#0;RADIUSAccessRequestEAP-RequestIdentity#0;RADIUSAccessChallengeEAP-Request#0;EAP-Request/LEAP-Start#0;EAP-Response/LEAPChallenge#0;RADIUSAccessRequestEAP-ResponseLEAPChallenge#0;#0;RADIUSAccessaccept#0;EAP-Success#0;图
3.
6.
3.
2.
3.1LEAP认证交互步骤客户端模块1）接受认证服务器发出的IDrequest包，发送客户端发出的IDresponse包2）客户端接收到认证服务器发送LEAP-Start包后开始发起LEAP-Challenge3）接受到Success或者Fail信息然后生成8位随机数，发送给认证服务器4）收到认证服务器发回的由随机数产生的加密串，验证认证服务器的身份服务器端模块1）认证服务器发出的IDrequest包2）认证服务器接收到客户端发出的IDresponse包，则在自己的数据库中搜索到了ID则发起MD5认证即发送LEAP-Start包3）认证服务器接收到客户端发出的LEAP-Challenge包，进行认证，成功则发Success失败则发Fail信息4）接受到客户端发送的8位随机数，加密后发送给客户端，等待验证结果
3.
6.4EAP_SIM认证机制EAP_SIM认证协议是由IETF制定的，EAP_SIM认证机制不仅是作为一种无线局域网的安全的认证机制被提出来的，而且也是无线局域网和现有的移动运营商网络结合起来的一项关键技术，在它的制定和完善过程中3GPP组织也有参与EAP_SIM认证技术的核心为借助GSM网络中的用户识别模块SIM卡将WLAN无线接入技术和基于GSM的用户识别模块（SIM）的移动用户管理、蜂窝通信与WLAN接入网间的漫游组合起来，构成一种应用于移动环境中的WLAN接入网结构由于无线局域网的高用户速率，在很大程度上缓解了移动用户的宽带数据业务对核心网的负荷对于无线局域网来讲，采用EAP_SIM认证最直接的优点有两方面其一就是它是一种统一的和更为安全的认证方式，在此认证方式下，所有的用户信息和部分原始鉴权数据、算法都集成在SIM卡上，同时这些数据和算法在HLR/AUC上同样存在，这就避免了在空中传输，所以它比其它典型的用户－密码认证方式更能抵御黑客的攻击；其二，此认证方式可以充分利用已有的GSM网络和数据库资源EAP_SIM认证方式会利用到GSM/GPRS的认证程序，但并非完全相同，这是因为在网路上被盗取资料的可能的危险性很大，为了提供更强大的安全性，除了使用GSM/GPRS的A
3、A8算法以外，还利用其它的算法，包括SHA
1、PRF、HMAC-SHA1等算法在参数方面，除了使用由认证服务器端提供的来自HLR/AUC的三元参数组RAND、Kc、SRES，还需用到由客户端提供的随机数NONCE_MT，来实现客户端和认证服务器的双向认证，即不仅认证服务器端要确认客户端的合法性，客户端也需要确认认证服务器的合法性的，以避免遭到作假的网路黑客窃取客户资料，安全性得到加强SIM卡是EAP_SIM认证方式的灵魂，下面就SIM卡的原理和与之有关的加密算法作一个介绍
3.
6.
4.
1.1概述无线传输比固定传输更易被窃听，如果不提供特别的保护措施，很容易被窃听或被假冒一个注册用户八十年代的模拟系统深受其害，令到用户利益受损，因此GSM首先引入了SIM卡技术，从而使GSM在安全方面得到了极大改进它通过鉴权来防止未授权的接入，这样保护了网络运营者和用户不被假冒的利益；通过对传输加密可以防止在无线信道上被窃听，从而保护了用户的隐私，而且这些保密机制全由运营者进行控制，用户不必加入更显安全由于在GSM通信中引入了SIM卡的技术，使无线电通信从不保密的禁区解放出来，只要客户手持一卡，可以实现走遍世界的愿望SIM卡有许多特点特点之一客户与设备分离人机分开在GSM通信中，SIM卡与移动设备之间已设置一个开放式的公共接口，这样，使用者与自己的设备之间没有互相依存的关系因在SIM卡中存储有持卡者的客户数据、保安数据、鉴权加密算法等，只要客户手持此卡就可以借用、租用不同厂家的移动台，得到卡内存储的各种业务的服务，大大方便了客户，大大增强了GSM通信的移动性，也大大地增强了各生产厂家的设备的共享性特点之二通信安全可靠因为在SIM卡中有一个永久性的存储器，既有存储能力，又有进行计算的能力，所以它属于智能卡当客户建立呼叫时，首先要客户输入个人身份号码PIN，此码由4～8位数字组成，由移动台的键盘键入若输入三次不正确的PIN码后，PIN码被锁，通信终止，这是防范那些伪客户盗用通信的方法之一若有权客户忘记了码或一时疏忽，输入三次错误，可利用SIM卡中存储的0～9位数字的个人解锁钥PUK来解锁PIN码，使之恢复正常但也要特别注意，若输入十次错误的PUK，整个SIM卡就报废了，只有重新购置一个SIM卡才能再进行通信在呼叫建立过程中PIN码正确时，网路开始对客户身份进行鉴权，利用存储在SIM卡中的A
3、A8算法，移动台与网路把计算结果进行比较，相同鉴权成功，这又是防范盗用通信的第二道防线因此GSM通信比模拟移动通信安全可靠特点之三成本低它比电话磁卡的成本低，并且质地结实耐用，易于推广
3.
6.
4.
1.2SIM卡中的保密算法及密钥SIM卡中最敏感的数据是保密算法A
3、A8算法、密钥Ki、PIN、PUK和KcA
3、A8算法是在生产SIM卡的同时写入的，一般人都无法读A
3、A8算法；HN码可由客户在手机上自己设定；PUK码由运营者持有；Kc是在加密过程中由Ki导出；Ki需要根据客户的IMSI和写卡时用的母钥Kki，由运营部门提供的一种高级算法DES，即Ki＝DESIMSI，Kki，经写卡机产生并写入SIM卡中，同时要将IMSI、Ki这一对数据送入GSM网路单元AUC鉴权中心如何保证Ki在传送过程中安全保密是一件非常重要的事情Ki在写卡时生成，同时加密，然后进入HLR／AUC后再解密，那么连写卡和HLR／AUC的操作人员也不知道Ki的真实数据一般流行的做法是用一高级方程DES对Ki进行加密，DES方程需要一把密钥Kdes，加密和解密都用同一把密钥由运营部门提供DES方程给HLR／AUC设备供应商，运营部门制定严格的保密制度，管理好密钥Kdes就能保证Ki传递的安全性
3.
6.
4.
1.3WLAN基于SIM卡的认证系统和GSM系统认证的比较由于基于SIM卡的认证系统的鉴权与加密均是通过系统提供的客户三参数组来完成的先对三元组作一个介绍:客户三参数组的产生是在GSM系统的AUC鉴权中心中完成AUC中还有个伪随机码发生器，用于产生一个128bits不可预测的伪随机数RANDRAND和Ki经AUC中的A8算法也叫加密算法产生一个64bits的c密钥，经A3算法鉴权算法产生一个32bits的响应数SRESRAND、Kc、SRES一起组成该客户的一个三参数组，传送给HLR，存储在该客户的客户资料库中而基于SIM卡认证的WLAN系统希望提高安全性，要求获得n个三元组，协议的推荐值n＝3GSM用户识别模块SIM卡包含IMSI（国际移动用户识别码）、用户身份鉴别码Ki，是认证的原始数据Transform#0;Transform#0;IsSRESequal#0;Mobile#0;Fixednetwork#0;Response��SRES32bits��#0;Challenge��RAND128bits��#0;UserKey#0;YES/No#0;UserKey#0;SRES32bits#0;图
3.
6.
4.
1.
3.1GSM系统认证模式HLR#0;Mobile#0;Fixednetwork#0;Transform#0;��MAC128bitsMACSRES128bits��#0;#0;Triples��RAND3��128bits��SRES4��32bits��Kc4��64bits#0;Challenge��RAND3��128bits��MAC128bits��#0;Transform#0;��MAC128bitsMACSRES128bits��#0;IsMACEqual��#0;#0;Quittheauthenticationprocess#0;YES#0;NO#0;ResponseMACSRES128bits#0;IsMACSRESEqual��#0;YES/NO#0;图
3.
6.
4.
1.
3.2WLAN基于SIM卡的认证模式基于SIM卡的认证系统，不论是GSM系统还是WLAN系统，都是挑战回复认证模式，但是两者的复杂程度不一样如图GSM系统认证模式所示，在GSM系统中只有固定网络（即GMS网络认证中心）对移动用户的认证而用户并不对认证中心进行认证这一点在WLAN基于SIM卡的认证系统中得到了改进，先进行的是客户对认证中心的认证，如图WLAN基于SIM卡的认证模式所示，客户端将来自服务器端通过Challenge报文带来的MAC属性的值域与本地通过同样的数据和算法得到的鉴权码MAC进行比较，若不一致，则客户端认为该认证中心为非法的，则停止该认证进程；若一致，则客户端将本地生成的MACSRES通过Response报文返回认证中心认证中心将接收来的MACSRES与本地的鉴权码MACSRES进行比较，一致，则认证通过，反之发送认证失败信息HLR#0;SHA1#0;MK#0;PRF#0;K_int#0;K_SRES#0;Client#0;MACSRES#0;MAC#0;Equal#0;Nonce#0;SHA1#0;MK#0;PRF#0;K_int#0;K_SRES#0;HMAC#0;HMAC#0;MACSRES#0;MAC#0;Equal#0;SIM#0;A3#0;A8#0;Kc#0;SRES#0;RAND#0;SRES#0;Kc#0;HMAC#0;HMAC#0;AC#0;图
3.
6.
4.
1.
3.3WLAN系统关于认证鉴权码的计算和鉴别Mobile#0;A3#0;#0;RAND#0;Kc#0;SRES#0;HLR#0;#0;#0;IMSI/Ki#0;IsSRESequal#0;AUC#0;YES/No#0;图
3.
6.
4.
1.
3.4GSM系统关于认证鉴权码的计算和鉴别在两个系统中算法和数据的复杂度也不一样GSM系统中，如图GSM系统关于认证鉴权码的计算和鉴别所示只用到一组三元组，而本认证系统使用了三个三元组在前者中，鉴权码只是由一组RAND和Ki经A3算法的来的一个SRES；在后者的认证系统中，利用了三组RAND分别与Ki经过三次计算得到三组SRES和Kc，且并未把SRES和Kc直接作为鉴权码，而是作为产生鉴权码的key，如图WLAN系统关于认证鉴权码的计算和鉴别所示加入了另一些参数经过一系列地算法最终得到鉴权码MAC和MACSRES其中的算法SHA1，PRF参见文献FederalInformationProcessingStandardFIPSPublication180-1HMAC_SHA1参见RFC2104所以WLAN基于SIM卡的认证系统的安全性能在GSM的基础上有所提高
3.
6.
4.
1.4A3/A8算法在GSM网络中的认证和Session密钥产生算法称为A3/A8Comp128-1是A3A8算法的一个例子Comp128-1是一个哈希函数，SIM卡的密钥Ki和一个challenge随机数RAND，经过Comp128-1运算，得到密钥SRES和KcComp128-1的输入是256bits输出是96bits输出结果的左边32bits是SRES，右边的64bits是Kc即（SRES|Kc）=comp128-1KiRANDKi和RAND都是16bytes，令X[
0..15]=KiX[
16..31]=RANDX[
0..31]就是哈希函数的输入值，令T0[
0..511]T1[
0..255]T2[
0..127]T3[
0..63]T4[
0..31]为置换表然后进行8次压缩（利用置换表T0到T4，做5次查表和置换），除了在最后一次循环，其余各次压缩，都还要在查表和置换后，在下次压缩前，对128bits的结果进行一次替换运算这5次查表和置换是这样进行的Fori=0to4do:Forj=0to2i-1do:Fork=0to24-i-1do:s=k+j*25-it=s+24-ix=X[s]+2X[t]mod29-iy=2X[s]+X[t]mod29-iX[s]=Ti[x]X[t]=Ti[y]/*5次查表和置换循环做完后*/Forj=0to32do:Fork=0to4do:xsbit[4*j+k]=x[j]3-k1/*仅不在最后一次循环中做替换*/IFi8Forj=0to16do:x[j+16]=0Fork=0to8do:next_bit=8*j+k*17%128x[j+16]|=xsbit[next_bit]7-k事实上32bytes的输出仅有4个significantbits所以32bytes进行重组后得到16bytes.替换运算后，16bytes的输出更新X[
16..31]Ki更新X[
0..15]重组运算按如下进行Fori=0to4do:simoutput[i]=x[2*i]4|x[2*i+1];Fori=0to6do:simoutput[4+i]=x[2*i+18]6|x[2*i+18+1]2|x[2*i+18+2]2;simoutput[4+6]=x[2*6+18]6|x[2*6+18+1]2;simoutput[4+7]=0;
3.
6.
4.
2.1EAP_SIM报文格式本认证系统只涉及了在EAP_SIM报文地四种类型EAP-Request/SIM/StartEAP-Response/SIM/StartEAP-Request/SIM/ChallengeEAP-Response/SIM/Challenge，下面分别介绍
1.EAP-Request/SIM/Start报文08162431+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|Code|Identifier|Length|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|Type|Subtype|Reserved|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|AT_PERM..._REQ|Length=1|Reserved|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|AT_FULL..._REQ|Length=1|Reserved|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|AT_ANY_ID_REQ|Length=1|Reserved|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|AT_VERSION_L..|Length|ActualVersionListLength|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|SupportedVersion1|SupportedVersion2|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.…….+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|SupportedVersionN|Padding|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type为18表示该EAP报文的类型为EAP-SIMSubtype10，表明这个报文的子类型是StartReserved为0x0000，为保留的2个字节AT_PERMANENT_ID_REQ为
10、AT_FULLAUTH_ID_REQ为
13、AT_PERMANENT_ID_REQ为17这三个属性只会出现一个，本认证系统中只用到了AT_PERMANENT_ID_REQAT_VERSION_LIST为15，Length标识整个AT_VERSION_LIST属性的长度，单位为4Bytes，若AT_VERSION_LIST长度不是4Bytes的整数倍，则在最后补零，即报文中的Padding部分ActualVersionListLength是该属性中真正支持的版本类型个数×2，单位为Byte每个被支持的版本的长度为2个Bytes
2.EAP-Response/SIM/Start报文格式08162431+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|Code|Identifier|Length|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|Type|Subtype|Reserved|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|AT_NONCE_MT|Length=5|Reserved|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|||NONCE_MT|||||+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|AT_IDENTITY|Length|ActualIdentityLength|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+||.Identityoptional..||+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|AT_SELECTED...|Length=1|SelectedVersion|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Code为2表示是Response包Type为18表示该EAP报文的类型为EAP-SIMSubtype10，表明这个报文的子类型是StartReserved为0x0000，为保留的2个字节AT_NONCE_MT属性的Value域包含2bytes的reservedbyte（值为0）和由Client产生的128bits的随机数AT_IDENTITY属性可选Vlaue域以2-byteidentity实际长度开始，接着是subscriber的整数倍，需要时Client应在Identity后补0AT_SELECTED_VERSION属性用在Version的协商中，Value域包含了一个2-byteversion号，表明Client希望使用的版本号
3.EAP-Request/SIM/Challenge报文格式08162431+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|Code|Identifier|Length|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|Type|Subtype|Reserved|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|AT_RAND|Length|Reserved|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+||.n*RAND...||+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|AT_IV|Length=5|Reserved|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|||InitializationVectoroptional|||||+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|AT_ENCR_DATA|Length|Reserved|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+||.EncryptedDataoptional...||+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|AT_MAC|Length=5|Reserved|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|||MAC|||||+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Code为1表示是Request包Type为18表示该EAP报文的类型为EAP-SIMSubtype11，表明这个报文的子类型是ChallengeReserved为0x0000，为保留的2个字节AT_RAND占（4＋n×16）字节，域值为n个RAND（128bits）n=
123.AT_IV可选AT_ENCR_DATA可选AT_MAC占20个字节，其域值携带鉴权码
4.EAP-Response/SIM/Challenge08162431+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|Code|Identifier|Length|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|Type|Subtype|Reserved|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|AT_MAC|Length=5|Reserved|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|||||MAC|||||+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Code2表示Response.Type18表示该EAP报文的类型为EAP-SIMSubtype11表明这个报文的子类型是ChallengeReserved为0x0000，为保留的2个字节，接收时被忽略AT_MACMAC占20个字节，其域值携带鉴权码
3.
6.
4.
2.2用户身份管理GSM用户身份由IMSI表示IMSI由三位的MCC（MobileCountryCode）、两到三位的MNC（MobileNetworkCode）、不多于十位的MSIN（MobileSubscriberIdentificationNumber）三部分组成，也就是说一个IMSI不多于15位，MCC和MNC一起决定了唯一的运营商和对应的认证中心（AuC）因特网AAA协议用NAI（NetworkAccessIdentifier）来标识用户身份如果是一个允许漫游的环境，则该标识由用户名和域名组成，中间由“@”连接但是域名使用与否是可选择的一般情况下域名是由运营商指定，它在客户端是一个可以配置参数运营商可能为EAP_SIM用户制定一个特定的域名，以便在认证过程中从GSM用户中分离出来即使使用临时用户身份，域名的配置和永久用户身份是一致的如果客户端软件不提供配置，客户端可以从MCC和MNC中提取相应的域名信息EAP_SIM支持可选择的用户身份保密，以保护永久用户身份因为永久用户身份是不变的，一旦被窃取，该用户就有可能被跟踪用户永久身份一般是基于IMSI的，而该IMSI还可能用于其它情况，所以有可能涉及其他相应的安全问题用户身份保密是基于临时身份或者伪身份的使用，等价于蜂窝网络的临时TMSI（TemporaryMobileSubscriberIdentities）但又不完全一样EAP_SIM协议中，客户端支持三种类型的用户名I.永久用户名如1123456789098765@myoperator.com是个有效的永久用户身份，则其中的1123456789098765是永久的用户名II.伪用户名如3s7ah6n9q@myoperator.com是个有效的伪用户身份，则其中的3s7ah6n9q是伪用户名III.重认证用户名如53953754@myoperator.com是个有效的重认证用户身份，则其中的53953754是重认证用户名其中伪用户名和重认证用户名属于临时用户名，永久用户名和伪用户名用于完全认证模式中，而重认证用户名用于重认证模式中如果实现中不支持伪用户名则在完全认证中只能用永久用户名在EAP_SIM中，永久用户名源于IMSI，一般在IMSI前加“1”EAP_SIM服务器可以根据这个处于用户名起始位置的“1”来决定选用EAP_SIM认证方式，而不是其它的方式当然也有情况永久用户名并非源之IMSI，协议不作讨论伪用户名和重认证用户名一般由EAP服务器通过一定的规则产生不论采用何种规则来产生伪用户名和重认证用户名，它们必须是有效的、唯一的EAP服务器需要建立伪用户名、重认证用户名与永久用户名的对应关系为了更好的区别永久用户名、伪用户名和重认证用户名，可以协定永久用户名以“1”开始、伪用户名以“2”开始、重认证用户名以“3”开始考虑到客户端可能没有能保存来自EAP-Request/SIM/Challenge报文中的伪用户名，所以EAP服务器应至少保存每一个用户的最近一次的伪用户名EAP服务器以加密的方式将伪用户身份和重认证用户身份封装在EAP-Request/SIM/Challenge报文的属性AT_ENCR_DATA中一旦收到带有属性AT_ENCR_DATA的EAP-Request/SIM/Challenge报文，客户端会对属性AT_ENCR_DATA的值域进行解密以获得伪用户身份或者重认证用户身份，以备下一次使用如果客户端没有接受到新的伪用户身份，在下一完全认证的时候它可能会使用之前已经用过的伪用户身份，但是重认证用户名则只能用一次，不可重复使用；由于用户身份保护和重认证机制的支持是可选择的，所以客户端有可能忽略报文中的属性AT_ENCR_DATA而继续使用永久用户身份一般情况下，客户端通过EAP-Response/Identity报文将用户身份传递给EAP服务器但是如果服务器端没有从EAP-Response/Identity报文中得到它认为有效的用户身份时，它会在发送的EAP-Request/SIM/Start报文中包括属性AT_ANY_ID_REQ（要求返回永久用户身份、伪用户身份或重认证用户身份）、AT_FULLAUTH_ID_REQ（要求返回永久用户身份或伪用户身份）或AT_PERMANENT_ID_REQ（要求只能返回永久用户身份），客户端会在它发送的EAP-Response/SIM/Start报文中包括封装有符合相应要求的用户身份的属性AT_IDENTITY用户身份的传输可能会遭遇这样的攻击网络窥探者可能给客户端发送一个封装有属性AT_PERMANENT_ID_REQ的EAP-Request/SIM/Start报文以刺探用户永久身份对应这样的攻击有两种客户端策略一种是保守型策略，如果该客户端拥有伪用户身份，它就认为网络可以通过它保存的伪用户身份和永久用户身份的对应关系得到它的永久用户身份，发送EAP-Response/SIM/Client-Error来拒绝此请求（如果客户端认为它拥有的伪用户身份可能过期，则可能会应答该请求），这样做的好处在于很好的保护了用户的永久身份；另一种是开放型策略，对这样的请求一律应答，因为有时网络可能会丢失用户伪身份和永久身份的对应关系，这样不至于否定合理的请求
3.
6.
4.
2.3EAP_SIM认证流程概述
3.
6.
4.
2.
3.1完全认证如图4-1所示，这是一个EAP_SIM完全认证的流程，在这里只给出客户（Client）和认证者（Authenticator）之间的交互过程第一步，认证者发送EAP-Request/Identity报文，客户回复报文中包括用户身份，这一步在所有的EAP认证机制中都需要进行第二步，认证者向客户发送EAP-Request/SIM/Start请求报文，这是EAP_SIM认证的开始其中包括EAP服务器端支持的版本列表属性，如果在上一步中EAP服务器端没有接收到有效的用户身份，则在本报文中需再次要求客户端发送有效的用户身份的属性客户端返回EAP-Response/SIM/Start报文，包括一个16字节随机数的NONCE_MT属性和客户端支持的版本的属性（如果被要求发送用户身份的话，还应包括身份属性）在接收到EAP-Response/SIM/Start报文以后，EAP服务器获取n个GSM网络三元组，这里n可以为2或3，作为生成认证码的种子之一，具体实现在后续章节中有详述#0;Client#0;Authenticator#0;EAP-Request/Identity#0;EAP-Response/Identity#0;EAP-Request/SIM/StartAT_VERSION_LIST#0;EAP-Response/SIM/StartAT_NONCE_MTAT_SELECTED_VERSION#0;EAP-Request/SIM/ChallengeAT_RANDAT_MAC#0;PeerrunsGSMalgorithmsverifiesAT_MACandderivessessionkeys#0;EAP-Response/SIM/ChallengeAT_MAC#0;EAP-Success#0;图
3.
6.
4.
2.
3.
1.1完全认证流程第三步，认证者向客户发送EAP-Request/SIM/Challenge报文，包括三元组中的一元RAND和认证码AT_MAC客户端一旦收到这个报文，利用与服务器端同样的参数和算法计算认证码AT_MAC若与接收到的AT_MAC不一致，则客户对网络的认证不通过，客户端发送EAP-Response/SIM/Client-Error报文，认证中断；反之，客户端发送EAP-Response/SIM/Challenge报文，包括另一个的认证码，由服务器端来判断该认证码的有效性第四步，如果所有的交互通过，则服务器端发送认证成功报文EAP-Success
3.
6.
4.
2.
3.2重认证在有些情况下，EAP认证需要被频繁的执行以提高安全性而EAP_SIM的完全认证模式需要用到GSMSIM的A3/A8算法和来自认证中心的参数组，开销较大，所以EAP_SIM完全认证的不适合频繁的使用EAP_SIM重认证是一种开销相对小的多的认证模式，它不需要用到SIM的A3/A8算法和来自认证中心的参数组，而且它的认证交互的过程也比完全认证要简洁的多重认证对于客户端和服务器都是可选的，只用当双方都支持时才可使用重认证基于之前进行的完全认证过程中产生的主密钥（MK）生成一个新的主会话密钥（MSK），也需要用到与前一次完全认证中产生的密钥K_aut和K_encr来实现对EAP_SIM报文和属性的保护在重认证模式下，客户端使用一个封装在属性AT_COUNTER中的16比特的计数器来限制重认证次数每次进行一次完全认证，客户端和服务器均将该计数器值置为1，在第一次进行重认证时计数器的值至少为1，以后每进行一次重认证，计数器值随之增大，所以理论上重认证次数的最大值可达到65535在重认证模式下，客户端和服务器均需保存如下的数据主密钥（MK）、当前计数器值、下一个重认证用户身份、K_aut和K_encr（这两个密钥可以由MK重新产生）服务器端还需要保存用户永久身份和重认证用户身份的对应关系重认证模式使用独立的用户身份，即重认证用户身份，而用户伪身份和永久身份均用于完全认证模式中如果重认证用户身份丢失或者网络无法解析它则网络认证模式重新返回到完全认证模式如果EAP服务器支持重认证模式，则可能会在EAP-Request/SIM/Challenge报文中封装属性AT_NEXT_REAUTH_ID，其中包括一个用于下一次重认证的重认证用户身份客户端可以忽略这个属性，这样下一次继续使用完全认证模式；相反如果客户端希望使用重认证模式，则解析并保存该重认证用户身份，以备下一次使用Client#0;Authenticator#0;EAP-Response/SIM/Re-authenticationAT_IVAT_ENCR_DATA*AT_COUNTERwithsamevalueAT_MAC#0;EAP-Request/SIM/Re-authenticationAT_IVAT_ENCR_DATA*AT_COUNTER*AT_NONCE_S*AT_NEXT_REAUTH_IDAT_MAC#0;Serverrecognizestheidentityandagreesonusingfastre-authentication#0;EAP-Request/Identity#0;EAP-Response/IdentityIncludesare-authenticationidentity#0;PeerverifiesAT_MACandthefreshnessofthecounter.PeerMAYstorethenewre-authenticationidentityfornextre-auth.#0;SerververifiesAT_MACandthecounter#0;EAP-Success#0;图
3.
6.
4.
2.
3.
2.1完整的重认证流程完整的重认证流程如图所示第一步，服务器端要求用户身份，客户端给出重认证用户身份第二步，服务器端辨认出接收到的重认证用户身份并同意进入快速的重认证模式，发送EAP-Request/SIM/Re-authentication报文，其中包含封装有鉴权码的属性AT_MAC第三步，客户端利用和EAP服务器端相同的参数和算法计算出鉴权码，与接收到的进行比较，若一致，则发送EAP-Response/SIM/Re-authentication报文，其中封装另一个鉴权码第四步，服务器将接收到的鉴权码和本地的另一鉴权码作比较，若一致则发送认证成功报文EAP/Success
3.
6.
4.
2.
3.3用户身份相关消息流局部解析用户身份的获取是认证流程的核心，本节重点解析一下客户端和EAP服务器之间与用户身份相关的消息流的交互过程1完全认证模式，如图4-2所示在EAP_SIM开始时服务器还没获得用户身份，则发送EAP-Request/SIM/Start报文，其中包括属性AT_ANY_ID_REQ、AT_VERSION_LIST客户端返回相应的EAP-Response/SIM/Start报文包括属性AT_IDENTITY、AT_NONCE_MT、AT_SELECTED_VERSION其中属性AT_IDENTITY中封装的可能是用户的永久身份或者伪身份ServerdoesnothaveanySubscriberidentityavailableWhenstartingEAP/SIM#0;Client#0;Authenticator#0;EAP-Request/SIM/StartAT_ANY_ID_REQAT_VERSION_LIST#0;EAP-Response/SIM/StartAT_IDENTITYAT_NONCE_MTAT_SELECTED_VERSION#0;图
3.
6.
4.
2.
3.
3.1完全认证模式2重认证模式，如图4-3所示在EAP_SIM开始时服务器还没获得用户身份，则发送EAP-Request/SIM/Start报文，其中包括属性AT_ANY_ID_REQ、AT_VERSION_LIST客户端返回相应的EAP-Response/SIM/Start报文包括封装有重认证用户身份的属性AT_IDENTITYServerdoesnothaveanySubscriberidentityavailableWhenstartingEAP/SIM#0;Client#0;Authenticator#0;EAP-Request/SIM/StartAT_ANY_ID_REQAT_VERSION_LIST#0;EAP-Response/SIM/StartAT_IDENTITYcontainingare-authenticationidentity#0;图
3.
6.
4.
2.
3.
3.1重认证模式Serverdoesnotrecognizethere-authenticationIdentity#0;EAP-Request/SIM/StartAT_FULLAUTH_ID_REQAT_VERSION_LIST#0;Client#0;Authenticator#0;EAP-Response/SIM/StartAT_IDENTITYwithafull-authidentityAT_NONCE_MTAT_SELECTED_VERSION#0;EAP-Request/SIM/StartAT_ANY_ID_REQAT_VERSION_LIST#0;EAP-Response/SIM/StartAT_IDENTITYcontainingare-authenticationidentity#0;ServerdoesnothaveanysubscriberidentityavailablewhenstartingEAP/SIM#0;图
3.
6.
4.
2.
3.
3.2返回完全认证模式3返回完全认证模式，如图4-4所示在EAP_SIM开始时服务器还没获得用户身份，则发送EAP-Request/SIM/Start报文，其中包括属性AT_ANY_ID_REQ、AT_VERSION_LIST客户端返回相应的EAP-Response/SIM/Start报文，包括封装有重认证用户身份的属性AT_IDENTITY服务器接收到该重认证用户名无法解析，继续发送EAP-Request/SIM/Start报文，包括属性AT_FULLAUTH_ID_REQ，AT_VERSION_LIST客户端返回相应的EAP-Response/SIM/Start报文其中包括属性AT_IDENTITY、AT_NONCE_MT、AT_SELECTED_VERSION属性AT_IDENTITY中封装了完全认证所需的伪用户身份或者永久用户身份4要求永久用户身份模式一，如图4-5所示在EAP认证一开始，服务器发送EAP-Request/Identity报文客户端返回EAP-Response/Identity，其中封装了用户伪身份但是服务器无法解析该用户伪身份，在EAP_SIM认证的开始报文EAP-Request/SIM/Start包括属性AT_PERMANENT_ID_REQ，要求客户返回用户永久身份客户在返回的相应的EAP-Response/SIM/Start报文中封装用户永久身份EMBEDVisio.Drawing.6Serverfailstomapthepseudonymtoapermanentid.#0;Client#0;Authenticator#0;EAP-Response/SIM/StartAT_IDENTITYwithapermanentidentityAT_NONCE_MTAT_SELECTED_VERSION#0;#0;EAP-Request/SIM/StartAT_PERMANENT_ID_REQAT_VERSION_LIST#0;EAP-Request/Identity#0;EAP-Response/IdentityIncludesapseudonym#0;图
3.
6.
4.
2.
3.
3.3要求永久用户身份模式一5要求永久用户身份模式二，如图4-6所示在EAP_SIM开始时服务器还没获得用户任何身份，发送EAP-Request/SIM/Start报文，其中包括属性AT_ANY_ID_REQ、AT_VERSION_LIST客户端返回封装有用户伪身份的EAP-Response/SIM/Start报文但是服务器无法将接收到的用户伪身份映射成相应的永久身份，再次发送EAP-Request/SIM/Start报文，其中包括AT_PERMANENT_ID_REQ，要求客户端返回用户永久身份客户端再次回复EAP-Response/SIM/Start报文，其内包括封装有用户永久身份的属性AT_IDENTITYServerfailtomapthepseudonymintheAT_IDENTITYtoavalidpermanentidentity#0;EAP-Request/SIM/StartAT_PERMANENT_ID_REQAT_VERSION_LIST#0;Client#0;Authenticator#0;EAP-Response/SIM/StartAT_IDENTITYwithapermanentidentityAT_NONCE_MTAT_SELECTED_VERSION#0;EAP-Request/SIM/StartAT_ANY_ID_REQAT_VERSION_LIST#0;EAP-Response/SIM/StartAT_IDENTITYwithapseudonymidentityAT_NONCCE_MTAT_SELECTED_VERSION#0;ServerdoesnothaveanysubscriberidentityavailablewhenstartingEAP/SIM#0;图
3.
6.
4.
2.
3.
3.4要求永久用户身份模式二这是最差的一种情况，为获得用户身份，服务器和客户端经历了三次EAP_SIM/Start交互，如图4-7对于服务器的用户身份的请求，客户端第一次返回的是重认证用户身份，服务器不支持重认证机制，要求客户端发送完全认证所需的用户身份；客户端第二次返回用户伪身份，服务器无法映射成相应的用户的永久身份，要求客户端发送用户永久身份；客户端第三次返回用户永久身份，服务器最终获得认证所需的有效的用户身份
3.
6.
4.
2.4系统组成本系统包括归属位置寄存器/认证中心（HLR/AUC）、移动应用协议（MAP）、远程拨号用户认证（RADIUS）、无线局域网（WLAN）各部分间的接口如图5-1所示1鉴权服务器鉴权服务器是用户管理的主要控制点，每个实体支持多个接入控制器并给漫游的用户提供鉴权、计费等业务鉴权服务器通过鉴权、认证和计费（AAA）的远程拨号用户认证（RADIUS）鉴权协议与接入控制器联络鉴权服务器以七号信令把GSM鉴权信息送到归属位置寄存器（HLR），并以贮存在SIM卡中的GSM国际移动用户身份（IMSI）码识别用户2）接入控制器在无线接入网与固定IP骨干网之间充当Internet网关功能将需要访问控制的局域网与Internet连接起来；实施对网络的业务控制和计费信息采集，并对网络的监控3）线接入点它是WLAN业务网络的小型无线基站设备，完成
802.11b标准的无线接入功能无线接入点AP也是一种网络桥接器，是连接有线网络与无线局域网络的桥梁，WLAN终端设备可通过相应的AP接入外部的网络资源在数据通讯方面，AP负责完成它与终端设备之间空间传输数据包的加密和解密4移动终端安装有无线网卡、SIM卡读卡器以及SIM鉴权软件的终端都具有获得WLAN无线接入的能力WLAN������#0;WLAN������#0;WLAN������#0;����������#0;����������#0;HLR/AUC#0;��������#0;��������#0;MAP#0;RADIUS#0;������������������#0;��������#0;图
3.
6.
4.
2.
4.1应用于移动环境中的WLAN接入网结构
3.
6.
4.
2.5认证流程实现基于SIM卡的鉴权认证是WLAN接入移动环境的第一步也是关键的一步，下面给出完整认证流程实现，如图所示
1.WLAN用户的无线网卡和所接入的认证者之间建立好物理连接之后，Client向认证者发送EAPoL-Start报文请求认证，开始
802.1x接入流程
2.在任何一种认证方式下，用户身份是必需的，而且应该是在认证最初的时候给出，AC收到认证请求后向客户端发送EAP-Request/Identity报文，要求客户端回应用户身份
3.在基于SIM卡的认证方式下协议草案给出用户身份的建议形式如下1IMSI@realm这里的“1”用来告知EAP认证服务器启用EAP_SIM认证方式，而不是EAP/AKA或者其他的EAP认证方式；IMSI是用于表示GSM用户的移动业务国家号码，它由三部分组成MCC＋MNC＋MSIN，是一个长度不超过15个数字的字符串realm即域名，认证服务器通过它来获取相应的运营商，如域名CMCC.COM代表移动，UNION.COM代表联通客户端将用户身份封装在EAP-Reponse/Identity报文内返回给认证者
4.认证者将从客户端接受到的EAP包封装成RADIUS/Access-Request/EAP-message/EAP-Response/Identity包，发往认证服务器，服务器从获取的包提取客户信息，包括域名realm和客户的IMSI
5.认证服务器判断获取的用户身份是否有效，若无效则在返回报文中包含一个要求再次发送用户身份的请求的属性，并且将本服务器的允许的版本列表包含在返回报文中，以RADIUS/Access-Challenge/EAP-message/EAP-Request/SIM/Start报文格式发送该回复报文，进入EAP_SIM认证过程
6.认证者将从服务器端获取的RADIUS包剥去包头，将其中的EAP报文发送给客户端
7.客户端从报文中提取允许的版本列表，将自身的版本与其进行比较，若为其中之一，则认证继续；若客户端的版本不同于服务器端允许的版本中的任何一个，则认证中断
8.客户端将本地生成的一个128bits的随机数NONCE_MT封装在EAP-Response/SIM/Start报文发送给认证者（若在之前接收到的报文中要求客户端再次发送用户身份，则在本报文中还需封装入用户身份属性
9.认证者将收到的报文封装成RADIUS/Access-Request/EAP-message/EAP-Response/Start报文发送至认证服务器
10.服务器再次确认是否已受到有效的用户身份，若是则认证继续，则将用户信息中的IMSI提取出来，封装在RADIUS－Access报文中发送往MAP网关；反之认证中断，返回RADIUS/Access-Reject报文
11.MAP网关在接收到报文中的用户IMSI提取出来封装成MAP-AuthInfo-Req报文通过SS7网络发往HLR/AUC
12.HLR/AUC鉴别接收到的用户IMSI是否合法，若合法则将认证三元参数组（RAND、Kc、SRES）封装在MAP-AuthInfo-Resp报文中通过SS7信令发往MAP网关
13.MAP网关将接收到的三元组的信息重新封装成RADIUS-Accept报文格式发往RADIUS服务器
14.认证服务器根据给定的算法，利用已获取的参数计算出鉴别码MAC和MACSRES，认证服务器将RAND，MAC封装在RADIUS/Access-Challenge/EAP-message/EAP-Request/SIM/Challenge报文中返回给认证者
15.认证者剥离收到的RADIUS报文包头，以EAP-Request/SIM/Challenge的报文形式发送给客户端
7.��������������������������������������������������������������������������������������#0;
16.��������������������MAC1����������MAC1����������������������������������������#0;
19.��������������������MAC2����������MAC2��������������������������������������������������������������#0;Client#0;AC#0;
1.EAPoL_Start#0;
2.EAP-Request/Identity#0;
3.EAP-Response/Identity#0;
4.Access-RequestEAP-Message#0;
10.Access-RequestIMSI#0;
11.MAPsendauthinfoReqIMSI#0;
12.MAPsendauthinfoRespKcRANDSRES_n#0;
13.Access-AcceptAuthTriplesKcRANDSRES_n#0;
5.Access-ChallengeEAP-Message#0;
6.EAP-Request/SIM/Start#0;AS#0;
17.EAP-Response/SIM/Challenge#0;
14.Access-ChallengeEAP-Message#0;
8.EAP-Response/SIM/Start#0;
9.Access-RequestEAP-Message#0;
18.Access-RequestEAP-Message#0;
20.Access-Accept/Access-Reject#0;
21.EAP-Success/EAP-Failure#0;MAPGateway#0;
15.EAP-Request/SIM/Challenge#0;HLR/AUC#0;图
3.
6.
4.
2.
5.1认证实现流图
16.客户端利用和认证服务器端一致的参数和算法得出MAC和MAC_SRES，将本地生成的鉴别码MAC和所收报文中提取的MAC进行比较，若不一致则认证中断；反之认证继续这个过程相当于客户端对服务器端进行了一次认证，一旦这次认证通过，客户端认为网络是可以信任的
17.客户端将本地的生成的参数MACSRES封装在EAP-Response/SIM/Challenge报文中，发往认证者
18.认证者将收到的报文封装成RADIUS/Access-Request/EAP-message/EAP-Response/Challenge报文发送至认证服务器
19.认证服务器提取报文中的MACSRES与本地的MACSRES比较是否一致，若一致，则认证服务器返回RADIUS/Access-Accept报文；反之则返回RADIUS/Access-Reject报文此过程是服务器对客户端的认证，防止非法用户占用或入侵系统资源
20.按照上述的认证结果发送Access/Accept或Access/Reject报文
21.认证者根据从认证服务器接收到的认证结果，告知用户认证结果EAP/Success或者EAP/Failure
3.
6.
4.
2.6具体实现由于在试验阶段没有办法与GSM网络核心网进行交互，在具体实现中只包括客户端、认证者和认证服务器三部分（处于客户端和认证者中间的接入点是透传方式，所以不加讨论），三者的通信协议栈层次如图5-3所示而本该从核心网中获取的数据由AS来模拟建立一个数据库以存放试验SIM卡的Ki值；设置一个随机数发生器以产生三元参数组中的参数RAND；实现A3/A8算法以计算得到密钥种子Kc和SRES图
3.
6.
4.
2.
6.1客户端、认证者和服务器三者通信协议栈层次
3.
6.
4.
2.
6.1客户端客户的操作、接收的报文的内容、各个定时器决定的状态机状态的转移，客户端的运作由状态机状态的转移决定客户端内部数据流图如图5-4所示������#0;��������#0;����
802.1x��������������������������������������������������������������������������������������������������������������������#0;��������������������������������������SIM������������#0;����������������������������������������������������������������#0;EAP/SIM#0;����������#0;����������������������#0;��������������������������������������������#0;图
3.
6.
4.
2.
6.
1.1客户端系统流程图
3.
6.
4.
2.
6.
1.1用户界面用户可以在客户界面上选择网卡类型、认证方式和认证者，如图5-4所示确定连接后，首先进行初始化模块，主要是SIM卡信息的获取一旦获取了有效的用户信息，客户端发出认证请求，要求和认证者进行对话，所有对话的EAP报文都是封装于EAPOL报文内，适于在局域网内传输图
3.
6.
4.
2.
6.
1.
1.1客户界面我们采用了北京飞天诚信公司的坚石100型SIM卡读卡器，这款SIM卡读卡器采用的是USB接口，支持ISO7816-1/2/3和PC/SC标准随读卡器还附带了读用户信息的接口程序SIMID
0820.exe，通过该公司给我们提供了读卡器的开发组件和和相应的接口动态链接库（GSMLogin.dll），以及读取SIM卡的Kc、IMSI和SRES的函数接口，如GLOG_InitGLOG_FinalGLOG_OpenGOLG_CloseGLOG_GetPinStateGLOG_VerifyPinGLOG_ReadIMSIGLOG_RunAlgorithm，通过隐式调用GSMLogin.dll中的函数GLOG_ReadIMSIGLOG_RunAlgorithm可向客户端程序提供所需的Kc、IMSI和SRES三个参数，以实现EAP_SIM协议中的对用户的认证
3.
6.
4.
2.
6.
1.2客户端包处理模块#0;#0;#0;#0;#0;#0;����EAP/SIM����Subtype����#0;����EAP/SIM����AT_VERSION_LIST��������#0;������128bits����������AT_NONCE��������#0;������������AT_SELECT_VERSION��������#0;����EAP/SIM����AT_RAND��������#0;��������RAND����SIM������������Kc��SRES#0;��AT_VERSION_LIST��AT_SELECT_VERSION��AT_NONOCE��Kc��IMSI����K_aut��K_sres#0;��K_aut|AT_NONOCE|EAP/SIM������������MAC#0;����EAP-Response/SIM/Start������������AT_NONOCE��AT_SELECT_VERSION����������������������������������������������������AT_IDENTITY#0;��������������MAC����������MAC#0;������������#0;��K_sres|SRES|messagesubtype��������������MACSRES#0;����EAP-Request/SIM/Challenge������������������MACSRES������AT_MAC#0;Subtype=10#0;Subtype=11#0;EAP��#0;图
3.
6.
4.
2.
6.
1.
2.1客户端包处理模块流程包处理模块对来自基于
802.1x的状态机模块发来的EAP-SIM/Request帧进行分析，如图5-7所示，通过帧中的subtype域判断此帧是EAP-Request/SIM/Start还是EAP-Request/SIM/Challenge如果是Subtype为10，即接收到的为EAP-Request/SIM/Start帧
1.从帧中提取AT_VERSION_LIST属性的域值，作为后续交互认证的认证码的计算因；
2.从该版本列表中选取适合本客户端的版本；
3.本地生成一个16Bytes的随机数作为AT_NONCE属性的域值；
4.发送EAP-Response/SIM/Start帧，内含AT_NONCE属性和AT_SELECTED_VERSION属性如果是Subtype为11，即接收到的为EAP-Request/SIM/Challenge帧
1.从帧中提取AT_RAND属性的域值，作为生成Kc和SRES的因子；
2.将得到的RAND通过读卡器写入SIM卡，由SIM卡的内置算法A3和A8计算得到Kc和SRES（其中Kc＝A3（RAND，Ki）、SRES＝A8（RAND，Ki））；
3.MK=SHA1Identity|n*Kc|NONCE_MT|VersionList|SelectedVersion在将MK作为一个随机数生成器的因子，得到随机数K_int128bits和K_sres128bitsAT_MAC=HMAC-SHA1-128K_int整个EAP帧，涉及MAC的域值置0，AT_MAC_SRES=HMAC-SHA1-128（K_sresn*SRES|messagesubtype，messagesubtype为此EAP帧的子类型）；
4.比较本地生成的AT_MAC（128bits）和接收到的值是否一致，若不一值，则弃包；若一致，发送EAP-Response/SIM/Challenge帧，内含AT_MAC属性，其域值为本地生成的AT_MAC_SRES（128bits）
3.
6.
4.
2.
6.2认证者在系统的接入控制器上安装有基于
802.1x的认证者，支持用户与认证服务器之间的多种EAP认证方式认证者与客户端的通讯需要用到原始帧（原始帧的收发采用libnet库和pcap库）；认证者与认证服务器的通讯为UDP层的通讯（UDP的收发采用socket），如图5-8所示������#0;������#0;������#0;������#0;RADIUS��#0;图
3.
6.
4.
2.
6.
2.
1.认证者与客户端、服务器的通讯这里采用的是EAP终结方式，即EAP报文中的认证信息被提取出来之后，封装成标准RADIUS报文，并送到RADIUS服务器，或者将受到的RADIUS报文拆封，提取EAP报文封装成原始帧发往客户端，如图5-9所示，当认证者收到报文时首先作一个判断
1.若是来自认证服务器端的报文，在判断报文可靠性以后提取EAP帧封装成原始帧发往客户端；
2.若是来自客户端的报文，则需判断是否为EAPOL_Start报文，若是则将EAP-Request/Identity报文封装成原始帧发往客户端以取得用户身份；若不是则从报文中提取EAP报文封装在RADIUS报文中发往认证服务器#0;#0;#0;������������#0;����������EAPOL_START����#0;����������������������������������EAP��������RADIUS������������������#0;����������#0;��������������#0;#0;#0;����������������������������������EAP������������������������#0;#0;#0;#0;Yes#0;��EAP-Request/Identity��������������������������#0;#0;#0;#0;#0;No#0;��������#0;图
3.
6.
4.
2.
6.
2.2认证者包处理流图由此可见，在认证的过程中认证者充当了中继的角色，而且与具体的认证方式基本没有关系
3.
6.
4.
2.
6.3认证服务器#0;#0;#0;������1#0;������2#0;������n#0;����������������UDP��������������������������������������������������������������������������#0;RADIUS/EAP-Message#0;RADIUS/EAP-Message#0;RADIUS/EAP-Message#0;����������������������������������������SIM����Ki��IMSI��������������������HLR��������������������A3/A8��������AUC������AS��������#0;图
3.
6.
4.
2.
6.
3.1服务器端系统流程图这里的认证服务器采用单线程的方式通过UDP套接字方式获取各认证者的报文为了使来自各客户的信息保持相互独立，设计了一个客户链typedefstructuserInfo{unsignedchar*UserName;unsignedcharUserNameLen;unsignedcharIMSI[IMSILEN];unsignedchar*Realm;BoolIdExist;unsignedcharKi[KILEN];unsignedcharRAND[NUMTRIPLE][RANDLEN];unsignedcharSRES[NUMTRIPLE][SRESLEN];unsignedcharKC[NUMTRIPLE][KCLEN];unsignedintMK
[5];unsignedcharK_int[KEYLEN];unsignedcharK_sres[KEYLEN];unsignedcharAuthMAC[AUTHMACLEN];unsignedcharAuthLocMACSRES[AUTHMACLEN];unsignedcharAuthRecvMACSRES[AUTHMACLEN];unsignedcharRecvNonc
[16];unsignedcharRecvVersion
[2];unsignedcharRecvAuthVector
[16];BoolAuthResult;structuserInfo*next;}USERINFO链中每一个元素均为一个客户信息结构，当服务器端收到一个报文，根据它的用户身份，即链中变量UserName的值确定客户链中是否包括该客户，若已存在，则只需记录客户信息至该客户信息结构中；若不存在则在此链中加入这个客户，并保存获得信息至该客户信息结构中根据协议，认证服务器在接收到有效的用户信息后应将其发往GSM网络的认证中心（AUC）以获取用于产生认证鉴别码的2或3个三元参数组但是因为目前条件不成熟，通过收集试验用的SIM卡的Ki和IMSI在认证服务器上建立数据库来模拟HLR；同样，在认证服务器上设定随机数发生器以及A3/A8算法来模拟AUC认证服务器在接收到来自某个客户的报文时，处理模块流程如图5-
11、5-12所示，首先通过报文的包头的各项指数判断该报文的可靠性，有任何一项不符合，均把报文丢弃而不作任何回复再根据它的用户身份判断该客户是否已在客户链表内，若不存在则为此客户申请一个客户信息结构并将该结构加入客户链表，之后将其中的EAP帧作深度分析
1.判断EAP帧的类型若类型既不是1也不是18，则丢弃该报，不作任何回复；
2.若是1，则此为EAP-Response/Identity帧，其内包含用户身份信息，提取该用户身份并判断其是否有效若有效，则该客户的信息结构中的变量IDExist为True，反之为False发送RADIUS/Access-Challenge报文，其内封装了EAP-Request/SIM/Start报文，包含了AT_VERSION_LIST属性，若IDExist为False的话，帧中还应包含属性AT_PERMANENT_ID_REQ（本实现版本中没有选择支持伪用户身份和重认证）
3.若是18，则为EAP_SIM帧，根据其中的subtype域值判断它是EAP-Response/SIM/Start帧是EAP-Response/SIM/Challenge帧若是EAP-Response/SIM/Start帧，a判断该帧中是否含有AT_IDENTITY属性以及其内是否含有有效的用户身份信息，若有则修改该客户的信息结构中的变量IDExistb判断IDExist，若为False，则发送RADIUS/Access-Reject报文，认证结束并从客户链表中删去该客户信息；若为True，则将该用户身份分解，分别提取IMSI（客户识别码）和Realm（域名），根据该AS上的IMSI数据库判断该客户的合法性c若确定该客户为非法客户，则认证者返回RADIUS/Access-Reject报文，认证结束并从客户链表中删去该客户信息；反之，认证服务器调用相应的算法计算三元组（RAND，SRES，Kc）并保存至该客户信息结构中d保存EAP-Response/SIM/Start帧中属性AT_NONCE的域值和属性AT_SELECTED_VERSIONS的域值e利用与客户端相同参数和算法计算鉴别码MAC128bits和MACSRES128bitsf发送RADIUS/Access-Challenge报文，其内封装了EAP-Request/SIM/Challenge帧，包含了属性AT_RAND和AT_MAC；若为EAP-Response/SIM/Challenge帧，a提取帧中AT_MAC属性的域值，即鉴别码MACSRESb将获取的MACSRES与本地的MACSRES比较，若一致则发送RADIUS-Accept报文，其内封装了EAP-Success帧，反之发送RADIUS-Reject报文，其内封装了EAP-Fail帧c不管发送的是认证成功抑或是认证失败的报文都需从客户链中删除该客户信息结构#0;#0;#0;������������������Radius������������������#0;����RADIUS/Access-Challenge����������������EAP-Response/SIM/Start������AT_VERSION_LIST��������IDExist��False��������AT_PERMANENT_ID_REQ������#0;#0;����������#0;����#0;����#0;����RADIUS������Code����#0;������������Identifier��athenticator������#0;����������������#0;#0;#0;RADIUS����#0;0CodeCode16#0;Code=0||Code16#0;����RADIUS����������EAP����������������packet#0;Type��79#0;Type����79#0;����EAP����code��#0;Code4#0;Code��4#0;����EAP����Identifier����#0;����EAP��������#0;����#0;����#0;����#0;������EAP������Identity��������������������ID#0;����#0;Type!=18Type!=1#0;������EAP����Identity������������������������������IDExist��True#0;������EAP����Identity������������������������������IDExist��False#0;��������������IP������������������������������������������������������������������������#0;Type=1||Type=18#0;Type=1#0;Type=18#0;��������#0;No#0;Yes#0;图
3.
6.
4.
2.
6.
3.2服务器端包处理模块#0;#0;#0;����EAP����������#0;True#0;EAPType=18#0;False#0;Subtype��10#0;Subtype��11#0;����IDExist#0;��������������������������������RAND��Kc��SRES��#0;��������ID������������realm������realm����������������������SS7/MAP��������������������������������������#0;������������������������������#0;True#0;IDExist��True#0;����RADIUS/Access-Challenge/EAP-SIM/Challenge������AT_RANDAT_MAC����#0;False#0;True#0;����RADIUS/Access-Reject��������������������������#0;����RADIUS/Access-Reject��������������������������#0;������������������AT_NONCE������������AT_SELECTED_VERSION������#0;��������������������������������AT_MAC��MACSRES����128bits#0;False#0;����������������AT_MACSRES������������#0;��������MACSRES��������MACSRES#0;����������������RADIUS/Access-Accept����������EAP/Success��#0;����������������RADIUS/Access-Reject����������EAP/False��#0;图
3.
6.
4.
2.
6.
3.3服务器端包处理模块（续）
3.
6.
4.
2.
6.4MAP网关MAP（MobileApplicationPart，移动应用部分）在SS7协议栈的位置如图5-13所示它提供位置管理、用户数据管理、鉴权、呼叫处理、用户追踪、短信服务管理它最重要的功能是从一个交换区域向另一个交换区域传送用户信息，这个程序的包括信令和数据库的交互当一个用户漫游到一个新的移动交换区域时，该区的VLR（VisitorLocationRegister，访问位置寄存器）通过封装在TCAPTransactionCapabilitiesApplicationPart事务处理能力应用部分消息报文中的MAP信息获得存放在HLR（HomeLocationRegister，本地位置寄存器）中的用户信息其中TCAP是一种SS7应用协议，在协议栈中位置如图5-13所示，它提供以非电路交换处理为基础的网络实体之间的信息交换，支持网络数据库间通信图
3.
6.
4.
2.
6.
4.1SS7协议栈MAP网关在WLAN系统的RADIUS服务器和GSM网络的HLR之间充当了桥梁的角色，如图5-14所示对于HLR来讲，MAP网关相当于SS7网络中的一个VLR节点；对于RADIUS服务器而言，MAP网关相当于另一个RADIUS服务器MAP网关在认证过程中的工作流程如下
1.当RADIUS服务器接收到一个认证请求以后，将这个请求送到MAP网关，MAP网关将此请求封装在MAP-Send-Auth-Info/Req报文中通过SS7网络发往HLR/AUC；
2.AUC由随机数发生器产生的n*RAND和对应用户的Ki经过A3/A8计算得到参数n*SRES和n*Kc，封装在MAP/Send-Auth-Info/Resp报文中发往MAP网关MAP网关再将报文重新封装成RADIUS报文发往RADIUS服务器
3.
6.
4.
2.7密钥生成规则在EAP_SIM完全认证模式中，主密钥MK由下式产生（这里“|”表示连接）算法“SHA1”是一种哈希函数这里Identity是用户身份字符串，不包括任何无效字符，它来自认证流程中客户端最后一次发送的用户身份；“n*Kc”表示n个Kc64bits相连接，Kc由GSM网络认证程序产生，因为每一个Kc的长度不够，所以需用到n个，这里n的值可以是2或3；NONCE_MT是指属性AT_NONCE_MT中的值域的内容，是由客户端产生的一个128bits的随机数，在产生密钥的参数中加入由客户端初始化的参数可实现客户端对来自网络的报文的认证；VersionList是属性AT_VERSION_LIST值域的内容；SelectedVersion是属性AT_SELECTED_VERSION值域的内容其中SHA是一个报文摘要算法，信息或者是数据被看作是一串比特流，对于长度是8的倍数的信息我们可以用16进制表示，附加比特的目的是为了要使得长度恰好是512的倍数sha-1算法是每次处理512比特的数据来计算摘要的，下面给出怎样来添加比特简要的说，就是一个1后面跟m个0，最后是一个64比特的整型数据用来表示比特流的长度，sha－1算法用来处理添加后的n个512比特的数据块报文摘要计算使用两个数列，每个都由5个32比特的字和一个80个32比特的字节的序列，开始的5个字节标为h
0、h
1、h
2、h
3、h4，80个序列的80个字是W
0、W
1、W
2、W
3、....W79，还需要使用一个数列temp在处理任何数据之前先初始化Hi，其中H0=
67452301、H1=EFCDAB
89、H2=98BADCFE、H3=
10325476、H4=C3D2E1F0为了得到报文摘要，将给出的报文分成以16个字节为单位的块M1M2M
3...Mn现在开始处理Mi，处理过程如下A将Mi分成16个字W0，W1，....W15，W0是最左边的字B从t＝16到79，使得Wt=S1Wt-3XORWt-8XORWt-14XORWt-
16.C令A=H0B=H1C=H2D=H3E=H
4.D从t=0到79TEMP=S5A+ftBCD+E+Wt+Kt;E=D;D=C;C=S30B;B=A;A=TEMP;E令H0=H0+AH1=H1+BH2=H2+CH3=H3+DH4=H4+E.处理完Mn，报文摘要就是一个160比特用5个字来表示H
0、H
1、H
2、H
3、H4在处理过程中会用到这些函数ftBCD=BANDCORNOTBANDD0=t=19；ftBCD=BXORCXORD20=t=39；ftBCD=BANDCORBANDDORCANDD40=t=59；ftBCD=BXORCXORD60=t=
79.以及使用到的如下的定量Kt=5A8279990=t=19Kt=6ED9EBA120=t=39Kt=8F1BBCDC40=t=59Kt=CA62C1D660=t=
79.以MK作为伪随机数发生器函数PRF的种子产生认证流程中用到的各种密钥，包括瞬时EAP密钥TEKs，128bits、主会话密钥MSK，64bytes和扩展主会话密钥EMSK，64bytes其中，TEKs用于保护EAP报文，在EAP_SIM认证机制中需要三个TEKs，其中两个是与属性AT_MAC相关的认证密钥K_int128bits和K_sres128bits，另一个是与属性AT_ENCR_DATA相关的加密密钥K_encr128bits；MSK用来保护链路层安全；EMSK则用作其他用途这里随机数发生器函数PRF算法如下Forj=0tom-1doXSEED_j=optionaluserinputFori=0to1doXVAL=XKEY+XSEED_jmod2^bw_i=GtXVALXKEY=1+XKEY+w_imod2^bx_j=w_0|w_1其中XKEY160bits=MK由之前的SHA算法生成；b=160；XSEED=0；x_i320bits；t=67452301EFCDAB8998BADCFE10325476C3D2E1F0；m的大小由算法实现者根据所需密钥的长度设定生成x向量以后根据所需密钥长度进行截取在重认证模式中可以使用在前一个完全认证模式下生成的TEKs，但是MSK和EMSK必须由MK重新派生
3.
6.
4.
2.
7.1安全评估这一节主要给出EAP_SIM认证机制在安全方面的策略和存在的弱点及解决意见1）AP_SIM认证机制中提供了可选的身份保护策略，即利用伪用户身份，以防止用户永久身份被恶意窃取一旦伪用户身份产生后则须存放在终端的稳定的存储区，不至于因丢失而影响认证过程但是在EAP第一次交互中仍必须使用用户永久身份，使EAP服务器建立用户永久身份和伪身份的映射关系一个主动的攻击者可能会扮演网络向客户端发送封装有属性AT_PERMANENT_ID_REQ的请求报文以期望获取用户永久身份，然而如前文
4.4节中提到的那样，终端会按设定的规则决定如何回复该请求如果客户端和服务器端无法保证用户伪身份能得到很好的保存，可能需要考虑使用PEAPProtectedExtensibleAuthenticationProtocol以取得更好的安全性2）AP_SIM认证机制提供双向认证如果网络能在EAP-Request/SIM/Challenge报文中给出正确的AT_MAC值，则客户端认为网络是可以信任的AT_MAC的计算主要依据GSM网络的三元组RAND，SRES，Kc，所以一旦攻击者获得三元组就可能扮演网络身份威胁网络的安全由此可见三元组的安全性决定着网络认证的安全程度，所以三元组的传输、存储、处理都要考虑其安全性在GSM中网络允许挑战随机数RAND可以在连续的认证中重复使用，这一点在EAP_SIM认证中是不允许的，要求每一次都使用新的随机数RAND，以给网络安全加了一道屏障但是在EAP_SIM中并没给出强制客户端去验证RAND的重复性的方法，所以这道屏障的安全性不高在UMTS认证和密钥协定中考虑到了认证矢量的重复使用问题，而且被用到了EAP/AKA认证机制中所以如果觉得EAP_SIM认证机制在这方面的安全性不够，可以考虑使用EAP/AKA认证机制aEAP_SIM支持密钥派生EAP_SIM结合若干个GSM三元组以产生更健壮的密钥和认证码AT_MAC事实上密钥的健壮性还倚赖于认证算法本身、Ki的健壮性、挑战随机数RAND的质量一个被动的攻击者可能通过窃取的随机数RAND和认证码AT_MAC取得与用户身份相关的信息而一个主动的攻击者通过假扮GSM网络用户可以很容易从EAP服务器处获得RAND和AT_MAC，但是通过AT_MAC反推Kc和SRES还要求攻击者得到函数HMAC-SHA1-128的反函数考虑到攻击者对传输数据的攻击，EAP_SIM的会话密钥长度到达了128bits，在一定程度上保证了安全性而且用来保护EAP_SIM报文的瞬时密钥TEKK_encr，K_aut与主会话密钥MSK是割裂的，攻击者不可能由其中的一个密钥推出另一个攻击者也不可能从所窃取的Kc、K_encr、K_aut或MSK反推出客户端和服务器端的共享密钥客户端通过高质量的随机数发生器生成参数NONCE_MT作为产生密钥的参数的一部分，对RAND可能的重复使用带来的危害起了很好的缓解作用，降低了密钥重复的概率b由于EAP_SIM机制不是用户－口令认证方式，其预共享对称密钥是分别存放在SIM卡和GSM认证中心而不需要传输，所以不容易受到字典攻击c属性AT_MAC、AT_IV和AT_ENCR_DATA分别用来实现对EAP_SIM请求和回复报文的完整性包括EAP包头、重用性和机密性的保护虽然这些属性不会出现在一开始的交互报文EAP/Identity和EAP_SIM/Start中以实现对报文的即时验证，但是这些报文中的某些域值如identity、NONCE_MT和版本参数信息参与了之后的密钥产生，所以这些报文的有效性还是会在之后的交互流程中得到验证3）AP_SIM机制中没有提供对EAP/Notification、EAP/Success和EAP/Failure报文的完整性、重用和机密性的保护因为网络的物理不安全性，有可能会出现以下问题其一，攻击者有可能向客户端发送伪造的EAP/Notification报文和发起拒绝服务攻击，所以机密信息不可以封装在EAP/Notification报文中进行传输；其二，EAP/Success和EAP/Failure可能会在传输的过程中丢失，这样服务器端和客户端对认证结果存在不一样的认识其三，攻击者可能会通过发送伪造的EAP/Success或EAP/Failure发起攻击扰乱认证结果，但是客户端和服务器在确定认证失败或认证还未进行时是不会相信这样的报文的4）AP_SIM机制允许通过定义新的属性来扩展协议但是需要注意的是之后新加入EAP_SIM/Start报文的属性不会在认证码MAC中得到验证，所以要注意采取相应的措施保护这些新加入的属性的安全EAP_SIM机制支持可选的快速重连接即重认证技术，支持这个技术的出发点是考虑到物理网络的安全性问题5在物理不安全的网络上为了防止人为的攻击和会话劫持，必须考虑用户数据完整性保护EAP_SIM的主会话密钥MSK或由其派生出来的密钥可以用来作为保证用户数据完整性的密钥，或者使用扩展的安全保护机制，如PEAP6在EAP_SIM中所用到的随机数对整个认证流程的安全性非常重要，所以需要一个高质量的随机数发生器，这方面的算法在文档[RFC1750]由详细论述
3.7EAP认证的实现
3.
7.1客户端
3.
7.
1.1客户端实现概述
3.
7.
1.
1.1Supplicant客户端的引用库文件
3.
7.
1.
1.
1.1底层收发包的winpcap库winpcapwindowspacketcapture是windows平台下一个免费，公共的网络访问系统开发winpcap这个项目的目的在于为win32应用程序提供访问网络底层的能力它提供了以下的各项功能 1捕获原始数据报，包括在共享网络上各主机发送/接收的以及相互之间交换的数据报； 2在数据报发往应用程序之前，按照自定义的规则将某些特殊的数据报过滤掉； 3在网络上发送原始的数据报； 4收集网络通信过程中的统计信息 winpcap的主要功能在于独立于主机协议（如TCP-IP而发送和接收原始数据报也就是说，winpcap不能阻塞，过滤或控制其他应用程序数据报的发收，它仅仅只是监听共享网络上传送的数据报因此，它不能用于QoS调度程序或个人防火墙 目前，winpcap开发的主要对象是windowsNT/2000/XP，这主要是因为在使用winpcap的用户中只有一小部分是仅使用windows95/98/Me，并且M$也已经放弃了对win9x的开发因此本文相关的程序T-ARP也是面向NT/2000/XP用户的其实winpcap中的面向9x系统的概念和NT系统的非常相似，只是在某些实现上有点差异，比如说9x只支持ANSI编码，而NT系统则提倡使用Unicode编码Winpcap有两层应用库，wpcap.dllpacket.dll前者较后者上层，后者是与底层网卡相结合的库，在supplicant实现中，我们调用的上层的wpcap.dll库图
3.
7.
1.
1.
1.
1.1winpcap的库结构
3.
7.
1.
1.
1.2实现SSL加密协议的openssl库opensslwww.openssl.org是sslv2，sslv3，tlsv1的一份完整实现，内部包含了大量的加密算法程序，其命令行提供了丰富的加密，验证，证书生成等功能，甚至可以用其建立一个完整的CAopenssl不但实现了ssl的一些接口，它所涵盖的内容从底层对称、非对称加密算法的到建立在其上的PKCSPublicKeyInfrastructure的接口包括X509证书、PKCS标准、ASN.1等的实现是一应俱全，甚至还给了一个有关CA的例子openssl这个包是由两部分组成的:ssleay和openssl它两者的关系是，ssleay是一套接口库，openssl是建立在这个库接口之上的一个应用时至今日，openssl也发展到了
0.95版，它的功能也越来越丰富openssl包中的ssleay是整个包的核心，ssleay这个加密库实现了常用的关于对称加密的des、idea、rc
2、rc
4、rc
5、blowfish、CAST；实现了非对称算法中的RSA、DH、DSA哈稀算法中的MD
2、MD
5、SHA、SHA-
93.
7.
1.
1.2Supplicant端的实现设计
3.
7.
1.
1.
2.1功能设计supplicant程序的总体设计如下������������#0;��������#0;����������������#0;����������������#0;������������������#0;��������#0;��������������#0;������������#0;������������#0;������������#0;������������#0;
802.1x����#0;EAP����#0;������������#0;������������#0;EAP����#0;EAP����#0;��������������������#0;����������������#0;��������������������#0;��������MAC����#0;MAC��������#0;MAC��������#0;����Eapol��������������#0;����Eapol��������������#0;图
3.
7.
1.
1.
2.
1.1supplicant总体设计本地网络接口基于winpcap的底层以太网帧收发接口，以太网子系统调用winpcap的底层函数，负责将认证的数据包发送到认证者，以及接收认证包
802.1x平台基于
802.1x状态机，控制程序的运行EAP认证将收到的认证包根据不同的认证类型进行相应的处理用户信息交流接口用户与程序通过可视界面的信息交互接口用户端图形界面接收用户对认证的要求和信息使用者数据区用户在认证中所需要使用的信息存储区使用者信息存贮文件程序运行中的调试语句
3.
7.
1.
1.
2.2supplicant端的界面设计界面是采用MicrosoftVisualC++进行开发的，界面是传统的Windows分格如下图所示图
3.
7.
1.
1.
2.
2.1客户端程序的界面1）网卡网卡下拉菜单中列出的客户计算机上所连接的网卡，客户可以根据需要选择认证所使用的网卡2）所用认证方式认证方式下拉列表中列出了7种认证选择，客户可以根据需要选择认证所使用的方式3）“详细设置”按钮选定好认证方式以后，单击“详细设置”按钮，将会出现用户信息输入框（根据各种认证方式的具体要求，用户信息输入框的格式是不相同的）图
3.
7.
1.
1.
2.
2.2用户的认证信息输入框4）认证者认证者下拉列表中列出了附近支持
802.1x认证的AC的描述语句，如果该列表中没有显示，则说明搜索不到AC5）认证信息认证信息栏中显示认证时的提示信息6）“连接”按钮当用户将网卡，认证方式，认证信息设置好以后，就可以单击“连接”按钮开始认证如果没有填写好认证信息，就会出现警告，如下图所示图
3.
7.
1.
1.
2.
2.3警告框（尚未设置认证信息）7）“断开”按钮用户下线时，单击“断开”按钮即可
3.
7.
1.
1.
2.3supplicant端支持的认证方法Supplicant端与AS（AuthenticatorServer）端都支持六种认证方法EAP-MD
5、EAP－LEAP，EAP-TLS，EAP－TTLS，EAP－PEAP和EAP－SIM
3.
7.2认证者
3.8创新点
3.
8.1逻辑端口的扩充
3.
8.
1.1逻辑端口的实现系统实现了控制的端口属于逻辑端口，具有VLAN级别和MAC级别两种逻辑端口对于VLAN级别的逻辑端口，VLANID是区别逻辑端口的唯一标识，如果某个VLAN在系统中设定为需要
802.1x认证，那么从该VLAN端口接入的用户（除非用户的MAC在下面一条中定义是否需要进行
802.1x认证）需要进行EAP认证； 对于MAC级别的用户，逻辑端口采用VLANID+用户MAC地址，如果在系统中设定某VLAN下的某MAC地址的用户接入需要进行
802.1x认证，那么以此MAC地址在此VLAN下接入的用户就需要进行EAP认证，无论此时的VLAN控制级别是否需要进行
802.1x认证 由此可见，系统对MAC级别定义的逻辑端口控制优先于对VLAN级别的逻辑端口控制
3.
8.
1.2端口强开的扩展为了使系统能够继承原有的业务类型，对端口的强开状态进行了扩展，以保证非
802.1x用户可以正常接入 1） 任何时候，收到客户端EAPOL-START报文，直接返回给客户端EAP-SUCCESS； 2）如果收到客户端DHCPDISCOVER报文，允许客户端完成DHCP过程，分配IP地址； 3）客户端必须通过WEB认证后，才能访问外部网络
3.
8.
1.3端口自动的扩展为了适应更加灵活的组网方式和不同类型用户的需要，对端口自动状态（AUTO）进行了扩展，以方便那些没有
802.1x客户端的用户可以通过传统的VLANWEB方式进行接入，实现
802.1x与VLANWEB接入的混合组网1）如果先收到客户端EAPOL-START报文的EAPOL-START触发，则首先进行EAP认证，EAP认证成功后，才允许进行DHCP过程，分配IP地址，获得访问外部网络的权限；2）如果先收到客户端的DHCPDISCOVER报文，则根据事先设定的策略完成后续的接入过程，如下表所示表
3.
8.
1.
3.1接入控制器的策略策略说明先DHCP，后WEB允许先完成DHCP，再进行WEB认证，用户只有通过WEB认证才允许上网先DHCP，后EAP，再DHCP允许先完成DHCP，再进行EAP认证，最后可以进行二次DHCP过程（可控制）用户只有通过EAP认证后才允许上网自适应允许先完成DHCP，再进行EAP或WEB认证，如果是EAP认证，可以进行二次DHCP过程（可控制）用户获得地址后可以进行WEB认证，也可以进行EAP认证，认证通过后才允许上网先EAP，后DHCP强行触发EAP认证，认证成功后再进行DHCP过程，用户EAP认证后获取地址允许上网如果客户端不支持EAP认证，还可以切换策略，按其他三种方式先完成DHCP再进行认证，用户认证后才允许上网（可控制）
3.9项目中引用的rfc和draft1）IETFRFC2284“PPPExtensibleAuthenticationProtocolEAP”L.BlunkJ.VollbrechtMeritNetworkIncMarch19982）IETFRFC2246“TheTLSProtocolVersion
1.0”T.DierksC.AllenCerticomJanuary19993）IETFRFC2716“PPPEAPTLSAuthenticationProtocol”B.AbobaD.SimonMicrosoftOctober19994）IETFRFC2104“HMACKeyed-HashingforMessageAuthentication”H.KrawczykIBMM.BellareUCSDR.CanettiIBMFebruary19975）IETFInternet-Draftdraft-ietf-pppext-eap-ttls-
02.txt“EAPTunneledTLSAuthenticationProtocol”PaulFunkFunkSoftwareInc.6）IETFInternet-Draftdraft-josefsson-pppext-eap-tls-eap-
06.txt“ProtectedEAPProtocolPEAP”AshwinPalekarDanSimonMicrosoftGlenZornCiscoS.JosefssonExtundo22March20037）IETFInternet-Draftdraft-haverinen-pppext-eap-sim-
10.txt“EAPSIMAuthentication”H.HaverineneditorNokiaJ.SaloweyeditorCiscoFebruary2003Supplicant
802.1XEAPoverWirelessAuthenticatorRADIUSserverEAPoverRADIUSTheWorldAuthenticatedkeyManagementSuiteList4noctetsAuthenticatedkeyManagementSuiteCount2octetsUnicastSuiteList4noctetsUnicastSuiteCount2octetsMulticastSuite4octetsVersion2octetsLength1octetElementID1octetOUI3octetsSuiteType1octets。
个人认证
优秀文档
获得点赞 0
