PPP挑戰握手身份驗證協議(CHAP)

2019-11-04 11:14:12

字體：大中小

來源：轉載

供稿：網友

　　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
　　　算*
　　　　算*字段一字節，指示所使用的認證方*，最?翟謐钚碌摹傲ssigned
　　　　 Number”【2】中指定，必須實現的值是：
　　　　　　 5　　MD5【3】下的CHAP
　　4.　包格式
　　　 CHAP數據包封裝在PPP數據鏈路層幀的信息域中，PPP的協議字段指示0xc223，
　　　 CHAP包格式如下圖所示，字段從左到右傳輸。
　　　 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
　　　　　 Code　　　　Identifier　　　　　　 Length　　　　　　
　　　 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
　　　　　Data ...
　　　 +-+-+-+-+
　　　代碼　Code
　　　　代碼字段一字節，指示CHAP包的類型，分配如下：
　　　　　　 1　　　挑戰　Challenge
　　　　　　 2　　　應答　Response
　　　　　　 3　　　成功∮UCcess
　　　　　　 4　　　失敗　Failure
　　　標識符　Identifier
　　　　標識符字段一字節，輔助匹配挑戰、應答和響應。
　　　長度　Length
　　　　長度字段兩字節，指示CHAP包的長度，包括代碼、長度和數據字段。超出
　　　　長度的字節應該視為數據鏈路層填充，接收方應該忽略。
　　　數據　Data
　　　　數據字段是零個或多個字節，數據字段格式由代碼字段確定。
　　4.1.　挑戰和應答
　　　描述
　　　　挑戰包是CHAP的開始，認證者必須傳送代碼字段為1的CHAP包，其他挑戰
　　　　數據包必須在有效應答數據包成功接收之后或者可選重試計數器計滿后發
　　　　　送。
　　　　為了確保連接沒有被更改，挑戰包也可以在NLP階段的任何時候發送。
　　　　對端應該隨時為認證階段和NLP階段的挑戰做好預備，任何時候收到挑戰
　　　　包，對端都必須傳送代碼字段為2（應答）的CHAP數據包。
　　　　無論何時，假如收到應答包，認證者都必須把應答值和自己計算的預期值
　　　　比較，基于這種比較，認證者必須發送成功（Success）或者失敗
　　　　　（Failure）CHAP包。
　　　　　　注：由于成功包可能丟失，認證者在NLP階段中必須答應重復的應答包，
　　　　　　為了發現更改的名字和密鑰，收到具有當前挑戰標識符的應答包必須返
　　　　　　回與先前挑戰同樣的響應代碼（消息部分可能不相同），在任何其他階
　　　　　　段收到的任何應答包必須靜靜丟棄。
　　　　　　假如“失敗包”丟失，認證者終止了鏈路，那么可以由LCP的“終

上一篇：BGP學習

下一篇：PE的OSPF設置