System and method for secured network access

Abstract

A method and system for secured network access is provided in accordance with the present invention. The method begins with receiving a login request from a client on a router. Thereafter, a certificate transfer instruction for the router to an authentication appliance is generated where the client lacks a copy of a client certificate. The client is authenticated with a challenge-response sequence, the response to which is deliverable through an out-of-band communications channel. Upon authentication, the client certificate and the client private key are transmitted to the client, which are used to authenticate the client to the network.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

These and other features and advantages of the various embodiments disclosed herein will be better understood with respect to the following description and drawings, in which like numbers refer to like parts throughout, and in which:

FIG. 1 is a block diagram illustrating an environment in which one aspect of the present invention may be implemented, including various interconnected servers, clients and Virtual Private Networks (VPNs);

FIG. 2 is a flowchart illustrating a method for bi-directionally authenticating a client and a server in accordance with an aspect of the present invention;

FIG. 3 is a sequence diagram illustrating the exchange of data for authenticating the client and the server;

FIG. 4 is a sequence diagram illustrating the establishment of a Transport Layer Security (TLS) connection between the client and the server;

FIG. 5 is one embodiment of a digital certificate in accordance with an aspect of the present invention including various subparts thereof;

FIG. 6 is one embodiment of a response packet including a user certificate, a full requested URL, a token, and a server certificate;

FIGS. 7 a-c is a flowchart illustrating the verification of the response packet;

FIG. 8 is a first exemplary configuration of the mutually authenticating client and server where the certificate and telephony servers are controlled by a third party provider;

FIG. 9 is a second exemplary configuration of the mutually authenticating client and server in which the certificate and telephony servers are controlled by an organization controlling the server;

FIG. 10 is a third configuration of the mutually authenticating client and server where secure access to web services is provided; and

FIG. 11 is a fourth exemplary configuration in which the client and the VPN resource are mutually authenticated.

Common reference numerals are used throughout the drawings and the detailed description to indicate the same elements.

DETAILED DESCRIPTION

The detailed description set forth below in connection with the appended drawings is intended as a description of the presently preferred embodiment of the invention, and is not intended to represent the only form in which the present invention may be constructed or utilized. The description sets forth the functions and the sequence of steps for developing and operating the invention in connection with the illustrated embodiment. It is to be understood, however, that the same or equivalent functions and sequences may be accomplished by different embodiments that are also intended to be encompassed within the spirit and scope of the invention. It is further understood that the use of relational terms such as first and second, and the like are used solely to distinguish one from another entity without necessarily requiring or implying any actual such relationship or order between such entities.

With reference to FIG. 1, an exemplary computer network 10 includes various data processing apparatuses or computers 12, 14. More particularly, the computers 12 may be personal computers or workstations that function as clients, and include a system unit 16 that houses a central processing unit, storage devices, and the like. The computers 12 may also include a display unit 18, and input devices 20 such as a keyboard 20a and a mouse 20b. It is understood that the system unit 16 receives various inputs from the input devices 20 that alter the control and flow of preprogrammed instructions being executed by the central processing unit, and the results of such execution are shown on the display unit 18. The computers 14 may be servers that provide data or services to the client computers 12. In this regard, the term “client” is understood to refer to the role of the computers 12 as a requestor of data or services, while the term “server” is understood to refer to the role of the servers 14 to provide such data or services. Additionally, it is possible that the computers 12 may request data or services in one transaction and provide data or services in a transaction, thus changing its role from client to server or vice versa. It is further understood that the term “server” as utilized herein may also refer generally to networked services such as a Secure Sockets Layer/Transport Layer Security (SSL/TLS) Virtual Private Network (VPN), through which conventional servers 14 provide data and applications to remote clients.

The computers 12, 14 are connected to a wide area network such as the Internet 22 via network connections 24. Requests from the client computers 12 and requested data from the server computers 14 are delivered through the network connections 24. According to an embodiment of the present invention, the server computers 14 are web servers, and the client computers 12 include web browsing applications such as Microsoft Internet Explorer that visually renders documents provided by the server computers 14 on the display unit 18. It will be appreciated that the network topology shown in FIG. 1 is presented by way of example only and not of limitation, and any other type of local or wide area network may be readily substituted without departing from the scope of the present invention. It is understood that any well known data transmission protocol may be utilized for the network connections 24 and the internet 22.

As a further example, a first server computer 14a may be an electronic banking web server that provides account information and funds transfer functionality. Additional uses are also contemplated, where the first server computer 14a hosts a mail server, an online shopping site, or a Microsoft .NET application. A user on the first client computer 12a may log on to first server computer 14a to retrieve the account balance and transfer funds to a separate account using a web browser. In this exemplary context, one of the considerations of information security includes ensuring that the user on the first client computer 12a is who he asserts to be. For example, a malicious user on a second client computer 12b may have all of the credentials of the user on the first client computer 12a to log on to the first server computer 14a without recognizing that such access is fraudulent. Another consideration is ensuring that the first server computer 14a is under the control of a bank of which the user on the first client computer 12a is a customer. It may be possible that the second server computer 14b is masquerading as the first server computer 14a in a phishing attempt, and the first client computer 12a may have been misdirected to the second server computer 14b. Additionally, all legitimate data transfers between the first client computer 12a and the first server computer 14a must not be intercepted by any of the other computers, including a third client computer 12c, the second client computer 12b, and the second server computer 14b.

As indicated above, instead of a specific server computer 14a, the clients 12 may access a VPN 15. The VPN 15 may be connected to the Internet 22 via a VPN router 17 for permitting remote access to the clients 12. It is understood that the VPN router 17 is the only modality through which outside clients 12 may access a server 14c on a local network 19. The same security concerns noted above are equally applicable to the VPN 15, and thus it is contemplated that the methods and systems of the present invention may be implemented therefor, as will be described in further detail below.

An aspect of the present invention relates to a method of mutually authenticating the client computer 12 and the server computer 14. With reference to the flowchart of FIG. 2 and additionally to the sequence diagram of FIG. 3, the method initiates with a step 200 of transmitting a token 26 from the client computer 12 to the server computer 14 over an unsecured data link 27. However, prior to the transmission of the token 26, there may be an additional step of the client computer 12 initiating the unsecured connection 27 with the server computer 14. For example, the user may input the network address of the server computer 14 into the browser application on the client computer 12, at which point a request is made for a file or page on the server computer 14. The token 26 is also referred to as a certificate request identifier, and contains a random value that identifies the particular request. As will be described in further detail below, the token 26 is maintained on the server computer 14 to ensure that only transactions referenced by the certificate request identifier are deemed valid. It is understood that the random value prevents replay attacks. According to one embodiment of the present invention, the token 26 is accompanied by a certificate retrieval script 28, which directs the browser to begin the process of authenticating the client computer 12.

Thereafter, according to step 210, a secure data transfer link 30 is initiated by the client computer 12 utilizing a full requested Uniform Resource Locator (URL) 32. In accordance with a preferred embodiment, the secure data transfer link 30 is a symmetric TLS link. In further detail with reference to the sequence diagram of FIG. 4, the client computer 12 initiates a connection to the server computer 14 by transmitting a synchronize, or SYN packet 34. Thereafter, the server computer 14 transmits a synchronize and acknowledge, or SYN+ACK packet 36 to the client computer 12. Upon receipt, the client computer 12 re-sends an acknowledge, or ACK packet 38 to the server computer 14. As understood, the foregoing transmissions relate to the Transmission Control Protocol (TCP), a protocol layer underneath the TLS protocol.

Upon establishing a TCP connection between the client computer 12 and the server computer 14, a CLIENT_HELLO command 40 is sent from the client computer 12 to the server computer 14. This packet includes the highest version of TLS supported by the client computer 12, the ciphers and data compression methods supported by the client computer 12, a session identifier, and random data. Upon receipt of the CLIENT_HELLO command 40, the server computer 14 transmits a SERVER_HELLO command 42. The SERVER_HELLO command 42 includes the version of TLS, cipher, and data compression method that has been selected. Additionally, the previously set session identifier is included, as well as additional random data. Thereafter, the server computer 14 transmits the CERTIFICATE command 44, which includes a server certificate 46, and a SERVER_DONE command 48, which indicates that the server computer 14 has completed this handshaking phase.

The server certificate 46 is understood to be in conformance with the X.509 standard. More particularly, with reference to FIG. 5, the data stored in the server certificate 46 includes a version number 51, a serial number 52, an issuer identifier 54, a validity identifier 55, a subject public key information 57 including a public key algorithm identifier 57a and a subject public key 57b, and a certificate signature 59. The version number 51 identifies the version of the X.509 standard being used for the particular certificate, while the serial number 52 is a unique number assigned by a particular CA. The issuer identifier 54 includes the name of the CA that issued the certificate, and a validity identifier 55 includes a validity date range with earlier and later limits. The subject identifier 56 contains the name of a person, group, or organization to which the certificate was issued. The subject public key algorithm identifier 57a denotes the algorithm used to generate the subject public key 57b, and the subject public key 57b contains the public key associated with the certificate. The certificate signature 59 contains a signature as generated by the CA. As further understood, the server certificate 46 includes a corresponding server private key 50.

After verifying the authenticity of the sever certificate 46, the client computer 12 transmits a CERTIFICATE_VERIFY command 66. Additionally, the client computer 12 transmits a first CHANGE_CIPHER SPEC command 68, followed immediately by a first FINISHED command 70. This indicates that the contents of subsequent TLS record data sent by the client computer 12 during the current session will be encrypted. It is understood that the first FINISHED command 70 includes a digest of all handshake commands previously transmitted to ensure that no alteration occurred. Next, the server computer 14 transmits a second CHANGE_CIPHER_SPEC command 72, followed immediately by a second FINISHED command 74. Like the first CHANGE_CIPHER_SPEC command 68, the second CHANGE_CIPHER SPEC command 72 indicates that subsequent TLS record data sent by the server computer 14 during the current session will be encrypted. The second FINISHED command 74 includes all prior handshake commands from the server computer 14 to the client computer 12. The client computer 12 transmits a generated symmetric key that is encrypted with the subject public key 57b in the server certificate 46. The server private key 50 is used to decrypt to the symmetric key upon receipt by the server computer 14, and subsequent transmissions to the client computer 12 will be encrypted therewith.

As indicated above, the client computer 12 securely retrieves the server certificate 46 in accordance with an aspect of the present invention. Specifically, according to the process of establishing the TLS connection 30 between the client computer 12 and the server computer 14, the server certificate 46 is transmitted. In one embodiment, the client computer 12 stores the server certificate 46 for use outside the context of the TLS connection 30, as will be detailed further below.

Referring back to FIGS. 2 and 3, the method for mutually authenticating the client computer 12 and the server computer 14 continues with a step 220 of transmitting a response packet 76 to the server computer 14. In further detail as shown in FIG. 6, the response packet 76 is comprised of the full requested URL 32, the token 36, the server certificate 46, and a client certificate 78. The structure of the client certificate 78 is identical to that of the server certificate 46, and as shown in FIG. 5, includes the version 51, the serial number 52, the issuer 54, the validity identifier 55, the subject identifier 56, the subject public key information 57a,b, and the certificate signature 59. According to one embodiment of the present invention, the Microsoft CryptoAPI libraries are utilized to retrieve the client certificate 78 from a certificate storage location. Like the server certificate 46, the client certificate 78 also has a corresponding private key, a client private key 80. The response packet 76 includes an additional authentication identifier correlated to the client private key 80. According to one embodiment of the present invention, such authentication identifier is a cryptographic hash 77 of the contents of the response packet 76. By way of example only and not of limitation, the Message Digest Algorithm-2 (MD2) hash function is used, though any other hash function such as Message Digest Algorithm-5 (MD5), Secure Hash Algorithm (SHA) or the like may be substituted without departing from the scope of the present invention. The resulting cryptographic hash 77 is signed with the client private key 80

According to step 230, the method further includes validating the contents of the response packet 76. First, the authenticity of the response packet 76 itself is verified. As indicated above, the response packet 76 includes the cryptographic hash 77 that has been signed with the client private key 80. With reference to the flowchart of FIGS. 7a-7c, according to step 300, the client-side cryptographic hash 77a is decrypted using the client certificate 78. A server-side cryptographic hash is computed for the response packet 76 as existing on the server 14. The server-side cryptographic hash is compared against the client-side cryptographic hash 77 accompanying the response packet 76 per comparison step 312. If the values do not match, then the response packet 76 is deemed to have been tampered with, and any connections are terminated as in step 315. If the values match, further verification of the contents of the response packet 76 continues as will be described below.

Such further verification includes comparing the constituent parts of the response packet 76 with known copies thereof. First, the signature of the client certificate 78 is validated per step 320, where the subject public key information 57b is verified. Thereafter, the certificate signature 59 and the issuer identifier 54 are examined to confirm that a properly recognized CA has signed the client certificate 78 per step 330. The subject identifier 56 is also examined to confirm that the client certificate 78 was issued to a properly recognized organization according to step 340. According to one embodiment, a properly recognized organization refers to a legitimate organization having control over the server computer 14. Additionally, the client certificate 78 is confirmed to be valid and unexpired by comparing the validity identifier 55 of the client certificate 78 against the current date per step 350. If any of the foregoing validation step fails, the client certificate 78 is deemed to have been tampered with, and drops the connection per step 315.

The remaining components in the response packet 76 is also verified, including the full requested URL 32, the token 26, and the server certificate 46. As described above, the token 26, or the certificate request identifier is stored in the server computer 14. Per step 360, such stored value of the token 26 is compared against value of the token 26 in the response packet 76. It is understood that matching values confirms that no replay attacks are taking place. With respect to the full requested URL 32 in step 370 the value thereof is verified against the actual URL of the server computer 14. This is understood to verify that no phishing attacks are taking place that redirect the client computer 12 to a malicious server. With respect to the server certificate 46 included in the response packet 76, per step 380 it is compared against the server certificate 46 residing on the server computer 14. This prevents man-in-the-middle attacks, as a different server certificate 46 from the one stored on the server computer 14 as opposed to the one being returned via the response packet 76. Along these lines, if any of the foregoing verifications fails, the connection between the server computer 14 and the client computer 12 is immediately broken, and no further access to the server computer 14 is permitted. If there are no anomalies, however, the client computer 12 is authenticated and continues to access the server computer 14. As will be appreciated, the foregoing verifications discover one or more security breaches.

With reference to FIG. 8, according to another aspect of the present invention, the client computer 12 includes a client authentication module 82, and the server computer 14 includes a server authentication module 84. The client authentication module 82 is understood to handle the processes on the client side as discussed above, including retrieval of the token 26, the script 28, the server certificate 46, and the client certificate 78, as well as the transmitting of the response packet 76 after signing the same with the client private key 80. According to one embodiment, the client authentication module 82 is an Active-X component that is installed with a single user interaction via the web browser on the client computer 12. However, alternative executable components that may be added on to the browser are also deemed to be within the scope of the present invention. The server authentication module 84 is understood to handle the processes on the server side as discussed above, including transmission of the token 26 and the server certificate 46, as well as the validation of the received response packet 76. Thus, the client authentication module 82 and the server authentication module 84 communicate with each other, and together implement an X.509 authentication scheme without the deployment of client-side TLS.

In the context of SSL VPNs as shown in FIG. 11, it is contemplated that the foregoing authentication process is performed by the VPN router 17. Thus, it is to be understood that the previously described role of the server 14 may also be performed by the VPN router 17, i.e., the server authentication module 84 also exists in the VPN router 17. Along these lines, it is also contemplated that the client 12 capable of communicating with the VPN 15 likewise includes the client authentication module 82. In accessing the VPN router 17, the client 12 initiates a communication dialogue with the VPN router 17 over a conventional web browser. After completing the authentication process, the client 12 is provided access to the VPN 15 in accordance with the security policies thereof as dictated by the VPN router 17. In other words, the user may be prompted with additional application or server-specific authentication modalities to gain access to the server 14c.

Referring to FIG. 8, it will be appreciated that the aforementioned authentication method presupposes that a client certificate 78 and a corresponding client private key 80 already exist on the client computer 12. The server authentication module 84 may determine whether or not the client certificate 78 exists on the client computer 12, and if not, the server authentication module 84 alerts a certificate server 86. Prior to issuing a client certificate and the client private key 80 to the client computer 12, the user associated therewith is authenticated via an out-of-band modality. According to one embodiment, the server authentication module 84 notifies a telephony server 88 to deliver a one-time password to a cellular phone or a landline phone under the control of the user. Alternatively, an e-mail or a Short Message Service (SMS) text message may be sent. Other out-of-band authentication techniques are contemplated, such as voice recognition, IP address verification, and the like. The entry of the one-time password may be handled through the server computer 14 with the server authentication module 84. In lieu of, or in addition to the foregoing out-of-band authentication, the user may be presented with an additional knowledge-based authentication. For example, the user may be asked about their favorite color, the high school they attended, and other similar questions.

Upon supplying the correct response, the server authentication module 84 directs the certificate server 86 to generate the client private key 80 and the corresponding client certificate 78, and store it on the client computer 12. The client certificate 78 may contain both identification and authorization information. In order to identify the particular user, the User ID, first name, last name, and employee identification information such as employee number may be incorporated into the client certificate 78. Further, authorization data such as enterprise name, organization name, workgroup, and other group-based permission system data may be incorporated into the client certificate 78. Additional authentication information may be stored in an enterprise database 90 for later retrieval and use by the server authentication module 84. It is understood that the foregoing procedure “registers” the browser on the client computer system 12 with the server computer 14, effectively making such browser a second authentication factor (“Something the user has”).

According to another embodiment of the present invention, the procedure described above of issuing the client certificate 78 and the corresponding private key 80 is also performed in the context of the SSL VPN 15 as shown in FIG. 11. When the client 12 initiates a connection to the VPN router 17 with a conventional web browser, the VPN router 17 searches the client 12 for a pre-existing client certificate 78. Finding none, the VPN router 17 generates a certificate transfer instruction 98 to a dedicated authentication appliance 100.

The authentication appliance 100 directs the telephony server 88 to deliver a one-time-password or authoritative response to a cellular phone, landline phone, or e-mail address previously known to be under the control of a user of the client 12. As indicated above, the one-time-password is delivered over a communications modality that is independent of, or out-of-band with respect to, the data communication link between the client 12 and the VPN router 17. The telephony sever 88 may be managed by a third party, or by the organization that manages the VPN 15. The authentication appliance 100 directs the user on the client 12 to enter the authoritative response 102. Along these lines, it is understood that the telephony server 88 and the step of transmitting the authoritative response 102 to the client 12 may be omitted, where the authoritative response 102 is an answer to a knowledge-based question. This answer is contemplated as being pre-defined by the user at an earlier time.

Additionally, the authentication appliance 100 may query the server 14c, which is a part of the VPN 15, to ensure that the client 12 has the authorization to access any resources thereon as a secondary authentication modality. It is contemplated that the server 14c has associated therewith its own username/password authentication scheme, and the authentication appliance 100 queries it. The server 14c may be an Active Directory server, a Lightweight Directory Access Protocol (LDAP) server, a database server, and so forth.

Upon successfully authenticating the client 12, the authentication appliance 100 directs the certificate server 86 to generate the client certificate 78 and the client private key 80. The client certificate 78 and the client private key 80 are transmitted first to the authentication appliance 100, which transmits the same to the client 12 for storage thereon. As described above, the certificate server 86 may be hosted by a third party or by the enterprise that manages the VPN 15. According to one embodiment of the present invention, the authentication appliance 100 communicates with the certificate server 86 via a secured WSE 3.0 WebService call.

As indicated above, the issuer identifier 54 is examined to confirm that a properly recognized CA has issued and signed the client certificate 78. According to the embodiment shown in FIG. 8, the certificate server 86 is the CA, and is understood to be within the control of a legitimate third party provider separate from the organization managing the server computer 14 and the enterprise database 90. In an alternative configuration shown in FIG. 9, the certificate server 86 and the telephony server 88 are managed and maintained by the same organization managing the server computer 14. In yet another configuration shown in FIG. 10, secure access is being enabled for web services 92. As understood, the term web service 92 refers to a standardized system for supporting machine to machine interaction. In this case, the client computer 12 utilizes the client authentication module 82 to authenticate with the server computer 14. The client certificate 78 thus generated is utilized to authenticate a W3 client to authenticate with the web service 92 via the client certificate 78.

In addition to the foregoing configurations, it is expressly contemplated that the client authentication module 82 and the server authentication module 84 may be integrated into a wide variety of applications requiring bi-directional authentication. By way of example only and not of limitation, these include .NET forms authentication in .NET applications, Microsoft Outlook Web Access, and Microsoft Sharepoint, as well as any other system with enforcement points that require proper client and server authentication.

The particulars shown herein are by way of example and for purposes of illustrative discussion of the embodiments of the present invention only and are presented in the cause of providing what is believed to be the most useful and readily understood description of the principles and conceptual aspects of the present invention. In this regard, no attempt is made to show any more detail than is necessary for the fundamental understanding of the present invention, the description taken with the drawings making apparent to those skilled in the art how the several forms of the present invention may be embodied in practice.

Claims

1. A method for authenticating a client and a network resource comprising: receiving on the network resource an initialization command from the client over an unsecured data transfer link;transmitting a token from the network resource to the client in response to the initialization command;establishing a secure data transfer link between the network resource and the client, a network resource certificate being transmitted to the client during the establishment of the secure data transfer link;receiving on the network resource a response packet including a full requested network address identifier, a client certificate, the network resource certificate, the token, and an authenticity identifier corresponding to a client private key, the client private key being associated with the client certificate; andvalidating the response packet.

2. The method of claim 1, wherein the network resource is a Secure Sockets Layer (SSL) Virtual Private Network (VPN).

3. The method of claim 2, further comprising: authenticating the client to a server accessible through the SSL VPN with a challenge-response sequence specific to the server.

4. The method of claim 1, further comprising: enabling access of the client to the network resource in accordance with security policies of the network resource.

5. The method of claim 1, wherein prior to establishing the secure data transfer link between the network resource and the client, the method includes: generating a certificate transfer instruction from the network resource to an authentication appliance, wherein the client lacks the client certificate;authenticating the client with a primary challenge-response sequence; andissuing the client certificate and the corresponding client private key to the client from the authentication appliance.

6. The method of claim 5, wherein a response to the primary challenge-response sequence is transmitted out-of-band to a predetermined data communication device independent of the client and associated with a user of the client.

7. The method of claim 5, wherein a response to the primary challenge-response sequence is transmitted out-of-band to a predetermined e-mail address associated with a user of the client.

8. The method of claim 5, wherein a response to the primary challenge-response sequence is predefined by a user of the client.

9. The method of claim 5, wherein prior to issuing the client certificate, the method further includes: authenticating the client with a secondary challenge-response sequence associated with a server accessible through the network resource.

10. The method of claim 5, wherein prior to issuing the client certificate and the client private key, the method includes: generating the client certificate and the client private key on an independent certificate authority server.

11. A method of issuing a client certificate for SSL VPN access, the method comprising: receiving a login request from a client on a VPN router;generating a certificate transfer instruction from the VPN router to an authentication appliance where the client lacks a pre-existing copy of the client certificate;authenticating the client with a primary challenge-response sequence in response to receiving the certificate transfer instruction from the VPN router, an authoritative response to the primary challenge-response sequence being deliverable through an out-of-band communications channel;generating the client certificate and a client private key; andtransmitting the client certificate and the client private key to the client for storage thereon.

12. The method of claim 11, wherein the authoritative response is a one-time-password.

13. The method of claim 11, wherein the authoritative response is predefined according to knowledge particular to a user of the client.

14. The method of claim 11, wherein prior to generating the client certificate and the client private key, the method further includes: authenticating the client with a secondary challenge-response sequence associated with a server resource on the SSL VPN.

15. A system for bi-directionally authenticating a client and a network resource comprising: an authentication appliance in communication with the network resource and the client, for issuing a client certificate and a client private key to the client upon a successful authentication thereof;wherein the network resource validates the client certificate against a network resource certificate, the client certificate being received from the client upon the establishment of a secure data transfer link between the network resource and the client.

16. The system of claim 15, wherein the network resource is an SSL VPN.

17. The system of claim 15, further comprising: an out-of-band authentication server for transmitting a challenge response to a communications device associated with a user of the client, the client being authenticated upon the challenge response being validated by the authentication appliance.

18. The system of claim 17, further comprising: a server accessible through the network resource, the client being validated against a secondary challenge-response sequence associated with an access control of the server.

19. The system of claim 15, further comprising: a certificate authority server for generating the client certificate and the client private key.

20. The system of claim 15, further comprising: a client authentication module associated with the client and including a memory for storing the client certificate and the client private key, the client authentication module being in communication with the authentication appliance.

21. The system of claim 20, wherein the client authentication module is a browser-executable code downloaded from the authentication appliance.

22. An article of manufacture comprising a program storage medium readable by a data processing device, the medium tangibly embodying one or more programs of instructions executable by the data processing device to perform a method for authenticating a client and a network resource, the method comprising: receiving a login request from a client on a VPN router;generating a certificate transfer instruction from the VPN router to an authentication appliance where the client lacks a pre-existing copy of the client certificate;authenticating the client with a primary challenge-response sequence in response to receiving the certificate transfer instruction from the VPN router, an authoritative response to the primary challenge-response sequence being delivered through an out-of-band communications channel;generating the client certificate and client private key pair;transmitting the client certificate and client private key pair to the client for storage thereon.