认证协议2——CHAP

CHAP(Challenge Handshake Authentication Protocol）询问握手认证协议，或者叫做冲击握手认证协议，属于三次握手协议，相对于PAP来说安全性高一些，防止了重放攻击，以为每次询问内容是不同的。这个流程我们还是分为一下两部分分析：

1. PC <——> NAS：所说的三次握手也是这个过程，当链路建立以后，首先NAS会向PC发送一个Challenge字符串，这个字符串是随机的，PC利用用户输入的明文密码和Challenge使用单向加密算法加密后将用户名和密文密码一同发送给NAS设备；

2. NAS <——> AAA：NAS设备收到PC发送的认证请求后，将用户名和密码分别放到User-Name和CHAP-Passowrd

中，另外必须携带Challenge给Radius服务器，否则Radius服务器无法验证密码，这个Challenge有两种方式，第一个是放到属性CHAP-Challenge中，如果Challenge长是16字节，也可以直接放到Radius包头中的Authenticator中，NAS将这些内容发送给Radius服务器，Radius服务器本地获取明文密码，加上Challenge后用相同的算法得到密文，与CHAP-Password对比得到结果；

所以看到三次握手指的是PC和NAS之间，而NAS和AAA服务器之间和PAP还是一样，NAS向AAA服务器发送一次请求，里面携带了所有数据，AAA根据这些数据判断将验证结果发送给NAS。

Radius对于CHAP-Password解析如下：

（1）第一个字节是CHAP Identifier，是PC发送给NAS的Response的ID值；

（2）计算：C = MD5(CHAP-Ident + 明文密码 + Challenge)计算的到密文；

（3）将C与CHAP-Password从第二字节开始的内容对比；

最后分析一下Radius对于PAP和CHAP的处理，RFC-2865中有如下描述：

For PAP, the NAS takes the PAP ID and password and sends them in an Access-Request packet as the User-Name and User-Password. The NAS MAY include the Attributes Service-Type = Framed-User and Framed-Protocol = PPP as a hint to the RADIUS server that PPP service is expected.

For CHAP, the NAS generates a random challenge (preferably 16 octets) and sends it to the user, who returns a CHAP response along with a CHAP ID and CHAP username.  The NAS then sends an Access-Request packet to the RADIUS server with the CHAP username as the User-Name and with the CHAP ID and CHAP response as the CHAP-Password (Attribute 3).  The random challenge can either be included in the CHAP-Challenge attribute or, if it is 16 octets long, it can be placed in the Request Authenticator field of the Access-Request packet.  The NAS MAY include the Attributes Service-Type = Framed-User and Framed-Protocol = PPP as a hint to the RADIUS server that PPP service is expected.

The RADIUS server looks up a password based on the User-Name, encrypts the challenge using MD5 on the CHAP ID octet, that password, and the CHAP challenge (from the CHAP-Challenge attribute if present, otherwise from the Request Authenticator), and compares that result to the CHAP-Password.  If they match, the server sends back an Access-Accept, otherwise it sends back an Access-Reject.

If the RADIUS server is unable to perform the requested authentication it MUST return an Access-Reject.  For example, CHAP requires that the user's password be available in cleartext to the server so that it can encrypt the CHAP challenge and compare that to the CHAP response.  If the password is not available in cleartext to the RADIUS server then the server MUST send an Access-Reject to the client.

FreeRadius的处理一般是复杂的协议首先确定，比如首先在属性中查找是否有CHAP-Password属性，如果有的话，就默认是CHAP认证，试图使用CHAP认证方式，如果没有找到CHAP-Password，那么看是否有User-Password，如果有User-Password就认为是PAP认证方式，使用PAP模块进行认证。