Switch local access authentication method based on client certificate

Abstract

This invention discloses a local access authentication method for a network switch based on client certificates, comprising: when a network switch detects that a remote authentication server is unavailable, it triggers a local authentication process; the client device uses its own client certificate and client private key to generate a local authentication credential through hash calculation and submits it to the switch; the switch compares the credential with a pre-stored reference hash value, and if the comparison is successful, grants network access permission. The beneficial effect of this invention is that when the remote authentication server is offline, it can reuse the client's existing digital certificate system, realizing a secure and seamless local authentication backup mechanism. Users do not need to remember and manage additional local passwords, greatly improving network availability and the continuity of user experience.

Description

Technical Field

[0001] This invention relates to the field of computer network technology, and more specifically, to a local access authentication method for switches based on client certificates. Background Technology

[0002] In modern enterprise networks, the port-based network access control (PNAC) protocol IEEE 802.1X is the cornerstone of secure network access. This architecture typically comprises three core components: a client device (Supplicant) that requests network access, a network device such as a switch or wireless access point that controls the physical access to the network port (Authenticator), and a central server (Authentication Server) responsible for making the final authentication decision, usually a RADIUS server.

[0003] Among these authentication methods, Extensible Authentication Protocol-Transport Layer Security (EAP-TLS) is widely recognized as one of the most secure EAP standards. Defined in RFC 5216, EAP-TLS utilizes X.509 digital certificates for mutual authentication between the client and server. Its authentication process is based on the TLS handshake protocol, where the client and server exchange their respective certificates and verify each other's identities, ultimately establishing an encrypted communication tunnel and deriving a session key. This public-key cryptography-based mechanism provides strong authentication and data confidentiality protection.

[0004] In a typical 802.1X deployment, the authenticator (such as a switch) does not perform complex authentication logic itself. It acts as a RADIUS client, encapsulating EAP messages received from the requester within RADIUS Access-Request messages and sending them over the network to the RADIUS server. The RADIUS server processes the EAP messages, verifies the client's certificate, and ultimately returns the authentication result to the authenticator via an Access-Accept or Access-Reject message. The advantage of this centralized architecture is that it simplifies the configuration of network devices and centrally manages all authentication policies and user data, facilitating maintenance and auditing.

[0005] However, this centralized architecture also introduces a critical weakness: the RADIUS server becomes a single point of failure in the entire authentication system. If the network connection between the authenticator and the RADIUS server is interrupted, or if the RADIUS server itself crashes for any reason, the standard EAP-TLS authentication process cannot be completed. In this case, newly connected devices or devices that need to be re-authenticated will fail authentication, resulting in network access interruption.

[0006] To address this issue, the industry has proposed and implemented various solutions, but each solution has its own limitations.

[0007] First, the most common approach is to build a highly available RADIUS server cluster, such as using a primary / backup, load balancing, or geographical redundancy deployment. Network access devices are configured to forward authentication requests to one or more backup servers when the primary server is unresponsive. While this method effectively improves the availability of the authentication service, it significantly increases the complexity of network deployment and operational costs, which may be impractical for small and medium-sized enterprises with limited budgets or branch offices with simple network structures.

[0008] Secondly, network devices themselves also provide some backup mechanisms in case of authentication server failure. These mechanisms are typically triggered when the switch cannot contact any configured RADIUS server, and mainly include: Deny all access: This is the most secure but also the most business-impacting strategy. The switch simply denies all new authentication requests, keeping the port in an unauthorized state to prevent any unauthorized access.

[0009] Authorized access to the guest VLAN: The switch automatically assigns users who cannot complete authentication to a pre-configured, isolated VLAN. This VLAN typically provides only limited network access, such as internet access only, but not access to critical internal resources. While this solution provides a degree of connectivity, it sacrifices the user's normal access to internal resources.

[0010] Fallback to local username / password authentication: The switch uses its built-in local user database, requiring users to authenticate using traditional usernames and passwords. This is the most complete escape solution in terms of functionality, but it has several serious drawbacks. First, it imposes an extremely heavy management burden. Network administrators need to create and maintain a separate set of local credentials for users on each switch, and the distribution, synchronization, and rotation of passwords are too much of a burden for administrators. Second, it results in a poor user experience. Users need to remember a set of emergency passwords that are unrelated to their daily work and are not frequently used, increasing their password management burden.

[0011] Analysis of existing technologies reveals irreconcilable contradictions among them in the three key dimensions of security, availability, and manageability. RADIUS cluster solutions, prioritizing high availability, sacrifice manageability (high cost, high complexity); default denial policies, prioritizing high security, sacrifice availability (service interruption); while local passwords or guest VLANs, prioritizing availability, severely compromise both security and manageability.

[0012] At a deeper level, existing backup mechanisms fail to fully utilize the high-value security assets already present in the EAP-TLS authentication system. In an EAP-TLS environment, each legitimate client device has deployed a digital certificate issued by an authoritative authority and its corresponding private key. This is a set of extremely strong identity credentials. However, when the RADIUS server fails, existing technologies either completely abandon authentication based on these credentials (such as guest VLANs) or degrade to a completely different and much less secure credential system (local username / password). This is equivalent to requiring a user to present a handwritten, easily forged "note" to prove their identity when the user possesses a "digital pass." This approach not only represents a huge waste of existing security investments but also exposes a fundamental flaw in the design philosophy of existing backup mechanisms. Summary of the Invention

[0013] The technical problem to be solved by this invention is to provide a local access authentication method for switches based on client certificates, which aims to solve the problem that in a network environment using 802.1X EAP-TLS authentication, when the central server becomes unavailable due to failure or network isolation, there is a lack of a secure and reliable local backup authentication mechanism, resulting in legitimate users being unable to access the network.

[0014] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows: a local access authentication method for switches based on client certificates, applied to a network system including client devices and network switches, comprising the following steps: When the S101 network switch receives an access request from the client device, it checks the availability status of the remote authentication server used for primary authentication of the client device. If it determines that the remote authentication server is unavailable, it triggers the local authentication process. The S102 client device generates a credential hash value as a local authentication credential based on its locally stored client certificate and the client private key paired with the client certificate, and sends the local authentication credential to the network switch; The S103 network switch compares the received local authentication credential with a reference hash value pre-stored locally that corresponds to the identity of the client device. If the comparison results match, the network switch authenticates the client device and grants it network access permission.

[0015] As a preferred embodiment, step S101 specifically involves: the client device physically connecting to a port of a network switch or associating with a wireless AP; after detecting the network connection, the client's requesting software automatically initiates 802.1X authentication, sending an authentication request to the switch to request the start of the authentication process; the switch, acting as the authenticator, upon receiving the client's request, first attempts to execute the main authentication process; it sends an authentication request message to the pre-configured remote authentication server's IP address and port, and waits for the server's response; The switch starts a timer; if no response is received from the remote authentication server within the preset timeout period, or if an error message is received from the network layer, the switch determines that the remote authentication server is currently unavailable; the switch determines that local authentication needs to be used as a backup plan; at this time, the switch sends a local authentication request to the client device, indicating that the client enters local authentication mode.

[0016] As a preferred embodiment, step S102 specifically involves the client's requesting software receiving the local authentication command from the switch and performing the following operations: Access the local certificate store and read the client certificate used for network authentication; obtain the client private key paired with the certificate through a secure API call; The two are combined into a single data block according to the same deterministic rules as the pre-registration phase; The data block is calculated using a predefined hash algorithm to generate a credential hash value; this credential hash value is the local authentication credential used for this authentication. The client encapsulates its own identity as the username and the hash value of that credential as the password in a message and sends it to the network switch.

[0017] As a preferred embodiment, step S103 specifically involves: the network switch receiving an authentication response from the client containing the username and password, i.e., the credential hash value; it uses the received username as an index to query its local user database to find the pre-stored reference hash value; The switch performs an exact comparison between the received credential hash and the reference hash retrieved from the local database. If they match exactly, it means the client does indeed hold the same certificate and private key pair as during pre-registration, authentication is successful, the switch switches the client port's state from unauthorized to authorized, allowing the client device's data traffic to pass through and officially access the network; the authentication process ends successfully. If the two do not match, or if the user's record cannot be found in the local database, authentication fails, and the switch will maintain the port in an unauthorized state, denying the user network access.

[0018] As a preferred embodiment, the remote authentication server is a RADIUS server, and the primary authentication is based on the Extensible Authentication Protocol-Transport Layer Security (EAP-TLS) protocol.

[0019] As a preferred embodiment, the reference hash value is generated by the client device or management server and securely configured into the local user database of the network switch during the initial registration or configuration phase of the client device.

[0020] As a preferred approach, the generation and configuration of the reference hash value adopts a centralized configuration, specifically: when issuing a client certificate to a client, the network management platform or configuration server can simultaneously perform the following operations: obtain the public key portion of the client's certificate, and calculate the reference hash value by combining it with its private key in a secure environment; The calculation formula is Hash is a predefined strong hash algorithm, and || represents data concatenation; then, the management security method associates the user's identity identifier with the corresponding... The data is written to the local user database of all network switches it may connect to; during this process, the private key is only used for calculation and is not stored on the management platform or transmitted to the switch; ultimately, a local user table is formed on the network switch.

[0021] As another preferred approach, the generation and configuration of the reference hash value employs client-assisted configuration. Specifically, after the client device successfully accesses the network for the first time through the standard EAP-TLS process, the remote authentication server can include a setting instruction in the authentication success message, or the client software can be configured to allow the client to calculate its own reference hash value within the established secure TLS tunnel. The system then sends the hash value of the credential to the switch. Upon receiving the hash value, the switch associates it with the currently successfully authenticated user identity and stores it in its local database as a backup credential for the future. Ultimately, a local user table is formed on the network switch.

[0022] The beneficial effects of this invention are: it achieves continuity and transformation of credentials. It uses the client's unique encrypted identity (private key / certificate pair) as a common root of trust in both primary and backup authentication scenarios. When the authentication environment changes (i.e., the central server is unavailable), this invention simply and smoothly transforms the method of proving the identity from a complex TLS handshake to credential hash comparison, thereby constructing a more secure authentication architecture. Furthermore, it possesses the following advantages: Improving network availability: This invention provides a robust and reliable local authentication path in the event of a primary authentication server failure. When the primary server is offline, the authentication process can be seamlessly switched to local processing on the switch, thereby avoiding network access service interruptions due to single points of failure and ensuring business continuity.

[0023] Enhancing User Experience: This invention cleverly reuses existing digital certificates and private keys on the client side. Users do not need to create, remember, or manually enter a separate local password in emergencies. For users, the entire authentication process can be completed automatically through the client software, with an experience almost identical to normal circumstances, achieving continuity and transparency in the authentication process.

[0024] Enhanced security: The root of authentication remains the private key held by the client and protected by hardware or the operating system—a strong encrypted credential. Private key-based authentication offers significantly higher security compared to static passwords that can be guessed or leaked. During the authentication process, the private key itself never leaves the client device; only the hash value of the credential generated by combining it with the certificate is transmitted, effectively preventing eavesdropping and replay attacks during transmission.

[0025] Reduced management overhead: Administrators no longer need to manually configure and maintain local user passwords on numerous network switches. Reference hash values ​​can be generated and securely distributed to switches once, via automated scripts or network management platforms, when a user or device joins the network. This greatly simplifies the configuration and management process and reduces the risk of human error. Attached Figure Description

[0026] Figure 1 This is a schematic diagram of a system architecture for switch local access authentication based on client certificates according to an embodiment of the present invention.

[0027] Figure 2 This is a flowchart of a switch local access authentication method based on client certificates according to an embodiment of the present invention. Detailed Implementation

[0028] The specific embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0029] like Figure 1 As shown, the implementation environment of this invention mainly includes three entities: Client device 100: For example, a laptop, workstation, or other terminal device with 802.1X requester software installed. This device securely stores one or more X.509 client certificates and their corresponding private keys locally.

[0030] Network switch 101: As the authenticator, it is typically an enterprise-grade Layer 2 or Layer 3 managed switch. It is responsible for executing the 802.1X protocol and communicating with client device 100 and remote authentication server 103. According to the present invention, the switch also has local authentication capabilities and stores a local user database 102.

[0031] Remote authentication server 103: As the primary authentication server, it is typically a RADIUS server. It is responsible for handling regular EAP-TLS authentication requests and integrating with the enterprise's backend identity directory.

[0032] like Figure 2 As shown, a client certificate-based local access authentication method for switches, applied to a network system including client devices and network switches when the remote authentication server is unavailable, includes the following steps: When the S101 network switch receives an access request from the client device, it checks the availability of the remote authentication server (RADIUS server) used for primary authentication of the client device. If the remote authentication server is found to be unavailable, it triggers the local authentication process. The primary authentication is based on the Extensible Authentication Protocol-Transport Layer Security (EAP-TLS). Specifically: the client device physically connects to a port of the network switch or is associated with a wireless access point (AP); after detecting the network connection, the client's requesting software automatically initiates 802.1X authentication, sending an authentication request to the switch to begin the authentication process; the switch, acting as the authenticator, upon receiving the client's request, first attempts to execute the primary authentication process; it sends an authentication request message to the pre-configured IP address and port of the remote authentication server and waits for the server's response. The switch starts a timer; if no response is received from the remote authentication server within the preset timeout period, or if an error message such as "target unreachable" is received from the network layer, the switch determines that the remote authentication server is currently unavailable; the switch determines that local authentication needs to be used as a backup plan; at this time, the switch sends a local authentication request to the client device, indicating that the client enters local authentication mode.

[0033] The S102 client device generates a credential hash value as a local authentication credential based on its locally stored client certificate and the client private key paired with the client certificate, and sends the local authentication credential to the network switch; specifically, after receiving the local authentication instruction from the switch, the client's requesting software performs the following operations: Access the local certificate store and read the client certificate used for network authentication; obtain the client private key paired with the certificate through a secure API call; Create a local user table on the network switch; combine the two into a data block according to the same deterministic rules as in the pre-registration phase; The data block is calculated using a predefined hash algorithm to generate a credential hash value; this credential hash value is the local authentication credential used for this authentication. The client encapsulates its own identity as the username and the hash value of that credential as the password in a message and sends it to the network switch.

[0034] The S103 network switch compares the received local authentication credentials with a pre-stored reference hash value corresponding to the client device's identity. If the comparison results match, the network switch authenticates the client device and grants it network access permission. Specifically, the network switch receives an authentication response from the client containing the username and password (i.e., the credential hash value); it uses the received username as an index to query its local user database to find the pre-stored reference hash value. The switch performs an exact comparison between the received credential hash and the reference hash retrieved from the local database. If they match exactly, it means the client does indeed hold the same certificate and private key pair as during pre-registration, authentication is successful, the switch switches the client port's state from unauthorized to authorized, allowing the client device's data traffic to pass through and officially access the network; the authentication process ends successfully. If the two do not match, or if the user's record cannot be found in the local database, authentication fails, and the switch will maintain the port in an unauthorized state, denying the user network access.

[0035] The reference hash value is generated by the client device or management server and securely configured into the local user database of the network switch during the initial registration or configuration phase of the client device.

[0036] The reference hash value is generated and configured in a centralized manner. Specifically, when issuing a client certificate to a client, the network management platform or configuration server can simultaneously perform the following operations: obtain the public key portion of the client's certificate and calculate the reference hash value by combining it with its private key in a secure environment. The calculation formula is Hash is a predefined strong hash algorithm, and || represents data concatenation; then, the management security method associates the user's identity identifier with the corresponding... The data is written to the local user database of all network switches it may connect to; during this process, the private key is only used for calculation and is not stored on the management platform or transmitted to the switch; ultimately, a local user table is formed on the network switch.

[0037] The generation and configuration of the reference hash value can also be achieved through client-assisted configuration. Specifically, after the client device successfully accesses the network for the first time through the standard EAP-TLS process, the remote authentication server can include a setting instruction in the authentication success message, or the client software can be configured to allow the client to calculate its own reference hash value within the established secure TLS tunnel. The system then sends the hash value of the credential to the switch. Upon receiving the hash value, the switch associates it with the currently successfully authenticated user identity and stores it in its local database as a backup credential for the future. Ultimately, a local user table is formed on the network switch.

[0038] The above embodiments are merely illustrative of the principles and effects of the present invention, as well as some examples of its application, and are not intended to limit the present invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the inventive concept of the present invention, and these modifications and improvements are all within the scope of protection of the present invention.

Claims

1. A client certificate-based local access authentication method for a network system including client devices and network switches, comprising the following steps: S101. When the network switch receives the access request from the client device, it checks the availability status of the remote authentication server used for primary authentication of the client device. If it determines that the remote authentication server is unavailable, it triggers the local authentication process. S102. The client device generates a credential hash value as a local authentication credential based on its locally stored client certificate and the client private key paired with the client certificate, and sends the local authentication credential to the network switch; S103. The network switch compares the received local authentication credential with a reference hash value pre-stored locally that corresponds to the identity of the client device. If the comparison results match, the network switch authenticates the client device and grants it network access permission.

2. The switch local access authentication method based on client certificates as described in claim 1, characterized in that: Step S101 specifically involves: the client device physically connecting to a port of a network switch or associating with a wireless AP; after the client's requesting software detects the network connection, it automatically initiates 802.1X authentication, sending an authentication request to the switch to request the start of the authentication process; the switch, acting as the authenticator, upon receiving the client's request, first attempts to execute the main authentication process; it sends an authentication request message to the pre-configured remote authentication server's IP address and port, and waits for the server's response; The switch starts a timer; if no response is received from the remote authentication server within the preset timeout period, or if an error message is received from the network layer, the switch determines that the remote authentication server is currently unavailable. The switch has determined that local authentication needs to be used as a backup solution. At this point, the switch sends a local authentication request to the client device, indicating that the client should enter local authentication mode.

3. The switch local access authentication method based on client certificates as described in claim 1, characterized in that: Specifically, step S102 involves the client's requesting software receiving the local authentication command from the switch and performing the following operations: Access the local certificate store and read the client certificate used for network authentication; obtain the client private key paired with the certificate through a secure API call; combine the two into a data block according to the same deterministic rules as in the pre-registration phase; The data block is calculated using a predefined hash algorithm to generate a credential hash value; this credential hash value is the local authentication credential used for this authentication. The client encapsulates its own identity as the username and the hash value of that credential as the password in a message and sends it to the network switch.

4. The switch local access authentication method based on client certificates as described in claim 1, characterized in that: Specifically, step S103 involves the network switch receiving an authentication response from the client containing the username and password, i.e., the credential hash value; it uses the received username as an index to query its local user database to find the pre-stored reference hash value. The switch performs an exact comparison between the received credential hash and the reference hash retrieved from the local database. If they match exactly, it means the client does indeed hold the same certificate and private key pair as during pre-registration, authentication is successful, the switch switches the client port's state from unauthorized to authorized, allowing the client device's data traffic to pass through and officially access the network; the authentication process ends successfully. If the two do not match, or if the user's record cannot be found in the local database, authentication fails, and the switch will maintain the port in an unauthorized state, denying the user network access.

5. The method of claim 2, wherein the method further comprises: receiving a client certificate from the client device; and verifying the client certificate. 5 The remote authentication server is a RADIUS server, and the primary authentication is based on the Extensible Authentication Protocol-Transport Layer Security (EAP-TLS) protocol.

6. The method of claim 4, wherein the method further comprises: The reference hash value is generated by the client device or management server and securely configured into the local user database of the network switch during the initial registration or configuration phase of the client device.

7. The method of claim 6, wherein the method further comprises: receiving a client certificate from the client device; and verifying the client certificate. 7 The reference hash value is generated and configured in a centralized manner. Specifically, when issuing a client certificate to a client, the network management platform or configuration server can simultaneously perform the following operations: obtain the public key portion of the client's certificate and calculate the reference hash value by combining it with its private key in a secure environment. The calculation formula is wherein Hash is a predefined strong hash algorithm, and || represents data splicing. Then, the management security mode will write the identity of this user and the corresponding to the local user database of all network switches that this user can access; in this process, the private key is only used for calculation and will not be stored on the management platform or transmitted to the switch; finally, a local user table is formed on the network switch.

8. The switch local access authentication method based on client certificates as described in claim 6, characterized in that: The generation and configuration of the reference hash value employs client-assisted configuration. Specifically, after the client device successfully accesses the network for the first time through the standard EAP-TLS process, the remote authentication server can include a setting instruction in the authentication success message, or the client software can be configured to allow the client to calculate its own reference hash value within the established secure TLS tunnel. The system then sends the hash value of the credential to the switch. Upon receiving the hash value, the switch associates it with the currently successfully authenticated user identity and stores it in its local database as a backup credential for the future. Ultimately, a local user table is formed on the network switch.

Images