專利名稱：一種802.1x認證方法
技術(shù)領(lǐng)域：
本發(fā)明一般涉及網(wǎng)絡(luò)通信技術(shù)，特別涉及一種在網(wǎng)絡(luò)通信認證系統(tǒng)中實現(xiàn)的基于MAC(介質(zhì)訪問控制)或端口的802.1x認證方法。
背景技術(shù)：
IEEE 802 LAN(局域網(wǎng))協(xié)議定義的局域網(wǎng)通常不提供接入認證，一般來說，只要用戶能接入局域網(wǎng)控制設(shè)備，如Hub(集線器)或LanSwitch(局域網(wǎng)交換機)，用戶就可以訪問局域網(wǎng)中的設(shè)備或資源。但是對于諸如電信接入等應(yīng)用，LAN(局域網(wǎng))設(shè)備提供者希望能對用戶的接入進行控制，為此產(chǎn)生了基于端口的網(wǎng)絡(luò)接入控制(Port Based network access control)需求。802.1x協(xié)議提供了一種用戶接入認證的手段，用以對用戶的認證進行控制。
圖1是常規(guī)的802.1x認證體系的結(jié)構(gòu)示意圖。從圖1中可以看出，IEEE802.1x認證體系包括三部分認證申請系統(tǒng)；認證執(zhí)行系統(tǒng)；以及認證服務(wù)器系統(tǒng)。
認證申請系統(tǒng)與認證系統(tǒng)之間運行由IEEE 802.1x定義的EAPOL協(xié)議(承載于局域網(wǎng)的擴展認證協(xié)議)，在EAP(擴展認證協(xié)議)幀中封裝了認證數(shù)據(jù)。認證系統(tǒng)與認證服務(wù)器之間同樣運行EAP協(xié)議，只是該協(xié)議承載于其他高層次的協(xié)議中，如Radius(遠端撥入用戶驗證服務(wù)協(xié)議)，以便穿越復(fù)雜的網(wǎng)絡(luò)到達認證服務(wù)器(EAP中繼)。
802.1x協(xié)議規(guī)定，認證執(zhí)行系統(tǒng)在將EAPOL傳遞到認證服務(wù)器時不能修改EAP幀的內(nèi)容。而且，如果認證系統(tǒng)與認證服務(wù)器系統(tǒng)處于同一個設(shè)備中，則不需要進行EAP中繼。
認證申請系統(tǒng)可以是任何接入LAN(局域網(wǎng))的設(shè)備，為支持基于端口的接入控制，只需使認證申請系統(tǒng)支持EAPOL協(xié)議即可，運行EAPOL協(xié)議的實體稱為認證申請端口接入實體。
認證執(zhí)行系統(tǒng)內(nèi)部有受控端口(Controlled Port)和非受控端口(Uncontrolled Port)。非受控端口始終處于雙向連通狀態(tài)，主要用來傳遞EAPOL協(xié)議幀，以保證客戶端始終可以發(fā)出或接受認證。受控端口只有在認證通過的狀態(tài)下才打開，用于傳遞網(wǎng)絡(luò)資源和服務(wù)。受控端口可配置為雙向受控和僅輸入受控兩種方式，以適應(yīng)不同的應(yīng)用環(huán)境。
認證服務(wù)器系統(tǒng)接受認證系統(tǒng)傳遞來的認證需求，并在認證完成后將認證結(jié)果下發(fā)給認證執(zhí)行系統(tǒng)，以完成對端口的管理。由于EAP協(xié)議較為靈活，除了IEEE 802.1x定義的端口狀態(tài)外，認證服務(wù)器系統(tǒng)實際上還可以用于認證和下發(fā)更多用戶相關(guān)的信息，如VLAN(虛擬局域網(wǎng))、QOS(業(yè)務(wù)質(zhì)量)、加密認證密鑰、DHCP(動態(tài)主機控制協(xié)議)響應(yīng)等。
圖2是常規(guī)IEEE 802.1x認證機制的原理示意圖。如圖2所示，常規(guī)的IEEE 802.1x認證包括以下主要過程(1)認證發(fā)起(用戶和設(shè)備均可發(fā)起)；(2)Radius(遠端撥入用戶驗證服務(wù))服務(wù)器接受認證，并返回認證結(jié)果；(3)認證通過，打開受控端口；(4)認證包丟失重傳；(5)重新認證(根據(jù)時間)；以及(6)退出已認證態(tài)(用戶“下線”)。由于其具體過程在本領(lǐng)域中都是公知技術(shù)，故省略說明。
IEEE 802.1x作為一種認證方式，其封裝開銷小，容易實現(xiàn)基于時間的計費，而且由于操作系統(tǒng)內(nèi)置有認證客戶端的支持，因此使用非常方便。但是，由于目前市場上推出的基于802.1X的認證方式都是基于端口的認證方式。在該認證方式下，如果該端口被認證通過，則該端口下的所有用戶都可以上網(wǎng)。但是，如果一個接入端口下接多個用戶，則不能分別對各用戶進行認證控制，從而不能很好地滿足企業(yè)和集團用戶的需求。

發(fā)明內(nèi)容
因此，本發(fā)明就是針對現(xiàn)有技術(shù)中存在的上述問題而做出的，其目的是提供一種基于MAC(介質(zhì)訪問控制)地址或端口的802.1X認證方法，該方法既可以對同一端口下接的多個用戶分別進行認證，也可以通過配置提供基于端口的802.1X認證。
為了實現(xiàn)上述目的，本發(fā)明提供了一種802.1x認證方法，該方法包括以下步驟1)所述網(wǎng)絡(luò)認證執(zhí)行系統(tǒng)根據(jù)用戶報文的認證類型來控制外部認證設(shè)備對用戶報文的認證；以及2)所述網(wǎng)絡(luò)認證執(zhí)行系統(tǒng)根據(jù)外部認證設(shè)備對所述用戶報文的認證情況以控制所述用戶報文的轉(zhuǎn)發(fā)處理。
所述步驟1)中進一步包括判斷所述用戶報文的認證類型是基于端口的認證還是基于MAC地址的認證的步驟。
在所述用戶報文的認證類型是基于端口的認證的情況下，所述步驟2)進一步包括對用戶報文所屬端口是否通過外部認證設(shè)備的認證進行判斷的步驟。
在用戶報文所屬端口通過外部認證設(shè)備的認證的情況下，所述網(wǎng)絡(luò)認證執(zhí)行系統(tǒng)將對用戶報文所屬端口的地址進行學(xué)習(xí)，并且對地址學(xué)習(xí)成功的報文進行轉(zhuǎn)發(fā)處理，對地址學(xué)習(xí)不成功的報文進行丟棄；在用戶報文所屬端口未通過外部認證設(shè)備的認證的情況下，所述網(wǎng)絡(luò)認證執(zhí)行系統(tǒng)將直接丟棄所述用戶報文。
在上述方法中，所述對用戶報文所屬端口進行地址學(xué)習(xí)的步驟進一步包括限制允許學(xué)習(xí)來自端口的MAC地址的數(shù)目以及將學(xué)習(xí)到的地址與所述網(wǎng)絡(luò)認證執(zhí)行系統(tǒng)的內(nèi)部連接標(biāo)識進行綁定的步驟。
另一方面，在所述用戶報文的認證類型是基于MAC地址的認證的情況下，所述步驟2)包括禁止學(xué)習(xí)所述用戶報文的所述端口的地址的步驟。
進一步，所述步驟2)包括對用戶報文的MAC地址是否通過外部認證設(shè)備的認證進行判斷的步驟。
在用戶報文的MAC地址通過外部認證設(shè)備的認證的情況下，所述網(wǎng)絡(luò)認證執(zhí)行系統(tǒng)將保存所述用戶報文的MAC地址，以使所述用戶報文可以通過網(wǎng)絡(luò)認證執(zhí)行系統(tǒng)進行發(fā)送和接收；在用戶報文的MAC地址通過外部認證設(shè)備的認證的情況下，所述網(wǎng)絡(luò)認證執(zhí)行系統(tǒng)將直接丟棄所述用戶報文。
此外，上述方法中還包括所述網(wǎng)絡(luò)認證執(zhí)行系統(tǒng)對EAPOL類型的報文直接進行轉(zhuǎn)發(fā)處理的步驟。
采用本發(fā)明的認證方法，既可以實現(xiàn)基于端口認證的802.1X認證，也可實現(xiàn)基于MAC地址的認證以對同一端口下接的多個用戶分別進行認證，從而可以較好地滿足企業(yè)和集團用戶的多樣性需求。


通過以下的文字說明并參考附圖，本發(fā)明的上述目的、特征和優(yōu)點將變得更加清楚。在以下的附圖中圖1是常規(guī)802.1x認證體系的結(jié)構(gòu)示意圖；圖2是常規(guī)IEEE 802.1x認證機制的原理示意圖；圖3示出了本發(fā)明中采用的認證執(zhí)行系統(tǒng)的結(jié)構(gòu)框圖；圖4示出了根據(jù)本發(fā)明實施例所述的基于MAC或端口的802.1x認證方法的流程框圖。
具體實施例方式
以下將參考附圖對本發(fā)明的具體實施方式
進行詳細說明。
圖3示出了本發(fā)明中采用的認證執(zhí)行系統(tǒng)的結(jié)構(gòu)框圖。如圖3所示，該認證執(zhí)行系統(tǒng)包括用戶側(cè)接收發(fā)送處理設(shè)備1、協(xié)議處理模塊2、MAC地址維護模塊3、中央處理器(CPU)4以及網(wǎng)絡(luò)側(cè)接收發(fā)送處理模塊5。
用戶側(cè)接收發(fā)送處理模塊1的功能是從用戶設(shè)備接收報文，進行緩存，然后送給協(xié)議處理模塊處理；對網(wǎng)絡(luò)側(cè)的報文進行封裝處理，轉(zhuǎn)發(fā)給用戶設(shè)備；協(xié)議處理模塊2的功能是對報文進行協(xié)議分析，根據(jù)分析結(jié)果進行交CPU、轉(zhuǎn)發(fā)或丟棄的操作。對于EAPOL幀，不需要進行MAC地址學(xué)習(xí)或查找操作而直接轉(zhuǎn)發(fā)；對于其他的業(yè)務(wù)報文只有MAC地址學(xué)習(xí)或查找操作成功的情況下才轉(zhuǎn)發(fā)，否則丟棄；MAC地址維護模塊3的功能是提供MAC地址學(xué)習(xí)和查找、自動老化、基于端口的是否允許學(xué)習(xí)控制、基于端口的允許學(xué)習(xí)的MAC地址數(shù)控制、MAC地址/IP地址和內(nèi)部連接標(biāo)識的綁定、CPU4添加靜態(tài)MAC地址等功能。網(wǎng)絡(luò)側(cè)接收發(fā)送處理模塊5的功能是從協(xié)議處理模塊2接收報文，將報文轉(zhuǎn)發(fā)給外部認證設(shè)備，并將來自外部認證設(shè)備的報文轉(zhuǎn)發(fā)給協(xié)議處理模塊2。應(yīng)該明白，上述各個模塊的實現(xiàn)方法對本領(lǐng)域技術(shù)人員來說都是公知的，其具體內(nèi)容可參考如IEEE802.1D，這里不再贅述。
以下將參考圖4對根據(jù)本發(fā)明實施例所述的方法進行詳細說明。
圖4示出了根據(jù)本發(fā)明實施例所述的基于MAC或端口的802.1x認證方法的流程框圖。如圖4所示，首先，當(dāng)用戶側(cè)接收發(fā)送處理模塊1接收到來自用戶設(shè)備的報文時(步驟1)，它將把報文交送給協(xié)議處理模塊處理2。在接收到報文之后，協(xié)議處理模塊2先判斷報文是否為EAPOL報文(步驟2)，其判斷的依據(jù)是對報文的Ethernet Type域進行分析，如果該域的值為0x888E，則認為該報文是EAPOL報文。對于EAPOL報文，協(xié)議處理模塊2將其直接送交CPU4并通過網(wǎng)絡(luò)側(cè)接收發(fā)送處理模塊5轉(zhuǎn)發(fā)給外部認證設(shè)備(步驟3)。接下來，若報文不是EAPOL報文，則協(xié)議處理模塊2將進一步判斷報文是基于端口認證的模式還是基于MAC地址認證的模式(步驟4)。這里，需要注意的是，用戶報文的認證類型已在用戶組網(wǎng)時被預(yù)先設(shè)定好?？梢酝ㄟ^用戶報文中預(yù)先設(shè)定好的標(biāo)記來確定用戶報文的認證類型。在步驟7中，當(dāng)用戶報文是基于端口認證的模式時，協(xié)議處理模塊2將進一步判斷該用戶端口是否已經(jīng)通過認證，如果用戶端口未通過認證，則協(xié)議處理模塊2將丟棄該報文(步驟10)，反之，則協(xié)議處理模塊2將對用戶端口進行地址學(xué)習(xí)(步驟8)。如果端口地址學(xué)習(xí)不成功，則協(xié)議處理模塊2丟棄該報文(步驟11)，反之，則協(xié)議處理模塊2將把該報文發(fā)送至網(wǎng)絡(luò)側(cè)接收發(fā)送處理模塊進行轉(zhuǎn)發(fā)處理(步驟9)。另外，在上述步驟8中，則協(xié)議處理模塊2還提供了基于端口的允許學(xué)習(xí)的MAC地址數(shù)目控制以及MAC地址/IP地址和內(nèi)部連接標(biāo)識的綁定，從而起到了限制用戶數(shù)量和防止用戶MAC地址盜用的作用。舉例如下在MAC地址維護模塊3中提供了允許由CPU配置的基于端口的允許學(xué)習(xí)的MAC地址數(shù)目，另外還提供一個MAC地址維護模塊3維護的已經(jīng)學(xué)習(xí)到的MAC地址數(shù)量計數(shù)器，每次該端口學(xué)習(xí)到一個新的MAC地址，MAC地址維護模塊3維護的計數(shù)器就加1，如果CPU刪除或者老化掉一個MAC地址時，MAC地址維護模塊3維護的計數(shù)器就減1，如果這個計數(shù)器大于或者等于CPU配置的允許學(xué)習(xí)的MAC地址數(shù)目時，新的MAC地址將不會再允許學(xué)習(xí)，這樣就起到了限制端口用戶數(shù)量的功能。MAC地址/IP地址和內(nèi)部連接標(biāo)識的綁定功能可以在協(xié)議處理模塊2中允許由CPU配置相應(yīng)的內(nèi)部標(biāo)識符和MAC地址/IP地址的映射表，然后由協(xié)議處理模塊2從接收的報文中提取源MAC和源IP地址和配置的表項進行比較，匹配的就允許通過，不匹配的報文進行丟棄處理，這樣就實現(xiàn)了MAC地址/IP地址和內(nèi)部連接標(biāo)識的綁定功能。
另一方面，在步驟4中，當(dāng)用戶報文是基于MAC的認證類型時，協(xié)議處理模塊2將判斷該報文所屬的MAC地址是否已經(jīng)通過認證(步驟5)，如果此MAC地址未通過認證，則該報文將被丟棄。反之，當(dāng)該MAC地址通過認證時，CPU將通過MAC地址維護模塊把該MAC地址添加為靜態(tài)MAC，這樣該MAC地址的用戶就可以進行業(yè)務(wù)報文的發(fā)送和接收。以后，對于除EAPOL報文以外的其它報文來講，在用戶通過認證之前，協(xié)議處理模塊2對其他數(shù)據(jù)報文進行丟棄處理(步驟6)，在認證通過以后，對其他數(shù)據(jù)報文進行MAC地址匹配查找，如果能夠在MAC地址表中找到匹配的表項就轉(zhuǎn)發(fā)(步驟9)，否則就丟棄。
應(yīng)該注意的是，雖然以上是參考具體實施方式
對本發(fā)明進行說明的，但這并不意味著是對本發(fā)明的限制。本領(lǐng)域的普通技術(shù)人員應(yīng)該明白，可以在上述說明的基礎(chǔ)上對本發(fā)明做出多種修改和變換。因此，本發(fā)明的保護范圍是由所附權(quán)利要求而不是具體實施方式
來限定的。
權(quán)利要求
1.一種802.1x認證方法，其特征在于包括以下步驟1)在網(wǎng)絡(luò)認證執(zhí)行系統(tǒng)中根據(jù)用戶報文的認證類型來控制外部認證設(shè)備對用戶報文的認證；以及2)所述網(wǎng)絡(luò)認證執(zhí)行系統(tǒng)根據(jù)外部認證設(shè)備對所述用戶報文的認證情況以控制所述用戶報文的轉(zhuǎn)發(fā)處理。
2.根據(jù)權(quán)利要求1所述的方法，其特征在于，所述步驟1)中進一步包括判斷所述用戶報文的認證類型是基于端口的認證還是基于MAC地址的認證的步驟。
3.根據(jù)權(quán)利要求2所述的方法，其特征在于，在所述用戶報文的認證類型是基于端口的認證的情況下，所述步驟2)進一步包括對用戶報文所屬端口是否通過外部認證設(shè)備的認證進行判斷的步驟。
4.根據(jù)權(quán)利要求3所述的方法，其特征在于，在用戶報文所屬端口通過外部認證設(shè)備的認證的情況下，所述網(wǎng)絡(luò)認證執(zhí)行系統(tǒng)將對用戶報文所屬端口的地址進行學(xué)習(xí)，并且對地址學(xué)習(xí)成功的報文進行轉(zhuǎn)發(fā)處理，對地址學(xué)習(xí)不成功的報文進行丟棄；在用戶報文所屬端口未通過外部認證設(shè)備的認證的情況下，所述網(wǎng)絡(luò)認證執(zhí)行系統(tǒng)將直接丟棄所述用戶報文。
5.根據(jù)權(quán)利要求4所述的方法，其特征在于，對用戶報文所屬端口進行地址學(xué)習(xí)的步驟進一步包括限制允許學(xué)習(xí)來自端口的MAC地址的數(shù)目以及將學(xué)習(xí)到的地址與所述網(wǎng)絡(luò)認證執(zhí)行系統(tǒng)的內(nèi)部連接標(biāo)識進行綁定的步驟。
6.根據(jù)權(quán)利要求2所述的方法，其特征在于，在所述用戶報文的認證類型是基于MAC地址的認證的情況下，所述步驟2)包括禁止學(xué)習(xí)所述用戶報文的所述端口的地址的步驟。
7.根據(jù)權(quán)利要求6所述的方法，其特征在于，所述步驟2)進一步包括對用戶報文的MAC地址是否通過外部認證設(shè)備的認證進行判斷的步驟。
8.根據(jù)權(quán)利要求7所述的方法，其特征在于，在用戶報文的MAC地址通過外部認證設(shè)備的認證的情況下，所述網(wǎng)絡(luò)認證執(zhí)行系統(tǒng)將保存所述用戶報文的MAC地址，以使所述用戶報文可以通過網(wǎng)絡(luò)認證執(zhí)行系統(tǒng)進行發(fā)送和接收；在用戶報文的MAC地址通過外部認證設(shè)備的認證的情況下，所述網(wǎng)絡(luò)認證執(zhí)行系統(tǒng)將直接丟棄所述用戶報文。
9.根據(jù)權(quán)利要求1至8中的任何一項所述的方法，其特征在于還包括所述網(wǎng)絡(luò)認證執(zhí)行系統(tǒng)對EAPOL類型的報文直接進行轉(zhuǎn)發(fā)處理的步驟。
全文摘要
本發(fā)明公開了一種802.1x認證方法，包括以下步驟1)所述網(wǎng)絡(luò)認證執(zhí)行系統(tǒng)根據(jù)用戶報文的認證類型來控制外部認證設(shè)備對用戶報文的認證；以及2)所述網(wǎng)絡(luò)認證執(zhí)行系統(tǒng)根據(jù)外部認證設(shè)備對所述用戶報文的認證情況以控制所述用戶報文的轉(zhuǎn)發(fā)處理。本發(fā)明的方法既可以對同一端口下接的多個用戶分別進行認證，也可以通過配置提供基于端口的802.1X認證，從而可以較好地滿足企業(yè)和集團用戶的多樣性需求。
文檔編號H04L12/54GK1635751SQ20031011294
公開日2005年7月6日 申請日期2003年12月26日 優(yōu)先權(quán)日2003年12月26日
發(fā)明者謝衛(wèi)平, 趙求鵬 申請人:華為技術(shù)有限公司