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

1、<p>　　組織：中國互動出版網(wǎng)（http://www.china-pub.com/）</p><p>　　RFC文檔中文翻譯計劃（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ā)布時間：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 身份驗證協(xié)議</p><p>　?。≧FC1334——PPP Authentication Protocols ）</p><p><b>　　備忘錄狀態(tài)</b></p><p>　　此RFC 為internet community詳細說明了 IAB 標(biāo)準(zhǔn)跟蹤協(xié)議，并且請求討論和建議以便改進。請參考IAB Official P

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

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

7、gineering Task Force)的PPP協(xié)議工作組的成果。關(guān)于這個備忘錄的建議請?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ù)語2</b></p><p>　　2. 密碼驗證協(xié)議3</p><p>　　2.1 配置選項格式3</p><p><b>　　2.2 包格式4</b></p><p>　　3.1配置選項格式6</p><p><b>　　3.2包格

9、式7</b></p><p><b>　　安全考慮10</b></p><p><b>　　參考文獻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 有三個主要的組成部分：&

11、lt;/p><p>　　在串行鏈路上封裝數(shù)據(jù)報（datagrams）的方法。</p><p>　　建立，配置和測試數(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>　　為了在點到點鏈路（point-to-point link）上建立通信，PPP鏈路的一端必須在建立階段（Establishment phase）首先發(fā)送LCP包（packets）配置數(shù)據(jù)鏈路。在鏈路建立后，在進入到網(wǎng)絡(luò)層協(xié)議階段前，PPP提供一個可選擇的驗證階段。</p><p>　　默認的，身份驗證不是強制的。如果希望進行鏈路的身份驗證，則實現(xiàn)者必須在建立階段指明身份驗證－協(xié)議配置選項

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

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

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

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

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

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

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

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

21、個域由左到右傳輸。</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>　　長度</b></p><p><b>　　4</b></p><p><b>　　驗證－協(xié)議</b

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

25、層幀（協(xié)議域是c023代表PAP）的信息域中的。下面是PAP包格式的總結(jié)。各個域由左到右傳輸。</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>　　代碼域是一個字節(jié)，代表PAP包的類型。PAP代碼分

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

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

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

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

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

33、包格式的總結(jié)。各個域由左到右傳輸。</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)識符</b></p><p>　　標(biāo)識符是一個字節(jié)，用于匹配請求和回應(yīng)。每次發(fā)送一個Authenticate-Request包，標(biāo)識符域必須改變。</p>

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

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

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

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

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

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

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

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

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

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

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

51、<p>　　下面是Challenge-Handshake 驗證協(xié)議使用的Authentication-Protocol 配置選項格式的總結(jié)。各個域由左到右傳輸。</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>　　長度</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>　　算法域是一個字節(jié)，代表所使用的one-way 哈希算法。CHAP算法域的最新值在最近的“Assigned Numbers”RFC[2]中有詳細說明。當(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é)。各個域由左到右傳輸。</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>　　代碼域是一個字節(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)識符</b></p><p>　　標(biāo)識符是一個字節(jié)，用于匹配challenge,response和replies。</p><p><b>　　長度<

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

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

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

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

65、est包和Terminate-Ack包提供了另一種代表驗證失敗的方法。</p><p>　　下面是Challenge 和Response包格式的總結(jié)。各個域由左到右傳輸。</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)識符</b></p><p>　　標(biāo)識符是一個字節(jié)，每發(fā)送一個Challenge包標(biāo)識符必須改變。Response包的標(biāo)識符必須從引起這個響應(yīng)的Challenge包的標(biāo)識符復(fù)制過來的。</p><p>　　Value-Size</p><p>　　此域是一個字節(jié)，代表Value域的長度。</p>

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

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

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

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

74、必須發(fā)送一個代碼域是4（Failure）的CHAP包，并且應(yīng)該終止鏈路。</p><p>　　下面是Success和Failure包格式的總結(jié)。各個域由左到右傳輸。</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)識符</b></p><p>　　標(biāo)識符是一個字節(jié)，用于匹配request和replies。標(biāo)識符必須從引起這個響應(yīng)的Response包

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

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

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

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

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

83、t;b>　　參考文獻</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)性工作，而且需要評述此推導(dǎo)性工作否則就得解釋它，或者輔助此推導(dǎo)性工作的實現(xiàn)。然而，此文檔本身不可以做任何修改，諸如刪除版權(quán)聲明或者因特網(wǎng)社區(qū)或其它因特網(wǎng)組織的涉及，除了當(dāng)需要開發(fā)因特網(wǎng)標(biāo)準(zhǔn)的目的時之外且在此種情況下必須遵

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