PPP协议基于H3C路由器的CHAP认证分析

田 君

PPP协议基于H3C路由器的CHAP认证分析

田 君

（天津城市职业学院 机电与信息工程系，天津 300250）

介绍基于H3C路由器的CHAP认证及配置要点，并通过几种情况的对比，提出充分发挥CHAP认证安全性的两种配置方法，即在主验方接口配置用户及双向验证，对类似工程案例具有良好的借鉴或参考意义。

CHAP认证；本地用户；接口；共享密钥

PPP是一种点到点方式的数据链路层协议，是在SLIP（Serial Line IP，串行线IP协议）的基础上发展起来，能够提供用户验证，易于扩充，并且支持同／异步通信，因而获得广泛应用。随着新型宽带技术的推出PPP衍生出新的形式，如符合ADSL（Asymmetrical Digital Subscriber Line，非对称数字用户线路）接入要求的PPPoE（PPP over Ethernet，以太网上的PPP）和PPPoA（PPP over ATM，ATM 上的PPP）。

PAP是基于口令的认证方式。由被验方发起认证，将被验方的用户名和口令以明文的方式发送给主验方，由于被验方不停地在链路上反复发送用户名和口令，直到身份验证过程结束，所以无法防止窃听、重放和穷举攻击，是一种不安全的认证协议。

CHAP是基于挑战的认证协议，通过三次握手周期性的校验对端的身份，在初始链路建立时完成，也可以在链路建立之后的任何时候重复进行。如图1－a所示CHAP由主验方发起认证，向被验方发出一个Challenge报文，其中包含随机数c，此随机数是此身份验证会话惟一的一些信息；作为响应，被验方将双方共享的密钥s和c一起作为输入，计算散列值A1（散列函数通常使用md5），并通过Response报文返回；主验方在本地将s和c作为输入，用同一散列函数计算散列值A2，并与A1进行比较。若A2＝A1，说明被验证方拥有正确的共享秘密，验证通过返回ACK，否则验证失败返回NAK。在会话过程中始终重复该过程，以验证正确的被验方仍在连接中。重复这些步骤可以防止有人通过“重放”从线路上截获的信息来“偷听”被验方的会话。CHAP报文格式如图1－b所示，包括code字段（代码），ID字段（标识），len字段（报文长度），value字段（报文的具体内容）。下面分三种情况讨论在H3C路由器上使用PPP协议的CHAP认证的验证过程、配置方法及注意事项。

情况一 主验方未配置用户且被验方配置接口缺省口令

如图2所示主验方RTA主动发起验证请求，向被验方RTB发送一些随机报文（Challenge，挑战）；被验方接到验证方请求后，利用报文ID、缺省口令rtbchap和MD5算法对该随机报文进行加密，将生成的密文和自己的用户名rtb发回主验方（Response）；主验方根据收到的被验用户rtb查找与之对应的密码rtbchap，然后使用该密码和MD5算法对原随机报文进行加密，比较二者的密文，相同则返回结果ACK，否则返回NAK。

图1 CHAP认证过程及报文格式

图2 主验方未配用户的CHAP认证

这种情况需要在主验方保存对端合法用户，并在接口配置验证对端的认证协议；在被验方接口配置需提交的用户名和缺省口令即可，具体配置方法如下：（以H3C路由器 MSR30－20为例，下同）

＃在主验方配置合法用户

［RTA］local－user rtb

［RTA－luser－rtb］service－type ppp

＃在主验方接口配置验证对端的认证协议为chap认证协议

［RTA－Serial6／0］ppp authentication－mode chap

＃在被验方接口配置验证时提交的用户名和缺省口令

［RTB－Serial6／0］ppp chapuser rtb

［RTB－Serial6／0］ppp chap password simple rtbchap

在被验方通过debugging ppp chap packet，可以了解到双方的chap认证过程，主要内容及说明如下：＊Jun 2 13：01：19：847 2011 RTB PPP／7／debug2：

PPP Packet：

Serial6／0Input CHAP（c223）Pkt，Len 28

State ListenChallenge，code Challenge（01），id1，len 24

Value＿Size：16 Value：2e dd be e1 74 db 17 9f a0e3 14 27 47 ec c2 85 Name：RTA

这些数据是主验方发来的packet。这个packet中code字段值为01，表示此数据报文为一个challenge。id字段值为1，用以标识本次身份验证会话，本次会话所有的询问和响应packet此字段值均相同。value字段值（十六进制表示）为2e dd be e1 74 db17 9f a0e3 14 27 47 ec c2 85，此字段是由主验方生成的惟一的且不可预测的值，该值的惟一性可以防止攻击者试图用以前截取的值欺骗主验方。另外从这些数据中不难看出，密钥不在网络中传送，不会被窃听；而且由于使用三次握手的方法，被验方如果没有收到“挑战信息”就不能进行验证，因此在某种程度上chap协议不容易被强制攻击。

＊Jun 2 13：01：19：847 2011 RTB PPP／7／debug2：

PPP Packet：

Serial6／0Output CHAP（c223）Pkt，Len28

State ListenChallenge，code Response（02），id1，len 24

Value＿Size：16 Value：ae c4 2d 57 18 51 51 b7 8e 1 a8 e 21 50 1f 7b Name：rtb

以上数据为被验方向主验方发送的packet。这个packet中code字段值为02，表示此数据报文为一个response。id字段值为1，标识本次身份验证会话，与本次会话前面packet的id字段值相同。value字段值（十六进制表示）为ae c4 2d 57 18 51 51 b7 8e 1 a8 e 21 50 1f 7b，此字段是由被验方将id字段值、Serial 6／0接口缺省口令rtbchap和本次会话前面packet收到的value字段值2e dd be e1 74 db17 9f a0e3 14 27 47 ec c2 85，使用MD5加密创建的单向散列。这个散列值连同被验方接口Serial 6／0上配置的用户rtb一起组成packet提交给主验方。

＊Jun 2 13：01：19：858 2011 RTB PPP／7／debug2：PPP Packet：

Serial6／0Input CHAP（c223）Pkt，Len 20

State SendResponse，code SUCCESS（03），id1，len 16

Message：Welcome to.

以上数据为被验方收到主验方发来的认证通过packet。这个packet中code字段值为03，表示身份验证成功。id字段值为1，标识本次身份验证会话，与本次会话前面packet的id字段值相同。

情况二 主验方接口配置用户且被验方配置接口缺省口令

如图3所示主验方RTA首先向被验方RTB发送自己的用户名rta及一些随机报文；被验方RTB接到请求后，优先使用被验方接口的缺省口令rtbchap、报文ID和MD5算法对该随机报文进行加密，将生成的密文和自己的用户名rtb发回主验方RTA；主验方RTA根据收到的被验方的用户名rtb查找与之对应的密码rtbchap，然后使用该密码rtbchap和MD5算法对原随机报文进行加密，比较二者的密文，相同则返回结果ACK，否则返回NAK。

图3 主验方配用户且被验方配接口缺省口令的CHAP认证

这种情况主验方需要保存对端的合法用户；此外主验方需要在接口配置验证对端的认证协议及自己的用户名；被验方需要在接口配置自己的用户名及缺省口令。这里需要说明的是被验方接口配置了缺省口令则加密时优先选用，即使在被验方本地保存了主验方合法用户rta（口令rtachap），在加密收到的随机报文时，也不会使用密码rtachap。具体配置方法如下：

＃在主验方配置合法用户

［RTA］local－user rtb

［RTA－luser－rtb］password simple rtbchap

［RTA－luser－rtb］service－type ppp

＃在主验方接口配置验证对端的认证协议为chap认证协议［RTA－Serial6／0］ppp authentication－mode chap＃在主验方接口配置发送给被验方的本地用户名［RTA－Serial6／0］ppp chapuser rta

＃在被验方接口配置验证时提交的用户名和缺省口令［RTB－Serial6／0］ppp chapuser rtb

［RTB－Serial6／0］ppp chap password simple rtbchap

在被验方通过执行debugging ppp chap packet，可以了解双方chap认证过程：……

＊Jun 13 11：20：07：422 2011 RTB PPP／7／debug2：

PPP Packet： ——收到主验方chap认证challenge（主验用户rta＋随机报文）

Serial6／0Input CHAP（c223）Pkt，Len 28

State ListenChallenge，code Challenge（01），id1，len 24

Value＿Size：16 Value：b7 47 5e 9a f0 1e 12 8f 9b 3a27 d3 2 2e93 79 Name：rta……

＊Jun 13 11：20：07：423 2011 RTB PPP／7／debug2：

PPP Packet： ——提交被验方chap认证信息（被验用户rtb＋密文）

Serial6／0Output CHAP（c223）Pkt，Len 28

State ListenChallenge，code Response（02），id1，len 24

Value＿Size：16 Value：63 62 74 1b 71 f4 5f 8a34 a1 70 7a ef f7 63 12

Name：rtb

……

＊Jun 13 11：20：07：433 2011 RTB PPP／7／debug2：PPP Packet： ——认证通过

Serial6／0Input CHAP（c223）Pkt，Len 23

State SendResponse，code SUCCESS（03），id 1，len 19 Message：Welcome to rta.……

情况三 通信双方接口均配置用户但被验方接口未配缺省口令

如图4所示主验方RTA首先向被验方RTB发送自己的用户名rta及一些随机报文；被验方RTB接到请求后，根据收到的主验方用户名rta在本地查找与之对应的密码hello，然后使用该密码、报文ID和MD5算法对该随机报文进行加密，将生成的密文和自己的用户名rtb发回主验方RTA；主验方RTA根据收到的被验方的用户名rtb在本地查找与之对应的密码hello，然后使用该密码和MD5算法对原随机报文进行加密，比较二者的密文，相同则返回结果ACK，否则返回NAK。

这种情况在双方都需保存对端的合法用户；主验方需要在接口配置验证对端的认证协议及自己的用户名；被验方需要在接口配置自己的用户名。这里需要注意的是在通信双方不仅必须保存对端的合法用户，而且为保证认证的顺利通过，还必须保证双方的口令一致。具体配置方法如下：

＃在主验方配置合法用户

［RTA］local－user rtb

［RTA－luser－rtb］password simple hello

［RTA－luser－rtb］service－type ppp

＃在主验方接口配置验证对端的认证协议为chap认证协议

［RTA－Serial6／0］ppp authentication－mode chap

＃在主验方接口配置challenge中提交的本地用户名

［RTA－Serial6／0］ppp chapuser rta

图4 通信双方均配置用户但被验方接口未配缺省口令的CHAP认证过程

＃在被验方配置合法用户

［RTB］local－user rta

［RTB－luser－rta］password simple hello

［RTB－luser－rta］service－type ppp

＃在被验方接口配置验证时提交的用户名

［RTB－Serial6／0］ppp chapuser rtb

在被验方通过执行debugging ppp chap packet，可以了解双方chap认证过程：……

＊Jun 2 12：53：39：844 2011 RTB PPP／7／debug2：

PPP Packet： ——收到主验方chap认证challenge（主验用户rta＋随机报文）

Serial6／0Input CHAP（c223）Pkt，Len 28

State ListenChallenge，code Challenge（01），id1，len 24

Value＿Size：16 Value：4 97 d7 bf 5c 98 7d 8f 6c ad 2c 79 87 92 9f 7e

Name：rta……

＊Jun 2 12：53：39：844 2011 RTB PPP／7／debug2：

PPP Packet： ——提交被验方chap认证信息（被验用户rtb＋密文）

Serial6／0Output CHAP（c223）Pkt，Len 28

State ListenChallenge，code Response（02），id1，len 24

Value＿Size：16 Value：f6 33 b1 f6 27 78 76 a29 ef cc 21 8b 6 e5bd

Name：rtb……

PPP Packet： ——认证通过

Serial6／0Input CHAP（c223）Pkt，Len 23

State SendResponse，code SUCCESS（03），id1，len 19

Message：Welcome to rta.……

因为通信双方都会以本地所存用户的口令进行加密，如果双方本地所存对端合法用户的口令不一致，将导致认证失败，假定主验方合法用户rta的口令为rtachap，被验方合法用户rtb的口令为rtbchap，在被验方通过执行debugging ppp chap packet，可以了解双方chap认证过程：

……

＊Jun 2 12：47：14：34 2011 RTB PPP／7／debug2：

PPP Packet： ——收到主验方chap认证challenge（主验用户rta＋随机报文）

Serial6／0Input CHAP（c223）Pkt，Len 28

State ListenChallenge，code Challenge（01），id1，len 24

Value＿Size：16 Value：73 ca bf 81 aa f0ae 59 f5 59 53 85 de 18 6a3

Name：rta……

＊Jun 2 12：47：14：35 2011 RTB PPP／7／debug2：

PPP Packet： ——提交被验方chap认证信息（被验用户rtb＋密文）

Serial6／0Output CHAP（c223）Pkt，Len 28

State ListenChallenge，code Response（02），id1，len 24

Value＿Size：16 Value：85 2a ea e7 ea 39 47 59 ad 8 19 fa 15 2f 6e40 Name：rtb……

＊Jun 2 12：47：14：46 2011 RTB PPP／7／debug2：

PPP Packet： ——认证失败（原因：非法用户或口令）

Serial6／0Input CHAP（c223）Pkt，Len 33

State SendResponse，code FAILURE（04），id1，len 29 Message：Illegal User or password.……

通过以上的分析，不难得出在CHAP单向认证中，为能够对主验方身份进行确认，推荐使用主验方（接口）配置用户的方式，此时在被验方接口推荐配置缺省口令，可以避免通信双方使用同一密码，减少口令泄密的可能性。

另外当被验方希望确定它被连接的是否为真正的主验方，可以在两个方向上都运行CHAP，但每个CHAP会话的共享密钥应该不同。此时在通信双方都需要保存对端的合法用户，在接口上都需要配置提交给对端的本地用户名和缺省口令，且该用户名和口令须与对方保存的用户信息一致。

［1］王达.路由器配置与管理完全手册—H3C篇［M］.武汉：华中科技大学出版社，2011.

［2］寇晓蕤，罗军勇，蔡延荣.网络协议分析［M］.北京：机械工业出版社，2009.

［3］STD51.RFC1661“The Point－to－Point Protocol（PPP）”［S］.Michigan：Network Working Group W.Simpson，July 1994.

CHAP Authentication Analysis of PPP Protocol Based on H3C Router

TIAN Jun

（Mechanical and Electronic and Information Engineering Department，Tianjin City Vocational College，Tianjin300250 China）

This paper introduces the CHAP authentication and configuration of H3C router，and puts forward two configuration methods which can give full play to the security of CHAP authentication through the comparison of several circumstances，namely the user＇s configuration and bi－directional validation at the main verification access.It provides valuable reference for similar projects and cases.

CHAP authentication；local users；access；shared key

TP393

A

1673－582X（2012）02－0065－06

2011－11－15

田君（1972－），女，天津市人，天津城市职业学院副教授，主要从事计算机网络数据库应用教学和研究。