Browse Prior Art Database

System and Method for Server-Based VPN SecureID Generation Using a Mobile Device

IP.com Disclosure Number: IPCOM000131886D
Publication Date: 2005-Nov-21
Document File: 2 page(s) / 50K

Publishing Venue

The IP.com Prior Art Database

Abstract

When a mobile professional starts at a company, they are assigned things things to communicate - a laptop, a mobile device, and a SecureID token. The SecureID token enables the user to connect to their corporate intranet via a VPN connection across an RSA server. The SecureID token info is passed to a back-end RSA server that has an algorithm running that is in line with the token. By combining a user-known PIN with a randomly generated password, the user can securely log into his intranet. Once the RSA server authenticates you with the VPN server, it encrypts and allows your traffic dependant on the rules that have been specified with your account. Although the SecureID token is a novel way to enable VPN connection, there are several disadvantages to this: - The token is prone to being lost or being misplaced. - The token has a limited life (i.e., must be replaced once battery dies). - The token must be handled out to each employee that wishes to VPN in which can be costly proposition. It has been suggested to use the mobile device to generate the random password based on a known algorithm running on device. However, this approach may also be limiting because it may be processor- and/or memory- intensive and may drain the battery. There is a need for another approach to replace the functionality of a SecureID token. This solution attempts the replacement of a SecureID token by using a client-server model wherein a centralized server (preferably secured behind the corporate firewall) generates the random password. This solution consists of the following: - A client application on mobile device, which can be a Web- or MDS-enabled application. - An algorithm server that runs an algorithm to generate a random password. This server may be the VPN authentication server or a separate algorithm server secured behind the corporate firewall. This is how a user would use it: - When a user starts at company, he is issued a mobile device and a laptop. - If the user wishes to “VPN” into the office from his laptop (i.e., from home, on road, etc), he would access the VPN application on his mobile device (via browser or MDS app) to retrieve a random password. - The mobile device makes a wireless connection to algorithm server via a MDS connection. - The mobile device sends a request with timestamp, a unique identifying number (UID) of the device, and some user password. - The request reaches the authentication server and is authenticated based on known user profile stored on server. - If authentication is successful (based on info provided), the algorithm server sends back a list of the next 3-5 passwords for login (based on time). - The user takes one of these passwords and uses it with his known UID in order to VPN into his network on his laptop. The benefit to this solution is that a single algorithm server can support multiple users without having to distribute SecureID tokens to each. Security is not breached because user still needs to enter a UID plus a random password in order to VPN into network. The reason for displaying multiple passwords is due to wireless latency (i.e., it can take more than one minute to access some sites); one password may be invalid once user retrieves it on his device. By displaying the next 2-5 passwords, at least one of these passwords would be valid. Furthermore, by having a server-based model wherein the server does most of the computing, we can use a thin-client application that has a very small footprint (uses less memory, less processor power, less battery energy).

This text was extracted from a Microsoft Word document.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 53% of the total text.

 SEVER-BASED VPN SECUREID GENERATION

System and Method for Server-Based VPN SecureID Generation Using a

Mobile

Device

Disclosed Anonymously

When a mobile professional starts at a company, they are assigned things things to communicate - a laptop, a mobile device, and a SecureID token.

The SecureID token enables the user to connect to their corporate intranet via a VPN connection across an RSA server. The SecureID token info is passed to a back-end RSA server that has an algorithm running that is in line with the token. By combining a user-known PIN with a randomly generated password, the user can securely log into his intranet. Once the RSA server authenticates you with the VPN server, it encrypts and allows your traffic dependant on the rules that have been specified with your account.

Although the SecureID token is a novel way to enable VPN connection, there are several disadvantages to this:

- The token is prone to being lost or being misplaced.

- The token has a limited life (i.e., must be replaced once battery dies).

- The token must be handled out to each employee that wishes to VPN in which can be costly proposition.

It has been suggested to use the mobile device to generate the random password based on a known algorithm running on device. However, this approach may also be limiting because it may be processor- and/or memory- intensive and may drain the battery. There is a need for another approach to replace the functionality of a SecureID token.

This solution attempts the replacement of a SecureID token by using a client-server model wherein a centralized server (preferably secured behind the corporate firewall) generates the random password.

 

This solution consists of the following:

- A client application on mobile device, which can be a Web- or  MDS-enabled application.

- An algorithm server that runs an algorithm to generate a random password. This server may be the VPN authentication server or a separate...