田 君

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

田 君

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

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

CHAP認證；本地用戶；接口；共享密鑰

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

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

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

情況一 主驗方未配置用戶且被驗方配置接口缺省口令

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

圖1 CHAP認證過程及報文格式

圖2 主驗方未配用戶的CHAP認證

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

＃在主驗方配置合法用戶

［RTA］local－user rtb

［RTA－luser－rtb］service－type ppp

＃在主驗方接口配置驗證對端的認證協(xié)議為chap認證協(xié)議

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

＊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ù)為被驗方向主驗方發(fā)送的packet。這個packet中code字段值為02，表示此數(shù)據(jù)報文為一個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加密創(chuàng)建的單向散列。這個散列值連同被驗方接口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.

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

情況二 主驗方接口配置用戶且被驗方配置接口缺省口令

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

圖3 主驗方配用戶且被驗方配接口缺省口令的CHAP認證

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

＃在主驗方配置合法用戶

［RTA］local－user rtb

［RTA－luser－rtb］password simple rtbchap

［RTA－luser－rtb］service－type ppp

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

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

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

在被驗方通過執(zhí)行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發(fā)送自己的用戶名rta及一些隨機報文；被驗方RTB接到請求后，根據(jù)收到的主驗方用戶名rta在本地查找與之對應(yīng)的密碼hello，然后使用該密碼、報文ID和MD5算法對該隨機報文進行加密，將生成的密文和自己的用戶名rtb發(fā)回主驗方RTA；主驗方RTA根據(jù)收到的被驗方的用戶名rtb在本地查找與之對應(yīng)的密碼hello，然后使用該密碼和MD5算法對原隨機報文進行加密，比較二者的密文，相同則返回結(jié)果ACK，否則返回NAK。

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

＃在主驗方配置合法用戶

［RTA］local－user rtb

［RTA－luser－rtb］password simple hello

［RTA－luser－rtb］service－type ppp

＃在主驗方接口配置驗證對端的認證協(xié)議為chap認證協(xié)議

［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

在被驗方通過執(zhí)行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.……

因為通信雙方都會以本地所存用戶的口令進行加密，如果雙方本地所存對端合法用戶的口令不一致，將導(dǎo)致認證失敗，假定主驗方合法用戶rta的口令為rtachap，被驗方合法用戶rtb的口令為rtbchap，在被驗方通過執(zhí)行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： ——認證失?。ㄔ颍悍欠ㄓ脩艋蚩诹睿?/p>

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

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

通過以上的分析，不難得出在CHAP單向認證中，為能夠?qū)χ黩灧缴矸葸M行確認，推薦使用主驗方（接口）配置用戶的方式，此時在被驗方接口推薦配置缺省口令，可以避免通信雙方使用同一密碼，減少口令泄密的可能性。

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

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

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