PPP協(xié)議基于H3C路由器的CHAP認(rèn)證分析

田 君

PPP協(xié)議基于H3C路由器的CHAP認(rèn)證分析

田 君

（天津城市職業(yè)學(xué)院 機(jī)電與信息工程系，天津 300250）

介紹基于H3C路由器的CHAP認(rèn)證及配置要點(diǎn)，并通過幾種情況的對(duì)比，提出充分發(fā)揮CHAP認(rèn)證安全性的兩種配置方法，即在主驗(yàn)方接口配置用戶及雙向驗(yàn)證，對(duì)類似工程案例具有良好的借鑒或參考意義。

CHAP認(rèn)證；本地用戶；接口；共享密鑰

PPP是一種點(diǎn)到點(diǎn)方式的數(shù)據(jù)鏈路層協(xié)議，是在SLIP（Serial Line IP，串行線IP協(xié)議）的基礎(chǔ)上發(fā)展起來，能夠提供用戶驗(yàn)證，易于擴(kuò)充，并且支持同／異步通信，因而獲得廣泛應(yīng)用。隨著新型寬帶技術(shù)的推出PPP衍生出新的形式，如符合ADSL（Asymmetrical Digital Subscriber Line，非對(duì)稱數(shù)字用戶線路）接入要求的PPPoE（PPP over Ethernet，以太網(wǎng)上的PPP）和PPPoA（PPP over ATM，ATM 上的PPP）。

PAP是基于口令的認(rèn)證方式。由被驗(yàn)方發(fā)起認(rèn)證，將被驗(yàn)方的用戶名和口令以明文的方式發(fā)送給主驗(yàn)方，由于被驗(yàn)方不停地在鏈路上反復(fù)發(fā)送用戶名和口令，直到身份驗(yàn)證過程結(jié)束，所以無法防止竊聽、重放和窮舉攻擊，是一種不安全的認(rèn)證協(xié)議。

CHAP是基于挑戰(zhàn)的認(rèn)證協(xié)議，通過三次握手周期性的校驗(yàn)對(duì)端的身份，在初始鏈路建立時(shí)完成，也可以在鏈路建立之后的任何時(shí)候重復(fù)進(jìn)行。如圖1－a所示CHAP由主驗(yàn)方發(fā)起認(rèn)證，向被驗(yàn)方發(fā)出一個(gè)Challenge報(bào)文，其中包含隨機(jī)數(shù)c，此隨機(jī)數(shù)是此身份驗(yàn)證會(huì)話惟一的一些信息；作為響應(yīng)，被驗(yàn)方將雙方共享的密鑰s和c一起作為輸入，計(jì)算散列值A(chǔ)1（散列函數(shù)通常使用md5），并通過Response報(bào)文返回；主驗(yàn)方在本地將s和c作為輸入，用同一散列函數(shù)計(jì)算散列值A(chǔ)2，并與A1進(jìn)行比較。若A2＝A1，說明被驗(yàn)證方擁有正確的共享秘密，驗(yàn)證通過返回ACK，否則驗(yàn)證失敗返回NAK。在會(huì)話過程中始終重復(fù)該過程，以驗(yàn)證正確的被驗(yàn)方仍在連接中。重復(fù)這些步驟可以防止有人通過“重放”從線路上截獲的信息來“偷聽”被驗(yàn)方的會(huì)話。CHAP報(bào)文格式如圖1－b所示，包括code字段（代碼），ID字段（標(biāo)識(shí)），len字段（報(bào)文長(zhǎng)度），value字段（報(bào)文的具體內(nèi)容）。下面分三種情況討論在H3C路由器上使用PPP協(xié)議的CHAP認(rèn)證的驗(yàn)證過程、配置方法及注意事項(xiàng)。

情況一 主驗(yàn)方未配置用戶且被驗(yàn)方配置接口缺省口令

如圖2所示主驗(yàn)方RTA主動(dòng)發(fā)起驗(yàn)證請(qǐng)求，向被驗(yàn)方RTB發(fā)送一些隨機(jī)報(bào)文（Challenge，挑戰(zhàn)）；被驗(yàn)方接到驗(yàn)證方請(qǐng)求后，利用報(bào)文ID、缺省口令rtbchap和MD5算法對(duì)該隨機(jī)報(bào)文進(jìn)行加密，將生成的密文和自己的用戶名rtb發(fā)回主驗(yàn)方（Response）；主驗(yàn)方根據(jù)收到的被驗(yàn)用戶rtb查找與之對(duì)應(yīng)的密碼rtbchap，然后使用該密碼和MD5算法對(duì)原隨機(jī)報(bào)文進(jìn)行加密，比較二者的密文，相同則返回結(jié)果ACK，否則返回NAK。

圖1 CHAP認(rèn)證過程及報(bào)文格式

圖2 主驗(yàn)方未配用戶的CHAP認(rèn)證

這種情況需要在主驗(yàn)方保存對(duì)端合法用戶，并在接口配置驗(yàn)證對(duì)端的認(rèn)證協(xié)議；在被驗(yàn)方接口配置需提交的用戶名和缺省口令即可，具體配置方法如下：（以H3C路由器 MSR30－20為例，下同）

＃在主驗(yàn)方配置合法用戶

［RTA］local－user rtb

［RTA－luser－rtb］service－type ppp

＃在主驗(yàn)方接口配置驗(yàn)證對(duì)端的認(rèn)證協(xié)議為chap認(rèn)證協(xié)議

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

＃在被驗(yàn)方接口配置驗(yàn)證時(shí)提交的用戶名和缺省口令

［RTB－Serial6／0］ppp chapuser rtb

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

在被驗(yàn)方通過debugging ppp chap packet，可以了解到雙方的chap認(rèn)證過程，主要內(nèi)容及說明如下：＊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

這些數(shù)據(jù)是主驗(yàn)方發(fā)來的packet。這個(gè)packet中code字段值為01，表示此數(shù)據(jù)報(bào)文為一個(gè)challenge。id字段值為1，用以標(biāo)識(shí)本次身份驗(yàn)證會(huì)話，本次會(huì)話所有的詢問和響應(yīng)packet此字段值均相同。value字段值（十六進(jìn)制表示）為2e dd be e1 74 db17 9f a0e3 14 27 47 ec c2 85，此字段是由主驗(yàn)方生成的惟一的且不可預(yù)測(cè)的值，該值的惟一性可以防止攻擊者試圖用以前截取的值欺騙主驗(yàn)方。另外從這些數(shù)據(jù)中不難看出，密鑰不在網(wǎng)絡(luò)中傳送，不會(huì)被竊聽；而且由于使用三次握手的方法，被驗(yàn)方如果沒有收到“挑戰(zhàn)信息”就不能進(jìn)行驗(yàn)證，因此在某種程度上chap協(xié)議不容易被強(qiáng)制攻擊。

＊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

以上數(shù)據(jù)為被驗(yàn)方向主驗(yàn)方發(fā)送的packet。這個(gè)packet中code字段值為02，表示此數(shù)據(jù)報(bào)文為一個(gè)response。id字段值為1，標(biāo)識(shí)本次身份驗(yàn)證會(huì)話，與本次會(huì)話前面packet的id字段值相同。value字段值（十六進(jìn)制表示）為ae c4 2d 57 18 51 51 b7 8e 1 a8 e 21 50 1f 7b，此字段是由被驗(yàn)方將id字段值、Serial 6／0接口缺省口令rtbchap和本次會(huì)話前面packet收到的value字段值2e dd be e1 74 db17 9f a0e3 14 27 47 ec c2 85，使用MD5加密創(chuàng)建的單向散列。這個(gè)散列值連同被驗(yàn)方接口Serial 6／0上配置的用戶rtb一起組成packet提交給主驗(yàn)方。

＊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.

以上數(shù)據(jù)為被驗(yàn)方收到主驗(yàn)方發(fā)來的認(rèn)證通過packet。這個(gè)packet中code字段值為03，表示身份驗(yàn)證成功。id字段值為1，標(biāo)識(shí)本次身份驗(yàn)證會(huì)話，與本次會(huì)話前面packet的id字段值相同。

情況二 主驗(yàn)方接口配置用戶且被驗(yàn)方配置接口缺省口令

如圖3所示主驗(yàn)方RTA首先向被驗(yàn)方RTB發(fā)送自己的用戶名rta及一些隨機(jī)報(bào)文；被驗(yàn)方RTB接到請(qǐng)求后，優(yōu)先使用被驗(yàn)方接口的缺省口令rtbchap、報(bào)文ID和MD5算法對(duì)該隨機(jī)報(bào)文進(jìn)行加密，將生成的密文和自己的用戶名rtb發(fā)回主驗(yàn)方RTA；主驗(yàn)方RTA根據(jù)收到的被驗(yàn)方的用戶名rtb查找與之對(duì)應(yīng)的密碼rtbchap，然后使用該密碼rtbchap和MD5算法對(duì)原隨機(jī)報(bào)文進(jìn)行加密，比較二者的密文，相同則返回結(jié)果ACK，否則返回NAK。

圖3 主驗(yàn)方配用戶且被驗(yàn)方配接口缺省口令的CHAP認(rèn)證

這種情況主驗(yàn)方需要保存對(duì)端的合法用戶；此外主驗(yàn)方需要在接口配置驗(yàn)證對(duì)端的認(rèn)證協(xié)議及自己的用戶名；被驗(yàn)方需要在接口配置自己的用戶名及缺省口令。這里需要說明的是被驗(yàn)方接口配置了缺省口令則加密時(shí)優(yōu)先選用，即使在被驗(yàn)方本地保存了主驗(yàn)方合法用戶rta（口令rtachap），在加密收到的隨機(jī)報(bào)文時(shí)，也不會(huì)使用密碼rtachap。具體配置方法如下：

＃在主驗(yàn)方配置合法用戶

［RTA］local－user rtb

［RTA－luser－rtb］password simple rtbchap

［RTA－luser－rtb］service－type ppp

＃在主驗(yàn)方接口配置驗(yàn)證對(duì)端的認(rèn)證協(xié)議為chap認(rèn)證協(xié)議［RTA－Serial6／0］ppp authentication－mode chap＃在主驗(yàn)方接口配置發(fā)送給被驗(yàn)方的本地用戶名［RTA－Serial6／0］ppp chapuser rta

＃在被驗(yàn)方接口配置驗(yàn)證時(shí)提交的用戶名和缺省口令［RTB－Serial6／0］ppp chapuser rtb

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

在被驗(yàn)方通過執(zhí)行debugging ppp chap packet，可以了解雙方chap認(rèn)證過程：……

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

PPP Packet： ——收到主驗(yàn)方chap認(rèn)證challenge（主驗(yàn)用戶rta＋隨機(jī)報(bào)文）

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： ——提交被驗(yàn)方chap認(rèn)證信息（被驗(yàn)用戶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： ——認(rèn)證通過

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

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

情況三 通信雙方接口均配置用戶但被驗(yàn)方接口未配缺省口令

如圖4所示主驗(yàn)方RTA首先向被驗(yàn)方RTB發(fā)送自己的用戶名rta及一些隨機(jī)報(bào)文；被驗(yàn)方RTB接到請(qǐng)求后，根據(jù)收到的主驗(yàn)方用戶名rta在本地查找與之對(duì)應(yīng)的密碼hello，然后使用該密碼、報(bào)文ID和MD5算法對(duì)該隨機(jī)報(bào)文進(jìn)行加密，將生成的密文和自己的用戶名rtb發(fā)回主驗(yàn)方RTA；主驗(yàn)方RTA根據(jù)收到的被驗(yàn)方的用戶名rtb在本地查找與之對(duì)應(yīng)的密碼hello，然后使用該密碼和MD5算法對(duì)原隨機(jī)報(bào)文進(jìn)行加密，比較二者的密文，相同則返回結(jié)果ACK，否則返回NAK。

這種情況在雙方都需保存對(duì)端的合法用戶；主驗(yàn)方需要在接口配置驗(yàn)證對(duì)端的認(rèn)證協(xié)議及自己的用戶名；被驗(yàn)方需要在接口配置自己的用戶名。這里需要注意的是在通信雙方不僅必須保存對(duì)端的合法用戶，而且為保證認(rèn)證的順利通過，還必須保證雙方的口令一致。具體配置方法如下：

＃在主驗(yàn)方配置合法用戶

［RTA］local－user rtb

［RTA－luser－rtb］password simple hello

［RTA－luser－rtb］service－type ppp

＃在主驗(yàn)方接口配置驗(yàn)證對(duì)端的認(rèn)證協(xié)議為chap認(rèn)證協(xié)議

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

＃在主驗(yàn)方接口配置challenge中提交的本地用戶名

［RTA－Serial6／0］ppp chapuser rta

圖4 通信雙方均配置用戶但被驗(yàn)方接口未配缺省口令的CHAP認(rèn)證過程

＃在被驗(yàn)方配置合法用戶

［RTB］local－user rta

［RTB－luser－rta］password simple hello

［RTB－luser－rta］service－type ppp

＃在被驗(yàn)方接口配置驗(yàn)證時(shí)提交的用戶名

［RTB－Serial6／0］ppp chapuser rtb

在被驗(yàn)方通過執(zhí)行debugging ppp chap packet，可以了解雙方chap認(rèn)證過程：……

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

PPP Packet： ——收到主驗(yàn)方chap認(rèn)證challenge（主驗(yàn)用戶rta＋隨機(jī)報(bào)文）

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： ——提交被驗(yàn)方chap認(rèn)證信息（被驗(yàn)用戶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： ——認(rèn)證通過

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

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

Message：Welcome to rta.……

因?yàn)橥ㄐ烹p方都會(huì)以本地所存用戶的口令進(jìn)行加密，如果雙方本地所存對(duì)端合法用戶的口令不一致，將導(dǎo)致認(rèn)證失敗，假定主驗(yàn)方合法用戶rta的口令為rtachap，被驗(yàn)方合法用戶rtb的口令為rtbchap，在被驗(yàn)方通過執(zhí)行debugging ppp chap packet，可以了解雙方chap認(rèn)證過程：

……

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

PPP Packet： ——收到主驗(yàn)方chap認(rèn)證challenge（主驗(yàn)用戶rta＋隨機(jī)報(bào)文）

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： ——提交被驗(yàn)方chap認(rèn)證信息（被驗(yàn)用戶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： ——認(rèn)證失敗（原因：非法用戶或口令）

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

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

通過以上的分析，不難得出在CHAP單向認(rèn)證中，為能夠?qū)χ黩?yàn)方身份進(jìn)行確認(rèn)，推薦使用主驗(yàn)方（接口）配置用戶的方式，此時(shí)在被驗(yàn)方接口推薦配置缺省口令，可以避免通信雙方使用同一密碼，減少口令泄密的可能性。

另外當(dāng)被驗(yàn)方希望確定它被連接的是否為真正的主驗(yàn)方，可以在兩個(gè)方向上都運(yùn)行CHAP，但每個(gè)CHAP會(huì)話的共享密鑰應(yīng)該不同。此時(shí)在通信雙方都需要保存對(duì)端的合法用戶，在接口上都需要配置提交給對(duì)端的本地用戶名和缺省口令，且該用戶名和口令須與對(duì)方保存的用戶信息一致。

［1］王達(dá).路由器配置與管理完全手冊(cè)—H3C篇［M］.武漢：華中科技大學(xué)出版社，2011.

［2］寇曉蕤，羅軍勇，蔡延榮.網(wǎng)絡(luò)協(xié)議分析［M］.北京：機(jī)械工業(yè)出版社，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－），女，天津市人，天津城市職業(yè)學(xué)院副教授，主要從事計(jì)算機(jī)網(wǎng)絡(luò)數(shù)據(jù)庫應(yīng)用教學(xué)和研究。