CHAP认证协议框架和PAP是完全不一样的

CHAP是非常经典的，在其他安全协议中可以看到CHAP认证的影子

在两端PPP会话初始建立的时候，依旧是使用LCP协商建立链路和确定验证方式

在协商的过程中就达成共识，是使用CHAP进行认证的

这时候core  router就会发送challenge<挑战>信息，是CHAP报文

challenge<挑战>信息主要的4个内容：

1.code：值为1，表示是challenge消息

2.id：在core  router上识别ppp会话的，因为在core  router上会有很多会话的

3.name：core  router的名称

--同时路由器会产生一个缓存，存储远端路由器建立请求

4.random：core  router  会产生随机数，存储在缓存中。

所以一并纳入报文传给远端路由器

远端路由器收到该报文后，会将chap密码和认证端发送的随机数、id取出来，进行hash

hash是一个散列算法，字符串进行hash算法后会生成定长的字符串，如果原始的字符串中有改变，那么新产生的值和原值是完全不一样的。hash是一个不可逆的过程

得到hash结果后，remote会发送response报文：

1.code：值为2，表示是响应报文

2.id：该值和challenge报文的id值相同

3.name：远端路由器 配置的hostname

4.value：计算的hash结果

报文发送给，core  router，

在core  router 在本地有缓存，

所以会把id ，随机数以及本地用户数据库所保存的值，进行hash、

比较response里面value和上一步hash的值，如果比对相同，验证成功；否则失败

因为id 和随机数都是core  router生成的，所以关键是两边密码是否一致

可以发现，在chap认证过程中没有密码字段，即使整个过程被监听了，也是安全的

但是会带来一定的资源损耗，因为要hash，三次报文

remote(config)#interface serial 0/1/0

remote(config-if)#ip add 192.168.12.1 255.255.255.0

remote(config-if)#no shu

remote(config-if)#ppp pap sent-username remote password togogo

Must set encapsulation to PPP before using PPP subcommands

remote(config-if)#encapsulation ppp

remote(config-if)#ppp chap hostname remote

remote(config-if)#ppp chap password togogo

Core(confit)#username remote  password  togogo

Core(config)#interface serial 0/1/0

Core(config-if)#ip add 192.168.12.2 255.255.255.0

Core(config-if)#no sh

Core(config-if)#ppp authentication chap

Must set encapsulation to PPP before using PPP subcommands

Core(config-if)#encapsulation ppp

Core(config-if)#ppp authentication chap