1. Radius协议Radius协议是当前AAA服务中使用最广泛的协议，支持身份验证、授权和计费功能。 Radius服务器构建自己的用户数据库，存储用户名、用户密码等一系列信息，访问用户通过将自己的用户名、密码、证书等信息发送到服务器来进行认证，认证成功后，服务器将只有经过认证的用户才能访问Radius服务上的资源。
1.1 RADIUS协议物理无线终端(Authenticating peer ) nas (radius client ) radiusserverauthenticatorserver 1.2 radius的典型过程radius协议是
基于数字证书的认证方法、基于数字证书的认证方法一般使用TLS协议建立安全通道，在通道内交换数据，嵌套另一认证方法。 密码认证方法和密码认证方法的示例包括PAP认证和CHAP认证。
1.3 RADIUS消息格式
代码(消息号) Code域用于标识Radius消息类型，表示对应于一般代码码的含义。 1访问请求消息2访问成功响应消息3访问拒绝响应消息4计费请求消息5计费响应消息11访问挑战消息12服务器状态消息13客户端状态消息255预留标识符标识域例如，可以根据该值判断是否为重复请求消息，并且如果在一个时间段内两个消息来自相同的地址和端口并且具有相同的Idenfier值，则认为是重复消息。 长度Length，长度域占位符2字节。 包含消息中代码域、标识符域、长度域、审计者域和属性域的总长度。 如果接收到的消息的长度大于这个值，则在接收到消息时忽略多余的字节； 如果长度小于此值，则消息不完整，直接丢弃消息。 一条Radius消息的长度在在20到4095个字节的范围内。 认证字，Authenticator域占位符16字节。 高位字节先传输。 此域的值用于标识服务器的响应消息。 请求认证字：认证tor的值是随机生成的16字节字符串。 NAS和Radius服务器共享添加在请求认证字字段之后的密钥，使用MD5算法生成16字节的摘要，获取该摘要与用户输入的密钥的异或，并将异或的结果访问请求消息的un 响应认证字：在接受访问、拒绝访问和挑战消息中。 该值被定义为通过MD5摘要计算整个接入响应消息的内容和共享密钥而获得的16字节字符串。 从代码字段开始，包含标识符字段、长度字段、访问请求消息中的请求认证字字段和响应消息中的属性，然后添加共享密钥，即， response auth=协调请求消息(MD5 )，其定义是整个协调请求消息的内容和定义MD5 ) codeidlength 16 zerooctetsattributessecret )计费响应消息中的认证字称为计费响应认证字。 其定义为对整个计费响应消息的内容和共享密钥进行MD5摘要计算的16字节字符串，其中在计算时，计费请求Accounting-Request消息的Authentictor替换了Authentictor的16字节数据计算公式： MD5 (编码要求) (2. EAP介绍EAP )协议是PPP (pointtopointprotocol ) 由此，客户端通过EAP协议，在服务器端和访问用户之间传递认证消息。 EAP协议提供了一个可以支持多种EAP认证方法的认证框架。 与PAP和CHAP认证相比，EAP认证对网络的访问管理更严格，能够更好地保证网络APP应用中的信息安全。
2.1 EAP消息格式
代码(消息号)代码字段占用用于标识EAP消息类型的字节。 具体应对如下。 1 EAP -请求，EAP请求2 EAP-Response，EAP响应3 EAP-Success，EAP成功4 EAP-Failure，EAP失败标识符Identifier占位符标识请求消息和响应消息长度Length，长度域占位符2字节。 用于表示代码标识符长度类型数据的全长。 类型Type占1个字节，用于表示具体的EAP消息验证类型。 具体类型如下。 1 EAP_Identity4 EAP_MD511
EAP_Challenge13 EAP_TLS21 EAP_TTLS25 EAP_PEAP26 EAP_MSCHAPv2 数据Data，当Code为EAP-Success或者Code为EAP-Failure的时候，Data内容为空。其它类型报文的Data内容与Type类型相关。 2.2 EAP_MSCHAPv2EAP_MSCHAPv2是一种双向相互认证的协议，认证过程是challenge－response式的。在认证过程中，服务器和客户端会进行双向验证，只要其中一方失败，则这个连接会被拒绝。EAP_MSCHAPv2通常不单独使用，通常是嵌套在EAP_PEAP认证方法中使用。
2.2.1 EAP_MSCHAPv2的认证过程 首先客户端给接入用户发送Identity报文，要求客户端提供身份标识；接入用户给客户端回应Identity报文，内容是用户的身份标识，客户端对这个报文的处理是将之封装成Radius访问请求报文传给服务器；服务器在获取到接入用户的接入标识后，会给客户端发送Radius访问挑战报文，客户端在收到这个报文后，对报文进行解封装，将报文中的EAP-Request/EAP-MSCHAPv2(Challenge)发送给接入用户，Challenge报文中包含有服务器端产生的Server-Challenge；接入用户进行计算，发送Response报文给客户端，客户端在接收到该报文后，将该报文封装到Access-Request中传给服务器，Response报文中包含用户产生的Peer-Challenge和根据用户密码，用户名，Peer-Challenge和Server-Challenge为输入通过MD4和DES算法生成的NT-Response；服务器对接入用户进行验证，具体验证的方法是服务器端使用同样的算法以用户密码，用户名，Peer-Challenge和Server-Challenge为输入计算出NT-Response，如果和Response报文中NT-Response匹配，则认证成功。在认证成功的基础下，会给客户端发Success-Request报文，Success-Request报文中含有以用户密码，用户名，Peer-Challenge，Server-Challenge以及NT-Response为输入使用MD4算法和DES算法计算出来的Message，客户端收到报文后，进行解封装，将报文中的Success-Request发送给接入用户，请求用户对服务器进行验证；接入用户对服务器进行验证，具体验证的方法是用同样算法以用户密码，用户名，Peer-Challenge，Server-Challenge以及NT-Response为输入计算出Message，然后与Success-Request中的Message做匹配，如果匹配失败，则不再向服务器发送报文，如果匹配成功，则向客户端发送EAP-Request/EAP-MSCHAPv2(Success-Response)报文，客户端收到后，将报文封装成Access-Request报文传给服务器；服务器如果接收到Success-Response报文，则说明验证成功，接入用户收到的报文将是EAP成功报文，到此整个认证流程结束。在第5步中，服务器对接入用户验证失败时，服务器可以发送
EAP MSCHAPv2(Failure-Request,R=1,E=691)来要求用户重新输入密码进行重试，然后又重新从第４步开始进行认证过程。
在RFC2869中，Radius为支持EAP认证增加了两个属性EAP-Message和Message-Authenticator（消息认证码）。
EAP-Message属性中存放的是整个EAP认证包内容，下图展示了EAP-Message属性的封装，这个属性用来封装EAP数据包，类型代码为79，String域最长253字节，如果EAP数据包长度大于253字节，可以对其进行分片，依次封装在多个EAP-Message属性中。Message-Authenticator属性封装，类型代码为80。这个属性用于在使用EAP认证方法的过程中，避免接入请求包被窃听。在含有EAP-Message属性的数据包中，必须同时也包含Message-Authenticator，否则该数据包会被认为无效而被丢弃，而且服务器或用户收到报文后，还将使用EAP消息和共享密钥作为输入计算该值，如果与传过来的属性值不一致，也将丢弃这个报文。
对于Access-Request消息，需要使用共享密钥，Message-Authenticator计算方法为：
Message-Authenticator＝MD5(Code+Type+Identifier+Length+16 Zero Octets+Attributes+Secret)对于Access-Challenge、Access-Accept、Access-Reject消息，Message-Authenticator计算方法为：
Message-Authenticator＝MD5(Code+Type+Identifier+Length+Request Authenticator+Attributes+Secret) 2.3 EAP_TLSEAP_TLS是基于PKI证书体系的，要求客户端和服务器都必须拥有有效的证书，支持导出密钥的功能，而且是一种支持双向认证的认证方法。PKI证书体系是非常复杂的，在企业中已经部署PKI证书体系的情况下，EAP_TLS认证是一种很安全且很方便的认证方法，但是在企业没有部署的情况下，使用EAP_TLS进行认证将会很复杂。一般来说，EAP_TLS用于验证设备，而不是普通的接入用户。
TLS协议由TLS记录协议(TLS Record)和TLS握手协议(TLS Handshake)两个协议组成。TLS握手协议使用了公共密钥和证书，在客户端和服务器之间进行通信之前协商算法和加密实际数据传输的密钥，该过程在TLS记录协议之上进行，TLS握手过程实际上就是通信双方协商交换一个用于对称加密的密钥的过程，这个过程实际上产生三个随机数：client random, server random,pre-master secret。前两个随机数都是明文传送的，只有pre-master secret是加密的（RSA或DHP）。一般生成证书的时候，签名算法可以使用RSA或者DSA。如果server使用RSA证书，RSA既可以用作签名也可以用作不对称加密，pre-master secret就是用server的RSA证书中包含的公钥加密的。如果server使用DSA证书，DSA只能完成签名的功能，所以交换密钥的功能还得由DH算法实现。TLS记录协议的作用是对数据进行处理，包括加密，压缩和重组等，而且会将处理后的数据传递给高层用户。
EAP_TLS虽然安全性能高，但是证书维护成本高且配置难度高，而且EAP_TLS在传送用户名的时候没有加密，即抓包的时候EAP_Identity报文中的用户名是明文显示的，可以考虑用EAP_PEAP或者是EAP_TTLS来代替，这两种认证方式不需要建立复杂的PKI系统，可以在TLS隧道内嵌套其他的认证方法，这不仅使复杂度大大降低，而且还提高了安全性。
2.3.1 EAP_TLS认证过程EAP_TLS的认证过程（以签名算法使用RSA为例）如图所示：
EAP_TTLS协议的规范文档是RFC5281，EAP_TTLS是EAP_TLS的一种扩展，与EAP_TLS的区别是对证书的要求没有那么严格，只需要提供服务器端证书，而客户端证书不是必须的。
EAP_TTLS是一个复合的认证方法，主要包括两个阶段：
EAP_PEAP是一个复合的认证方法，主要包括两个阶段：
第一个阶段是在用户和认证服务器之间建立TLS隧道，第二阶段是在已经建立的隧道内使用其他的EAP方法进行认证，如EAP-MSCHAPv2。EAP_PEAP的认证过程，具体流程如下：
握手阶段和EAP_TLS相似，与之不同的是，只需要服务器发送证书给客户端，实现客户端对服务器的认证，客户端不再需要发送自身的证书给服务器；服务器给客户端发送Access-Challenge报文，客户端收到报文之后，解封装该报文，将其中的Identity报文传给接入用户；客户端在收到接入用户发来的回应报文Identity后，将读报文封装在Access-Request中传给服务器；服务器根据用户的Identity査找该接入用户的认证方法，在获取认证方法之后，向接入用户发送嵌套的认证方法的Challenge报文；根据嵌套的认证方法的类型，接入用户和服务器进行相应的认证过程，直到服务器对接入用户认证成功；服务器对接入用户认证成功后，给客户端发送访问质询报文，客户端将其中的Result=Success报文传给接入用户；同样的，接入用户在收到报文后，给客户端发送EAP回应报文，客户端将EAP报文封装成访问请求的格式传给服务器；服务器给接入用户发送Access-Accept报文，接入用户将收到EAP-Success。EAP_TTLS和EAP_PEAP还可以支持快速恢复TLS会话。在认证的第二阶段成功的情况下，无须执行认证第一阶段或第二阶段就能够恢复该会话，可以通过发送一条EAP-Success消息来进行重新身份验证尝试，这称为快速重连。这可以减少域间切换的延迟。