PPP擴展認證協議(EAP)

StatusofthisMemo

ThisdocumentspecifiesanInte.netstandardstrackprotocolforthe
Internetcommunity,andrequestsdiscussionandsuggestionsfor
improvements.Pleaserefertothecurrenteditionofthe"Internet
OfficialProtocolStandards"(STD1)forthestandardizationstate
andstatusofthisprotocol.Distributionofthismemoisunlimited.

CopyrightNotice

Copyright(C)TheInternetSociety(1998).AllRightsReserved.

摘要

點到點協議（PPP）提供一種在點到點鏈路上傳輸多協議報文的標準方法。在PPP中定義了一個可擴展的鏈路控制協議（LCP），LCP協議允許協商認證協議，從而可以在網絡層報文在鏈路上傳輸之前對對端進行認證。本文檔定義了PPP擴展認證協議（EAP）。
目錄
1介紹
3
1.1要求規范
3
1.2術語
3
2PPP擴展認證協議(EAP)
3
2.1配置選項(ConfigOption)格式
4
2.2報文格式
4
請求和應答
5
成功和失敗
6
3EAP請求/應答類型
7
3.1標識Identification
7
3.2通知Notification
8
3.3否定Nak
8
3.4MD5挑戰字
8
3.5一次密碼（OTP）
9
3.6通用令牌卡
9
4安全考慮
9
5參考文獻
10
6鳴謝
10
1.介紹
為了在點到點的鏈路上進行通信，PPP鏈路的每一端在鏈路建立階段必須首先發送LCP報文配置數據鏈路。鏈路建立之后，PPP提供可選的認證階段，可以在進入NCP階段之前對對端進行認證。
缺省情況下，認證過程不是必須的。如果需要鏈路認證，PPP實現必須在鏈路建立階段指定“認證協議”配置選項。
這些認證協議主要是用在主機或者路由器，這些主機和路由器通過交換電路線或者撥號線連在PPP網絡服務器上，但是也適用于專線。PPP網絡服務器可以用主機或路由器的認證身份來作為網絡層協商的選項。
本文定義了PPP的擴展認證協議（EAP）。鏈路建立和認證階段以及其中的認證協議配置選項在PPP協議中定義[1]。
1.1要求規范
在本文中用以下幾個詞表示規范描述要求，這幾個詞用大些（黑體）表示。
1. MUST “必須”，也就是形容詞“必需的”，意思是該項是本規范的絕對要求。
2. MUSTNOT“不得”，意思是該項是本規范所絕對禁止的。
3. SHOULD“應該”，也就是形容詞“推薦的”，意思是在某些場合可能由于某種原因忽略該項，但是協議的完全實現必須能夠理解該項，在決定其他方式之前要經過仔細考慮。
4. MAY“可以”，也就是形容詞“可選的”，意思是該項可以作為可選集使用，不包含該選項的協議實現必須能夠和包含了該選項的實現交互協作。
1.2術語
本文頻繁使用下面的術語：
黖 Autherticator認證者
鏈路要求認證的一端。認證者在鏈路建立階段的配置請求項中指定要使用的認證協議。
黖 Peer對端
點到點鏈路的另一端，由認證者認證的另一端。
黖 Slientlydiscard靜靜丟棄
指直接丟棄數據包，不作進一步處理。實現中應該提供記錄錯誤的能力——包括所丟棄報文的內容，還應該在統計計數器中記錄這個事件。
2PPP擴展認證協議(EAP)
PPP擴展認證協議（EAP）是一個用于PPP認證的通用協議，可以支持多種認證方法。EAP并不在鏈路建立階段指定認證方法，而是把這個過程推遲到認證階段。這樣認證方就可以在得到更多的信息以后再決定使用什么認證方法。這種機制還允許PPP認證方簡單地把收到的認證報文透傳給后方的認證服務器，由后方的認證服務器來真正實現各種認證方法。
1. 在鏈路階段完成以后，認證方向對端發送一個或多個請求報文。在請求報文中有一個類型字段用來指明認證方所請求的信息類型，例如是對端的ID、MD5的挑戰字、一次密碼（OTP）以及通用令牌卡等。MD5的挑戰字對應于CHAP認證協議的挑戰字。典型情況下，認證方首先發送一個ID請求報文隨后再發送其他的請求報文。當然，并不是必須要首先發送這個ID請求報文，在對端身份是已知的情況下（如租用線、撥號專線等）可以跳過這個步驟。
2. 對端對每一個請求報文回應一個應答報文。和請求報文一樣，應答報文中也包含一個類型字段，對應于所回應的請求報文中的類型字段。
3. 認證方通過發送一個成功或者失敗的報文來結束認證過程。

優點：
EAP可以支持多種認證機制，而無需在LCP階段預協商過程中指定。
某些設備（如：網絡接入服務器）不需要關心每一個請求報文的真正含義，而是作為一個代理把認證報文直接透傳給后端的認證服務器。設備只需關心認證結果是成功還是失敗，然后結束認證階段。

缺點：
EAP需要在LCP中增加一個新的認證協議，這樣現有的PPP實現要想使用EAP就必須進行修改。同時，使用EAP也和現有的在LCP協商階段指定認證方法的模型不一致。
2.1配置選項(ConfigOption)格式
用于指定EAP認證協議的認證協議配置選項格式如下所示，字段的傳輸順序是從左向右。
0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type|Length|Authentication-Protocol|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
類型Type
3
長度Length
4
認證協議Authentication-Protocol
C227(16進制)對應于PPP的擴展認證協議EAP
1.1報文格式
當PPP幀的協議字段是16機制的C227的時候，表示PPP幀的信息字段里封裝了一個完整的EAP報文。EAP報文的格式如下所示，字段的傳輸順序是從左向右。

0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Code|Identifier|Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Data...
+-+-+-+-+
代碼Code
代碼字段占一個字節，表明了EAP報文的報文類型。分配如下：
1請求
2應答
3成功
4失敗

標識Identifier
標識字段占一個字節，用于應答報文和請求報文之間進行匹配。

長度Length
長度字段占兩個字節，用于表示EAP報文的長度，包括代碼、標識、長度和數據字段。超出長度的字節應該視為鏈路層的填充字節，接收方應該忽略。

數據Data
數據字段是零個或多個字節，數據字段格式由代碼字段確定。

請求和應答
描述
請求報文由認證方發向對端。每一個請求報文都有一個類型字段用來表示請求方在請求什么信息。認證方必須向對端發送一個EAP報文并把其中的代碼（CODE）字段設為1（REQUEST）。認證方必須在收到一個有效的應答報文或者在一個可選的計數器計滿后再發送其他的請求報文。重傳的請求報文中的標識（ID）字段必須保持不變，以便區分重傳的請求報文和新的請求報文。數據字段的內容取決于類型字段的值。對端每收到一個請求報文后必須回應一個報文。只有在收到請求報文的情況下才發送應答報文，請求報文沒有超時重傳的情況。應答報文中標識（ID）字段必須和請求報文中的標識字（ID）段相匹配。
1實現注意事項：由于在認證過程經常涉及到用戶輸入，必須采取合適的重傳策略和超時時間。建議缺省情況下采用6秒的超時計數器，最大重傳次數設為10。在某些情況下可以延長超時時間（如涉及到令牌卡的情況）。另外，對端在等待用戶輸入的時候必須靜靜地丟棄收到的重復的請求報文。
請求和應答報文的格式如下所示，字段的傳輸順序是從左向右。
0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Code|Identifier|Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type|Type-Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
代碼Code
1請求
2.應答

標識Identifier
標識字段占一個字節。由于等待應答超時而重傳的請求報文的標識字段必須保持不變。新的（不是重傳的）請求報文必須改變標識字段。如果對端在收到重復的請求報文之前已經發送過針對該報文的應答報文，它必須重新發送已發送的應答報文。如果對端收到重復的請求報文之前還沒有發送針對該報文的應答報文，它必須靜靜地丟棄重復的請求報文。

長度Length
長度字段占兩個自己，用于表示EAP報文的長度，包括代碼、標識、長度和數據字段。超出長度的字節應該視為鏈路層的填充字節，接收方應該忽略。

類型Type
類型字段占一個字節。這個字段表示請求或者應答的信息類型。每一種EAP請求或者應答報文必須指定并且也只能指定一種類型。一般情況下，應答報文中的類型字段和請求報文中的類型字段是相同的，但是還存在一種為NAK的應答類型用來表示對端不接受請求報文中的信息類型。當對端用NAK報文應答請求報文的時候，對端可以同時提供一個它所支持的的信息類型供認證者選擇。在本文的隨后章節中有對類型的詳細定義。

類型數據Type-Data
類型數據字段隨著請求或應答報文中的類型字段變化而變化。

成功和失敗
描述
成功報文是認證者向發送給對端用來指示認證成功的。認證者必須傳送代碼字段為3（成功）的EAP報文。
如果不能認證對端（對應于一個或多個請求報文收到不可接受的應答），認證者必須發送代碼字段為4（失?。┑腅AP報文。認證者可能會在發送失敗的應答報文之前再發起請求報文來避免用戶輸入錯誤的情況。
1實現注意事項：由于成功和失敗報文不需要確認，它們有可能會丟失。對端必須允許這種情況的發生。對端可以把網絡協議報文作為對認證成功的指示；同樣也可以把LCP的結束請求報文作為對認證失敗的指示。
成功和失敗報文的格式如下所示，字段的傳輸順序從左向右。
0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Code|Identifier|Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
代碼Code
3代表成功
4代表失敗

標識Identifier
標識字段占一個字節，用于和對端的應答報文之間的匹配。成功和失敗報文中的標識字段必須和它所對應的應答報文中的標識字段相匹配。

長度Length
4
1EAP請求/應答類型
這一節中主要定義了在請求和應答的交互過程中所使用到的EAP類型集，后續的文檔可能會再擴展其他的類型。類型字段占一個字節，它標識了EAP請求和應答報文的結構。前三中類型有其特別的適用情況，后兩種類型適用于認證信息的交互。NAK類型只適用在應答報文中，而絕不能出現在請求報文中。所有的EAP實現必須支持類型1到4，本文中定義了這些類型以及類型5、6。后續的RFC可能會定義一些其他的類型。
1標識Identity
2通知Notification
3否定Nak(只用在應答中)
4MD5挑戰字MD5-Challenge
5一次密碼One-TimePassword(OTP)(RFC1938)
6通用令牌卡GenericTokenCard

1.1標識Identification
描述
標識類型用來詢問對端的身份。一般情況下，認證者會首先發起這種類型的請求，這種請求報文可選擇包含一個可顯示的提示信息，用于和終端用戶間的交互。對這種請求報文的應答報文的類型值也必須設為1。
1實現注意事項：對端可能通過用戶的輸入得到身份值，因此建議認證者在收到錯誤的身份值或者認證失敗的身份值后重新發送標識類型的請求報文，以應付用戶輸入錯誤的情況。并且建議認證者至少在嘗試三次失敗以后才向對端發送一個失?。‵ailure）的應答報文來終止認證階段。認證者可以在重新發送標識（ID）請求報文之前發送一個通知（Notification）報文用于提示對端認證錯誤（也可以把這些提示信息放在重新發送的標識（ID）請求報文的提示信息中）。
類型Type
1
類型數據Type-Data
在請求報文中這個字段可以包含一段可顯示的提示信息；而在應答報文中這個字段包含對端的身份（ID），如果對端還不知道自己的身份，那么在長度（Length）字段中指示標識（ID）字段的長度應該為零。在該字段中的字符串不需要用空字符（NULL）結束，因為長度字段中的值就標明了字符串的長度。
1.2通知Notification
描述
通知類型經常用于認證者向對端傳送一個可顯示的字符串。對端應該把這個字符串顯示給用戶，如果不能顯示的話也應該記錄下來。它主要用于向對端發一些通知，比如提示密碼將要超期、OTP的順序號碼接近零以及認證失敗的警告等。在大部分情況下不需要這個類型。
類型Type
2
類型數據Type-Data
請求報文中的類型數據字段包含一段長度大于0字節的可顯示的字符串。字符串的長度由請求報文中的長度字段的值來決定，并且字符串不需要用空字符（NULL）結束。對端收到這種類型的請求報文以后不管怎么處理其中的通知信息都必須立刻發送一個類型值為2（通知）的應答報文，并且應答報文的類型數據字段的長度應該為零。
1.3否定Nak
描述
否定類型只應該出現在應答報文中，用來表示對端不接受請求報文中的認證信息類型。認證信息類型是指類型值大于等于4的信息類型。否定類型的應答報文中可以同時提供一個對端所期望的認證信息類型。
類型Type
3
類型數據Type-Data
這個字段必須包含一個字節用來向認證者提供對端所期待的認證信息類型。
1.4MD5挑戰字
描述
MD5挑戰字和PPP的CHAP[3]協議中的挑戰字類似，使用MD5算法。CHAP的具體實現細節應該查閱PPP挑戰握手認證協議的RFC[3]。在類型為MD5挑戰字的請求報文中包含一個“挑戰”信息，對端收到這個請求報文后必須發送一個應答報文，應答報文的信息類型可以是4（MD5挑戰字）或者3（否定），在NAK應答報文中對端同時也標明了它所期待的認證機制的類型值。所有的EAP實現必須支持MD5挑戰字算法。
類型Type
4
類型數據Type-Data
類型數據的內容如下所示。至于如何使用其中的這些字段請參閱PPP的挑戰握手認證協議[3]。
0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Value-Size|Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Name...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1.5一次密碼（OTP）
描述
一次密碼系統在文獻[4]中定義。請求報文中包含一個可顯示的信息作為一次密碼（OTP）的挑戰字。對端收到這種請求報文后必須發送一個應答報文，應答報文的類型值也必須設為5（OTP）或者3（NAK）,在NAK應答報文中對端同時也標明了它所期待的認證機制的類型值。
類型Type
5
類型數據Type-Data
在請求報文中，類型數據字段包含一個可顯示的信息作為一次密碼（OTP）的挑戰字。在應答報文中類型數據字段用于填充從OTP目錄中得到的6個字。該字段不需要用空字符（NULL）結束，該字段的長度可以從報文的長度字段中計算得到。
1.6通用令牌卡
描述
通用令牌卡類型適用于各種需要用戶輸入信息的令牌卡的實現。在請求報文中包含一段ASCII文本信息，而應答報文中包含用于認證的令牌卡信息。典型的，令牌卡信息是由用戶從令牌卡設備上讀取得到并作為ASCII文本輸入的。
類型Type
6
類型數據Type-Data
在請求報文中，該字段包含一段長度大于零的可顯示的信息，它的長度可以從報文的長度字段中計算得到，因此該字段不需要用空字符（NULL）結束。對端收到這種請求報文以后必須發送一個類型值為6（通用令牌卡）的報文作為應答，應答報文中包含用于認證的令牌卡信息，通用它的長度也可以從報文的長度字段中計算得到。

1安全考慮
安全主題是該RFC的主題。
PPP的認證交換過程依賴于實現。例如在有些實現中認證失敗就直接終止鏈路，而在另外一些實現中并不終止鏈路，而只是限制和濾除網絡層的流量從而允許用戶更改密鑰或者發郵件通知管理員。
雖然沒有如何處理認證失敗以后的重新認證的規定，但由于LCP的狀態機可以隨時重新協商認證協議，然后開始一個新的認證過程，因此建議用于認證失敗的各種計數器只有在認證成功或者鏈路終結以后才重新設置。
并沒有要求認證一定要在兩個方向上進行，也沒有要求在兩個方向上使用同樣的認證協議。我們完全可以接受在兩個方向上使用不同的認證協議，當然，這依賴于協商的結果。
實際上，一個PPP服務器不應該使用多種認證協議來認證一個特定的用戶。因為這樣容易使用戶在使用安全性較低的認證協議（如PAP，而不是EAP）的時候受到攻擊。對于每一個用戶名，應該指示一種特定的認證方法，如果用戶在不同的環境下使用不同的認證方法，那么他應該在不同的環境下使用不同的用戶名，每個用戶名對應一個認證方法。

1參考文獻
[1]Simpson,W.,"ThePoint-to-PointProtocol(PPP)",STD51,RFC1661,July1994.
[2]Reynolds,J.andJ.Postel,"AssignedNumbers",STD2,RFC1700,October1994.
[3]Simpson,W.,"PPPChallengeHandshakeAuthenticationProtocol(CHAP)",RFC1994,August1996.
[4]Haller,N.andC.Metz,"AOne-TimePasswordSystem",RFC1938,May1996.
[5]Yergeau,F.,"UTF-8,atransformationformatofUnicodeandISO10646",RFC2044,October1996.
[6]Bradner,S.,"KeywordsforuseinRFCstoIndicateRequirementLevels",RFC2119,March1997.

1鳴謝
撰寫本文的很多靈感都來源于DaveCarrel的AHA草案和PPP的CHAP認證協議。BillSimpson提供了本文所使用的書寫模板。AlRubens為本文提出了很多有價值的建議。