PPP可擴(kuò)展認(rèn)證協(xié)議

PAGEPPP可擴(kuò)展認(rèn)證協(xié)議(RFC2284PPPExtensibleAuthenticationProtocol,EAP)摘要點(diǎn)到點(diǎn)協(xié)議（PPP，參考文獻(xiàn)[1]）提供了一種在點(diǎn)到點(diǎn)鏈路上傳輸多協(xié)議數(shù)據(jù)包的標(biāo)準(zhǔn)的方法。PPP還定義了可擴(kuò)展的鏈路控制協(xié)議(LinkControlProtocol,簡稱LCP)，允許該鏈路在進(jìn)入網(wǎng)絡(luò)層協(xié)議之前協(xié)商為通信對方進(jìn)行身份認(rèn)證所使用的認(rèn)證協(xié)議(AuthenticationProtocol)。本文檔定義了PPP可擴(kuò)展的認(rèn)證協(xié)議（AuthenticationProtocol）。ThisdocumentdefinesthePPPExtensibleAuthenticationProtocol.目錄1.簡介21.1規(guī)范的條件21.2術(shù)語22.PPP可擴(kuò)展認(rèn)證協(xié)議(EAP)32.1配置選項(xiàng)格式42.2數(shù)據(jù)包格式62.2.1Request和Response62.2.2Success和Failure73.初始EAPRequest/Response類型83.1Identity93.2Notification103.3Nak103.4MD5-Challenge113.5One-TimePassword(OTP)113.6GenericTokenCard12參考文獻(xiàn)13致謝14主席地址14作者地址14完整的版權(quán)通告151.簡介為了在點(diǎn)到點(diǎn)鏈路上建立通信，在鏈路建立階段PPP鏈路的每一端都必須首先發(fā)送LCP數(shù)據(jù)包來對該數(shù)據(jù)鏈路進(jìn)行配置。在鏈路已經(jīng)建立起來后，在進(jìn)入網(wǎng)絡(luò)層協(xié)議之前，PPP提供一個(gè)可選的認(rèn)證階段。缺省認(rèn)為，認(rèn)證不是必需的。如果想要對鏈路進(jìn)行認(rèn)證，實(shí)現(xiàn)必須在鏈路建立階段指定認(rèn)證協(xié)議配置選項(xiàng)（Authentication-ProtocolConfiguration）。這些認(rèn)證協(xié)議主要是由通過交換電路（switchedcircuits）或者撥號鏈路（也適用于專用鏈路）連接到PPP網(wǎng)絡(luò)服務(wù)器上的主機(jī)或者路由器使用。服務(wù)器可以使用這些主機(jī)或路由器的身份（identification）來選擇網(wǎng)絡(luò)層協(xié)商的選項(xiàng)。本文檔定義了PPP可擴(kuò)展認(rèn)證協(xié)議（EAP）。鏈路建立階段、認(rèn)證階段以及認(rèn)證協(xié)議配置選項(xiàng)在點(diǎn)到點(diǎn)協(xié)議（PPP，參考文獻(xiàn)[1]）中定義。1.1.本規(guī)范的條件本文檔中出現(xiàn)的關(guān)鍵詞必須（MUST）,不允許（MUSTNOT）,必需（REQUIRED）,應(yīng)該（SHALL）,不應(yīng)（SHALLNOT）,應(yīng)該（SHOULD）,不應(yīng)該（SHOULDNOT）,推薦（RECOMMENDED）,可以（可能，MAY）,以及可選（OPTIONAL）,按RFC2119(參考文獻(xiàn)[6])解釋。中譯版本將對這些關(guān)鍵詞加粗并加上紅色突出顯示。1.2.術(shù)語本文檔頻繁使用下面的術(shù)語：認(rèn)證者（authenticator）鏈路要求進(jìn)行認(rèn)證的一端。在鏈路建立階段的Configure-Request中認(rèn)證者指定了將要使用的認(rèn)證協(xié)議。對方（peer）點(diǎn)到點(diǎn)鏈路的另一端；被認(rèn)證者進(jìn)行認(rèn)證的那一端。悄悄地丟棄（silentlydiscard）意味著實(shí)現(xiàn)不對數(shù)據(jù)包進(jìn)行進(jìn)一步處理而把它丟掉。實(shí)現(xiàn)應(yīng)該提供對錯(cuò)誤包括被丟棄數(shù)據(jù)包的內(nèi)容進(jìn)行登記的能力，并且應(yīng)該在一個(gè)統(tǒng)計(jì)計(jì)數(shù)器中記錄下該事件?？娠@示的消息（displayablemessage）解釋為人類可讀的字符串，并且不允許影響本協(xié)議的操作。消息的編碼必須符合UTF-8轉(zhuǎn)換格式（參考文獻(xiàn)[5]）。2.PPP可擴(kuò)展認(rèn)證協(xié)議(EAP)PPP可擴(kuò)展認(rèn)證協(xié)議(EAP)是PPP認(rèn)證的一個(gè)通用協(xié)議，支持多種認(rèn)證機(jī)制。EAP在鏈路控制（LCP）階段沒有選擇好一種認(rèn)證機(jī)制，而把這一步推遲到認(rèn)證(Authentication)階段。這樣就允許認(rèn)證者在確定某種特定認(rèn)證機(jī)制之前請求更多的信息。這樣做還允許使用一個(gè)“后端”服務(wù)器來實(shí)際實(shí)現(xiàn)各種認(rèn)證機(jī)制，PPP的認(rèn)證者僅僅需要傳送認(rèn)證（passthrough）認(rèn)證信息。1.在鏈路建立階段完成后，認(rèn)證者發(fā)送一個(gè)或多個(gè)Request來對對方進(jìn)行認(rèn)證。Request中有一個(gè)type域表明請求的類型。Request中type的實(shí)例包括，Identity,MD5-challenge,One-TimePasswords,GenericTokenCard等等。MD5-challenge類型與CHAP認(rèn)證協(xié)議緊緊對應(yīng)。典型情況下，認(rèn)證者將發(fā)送一個(gè)最初的Identity請求，然后是一個(gè)或多個(gè)請求認(rèn)證信息的Request。但是，最初的IdentityRequest并不是必需的，在identity能被事先假定（租借鏈路，專用撥號線路等等）的情況下可以跳過（bypass）。2.對方發(fā)送一個(gè)Response數(shù)據(jù)包對每一個(gè)Request做出應(yīng)答。對應(yīng)于每一個(gè)Request數(shù)據(jù)包，Response數(shù)據(jù)包包含一個(gè)type域，與Request中的type域?qū)?yīng)。3.認(rèn)證者發(fā)送一個(gè)Success或Failure數(shù)據(jù)包結(jié)束認(rèn)證階段。優(yōu)點(diǎn)EAP協(xié)議可以支持多種認(rèn)證機(jī)制，而不必在LCP階段預(yù)先協(xié)商好某種特定認(rèn)證機(jī)制。特定設(shè)備（例如，網(wǎng)絡(luò)訪問服務(wù)器NAS）不一定要理解每一種請求類型，而可以簡單的作為某個(gè)主機(jī)上的“后端”服務(wù)器的透傳（passthrough）代理。設(shè)備僅僅需要檢查success/failure的code來結(jié)束認(rèn)證階段。缺點(diǎn)EAP要求給LCP增加新的認(rèn)證類型（機(jī)制），這就要求修改PPP實(shí)現(xiàn)以使用EAP。它也與在LCP階段就協(xié)商好特定認(rèn)證機(jī)制的傳統(tǒng)的PPP認(rèn)證模式相背離。2.1.認(rèn)證選項(xiàng)格式協(xié)商EAP認(rèn)證協(xié)議的“認(rèn)證協(xié)議配置選項(xiàng)”（Authentication-ProtocolConfigurationOption）的格式如下所示。傳輸時(shí)各域從左到右依次進(jìn)行。012301234567890123456789012345678901+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|Type|Length|Authentication-Protocol|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type3Length4Authentication-ProtocolC227(十六進(jìn)制)EAP2.2.數(shù)據(jù)包格式檔PPP幀中的protocol域表明協(xié)議類型為C227(PPPEAP)時(shí)，在PPP數(shù)據(jù)鏈路層幀的Information域中封裝且僅封裝一個(gè)PPPEAP數(shù)據(jù)包。EAP數(shù)據(jù)包的格式如下所示，傳輸時(shí)各域從左到右依次進(jìn)行。012301234567890123456789012345678901+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|Code|Identifier|Length|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|Data...+-+-+-+-+CodeCode域?yàn)橐粋€(gè)字節(jié)，標(biāo)識了EAP數(shù)據(jù)包的類型。EAP的code值指定如下：1Request2Response3Success4FailureIdentifierIdentifier域?yàn)橐粋€(gè)字節(jié)，輔助進(jìn)行response和request的匹配。LengthLength域?yàn)閮蓚€(gè)字節(jié)，表明了EAP數(shù)據(jù)包的長度，包括Code,Identifier,Length以及Data等各域。超出Length域范圍的字節(jié)應(yīng)該視為數(shù)據(jù)鏈路層填充（padding）,在接收時(shí)應(yīng)該被忽略掉。DataData域?yàn)?個(gè)或更多個(gè)字節(jié)。Data域的格式由Code域決定。2.2.1.Request和Response描述Request數(shù)據(jù)包由認(rèn)證者發(fā)送給對方。每一個(gè)Request有一個(gè)type域來表明正在請求的類型。認(rèn)證者必須發(fā)送一個(gè)Code域?yàn)?的EAP數(shù)據(jù)包（即Request）。在收到有效的Response數(shù)據(jù)包之前，或者在可選的重發(fā)計(jì)數(shù)器計(jì)數(shù)滿（expires）之前，必須發(fā)送另外的Request數(shù)據(jù)包。重新發(fā)送的Request必須保持Identifier的值不變以區(qū)別于新的Request。Data域的內(nèi)容依賴于Request的Type。對方必須發(fā)送一個(gè)Response作為對Request的應(yīng)答。Response必須僅在對接收到的Request作出應(yīng)答時(shí)發(fā)送，從不根據(jù)定時(shí)器重發(fā)。Response中的Identifier域必須與Request中的Identifier域匹配。實(shí)現(xiàn)須知：因?yàn)檎J(rèn)證過程經(jīng)常涉及到用戶輸入，在決定重發(fā)策略和認(rèn)證超時(shí)設(shè)定（timeout）時(shí)要謹(jǐn)慎。建議使用重發(fā)定時(shí)器為6秒，最大重傳次數(shù)為10次作為缺省值。人們可能希望某些特定情況下（例如，涉及到TokenCards的時(shí)候）超時(shí)設(shè)定能更長些。另外，對方必須準(zhǔn)備好在等待用戶輸入時(shí)悄悄丟棄所收到的重傳數(shù)據(jù)包。Request和Response數(shù)據(jù)包的格式如下所示，傳輸時(shí)各域從左到右依次進(jìn)行。012301234567890123456789012345678901+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|Code|Identifier|Length|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|Type|Type-Data...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-Code1forRequest;2forResponse.IdentifierIdentifier域?yàn)橐粋€(gè)字節(jié)。在等待Response時(shí)根據(jù)timeout而重發(fā)的Request的Identifier域必須相同。任何新的（非重發(fā)的）Request必須修改Identifier域。如果對方收到了重復(fù)的Request，并且已經(jīng)發(fā)送了對該Request的Response，則對方必須重發(fā)該Response。如果對方在給最初的Request發(fā)送Response之前收到重復(fù)的Request（也就是說，它在等待用戶輸入），它必須悄悄的丟棄重復(fù)的Request。LengthLength域?yàn)閮蓚€(gè)字節(jié)，表明EAP數(shù)據(jù)包的長度，包括Code,Identifier，Length，Type以及Type-Data等各域。超出Length域的字節(jié)應(yīng)視為數(shù)據(jù)鏈路層填充（padding），在接收時(shí)應(yīng)該被忽略掉。TypeType域?yàn)橐粋€(gè)字節(jié),該域表明了Request或Response的類型。在EAP的Request或Response中必須出現(xiàn)且僅出現(xiàn)一個(gè)Type。通常，Response中的Type域和Request中的Type域相同。但是，Response可以有一個(gè)Nak類型，表明Request中的Type不能被對方接受。當(dāng)對方發(fā)送Nak來響應(yīng)一個(gè)Request時(shí)，它可以暗示它所希望使用并且支持的認(rèn)證類型。各種Type的原始定義在本文檔后面的章節(jié)中給出。Type-DataType-Data域隨Request和相對應(yīng)的Response的Type的不同而不同。2.2.2.Success和Failure描述Success數(shù)據(jù)包由認(rèn)證者發(fā)送給對方，以確認(rèn)認(rèn)證成功。認(rèn)證者必須發(fā)送一個(gè)Code域?yàn)?的EAP數(shù)據(jù)包（即Success）。如果認(rèn)證者不能為對方進(jìn)行認(rèn)證（給一個(gè)或多個(gè)Request發(fā)送“不可接受”Response）,則實(shí)現(xiàn)必須發(fā)送一個(gè)Code域?yàn)?的EAP數(shù)據(jù)包（即Failure）。認(rèn)證者可能希望在發(fā)送Failure之前發(fā)送幾個(gè)Request以顧及到人為地打字錯(cuò)誤。實(shí)現(xiàn)須知：因?yàn)镾uccess和Failure數(shù)據(jù)包不被確認(rèn)，所以它們有可能丟失。對方必須顧及到這種情況。對方可以用一個(gè)網(wǎng)絡(luò)協(xié)議數(shù)據(jù)包（NetworkProtocolpacket）來作為可選的Success的暗示。同樣，收到LCPTerminate-Request可以視為收到Failure。Success和Failure數(shù)據(jù)包的格式如下所示。傳輸時(shí)各域從左到右依次進(jìn)行。012301234567890123456789012345678901+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|Code|Identifier|Length|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Code3Success;4Failure.IdentifierIdentifier域?yàn)橐粋€(gè)字節(jié)，輔助匹配Response應(yīng)答。Identifier域必須與其正在應(yīng)答的Response域中的Identifier域相匹配。Length43.最初Request/Respons中的Type類型本章定義了用于Request/Response中的各種EAPType的最初集合。更多的類型在以后的文檔中可以定義。Type域?yàn)橐粋€(gè)字節(jié)，標(biāo)識了EAPRequest或Response數(shù)據(jù)包的結(jié)構(gòu)。頭3種Type被認(rèn)為特殊情形的Type，其余的Type定義了認(rèn)證的交換流量。Nak類型僅對Response數(shù)據(jù)包有效，不允許把它放在Request中發(fā)送。Nak類型必須僅在對使用認(rèn)證Type的Request作出響應(yīng)時(shí)才發(fā)送。所有的EAP實(shí)現(xiàn)必須支持類型1-4,這些類型和類型5-6在本文檔中定義，以后的RFC將定義其它的類型。Blunk&VollbrechtStandardsTrack[Page8]

RFC2284EAPMarch19981Identity2Notification3Nak(Responseonly)4MD5-Challenge5One-TimePassword(OTP)(RFC1938)6GenericTokenCard3.1.Identity描述Identify類型用來查詢對方的身份。通常，認(rèn)證者發(fā)送該類型作為最初的Request。在期望與用戶進(jìn)行交互的場合還可以包括一條可選的可顯示的消息以給對方作出提示。必須對包含Type1(Identity)的Request發(fā)送Response以作出響應(yīng)。實(shí)現(xiàn)須知：對方可以通過用戶輸入獲得Identity。建議在Identity無效或者認(rèn)證失敗時(shí)認(rèn)證者重發(fā)（retry）IdentityRequest以顧及到用戶的打字錯(cuò)誤。建議在發(fā)送Failure應(yīng)答來結(jié)束認(rèn)證階段之前最少重發(fā)IdentityRequest3次。在發(fā)送新的IdentityRequest之前可以發(fā)送一個(gè)NotificationRequest來暗示認(rèn)證無效（可選地，失敗可以通過新的Identity中的消息來暗示）。Type1Type-Data該域可以包含一條可顯示的消息。Response用該域來返回Identity。如果Identity未知，該域長度應(yīng)該為0。該域不允許以null作為終結(jié)符。該域的長度由Request/Response中的Length域來決定，所以null是不必要的。Blunk&VollbrechtStandardsTrack[Page9]

RFC2284EAPMarch19983.2.Notification描述NotificationType可選地由認(rèn)證者用來給對方傳遞一條可顯示的消息。對方應(yīng)該把這條消息顯示給用戶，如果無法顯示則紀(jì)錄（log）該消息。使用它的目的是在某些緊急情況下（imperativenature）提供一條確認(rèn)通知（acknowledgednotification）。這樣的例子包括帶一個(gè)超時(shí)設(shè)定（expiration）的口令，OTP序列整數(shù)（接近0），認(rèn)證失敗警告等等。在大多數(shù)情況下，notification不應(yīng)該是必要的。Type2Type-DataType-Data域包含一條長度大于0字節(jié)的可顯示的消息。消息的長度由Request數(shù)據(jù)包中的Length域決定，消息不允許以null作為終結(jié)符。必須對帶有Type域?yàn)?（Notification）的Request發(fā)送一個(gè)Response。Response中的Type-Data域長度為0字節(jié)，Response應(yīng)該立即發(fā)送（與消息顯示或紀(jì)錄的方法無關(guān)）。3.3.Nak描述Nak僅對Response有效，當(dāng)Request中希望（desired）的認(rèn)證類型不可接受時(shí)，發(fā)送Nak作為對Request的響應(yīng)。AuthenticationType的值為大于等于4。Response中包含了對方所希望使用的認(rèn)證類型。Type3Type-Data該域必須包含一個(gè)唯一的字節(jié)，表明希望的認(rèn)證類型。Blunk&VollbrechtStandardsTrack[Page10]

RFC2284EAPMarch19983.4.MD5-Challenge描述MD5-ChallengeType與PPPCHAP協(xié)議（參考文獻(xiàn)[3]，制定了MD5算法）類似。更多的實(shí)現(xiàn)細(xì)節(jié)應(yīng)該參考PPP挑戰(zhàn)握手認(rèn)證協(xié)議RFC（參考文獻(xiàn)[3]）。Request包含一個(gè)對對方進(jìn)行“挑戰(zhàn)”的消息，必須對這樣的Request發(fā)送一個(gè)Response以作出應(yīng)答。Response可以為Type4（MD5-Challenge）或者Type3(Nak)。Nak應(yīng)答表明對方希望的認(rèn)證機(jī)制類型。所有的EAP實(shí)現(xiàn)必須支持MD5-Challenge機(jī)制。Type4Type-DataType-Data域的內(nèi)容如下所示。這些域的用法請參考PPP挑戰(zhàn)握手認(rèn)證協(xié)議（參考文獻(xiàn)[3]）。012301234567890123456789012345678901+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|Value-Size|Value...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|Name...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+3.5.One-TimePassword(OTP)描述One-TimePassword系統(tǒng)在“One-TimePasswordSystem（參考文獻(xiàn)[4]）”中定義。Request包含了一條包含一個(gè)OTP挑戰(zhàn)的可顯示的消息。必須對這樣的Request發(fā)送一個(gè)Response以作出應(yīng)答。Response必須為Type5(OTP)或Type3(Nak)。Nak應(yīng)答表明了對方希望使用的認(rèn)證機(jī)制類型。Type5Blunk&VollbrechtStandardsTrack[Page11]

RFC2284EAPMarch1998Type-DataType-Data域包含了該OTP挑戰(zhàn)，為Request中的可顯示消息。在Response中，該域用來存放來自O(shè)TP字典（參考文獻(xiàn)[4]）的6個(gè)詞（word）,該消息不允許以null作為終結(jié)符。該域的長度由Request/Reply數(shù)據(jù)包中的Length域決定。3.6.GenericTokenCard描述GenericTokenCardType是為要求用戶輸入的各種TokenCard實(shí)現(xiàn)定義的。Request包含一條ASCII文本消息，Reply包含認(rèn)證所必需的有關(guān)TokenCard信息。典型地，這些信息將是由用戶從TokenCard設(shè)備讀取并以ASCII文本輸入的信息。Type6Type-DataRequest中的Type-Data域包含了長度大于0的可顯示的消息。消息的長度由Request中的Length域決定，該消息不允許以null作為終結(jié)符。必須對包含Type為6（GenericTokenCard）的Request發(fā)送一個(gè)Response以作為響應(yīng)。Response包含了認(rèn)證所必需的TokenCard信息，信息的長度由Response數(shù)據(jù)包中的Length域決定。安全方面的考慮安全問題是本RFC的基本的主題。PPP內(nèi)各種認(rèn)證協(xié)議的相互作用高度依賴于實(shí)現(xiàn)。例如，一旦認(rèn)證失敗，某些實(shí)現(xiàn)并不終止鏈路，相反，實(shí)現(xiàn)把網(wǎng)絡(luò)層協(xié)議的流量限制為某一個(gè)經(jīng)篩選后的子集，這依次允許用戶有機(jī)會更新密鑰（secret）或者給網(wǎng)絡(luò)管理員發(fā)送郵件暗示出現(xiàn)了問題。Blunk&VollbrechtStandardsTrack[Page12]

RFC2284EAPMarch1998不提供失敗認(rèn)證的重試。但是，LCP狀態(tài)機(jī)可在任意時(shí)刻協(xié)商認(rèn)證協(xié)議，這就允許了新的嘗試。建議用于認(rèn)證的計(jì)數(shù)器直到成功認(rèn)證，或者隨后終止該失效鏈路后才進(jìn)行復(fù)位（reset）。不要求認(rèn)證是雙向的，也不要求兩個(gè)方向使用同一個(gè)協(xié)議。在每個(gè)方向是用不同的協(xié)議將是可很合理的。這當(dāng)然依賴于每個(gè)方向所使用的特定的協(xié)議在實(shí)踐中，在每個(gè)PPP服務(wù)器內(nèi)部或與之相關(guān)，事先不預(yù)期對特定名字的用戶使用多種方法來進(jìn)行認(rèn)證。如果這樣做將使用戶在一個(gè)可選認(rèn)證協(xié)議的集合中當(dāng)協(xié)商使用了最不安全的認(rèn)證類型（如使用PAP而不是EAP）時(shí)容易受到攻擊。相反，對于每一個(gè)命名用戶，應(yīng)該表明恰好只有一種方法對用戶進(jìn)行認(rèn)證。如果一個(gè)用戶需要在不同的環(huán)境下使用不同的認(rèn)證方法，應(yīng)該使用不同的身份（identities），每一個(gè)身份對應(yīng)唯一的認(rèn)證方法。參考文獻(xiàn)[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.Blunk&VollbrechtStandardsTrack[Page13]

RFC2284EAPMarch1998致謝本協(xié)議從DaveCarrel的AHA草案（即PPPCHAP協(xié)議，參考文獻(xiàn)[3]）中獲得靈感，BillSimpson提供了本文當(dāng)通篇使用的文檔樣板。AlRubens(Merit)也提供了很有價(jià)值的反饋信息。主席地址工作組可以通過現(xiàn)任主席聯(lián)系:KarlF.FoxAscendCommunications,Inc.655MetroPlaceSouth,Suite370DublinEMail:karl@Phone:+16147604041Fax:+16147604050作者地址LarryJ.BlunkMeritNetwork,Inc.4251PlymouthRd.,SuiteCAnnArbor,MI48105EMail:ljb@Phone:734-763-6056FAX:734-647-3185JohnR.VollbrechtMeritNetwork,Inc.4251PlymouthRd.,SuiteCAnnArborEMail:jrv@Phone:+1-313-763-1206FAX:+1-734-647-3185Blunk&VollbrechtStandardsTrack[Page14]

RFC2284EAPMarch1998完整的版權(quán)通告FullCopyrightStatementCopyright(C)TheInternetSociety(1998).AllRightsReserved.Thisdocumentandtra