Sign In to Follow Application
View All Documents & Correspondence

System, Network Apparatus And Method Of Authentication

Abstract: The embodiments of the present invention provide a system, network apparatus and method of authentication. The system includes: at least one authentication client (301); an authenticator (302) which has no IP forwarding capability or Layer 3 service deployment; an authentication server (303), configured to provide authentication services as a RADIUS server; and a proxy server (304) in which a RADIUS client is deployed, configured to bind with the authenticator; wherein the authentication service is performed between the RADIUS server and the RADIUS client, the proxy server forwards packets between the authenticator and the authentication server. In this invention, RADIUS will be used between an authentication server and an authenticator, even though the authenticator has no capability of IP forwarding or L3 service deployment. Abstract Fig.: Figures 3 & 4

Get Free WhatsApp Updates!
Notices, Deadlines & Correspondence

Patent Information

Application #
Filing Date
20 December 2013
Publication Number
26/2015
Publication Type
INA
Invention Field
COMMUNICATION
Status
Email
Parent Application

Applicants

HUAWEI TECHNOLOGIES INDIA PVT. LTD.
NO. 23, LEVEL 3&4 LEELA GALLERIA, AIRPORT ROAD, BANGALORE 560 017

Inventors

1. KONDREDDY, VENUGOPAL REDDY
APT NO. 102, DIVINE GRACE, NO. 23, 2ND MAIN ROAD, KODIHALLI, HAL 2ND STAGE, INDIRA NAGAR, BANGALORE - 560 008

Specification

FIELD OF THE INVENTION

This application relates to authentication technology and in particular, to a system, a network apparatus and a method of authentication.

BACKGROUND OF THE INVENTION

Nowadays, there are some mechanisms for IEEE (Institute of Electrical and Electronics Engineers) 802. IX authentication. RADIUS (Remote Authentication Dial In User Service) for EAP (Extensible Authentication Protocol) describes the protocol mechanism for EAP authentication using RADIUS as authentication server.

Figure 1 is a flowchart of the method of authentication in the conventional technology. As shown in Figure 1, there are three entities: a supplicant (as an 802.IX client), an authenticator (as a NAS, Network Access Server) and an authentication server (as a RADIUS server).

As shown in Figure 1, the authenticator receives an EAPOL-Start message from a supplicant and sends an EAP-Request/Identity message to the supplicant; then the authenticator receives an EAP-Response/Identity message from the supplicant and sends a Radius Access-Request (EAP-Request/Identity) message to the authentication server.

As shown in Figure 1, the authenticator receives a Radius Access- Challenge (EAP-Request/MD5 Challenge) message from the authentication server and sends an EAP-Request/MD5 Challenge message to the supplicant; the supplicant sends an EAP-Response/MD5 Challenge message to the authenticator; then the authenticator sends a Radius Access-Request (EAP-Response/MD5 Challenge) message to the authentication server.

As shown in Figure 1, if the authenticator receives a Radius Access- Accept (EAP-Success) message from the authentication server, the authenticator sends an EAP-Success message to the supplicant. Handshake will continue as above if it enabled and the supplicant is authenticated.

In this conventional technology, a RADIUS client is deployed in the authenticator. When an EAP packet from the supplicant is received, the authenticator will send a RADIUS packet to the authentication server via the

RADIUS client, wherein the EAP packet is carried as RADIUS attribute in the RADIUS packet. On the other hand, the authenticator will receive a RADIUS packet from the authentication server via the RADIUS client, wherein an EAP packet is carried as RADIUS attribute in the RADIUS packet; the authenticator will send the EAP packet to the supplicant.

However, some network edge devices may not have L3 (Layer 3) protocol stack and IP (Internet Protocol) forwarding capability. For example, some edge devices cannot have L3 deployment and can only have L2 (Layer 2) deployment.

On the other hand, RADIUS protocol is over an UDP (User Datagram Protocol) which requires IP stack. 802. IX standard or EAP mechanism cannot handle the situation where network edge devices may not have IP forwarding capability. So that RADIUS mechanism can't be used between the network edge device and an authentication server for 802. IX authentication.

Figure 2 is a conventional topology diagram of authentication. As shown in Figure 2, there are L2 network and L3 network. There is no IP forwarding capability or L3 service deployment on a network edge node (PE-1, as the 802.1XNAS).

As PE-1 has no capable of IP forwarding or L3 service deployment, a RADIUS client cannot be deployed inside PE-1 along with 802.1X NAS. It wouldn't be possible to use RADIUS as authentication server.

SUMMARY OF THE INVENTION

The present invention pertains to a system, a network apparatus and a method of authentication. The objection of the invention is that RADIUS will be used between an authentication server and an authenticator, even though the authenticator has no capability of IP forwarding or L3 service deployment.

According to a first aspect of the present invention, a system of authentication is provided, the system comprising:

at least one authentication client, configured to send an authentication request and receive an authentication response;

an authenticator, configured to receive the authentication request, send the authentication request to a proxy server via a tunnel for forwarding packets, receive the authentication response from the proxy server and send the authentication response to the authentication client;

the proxy server in which a RADIUS (Remote Authentication Dial In User Service) client is deployed, configured to bind with the authenticator; wherein the

proxy server receives the authentication request via the tunnel, sends the authentication request by using the RADIUS client to an authentication server, receives the authentication response from the authentication server and sends the authentication response to the authenticator via the tunnel;

the authentication server, configured to provide authentication services as a RADIUS server.

According to a second aspect of the present invention, wherein the authenticator has no IP forwarding capability and the tunnel is established by using a physical interface.

According to a third aspect of the present invention, wherein a format of the packet between the authenticator and the proxy server is

[L2 Header] [EAPOL][EAP]

According to a fourth aspect of the present invention, wherein a network between the authenticator and the proxy server is a Layer 2 network; the tunnel is established by using a virtual interface.

According to a fifth aspect of the present invention, wherein a format of the packet between the authenticator and the proxy server is

[L2 Header] [MPLS Tunnel Label] [MPLS PW Label] [EAPOL] [EAP]

According to a sixth aspect of the present invention, wherein the packet between the proxy server and the authenticator is an EAPOL (Extensible Authentication Protocol encapsulation Over LAN) packet and the packet is based on Ether type in Ethernet header.

According to a seventh aspect of the present invention, wherein the packet between the proxy server and the authenticator is an EAPOL packet, and a VLAN (Virtual Local Area Network) tag is included in the EAPOL packet.

According to an eighth aspect of the present invention, wherein in the authenticator, a MAC session is maintained for each of the authentication clients.

According to a ninth aspect of the present invention, wherein a plurality of timers for the MAC session is configured in the authenticator.

According to a tenth aspect of the present invention, wherein a client timeout timer and a server timeout timer are configured in the authenticator and the proxy server.

According to an eleventh aspect of the present invention, wherein another proxy server for the authenticator is used as a backup server.

According to a twelfth aspect of the present invention, wherein a FSM (Finite State Machine) is maintained in the proxy server.

According to a thirteenth aspect of the present invention, a method of authentication is provided, the method comprising:

receiving, by a proxy server in which a RADIUS client is deployed, an authentication request from an authenticator via a tunnel for forwarding packets;

sending, by the proxy server, the authentication request to an authentication server by using the RADIUS client;

receiving, by the proxy server, an authentication response from the authentication server;

sending, by the proxy server, the authentication response to the authenticator via the tunnel.

According to a fourteenth aspect of the present invention, wherein the method further comprising:
sending, by the proxy server, a success message or failure message to the authenticator.

According to a fifteenth aspect of the present invention, wherein the method further comprising:
receiving, by the proxy server, a logoff message from the authenticator.

According to a sixteenth aspect of the present invention, a network apparatus of authentication, in which a RADIUS client is deployed; the network apparatus has capability of IP forwarding, the network apparatus comprising:

a first receiving unit, configured to receive an authentication request from an authenticator via a tunnel for forwarding packets;

a first sending unit, configured to send the authentication request to an authentication server by using the RADIUS client;

a second receiving unit, configured to receive an authentication response from the authentication server;

a second sending unit, configured to send the authentication response to the authenticator via the tunnel.

According to a seventeenth aspect of the present invention, wherein the network apparatus further comprising:

a third sending unit, configured to send a success message or failure message to the authenticator.

According to a eighteenth aspect of the present invention, wherein the network apparatus further comprising:

a third receiving unit, configured to receive a logoff message from the authenticator.

The advantages of the present invention exist in that: a proxy server which deployed a RADIUS client is used and the proxy server binds with an authenticator; RADIUS will be used between an authentication server and the authenticator, even though the authenticator has no capability of IP forwarding or L3 service deployment.

These and further aspects and features of the present invention will be apparent with reference to the following description and attached drawings. In the description and drawings, particular embodiments of the invention have been disclosed in detail as being indicative of some of the ways in which the principles of the invention may be employed, but it is understood that the invention is not limited correspondingly in scope. Rather, the invention includes all changes, modifications and equivalents coming within the spirit and terms of the appended claims.

Features that are described and/or illustrated with respect to one embodiment may be used in the same way or in a similar way in one or more other embodiments and/or in combination with or instead of the features of the other embodiments.

It should be emphasized that the term "comprises/comprising" when used in this specification is taken to specify the presence of stated features, integers, steps or components but does not preclude the presence or addition of one or more other features, integers, steps, components or groups thereof.

Many aspects of the invention can be better understood with reference to the following drawings. The components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present invention. To facilitate illustrating and describing some parts of the invention, corresponding portions of the drawings may be exaggerated in size, e.g., made larger in relation to other parts than in an exemplary device actually made according to the invention. Elements and features depicted in one drawing or embodiment of the invention may be combined with elements and features depicted in one or more additional drawings or embodiments. Moreover, in the drawings, like reference numerals designate corresponding parts throughout the several views and may be used to designate like or similar parts in more than one embodiment.

BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWING

The drawings are included to provide further understanding of the present invention, which constitute a part of the specification and illustrate the preferred embodiments of the present invention, and are used for setting forth the principles of the present invention together with the description. The same element is represented with the same reference number throughout the drawings.

In the drawings:

Figure 1 is a flowchart of the method of authentication in the conventional technology;

Figure 2 is a conventional topology diagram of authentication;

Figure 3 is a schematic diagram of the system in accordance with an embodiment of the present invention;

Figure 4 is a topology diagram of authentication in accordance with an embodiment of the present invention;

Figure 5 is another topology diagram of authentication in accordance with an embodiment of the present invention;

Figure 6 is a schematic block diagram showing the structure of the EAPOL packet of the embodiments of the present invention;

Figure 7 is a flowchart of the method of authentication in accordance with an embodiment of the present invention;

Figure 8 is a schematic block diagram showing the FSM of the embodiments of the present invention;

Figure 9 is a flowchart of the method of authentication in accordance with an embodiment of the present invention;

Figure 10 is another flowchart of the method of authentication in accordance with an embodiment of the present invention;

Figure 11 is a schematic diagram of the network apparatus in accordance with an embodiment of the present invention;

Figure 12 is another schematic diagram of the network apparatus in accordance with an embodiment of the present invention;

Figure 13 is a schematic block diagram showing the systematic structure of the network apparatus of the embodiments of the present invention.

DETAILED DESCRIPTION

The many features and advantages of the embodiments are apparent from the detailed specification and, thus, it is intended by the appended claims to cover all such features and advantages of the embodiments that fall within the scope thereof. Further, since numerous modifications and changes will readily occur to those skilled in the art, it is not desired to limit the inventive embodiments to the exact construction and operation illustrated and described, and accordingly all suitable modifications and equivalents may be resorted to, falling within the scope thereof.

The preferred embodiments of the present invention are described as follows in reference to the drawings.

Embodiment 1

This embodiment of the present invention provides a system of authentication. Figure 3 is a schematic diagram of the system in accordance with an embodiment of the present invention. As shown in Figure 3, the system 300 includes: at least one authentication client 301, an authenticator 302, an authentication server 303 and a proxy server 304. Where, the authentication client (supplicant) 301 is configured to send an authentication request and receive an authentication response; the authenticator 302 which has no IP forwarding capability or Layer 3 service deployment, is configured to receive the authentication request, request an authentication service from the authentication server 303 via the proxy server 304 and send the authentication response to the authentication client 301; the authentication server 303 is configured to provide authentication services as a RADIUS server; and the proxy server 304 in which a RADIUS client is deployed, is configured to bind with the authenticator 302; wherein the authentication service is performed between the RADIUS server and the RADIUS client, the proxy server 304 forwards packets between the authenticator 302 and the authentication server 303.

In this embodiment, the proxy server 304 has capability of IP forwarding or L3 service deployment, and the authenticator 302 has no capability of IP forwarding or L3 service deployment. A RADIUS client is deployed in the proxy server 304 instead of the authenticator 302.

Figure 4 is a topology diagram of authentication in accordance with an embodiment of the present invention, shows an example of the system. As shown in Figure 4, there are L2 network and L3 network. There are some authentication clients 301; PE-1 is used as the authenticate* 302; the RADIUS server is used as the authentication server 303 and PE-2 is used as the proxy server 304.

As shown in Figure 4, PE-1 and PE-2 are connected in the L2 network. IP-aware product (PE-2) can act as a proxy to the 802. IX NAS (PE-1). The 802. IX NAS (PE-1) can forward EAP authentication packets to the 802. IX Proxy-NAS (PE-2) over the L2 network, i.e., 802. IX packets can be tunneled to the802.1XProxy-NAS.

In this embodiment, packets between the proxy server and the authenticator may be EAPOL (Extensible Authentication Protocol encapsulation Over LAN) packets, and the packets may be based on Ether type in Ethernet header.

In this embodiment, a RADIUS client is deployed in the proxy server 304. The 802. IX Proxy-NAS (PE-2) processes the EAP authentication packets by using the RADIUS client; the RADIUS client is used to get the client authenticated from the RADIUS server. Communication between the RADIUS client and the RADIUS server, please refer to the conventional technology.

In this embodiment, the 802. IX Proxy-NAS (PE-2) can get an authentication result from the RADIUS server via the L3 network. The authentication result is sent back from the 802. IX Proxy-NAS (PE-2) to the 802.1X NAS (PE-1). Upon receiving the authentication result, the 802.1X NAS (PE-1) can add the authentication client to a product white list; therefore the authentication client is enabled to access network via the authenticator.

In this embodiment, there is a physical interface or a virtual interface between the proxy server and the authenticator. In the authenticator and the proxy server, 802. IX work modes may be introduced.

Work modes may be 802. IX NAS or 802. IX proxy NAS. If the work mode of the authenticator is 802.IX NAS and the authenticator is bound with a proxy-NAS interface, EAPOL packets received from 802. IX client (supplicant) are processed and sent to the 802. IX proxy server through the proxy-NAS interface. EAPOL packets received from the proxy server are processed and sent to the supplicant.

For example, in the Figure 4, PE-1 can be configured with 802. IX NAS work mode; PE-2 can be configured with 802. IX proxy NAS work mode (since PE-2 has IP forwarding capability or L3 service deployment). There exists a proxy-NAS interface between PE-1 and PE-2. This interface can be a directly connected physical interface or a virtual interface. EAP packets received at PE-1 are processed and sent to the proxy (PE-2) via the proxy-NAS interface, so that RADIUS can be used for authentication.

Figure 5 is another topology diagram of authentication in accordance with an embodiment of the present invention, shows another example of the system. There is a virtual interface between the proxy server and the authenticator.

As shown in Figure 5, PE-1 is used as the authenticator 302; PE-2 is used as the proxy server 304 and the RADIUS server is used as the authentication server 303.

In this embodiment, if the PE-1 has some IP capability, such as PE-1 has IP stack in it, then PE-1 may be configured with IP address, such as configured with gateway as L3 side IP address of site PE-2. PE-1 may learn the MAC address of the interface using ARP (Address Resolution Protocol).

RADIUS protocol can be made to pass over L2VPN network from PE-1 to PE-2. L2 to L3 conversion can be made at PE-2. RADIUS packets can be IP forwarded or MPLS (Multi-Protocol Label Switching) forwarded (for L3VPN network) between PE-2 and PE-3.

The above embodiments have described the structure of the system. The description is exemplary and it is not limited thereto. In the below embodiments, how to interact between the authenticator and the proxy server may be described.

The authenticator should be set a work mode (802. IX NAS/802.1X Proxy-NAS). Default configuration could be 802.1X NAS. If the work mode is 802. IX Proxy-NAS, it can serve as both 802.IX NAS and 802.IX Proxy-NAS.

Work mode configuration may also be provided at interface level, such as it could be a physical interface or a virtual (PW tunnel) interface. If the interface work mode is 802.1X Proxy-NAS, the interface can serve only as 802.1X Proxy-NAS. Virtual interfaces are not allowed to be configured to work in 802. IX NAS mode, i.e., default work mode of the virtual interface is 802. IX Proxy-NAS.
When the authenticator works in the 802.IX NAS mode, the authenticator should support the configuration to bind with a proxy-NAS interface (virtual or another physical interface). If a RADIUS client module inside the authenticator doesn't exist and/or the proxy-NAS interface has been configured, on receiving an authentication request (EAPOL packet) from a authentication client, the authenticator can process the authentication request (such as create a client MAC session for the authentication request etc) and send the EAPOL packet to the proxy server through the proxy-NAS interface.

In this embodiment, Format of the packet sent between the proxy server and the authenticator may be represented as below:

For an example, the proxy-NAS interface is a physical interface. Destination address in L2 header should be multicast PAE (Physical Address

Extension) group MAC address, when the packet is sent from the authenticator to the proxy server. An example of the packet is shown as below: [L2 Header] [EAPOL][EAP]

In this embodiment, EAPOL is a method to transport EAP packets between a supplicant and an authenticator directly by a LAN MAC service. The authenticator re-encapsulates the EAPOL received from the supplicant to the proxy server on Layer 2. Any Layer 2(Data link Layer) transport can be used between the authenticator and the proxy server. For the sake of simplicity, Ethernet is considered as layer 2 transport used between the authenticator and the proxy server in the below example.

Table 1 illustrates an example of L2 header (Ethernet) frame format:
Table 1
Table 2 illustrates an example of EAPOL frame format:
Table 2
Where, the packet type is as follows:
Table 3 illustrates an example of EAP packet format:
Table 3

It should be noted that when 802.lx is the transport, all this fits into the 802. lx payload field, with EAPOL packet type set to 0 (EAP packet). Where, the code field indicates the type of EAP packet as follows:

The ID is one byte for matching requests and responses. Length is the byte count including the code, ID, length and data fields.

The data field format varies depending on the code field. Types 3 and 4, Success and Failure are easy to describe: they have no data field (0 bytes). Types 1 and 2 share a format. It boils down to a type code (one byte) then the data for that type.

Table 4 illustrates another example of EAP packet format. Here's what that makes the EAP packet look like:

Table 4

In this embodiment, several types of EAP authentication are defined by the original RFC (Request For Comments). They are:

As show in the above format, some information (such as a L2 header) may be added into the packet, in case of the proxy-NAS interface is a physical interface.

For another example, the proxy-NAS interface is a virtual interface. An inner L2 header and an outer L2 header may be included in the packet. Destination address in the inner L2 header should be multicast PAE group MAC address, when the packet is sent from the authenticator to the proxy server. Another example of the packet is shown as below:

[L2 Header] [MPLS Tunnel Label] [MPLS PW Label] [EAPOL] [EAP]

In this embodiment, L2 Header, EAPOL and EAP are illustrated as table 1 to 4. MPLS Tunnel label is an outer label, an MPLS label that forwards packets from a PE (provider edge) to another PE.

In this embodiment, an MPLS tunnel is created from the authenticator to the proxy server. So it is a label that forwards the packets from the authenticator to the proxy server. Table 5 illustrates an example of the MPLS Tunnel Label format.

Table 5

Exp s experimental S = bottom of stack bit In this embodiment, MPLS PW (Pseudo Wire) label is an inner label; an MPLS PW label identifies an PE-CE (Provider Edge to Customer Edge) link. As show in the above format, information (such as an L2 header, a MPLS Tunnel Label, a MPLS PW Label) may be added into the packet, in case of the proxy-NAS interface is a virtual interface.

Furthermore, a VLAN (Virtual Local Area Network) tag may be included in the EAPOL packet. For example, if the proxy-NAS interface is a virtual L3 VLAN interface, the EAPOL packet should include the VLAN tag. Format of the packet between the proxy server and the authenticator may be configured in format illustrated in table 1 to 5.

Figure 6 is a schematic block diagram showing the structure of the EAPOL packet of the embodiments of the present invention. As shown Figure 6, the authenticator should have mechanism to send the EAPOL packet through the proxy-NAS interface to the proxy server.

In this embodiment, the proxy server (remote PE site) may be configured to work in a 802. IX Proxy-NAS mode. This site should have mechanism to pick the EAPOL packet from the proxy-NAS interface based on ETHER TYPE. However, it is not limited thereto.

Figure 7 is a flowchart of the method of authentication in accordance with an embodiment of the present invention. As shown in Figure 7, there are four entities: a supplicant (as an 802.IX client), an authenticator (as an 802.IX NAS), a proxy server (as an 802. IX Proxy-NAS) and an authentication server (as a RADIUS server). A RADIUS client is deployed in the proxy server.

As shown in Figure 7, the proxy server (by using the RADIUS client) encodes the EAP packet as a RADIUS attribute, then the proxy server sends a RADIUS packet (with the RADIUS attribute) to the RADIUS server. The RADIUS server in turn responds back with a RADIUS packet, such as accept/reject, i.e..

As shown in Figure 7, on receiving an authentication result from the RADIUS server, the proxy server (by using the RADIUS client) decodes the RADIUS packet to an EAP packet. Then the proxy server sends the EAP packet to the authenticator through the proxy-NAS interface. Furthermore, the proxy server (802. IX Proxy-NAS) may clean up the MAC session etc.

As shown in Figure 7, on receiving the authentication result (in EAP packet) from the proxy-NAS interface, the authenticator will take necessary actions. If the authentication result is EAP-Success, the authenticator adds information of the authentication client (such as the client MAC) to a product white list, to allow the authentication client access network service/resource; then the authenticator sends the EAP-Success to the authentication client. If the authentication result is EAP-Failure, the authenticator may send the EAP-failure to the authentication client.

In this embodiment, an MAC session may be maintained for the supplicant; wherein a plurality of timers for the MAC session may be run in the authenticator. Furthermore, a client timeout timer and a server timeout timer may be run in both the authenticator and the proxy server.

For example, all timers for the client MAC session i.e., a handshake timer, a re-authentication timer, a retransmission timer, can run only in the authenticator (802. lx NAS). But, the client timeout and the server timeout timer may be run in both the 802.1X NAS and the 802.1X proxy-NAS. The client timeout timer is used to detect timeout for an authentication packet sent towards client. The server timeout timer is used to detect timeout for an authentication packet sent towards server.

In this embodiment, for the authenticator (802. IX NAS), the proxy server (802. IX proxy) may act as a server; for the proxy server (802. IX proxy), the RADIUS server may act as a server.

As shown in Figure 7, the authenticator (802.lx NAS) can originate an EAPOL-logoff message and send it to the proxy server (802. IX proxy-NAS).

For example, EAPOL-logoff is sent to the proxy server (802. lx proxy-NAS) by the authenticator, when a retransmission/client/server timer is timeout, or when a client-logoff message is received from an authentication client etc..

In this embodiment, there may be another proxy server for the authenticator; and the proxy server is used as a backup.

For example, two proxy servers may be deployed for one authenticator (802. IX NAS). One proxy server (802. IX proxy-NAS) acts as a master and the other one acts as a backup. The backup may be used when the master fails.

In this embodiment, a FSM (Finite State Machine) may be maintained in the proxy server. Figure 8 is a schematic block diagram showing the FSM of the embodiments of the present invention. As shown Figure 8, the states of the FSM may include: IDLE, RESPONSE, REQUEST, AUTHENTICATED.

As shown in Figure 8, for the IDLE state, it is a transient state just before client session creation or deletion is triggered. On successful session creation, state immediately changes to the RESPONSE state. An EAPOL-EAP Response/Identity message should be received to create a client session. When events (such as Client Logoff, Client Timeout, Server Timeout and RADIUS Reject) happen, the proxy server will be transferred into this state before deleting the client session.

As shown in Figure 8, for the RESPONSE state, upon receiving the EAPOL-EAP Response message from the authenticator (802. IX NAS) or sending a RADIUS access request to the RADIUS server, the proxy server will transfer into the state.

As shown in Figure 8, for the REQUEST state, upon receiving a RADIUS challenge message or sending an EAP request to the authenticator (802. IX NAS), the proxy server will transfer into the state.

As shown in Figure 8, for the AUTHENTICATED state, upon receiving a RADIUS Accept message from the RADIUS server or sending an EAPOL-EAP SUCCESS message to the authenticator (802. IX NAS), the proxy server will transfer into the state.

As shown in Figure 8, there are some events. For CLIENT_MSG_ RCVD, this event occurs when an EAPOL-EAP or EAPOL Logoff message is received from the authenticator (802.IX NAS). For SERVERTIMEOUT, this event occurs when the RADIUS server times out. For SERVER_MSG_ RCVD, this event occurs when a RADIUS Challenge or Accept or Reject message is received from the RADIUS server. For CLIENTTIMEOUT, this event occurs when a client (such as 802. lx NAS) times out.

It can be seen from the above embodiment that: a proxy server which deployed a RADIUS client is used and the proxy server binds with an authenticator; RADIUS will be used between an authentication server and the authenticator, even though the authenticator has no capability of IP forwarding or L3 service deployment.

Embodiment 2

This embodiment of the present invention provides a method and network apparatus of authentication, applied in a proxy server side. This embodiment is based on the embodiment 1 and the same content will not be described.

Figure 9 is a flowchart of the method of authentication in accordance with an embodiment of the present invention. As shown in Figure 9, the method includes:

Step 901, a proxy server (in which a RADIUS client is deployed) receives an EAP response message from an authenticator (which has no IP forwarding capability or Layer 3 service deployment);

Step 902, the proxy server sends a RADIUS access request message to an authentication server according to the EAP response message;

Step 903, the proxy server receives a RADIUS access challenge message from the authentication server;

Step 904, the proxy server sends a EAP request message to the authenticator according to the RADIUS access challenge message.

Figure 10 is another flowchart of the method of authentication in accordance with an embodiment of the present invention. As shown in Figure 10, the method includes:

Step 1001, a proxy server receives an EAP response message from an authenticator;

Step 1002, the proxy server sends a RADIUS access request message to an authentication server according to the EAP response message;

Step 1003, the proxy server receives a RADIUS access challenge message from the authentication server;

Step 1004, the proxy server sends a EAP request message to the authenticator according to the RADIUS access challenge message.

As shown in Figure 10, the method further includes:

Step 1005, the proxy server sends a EAP success message or EAP failure message to the authenticator.

As shown in Figure 10, the method further includes:

Step 1006, the proxy server receives a EAPOL logoff message from the authenticator.

This embodiment of the present invention further provides a network apparatus, applied in a proxy server.

Figure 11 is a schematic diagram of the network apparatus in accordance with an embodiment of the present invention. As shown in Figure 11, the network apparatus 1100 includes: a first receiving unit 1101, a first sending unit 1102, a second receiving unit 1103, and a second sending unit 1104.

In this embodiment, the network apparatus may be a proxy server; other parts of the proxy server can refer to the existing technology and not be described in the present application. However, it is not limited thereto, and particular implement way may be determined as actually required.

Where, the first receiving unit 1101 is configured to receive a EAP response message from an authenticator (which has no IP forwarding capability or Layer 3 service deployment); the first sending unit 1102 is configured to send a RADIUS access request message to an authentication server according to the EAP response message; the second receiving unit 1103 is configured to receive a RADIUS access challenge message from the authentication server; the second sending unit 1104 is configured to send a EAP request message to the authenticator according to the RADIUS access challenge message.

Figure 12 is another schematic diagram of the network apparatus in accordance with an embodiment of the present invention. As shown in Figure 12, the network apparatus 1200 includes: a first receiving unit 1101, a first sending unit 1102, a second receiving unit 1103, a second sending unit 1104. As described in above.

As shown in Figure 12, the network apparatus 1200 may further include: a third sending unit 1205, the third sending unit 1205 is configured to send a EAP success message or EAP failure message to the authenticator.

As shown in Figure 12, the network apparatus 1200 may further include: a third receiving unit 1206, the third receiving unit 1206 is configured to receive a EAPOL logoff message from the authenticator.

It can be seen from the above embodiment that: a proxy server which deployed a RADIUS client is used and the proxy server binds with an authenticator; RADIUS will be used between an authentication server and the authenticator, even though the authenticator has no capability of IP forwarding or L3 service deployment.

It should be understood that each of the parts of the present invention may be implemented by hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods may be realized by software or firmware that is stored in the memory and executed by an appropriate instruction executing system. For example, if it is realized by hardware, it may be realized by any one of the following technologies known in the art or a combination thereof as in another embodiment: a discrete logic circuit having a logic gate circuit for realizing logic functions of data signals, application-specific integrated circuit having an appropriate combined logic gate circuit, a programmable gate array (PGA), and a field programmable gate array (FPGA), etc.

Figure 13 is a schematic block diagram showing the systematic structure of the network apparatus of the embodiments of the present invention. Such a figure is just exemplary and other types of structures may also be used for supplementing or replacing this structure, so as to implement the function of telecommunications or other functions.

As shown in Figure 13, the network apparatus 1300 may include a CPU 1301, a communication device 1302, an input device 1303, a memory 1304 and an output device 1305.

Where, the CPU 1301 (also referred to as a controller or an operational control, which may include a microprocessor or other processing devices and/or logic devices) receives input and controls each part and operation of the network apparatus. The input device 1303 provides input to the CPU 1301. The input device 1303 may be for example a key or touch input device. The output device 1305 receives the data from the CPU 1301 and sends it to other apparatus.

The memory 1304 is coupled to the CPU 1301. The memory 1304 may store a logic part readable program according to the method of authentication above-mentioned, the CPU 1301 may carry out the method of authentication. The memory 1304 may be a read-only memory (ROM), a random access memory (RAM), and a SIM card. The memory 1304 may also be such a memory that stores information even when the power is interrupted, may be optionally erased and provided with more data. Examples of such a memory are sometimes referred to as an EPROM, etc.. The memory 1304 may also be other types of devices.

The communication device 1302 may be a network interface controller (NIC). The communication device 1302 is coupled to the CPU 1301 to provide input signals and receive output signals, this being similar to the case in a conventional communication center.

The description or blocks in the flowcharts or of any process or method in other manners may be understood as being indicative of comprising one or more modules, segments or parts for realizing the codes of executable instructions of the steps in specific logic functions or processes, and that the scope of the preferred embodiments of the present invention comprise other implementations, wherein the functions may be executed in manners different from those shown or discussed, including executing the functions according to the related functions in a substantially simultaneous manner or in a reverse order, which should be understood by those skilled in the art to which the present invention pertains.

The logic and/or steps shown in the flowcharts or described in other manners here may be, for example, understood as a sequencing list of executable instructions for realizing logic functions, which may be implemented in any computer readable medium, for use by an instruction executing system, device or apparatus (such as a system including a computer, a system including a processor, or other systems capable of extracting instructions from an instruction executing system, device or apparatus and executing the instructions), or for use in combination with the instruction executing system, device or apparatus.

The above literal description and drawings show various features of the present invention. It should be understood that those skilled in the art may prepare appropriate computer codes to carry out each of the steps and processes as described above and shown in the drawings. It should be also understood that all the terminals, computers, servers, and networks may be any type, and the computer codes may be prepared according to the disclosure to carry out the present invention by using the apparatus.

Particular embodiments of the present invention have been disclosed herein. Those skilled in the art will readily recognize that the present invention is applicable in other environments. In practice, there exist many embodiments and implementations. The appended claims are by no means intended to limit the scope of the present invention to the above particular embodiments. Furthermore, any reference to "a device to..." is an explanation of device plus function for describing elements and claims, and it is not desired that any element using no reference to "a device to..." is understood as an element of device plus function, even though the wording of "device" is included in that claim.

Although a particular preferred embodiment or embodiments have been shown and the present invention has been described, it is obvious that equivalent modifications and variants are conceivable to those skilled in the art in reading and understanding the description and drawings. Especially for various functions executed by the above elements (portions, assemblies, apparatus, and compositions, etc.), except otherwise specified, it is desirable that the terms (including the reference to "device") describing these elements correspond to any element executing particular functions of these elements (i.e. functional equivalents), even though the element is different from that executing the function of an exemplary embodiment or embodiments illustrated in the present invention with respect to structure. Furthermore, although the a particular feature of the present invention is described with respect to only one or more of the illustrated embodiments, such a feature may be combined with one or more other features of other embodiments as desired and in consideration of advantageous aspects of any given or particular application.

WE CLAIM :

1. A system of authentication, the system comprising:
at least one authentication client, configured to send an authentication request and receive an authentication response;
an authenticator, configured to receive the authentication request, send the authentication request to a proxy server via a tunnel for forwarding packets, receive the authentication response from the proxy server and send the authentication response to the authentication client;
the proxy server in which a RADIUS (Remote Authentication Dial In User Service) client is deployed, configured to bind with the authenticator; wherein the proxy server receives the authentication request via the tunnel, sends the authentication request by using the RADIUS client to an authentication server, receives the authentication response from the authentication server and sends the authentication response to the authenticator via the tunnel;
the authentication server, configured to provide authentication services as a RADIUS server.

2. The system as claimed in claim 1, wherein the authenticator has no IP forwarding capability and the tunnel is established by using a physical interface.

3. The system as claimed in claim 2, wherein a format of the packet between the authenticator and the proxy server is [L2 Header] [EAPOL][EAP]

4. The system as claimed in claim 1, wherein a network between the authenticator and the proxy server is a Layer 2 network; the tunnel is established by using a virtual interface.

5. The system as claimed in claim 4, wherein a format of the packet between the authenticator and the proxy server is [L2 Header] [MPLS Tunnel Label] [MPLS PW Label] [EAPOL] [EAP]

6. The system as claimed in claim 1, wherein the packet between the proxy server and the authenticator is an EAPOL (Extensible Authentication Protocol encapsulation Over LAN) packet and the packet is based on Ether type in Ethernet header.

7. The system as claimed in claim 1, wherein the packet between the proxy server and the authenticator is an EAPOL packet, and a VLAN (Virtual Local Area Network) tag is included in the EAPOL packet.

8. The system as claimed in claim 1, wherein in the authenticator, a MAC session is maintained for each of the authentication clients.

9. The system as claimed in claim 8, wherein a plurality of timers for the MAC session is configured in the authenticator.

10. The system as claimed in claim 9, wherein a client timeout timer and a server timeout timer are configured in the authenticator and the proxy server.

11. The system as claimed in claim 1, wherein another proxy server for the authenticator is used as a backup server.

12. The system as claimed in claim 1, wherein a FSM (Finite State Machine) is maintained in the proxy server.

13. A method of authentication, the method comprising:
receiving, by a proxy server in which a RADIUS client is deployed, an authentication request from an authenticator via a tunnel for forwarding packets;
sending, by the proxy server, the authentication request to an authentication server by using the RADIUS client;
receiving, by the proxy server, an authentication response from the authentication server;
sending, by the proxy server, the authentication response to the authenticator via the tunnel.

14. The method as claimed in claim 13, wherein the method further comprising:
sending, by the proxy server, a success message or failure message to the authenticator.

15. The method as claimed in claim 13, wherein the method further comprising:
receiving, by the proxy server, a logoff message from the authenticator.

16. A network apparatus of authentication, in which a RADIUS client is deployed; the network apparatus has capability of IP forwarding, the network apparatus comprising:
a first receiving unit, configured to receive an authentication request from an authenticator via a tunnel for forwarding packets;
a first sending unit, configured to send the authentication request to an authentication server by using the RADIUS client;
a second receiving unit, configured to receive an authentication response from the authentication server;
a second sending unit, configured to send the authentication response to the authenticator via the tunnel.

17. The network apparatus as claimed in claim 16, wherein the network apparatus further comprising:
a third sending unit, configured to send a success message or failure message to the authenticator.

18. The network apparatus as claimed in claim 16, wherein the network apparatus further comprising:
a third receiving unit, configured to receive a logoff message from the authenticator.

Documents

Orders

Section Controller Decision Date

Application Documents

# Name Date
1 5980-CHE-2013 POWER OF ATTORNEY 20-12-2013.pdf 2013-12-20
1 5980-CHE-2013-Correspondence to notify the Controller [08-11-2023(online)].pdf 2023-11-08
2 5980-CHE-2013 FORM-2 20-12-2013.pdf 2013-12-20
2 5980-CHE-2013-US(14)-HearingNotice-(HearingDate-08-11-2023).pdf 2023-10-23
3 5980-CHE-2013-CLAIMS [07-05-2019(online)].pdf 2019-05-07
3 5980-CHE-2013 FORM-1 20-12-2013.pdf 2013-12-20
4 5980-CHE-2013-DRAWING [07-05-2019(online)].pdf 2019-05-07
4 5980-CHE-2013 DRAWINGS 20-12-2013.pdf 2013-12-20
5 5980-CHE-2013-FER_SER_REPLY [07-05-2019(online)].pdf 2019-05-07
5 5980-CHE-2013 DESCRIPTION (COMPLETE) 20-12-2013.pdf 2013-12-20
6 5980-CHE-2013-OTHERS [07-05-2019(online)].pdf 2019-05-07
6 5980-CHE-2013 CORRESPONDENCE OTHERS 20-12-2013.pdf 2013-12-20
7 5980-CHE-2013-FER.pdf 2019-02-20
7 5980-CHE-2013 CLAIMS 20-12-2013.pdf 2013-12-20
8 Correspondence by Agent_Form 6_16-04-2018.pdf 2018-04-16
8 5980-CHE-2013 ABSTRACT 20-12-2013.pdf 2013-12-20
9 5980-CHE-2013 FORM-3 20-12-2013.pdf 2013-12-20
9 5980-CHE-2013-8(i)-Substitution-Change Of Applicant - Form 6 [24-03-2018(online)].pdf 2018-03-24
10 5980-CHE-2013 CORRESPONDENCE OTHERS 13-01-2014.pdf 2014-01-13
10 5980-CHE-2013-ASSIGNMENT DOCUMENTS [24-03-2018(online)].pdf 2018-03-24
11 5980-CHE-2013 FORM-18 13-01-2014.pdf 2014-01-13
11 5980-CHE-2013-PA [24-03-2018(online)].pdf 2018-03-24
12 5980-CHE-2013 CORRESPONDENCE OTHERS 06-07-2015.pdf 2015-07-06
12 PETITION EXTENTION ONE MONTH FORM-1 - PCC9467.pdf 2014-06-27
13 5980-CHE-2013 FORM-1 18-07-2014.pdf 2014-07-18
13 FORM 13 _Applicant Address Change_.pdf 2015-03-13
14 5980-CHE-2013 CORRESPONDENCE OTHERS 18-07-2014.pdf 2014-07-18
14 FORM NO. INC-22.pdf 2015-03-13
15 abstract5980-CHE-2013.jpg 2014-07-21
15 FORM 13 _Applicant Address Change_.pdf ONLINE 2015-02-25
16 5980-CHE-2013 FORM-13 20-02-2015.pdf 2015-02-20
16 FORM NO. INC-22.pdf ONLINE 2015-02-25
17 FORM NO. INC-22.pdf ONLINE 2015-02-25
17 5980-CHE-2013 FORM-13 20-02-2015.pdf 2015-02-20
18 abstract5980-CHE-2013.jpg 2014-07-21
18 FORM 13 _Applicant Address Change_.pdf ONLINE 2015-02-25
19 5980-CHE-2013 CORRESPONDENCE OTHERS 18-07-2014.pdf 2014-07-18
19 FORM NO. INC-22.pdf 2015-03-13
20 5980-CHE-2013 FORM-1 18-07-2014.pdf 2014-07-18
20 FORM 13 _Applicant Address Change_.pdf 2015-03-13
21 5980-CHE-2013 CORRESPONDENCE OTHERS 06-07-2015.pdf 2015-07-06
21 PETITION EXTENTION ONE MONTH FORM-1 - PCC9467.pdf 2014-06-27
22 5980-CHE-2013 FORM-18 13-01-2014.pdf 2014-01-13
22 5980-CHE-2013-PA [24-03-2018(online)].pdf 2018-03-24
23 5980-CHE-2013 CORRESPONDENCE OTHERS 13-01-2014.pdf 2014-01-13
23 5980-CHE-2013-ASSIGNMENT DOCUMENTS [24-03-2018(online)].pdf 2018-03-24
24 5980-CHE-2013-8(i)-Substitution-Change Of Applicant - Form 6 [24-03-2018(online)].pdf 2018-03-24
24 5980-CHE-2013 FORM-3 20-12-2013.pdf 2013-12-20
25 Correspondence by Agent_Form 6_16-04-2018.pdf 2018-04-16
25 5980-CHE-2013 ABSTRACT 20-12-2013.pdf 2013-12-20
26 5980-CHE-2013-FER.pdf 2019-02-20
26 5980-CHE-2013 CLAIMS 20-12-2013.pdf 2013-12-20
27 5980-CHE-2013-OTHERS [07-05-2019(online)].pdf 2019-05-07
27 5980-CHE-2013 CORRESPONDENCE OTHERS 20-12-2013.pdf 2013-12-20
28 5980-CHE-2013-FER_SER_REPLY [07-05-2019(online)].pdf 2019-05-07
28 5980-CHE-2013 DESCRIPTION (COMPLETE) 20-12-2013.pdf 2013-12-20
29 5980-CHE-2013-DRAWING [07-05-2019(online)].pdf 2019-05-07
29 5980-CHE-2013 DRAWINGS 20-12-2013.pdf 2013-12-20
30 5980-CHE-2013-CLAIMS [07-05-2019(online)].pdf 2019-05-07
30 5980-CHE-2013 FORM-1 20-12-2013.pdf 2013-12-20
31 5980-CHE-2013 FORM-2 20-12-2013.pdf 2013-12-20
31 5980-CHE-2013-US(14)-HearingNotice-(HearingDate-08-11-2023).pdf 2023-10-23
32 5980-CHE-2013 POWER OF ATTORNEY 20-12-2013.pdf 2013-12-20
32 5980-CHE-2013-Correspondence to notify the Controller [08-11-2023(online)].pdf 2023-11-08

Search Strategy

1 TOTALPATENTONESEARCH_20-02-2019.pdf