?? rfc1994.txt
字號:
組織:中國互動出版網(http://www.china-pub.com/)
RFC文檔中文翻譯計劃(http://www.china-pub.com/compters/emook/aboutemook.htm)
E-mail:ouyang@china-pub.com
譯者:于德雷 (于德雷 ydl_ldy@sina.com)
譯文發布時間:2001-8-8
版權:本中文翻譯文檔版權歸中國互動出版網所有。可以用于非商業用途自由轉載,但必須
保留本文檔的翻譯及版權信息。
Network Working Group W. Simpson
equest for Comments: 1994 DayDreamer
Obsoletes: 1334 August 1996
Category: Standards Track
PPP挑戰握手認證協議(CHAP)
(RFC1994——PPP Challenge Handshake Authentication Protocol (CHAP) )
此備忘錄的狀態
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
摘要
PPP【1】提供了點到點鏈路傳輸多協議數據報的標準方法。
在PPP中也定義了一種可擴展的LCP,允許協商認證協議,從而可以在進行網絡層
協議傳輸之前對對端進行認證。
本文定義了一種PPP認證方法,該方法利用隨機“挑戰”和依據“挑戰”和密鑰
計算出的加密哈希“應答”來完成認證。
目錄
1. 簡介 2
1.1. 要求規范 2
1.2. 術語 3
2. 挑戰握手認證協議 Challenge-Handshake Authentication Protocol 3
2.1. 優點 4
2.2. 缺點 4
2.3. 設計要求 4
3. 配置選項格式 5
4. 包格式 5
4.1. 挑戰和應答 6
4.2. 成功與失敗 8
安全考慮 9
鳴謝 10
參考文獻 10
1. 簡介
為了在點到點鏈路上建立通信,PPP鏈路的每一端在鏈路建立階段必須首先發送
LCP包進行數據鏈路配置。鏈路建立之后,PPP提供可選的認證階段,可以在進入
NLP階段之前實行認證。
缺省情況下,認證并非是強制執行的,如果需要鏈路認證,PPP實現必須在鏈路
建立階段指定“認證協議配置”選項。
這些認證協議主要用于主機和路由器,這些主機和路由器一般通過交換電路線
或者撥號線連在PPP網絡服務器上,但是也可以通過專線實現。服務器可以用主
機或路由器的連接身份來作為網絡層協商的選項。
本文定義了PPP認證協議,鏈路建立階段和認證階段以及認證協議配置選項都
已經在PPP【1】中定義。
1.1. 要求規范
在本文中,用以下幾個詞表示規范描述要求,這幾個詞用大寫標明。
MUST “必須”,也就是形容詞“必需的”,意思是該項是本規范的絕對要求。
MUST NOT “不得”,意思是該項是本規范所絕對禁止的。
SHOULD “應該”,也就是形容詞“推薦的”,意思是在某些場合可能由于某種原因忽
略該項,但是協議的完全實現必須能夠理解該項,在決定其
他方式之前要經過仔細考慮。
MAY “可以”,也就是形容詞“可選的”,意思是該項可以作為可選集使
用,不包含該選項的協議實現必須能夠和包含了該選項的實現交互協
作。
1.2. 術語
本文頻繁使用的術語包括以下幾個:
Authenticator 認證者
鏈路要求認證的一端,認證者在鏈路建立階段的Configure-Request
中指定認證協議。
peer 對端
點到點鏈路的另一端;由認證者認證的一端。
silently discard 靜靜丟棄
協議實現直接丟棄數據包,不作進一步處理,實現應該提供記錄錯誤
的能力——包括被靜靜丟棄的包的內容,還應該在統計計數器里記錄
事件。
2. 挑戰握手認證協議 Challenge-Handshake
Authentication Protocol
挑戰握手認證協議(CHAP)通過三次握手周期性的認證對端的身份,在初始鏈路
建立時完成,可以在鏈路建立之后的任何時候重復進行。
1. 鏈路建立階段結束之后,認證者向對端發送“挑戰”消息。
2. 對端用經過單向哈希函數計算出來的值做應答。
3. 認證者根據它自己的預期哈希值的計算來檢查應答,如果值匹配,認證得
到承認;否則,連接應該終止。
4. 經過一定的隨機間隔,認證者發送一個新的挑戰給對端,重復1到3。
2.1. 優點
通過遞增改變的標識符和可變的挑戰值,CHAP防止了重放攻擊,重復挑戰限制了
對單個攻擊的暴露時間,認證者控制挑戰的頻度。
該認證方法依賴于認證者和對端共享的密鑰,密鑰不是通過該鏈路發送的。
雖然該認證是單向的,但是在兩個方向都進行CHAP協商,同一密鑰可以很容易的
實現交互認證。
由于CHAP可以用在許多不同的系統認證中,因此可以用NAME字段作為索引,以便
在一張大型密鑰表中查找正確的密鑰,這樣也可以在一個系統中支持多個NAME/
密鑰對,在會話中隨時改變密鑰。
2.2. 缺點
CHAP要求密鑰以明文形式存在,無法使用通常的不可回復加密口令數據庫。
在大型設備中不適用,因為每個可能的密鑰由鏈路的兩端共同維護。
注:為了避免在網絡的其他鏈路上發送密鑰,推薦在中心服務器中檢查挑戰
和應答,而不是在每一個接入服務器中,否則,密鑰最好發送到可回復加密
格式的服務器中。無論那種情況都需要信任關系,信任關系的討論超出本文
的范圍。
2.3. 設計要求
CHAP算法要求密鑰長度必須至少是一字節,至少應該不易讓人猜出,密鑰最好
至少是哈希算法(16字節,MD5)所選用的哈希值的長度,如此可以保證密鑰
不易受到窮搜索攻擊。
所選用的哈希算法,必須使得從已知挑戰值和應答值來確定密鑰在計算上是不
可行的。
每一個挑戰值應該是唯一的,否則在同一密鑰下,重復挑戰值將使攻擊者能夠
用以前截獲的應答值響應挑戰。由于希望同一密鑰可以用于地理上分散的不同
服務器的認證,因此挑戰應該全局臨時唯一。
每一個挑戰值也應該是不可預計的,否則攻擊者可以欺騙對端,讓對端響應一
個預計的的挑戰值,然后用該響應冒充對端欺騙認證者。
雖然CHAP不能防止實時的主動搭線竊聽攻擊,然后只要能產生不可預計的挑戰
就可以防范大多數的主動攻擊。
唯一性來源和分歧可能性在魔術數配置選項【1】中討論。
3. 配置選項格式
協商CHAP的“認證協議配置選項”格式如下圖所示,字段從左到右傳輸。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Authentication-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm |
+-+-+-+-+-+-+-+-+
類型 Type
3
長度 Length
5
認證協議 Authentication-Protocol
0xc223 CHAP
算法
算法字段一字節,指示所使用的認證方法,最新值在最新的“Assigned
Number”【2】中指定,必須實現的值是:
5 MD5【3】下的CHAP
4. 包格式
CHAP數據包封裝在PPP數據鏈路層幀的信息域中,PPP的協議字段指示0xc223,
CHAP包格式如下圖所示,字段從左到右傳輸。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+
代碼 Code
代碼字段一字節,指示CHAP包的類型,分配如下:
1 挑戰 Challenge
2 應答 Response
3 成功 Success
4 失敗 Failure
標識符 Identifier
標識符字段一字節,輔助匹配挑戰、應答和響應。
長度 Length
?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -