PPP擴展認證協(xié)議

StatusofthisMemoThisdocumentspecifiesanInternetstandardstrackprotocolfortheInternetcommunity,andrequestsdiscussionandsuggestionsforimprovements.Pleaserefertothecurrenteditionofthe"InternetOfficialProtocolStandards"(STD1)forthestandardizationstateandstatusofthisprotocol.Distributionofthismemoisunlimited.CopyrightNoticeCopyright(C)TheInternetSociety(1998).AllRightsReserved.摘要點到點協(xié)議(PPP)提供一種在點到點鏈路上傳輸多協(xié)議報文的標準方法。在PPP中定義了一個可擴展的鏈路控制協(xié)議(LCP)，LCP協(xié)議允許協(xié)商認證協(xié)議，從而可以在網(wǎng)絡(luò)層報文在鏈路上傳輸之前對對端進行認證。本文檔定義了PPP擴展認證協(xié)議(EAP)。目錄1介紹31.1要求規(guī)范31.2術(shù)語32PPP擴展認證協(xié)議(EAP)32.1配置選項(ConfigOption)格式42.2報文格式4請求和應(yīng)答5成功和失敗63EAP請求/應(yīng)答類型7標識Identification7通知Notification83.3否定Nak83.4MD5挑戰(zhàn)字83.5一次密碼（OTP）93.6通用令牌卡94安全考慮95參考文獻106鳴謝101.介紹為了在點到點的鏈路上進行通信,PPP鏈路的每一端在鏈路建立階段必須首先發(fā)送LCP報文配置數(shù)據(jù)鏈路。鏈路建立之后，PPP提供可選的認證階段，可以在進入NCP階段之前對對端進行認證。缺省情況下，認證過程不是必須的。如果需要鏈路認證，PPP實現(xiàn)必須在鏈路建立階段指定“認證協(xié)議”配置選項。這些認證協(xié)議主要是用在主機或者路由器，這些主機和路由器通過交換電路線或者撥號線連在PPP網(wǎng)絡(luò)服務(wù)器上，但是也適用于專線。PPP網(wǎng)絡(luò)服務(wù)器可以用主機或路由器的認證身份來作為網(wǎng)絡(luò)層協(xié)商的選項。本文定義了PPP的擴展認證協(xié)議（EAP）。鏈路建立和認證階段以及其中的認證協(xié)議配置選項在PPP協(xié)議中定義［1］。1.1要求規(guī)范在本文中用以下幾個詞表示規(guī)范描述要求，這幾個詞用大些（黑體）表示。MUST“必須”，也就是形容詞“必需的”，意思是該項是本規(guī)范的絕對要求。MUSTNOT"不得”，意思是該項是本規(guī)范所絕對禁止的。SHOULD"應(yīng)該”，也就是形容詞“推薦的”，意思是在某些場合可能由于某種原因忽略該項，但是協(xié)議的完全實現(xiàn)必須能夠理解該項，在決定其他方式之前要經(jīng)過仔細考慮。MAY“可以”，也就是形容詞“可選的”，意思是該項可以作為可選集使用，不包含該選項的協(xié)議實現(xiàn)必須能夠和包含了該選項的實現(xiàn)交互協(xié)作。1.2術(shù)語本文頻繁使用下面的術(shù)語：觥Autherticator認證者鏈路要求認證的一端。認證者在鏈路建立階段的配置請求項中指定要使用的認證協(xié)議。觥Peer對端點到點鏈路的另一端，由認證者認證的另一端。觥Slientlydiscard靜靜丟棄指直接丟棄數(shù)據(jù)包，不作進一步處理。實現(xiàn)中應(yīng)該提供記錄錯誤的能力——包括所丟棄報文的內(nèi)容，還應(yīng)該在統(tǒng)計計數(shù)器中記錄這個事件。2PPP擴展認證協(xié)議（EAP）PPP擴展認證協(xié)議（EAP）是一個用于PPP認證的通用協(xié)議，可以支持多種認證方法。EAP并不在鏈路建立階段指定認證方法，而是把這個過程推遲到認證階段。這樣認證方就可以在得到更多的信息以后再決定使用什么認證方法。這種機制還允許PPP認證方簡單地把收到的認證報文透傳給后方的認證服務(wù)器，由后方的認證服務(wù)器來真正實現(xiàn)各種認證方法。1.在鏈路階段完成以后，認證方向?qū)Χ税l(fā)送一個或多個請求報文。在請求報文中有一個類型字段用來指明認證方所請求的信息類型，例如是對端的ID、MD5的挑戰(zhàn)字、一次密碼（OTP）以及通用令牌卡等°MD5的挑戰(zhàn)字對應(yīng)于CHAP認證協(xié)議的挑戰(zhàn)字。典型情況下，認證方首先發(fā)送一個ID請求報文隨后再發(fā)送其他的請求報文。當然，并不是必須要首先發(fā)送這個ID請求報文，在對端身份是已知的情況下（如租用線、撥號專線等）可以跳過這個步驟。對端對每一個請求報文回應(yīng)一個應(yīng)答報文。和請求報文一樣，應(yīng)答報文中也包含一個類型字段，對應(yīng)于所回應(yīng)的請求報文中的類型字段。認證方通過發(fā)送一個成功或者失敗的報文來結(jié)束認證過程。優(yōu)點：EAP可以支持多種認證機制，而無需在LCP階段預(yù)協(xié)商過程中指定。某些設(shè)備（如：網(wǎng)絡(luò)接入服務(wù)器）不需要關(guān)心每一個請求報文的真正含義，而是作為一個代理把認證報文直接透傳給后端的認證服務(wù)器。設(shè)備只需關(guān)心認證結(jié)果是成功還是失敗，然后結(jié)束認證階段。缺點：EAP需要在LCP中增加一個新的認證協(xié)議，這樣現(xiàn)有的PPP實現(xiàn)要想使用EAP就必須進行修改。同時，使用EAP也和現(xiàn)有的在LCP協(xié)商階段指定認證方法的模型不一致。2.1配置選項（ConfigOption）格式用于指定EAP認證協(xié)議的認證協(xié)議配置選項格式如下所示，字段的傳輸順序是從左向右。012301234567890123456789012345678901+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ITypelLengthlAuthentication-Protocoll+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+類型Type3長度Length4認證協(xié)議Authentication-ProtocolC227（16進制）對應(yīng)于PPP的擴展認證協(xié)議EAP1.1報文格式當PPP幀的協(xié)議字段是16機制的C227的時候，表示PPP幀的信息字段里封裝了一個完整的EAP報文。EAP報文的格式如下所示，字段的傳輸順序是從左向右。012301234567890123456789012345678901+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ICodelldentifierlLengthl+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+lData...+-+-+-+-+代碼Code代碼字段占一個字節(jié)，表明了EAP報文的報文類型。分配如下：1請求2應(yīng)答3成功4失敗標識Identifier標識字段占一個字節(jié)，用于應(yīng)答報文和請求報文之間進行匹配。長度Length長度字段占兩個字節(jié)，用于表示EAP報文的長度，包括代碼、標識、長度和數(shù)據(jù)字段。超出長度的字節(jié)應(yīng)該視為鏈路層的填充字節(jié)，接收方應(yīng)該忽略。數(shù)據(jù)Data數(shù)據(jù)字段是零個或多個字節(jié)，數(shù)據(jù)字段格式由代碼字段確定。請求和應(yīng)答描述請求報文由認證方發(fā)向?qū)Χ?。每一個請求報文都有一個類型字段用來表示請求方在請求什么信息。認證方必須向?qū)Χ税l(fā)送一個EAP報文并把其中的代碼（CODE）字段設(shè)為1（REQUEST）。認證方必須在收到一個有效的應(yīng)答報文或者在一個可選的計數(shù)器計滿后再發(fā)送其他的請求報文。重傳的請求報文中的標識（ID）字段必須保持不變，以便區(qū)分重傳的請求報文和新的請求報文。數(shù)據(jù)字段的內(nèi)容取決于類型字段的值。對端每收到一個請求報文后必須回應(yīng)一個報文。只有在收到請求報文的情況下才發(fā)送應(yīng)答報文，請求報文沒有超時重傳的情況。應(yīng)答報文中標識（ID）字段必須和請求報文中的標識字（ID）段相匹配。1實現(xiàn)注意事項：由于在認證過程經(jīng)常涉及到用戶輸入，必須采取合適的重傳策略和超時時間。建議缺省情況下采用6秒的超時計數(shù)器，最大重傳次數(shù)設(shè)為10。在某些情況下可以延長超時時間（如涉及到令牌卡的情況九另外，對端在等待用戶輸入的時候必須靜靜地丟棄收到的重復(fù)的請求報文。請求和應(yīng)答報文的格式如下所示，字段的傳輸順序是從左向右。012301234567890123456789012345678901+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|Code|Identifier|Length|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|Type|Type-Data...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-代碼Code1請求2.應(yīng)答標識Identifier標識字段占一個字節(jié)。由于等待應(yīng)答超時而重傳的請求報文的標識字段必須保持不變。新的（不是重傳的）請求報文必須改變標識字段。如果對端在收到重復(fù)的請求報文之前已經(jīng)發(fā)送過針對該報文的應(yīng)答報文，它必須重新發(fā)送已發(fā)送的應(yīng)答報文。如果對端收到重復(fù)的請求報文之前還沒有發(fā)送針對該報文的應(yīng)答報文，它必須靜靜地丟棄重復(fù)的請求報文。長度Length長度字段占兩個自己，用于表示EAP報文的長度，包括代碼、標識、長度和數(shù)據(jù)字段。超出長度的字節(jié)應(yīng)該視為鏈路層的填充字節(jié)，接收方應(yīng)該忽略。類型Type類型字段占一個字節(jié)。這個字段表示請求或者應(yīng)答的信息類型。每一種EAP請求或者應(yīng)答報文必須指定并且也只能指定一種類型。一般情況下，應(yīng)答報文中的類型字段和請求報文中的類型字段是相同的，但是還存在一種為NAK的應(yīng)答類型用來表示對端不接受請求報文中的信息類型。當對端用NAK報文應(yīng)答請求報文的時候，對端可以同時提供一個它所支持的的信息類型供認證者選擇。在本文的隨后章節(jié)中有對類型的詳細定義。類型數(shù)據(jù)Type-Data類型數(shù)據(jù)字段隨著請求或應(yīng)答報文中的類型字段變化而變化。成功和失敗描述成功報文是認證者向發(fā)送給對端用來指示認證成功的。認證者必須傳送代碼字段為3（成功）的EAP報文。如果不能認證對端（對應(yīng)于一個或多個請求報文收到不可接受的應(yīng)答），認證者必須發(fā)送代碼字段為4（失?。┑腅AP報文。認證者可能會在發(fā)送失敗的應(yīng)答報文之前再發(fā)起請求報文來避免用戶輸入錯誤的情況。1實現(xiàn)注意事項：由于成功和失敗報文不需要確認，它們有可能會丟失。對端必須允許這種情況的發(fā)生。對端可以把網(wǎng)絡(luò)協(xié)議報文作為對認證成功的指示；同樣也可以把LCP的結(jié)束請求報文作為對認證失敗的指示。成功和失敗報文的格式如下所示，字段的傳輸順序從左向右。012301234567890123456789012345678901+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|Code|Identifier|Length|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+代碼Code3代表成功4代表失敗標識Identifier標識字段占一個字節(jié)，用于和對端的應(yīng)答報文之間的匹配。成功和失敗報文中的標識字段必須和它所對應(yīng)的應(yīng)答報文中的標識字段相匹配。長度Length41EAP請求/應(yīng)答類型這一節(jié)中主要定義了在請求和應(yīng)答的交互過程中所使用到的EAP類型集，后續(xù)的文檔可能會再擴展其他的類型。類型字段占一個字節(jié)，它標識了EAP請求和應(yīng)答報文的結(jié)構(gòu)。前三中類型有其特別的適用情況，后兩種類型適用于認證信息的交互。NAK類型只適用在應(yīng)答報文中，而絕不能出現(xiàn)在請求報文中。所有的EAP實現(xiàn)必須支持類型1到4,本文中定義了這些類型以及類型5、6。后續(xù)的RFC可能會定義一些其他的類型。標識Identity通知Notification3否定Nak（只用在應(yīng)答中）4MD5挑戰(zhàn)字MD5-Challenge一次密碼One-TimePassword(OTP)(RFC1938)通用令牌卡GenericTokenCard標識Identification描述標識類型用來詢問對端的身份。一般情況下，認證者會首先發(fā)起這種類型的請求，這種請求報文可選擇包含一個可顯示的提示信息，用于和終端用戶間的交互。對這種請求報文的應(yīng)答報文的類型值也必須設(shè)為1。1實現(xiàn)注意事項：對端可能通過用戶的輸入得到身份值，因此建議認證者在收到錯誤的身份值或者認證失敗的身份值后重新發(fā)送標識類型的請求報文，以應(yīng)付用戶輸入錯誤的情況。并且建議認證者至少在嘗試三次失敗以后才向?qū)Χ税l(fā)送一個失敗（Failure）的應(yīng)答報文來終止認證階段。認證者可以在重新發(fā)送標識（ID）請求報文之前發(fā)送一個通知（Notification）報文用于提示對端認證錯誤（也可以把這些提示信息放在重新發(fā)送的標識（ID）請求報文的提示信息中）。類型Type1類型數(shù)據(jù)Type-Data在請求報文中這個字段可以包含一段可顯示的提示信息；而在應(yīng)答報文中這個字段包含對端的身份（ID），如果對端還不知道自己的身份，那么在長度（Length）字段中指示標識（ID）字段的長度應(yīng)該為零。在該字段中的字符串不需要用空字符（NULL）結(jié)束，因為長度字段中的值就標明了字符串的長度。通知Notification描述通知類型經(jīng)常用于認證者向?qū)Χ藗魉鸵粋€可顯示的字符串。對端應(yīng)該把這個字符串顯示給用戶，如果不能顯示的話也應(yīng)該記錄下來。它主要用于向?qū)Χ税l(fā)一些通知，比如提示密碼將要超期、OTP的順序號碼接近零以及認證失敗的警告等。在大部分情況下不需要這個類型。類型Type2類型數(shù)據(jù)Type-Data請求報文中的類型數(shù)據(jù)字段包含一段長度大于0字節(jié)的可顯示的字符串。字符串的長度由請求報文中的長度字段的值來決定，并且字符串不需要用空字符（NULL）結(jié)束。對端收到這種類型的請求報文以后不管怎么處理其中的通知信息都必須立刻發(fā)送一個類型值為2（通知）的應(yīng)答報文，并且應(yīng)答報文的類型數(shù)據(jù)字段的長度應(yīng)該為零。1.3否定Nak描述否定類型只應(yīng)該出現(xiàn)在應(yīng)答報文中，用來表示對端不接受請求報文中的認證信息類型。認證信息類型是指類型值大于等于4的信息類型。否定類型的應(yīng)答報文中可以同時提供一個對端所期望的認證信息類型。類型Type3類型數(shù)據(jù)Type-Data這個字段必須包含一個字節(jié)用來向認證者提供對端所期待的認證信息類型。1.4MD5挑戰(zhàn)字描述MD5挑戰(zhàn)字和PPP的CHAP[3]協(xié)議中的挑戰(zhàn)字類似，使用MD5算法°CHAP的具體實現(xiàn)細節(jié)應(yīng)該查閱PPP挑戰(zhàn)握手認證協(xié)議的RFC[3]。在類型為MD5挑戰(zhàn)字的請求報文中包含一個“挑戰(zhàn)”信息，對端收到這個請求報文后必須發(fā)送一個應(yīng)答報文，應(yīng)答報文的信息類型可以是4（MD5挑戰(zhàn)字）或者3（否定），在NAK應(yīng)答報文中對端同時也標明了它所期待的認證機制的類型值。所有的EAP實現(xiàn)必須支持MD5挑戰(zhàn)字算法。類型Type4類型數(shù)據(jù)Type-Data類型數(shù)據(jù)的內(nèi)容如下所示。至于如何使用其中的這些字段請參閱PPP的挑戰(zhàn)握手認證協(xié)議［3］。012301234567890123456789012345678901+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|Value-Size|Value...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|Name...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+1.5一次密碼（OTP）描述一次密碼系統(tǒng)在文獻［4］中定義。請求報文中包含一個可顯示的信息作為一次密碼（OTP）的挑戰(zhàn)字。對端收到這種請求報文后必須發(fā)送一個應(yīng)答報文，應(yīng)答報文的類型值也必須設(shè)為5（OTP）或者3（NAK），在NAK應(yīng)答報文中對端同時也標明了它所期待的認證機制的類型值。類型Type5類型數(shù)據(jù)Type-Data在請求報文中，類型數(shù)據(jù)字段包含一個可顯示的信息作為一次密碼（OTP）的挑戰(zhàn)字。在應(yīng)答報文中類型數(shù)據(jù)字段用于填充從OTP目錄中得到的6個字。該字段不需要用空字符（NULL）結(jié)束，該字段的長度可以從報文的長度字段中計算得到。1.6通用令牌卡描述通用令牌卡類型適用于各種需要用戶輸入信息的令牌卡的實現(xiàn)。在請求報文中包含一段ASCII文本信息，而應(yīng)答報文中包含用于認證的令牌卡信息。典型的，令牌卡信息是由用戶從令牌卡設(shè)備上讀取得到并作為ASCII文本輸入的。類型Type6類型數(shù)據(jù)Type-Data在請求報文中，該字段包含一段長度大于零的可顯示的信息，它的長度可以從報文的長度字段中計算得到，因此該字段不需要用空字符（NULL）結(jié)束。對端收到這種請求報文以后必須發(fā)送一個類型值為6（通用令牌卡）的報文作為應(yīng)答，應(yīng)答報文中包含用于認證的令牌卡信息，通用它的長度也可以從報文的長度字段中計算得到。1安全考慮安全主題是該RFC的主題。PPP的認證交換過程依賴于實現(xiàn)。例如在有些實現(xiàn)中認證失敗就直接終止鏈路，而在另外一些實現(xiàn)中并不終止鏈路，而只是限制和濾除網(wǎng)絡(luò)層的流量從而允許用戶更改密鑰或者發(fā)郵件通知管理員。雖然沒有如何處理認證失敗以后的重新認證的規(guī)定，但由于LCP的狀態(tài)機可以隨時重新協(xié)商認證協(xié)議，然后開始一個新的認證過程，因此建議用于認證失敗的各種計