rfc1134_+ppp協(xié)議關(guān)于在點(diǎn)到點(diǎn)鏈路上進(jìn)行多協(xié)議包傳送的建議

1、<p>　　組織：中國(guó)互動(dòng)出版網(wǎng)（http://www.china-pub.com/）</p><p>　　RFC文檔中文翻譯計(jì)劃（http://www.china-pub.com/compters/emook/aboutemook.htm）</p><p>　　E-mail：ouyang@china-pub.com</p><p>　　譯者：王奎（pyw

2、ang wangtianzhi@263.net）</p><p>　　譯文發(fā)布時(shí)間：2001-12-28</p><p>　　版權(quán)：本翻譯文檔可以用于非商業(yè)用途自由轉(zhuǎn)載，但必須保留本文檔的翻譯及組織信息。</p><p>　　Network Working Group B. Llo

3、yd</p><p>　　Request for Comments: 1334 L&A</p><p>　　W. Simpson</p><p>　　Daydreamer</p><p>　　October 1992</p><p&

4、gt;　　PPP 身份驗(yàn)證協(xié)議</p><p>　?。≧FC1334——PPP Authentication Protocols ）</p><p><b>　　備忘錄狀態(tài)</b></p><p>　　此RFC 為internet community詳細(xì)說明了 IAB 標(biāo)準(zhǔn)跟蹤協(xié)議，并且請(qǐng)求討論和建議以便改進(jìn)。請(qǐng)參考IAB Official P

5、rotocol Standards 的當(dāng)前版本，確保這個(gè)協(xié)議陳述和狀態(tài)的標(biāo)準(zhǔn)化。此備忘錄的分發(fā)不受限制。</p><p><b>　　摘要</b></p><p>　　點(diǎn)到點(diǎn)協(xié)議（the Point-to-Point Protocol）提供了一種在點(diǎn)到點(diǎn)鏈路上封裝網(wǎng)絡(luò)層協(xié)議信息的標(biāo)準(zhǔn)方法。PPP 也定義了可擴(kuò)展的鏈路控制協(xié)議(Link Control Protocol

6、)，它（Link Control Protocol）使用驗(yàn)證協(xié)議磋商在鏈路上傳輸網(wǎng)絡(luò)層協(xié)議前驗(yàn)證鏈路的對(duì)端。</p><p>　　這個(gè)文檔定義了兩種驗(yàn)證協(xié)議：密碼驗(yàn)證協(xié)議（the Password Authentication Protocol）和挑戰(zhàn)－握手驗(yàn)證協(xié)議（the Challenge-Handshake Authentication Protocol）。此RFC是IETF(the Internet En

7、gineering Task Force)的PPP協(xié)議工作組的成果。關(guān)于這個(gè)備忘錄的建議請(qǐng)?zhí)峤唤o：ietf-ppp@ucdavis.edu郵件列表。</p><p><b>　　目錄</b></p><p><b>　　1. 介紹2</b></p><p>　　1.1要求說明書2</p><p>

8、;<b>　　1.2術(shù)語(yǔ)2</b></p><p>　　2. 密碼驗(yàn)證協(xié)議3</p><p>　　2.1 配置選項(xiàng)格式3</p><p><b>　　2.2 包格式4</b></p><p>　　3.1配置選項(xiàng)格式6</p><p><b>　　3.2包格

9、式7</b></p><p><b>　　安全考慮10</b></p><p><b>　　參考文獻(xiàn)10</b></p><p><b>　　致謝11</b></p><p><b>　　主席地址11</b></p>&

10、lt;p><b>　　作者地址11</b></p><p><b>　　完整版權(quán)說明11</b></p><p><b>　　致謝12</b></p><p><b>　　1. 介紹</b></p><p>　　PPP 有三個(gè)主要的組成部分：&

11、lt;/p><p>　　在串行鏈路上封裝數(shù)據(jù)報(bào)（datagrams）的方法。</p><p>　　建立，配置和測(cè)試數(shù)據(jù)鏈路鏈接（the data-link connection）的LCP協(xié)議（Link Control Protocol）。</p><p>　　建立和配置不同網(wǎng)絡(luò)層協(xié)議的一組NCP協(xié)議（Network Control Protocol）。</p>

12、;<p>　　為了在點(diǎn)到點(diǎn)鏈路（point-to-point link）上建立通信，PPP鏈路的一端必須在建立階段（Establishment phase）首先發(fā)送LCP包（packets）配置數(shù)據(jù)鏈路。在鏈路建立后，在進(jìn)入到網(wǎng)絡(luò)層協(xié)議階段前，PPP提供一個(gè)可選擇的驗(yàn)證階段。</p><p>　　默認(rèn)的，身份驗(yàn)證不是強(qiáng)制的。如果希望進(jìn)行鏈路的身份驗(yàn)證，則實(shí)現(xiàn)者必須在建立階段指明身份驗(yàn)證－協(xié)議配置選項(xiàng)

13、。</p><p>　　這些協(xié)議主要是為通過交換網(wǎng)（switched circuits）或者撥號(hào)線(dial-up lines)連接到PPP網(wǎng)絡(luò)服務(wù)器的主機(jī)和路由器服務(wù)的，但是也可以被用到專用鏈路（dedicated links）中。服務(wù)器在為網(wǎng)絡(luò)層磋商選擇選項(xiàng)時(shí)可以對(duì)連接的主機(jī)或路由器進(jìn)行身份驗(yàn)證。</p><p>　　此文檔定義了PPP身份驗(yàn)證協(xié)議。鏈路建立和驗(yàn)證階段，和驗(yàn)證協(xié)議配置選

14、項(xiàng)定義在PPP協(xié)議中[1]。</p><p><b>　　1.1要求說明書</b></p><p>　　在本文檔中，用以下幾個(gè)詞來表示說明書的要求，這些詞一般以大寫字體書寫。</p><p><b>　　MUST</b></p><p>　　這個(gè)詞表示在此說明書中是絕對(duì)要求的。</p>

15、<p><b>　　MUST NOT</b></p><p>　　這個(gè)詞組表示在此說明書中是絕對(duì)禁止的。</p><p><b>　　SHOULD</b></p><p>　　此詞表示在此說明書中是推薦的。</p><p><b>　　MAY</b></p&g

16、t;<p>　　此詞表示在此說明書中是可選的。</p><p><b>　　1.2術(shù)語(yǔ)</b></p><p>　　本文檔中，頻繁使用以下術(shù)語(yǔ)：</p><p>　　authenticator――驗(yàn)證者：</p><p>　　要求驗(yàn)證的鏈路端點(diǎn)。驗(yàn)證者說明了在鏈路建立階段使用的驗(yàn)證協(xié)議。</p>

17、<p>　　Peer――點(diǎn)到點(diǎn)鏈路的另一端：</p><p>　　正在被驗(yàn)證者驗(yàn)證的一端。</p><p>　　Silently discard――靜靜地丟棄</p><p>　　丟棄packet而不進(jìn)行進(jìn)一步的處理。執(zhí)行（這個(gè)動(dòng)作）應(yīng)該提供記錄錯(cuò)誤，包括丟棄packet的內(nèi)容，的容量，并且應(yīng)該在一個(gè)統(tǒng)計(jì)計(jì)數(shù)器中記錄這一事件。</p>&

18、lt;p><b>　　2. 密碼驗(yàn)證協(xié)議</b></p><p>　　密碼驗(yàn)證協(xié)議（PAP）提供了一種簡(jiǎn)單的方法，可以使對(duì)端（peer）使用2次握手建立身份驗(yàn)證。這個(gè)方法僅僅在鏈路初始化時(shí)使用。</p><p>　　鏈路建立階段完成后，對(duì)端不停地發(fā)送Id/Password對(duì)給驗(yàn)證者，一直到驗(yàn)證被響應(yīng)或者連接終止為止。</p><p>　　

19、PAP不是一個(gè)健壯的身份驗(yàn)證方法。密碼在電路上是明文發(fā)送的，并且對(duì)回送或者重復(fù)驗(yàn)證和錯(cuò)誤攻擊沒有保護(hù)措施。對(duì)端控制著嘗試的頻率和時(shí)間。</p><p>　　包含健壯驗(yàn)證方法（例如CHAP，下面描述）的任何實(shí)現(xiàn)者必須提供商議優(yōu)先于PAP的方法。</p><p>　　這個(gè)驗(yàn)證方法最適合用在使用有效的明文密碼在遠(yuǎn)程主機(jī)上模擬登陸的地方了。通過這種用法，這個(gè)方法向普通用戶要登陸遠(yuǎn)程主機(jī)提供了一種安

20、全的類似級(jí)別。</p><p>　　實(shí)現(xiàn)注意：要限制暴露在PPP鏈路上傳輸明文密碼和避免在整個(gè)網(wǎng)絡(luò)上發(fā)送明文密碼是可能的。如果遠(yuǎn)程主機(jī)密碼是以單向轉(zhuǎn)換值保存的，并且轉(zhuǎn)換函數(shù)的算法是在當(dāng)?shù)刂鳈C(jī)上完成的，則明文密碼應(yīng)該在和遠(yuǎn)程主機(jī)的轉(zhuǎn)換密碼比較前在本地轉(zhuǎn)換。</p><p>　　2.1 配置選項(xiàng)格式</p><p>　　下面是關(guān)于PAP的驗(yàn)證－協(xié)議配置選項(xiàng)格式的總結(jié)。各

21、個(gè)域由左到右傳輸。</p><p>　　0 1 2 3</p><p>　　0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1</p><p>　　+-+-+-+-+-+-+-+-+-

22、+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</p><p>　　| Type | Length | Authentication-Protocol |</p><p>　　+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

23、+-+</p><p><b>　　類型</b></p><p><b>　　3</b></p><p><b>　　長(zhǎng)度</b></p><p><b>　　4</b></p><p><b>　　驗(yàn)證－協(xié)議</b

24、></p><p>　　c023（對(duì)于PAP）</p><p><b>　　數(shù)據(jù)</b></p><p><b>　　沒有數(shù)據(jù)域</b></p><p><b>　　2.2 包格式</b></p><p>　　一個(gè)PAP包是完全封裝在PPP數(shù)據(jù)鏈路

25、層幀（協(xié)議域是c023代表PAP）的信息域中的。下面是PAP包格式的總結(jié)。各個(gè)域由左到右傳輸。</p><p>　　0 1 2 3</p><p>　　0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1<

26、;/p><p>　　+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</p><p>　　| Code | Identifier | Length |</p><p>　　+-+-+-+-+-+-+-+-+-+-+-+-

27、+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</p><p>　　| Data ...</p><p><b>　　+-+-+-+-+</b></p><p><b>　　代碼</b></p><p>　　代碼域是一個(gè)字節(jié)，代表PAP包的類型。PAP代碼分

28、配如下：</p><p>　　1 Authenticate-Request</p><p>　　2 Authenticate-Ack</p><p>　　3Authenticate-Nak</p><p><b>　　標(biāo)識(shí)符</b></p><p>　　標(biāo)識(shí)符是一個(gè)字節(jié)，用于匹配請(qǐng)求和

29、響應(yīng)。</p><p><b>　　長(zhǎng)度</b></p><p>　　長(zhǎng)度域是兩個(gè)字節(jié)，代表PAP包的長(zhǎng)度，包括代碼域，標(biāo)識(shí)符和數(shù)據(jù)域。超出長(zhǎng)度域指定的字節(jié)被認(rèn)為是數(shù)據(jù)鏈路層的填料，在接收端應(yīng)該忽略掉。</p><p><b>　　數(shù)據(jù)</b></p><p>　　數(shù)據(jù)域是零個(gè)或多個(gè)字節(jié)。數(shù)據(jù)域的格

30、式由代碼域決定。</p><p>　　2.2.1 Authenticate-Request</p><p><b>　　描述</b></p><p>　　Authenticate-Request包用來啟動(dòng)PAP。在驗(yàn)證階段鏈路的一端必須傳輸代碼域?yàn)?（驗(yàn)證－請(qǐng)求）的PAP包。直到接收到一個(gè)有效的響應(yīng)包或者可選的重試計(jì)數(shù)器超時(shí)，驗(yàn)證－請(qǐng)求包必須不

31、停地發(fā)送。</p><p>　　驗(yàn)證者應(yīng)該期待對(duì)端發(fā)送一個(gè)Authenticate-Request包。一旦接收到Authenticate-Request包，必須返回某種驗(yàn)證響應(yīng)（下面描述）。</p><p>　　實(shí)現(xiàn)注意：因?yàn)锳uthenticate-Request包可能會(huì)丟失，所以在完成驗(yàn)證階段后驗(yàn)證者必須允許重復(fù)的Authenticate-Request包。在驗(yàn)證階段完成（部分信息可能

32、不同）后，在協(xié)議階段必須返回相同的響應(yīng)代碼。在另外的階段接到的任何Authenticate-Request包必須被靜靜地處理掉。</p><p>　　如果Authenticate-Nak包丟失，和驗(yàn)證者終止鏈路，則LCP Terminate-Request 包和Terminate-Ack包提供一個(gè)可選擇的方法表示驗(yàn)證失敗。</p><p>　　下面是Authenticate-Request

33、包格式的總結(jié)。各個(gè)域由左到右傳輸。</p><p>　　0 1 2 3</p><p>　　0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1</p><p>　　+-+-+-+-+-

34、+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</p><p>　　| Code | Identifier | Length |</p><p>　　+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

35、+-+-+-+-+-+</p><p>　　| Peer-ID Length| Peer-Id ...</p><p>　　+-+-+-+-+-+-+-+-+-+-+-+-+</p><p>　　| Passwd-Length | Password ...</p><p>　　+-+-+-+-+-+-+-+-+-+-+-+-+-+<

36、;/p><p><b>　　代碼</b></p><p>　　Authenticate-Request。</p><p><b>　　標(biāo)識(shí)符</b></p><p>　　標(biāo)識(shí)符是一個(gè)字節(jié)，用于匹配請(qǐng)求和回應(yīng)。每次發(fā)送一個(gè)Authenticate-Request包，標(biāo)識(shí)符域必須改變。</p>

37、<p>　　Peer-ID-Length</p><p>　　Peer-ID-Length域是一個(gè)字節(jié)，代表Peer-ID域的長(zhǎng)度。</p><p><b>　　Peer-ID</b></p><p>　　Peer-ID域是零個(gè)或多個(gè)字節(jié)，代表被驗(yàn)證端的名字。</p><p>　　Passwd-Length&

38、lt;/p><p>　　Passwd-Length域一個(gè)字節(jié)，代表Password域的長(zhǎng)度。</p><p><b>　　Password</b></p><p>　　Password域是零個(gè)或者多個(gè)字節(jié)，是用來驗(yàn)證的密碼。</p><p>　　2.2.2 Authenticate-Ack and Authenticate-

39、Nak</p><p><b>　　描述</b></p><p>　　如果在接收的Authenticate-Request包中的Peer-ID/Password對(duì)是可識(shí)別的和可接受的，則驗(yàn)證者必須發(fā)送一個(gè)代碼域是2（Authenticate-Ack）的PAP包。</p><p>　　如果在接收的Authenticate-Request包中的Pe

40、er-ID/Password對(duì)是不可識(shí)別的和不可接受的，則驗(yàn)證者必須發(fā)送一個(gè)代碼域是3（Authenticate-Nak）的PAP包，并且應(yīng)該終止鏈路。</p><p>　　下面是Authenticate-Ack包和Authenticate-Nak包格式的總結(jié)。各個(gè)域由左到右傳輸。</p><p>　　0 1 2

41、 3</p><p>　　0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1</p><p>　　+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</p><p>　　|

42、Code | Identifier | Length |</p><p>　　+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</p><p>　　| Msg-Length | Message ...</p><p&g

43、t;　　+-+-+-+-+-+-+-+-+-+-+-+-+-</p><p><b>　　代碼</b></p><p>　　Authenticate-Ack;</p><p>　　Authenticate-Nak</p><p><b>　　標(biāo)識(shí)符</b></p><p>　

44、　標(biāo)識(shí)符域是一個(gè)字節(jié)，用于匹配請(qǐng)求和回應(yīng)。此域必須從引起這次回應(yīng)的Authenticate-Request包標(biāo)識(shí)符域復(fù)制過來的。</p><p>　　Msg-Length</p><p>　　Msg-Length域是一個(gè)字節(jié)，代表Message域的長(zhǎng)度。</p><p><b>　　Message</b></p><p>

45、;　　Message域是零個(gè)或者多個(gè)字節(jié)，并且它的內(nèi)容依靠于實(shí)現(xiàn)者。它是可讀的，不得影響協(xié)議的操作。建議在Message中包含可顯示的ASCII字符（32－126）。擴(kuò)展字符集的機(jī)制是進(jìn)一步研究的主題。</p><p>　　3 Challenge-Handshake Authentication Protocol</p><p>　　CHAP 用于使用3次握手周期性的驗(yàn)證對(duì)端。在鏈路建立初

46、始化時(shí)這樣做，也可以在鏈路建立后任何時(shí)間重復(fù)驗(yàn)證。</p><p>　　在鏈路建立完成后，驗(yàn)證者向?qū)Χ税l(fā)送一個(gè)“challenge”信息。對(duì)端使用一個(gè)“one-way-hash”函數(shù)計(jì)算出的值響應(yīng)這個(gè)信息。驗(yàn)證者使用自己計(jì)算的hash值校驗(yàn)響應(yīng)值。如果兩個(gè)值匹配，則驗(yàn)證是承認(rèn)得，否則連接應(yīng)該終止。</p><p>　　CHAP通過使用遞增的標(biāo)識(shí)符和可變得挑戰(zhàn)值提供了防止回送攻擊的保護(hù)。使用

47、重復(fù)挑戰(zhàn)目的是任一個(gè)攻擊的暴露時(shí)間。驗(yàn)證者控制著挑戰(zhàn)的頻率和時(shí)間。這種驗(yàn)證方法依靠只有驗(yàn)證者和對(duì)端知道的秘密（secret）。這個(gè)秘密（secret）不在鏈路上傳播。這種方法最可能用的地方是相同的秘密容易訪問鏈路的兩端。</p><p>　　實(shí)現(xiàn)注意：CHAP要求秘密是明文形式的。為了避免在網(wǎng)絡(luò)的其他鏈路上發(fā)送秘密，建議在中心服務(wù)器上檢查challenge 和respone值，而不是在每一個(gè)網(wǎng)絡(luò)訪問服務(wù)器上檢查。

48、另外，秘密應(yīng)該以可逆轉(zhuǎn)的加密形式發(fā)送到服務(wù)器上。</p><p>　　CHAP算法要求秘密的長(zhǎng)度必須至少一個(gè)字節(jié)。秘密至少應(yīng)該和選擇好的密碼一樣大小和不可猜。比較好的是秘密應(yīng)該至少是選擇的哈希算法的哈希值的長(zhǎng)度（對(duì)于MD5是16個(gè)字節(jié)）。這樣保證了足夠大的范圍使得秘密提供了防止窮盡搜索攻擊的保護(hù)措施。</p><p>　　選擇one-way哈希算法使得要想從已知的challenge 和re

49、sponse值得出秘密的計(jì)算是不可行的。</p><p>　　Challenge值應(yīng)該符合兩個(gè)標(biāo)準(zhǔn)：唯一性和不可預(yù)測(cè)性。每一個(gè)challenge值應(yīng)該是唯一的，因?yàn)槭褂门c相同秘密聯(lián)系的challenge執(zhí)的副本可以讓攻擊者利用前一個(gè)截獲得響應(yīng)包響應(yīng)。由于希望可以使用相同的秘密在不同區(qū)域中驗(yàn)證服務(wù)器，challenge 應(yīng)該具有全局和暫時(shí)的唯一性。每一個(gè)challenge值也應(yīng)該是不可預(yù)測(cè)的，否則攻擊者欺騙對(duì)端響應(yīng)

50、一個(gè)可預(yù)測(cè)的未來challenge，然后用這個(gè)響應(yīng)偽裝成對(duì)端欺騙驗(yàn)證者。盡管象CHAP這樣的協(xié)議不能夠防止實(shí)時(shí)的竊聽攻擊，但是使用唯一的和不可預(yù)測(cè)的challenge可以防止一定范圍的能動(dòng)攻擊。</p><p>　　關(guān)于唯一性來源和產(chǎn)生分歧概率的討論包含在Magic-Number配置選項(xiàng)中。</p><p><b>　　3.1配置選項(xiàng)格式</b></p>

51、<p>　　下面是Challenge-Handshake 驗(yàn)證協(xié)議使用的Authentication-Protocol 配置選項(xiàng)格式的總結(jié)。各個(gè)域由左到右傳輸。</p><p>　　0 1 2 3</p><p>　　0 1 2 3 4 5 6 7 8 9 0 1 2 3

52、 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1</p><p>　　+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</p><p>　　| Type | Length | Authentication-Protocol |</p&g

53、t;<p>　　+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</p><p>　　| Algorithm |</p><p>　　+-+-+-+-+-+-+-+-+</p><p><b>　　類型</b></p><

54、p><b>　　3</b></p><p><b>　　長(zhǎng)度</b></p><p><b>　　5</b></p><p>　　Authentication-Protocol</p><p>　　c223 Challenge-Protocol Authenticatio

55、n Protocol</p><p><b>　　算法</b></p><p>　　算法域是一個(gè)字節(jié)，代表所使用的one-way 哈希算法。CHAP算法域的最新值在最近的“Assigned Numbers”RFC[2]中有詳細(xì)說明。當(dāng)前的值分配如下：</p><p>　　unused(保留)</p><p><b&

56、gt;　　MD5[3]</b></p><p><b>　　3.2包格式</b></p><p>　　CHAP包封裝在PPP數(shù)據(jù)聯(lián)絡(luò)層幀的信息域中，它的協(xié)議域是c223。下面是CHAP包格式的總結(jié)。各個(gè)域由左到右傳輸。</p><p>　　0 1 2

57、 3</p><p>　　0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1</p><p>　　+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</p><p>　　| Cod

58、e | Identifier | Length |</p><p>　　+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</p><p>　　| Data ...</p><p><b>　　+-+-+-+-

59、+</b></p><p><b>　　代碼</b></p><p>　　代碼域是一個(gè)字節(jié)，代表CHAP包的類型。CHAP代碼分配如下：</p><p>　　1Challenge</p><p><b>　　2esponse</b></p><p><b

60、>　　3Success</b></p><p><b>　　Failure</b></p><p><b>　　標(biāo)識(shí)符</b></p><p>　　標(biāo)識(shí)符是一個(gè)字節(jié)，用于匹配challenge,response和replies。</p><p><b>　　長(zhǎng)度<

61、/b></p><p>　　長(zhǎng)度域是兩個(gè)字節(jié)，代表CHAP包的長(zhǎng)度，包括Code,Identifier,Length和Data。超出這個(gè)長(zhǎng)度的字節(jié)應(yīng)該被認(rèn)為是鏈路層的填料，在接收端應(yīng)該被忽略。</p><p><b>　　數(shù)據(jù)</b></p><p>　　數(shù)據(jù)域是零個(gè)或者多個(gè)字節(jié)。它的格式由code域決定。</p><

62、p>　　3.2.1 Challenge 和 Response</p><p><b>　　描述</b></p><p>　　Challenge包用來啟動(dòng)CHAP。驗(yàn)證者必須發(fā)送一個(gè)代碼域是1的CHAP包。一直到接收到有效的響應(yīng)包或者重試計(jì)數(shù)器超時(shí)，必須不停發(fā)送Challenge包。</p><p>　　在網(wǎng)絡(luò)層協(xié)議階段的任一個(gè)時(shí)間也可以發(fā)

63、送Challenge包確保連接沒有改變。</p><p>　　在驗(yàn)證階段和網(wǎng)絡(luò)層協(xié)議階段對(duì)端應(yīng)該期待Challenge包。無論何時(shí)接到Challenge包，對(duì)端必須發(fā)送一個(gè)代碼域是2的CHAP包。</p><p>　　無論何時(shí)驗(yàn)證者接到一個(gè)Response包，則它比較Response值和自己計(jì)算的期待值是否相同。在比較的基礎(chǔ)上，驗(yàn)證者必須發(fā)送一個(gè)Success 或者Failure包。<

64、;/p><p>　　實(shí)現(xiàn)注意：因?yàn)镾uccess包有可能丟失，驗(yàn)證者必須在完成驗(yàn)證階段后允許重復(fù)的Response包。為了防止名字和秘密的泄漏，在驗(yàn)證階段后，任何具有當(dāng)前Challenge標(biāo)識(shí)符的Response包必須返回相同的響應(yīng)代碼。在其他階段接到的任何Response包必須被靜靜地丟掉。</p><p>　　如果Failure包丟失和驗(yàn)證者終止鏈路，則LCP的Terminate-Requ

65、est包和Terminate-Ack包提供了另一種代表驗(yàn)證失敗的方法。</p><p>　　下面是Challenge 和Response包格式的總結(jié)。各個(gè)域由左到右傳輸。</p><p>　　0 1 2 3</p><p>　　0 1 2 3 4 5 6 7

66、8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1</p><p>　　+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</p><p>　　| Code | Identifier | Length

67、 |</p><p>　　+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</p><p>　　| Value-Size | Value ...</p><p>　　+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

68、-+-+-+-+-+</p><p>　　| Name ...</p><p>　　+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</p><p><b>　　代碼</b></p><p>　　1Challenge</p><p>　　2Response</p>

69、;<p><b>　　標(biāo)識(shí)符</b></p><p>　　標(biāo)識(shí)符是一個(gè)字節(jié)，每發(fā)送一個(gè)Challenge包標(biāo)識(shí)符必須改變。Response包的標(biāo)識(shí)符必須從引起這個(gè)響應(yīng)的Challenge包的標(biāo)識(shí)符復(fù)制過來的。</p><p>　　Value-Size</p><p>　　此域是一個(gè)字節(jié)，代表Value域的長(zhǎng)度。</p>

70、<p><b>　　Value</b></p><p>　　Value域是一個(gè)或多個(gè)字節(jié)。最重要的字節(jié)先傳輸。</p><p>　　Challenge Value是一個(gè)可變的字節(jié)流。上面講述了Challenge Value唯一性的重要性以及它和秘密的關(guān)系。每次發(fā)送Challenge 包必須改變Challenge Value。Challenge Value

71、的長(zhǎng)度依靠于產(chǎn)生字節(jié)所使用的方法，獨(dú)立于所用的哈希算法。</p><p>　　Response Value是在字節(jié)流上用單向哈希算法計(jì)算得出的，字節(jié)流包含Identifier,后面是secret,再后面是Challenge Value。Response Value的長(zhǎng)度依靠于所用的哈希算法（對(duì)于MD5是16個(gè)字節(jié)）。</p><p><b>　　名字</b></

72、p><p>　　名字域是一個(gè)或多個(gè)字節(jié)，代表發(fā)送包的系統(tǒng)的標(biāo)識(shí)。對(duì)這個(gè)域的內(nèi)容沒有限制。例如，它可以是ASCII字符串或者是ASN.1語(yǔ)法中的全局唯一標(biāo)識(shí)。名字不應(yīng)該是以NULL 或者CR/LF結(jié)尾的。大小由長(zhǎng)度域決定。</p><p>　　因?yàn)镃HAP可以驗(yàn)證許多不同的系統(tǒng)，所以名字域的內(nèi)容可以用作在秘密數(shù)據(jù)庫(kù)查詢秘密的關(guān)鍵字。這也可以在每個(gè)系統(tǒng)上支持更多的Name/Secret對(duì)。<

73、/p><p>　　3.2.2 Success 和 Failure</p><p><b>　　描述</b></p><p>　　如果在Response包中的Value等于期待的值，則驗(yàn)證者必須發(fā)送一個(gè)代碼域是3（Success）的CHAP包。</p><p>　　如果在Response包中的Value不等于期待的值，則驗(yàn)證者

74、必須發(fā)送一個(gè)代碼域是4（Failure）的CHAP包，并且應(yīng)該終止鏈路。</p><p>　　下面是Success和Failure包格式的總結(jié)。各個(gè)域由左到右傳輸。</p><p>　　0 1 2 3</p><p>　　0 1 2 3 4 5 6 7 8 9

75、 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1</p><p>　　+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</p><p>　　| Code | Identifier | Length |

76、</p><p>　　+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</p><p>　　| Message ...</p><p>　　+-+-+-+-+-+-+-+-+-+-+-+-+-</p><p><b>　　代碼</b>&

77、lt;/p><p><b>　　3Success</b></p><p><b>　　4Failure</b></p><p><b>　　標(biāo)識(shí)符</b></p><p>　　標(biāo)識(shí)符是一個(gè)字節(jié)，用于匹配request和replies。標(biāo)識(shí)符必須從引起這個(gè)響應(yīng)的Response包

78、的標(biāo)識(shí)符復(fù)制過來的。</p><p><b>　　Message</b></p><p>　　Message域是零個(gè)或者多個(gè)字節(jié)，它的內(nèi)容依靠實(shí)現(xiàn)者。它被設(shè)計(jì)成可讀的，不得影響協(xié)議操作。建議在Message中包含可顯示的ASCII字符（32－126）。擴(kuò)展字符集的機(jī)制是進(jìn)一步研究的主題。大小由長(zhǎng)度域決定。</p><p><b>　　

79、安全考慮</b></p><p>　　安全問題是此備忘錄的主要話題。</p><p>　　PPP中的驗(yàn)證協(xié)議的交互操作很大程度上依靠于實(shí)現(xiàn)者。在文檔中通篇使用SHOULD表明了這點(diǎn)。</p><p>　　例如，一旦驗(yàn)證失敗，有些實(shí)現(xiàn)者并不終止鏈路。相反，實(shí)現(xiàn)者限制網(wǎng)絡(luò)層的通信量的類型構(gòu)造子網(wǎng)，這樣反過來允許用戶有機(jī)會(huì)更新秘密或者發(fā)郵件給網(wǎng)絡(luò)管理員說明問題

80、。</p><p>　　對(duì)于驗(yàn)證失敗沒有重試機(jī)制。然而，LCP狀態(tài)機(jī)可以在任何時(shí)候重新磋商驗(yàn)證協(xié)議，這樣就允許了一個(gè)新的重試。建議任何用來為驗(yàn)證失敗的計(jì)數(shù)器在成功驗(yàn)證前或者終止失敗的鏈路前不要重置。</p><p>　　不要求驗(yàn)證是雙向的或者在兩個(gè)方向使用相同的協(xié)議。在任一個(gè)方向上使用不同的協(xié)議是完全可以接受的。當(dāng)然，這依靠于在磋商時(shí)指定的協(xié)議。</p><p>　

81、　在實(shí)踐中，在每個(gè)PPP服務(wù)器上有一個(gè)數(shù)據(jù)庫(kù)，它聯(lián)合驗(yàn)證信息的用戶名字。不期望使用多個(gè)方法驗(yàn)證特殊的命名用戶。這樣使用戶容易受到攻擊。作為代替的，對(duì)于每一個(gè)命名用戶有一個(gè)準(zhǔn)確的方法用來驗(yàn)證用戶名。如果一個(gè)用戶在不同的環(huán)境下需要使用不同的驗(yàn)證方法，那么應(yīng)該采用截然不同的用戶名，每一個(gè)準(zhǔn)確代表一個(gè)驗(yàn)證方法。</p><p>　　密碼和其他的秘密應(yīng)該保存在各自的端點(diǎn)以至于對(duì)它們的訪問盡可能的受到限制。理想的，只能是為了

82、完成驗(yàn)證而需要訪問的過程可以訪問秘密。</p><p>　　應(yīng)該使用一種機(jī)制分發(fā)秘密，這種機(jī)制能夠限制處理秘密實(shí)體的數(shù)目。理想的，沒有通過驗(yàn)證的人不會(huì)再得到秘密的內(nèi)容。使用SNMP安全協(xié)議[4]可以實(shí)現(xiàn)這個(gè)目標(biāo)，但是這樣的機(jī)制不在這個(gè)規(guī)范的范圍內(nèi)。</p><p>　　目前正在研究和試驗(yàn)其他的分發(fā)機(jī)制。SNMP安全文檔很好的概括了對(duì)網(wǎng)絡(luò)的威脅。</p><p>&l

83、t;b>　　參考文獻(xiàn)</b></p><p>　　[1] Simpson, W., "The Point-to-Point Protocol (PPP)", RFC 1331,</p><p>　　Daydreamer, May 1992.</p><p>　　[2] Reynolds, J., and J. Postel, &

84、quot;Assigned Numbers", RFC 1340,</p><p>　　USC/Information Sciences Institute, July 1992.</p><p>　　[3] Rivest, R., and S. Dusse, "The MD5 Message-Digest Algorithm", MIT</p>

85、<p>　　Laboratory for Computer Science and RSA Data Security, Inc. RFC</p><p>　　1321, April 1992.</p><p>　　[4] Galvin, J., McCloghrie, K., and J. Davin, "SNMP Security</p><

86、p>　　Protocols", Trusted Information Systems, Inc., Hughes LAN</p><p>　　Systems, Inc., MIT Laboratory for Computer Science, RFC 1352,</p><p>　　July 1992.</p><p><b>　　致謝

87、</b></p><p>　　此文檔的一些內(nèi)容來自RFC1172，它是由 Drew Perkins of Carnegie Mellon University和Russ Hobby of the University of California at Davis共同制定的。</p><p>　　特別感謝Dave Balenson, Steve Crocker and, Jame

88、s Galvin,和Steve Kent，感謝他們的廣泛的解釋和建議。</p><p><b>　　主席地址</b></p><p>　　可以通過現(xiàn)任主席聯(lián)系工作組。</p><p>　　Brian Lloyd</p><p>　　Lloyd & Associates</p><p>　　

89、3420 Sudbury Road</p><p>　　Cameron Park, California 95682</p><p>　　Phone: (916) 676-1147</p><p>　　EMail: brian@lloyd.com</p><p><b>　　作者地址</b></p><

90、;p>　　關(guān)于此備忘錄的問題可以直接聯(lián)系：</p><p>　　William Allen Simpson</p><p>　　Daydreamer</p><p>　　Computer Systems Consulting Services</p><p>　　P O Box 6205</p><p>　　Ea

91、st Lansing, MI 48826-6205</p><p>　　EMail: Bill.Simpson@um.cc.umich.edu</p><p><b>　　完整版權(quán)說明</b></p><p>　　Copyright (C) The Internet Society (2001). All Rights Reserved.&

92、lt;/p><p>　　只要在所有復(fù)本與推導(dǎo)性工作中包含上面的版權(quán)聲明和這段文字，就可以全部地或者部分地且沒有任何限制地復(fù)制這篇文檔與其譯本以及把它提供給其它文檔，同樣也可以準(zhǔn)備、復(fù)制、出版與發(fā)行推導(dǎo)性工作，而且需要評(píng)述此推導(dǎo)性工作否則就得解釋它，或者輔助此推導(dǎo)性工作的實(shí)現(xiàn)。然而，此文檔本身不可以做任何修改，諸如刪除版權(quán)聲明或者因特網(wǎng)社區(qū)或其它因特網(wǎng)組織的涉及，除了當(dāng)需要開發(fā)因特網(wǎng)標(biāo)準(zhǔn)的目的時(shí)之外且在此種情況下必須遵

93、循在因特網(wǎng)標(biāo)準(zhǔn)過程中定義的版權(quán)程序，或者除了當(dāng)要求把它譯成其它語(yǔ)言（即不是英文）的目的時(shí)之外。</p><p>　　在上面準(zhǔn)予的有限的許可是永久性的，而且因特網(wǎng)社區(qū)或者它的繼承者或指派者都將不會(huì)廢除它。</p><p>　　在此包含的這篇文檔與信息是基于“AS IS”而提供的，并且因特網(wǎng)社區(qū)與因特網(wǎng)工程任務(wù)組織聲明了所有的授權(quán)、表達(dá)或含義，且包含對(duì)任何授權(quán)的限制，比如這里信息的使用不會(huì)違反