專利名稱：一種點(diǎn)到點(diǎn)協(xié)議強(qiáng)制認(rèn)證方法和裝置的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及網(wǎng)絡(luò)管理技術(shù)，尤其是一種點(diǎn)到點(diǎn)協(xié)議強(qiáng)制認(rèn)證方法和裝置。
背景技術(shù)：
PPP協(xié)議(Point to Point Protocol，點(diǎn)到點(diǎn)協(xié)議)是TCP/IP協(xié)議(Transmission Control Protocol/Internet Protocol，傳輸控制協(xié)議/互聯(lián)網(wǎng)協(xié)議)中數(shù)據(jù)鏈路層的協(xié)議，提供一種標(biāo)準(zhǔn)的方式在點(diǎn)對(duì)點(diǎn)的鏈路上傳輸多個(gè)網(wǎng)絡(luò)層協(xié)議的數(shù)據(jù)包，PPP協(xié)議包括各種NCP協(xié)議(Network Control Protocol，網(wǎng)絡(luò)控制協(xié)議)，如IPCP協(xié)議(InternetProtocol Control Protocol，網(wǎng)絡(luò)協(xié)議控制協(xié)議)和IPXCP(IPX ControlProtocol，IPX控制協(xié)議)等；LCP協(xié)議族(Link Control Protocol，鏈路控制協(xié)議)；以及驗(yàn)證協(xié)議族(Authentication Protocol)，如CHAP協(xié)議(Challenge Handshake Authentication Protocol，挑戰(zhàn)握手驗(yàn)證協(xié)議)、PAP協(xié)議(Password Authentication Protocol，密碼驗(yàn)證協(xié)議)等。
其中，NCP協(xié)議主要用來協(xié)商鏈路上傳輸?shù)臄?shù)據(jù)包的格式和類型；LCP協(xié)議主要用來建立、拆除和監(jiān)控PPP數(shù)據(jù)鏈路；驗(yàn)證協(xié)議主要用來提供網(wǎng)絡(luò)安全的保證。
為了在點(diǎn)對(duì)點(diǎn)的鏈路上建立通信，PPP鏈路的兩端必須發(fā)送LCP數(shù)據(jù)包進(jìn)行數(shù)據(jù)鏈路的測試和配置，等鏈路建立起來之后，還可能需要進(jìn)行端的驗(yàn)證。然后，PPP發(fā)送NCP數(shù)據(jù)包選擇并配置一個(gè)或多個(gè)網(wǎng)絡(luò)層協(xié)議，當(dāng)所選擇的網(wǎng)絡(luò)層協(xié)議配置成功之后，每個(gè)網(wǎng)絡(luò)層發(fā)送的數(shù)據(jù)包就可以在鏈路上傳送了。鏈路一直保持連接狀態(tài)，直到有明確的LCP或者NCP數(shù)據(jù)包斷開鏈路，或某些外來的事件發(fā)生，如定時(shí)器超時(shí)或者網(wǎng)絡(luò)管理員干涉。
在驗(yàn)證階段，由于運(yùn)營商采用AAA服務(wù)器(AuthenticationAuthorization and Accounting，認(rèn)證、授權(quán)和計(jì)費(fèi))所支持的認(rèn)證類型存在差異，有的不支持PAP，CHAP，或者M(jìn)SCHAP1(Microsoft CHAPversion1，微軟CHAP協(xié)議版本1)、MSCHAP2(Microsoft CHAP version2，微軟CHAP協(xié)議版本2)的情況，所以，只有在對(duì)端采用的驗(yàn)證協(xié)議跟AAA服務(wù)器所支持的認(rèn)證類型相一致的情況下，才有可能通過驗(yàn)證；否則，就會(huì)出現(xiàn)在AAA服務(wù)器上存在該帳號(hào)而實(shí)際未通過驗(yàn)證的現(xiàn)象。
針對(duì)上述情形，現(xiàn)有的解決方案一是基于物理位置，如用戶接入設(shè)備的槽位、子卡、端口、VLAN(Virtual Local Area Network，虛擬局域網(wǎng))或PVC(Permanent Virtual Connection，永久虛連接)來配置點(diǎn)到點(diǎn)認(rèn)證方案，使之與AAA服務(wù)器所支持的認(rèn)證類型相一致。為了減少配置工作量可將同一物理端口下一些VLAN或PVC，組成一個(gè)邏輯接口一起進(jìn)行配置。所有通過該接口接入的用戶，PPP協(xié)商過程的LCP階段，設(shè)備使用該接口下配置的認(rèn)證方案與用戶進(jìn)行協(xié)商。通過該接口上來的用戶在LCP階段協(xié)商的認(rèn)證類型就是接口所配置的認(rèn)證類型，例如接口下配置的認(rèn)證類型是PAP，則通過該接口上來的用戶在LCP階段協(xié)商的認(rèn)證類型就是PAP。
如圖1所示的用戶撥號(hào)上網(wǎng)流程示意圖，取PPPoE(PPP overEthernet，以太網(wǎng)承載PPP協(xié)議)用戶為例，假設(shè)在接口下配置了CHAP認(rèn)證類型，則具體過程如下首先，進(jìn)行PPPoE協(xié)商；其次，進(jìn)行PPP協(xié)商，具體包括下述步驟(1)用戶端和PPPoE服務(wù)器之間進(jìn)行點(diǎn)到點(diǎn)的LCP協(xié)商，建立鏈路層通信，同時(shí)協(xié)商使用CHAP認(rèn)證方式；(2)PPPoE服務(wù)器發(fā)送Challenge報(bào)文給認(rèn)證用戶端，提供一個(gè)128bit的Challenge；(3)用戶端收到Challenge報(bào)文后，將密碼和Challenge做MD5算法后，發(fā)送Response響應(yīng)報(bào)文給PPPoE服務(wù)器；(4)PPPoE服務(wù)器發(fā)送含Challenge、Challenge-Password和用戶名的Access-Request(認(rèn)證請(qǐng)求報(bào)文)到AAA服務(wù)器，由AAA服務(wù)器進(jìn)行認(rèn)證。
(5)AAA服務(wù)器根據(jù)用戶信息判斷用戶是否合法，然后回應(yīng)Access-Accept/Access-Reject(認(rèn)證成功/失敗報(bào)文)到PPPoE服務(wù)器；如果認(rèn)證成功，攜帶協(xié)商參數(shù)，以及用戶的相關(guān)業(yè)務(wù)屬性給用戶授權(quán)；如果認(rèn)證失敗，則流程到此結(jié)束；(6)PPPoE服務(wù)器將認(rèn)證結(jié)果(Success/Failure)返回給用戶端；(7)用戶進(jìn)行NCP(如IPCP)協(xié)商，通過PPPoE服務(wù)器獲取到規(guī)劃的IP地址等參數(shù)；(8)認(rèn)證如果成功，PPPoE服務(wù)器發(fā)起計(jì)費(fèi)開始請(qǐng)求給AAA服務(wù)器；(9)AAA服務(wù)器回應(yīng)計(jì)費(fèi)開始請(qǐng)求報(bào)文；用戶此時(shí)通過認(rèn)證，并且獲得了合法的權(quán)限，可以正常開展網(wǎng)絡(luò)業(yè)務(wù)。
目前，網(wǎng)絡(luò)用戶與網(wǎng)絡(luò)接入服務(wù)設(shè)備相連，通過這些設(shè)備實(shí)現(xiàn)網(wǎng)絡(luò)連接。網(wǎng)絡(luò)用戶又屬于不同的網(wǎng)絡(luò)運(yùn)營商，屬于不同的域。在目前的網(wǎng)絡(luò)運(yùn)營管理系統(tǒng)中，網(wǎng)絡(luò)運(yùn)營商不需要真正的NAS(Network AccessServer，網(wǎng)絡(luò)接入服務(wù)設(shè)備)，只需要向真正擁有該設(shè)備的網(wǎng)絡(luò)服務(wù)供應(yīng)商租用設(shè)備即可。多個(gè)網(wǎng)絡(luò)運(yùn)營商可能租用同一個(gè)網(wǎng)絡(luò)服務(wù)供應(yīng)商的設(shè)備的同一個(gè)接口。由于運(yùn)營商采用的AAA服務(wù)器所支持的認(rèn)證類型存在差異，有的不支持PAP，CHAP，或者M(jìn)SCHAP1、MSCHAP2的情況。如圖2所示，運(yùn)營商A和運(yùn)營商B分別采用AAA服務(wù)器1和AAA服務(wù)器2，這兩臺(tái)用戶認(rèn)證服務(wù)器所支持的認(rèn)證類型分別為PAP和CHAP。按照現(xiàn)有的技術(shù)方案一，如果接口下配置的PPP強(qiáng)制認(rèn)證方案為MSCHAP1或者M(jìn)SCHAP2，那么分屬于運(yùn)營商A和運(yùn)營商B的網(wǎng)絡(luò)用戶user1@dom1和user2@dom2雖然在各自的AAA服務(wù)器上有賬號(hào)，但均不能驗(yàn)證通過，從而導(dǎo)致用戶無法開展網(wǎng)絡(luò)業(yè)務(wù)；如果接口下配置的點(diǎn)到點(diǎn)強(qiáng)制認(rèn)證方案為PAP或者CHAP，那么用戶user1@dom1和user2@dom2最多只有一個(gè)用戶能夠驗(yàn)證成功。也就是說，只有在LCP階段協(xié)商好的認(rèn)證類型與AAA服務(wù)器所支持的認(rèn)證類型相一致的情況下才有可能通過驗(yàn)證，否則就會(huì)出現(xiàn)在AAA服務(wù)器上存在著該賬號(hào)而實(shí)際上驗(yàn)證不過的現(xiàn)象。所以，現(xiàn)有的技術(shù)方案一在圖2所示的情況下，為了使得用戶均能驗(yàn)證通過，只能由網(wǎng)絡(luò)服務(wù)供應(yīng)商給每個(gè)網(wǎng)絡(luò)運(yùn)營商分配不同的接口，這樣不利于網(wǎng)絡(luò)服務(wù)供應(yīng)商的利益；且在大容量的BRAS(Broadband Remote Access Server，寬帶遠(yuǎn)程接入服務(wù)器)中，給每個(gè)運(yùn)營商分配不同的接口是不現(xiàn)實(shí)的。
現(xiàn)有的解決方案二是通過為用戶端配置點(diǎn)到點(diǎn)強(qiáng)制認(rèn)證類型的方式來實(shí)現(xiàn)，在用戶的客戶端撥號(hào)軟件上配置點(diǎn)到點(diǎn)認(rèn)證類型，設(shè)備接口上配置認(rèn)證類型為自適應(yīng)。這樣PPP協(xié)商中LCP階段時(shí)用戶端指定使用用戶端撥號(hào)軟件上配置的認(rèn)證類型，而設(shè)備接受用戶端的要求。例如，AAA服務(wù)器支持的認(rèn)證類型是CHAP，則配置用戶端的認(rèn)證類型是CHAP。這一方案的前提是用戶必須知道其所要認(rèn)證的AAA服務(wù)器支持的認(rèn)證類型，即運(yùn)營商必須預(yù)先告訴用戶AAA服務(wù)器所支持的認(rèn)證類型，因此就存在一定的網(wǎng)絡(luò)安全隱患；另外，該方案不夠靈活，如果運(yùn)營商需要切換用戶認(rèn)證的AAA服務(wù)器，必須通知用戶根據(jù)新的服務(wù)器所支持的認(rèn)證類型進(jìn)行調(diào)整，使用戶端的認(rèn)證類型與切換后的認(rèn)證服務(wù)器所支持的認(rèn)證類型保持一致，否則，將導(dǎo)致用戶無法驗(yàn)證通過。

發(fā)明內(nèi)容
基于上述情形，本發(fā)明提供了一種點(diǎn)到點(diǎn)協(xié)議強(qiáng)制認(rèn)證方法和裝置。靈活、安全地解決了由于運(yùn)營商采用AAA服務(wù)器所支持的認(rèn)證類型存在差異而導(dǎo)致用戶無法通過驗(yàn)證的問題；無須為每個(gè)網(wǎng)絡(luò)運(yùn)營商分配不同接口，從而維護(hù)網(wǎng)絡(luò)服務(wù)供應(yīng)商的利益。
本發(fā)明中的點(diǎn)到點(diǎn)協(xié)議強(qiáng)制認(rèn)證方法，包括步驟A、鏈路進(jìn)行LCP協(xié)商，獲得LCP協(xié)商的認(rèn)證類型；B、比較LCP協(xié)商的認(rèn)證類型和域下配置的點(diǎn)到點(diǎn)強(qiáng)制認(rèn)證類型，進(jìn)行點(diǎn)到點(diǎn)協(xié)議認(rèn)證。
其中，步驟B包括具體步驟B1、若LCP協(xié)商的認(rèn)證類型和域下配置的點(diǎn)到點(diǎn)強(qiáng)制認(rèn)證類型相同，發(fā)送認(rèn)證請(qǐng)求報(bào)文到AAA服務(wù)器進(jìn)行認(rèn)證；B2、若LCP協(xié)商的認(rèn)證類型和域下配置的點(diǎn)到點(diǎn)強(qiáng)制認(rèn)證類型不同，將域下配置的點(diǎn)到點(diǎn)強(qiáng)制認(rèn)證類型下發(fā)，進(jìn)行LCP重協(xié)商，獲得LCP重協(xié)商的認(rèn)證類型，并與域下配置的點(diǎn)到點(diǎn)強(qiáng)制認(rèn)證類型進(jìn)行比較，二者相同，則發(fā)送認(rèn)證請(qǐng)求報(bào)文到AAA服務(wù)器進(jìn)行認(rèn)證。
本發(fā)明方法中，域下配置的點(diǎn)到點(diǎn)強(qiáng)制認(rèn)證類型為AAA服務(wù)器所支持的認(rèn)證類型。
所述LCP重協(xié)商是由鏈路控制協(xié)議通過交換配置報(bào)文，將協(xié)商的類型更換為所述下發(fā)的域下配置的點(diǎn)到點(diǎn)強(qiáng)制認(rèn)證類型。
所述AAA服務(wù)器接收到認(rèn)證請(qǐng)求報(bào)文后，進(jìn)行認(rèn)證，認(rèn)證通過后，返回認(rèn)證成功報(bào)文。
本發(fā)明的點(diǎn)到點(diǎn)協(xié)議強(qiáng)制認(rèn)證裝置，在用戶端與AAA服務(wù)器之間包括接口模塊與比較模塊，接口模塊與用戶端和比較模塊相連，比較模塊又與AAA服務(wù)器相連，接口模塊，與用戶端進(jìn)行LCP協(xié)商，并發(fā)送比較請(qǐng)求消息給比較模塊；比較模塊，將LCP協(xié)商的認(rèn)證類型與域下配置的點(diǎn)到點(diǎn)強(qiáng)制認(rèn)證類型進(jìn)行比較，并發(fā)送認(rèn)證請(qǐng)求報(bào)文給AAA服務(wù)器進(jìn)行認(rèn)證。
其中，若LCP協(xié)商的認(rèn)證類型與域下配置的認(rèn)證類型不同，則所述的比較模塊將域下配置的點(diǎn)到點(diǎn)強(qiáng)制認(rèn)證類型下發(fā)給所述的接口模塊。
所述的接口模塊根據(jù)下發(fā)的認(rèn)證類型與用戶端進(jìn)行LCP重協(xié)商，鏈路再次建立后，所述的接口模塊再次發(fā)送比較請(qǐng)求消息給所述的比較模塊進(jìn)行處理。
其中，所述比較請(qǐng)求消息中攜帶有LCP協(xié)商的認(rèn)證類型。
本發(fā)明提供的方法和裝置，實(shí)現(xiàn)了針對(duì)不同運(yùn)營商的網(wǎng)絡(luò)用戶的認(rèn)證管理。這不僅有利于網(wǎng)絡(luò)服務(wù)供應(yīng)商開展業(yè)務(wù)，能夠把同一個(gè)接口租給不同的網(wǎng)絡(luò)運(yùn)營商，同時(shí)也是構(gòu)建大容量BRAS系統(tǒng)不可或缺的一項(xiàng)技術(shù)。


圖1為現(xiàn)有技術(shù)中的用戶撥號(hào)上網(wǎng)流程圖；圖2為現(xiàn)有技術(shù)中的用戶撥號(hào)上網(wǎng)示意圖；圖3為本發(fā)明中點(diǎn)到點(diǎn)協(xié)議強(qiáng)制認(rèn)證的流程圖；圖4為本發(fā)明中點(diǎn)到點(diǎn)協(xié)議強(qiáng)制認(rèn)證裝置圖。
具體實(shí)施例方式
同一個(gè)域下的用戶具有相同的認(rèn)證方法，計(jì)費(fèi)方法，DNS(DomainName Server，域名服務(wù)器)的IP地址，缺省的業(yè)務(wù)屬性，該域?qū)?yīng)的AAA服務(wù)器的IP地址和服務(wù)端口號(hào)，當(dāng)系統(tǒng)失去計(jì)費(fèi)能力時(shí)是否允許用戶在線的策略等。
在域下配置點(diǎn)到點(diǎn)強(qiáng)制認(rèn)證類型與AAA服務(wù)器所支持的認(rèn)證類型相一致，可通過下發(fā)命令進(jìn)行配置。網(wǎng)絡(luò)用戶撥號(hào)上網(wǎng)根據(jù)域所對(duì)應(yīng)的AAA服務(wù)器的IP地址和服務(wù)端口號(hào)，到相應(yīng)的AAA服務(wù)器上去認(rèn)證。
下面結(jié)合圖3，具體說明點(diǎn)到點(diǎn)協(xié)議強(qiáng)制認(rèn)證方法的具體實(shí)現(xiàn)過程步驟1，LCP協(xié)商階段接口下配置認(rèn)證類型為auto，用戶撥號(hào)上網(wǎng)，LCP通過交換配置報(bào)文，進(jìn)行LCP協(xié)商，建立鏈路并確定認(rèn)證類型；步驟2，認(rèn)證階段把LCP協(xié)商階段確定的認(rèn)證類型和該用戶所在域下配置的點(diǎn)到點(diǎn)強(qiáng)制認(rèn)證類型比較，如果二者相同，發(fā)送認(rèn)證請(qǐng)求報(bào)文到AAA服務(wù)器進(jìn)行認(rèn)證處理；如果二者不同，則將域下配置的點(diǎn)到點(diǎn)強(qiáng)制認(rèn)證類型下發(fā)，進(jìn)入LCP重協(xié)商階段；
步驟3，LCP重協(xié)商階段LCP通過交換配置報(bào)文，進(jìn)行LCP重協(xié)商，協(xié)商的認(rèn)證類型為步驟2中下發(fā)的域下配置的點(diǎn)到點(diǎn)強(qiáng)制認(rèn)證類型，鏈路建立后，再次進(jìn)入步驟2的認(rèn)證階段。
這時(shí)，LCP階段協(xié)商的認(rèn)證類型和該用戶所在域下配置的點(diǎn)到點(diǎn)強(qiáng)制認(rèn)證類型相同，發(fā)送認(rèn)證請(qǐng)求報(bào)文到AAA服務(wù)器進(jìn)行認(rèn)證處理。
由于，在域下配置點(diǎn)到點(diǎn)強(qiáng)制認(rèn)證類型與該AAA服務(wù)器所支持的認(rèn)證類型相一致，因此，用戶能夠通過AAA服務(wù)器的驗(yàn)證，順利開展網(wǎng)絡(luò)業(yè)務(wù)。
同時(shí)，本發(fā)明還提供了一種點(diǎn)到點(diǎn)強(qiáng)制認(rèn)證裝置，如圖4所示，在用戶端與AAA服務(wù)器之間包括接口模塊與比較模塊。
用戶端與接口模塊之間進(jìn)行LCP協(xié)商建立鏈路并協(xié)商認(rèn)證類型；鏈路建立后，接口模塊發(fā)送比較請(qǐng)求消息給比較模塊，該比較請(qǐng)求消息中攜帶有LCP協(xié)商的認(rèn)證類型；比較模塊將LCP階段協(xié)商的認(rèn)證類型與域下配置的點(diǎn)到點(diǎn)強(qiáng)制認(rèn)證類型進(jìn)行比較，若LCP階段協(xié)商的認(rèn)證類型與域下配置的點(diǎn)到點(diǎn)強(qiáng)制認(rèn)證類型相同，比較模塊則發(fā)送認(rèn)證請(qǐng)求報(bào)文給AAA服務(wù)器，進(jìn)行認(rèn)證；若LCP階段協(xié)商的認(rèn)證類型與域下配置的點(diǎn)到點(diǎn)強(qiáng)制認(rèn)證類型不同，則比較模塊將域下配置的點(diǎn)到點(diǎn)強(qiáng)制認(rèn)證類型下發(fā)給接口模塊；接口模塊根據(jù)下發(fā)的認(rèn)證類型與用戶端進(jìn)行LCP重協(xié)商，鏈路再次建立后，由接口模塊發(fā)送比較請(qǐng)求消息給比較模塊。此時(shí)，LCP階段協(xié)商的認(rèn)證類型與域下配置的點(diǎn)到點(diǎn)強(qiáng)制認(rèn)證類型相同，比較模塊將發(fā)送認(rèn)證請(qǐng)求報(bào)文給AAA服務(wù)器，進(jìn)行認(rèn)證。
AAA服務(wù)器認(rèn)證成功后，將返回認(rèn)證成功報(bào)文給接口模塊，接口模塊將認(rèn)證成功報(bào)文返回到用戶端。至此，用戶通過認(rèn)證，獲得合法的權(quán)限，可以正常開展網(wǎng)絡(luò)業(yè)務(wù)。
以上所述，僅為本發(fā)明較佳的具體實(shí)施方式
，但本發(fā)明的保護(hù)范圍并不局限于此，任何熟悉該技術(shù)的人在本發(fā)明所揭露的技術(shù)范圍內(nèi)，可輕易想到的變化或替換，都應(yīng)涵蓋在本發(fā)明的保護(hù)范圍之內(nèi)。
權(quán)利要求
1.一種點(diǎn)到點(diǎn)協(xié)議強(qiáng)制認(rèn)證方法，其特征在于，包括步驟A、鏈路兩端進(jìn)行LCP協(xié)商，獲得LCP協(xié)商的認(rèn)證類型；B、比較LCP協(xié)商的認(rèn)證類型和域下配置的點(diǎn)到點(diǎn)強(qiáng)制認(rèn)證類型，進(jìn)行點(diǎn)到點(diǎn)協(xié)議認(rèn)證。
2.根據(jù)權(quán)利要求1所述的點(diǎn)到點(diǎn)協(xié)議強(qiáng)制認(rèn)證方法，其特征在于，步驟B包括具體步驟B1、若LCP協(xié)商的認(rèn)證類型和域下配置的點(diǎn)到點(diǎn)強(qiáng)制認(rèn)證類型相同，發(fā)送認(rèn)證請(qǐng)求報(bào)文到AAA服務(wù)器進(jìn)行認(rèn)證；B2、若LCP協(xié)商的認(rèn)證類型和域下配置的點(diǎn)到點(diǎn)強(qiáng)制認(rèn)證類型不同，將域下配置的點(diǎn)到點(diǎn)強(qiáng)制認(rèn)證類型下發(fā)，進(jìn)行LCP重協(xié)商，獲得LCP重協(xié)商的認(rèn)證類型，并與域下配置的點(diǎn)到點(diǎn)強(qiáng)制認(rèn)證類型進(jìn)行比較，二者相同，則發(fā)送認(rèn)證請(qǐng)求報(bào)文到AAA服務(wù)器進(jìn)行認(rèn)證。
3.根據(jù)權(quán)利要求1或2所述的點(diǎn)到點(diǎn)協(xié)議強(qiáng)制認(rèn)證方法，其特征在于，所述域下配置的點(diǎn)到點(diǎn)強(qiáng)制認(rèn)證類型為AAA服務(wù)器所支持的認(rèn)證類型。
4.根據(jù)權(quán)利要求2所述的點(diǎn)到點(diǎn)協(xié)議強(qiáng)制認(rèn)證方法，所述LCP重協(xié)商是由鏈路控制協(xié)議通過交換配置報(bào)文，將協(xié)商的類型更換為所述下發(fā)的域下配置的點(diǎn)到點(diǎn)強(qiáng)制認(rèn)證類型。
5.根據(jù)權(quán)利要求2所述的點(diǎn)到點(diǎn)協(xié)議強(qiáng)制認(rèn)證方法，其特征在于，所述AAA服務(wù)器接收到認(rèn)證請(qǐng)求報(bào)文后，進(jìn)行認(rèn)證，認(rèn)證通過后，返回認(rèn)證成功報(bào)文。
6.一種點(diǎn)到點(diǎn)協(xié)議強(qiáng)制認(rèn)證裝置，其特征在于，在用戶端與AAA服務(wù)器之間包括接口模塊與比較模塊，接口模塊與用戶端和比較模塊相連，比較模塊又與AAA服務(wù)器相連，接口模塊，與用戶端進(jìn)行LCP協(xié)商，并發(fā)送比較請(qǐng)求消息給比較模塊；比較模塊，將LCP協(xié)商的認(rèn)證類型與域下配置的點(diǎn)到點(diǎn)強(qiáng)制認(rèn)證類型進(jìn)行比較，并發(fā)送認(rèn)證請(qǐng)求報(bào)文到AAA服務(wù)器進(jìn)行認(rèn)證。
7.根據(jù)權(quán)利要求6所述的點(diǎn)到點(diǎn)協(xié)議強(qiáng)制認(rèn)證裝置，其特征在于，若LCP協(xié)商的認(rèn)證類型與域下配置的認(rèn)證類型不同，則所述的比較模塊將域下配置的點(diǎn)到點(diǎn)強(qiáng)制認(rèn)證類型下發(fā)給所述的接口模塊。
8.根據(jù)權(quán)利要求7所述的點(diǎn)到點(diǎn)協(xié)議強(qiáng)制認(rèn)證裝置，其特征在于，所述的接口模塊根據(jù)下發(fā)的認(rèn)證類型與用戶端進(jìn)行LCP重協(xié)商，鏈路再次建立后，所述的接口模塊再次發(fā)送比較請(qǐng)求消息給所述的比較模塊進(jìn)行處理。
9.根據(jù)權(quán)利要求6所述的點(diǎn)到點(diǎn)協(xié)議強(qiáng)制認(rèn)證裝置，其特征在于，所述比較請(qǐng)求消息中攜帶有LCP協(xié)商的認(rèn)證類型。
全文摘要
本發(fā)明公開了一種點(diǎn)到點(diǎn)協(xié)議強(qiáng)制認(rèn)證方法，包括如下步驟A.進(jìn)行LCP協(xié)商，獲得LCP協(xié)商的認(rèn)證類型；B.比較LCP協(xié)商的認(rèn)證類型和域下配置的點(diǎn)到點(diǎn)協(xié)議強(qiáng)制認(rèn)證類型，進(jìn)行點(diǎn)到點(diǎn)協(xié)議認(rèn)證。本發(fā)明還公開了一種點(diǎn)到點(diǎn)協(xié)議強(qiáng)制認(rèn)證裝置。本發(fā)明能夠?qū)Σ煌\(yùn)營商的用戶進(jìn)行認(rèn)證管理，有利于網(wǎng)絡(luò)服務(wù)供應(yīng)商開展業(yè)務(wù)，并且是構(gòu)建大容量寬帶遠(yuǎn)程接入服務(wù)器系統(tǒng)不可或缺的一項(xiàng)技術(shù)。
文檔編號(hào)H04L12/24GK1859415SQ200610034898
公開日2006年11月8日 申請(qǐng)日期2006年4月4日 優(yōu)先權(quán)日2006年4月4日
發(fā)明者張軼炯, 韓濤, 夏開軍 申請(qǐng)人:華為技術(shù)有限公司