專利名稱：一種網(wǎng)絡(luò)接入認證轉(zhuǎn)換的方法及系統(tǒng)和裝置的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及網(wǎng)絡(luò)通信領(lǐng)域，尤其涉及一種網(wǎng)絡(luò)接入認證轉(zhuǎn)換的方法及系統(tǒng) 和裝置。
背景技術(shù)：
網(wǎng)絡(luò)接入認證承載協(xié)議(Protocol for carrying Authentication for Network Access, PANA )是一種層3認證協(xié)議，這種層3的認證協(xié)議系統(tǒng)一般包括有PANA 客戶端(PANA Client, PaC )、 PANA認證代理(PANA Authentication Agent, PAA )、 認證服務器(Authentication Server, AS)以及控制點(Enforcement Point, EP)。 其中，PaC位于PANA協(xié)議的客戶端，用于獲得PAA所述網(wǎng)絡(luò)的訪問，并參與 PANA協(xié)議的認證過程；PAA位于訪問網(wǎng)絡(luò)的一端，用于負責與AS溝通以驗證 PaC認證證書的真?zhèn)危殛P(guān)聯(lián)于PaC的設(shè)備提供網(wǎng)絡(luò)訪問授權(quán)，此外還可以 通過建立或刪除訪問授權(quán)來對訪問的控制狀態(tài)進行更新；AS負責對PAA轉(zhuǎn)發(fā) 的PaC認證證書進行檢驗，并向PAA返回檢驗的結(jié)果和授權(quán)的參數(shù)；EP位于 訪問網(wǎng)絡(luò)上的一個節(jié)點，負責對出入PaC設(shè)備的數(shù)據(jù)包進行監(jiān)控，并依據(jù)從PAA 處獲得的監(jiān)控策略來對數(shù)據(jù)包進行過濾。
圖1示出了現(xiàn)有的層2認證協(xié)議的接入網(wǎng)架構(gòu)圖，在用戶駐地網(wǎng)處包含了 多個用戶駐地i殳備(Terminal Equipment, TE),如用戶駐地i殳備1至用戶駐地 設(shè)備N，其中，用戶駐地設(shè)備1和用戶駐地設(shè)備N之間還包括了多個用戶駐地 設(shè)備，這些用戶駐地設(shè)備通過駐地網(wǎng)關(guān)(Residential Gateway, RG)聯(lián)入IP匯 聚接入網(wǎng)中的接入節(jié)點(Access Node, AN),再通過IP匯聚接入網(wǎng)中的寬帶網(wǎng) 絡(luò)網(wǎng)關(guān)(Broadband Network Gateway, BNG )接入層2認證協(xié)議的AS中對TE 進行認證。
現(xiàn)有的用戶終端基本采用的是層2認證協(xié)議，如一種層2認證方法802.1x 和點對點協(xié)議(Point-to-Point Protocol, PPP)等，圖1中的TE接入層2的RG 或接入點(Access Point, AP )通過層2協(xié)議進行認證時，層2認證協(xié)議是無法
穿過層3的RG，即使是層2的RG也不支持對層2廣播信息的透傳。如果層2 協(xié)議認證能夠穿越層3的RG,但也不能夠穿越層3的AN或IP匯聚節(jié)點達到 PAA所在的IP邊緣節(jié)點，而隨著接入網(wǎng)絡(luò)的發(fā)展，層3的AN或IP匯聚節(jié)點是 下一代接入網(wǎng)的發(fā)展趨勢，這需要客戶端都能夠滿足層3認證協(xié)議的要求，但 是層3認證協(xié)議的PANA是一種新的認證協(xié)議，如果都采用PANA進行認證， 需要對所有的支持所有層2認證協(xié)議的客戶端進行升級或換成支持層3認證協(xié) 議的客戶端，但是通過這種升級或換代成本會很高。

發(fā)明內(nèi)容
鑒于上述現(xiàn)有技術(shù)所存在的問題，本發(fā)明實施例提供了 一種網(wǎng)絡(luò)接入認證 轉(zhuǎn)換的方法及系統(tǒng)和裝置。通過在網(wǎng)絡(luò)側(cè)中設(shè)置一認證中轉(zhuǎn)者，將接收的第一 認證協(xié)議消息轉(zhuǎn)換為第二認證協(xié)議消息到認證設(shè)備中進行認證，解決了層2認 證客戶端在層3協(xié)議中的認證過程，從而使用戶平滑的過渡到基于IP的下一代 接入網(wǎng)。
為了解決上述技術(shù)問題，本發(fā)明實施例提出了一種網(wǎng)絡(luò)接入認證轉(zhuǎn)換的方
法，該方法包括以下步驟
一種網(wǎng)絡(luò)接入認證轉(zhuǎn)換的方法，其特征在于，該方法包括以下步驟
網(wǎng)絡(luò)側(cè)設(shè)備將來自客戶端的第 一認證協(xié)議報文轉(zhuǎn)換為第二認證協(xié)議報文。
相應的，本發(fā)明實施例還提出了一種網(wǎng)絡(luò)節(jié)點設(shè)備，包括第一收發(fā)單元、
認證中轉(zhuǎn)單元和第二收發(fā)單元，其中
所述第 一收發(fā)單元用于接收來自客戶端發(fā)送的第 一認證協(xié)議消息并發(fā)送給
認證中轉(zhuǎn)單元；接收認證中轉(zhuǎn)單元轉(zhuǎn)換后的第一認證協(xié)議報文并轉(zhuǎn)發(fā)給客戶端； 所述認證中轉(zhuǎn)單元用于將所述第一認證協(xié)議消息轉(zhuǎn)換成認證設(shè)備所采用的
第二認證協(xié)議消息，將所述認證設(shè)備返回的第二認證協(xié)議報文轉(zhuǎn)換為第一認證
協(xié)議報文；
所述第二收發(fā)單元用于將所述認證中轉(zhuǎn)單元轉(zhuǎn)換后的第二認證協(xié)議消息發(fā) 送給認證設(shè)備；接收認證設(shè)備返回的第二認證協(xié)議報文并發(fā)送給認證中轉(zhuǎn)單元。
相應的，本發(fā)明實施例還提出了 一種網(wǎng)絡(luò)接入認證轉(zhuǎn)換系統(tǒng)，包括客戶端、 認證中轉(zhuǎn)者、認證設(shè)備，其中
所述客戶端用于與認證中轉(zhuǎn)者進行第 一認證協(xié)議的消息交互，并提供身份 認證材料給認證設(shè)備進行接入認證；
所述認證中轉(zhuǎn)者用于完成第 一認證協(xié)議的消息和第二認證協(xié)議的消息的轉(zhuǎn)
換功能，所述認證中轉(zhuǎn)者與客戶端進行第一認證協(xié)議的消息交互，與認證設(shè)備 進行第二認證協(xié)議的消息交互；
所述認證設(shè)備用于與所述認證中轉(zhuǎn)者進行第二認證協(xié)議的消息交互，為客 戶端所關(guān)聯(lián)的用戶或設(shè)備提供認證和授權(quán)。
實施本發(fā)明實施例，通過在網(wǎng)絡(luò)系統(tǒng)中設(shè)置認證中轉(zhuǎn)者，在接收客戶端的 第 一認證協(xié)議消息之后，將第 一認證協(xié)議消息轉(zhuǎn)換為第二認證協(xié)議消息發(fā)送到 認證設(shè)備中進行認證，解決了層2認證協(xié)議客戶端不能在下一代接入網(wǎng)進行認 證的問題。通過所述認證的方法，客戶端通過認證中轉(zhuǎn)者將第一認證協(xié)議消息 轉(zhuǎn)換為第二認證協(xié)議消息，通過第二認證協(xié)議消息的交互在認證設(shè)備中完成接 入認證。通過所述方法的實現(xiàn)，在網(wǎng)絡(luò)側(cè)將原有的層2認證協(xié)議消息統(tǒng)一轉(zhuǎn)換 為層3認證協(xié)議消息，從而解決了層2認證協(xié)議無法穿越層3的網(wǎng)絡(luò)節(jié)點的問 題，而用戶不需對原有的層2客戶端進行升級和換代就能完成，使用戶平滑的 過渡到基于IP下一代接入網(wǎng)。


圖1是現(xiàn)有的層2認證協(xié)議的接入網(wǎng)架構(gòu)示意圖2是本發(fā)明實施例中的網(wǎng)絡(luò)接入認證轉(zhuǎn)換的系統(tǒng)圖4是本發(fā)明實施例中的IP匯聚網(wǎng)認證中轉(zhuǎn)的應用場景圖； 圖5是本發(fā)明實施例中的認證中轉(zhuǎn)的另 一應用場景示意圖； 圖6是本發(fā)明實施例中的認證中轉(zhuǎn)的再一應用場景示意圖； 圖7是本發(fā)明實施例中的802. lx到PANA認證成功的認證轉(zhuǎn)換的流程圖； 圖8是本發(fā)明實施例中的802.1x到PANA重認證的認證轉(zhuǎn)換的流程圖； 圖9是本發(fā)明實施例中的PKM到PANA認證成功的認證轉(zhuǎn)換的流程圖； 圖10是本發(fā)明實施例中的PKM到PANA重認證的認證轉(zhuǎn)換的流程圖； 圖11是本發(fā)明實施例中802.lx到DHCP認證成功的認證轉(zhuǎn)換流程圖； 圖12是本發(fā)明實施例中802.1x到DHCP重認證的認證轉(zhuǎn)換的流程圖； 圖13是本發(fā)明實施例中PKM到DHCP認證成功的認證轉(zhuǎn)換的流程圖14是本發(fā)明實施例中PKM到DHCP重認證的認證轉(zhuǎn)換的流程圖。
具體實施例方式
本發(fā)明實施例提供了 一種網(wǎng)絡(luò)接入認證轉(zhuǎn)換的方法及其裝置。通過在網(wǎng)絡(luò) 節(jié)點設(shè)備中設(shè)置認證中轉(zhuǎn)者，通過認證中轉(zhuǎn)者將原有的層2認證協(xié)議消息統(tǒng)一 轉(zhuǎn)換為層3認證協(xié)議消息，從而解決了層2認證協(xié)議客戶端無法穿越層3的RG、 層3的AN或IP匯聚節(jié)點的問題，無需對原有的層2認證協(xié)議的客戶端進行升 級，使客戶端平滑的過渡到基于IP的下一代接入網(wǎng)，有效地保護了用戶的利益。
下面結(jié)合附圖詳細說明本發(fā)明的優(yōu)選實施例。
首先請參閱圖2，圖2示出了本發(fā)明實施例中的網(wǎng)絡(luò)接入認證轉(zhuǎn)換的系統(tǒng)圖， 該系統(tǒng)包括客戶端201、認i正中轉(zhuǎn)者202、認證者203、認證服務器204、層3 監(jiān)控點205以及層2接入控制器206,其中層2接入控制器206和層3監(jiān)控點 205都位于數(shù)據(jù)面中，其他的功能單元都位于控制面中。
客戶端201即為認證的申請者，客戶端201尋求獲得對認證者203所屬網(wǎng) 絡(luò)的訪問，并提供身份認證材料給認證服務器204參與認證協(xié)議的認證過程， 客戶端201關(guān)聯(lián)于一組在認證協(xié)議范圍內(nèi)證明客戶端201自身的設(shè)備或證書， 它可以是便攜式電腦、個人數(shù)字助理、移動電話、PC機或路由器等連接在網(wǎng)絡(luò) 上的終端設(shè)備，采用層2認證協(xié)議通過認證中轉(zhuǎn)者202參與認證者203所在的 支持層3認證協(xié)議的認證服務器204中進行認證，客戶端202采用的層2認證 協(xié)議包括了 802.1x、 PPP以及私鑰管理協(xié)議(Privacy Key Management, PKM) 等。
認證中轉(zhuǎn)者(Authentication Relay, AR) 202為層2認證的客戶端201提供 了層2認證協(xié)議消息到層3認證協(xié)議消息(如PANA協(xié)議或DHCP協(xié)議)間的 轉(zhuǎn)換，即將客戶端201發(fā)送過來的層2的認證協(xié)議的消息轉(zhuǎn)換為層3認證協(xié)議 的消息發(fā)送至認證者203,將認證者203發(fā)送過來的層3的認證協(xié)議的消息轉(zhuǎn)換 為層2認證協(xié)議的消息發(fā)送至客戶端201,并接收認證者下發(fā)的層3接入控制策 略和或/授權(quán)密鑰，并下發(fā)給層3監(jiān)控點205，從而建立客戶端201與認證者203 之間認證信息的交互。AR202代理認證的客戶端201與認證者203之間進行層3 協(xié)議信息的交互，利用客戶端201的地址標識完成對所述客戶端201的認證或 設(shè)備認證；可選地，上行方向，AR發(fā)送往認證者的報文的源地址可釆用用戶的 i也址標識。AR202中i史有第一收發(fā)單元、iU正中轉(zhuǎn)單元、第二收發(fā)單元以及重 認證模塊，其中所述第一收發(fā)單元用于接收來自客戶端201發(fā)送的層2認證 協(xié)議消息并發(fā)送給認證中轉(zhuǎn)單元；所述接收認證中轉(zhuǎn)單元轉(zhuǎn)換后的層2認證協(xié) 議報文并轉(zhuǎn)發(fā)給客戶端201;所述認證中轉(zhuǎn)單元用于將所述層2認證協(xié)議消息轉(zhuǎn) 換成認證者所采用的層3認證協(xié)議消息，將所述認證者203返回的層3認證協(xié) 議報文轉(zhuǎn)換為層2認證協(xié)議報文；所述第二收發(fā)單元用于將所述認證中轉(zhuǎn)單元 轉(zhuǎn)換后的層3認證協(xié)議消息發(fā)送給認證者203;接收認證者203返回的層3認證 協(xié)議報文并發(fā)送給認證中轉(zhuǎn)單元；所述重認證模塊用于在會話的過程中發(fā)起對 客戶端201的重認證過程。
認證者203為認證代理，即在PANA協(xié)議中的PAA，通過與AR202進行層 3認證協(xié)議消息的交互，代理客戶端201與認證服務器204進行AAA認證協(xié)議 (如RADIUS/Diameter) /API交互，為關(guān)聯(lián)于客戶端201的設(shè)備提供接入認證 和授權(quán)，此外，認證者203還可以通過建立或解除訪問授權(quán)對客戶端201處的 接入訪問控制狀態(tài)進行更新。若認證者203與認證服務器204位于同一網(wǎng)絡(luò)節(jié) 點時，認證者203與認證服務器之間204可以通過應用程序接口 (Application Program Interface, API)來進行數(shù)據(jù)傳遞，若認證者203與認證服務器204不位 于同一網(wǎng)絡(luò)節(jié)點時，認證者203與認證服務器204需要能攜帶認證、授權(quán)和計 費協(xié)議(Authentication, Authorization and Accounting, AAA)的諸如RADIUS 或Diameter來進行數(shù)據(jù)之間的傳遞。所述認證者203可位于網(wǎng)絡(luò)的IP邊緣節(jié)點 如BNG等網(wǎng)絡(luò)網(wǎng)關(guān)或網(wǎng)絡(luò)節(jié)點中。
認證服務器(Authentication Server, AS ) 204負責對客戶端201提供的認證 材料進行檢驗，并向客戶端201返回檢驗的結(jié)果和授權(quán)的參數(shù)，其中包括接入 控制策略和4受權(quán)密鑰等。認證服務器204可以與認證者203位于同一個網(wǎng)絡(luò)節(jié) 點中，也可以位于訪問網(wǎng)絡(luò)上一個專門的網(wǎng)絡(luò)節(jié)點或是因特網(wǎng)上的中心服務器。
層3監(jiān)控點(Layer 3 Enforcement Point, L3 EP) 205位于訪問網(wǎng)絡(luò)數(shù)據(jù)面 上的一個節(jié)點，負責對來自層2接入控制器206的數(shù)據(jù)包進行監(jiān)控，并依據(jù)從 認證者203處獲得的接入控制策略來對數(shù)據(jù)包進行非加密接入過濾或加密接入 過濾。若網(wǎng)絡(luò)底層缺乏安全保障，則必須采用加密接入過濾方式，層2接入控 制器206與L3 EP205之間需要建立層3安全聯(lián)盟，安全聯(lián)盟的建立可采用因特 網(wǎng)密鑰交換協(xié)議(Internet Key Exchange, IKE)等。在完成層3安全聯(lián)盟建立后，
可采用網(wǎng)絡(luò)層加密協(xié)議進行數(shù)據(jù)流的安全保護，加密數(shù)據(jù)流信息可采用IP網(wǎng)絡(luò)
安全協(xié)議(IP Security Protocol, IPSec)協(xié)議。若認證者203和L3 EP位于同一 節(jié)點，則它們之間僅需API進行數(shù)據(jù)交互即可，否則，則需要層2控制協(xié)議(Layer 2 Control Protocol, L2CP)或簡單網(wǎng)絡(luò)管理協(xié)議(Simple Network Management Protocol, SNMP)進行數(shù)據(jù)交互。L3 EP205通常是位于AR202與認證者203之 間的if各徑上。
層2接入控制器(Layer 2 Access Controller, L2 AC) 206位于訪問網(wǎng)絡(luò)數(shù)據(jù) 面上的一個節(jié)點，負責對來自客戶端201的數(shù)據(jù)包進行監(jiān)控，并依據(jù)從認證者 203處通過L3 EP205轉(zhuǎn)發(fā)的接入控制策略對數(shù)據(jù)包進行非加密接入過濾或加密 接入過濾。通常L2AC位于客戶端201與AR202之間的路徑上。若網(wǎng)絡(luò)底層缺 乏安全保障，則必須采用加密接入過濾方式，客戶端201與L2AC206之間需要 建立層2安全聯(lián)盟，層2安全聯(lián)盟建立可采用802.1U的四次握手協(xié)議(4WHS )， 或釆用802.16的三次握手協(xié)議(3WHS);在完成安全聯(lián)盟建立后，可采用鏈路 層加密協(xié)議進行數(shù)據(jù)流的安全保護，加密可采用802.11i鏈路層加密協(xié)議，或 802.16鏈路層加密協(xié)議。
L2 AC206與L3 EP205同時位于數(shù)據(jù)面相同節(jié)點時，其在構(gòu)造設(shè)備時可以 設(shè)置在同一個設(shè)備中，此時，該合一設(shè)備與客戶端201之間，既可以用層2安 全保護，也可以用層3安全保護。
下面結(jié)合圖3和圖2所示的網(wǎng)絡(luò)接入認證中轉(zhuǎn)的系統(tǒng)圖來說明圖3的客戶 端認證中轉(zhuǎn)過程中的IP會話周期示意圖，步驟如下
步驟S301:客戶端與AR之間進行層2認證協(xié)議消息的交互；
步驟S302: AR將客戶端的層2認證協(xié)議消息轉(zhuǎn)換為層3認證協(xié)議消息， 在客戶端沒有通過認證之前，AR可以代替每個客戶端申請臨時的IP地址或利 用自己的IP地址來支持層3認證；
步驟S303:認證者與AR之間進行層3認證協(xié)議消息的交互；
步驟S304:認證者將層3認證協(xié)議消息轉(zhuǎn)到認證、授權(quán)、計費(Authentication, Authorization and Accounting, AAA)協(xié)、i義與AS進4亍4言息之間的交互；
步驟S305:客戶端通過認證之后，客戶端為自己申請正式的IP地址，該IP 地址可以由AR或DHCP服務器提供，若該IP地址由AR提供，則該IP地址與 步驟S302中的AR代替每個客戶端申請時的IP地址——對應；步驟S306:客戶端通過認證之后，認證者將接入控制策略和授權(quán)密鑰下發(fā) 到L3 EP;
步驟S307: L2 AC與L3 EP之間建立層3的安全聯(lián)盟；
步驟S308: L3 EP將層3的接入控制策略轉(zhuǎn)換為層2的接入控制策略；
步驟S309:在L3EP中生成層2的授權(quán)密鑰；
步驟S31(h將轉(zhuǎn)換后的層2接入控制策略和層2的授權(quán)密鑰下發(fā)給L2AC; 步驟S311: L2AC與客戶端建立層2的安全聯(lián)盟；
步驟S312:客戶端與認證者所在的網(wǎng)絡(luò)建立數(shù)據(jù)流，該數(shù)據(jù)流通過L2AC 和L3 EP的安全過濾在接入網(wǎng)絡(luò)；
步驟S313: L2 AC通過監(jiān)聽到客戶端的數(shù)據(jù)包信息感知客戶端要下線，將 用戶下線的消息通知給AR，對于層2認證協(xié)議為802.1x時，L2AC感知客戶端 下線時，通過EAP下線(EAPoL-Logoff)才艮文通知給AR;
步驟S314: AR終止層3i/vi正會話，整個IP會話結(jié)束，對于層3 i^-i正協(xié)議 為PANA時，AR與認證者之間通過PANA終止請求或PANAN終止答復 (PANA-Termination誦Request或PANA-Termination-Answer)才艮文進4亍交互，以 此才艮文來終止PANA會話過程。若層3認證協(xié)議為動態(tài)主才幾配置協(xié)議(Dynamic Host Configuration Protocol, DHCP)認證協(xié)議時，AR發(fā)送DHCP釋放(DHCP Release)報文給認證者，以終止IP會話。
圖4至圖6示出了本發(fā)明實施例中的認證中轉(zhuǎn)的應用場景，圖4為認證中 轉(zhuǎn)應用在IP匯聚網(wǎng)中，在接入IP匯聚網(wǎng)中，中心局接入節(jié)點(Central Office AN， CO AN )或IP邊緣設(shè)備，如BNG或?qū)拵нh程接入服務器(Broadband Network Gateway, BRAS )上設(shè)有PAA和L3 EP，在層2的AN上設(shè)有AR和AC, IP 匯聚網(wǎng)中的邊緣設(shè)備僅支持PANA認證，但層2的客戶端可以通過AN上設(shè)有 的AR進行認證中轉(zhuǎn)，通過AR中轉(zhuǎn)后能支持不同認證方式的客戶端，如802.1x/f 終端、802.16終端、PPP終端等，而PANA終端通過IP匯聚網(wǎng)上設(shè)有的PAA直 接進行層三認證協(xié)議之間的交互。
圖5示出了本發(fā)明實施例中認證中轉(zhuǎn)的另一應用場景示意圖，在IP邊緣設(shè) 備，如BNG或BRAS上設(shè)置PAA和L3 EP，在RG或AP或基站(Base, Station, BS )上設(shè)置AR和L2 AC,則客戶端可以在認證的過程中由AR中轉(zhuǎn)認證協(xié)議 通過AN接入PAA處進行認證。
圖6示出了本發(fā)明實施例中認-〖正中轉(zhuǎn)的再一應用場景示意圖，家鄉(xiāng)地網(wǎng)絡(luò) 與拜訪地網(wǎng)絡(luò)通過IP邊緣設(shè)備之間的連接互通，在家鄉(xiāng)地網(wǎng)絡(luò)IP邊緣設(shè)備如 BNG或BRAS上設(shè)置PAA和L3EP,在拜訪地網(wǎng)絡(luò)IP邊緣處設(shè)備的BNG或BRAS 上設(shè)置AR，在拜訪地網(wǎng)絡(luò)的AN上設(shè)置AC。當客戶端由家鄉(xiāng)地網(wǎng)絡(luò)漫游至拜 訪地網(wǎng)絡(luò)時，通過拜訪地網(wǎng)絡(luò)BNG或BRAS上的AR進行認證中轉(zhuǎn)，回到家鄉(xiāng) 地網(wǎng)絡(luò)的IP邊緣設(shè)備上的PAA處進行認證。
下面根據(jù)圖3所示的會話周期和圖4至圖6所示的認證中轉(zhuǎn)應用場景來詳 細說明整個的認證中轉(zhuǎn)過程，圖7示出了本發(fā)明實施例中802.1x到PANA認證 成功的認證轉(zhuǎn)換的流程圖，具體步驟如下
步驟S701:客戶端發(fā)起EAPoL啟動(EAPoL-Start)報文，啟動可擴展認 i正十辦i義(Extensible Authentication Protocol, EAP ) i人i正過禾呈；
步驟S702: AR收到EAPoL-Start l艮文之后，觸發(fā)PANA客戶啟動才艮文 (PANA-Client-Initiation )來選擇提供認證授權(quán)服務的PAA;
步驟S703: PAA向AR發(fā)送PANA認證請求(PANA-Auth-Request)消息， 表明PAA可以提供認證的認證授權(quán)服務，并給AR配置本地使用的局部IP地址， 其中，S位置位；
步驟S704: AR發(fā)送PANA認證答復(PANA-Auth-Answer)消息給PAA, 表明AR已收到PANA-Auth-Request消息；
步驟S705: PAA向AR發(fā)出EAP身份請求(EAP-Request/Identity)消息， 該消息由PANA-Auth-Request報文攜帶；
步驟S706: AR將PANA-Auth-Request才艮文轉(zhuǎn)化為EAPoLl艮文，通過EAPoL 報文攜帶EAP-Request/Identity消息發(fā)送給客戶端；
步驟S707 : 客戶端發(fā)送EAPoL報文攜帶EAP身份應答 (EAP-Response/Identity)消息給AR;
步驟S708: AR將EAPoL報文轉(zhuǎn)換為PANA報文，通過PANA-Auth-Answer 報文攜帶EAP-Response/Identity消息給PAA;
步驟S709至步驟S710:進行EAP的認證方法(EAP Method)協(xié)商，以及 認證方法交互的過程，這里需要將客戶端關(guān)聯(lián)的身份證書信息傳遞多次至認證 服務器，通過在客戶端和AR以及AR和PAA之間進行認證協(xié)議消息的交互才 能完成整個客戶端的身份認證，在此過程中，AR將EAPoL報文轉(zhuǎn)換為PANA
才艮文進行認證轉(zhuǎn)換實現(xiàn)客戶端到PAA的身份認證，此過程直到EAP認證過程結(jié) 束；
步驟S711:用戶認證成功后，PAA向AR回復EAP認證成功(EAP success) 消息，并將EAP success消息和相應的EAP衍生密鑰封裝在PANA-Auth-Request 報文中，通過PANA-Auth-Request報文攜帶給AR，其中，C位置位；
步驟S712: AR收到PANA-Auth-Request報文后，向PAA發(fā)送 PANA-Auth-Answer報文來響應PAA，其中，C位置位；
步驟S713: AR將收到的EAP Success消息通過EAPoL報文攜帶發(fā)送至客 戶端。
在圖7所示的認證轉(zhuǎn)換流程圖中，通過將802.1x認證消息轉(zhuǎn)換為PANA消 息進行認證，先通過802.1x中的EAPoL消息攜帶相應的EAP消息到AR中去 后，AR與PAA之間通過PANA-Request和PAN A-Answer消息進行攜帶相應的 EAP消息完成對所述802.1x終端的認證過程，在認證成功之后，在整個IP會話 周期中，需要對客戶端進行重認證來延長會話周期，或其他原因也需要對客戶 端進行重認證。圖8中示出了本發(fā)發(fā)明實施例中的802.1x到PANA重認證的認 證轉(zhuǎn)換的流程圖，具體步驟如下
步驟S801:客戶端發(fā)起EAPoL-Start報文，重新啟動EAP認證；
步驟S802:當設(shè)定的握手定時器或重認證定時器超過設(shè)定的時間時，可以 通過AR發(fā)起重iU正；
步驟S801和步驟S802是重認證發(fā)起的兩種方式，可以由客戶端發(fā)起重認 證的過程，也可以通過AR發(fā)起重認證的過程。
步驟S803:通過步驟S801或步驟S802觸發(fā)重認證之后，AR與PAA之間 通過PANA通告請求(PANA-Notification-Request)才艮文請求重認證的過程，其 中A位置位；
步驟S804: PAA向AR發(fā)送PANA通告答復(PANA-Notification-Answer) 報文表明PAA已收到重認證的請求，其中A位置位；
步驟S805至步驟S813與圖7所述的步驟S705至步驟S813相同，這里不 再過多贅述。
以上圖7和圖8是客戶端通過802.1x認證協(xié)議進行認證中轉(zhuǎn)到PANA協(xié)議 的認證者進行i/v證的流程圖，當客戶端為802.16客戶端，采用PKM層2協(xié)議進
行認證時，客戶端認證中轉(zhuǎn)的流程圖如圖9所示中，具體步驟如下
步驟S901:客戶端發(fā)起PKM請求/EAP啟動(PKM-REQ/EAP-Start)報文， 啟動EAP認證過程；
步驟S902 : AR收到 PKM-REQ/EAP-Start報文之后，觸發(fā) PANA-Client-Initiation報文來選擇提供認證授權(quán)服務的PAA;
步驟S903: PAA向AR發(fā)送PANA-Auth-Request消息表明自己可以提供認 證的認證授權(quán)服務，并給AR配置本地使用的局部的IP地址，其中，S位置位；
步驟S904: AR發(fā)送PANA-Auth-Answer消息給PAA;
步驟S905: PAA向AR發(fā)出EAP-Request/Identity消息，該消息由 PANA-Auth-Request報文攜帶；
步驟S906: AR將PANA-Auth-Request報文轉(zhuǎn)化為PKM響應/EAP傳遞 (PKM-RSP/EAP-Transfer )報文，通過PKM-RSP/EAP-Transfer報文攜帶 EAP-Request/Identity消息發(fā)送給客戶端；
步驟S907:客戶端發(fā)送PKM-REQ/EAP-Transfer報文攜帶EAP身份應答 (EAP-Response/Identity)消息給AR;
步驟S908: AR將PKM報文轉(zhuǎn)換為PANA報文，通過PANA-Auth-Answer 報文攜帶EAP-Response/Identity消息給PAA;
步驟S909至步驟S910:進行EAP的認證方法(EAP Method)協(xié)商，以及 認證方法交互的過程，這里需要將客戶端關(guān)聯(lián)的身份證書信息傳遞多次至認證 服務器，通過在客戶端和AR以及AR和PAA之間進行認證協(xié)議消息的交互才 能完成整個客戶端的身份認證，在此過程中，AR將PKM報文轉(zhuǎn)換為PANA報 文進行認證轉(zhuǎn)換實現(xiàn)客戶端到PAA的身份認證，此過程直到EAP認證過程結(jié)束；
步驟S911:用戶認證成功后，PAA向AR回復EAP認證成功(EAP success) 消息，并將EAP success消息和相應的EAP衍生密鑰封裝在PANA-Auth-Request 報文中，通過PANA-Auth-Request報文攜帶給AR，其中C位置位；
步驟S912: AR收到PANA-Auth-Request才艮文后，向PAA發(fā)送 PANA-Auth-Answer報文，其中C位置位；
步驟S913: AR將收到的EAP Success消息通過PKM-RSP/EAP-Transfer報 文攜帶發(fā)送至客戶端。
在圖9所示的認證轉(zhuǎn)換流程圖中，通過將PKM認證消息轉(zhuǎn)換為PANA消息進行認證，在認證成功之后，在整個IP會話周期中，需要對客戶端進行重認證
來延長會話周期，或其他原因也需要對客戶端進行重認證。圖10中示出了本發(fā) 發(fā)明實施例中的802.16客戶端到PANA認證服務器中進行重認證的認證轉(zhuǎn)換的 流程圖，具體步驟如下
步驟S1001:客戶端發(fā)起PKM-REQ/EAP-Start報文，重新啟動EAP認證；
步驟S1002:當設(shè)定的握手定時器或重認證定時器超過設(shè)定的時間時，可以 通過AR發(fā)起重認證；
步驟S1001和步驟S1002是重i/vi正發(fā)起的兩種方式，可以由客戶端發(fā)起重 認證的過程，也可以通過AR發(fā)起重認證的過程。
步驟S1003:通過步驟S1001或步驟S1002觸發(fā)重認證之后，AR與PAA 之間通過PANA通告請求(PANA-Notification-Request )報文請求重認證的過程， 其中A位置位；
步驟S1004: PAA向AR發(fā)送PANA通告答復(PANA-Notification-Answer) 報文表明PAA已收到重認證的請求，其中A位置位；
步驟S1005至步驟S1013與圖9所述的步驟S905至步驟S913相同，這里
不再過多贅述。
以上是通過層3認證協(xié)議中的PANA協(xié)議在實現(xiàn)認證協(xié)議轉(zhuǎn)換后對層2客 戶端進行認證的，下面圖11至圖14描述了通過層3認證協(xié)議的DHCP協(xié)議實 現(xiàn)認證轉(zhuǎn)換后對層2客戶端進行認證的流程圖。
首先請參閱圖11,圖11示出了本發(fā)明實施例中802.1x到DHCP認證成功 的認證轉(zhuǎn)換流程圖，具體步驟如下
步驟S1101:客戶端發(fā)起EAPoL-Start報文，啟動EAP認證過程；
步驟Sl 102: AR收到EAPoL-Start報文之后，觸發(fā)DHCP發(fā)現(xiàn)報文(DHCP Discover)來選擇提供認證授權(quán)服務的DHCP認證者PAA和DHCP服務器，并 通過認證選項(auth-proto Option)表明AR所支持的認證才莫式；
步驟SI 103: PAA收到DHCP Discover報文之后，添加認證選項表明PAA 所支持的認證模式，并記錄下可將DHCP服務器為客戶端提供的未租借的IP地 址，并將該IP地址替換為一個供AR本地使用的局部IP地址，然后向AR轉(zhuǎn)發(fā) DHCP地址分配服務確認(DHCP Offer)消息；
步驟SI 104: AR發(fā)送DHCP地址分配請求(DHCP Request)消息響應PAA的DHCP Offer消息，DHCP Request消息中包含了 PAA支持的認證才莫式和PAA 提供的IP地址，表明AR已經(jīng)選擇能支持相應認證模式的PAA，并接受了 PAA 提供的IP地址；
步驟S1105: PAA收到DHCP Request消息之后，向AR發(fā)出 EEAP-Request/Identity消息，該消息由DHCP地址分配回應(DHCP Ack)報文
攜帶；
步驟SI 106: AR將DHCP Ack報文轉(zhuǎn)化為EAPoL報文，通過EAPoL報文 攜帶EAP-Request/Identity消息發(fā)送給客戶端；
步驟SI 107:客戶端發(fā)送EAPoL報文攜帶EAP-Response/Identity消息給AR;
步驟S1108: AR將EAPoL報文轉(zhuǎn)換為DHCP報文，通過DHCP Request報 文攜帶EAP-Response/Identity消息給PAA;
步驟S1109至步驟S1110:進行EAP的認證方法(EAP Method)協(xié)商，以 及認證方法交互的過程，這里需要將客戶端關(guān)聯(lián)的身份證書信息傳遞多次至認 證服務器，通過在客戶端和AR以及AR和PAA之間進行認證協(xié)議消息的交互 才能完成整個客戶端的身份認證，在此過程中，AR將EAPoL報文轉(zhuǎn)換為DHCP 報文進行認證轉(zhuǎn)換實現(xiàn)客戶端到PAA的身份認證，此過程直到EAP認證過程結(jié) 束；
步驟SI 111:客戶端認證成功后，PAA向AR回復EAP認證成功(EAP success )消息，其中，EAP success消息通過DHCP Ack才艮文攜帶，yiaddr為分 配的全局IP地址；
步驟S1112: AR收到DHCP Ack報文后，將DHCP Ack報文轉(zhuǎn)換為EAPoL 報文攜帶EAP success消息，并將攜帶有EAP success消息的EAPoL報文發(fā)送給 客戶端。
在圖11所示的認證轉(zhuǎn)換流程圖中，通過將802.1x認證消息轉(zhuǎn)換為DHCP 消息進行認證，在認證成功之后，在整個IP會話周期中，需要對客戶端進行重 認證來延長會話周期，或其他原因也需要對客戶端進行重認證。圖12中示出了 本發(fā)發(fā)明實施例中的802.1x到DHCP重認證的認證轉(zhuǎn)換的流程圖，具體步驟如 下
步驟S1201:客戶端發(fā)起EAPoL-Start報文，重新啟動EAP認證； 步驟S1202:當設(shè)定的握手定時器或重認證定時器超過設(shè)定的時間時，可以
通過AR發(fā)起重iU正；
步驟S1201和步驟S1202是重認證發(fā)起的兩種方式，可以由客戶端發(fā)起重 i人證的過程，也可以通過AR發(fā)起重認證的過程。
步驟S1203: AR發(fā)送DHCP地址分配請求(DHCP Request)消息給PAA， DHCP Request消息中包含了 PAA支持的認證模式和PAA提供的IP地址，表明 AR已經(jīng)選擇能支持相應認證模式的PAA,并接受了 PAA提供的IP地址；
步驟S1204至步驟S1211與圖11所述的步驟S1105至步驟S1112相同，這 里不再過多贅述。
以上圖11和圖12是客戶端通過802.1x認證協(xié)議進行認證中轉(zhuǎn)到DHCP協(xié) 議的認i正者中進行認i正的流程圖，當客戶端為802.16客戶端，采用PKM層2 協(xié)議進行認證時，客戶端認證中轉(zhuǎn)的流程圖如圖13所示中，具體步驟如下
步驟S1301:客戶端發(fā)起PKM-REQ/EAP-Start報文，啟動EAP認證過程；
步驟1302: AR收到PKM-REQ/EAP-Start報文之后，觸發(fā)DHCP Discover 報文來選擇提供認證授權(quán)服務的DHCP認證者PAA和DHCP服務器，并通過認 證選項(auth-proto Option)表明AR所支持的iU正才莫式；
步驟S1303: PAA收到DHCP Discover報文之后，添加認證選項表明PAA 所支持的認證模式，并記錄下可將DHCP服務器為客戶端提供的未租借的IP地 址，并將該IP地址替換為一個供AR本地使用的局部IP地址，然后向AR轉(zhuǎn)發(fā) DHCP Offer消息；
步驟SI304: AR發(fā)送DHCP Request消息響應PAA的DHCP Offer消息， DHCP Request消息中包含了 PAA支持的認證模式和PAA提供的IP地址，表明 AR已經(jīng)選擇能支持相應認證模式的PAA，并接受了 PAA提供的IP地址；
步驟SI305: PAA收到DHCP Request消息之后，向AR發(fā)出 EEAP-Request/Identity消息，該消息由DHCP Ack報文攜帶；
步驟SI306: AR將DHCP Ack報文轉(zhuǎn)化為PKM-RSP/EAP-Transfer報文， 通過PKM-RSP/EAP-Transfer報文攜帶EAP-Request/Identity消息發(fā)送給客戶端；
步驟S1307 : 客戶端發(fā)送PKM-REQ/EAP-Transfer報文攜帶 EAP-Response/Identity消息給AR;
步驟S1308: AR將PKM報文轉(zhuǎn)換為DHCP報文，通過DHCP Request報文 攜帶EAP-Response/Identity消息給PAA;
步艱i S1309至步驟S1310:進4亍EAP的iU正方法(EAP Method )協(xié)商，以 及認證方法交互的過程，這里需要將客戶端關(guān)聯(lián)的身份證書信息傳遞多次至認 證服務器，通過在客戶端和AR以及AR和PAA之間進行認證協(xié)議消息的交互 才能完成整個客戶端的身份認證，在此過程中，AR將PKM報文轉(zhuǎn)換為DHCP 報文進行認證轉(zhuǎn)換實現(xiàn)客戶端到PAA的身份認證，此過程直到EAP認證過程結(jié) 束；
步驟S1311:客戶端認證成功后，PAA向AR回復EAP認證成功(EAP success)消息，其中，EAP success消息通過DHCP Ack報文攜帶，yiaddr為分 配的全局IP;也址；
步驟S1312: AR收到DHCP Ack報文后，將DHCP Ack報文轉(zhuǎn)換為EAPoL 報文攜帶EAP success消息，并將攜帶有EAP success消息的 PKM-RSP/EAP-Transfer才艮文發(fā)送給客戶端。
在圖13所示的認證轉(zhuǎn)換流程圖中，通過將PKM認證消息轉(zhuǎn)換為DHCP消 息進行認證，在認證成功之后，在整個IP會話周期中，需要對客戶端進行重認 證來延長會話周期，或其他原因也需要對客戶端進行重認證。圖14中示出了本 發(fā)發(fā)明實施例中的802.16客戶端到DHCP認證服務器中進行重認證的認證轉(zhuǎn)換 的流程圖，具體步驟如下
步驟S1401:客戶端發(fā)起PKM-REQ/EAP-Start報文，重新啟動EAP認證；
步驟S1402:當設(shè)定的握手定時器或重認證定時器超過設(shè)定的時間時，可以 通過AR發(fā)起重iU正；
步驟S1401和步驟S1402是重認證發(fā)起的兩種方式，可以由客戶端發(fā)起重 認證的過程，也可以通過AR發(fā)起重認證的過程。
步驟S1403: AR發(fā)送DHCP地址分配請求(DHCP Request)消息給PAA， DHCP Request消息中包含了 PAA支持的認證模式和PAA提供的IP地址，表明 AR已經(jīng)選擇能支持相應認證模式的PAA,并接受了 PAA提供的IP地址；
步驟S1404至步驟S1411與圖13所述的步驟S1305至步驟S1312相同，這 里不再過多贅述。
以上圖8至圖14描述了層2認證協(xié)議中的PKM和802.1x認證轉(zhuǎn)換的過程， 以此類推，客戶端發(fā)送的層2中的認證協(xié)議消息通過AR實現(xiàn)了層2認證協(xié)議消 息向?qū)?認證協(xié)議消息的轉(zhuǎn)換，到層3的認證服務器中進行認證。在認證授權(quán)
之后，所述認證中轉(zhuǎn)系統(tǒng)的數(shù)據(jù)面需要通過L2 AC和L3 EP來控制數(shù)據(jù)面的數(shù) 據(jù)流，L2AC與L3 EP之間要建立層3的安全聯(lián)盟，L2AC與客戶端之間建立層 2的安全聯(lián)盟，通過PAA生成的接入控制策略下發(fā)給L3 EP之后，L3 EP將所 述接入控制策略下發(fā)至L2 AC。如果數(shù)據(jù)面所處的網(wǎng)絡(luò)層缺乏安全保障，則需 要采用加密接入過濾方式建立數(shù)據(jù)流的安全保障。
綜上所述，本發(fā)明實施例通過在網(wǎng)絡(luò)節(jié)點設(shè)備中設(shè)置一認證中轉(zhuǎn)者，在接 收客戶端的層2認證協(xié)議消息之后，將層2認證協(xié)議消息統(tǒng)一轉(zhuǎn)換為層3認證 協(xié)議消息發(fā)送至認證者中進行認證，解決了層2認證協(xié)議客戶端不能在下一代 接入網(wǎng)的認證問題。通過在網(wǎng)絡(luò)匯聚網(wǎng)的接入?yún)R聚網(wǎng)和其他網(wǎng)絡(luò)節(jié)點中設(shè)置認 證中轉(zhuǎn)者，解決了層2認證協(xié)議消息無法穿透層3的RG或AN等進行認證的問 題，通過所述認證的方法，客戶端能夠通過層2的認證方法到下一代接入網(wǎng)的 認證者中進行認證，從而實現(xiàn)客戶端在認證服務器中的認證和授權(quán)，而用戶不 需對客戶端進行升級和換代就能完成。在認證接入系統(tǒng)中采用承載與控制相分 離的技術(shù)，通過層3監(jiān)控點和層2接入控制器監(jiān)數(shù)據(jù)面上控數(shù)據(jù)流信息，在認 證通過后，通過層3監(jiān)控點向?qū)?接入控制器下發(fā)接入控制策略保障了出入客 戶端數(shù)據(jù)流信息的安全。
以上所揭露的僅為本發(fā)明實施例中的一種較佳實施例而已，當然不能以此 來限定本發(fā)明之權(quán)利范圍，因此依本發(fā)明權(quán)利要求所作的等同變化，仍屬本發(fā) 明所涵蓋的范圍。
權(quán)利要求
1、一種網(wǎng)絡(luò)接入認證轉(zhuǎn)換的方法，其特征在于，該方法包括以下步驟網(wǎng)絡(luò)側(cè)設(shè)備將來自客戶端的第一認證協(xié)議報文轉(zhuǎn)換為第二認證協(xié)議報文。
2、 如權(quán)利要求1所述的網(wǎng)絡(luò)接入認證轉(zhuǎn)換的方法，其特征在于，進一步包括認證完成后，網(wǎng)絡(luò)側(cè)設(shè)備將來自于認證設(shè)備的第二認證協(xié)議報文轉(zhuǎn)換為第 一認證協(xié)議報文，并發(fā)送給所述客戶端。
3、如權(quán)利要求1或2所述的網(wǎng)絡(luò)接入認證轉(zhuǎn)換的方法，其特征在于， 所述第一認證協(xié)議為層2認證協(xié)議； 所述第二認證協(xié)議為層3認證協(xié)議。
4、 如權(quán)利要求3所述的網(wǎng)絡(luò)接入認證轉(zhuǎn)換的方法，其特征在于，所述網(wǎng)絡(luò) 側(cè)設(shè)備為認證中轉(zhuǎn)者。
5、 如權(quán)利要求4所述的網(wǎng)絡(luò)接入認證轉(zhuǎn)換的方法，其特征在于，所述層2 認證協(xié)議為802.1x認證協(xié)議或PKM認證協(xié)議，所述層3認證協(xié)議為網(wǎng)絡(luò)接入認 證承載協(xié)議或動態(tài)主#幾配置協(xié)議。
6、 如權(quán)利要求4所述的網(wǎng)絡(luò)接入認證轉(zhuǎn)換的方法，其特征在于，所述認證 過程中，認證中轉(zhuǎn)者代替客戶端申請IP地址，為客戶端分配IP地址，所述認證 中轉(zhuǎn)者為客戶端分配的IP地址與所述認證中轉(zhuǎn)者代替客戶端申請的IP地址——對應。
7、 如權(quán)利要求4所述的網(wǎng)絡(luò)接入認證轉(zhuǎn)換的方法，其特征在于，進一步包括所述認證成功后，認證者下發(fā)第一接入控制策略和/或第一授權(quán)密鑰給層3 監(jiān)控點； 層3監(jiān)控點將第一接入控制策略轉(zhuǎn)換為第二接入控制策略，和/或才艮據(jù)第一授權(quán)密鑰生成第二授權(quán)密鑰；將所述第二接入控制策略和/或第二授權(quán)密鑰下發(fā)給層2接入控制器。
8、 如權(quán)利要求7所述的網(wǎng)絡(luò)接入認證轉(zhuǎn)換的方法，其特征在于，進一步包括認證者下發(fā)第一接入控制策略和/或第一授權(quán)密鑰后，層3監(jiān)控點與層2接 入控制器建立第 一安全聯(lián)盟；層3監(jiān)控點下發(fā)第二接入控制策略和/或第二授權(quán)密鑰后，層2接入控制器 與客戶端建立第二安全聯(lián)盟。
9、 如權(quán)利要求8所述的網(wǎng)絡(luò)接入認證轉(zhuǎn)換的方法，其特征在于，進一步包括所述認證成功后，層3監(jiān)控點根據(jù)第一接入控制策略對來自層2接入控制 器的數(shù)據(jù)包進行監(jiān)控，層2接入控制器根據(jù)第二接入控制策略對來自客戶端的 數(shù)據(jù)包進行監(jiān)控。
10、 如權(quán)利要求9所述的網(wǎng)絡(luò)接入認證轉(zhuǎn)換的方法，其特征在于，進一步包 括層2接入控制器檢測到客戶端下線后，通知認證中轉(zhuǎn)者客戶端下線，認證中 轉(zhuǎn)者得知客戶端下線后終止層3認證會話。
11、 如權(quán)利要求4所述的網(wǎng)絡(luò)接入認證轉(zhuǎn)換的方法，其特征在于，進一步 包括所述認證成功后，認證中轉(zhuǎn)者在會話過程中將第一認證協(xié)議消息轉(zhuǎn)換為第 二認證協(xié)議消息到認證者中進行重認證。
12、 一種網(wǎng)絡(luò)節(jié)點設(shè)備，其特征在于，包括第一收發(fā)單元、認證中轉(zhuǎn)單元 和第二收發(fā)單元，其中所述第一收發(fā)單元用于接收來自客戶端發(fā)送的第一認證協(xié)議消息并發(fā)送給 認i正中轉(zhuǎn)單元；接收iU正中轉(zhuǎn)單元轉(zhuǎn)換后的第一iU正協(xié)議才艮文并轉(zhuǎn)發(fā)給客戶端； 所述認證中轉(zhuǎn)單元用于將所述第一認證協(xié)議消息轉(zhuǎn)換成認證設(shè)備所采用的 第二認證協(xié)議消息，將所述認證設(shè)備返回的第二認證協(xié)議報文轉(zhuǎn)換為第一認證 協(xié)議報文；所述第二收發(fā)單元用于將所述認證中轉(zhuǎn)單元轉(zhuǎn)換后的第二認證協(xié)議消息發(fā) 送給認證設(shè)備；接收認證設(shè)備返回的第二認證協(xié)議報文并發(fā)送給認證中轉(zhuǎn)單元。
13、 如權(quán)利要求12所述的網(wǎng)絡(luò)節(jié)點設(shè)備，其特征在于， 所述第一認證協(xié)議為層2認證協(xié)議； 所述第二認證協(xié)議為層3認證協(xié)議。
14、 如權(quán)利要求13所述的網(wǎng)絡(luò)節(jié)點設(shè)備，其特征在于，所述網(wǎng)絡(luò)節(jié)點設(shè)備 還包括一重認證4莫塊，用于在會話過程中對客戶端發(fā)起重認證過程。
15、 如權(quán)利要求14所述的網(wǎng)絡(luò)節(jié)點設(shè)備，其特征在于，所述網(wǎng)絡(luò)節(jié)點設(shè)備 為寬帶網(wǎng)絡(luò)網(wǎng)關(guān)、寬帶遠程接入服務器、接入節(jié)點、駐地網(wǎng)關(guān)、接入點和基站 中的任一個。
16、 一種網(wǎng)絡(luò)接入認證轉(zhuǎn)換系統(tǒng)，其特征在于，包括客戶端、認證中轉(zhuǎn)者、 認證設(shè)備，其中所述客戶端用于與認證中轉(zhuǎn)者進行第 一認證協(xié)議的消息交互，并提供身份 認證材料給認證設(shè)備進行接入認證；所述認證中轉(zhuǎn)者用于完成第一認證協(xié)議的消息和第二認證協(xié)議的消息的轉(zhuǎn) 換功能，所述認證中轉(zhuǎn)者與客戶端進行第一認證協(xié)議的消息交互，與認證設(shè)備 進行第二認證協(xié)議的消息交互；所述認證設(shè)備用于與所述認證中轉(zhuǎn)者進行第二認證協(xié)議的消息交互，為客 戶端所關(guān)聯(lián)的用戶或設(shè)備提供認證和授權(quán)。
17、如權(quán)利要求16所述的網(wǎng)絡(luò)接入認證轉(zhuǎn)換系統(tǒng)，其特征在于, 所述第一認證協(xié)議為層2認證協(xié)議； 所述第二認證協(xié)議為層3認證協(xié)議。
18、如權(quán)利要求17所述的網(wǎng)絡(luò)接入認證轉(zhuǎn)換系統(tǒng)，其特征在于，所述認證 設(shè)備包括認證者和認證服務器所述認證者用于與所述認證中轉(zhuǎn)者進行層3認證協(xié)議的消息交互，為客戶 端所關(guān)聯(lián)的用戶或設(shè)備提供接入認證和授權(quán)；二V^正月^分備用丁通遼》人卞認證，并通過認證者向客戶端返回認證結(jié)果和第一接入控制策略
19、如權(quán)利要求18所述的網(wǎng)絡(luò)接入認證轉(zhuǎn)換系統(tǒng)，其特征在于，所述網(wǎng)絡(luò) 接入認證轉(zhuǎn)換系統(tǒng)還包括層3監(jiān)控點和層2接入控制器，其中所述層3監(jiān)控點根據(jù)所述認證服務器下發(fā)的第一接入控制策略對來自層2 接入控制器的數(shù)據(jù)包進行監(jiān)控，將第 一接入控制策略轉(zhuǎn)換為第二接入控制策略， 和/或根據(jù)第 一授權(quán)密鑰生成第二授權(quán)密鑰；所述層2接入控制器根據(jù)第二接入控制策略對來自客戶端的數(shù)據(jù)包進行監(jiān)控。
20、如權(quán)利要求19所述的網(wǎng)絡(luò)接入認證轉(zhuǎn)換系統(tǒng)，其特征在于，所述層3 監(jiān)控點和層2接入控制器為同一個節(jié)點設(shè)備。
全文摘要
本發(fā)明公開了一種網(wǎng)絡(luò)接入認證轉(zhuǎn)換的方法，該方法包括以下步驟網(wǎng)絡(luò)側(cè)設(shè)備將來自客戶端的第一認證協(xié)議報文轉(zhuǎn)換為第二認證協(xié)議報文。本發(fā)明還公開了一種網(wǎng)絡(luò)節(jié)點設(shè)備及網(wǎng)絡(luò)接入認證轉(zhuǎn)換系統(tǒng)，通過實施本發(fā)明實施例，通過在本發(fā)明實施例中的認證中轉(zhuǎn)者將層2認證協(xié)議轉(zhuǎn)換為層3認證協(xié)議在認證者中轉(zhuǎn)者所在的網(wǎng)絡(luò)中進行認證授權(quán)，解決了在下一代接入網(wǎng)中進行認證的問題。
文檔編號H04L12/54GK101355485SQ200710029380
公開日2009年1月28日 申請日期2007年7月26日 優(yōu)先權(quán)日2007年7月26日
發(fā)明者鄭若濱 申請人:華為技術(shù)有限公司