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

2.密碼驗證協議
密碼驗證協議（PAP）提供了一種簡單的方法，可以使對端（peer）使用2次握手建立身
份驗證。這個方法僅僅在鏈路初始化時使用。
鏈路建立階段完成后，對端不停地發送Id/PassWord對給驗證者，一直到驗證被響應或者
連接終止為止。
PAP不是一個健壯的身份驗證方法。密碼在電路上是明文發送的，并且對回送或者重復
驗證和錯誤攻擊沒有保護措施。對端控制著嘗試的頻率和時間。
包含健壯驗證方法（例如CHAP，下面描述）的任何實現者必須提供商議優先于PAP的
方法。
這個驗證方法最適合用在使用有效的明文密碼在遠程主機上模擬登陸的地方了。通過這
種用法，飧齜椒ㄏ蚱脹ㄓ沒б鍬皆凍討骰峁┝艘恢職踩睦嗨萍侗稹?BR>實現注重：要限制暴露在PPP鏈路上傳輸明文密碼和避免在整個網絡上發送明文密碼是
可能的。假如遠程主機密碼是以單向轉換值保存的，并且轉換函數的算法是在當地主機上完
成的，則明文密碼應該在和遠程主機的轉換密碼比較前在本地轉換。

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

0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TypeLengthAuthentication-Protocol
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CodeIdentifierLength
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data...
+-+-+-+-+

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

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

0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CodeIdentifierLength
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Peer-IDLengthPeer-Id...
+-+-+-+-+-+-+-+-+-+-+-+-+
Passwd-LengthPassword...
+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CodeIdentifierLength
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Msg-LengthMessage...
+-+-+-+-+-+-+-+-+-+-+-+-+-

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

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

0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TypeLengthAuthentication-Protocol
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Algorithm
+-+-+-+-+-+-+-+-+

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

0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CodeIdentifierLength
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data...
+-+-+-+-+

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

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

0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CodeIdentifierLength
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value-SizeValue...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Name...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

代碼
1 Challenge
2 Response

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

0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CodeIdentifierLength
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message...
+-+-+-+-+-+-+-+-+-+-+-+-+-

代碼
3 Success
4 Failure

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


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

參考文獻

[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.

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

Phone:(916)676-1147

EMail:brian@lloyd.com


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

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

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

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