1.介紹
PPP有三個主要的組成部分：
1． 在串行鏈路上封裝數(shù)據(jù)報（datagrams）的方法。
2． 建立，配置和測試數(shù)據(jù)鏈路鏈接（thedata-linkconnection）的LCP協(xié)議（Link ControlProtocol）。
3． 建立和配置不同網(wǎng)絡層協(xié)議的一組NCP協(xié)議（NetworkControlProtocol）。為了在點到點鏈路（point-to-pointlink）上建立通信，PPP鏈路的一端必須在建立階段（Establishmentphase）首先發(fā)送LCP包（packets）配置數(shù)據(jù)鏈路。在鏈路建立后，在進入到網(wǎng)絡層協(xié)議階段前，PPP提供一個可選擇的驗證階段。默認的，身份驗證不是強制的。如果希望進行鏈路的身份驗證，則實現(xiàn)者必須在建立階段指明身份驗證－協(xié)議配置選項。
這些協(xié)議主要是為通過交換網(wǎng)（switchedcircuits）或者撥號線(dial-uplines)連接到PPP網(wǎng)絡服務器的主機和路由器服務的，但是也可以被用到專用鏈路（dedicatedlinks）中。服務器在為網(wǎng)絡層磋商選擇選項時可以對連接的主機或路由器進行身份驗證。
此文檔定義了PPP身份驗證協(xié)議。鏈路建立和驗證階段，和驗證協(xié)議配置選項定義在PPP協(xié)議中[1]。
1.1要求說明書
在本文檔中，用以下幾個詞來表示說明書的要求，這些詞一般以大寫字體書寫。
MUST
這個詞表示在此說明書中是絕對要求的。
MUSTNOT
這個詞組表示在此說明書中是絕對禁止的。
SHOULD
此詞表示在此說明書中是推薦的。
MAY
此詞表示在此說明書中是可選的。
1.2術語
本文檔中，頻繁使用以下術語：
authenticator――驗證者：
要求驗證的鏈路端點。驗證者說明了在鏈路建立階段使用的驗證協(xié)議。
Peer――點到點鏈路的另一端：
正在被驗證者驗證的一端。
Silentlydiscard――靜靜地丟棄
丟棄packet而不進行進一步的處理。執(zhí)行（這個動作）應該提供記錄錯誤，包括丟棄packet的內(nèi)容，的容量，并且應該在一個統(tǒng)計計數(shù)器中記錄這一事件。

2.密碼驗證協(xié)議
密碼驗證協(xié)議（PAP）提供了一種簡單的方法，可以使對端（peer）使用2次握手建立身份驗證。這個方法僅僅在鏈路初始化時使用。鏈路建立階段完成后，對端不停地發(fā)送Id/Password對給驗證者，一直到驗證被響應或者連接終止為止。PAP不是一個健壯的身份驗證方法。密碼在電路上是明文發(fā)送的，并且對回送或者重復驗證和錯誤攻擊沒有保護措施。對端控制著嘗試的頻率和時間。包含健壯驗證方法（例如CHAP，下面描述）的任何實現(xiàn)者必須提供商議優(yōu)先于PAP的方法。這個驗證方法最適合用在使用有效的明文密碼在遠程主機上模擬登陸的地方了。實現(xiàn)注意：要限制暴露在PPP鏈路上傳輸明文密碼和避免在整個網(wǎng)絡上發(fā)送明文密碼是可能的。如果遠程主機密碼是以單向轉(zhuǎn)換值保存的，并且轉(zhuǎn)換函數(shù)的算法是在當?shù)刂鳈C上完成的，則明文密碼應該在和遠程主機的轉(zhuǎn)換密碼比較前在本地轉(zhuǎn)換。

2.1配置選項格式
下面是關于PAP的驗證－協(xié)議配置選項格式的總結(jié)。各個域由左到右傳輸。

0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type|Length|Authentication-Protocol|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

類型
3
長度
4
驗證－協(xié)議
c023（對于PAP）
數(shù)據(jù)
沒有數(shù)據(jù)域
2.2包格式
一個PAP包是完全封裝在PPP數(shù)據(jù)鏈路層幀（協(xié)議域是c023代表PAP）的信息域中的。
下面是PAP包格式的總結(jié)。各個域由左到右傳輸。

0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Code|Identifier|Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Data...
+-+-+-+-+

代碼
代碼域是一個字節(jié)，代表PAP包的類型。PAP代碼分配如下：
1 Authenticate-Request
2 Authenticate-Ack
3 Authenticate-Nak

標識符
標識符是一個字節(jié)，用于匹配請求和響應。
長度
長度域是兩個字節(jié)，代表PAP包的長度，包括代碼域，標識符和數(shù)據(jù)域。超出長度域指定的字節(jié)被認為是數(shù)據(jù)鏈路層的填料，在接收端應該忽略掉。
數(shù)據(jù)
數(shù)據(jù)域是零個或多個字節(jié)。數(shù)據(jù)域的格式由代碼域決定。
2.2.1Authenticate-Request
描述
Authenticate-Request包用來啟動PAP。在驗證階段鏈路的一端必須傳輸代碼域為1（驗證－請求）的PAP包。直到接收到一個有效的響應包或者可選的重試計數(shù)器超時，驗證－請求包必須不停地發(fā)送。
驗證者應該期待對端發(fā)送一個Authenticate-Request包。一旦接收到Authenticate-Request包，必須返回某種驗證響應（下面描述）。
實現(xiàn)注意：因為Authenticate-Request包可能會丟失，所以在完成驗證階段后驗證者必須允許重復的Authenticate-Request包。在驗證階段完成（部分信息可能不同）后，在協(xié)議階段必須返回相同的響應代碼。在另外的階段接到的任何Authenticate-Request包必須被靜靜地處理掉。如果Authenticate-Nak包丟失，和驗證者終止鏈路，則LCPTerminate-Request包和Terminate-Ack包提供一個可選擇的方法表示驗證失敗。
下面是Authenticate-Request包格式的總結(jié)。各個域由左到右傳輸。

0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Code|Identifier|Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Peer-IDLength|Peer-Id...
+-+-+-+-+-+-+-+-+-+-+-+-+
|Passwd-Length|Password...
+-+-+-+-+-+-+-+-+-+-+-+-+-+

代碼
1 Authenticate-Request。
標識符
標識符是一個字節(jié)，用于匹配請求和回應。每次發(fā)送一個Authenticate-Request包，標識符域必須改變。
Peer-ID-Length
Peer-ID-Length域是一個字節(jié)，代表Peer-ID域的長度。
Peer-ID
Peer-ID域是零個或多個字節(jié)，代表被驗證端的名字。
Passwd-Length
Passwd-Length域一個字節(jié)，代表Password域的長度。
Password
Password域是零個或者多個字節(jié)，是用來驗證的密碼。
2.2.2Authenticate-AckandAuthenticate-Nak
描述
如果在接收的Authenticate-Request包中的Peer-ID/Password對是可識別的和可接受的，則驗證者必須發(fā)送一個代碼域是2（Authenticate-Ack）的PAP包。如果在接收的Authenticate-Request包中的Peer-ID/Password對是不可識別的和不可接受的，則驗證者必須發(fā)送一個代碼域是3（Authenticate-Nak）的PAP包，并且應該終止鏈路。下面是Authenticate-Ack包和Authenticate-Nak包格式的總結(jié)。各個域由左到右傳輸。

0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Code|Identifier|Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Msg-Length|Message...
+-+-+-+-+-+-+-+-+-+-+-+-+-

代碼
2 Authenticate-Ack;
3 Authenticate-Nak
標識符
標識符域是一個字節(jié)，用于匹配請求和回應。此域必須從引起這次回應的Authenticate-Request包標識符域復制過來的。
Msg-Length
Msg-Length域是一個字節(jié)，代表Message域的長度。
Message
Message域是零個或者多個字節(jié)，并且它的內(nèi)容依靠于實現(xiàn)者。它是可讀的，不得影響協(xié)議的操作。建議在Message中包含可顯示的ASCII字符（32－126）。擴展字符集的機制是進一步研究的主題。

3Challenge-HandshakeAuthenticationProtocol
CHAP用于使用3次握手周期性的驗證對端。在鏈路建立初始化時這樣做，也可以在鏈路建立后任何時間重復驗證。在鏈路建立完成后，驗證者向?qū)Χ税l(fā)送一個“challenge”信息。對端使用一個“one-way-hash”函數(shù)計算出的值響應這個信息。驗證者使用自己計算的hash值校驗響應值。如果兩個值匹配，則驗證是承認得，否則連接應該終止。CHAP通過使用遞增的標識符和可變得挑戰(zhàn)值提供了防止回送攻擊的保護。使用重復挑戰(zhàn)目的是任一個攻擊的暴露時間。驗證者控制著挑戰(zhàn)的頻率和時間。這種驗證方法依靠只有驗證者和對端知道的秘密（secret）。這個秘密（secret）不在鏈路上傳播。這種方法最可能用的地方是相同的秘密容易訪問鏈路的兩端。
實現(xiàn)注意：CHAP要求秘密是明文形式的。為了避免在網(wǎng)絡的其他鏈路上發(fā)送秘密，建議在中心服務器上檢查challenge和respone值，而不是在每一個網(wǎng)絡訪問服務器上檢查。另外，秘密應該以可逆轉(zhuǎn)的加密形式發(fā)送到服務器上。CHAP算法要求秘密的長度必須至少一個字節(jié)。秘密至少應該和選擇好的密碼一樣大小和不可猜。比較好的是秘密應該至少是選擇的哈希算法的哈希值的長度（對于MD5是16個字節(jié)）。這樣保證了足夠大的范圍使得秘密提供了防止窮盡搜索攻擊的保護措施。選擇one-way哈希算法使得要想從已知的challenge和response值得出秘密的計算是不可行的。
Challenge值應該符合兩個標準：唯一性和不可預測性。每一個challenge值應該是唯一的，因為使用與相同秘密聯(lián)系的challenge執(zhí)的副本可以讓攻擊者利用前一個截獲得響應包響應。由于希望可以使用相同的秘密在不同區(qū)域中驗證服務器，challenge應該具有全局和暫時的唯一性。每一個challenge值也應該是不可預測的，否則攻擊者欺騙對端響應一個可預測的未來challenge，然后用這個響應偽裝成對端欺騙驗證者。盡管象CHAP這樣的協(xié)議不能夠防止實時的竊聽攻擊，但是使用唯一的和不可預測的challenge可以防止一定范圍的能動攻擊。關于唯一性來源和產(chǎn)生分歧概率的討論包含在Magic-Number配置選項中。
3.1配置選項格式
下面是Challenge-Handshake驗證協(xié)議使用的Authentication-Protocol配置選項格式的總結(jié)。各個域由左到右傳輸。

0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type|Length|Authentication-Protocol|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Algorithm|
+-+-+-+-+-+-+-+-+

類型
3
長度
5
Authentication-Protocol
c223Challenge-ProtocolAuthenticationProtocol
算法
算法域是一個字節(jié)，代表所使用的one-way哈希算法。CHAP算法域的最新值在最近的“AssignedNumbers”RFC[2]中有詳細說明。當前的值分配如下：
0-4 unused(保留)
5 MD5[3]
3.2包格式
CHAP包封裝在PPP數(shù)據(jù)聯(lián)絡層幀的信息域中，它的協(xié)議域是c223。下面是CHAP包格式的總結(jié)。各個域由左到右傳輸。

0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Code|Identifier|Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Data...
+-+-+-+-+

代碼
代碼域是一個字節(jié)，代表CHAP包的類型。CHAP代碼分配如下：
1 Challenge
2 esponse
3 Success
4 Failure

標識符
標識符是一個字節(jié)，用于匹配challenge,response和replies。
長度
長度域是兩個字節(jié)，代表CHAP包的長度，包括Code,Identifier,Length和Data。超出這個長度的字節(jié)應該被認為是鏈路層的填料，在接收端應該被忽略。
數(shù)據(jù)
數(shù)據(jù)域是零個或者多個字節(jié)。它的格式由code域決定。
3.2.1Challenge和Response
描述
Challenge包用來啟動CHAP。驗證者必須發(fā)送一個代碼域是1的CHAP包。一直到接收到有效的響應包或者重試計數(shù)器超時，必須不停發(fā)送Challenge包。在網(wǎng)絡層協(xié)議階段的任一個時間也可以發(fā)送Challenge包確保連接沒有改變。驗證階段和網(wǎng)絡層協(xié)議階段對端應該期待Challenge包。無論何時接到Challenge包，對端必須發(fā)送一個代碼域是2的CHAP包。無論何時驗證者接到一個Response包，則它比較Response值和自己計算的期待值是否相同。在比較的基礎上，驗證者必須發(fā)送一個Success或者Failure包。實現(xiàn)注意：因為Success包有可能丟失，驗證者必須在完成驗證階段后允許重復的Response包。為了防止名字和秘密的泄漏，在驗證階段后，任何具有當前Challenge標識符的Response包必須返回相同的響應代碼。在其他階段接到的任何Response包必須被靜靜地丟掉。如果Failure包丟失和驗證者終止鏈路，則LCP的Terminate-Request包和Terminate-Ack包提供了另一種代表驗證失敗的方法。下面是Challenge和Response包格式的總結(jié)。各個域由左到右傳輸。

0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Code|Identifier|Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Value-Size|Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Name...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

代碼
1 Challenge
2 Response

標識符
標識符是一個字節(jié)，每發(fā)送一個Challenge包標識符必須改變。Response包的標識符必須從引起這個響應的Challenge包的標識符復制過來的。
Value-Size
此域是一個字節(jié)，代表Value域的長度。
Value
Value域是一個或多個字節(jié)。最重要的字節(jié)先傳輸。
ChallengeValue是一個可變的字節(jié)流。上面講述了ChallengeValue唯一性的重要性以及它和秘密的關系。每次發(fā)送Challenge包必須改變ChallengeValue。ChallengeValue的長度依靠于產(chǎn)生字節(jié)所使用的方法，獨立于所用的哈希算法。ResponseValue是在字節(jié)流上用單向哈希算法計算得出的，字節(jié)流包含Identifier,后面是secret,再后面是ChallengeValue。ResponseValue的長度依靠于所用的哈希算法（對于MD5是16個字節(jié)）。
名字
名字域是一個或多個字節(jié)，代表發(fā)送包的系統(tǒng)的標識。對這個域的內(nèi)容沒有限制。例如，它可以是ASCII字符串或者是ASN.1語法中的全局唯一標識。名字不應該是以NULL或者CR/LF結(jié)尾的。大小由長度域決定。因為CHAP可以驗證許多不同的系統(tǒng)，所以名字域的內(nèi)容可以用作在秘密數(shù)據(jù)庫查詢秘密的關鍵字。這也可以在每個系統(tǒng)上支持更多的Name/Secret對。
3.2.2Success和Failure
描述
如果在Response包中的Value等于期待的值，則驗證者必須發(fā)送一個代碼域是3（Success）的CHAP包。
如果在Response包中的Value不等于期待的值，則驗證者必須發(fā)送一個代碼域是4（Failure）的CHAP包，并且應該終止鏈路。下面是Success和Failure包格式的總結(jié)。各個域由左到右傳輸。

0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Code|Identifier|Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Message...
+-+-+-+-+-+-+-+-+-+-+-+-+-

代碼
3 Success
4 Failure

標識符
標識符是一個字節(jié)，用于匹配request和replies。標識符必須從引起這個響應的Response包的標識符復制過來的。
Message
Message域是零個或者多個字節(jié)，它的內(nèi)容依靠實現(xiàn)者。它被設計成可讀的，不得影響協(xié)議操作。建議在Message中包含可顯示的ASCII字符（32－126）。擴展字符集的機制是進一步研究的主題。大小由長度域決定。


安全考慮
安全問題是此備忘錄的主要話題。
PPP中的驗證協(xié)議的交互操作很大程度上依靠于實現(xiàn)者。在文檔中通篇使用SHOULD表明了這點。例如，一旦驗證失敗，有些實現(xiàn)者并不終止鏈路。相反，實現(xiàn)者限制網(wǎng)絡層的通信量的類型構造子網(wǎng)，這樣反過來允許用戶有機會更新秘密或者發(fā)郵件給網(wǎng)絡管理員說明問題。
對于驗證失敗沒有重試機制。然而，LCP狀態(tài)機可以在任何時候重新磋商驗證協(xié)議，這樣就允許了一個新的重試。建議任何用來為驗證失敗的計數(shù)器在成功驗證前或者終止失敗的鏈路前不要重置。不要求驗證是雙向的或者在兩個方向使用相同的協(xié)議。在任一個方向上使用不同的協(xié)議是完全可以接受的。當然，這依靠于在磋商時指定的協(xié)議。
在實踐中，在每個PPP服務器上有一個數(shù)據(jù)庫，它聯(lián)合驗證信息的用戶名字。不期望使用多個方法驗證特殊的命名用戶。這樣使用戶容易受到攻擊。作為代替的，對于每一個命名用戶有一個準確的方法用來驗證用戶名。如果一個用戶在不同的環(huán)境下需要使用不同的驗證方法，那么應該采用截然不同的用戶名，每一個準確代表一個驗證方法。密碼和其他的秘密應該保存在各自的端點以至于對它們的訪問盡可能的受到限制。理想的，只能是為了完成驗證而需要訪問的過程可以訪問秘密。應該使用一種機制分發(fā)秘密，這種機制能夠限制處理秘密實體的數(shù)目。理想的，沒有通過驗證的人不會再得到秘密的內(nèi)容。使用SNMP安全協(xié)議[4]可以實現(xiàn)這個目標，但是這樣的機制不在這個規(guī)范的范圍內(nèi)。
目前正在研究和試驗其他的分發(fā)機制。SNMP安全文檔很好的概括了對網(wǎng)絡的威脅。

參考文獻

[1]Simpson,W.,"ThePoint-to-PointProtocol(PPP)",RFC1331,
Daydreamer,May1992.

[2]Reynolds,J.,andJ.Postel,"AssignedNumbers",RFC1340,
USC/InformationSciencesInstitute,July1992.

[3]Rivest,R.,andS.Dusse,"TheMD5Message-DigestAlgorithm",MIT
LaboratoryforComputerScienceandRSADataSecurity,Inc.RFC
1321,April1992.

[4]Galvin,J.,McCloghrie,K.,andJ.Davin,"SNMPSecurity
Protocols",TrustedInformationSystems,Inc.,HughesLAN
Systems,Inc.,MITLaboratoryforComputerScience,RFC1352,
July1992.

致謝
此文檔的一些內(nèi)容來自RFC1172，它是由DrewPerkinsofCarnegieMellonUniversity和RussHobbyoftheUniversityofCaliforniaatDavis共同制定的。特別感謝DaveBalenson,SteveCrockerand,JamesGalvin,和SteveKent，感謝他們的廣泛的解釋和建議。
主席地址
可以通過現(xiàn)任主席聯(lián)系工作組。
BrianLloyd
Lloyd&Associates
3420SudburyRoad
CameronPark,California95682

Phone:(916)676-1147

EMail:brian@lloyd.com


作者地址
關于此備忘錄的問題可以直接聯(lián)系：
WilliamAllenSimpson
Daydreamer
ComputerSystemsConsultingServices
POBox6205
EastLansing,MI48826-6205

EMail:Bill.Simpson@um.cc.umich.edu

完整版權說明
Copyright(C)TheInternetSociety(2001).AllRightsReserved.

只要在所有復本與推導性工作中包含上面的版權聲明和這段文字，就可以全部地或者部分地且沒有任何限制地復制這篇文檔與其譯本以及把它提供給其它文檔，同樣也可以準備、復制、出版與發(fā)行推導性工作，而且需要評述此推導性工作否則就得解釋它，或者輔助此推導性工作的實現(xiàn)。然而，此文檔本身不可以做任何修改，諸如刪除版權聲明或者因特網(wǎng)社區(qū)或其它因特網(wǎng)組織的涉及，除了當需要開發(fā)因特網(wǎng)標準的目的時之外且在此種情況下必須遵循在因特網(wǎng)標準過程中定義的版權程序，或者除了當要求把它譯成其它語言（即不是英文）的目的時之外。
在上面準予的有限的許可是永久性的，而且因特網(wǎng)社區(qū)或者它的繼承者或指派者都將不會廢除它。
在此包含的這篇文檔與信息是基于“ASIS”而提供的，并且因特網(wǎng)社區(qū)與因特網(wǎng)工程任務組織聲明了所有的授權、表達或含義，且包含對任何授權的限制，比如這里信息的使用不會違反任何授權或者出于特殊目的的商品性或適切性的任何含蓄授權。
致謝
感謝因特網(wǎng)社區(qū)當前為RFC編輯提供了功能基金。