概況
簡述
詢問握手認證協定（CHAP）通過三次握手周期性的校驗對端的身份，在初始鏈路建立時完成，可以在鏈路建立之後的任何時候重複進行。
1. 鏈路建立階段結束之後，認證者向對端點傳送“challenge”訊息。
2. 對端點用經過單向哈希函式計算出來的值做應答。
3. 認證者根據它自己計算的哈希值來檢查應答，如果值匹配，認證得到承認；否則，連線應該終止。
4. 經過一定的隨機間隔，認證者傳送一個新的 challenge 給端點，重複步驟 1 到 3 。
通過遞增改變的標識符和可變的詢問值，CHAP 防止了來自端點的重放攻擊，使用重複校驗可以限制暴露於單個攻擊的時間。認證者控制驗證頻度和時間。
特性
該認證方法依賴於只有認證者和對端共享的密鑰，密鑰不是通過該鏈路傳送的。
雖然該認證是單向的，但是在兩個方向都進行 CHAP 協商，同一密鑰可以很容易的實現相互認證。
由於 CHAP 可以用在許多不同的系統認證中，因此可以用 NAME 欄位作為索引，以便在一張大型密鑰表中查找正確的密鑰，這樣也可以在一個系統中支持多個 NAME/ 密鑰對，並可以在會話中隨時改變密鑰。
CHAP 要求密鑰以明文形式存在，無法使用通常的不可回復加密口令資料庫。
CHAP是以MD5加密算法進行口令認證。
CHAP 在大型網路中不適用，因為每個可能的密鑰由鏈路的兩端共同維護。
協定結構
CHAP 幀格式
CHAP 的配置選項格式如下：
8 16 32 40 bit
Type Length Authentication-Protocol Algorithm
Type ― 3
Length ― 5
Authentication-Protocol ― 對於 CHAP，為 C223（Hex）。
Algorithm ― Algorithm 欄位為八位位元組，表示使用的認證方法。
CHAP 數據包結構如下所示：
8 16 32 bit Variable
Code> Identifier Length Data . . .
Code ― 識別 CHAP 數據包類型。CHAP 代碼具有以下幾種：1、Challenge；2、Response；3、Success；4、Failure。
Identifier ― 用於匹配 Challenges、Responses 和 Replies 信息。
Length ― CHAP 數據包的長度，包括 Code、Identifier、Length 和 Data 欄位。
Data ― 0或更多八位位元組。該欄位格式取決於 Code 欄位。對於 Success 和 Failure，Data 欄位包括一個獨立執行的可變信息欄位
CHAP性能分析
應更強大的記憶式密碼認證系統的需要——能適用在公共網路中。Intemet Engineering Task Force公布了一個被稱作“CHAP”的協定標準和使用指導。利用這一協定，專門設計的應用程式和網路設備就可以發出密碼寫成的詢問/應答對話，來確定彼此的身份。
對用戶來說，CHAP認證通常是自動的和一目了然的。事實上，CHAP的主要作用不是進行用戶認證，而是主要用來幫助“黑匣子”進行信息傳播。CHAP在現代網關裝置中比較常見，例如路由器和一般伺服器，它們在允許網路連線之前，都要詢問和鑑定CHAP加密的記憶式密碼。
CHAP認證幾乎和所有的路由器以及一般伺服器設備兼容，因此可以安裝在幾乎所有的Intemet網關上。它也與大部分的PPP客戶端軟體兼容，其中包括Microsoft Windows提供的一些主流PPP客戶端。然而，它與大多數的“legacy”套用不能兼容，其中包括絕大多數的主機設備和微機的登錄系統。
在Internet上傳輸時，CHAP表現出了足夠強大的抗攻擊能力。然而，當CHAP全自動和透明時，它就不能夠準確鑑別人類用戶的身份了。即使要求輸入記憶式密碼而且這個密碼還被CHAP加密，它也仍然存在被身後的人輕鬆窺視到的致命弱點。因此，通常認可的計算機操作在承認記憶式密碼的地方也允許使用CHAP認證，同時可以在單獨使用記憶式密碼不能滿足網路暴露時使用CHAP認證。
然而，即使是最好的CHAP配置也不能夠解決有關環境的物理安全和可接近性的所列問題，因為使用記憶式密碼時通常是不能遠離身邊其他電腦工作者的。
配置方法
chap步驟一：配置路由器的IP位址。 基礎配置省略，串列鏈路要記得配置時鐘頻率。
步驟二：將R1的 s1接口改為ppp協定. 並配置 雙向身份驗證 R1(config)#inter serial 0/3/0
R1(config-if)#encapsulation ppp
R1(config-if)#exit
R1(config)#hostname R1 //R1 將作為PPP 的用戶名
R1(config)#username R2 password cisco
//配置本地用戶名密碼資料庫。用於確認其它設備的身份。
R1(config)#interface serial 0/3/0
R1(config-if)#ppp authentication [ chap | pap ]
//指定採用chap 的進行身份驗證
步驟三：將R2的S0改為PPP協定，並配置身份驗證 R2(config)#host R2
R2(config)#username R1 password cisco
R2(config)#interface serial 0
R2(config-if)#encapsulation ppp
R2(config-if)#ppp authentication [ chap | pap ]
步驟四：確認雙方是否可以PING通。 步驟五：配置CHAP單向的身份驗證,R2配置基礎上添加一個新的用戶 R2(config)#username wy password 123
步驟六：配置R1的PPP認證。 R1(config)#interface serial 1
R1(config-if)#encapsulation ppp
R1(config-if)#ppp chap hostname wy //傳送chap 的用戶名
R1(config-if)#ppp chap password 123 //傳送chap 的密碼
R1(config-if)#exit
步驟七：確認雙方是否可以PING通。 步驟八：配置PAP的單向的身份驗證，在原先的配置基礎上將R2改為pap的認證 R2(config)#interface serial 0
R2(config-if)#encapsulation ppp
R2(config-if)#ppp authentication pap
R2(config-if)#exit
步驟九：配置R1的PPP認證 R1(config)#interface serial 1
R1(config-if)#encapsulation ppp
R1(config-if)#ppp pap sent-username wy password 123 //傳送pap 的用戶名和密碼
步驟十：確認雙方是否可以PING通。
故障排查
可用以下命令進行故障排查
debug ppp negotiation-確定客戶端是否可以通過PPP協商; 這是您檢查地址協商的時候。
debug ppp authentication-確定客戶端是否可以通過驗證。 如果您在使用Cisco IOS軟體版本11.2之前的一個版本，請發出debug ppp chap命令。
debug ppp error – 顯示和PPP連線協商與操作相關的協定錯誤以及統計錯誤。
debug aaa authentication-要確定在使用哪個方法進行驗證(應該是RADIUS，除非RADIUS伺服器發生故障)，以及用戶是否通過驗證。
debug aaa authorization-要確定在使用哪個方法進行驗證，並且用戶是否通過驗證。
debug aaa accounting-查看傳送的記錄。
debug radius-查看用戶和伺服器交換的屬性。
