Draft Technical Specifications for Multilevel Security Authentication Device

Transcription

1 Proposed QRs/Tech Specification for Multilevel Security Authentication Device is given below for inviting valuable comments/suggestions from Vendors, suppliers and OEMs. Draft Technical Specifications for Multilevel Security Authentication Device Hard Token S.No Specifications Details Technical Directive 1 Indigenous Hard Token Client does a lot of work which is of critical importance to National Security. Keeping this in mind, we need to ensure that such an important component (Hard Token for Two factor Authentication) should be completely indigenous and manufactured in India Documents submitted by the company along with visit to the manufacturing unit of the company by Technical committee. Submission of Design documents 2 Dynamically generate a new password within every two 3 Hybrid Token (between Time Based One time Password and Challenge Response) 4 Time Sync with the Authentication The Token should generate a new password within every two In TOTP, the password changes after every specific duration of time and is shown on the screen. Not only does this waste battery life but is also a security hazard since a non authorized user may be able to see the password. Challenge response generates a new password when asked by the user. However, this can lead to token going out of sync if a user generates multiple passwords and not use them. The requirements is a Hybrid token which is in sync with the server based on time but only show the password when asked by the user. This ensures security and long battery life. A user will only be able to see the password when physically in possession of the token token should be in sync with the server based on time and no other Check for two consecutive passwords generated by the token. The gap between the two passwords generated should not be more than 120 seconds The Password should be generated by pressing a button and should disappear from the screen after a fixed interval The server should show the same password as the token. The vendor

2 Server 5 Six Digit Numerical Password parameter.i.e. at a given point of time, the server and the token should have the same password for a particular user token should be a six digit numerical password to ensure it cannot be guessed in a given time frame 6 Five Year life The token should have a five year battery life 7 Unique Identity Every token should have an unique identity and should be unique to the user 8 Multi Application Support 9 Small and convenient form factor It should be possible to integrate the same token with other applications if required The token should have a small form factor which can ensure ease of carrying. 10 Token Activation User should be able to activate the token on his own 11 Token bound with user and not user name A user may have two different user names for logging into different applications. The user should use the same token to log into all the applications instead of different tokens for different applications should provide a URL where the user can enter the One Time Password and validate whether the password is correct or incorrect The password generated should be of six numerical digits Data Sheet submitted by company The user should generate passwords on two different tokens. The tokens should show a difference sequence of password generated The same token should be used on two different applications Data Sheet The vendor should provide a URL wherein which the committee should be able to activate the token on its own The user should assign the same token to two different usernames belonging to the same user Draft Specifications for Mobile Token Mobile Token S.No Specifications Details Technical Directive 1 Indigenous Mobile Token Client does a lot of work which is of critical importance to National Security. Keeping this in mind, we need to ensure that such an important component (Mobile Token for Two factor Authentication) should be completely indigenous and developed in India Documents submitted by the company along with visit to the R&D unit of the company by Technical committee. Submission of source code in escrow account if asked for

3 2 Dynamically generate a new password within every two The Token should generate a new password within every two 3 PIN Protected The application should need a PIN to generate the password so as to ensure that device sharing should not automatically lead to sharing of One Time passwords 4 Time Sync with the Authentication Server 5 Six Digit Numerical Password 6 Multi OS Support token should be in sync with the server based on time and no other parameter.i.e. at a given point of time, the server and the token should have the same password for a particular user token should be a six digit numerical password to ensure it cannot be guessed in a given time frame The Mobile token should be available as a software form factor that can be installed on a Windows Mobile, ios, Android, Blackberry etc 7 Unique Identity Every token should have an unique identity and should be unique to the user 8 Multi Application Support 9 IMEI / UID Binding 10 Token bound with user and not user name It should be possible to integrate the same token with other applications if required The mobile token generator should be bound with the IMEI device. The application installed on one IMEI / UID should not be installed on another A user may have two different user names for logging into different applications. The user should use the same token to log into all the applications instead of different tokens for Check for two consecutive passwords generated by the token. The gap between the two passwords generated should not be more than 120 seconds The user should enter a PIN before he would be allowed to see the password The server should show the same password as the token. The vendor should provide a URL where the user can enter the One Time Password and validate whether the password is correct or incorrect The password generated should be of six numerical digits Mobile tokens should be demonstrated on Android, ios and windows platform The user should generate passwords on two different tokens. The tokens should show a difference sequence of password generated The same token should be used on two different applications The user should attempt to install a mobile token on two different handsets. He should not be able to install the same token on more than one handset The user should assign the same token to two different usernames belonging to the same user

4 different applications Draft Specifications for Desktop Token Desktop Token S.No Specifications Details Technical Directive 1 Indigenous Desktop Token Client does a lot of work which is of critical importance to National Security. Keeping this in mind, we need to ensure that such an important component (Software Token for Two factor Authentication) should be completely indigenous and developed in India Documents submitted by the company along with visit to the R&D unit of the company by Technical committee. Submission of source code in escrow account if asked for 2 Dynamically generate a new password within every two The Token should generate a new password within every two 3 PIN Protected The application should need a PIN to generate the password so as to ensure that device sharing should not automatically lead to sharing of One Time passwords 4 Time Sync with the Authentication Server 5 Six Digit Numerical Password token should be in sync with the server based on time and no other parameter.i.e. at a given point of time, the server and the token should have the same password for a particular user token should be a six digit numerical password to ensure it cannot be guessed in a given time frame 6 Multi OS Support The Desktop token should be available as a software form factor that can be installed on a windows / Linux 7 Unique Identity Every token should have an unique identity and should be Check for two consecutive passwords generated by the token. The gap between the two passwords generated should not be more than 120 seconds The user should enter a PIN before he would be allowed to see the password The server should show the same password as the token. The vendor should provide a URL where the user can enter the One Time Password and validate whether the password is correct or incorrect The password generated should be of six numerical digits Desktop tokens should be demonstrated on windows and Linux platform The user should generate passwords on two different

5 8 Multi Application Support 9 IMEI / UID Binding 10 Token bound with user and not user name unique to the user It should be possible to integrate the same token with other applications if required The desktop token generator should be bound with the Mac ID device. The application installed on one Mac ID should not be installed on another A user may have two different user names for logging into different applications. The user should use the same token to log into all the applications instead of different tokens for different applications tokens. The tokens should show a difference sequence of password generated The same token should be used on two different applications The user should attempt to install a Desktop token on two different Desktops / Laptops. He should not be able to install the same token on more than one handset The user should assign the same token to two different usernames belonging to the same user Draft Specifications for Authentication Appliance S.No Specifications Details Technical Directive 1 Same Authentication Server for Hard Token, Mobile Token, Desktop Token and SMS Token The same authentication server should be used to authenticate both the Hard Token user as well as SMS token user Using the same server, user should be able to assign different types of tokens 2 Ease of Integration The authentication server should be easily integrated to the current running VPN 3 No access to user password The authentication server should not have any access to regular (static) password of the user. It should only be used to validate the OTP of the user 4 Custom Plug Ins It should be possible to integrate the Token with applications such as Microsoft Outlook, where the OTP should be valid for a specific duration of time 5 Sync users and user details It should be possible to sync all the users from the current LDAP server being used by client. The server should regularly sync with LDAP and make auto modifications where necessary 6 Lock / Unlock a user The system should have provision to lock a particular user on numerous wrong attempts or unlock a particular user Date sheet and Architectural diagram. A Proof of concept if required Data Sheet and Technical Specifications. Data Sheet and technical specifications. A proof of concept if required Data Sheet. A proof of concept if required The user should be log onto the server and lock / unlock a user

6 7 Associate users to Token 8 Multi-Tenant Architecture 9 Policy set for different tokens and users 10 Authenticate different applications with the same server The authentication server should have provision to assign a Hard Token / SMS Token to a user The authentication server should have provision to create separate logical groups and if required create separate administrator(s) for these groups The authentication server should allow the administrator freedom to create his own policies and assign them to different set of users It should be possible to integrate multiple applications with the same server including web as well as desktop mail client login. It should be possible to assign different set of policies for each 11 Manage Tokens The server should allow the administrator to manage tokens, block lost tokens, assign new tokens etc 12 GUI The software should have an easy to use GUI 13 Back Up It should be possible to schedule a backup of the server 14 High Availability The solution should be provided with High Availability and automatic failover between each system. 15 Logs The access logs generated by the OTP system should provide the following audit trails - An easy to use GUI where the user should be able to assign tokens on his own using the authentication server create different admins for different applications create different set of policies for different users on same server create authentication modules for different applications on same server assign, lock / unlock a token from the server All functionality defined should be done via GUI schedule a backup using the GUI Data Sheet and technical specifications see the logs on the GUI 1. Time stamped 2. IP address of the calling system (client system requesting for authentication) 3. Unique ID / serial no of the token. 16 Multi-OS Support It should be possible for the Appliance to work on Linux / Solaris / Windows / Vmware environments. Data Sheet submitted by company 17 Support a wide The solution should support Data Sheet submitted by

7 variety of VPN s integration with most popular firewalls, SSL IPSEC VPNs, routers, RADIUS servers, NAC clients, VPN clients, Citrix servers window servers( and 64 bit) local and RDP logon, wireless access points etc. 18 Token Assignment Should provide inbuilt database for user record creation and token assignment that could be automatically synced with external LDAP 19 Reports Should provide extensive reporting capability including but not limited to inbuilt reports like: company assign tokens using the GUI see the reports on the GUI 1. Users with Disabled Accounts 2. Users with Days Since Last Login Locked User Accounts 3. Principals Never Logged In with Token Authentication Activity 20 Inbuilt RADIUS Authentication server should have inbuilt RADIUS Server for ease of integration with end systems that support RADIUS based authentication. 21 Training The proposed solution should include user awareness training and administration training modules required to be delivered as part of the on boarding process Data Sheet Support letter issued by the company Hardware Specifications 1 CPU 1 * Intel Xeon X GHz Data Sheet 6.4GT/s, Core 12MB Cache or above 2 MotherBoard Intel S5520HCR Data Sheet 3 DDR III RAM 24 GB or above Data Sheet 4 HDD 12TB SATA 7.2K RPM or above Data Sheet

8 Please forward your valuable Comments/Suggestions by clearly mentioning in subject line as QRs suggestion for Multilevel Authentication Device on the following address/route: - Through Mail itwing@crpf.gov.in Through Fax By Hand Room No.325, 3 rd Floor, Block No-1, Directorate General, CRPF, Lodhi Road, New Delhi-3 NOTE:-You are hereby requested to submit the documents also as per given list below. 1. You are OEM/Supplier or otherwise (document in support-scan copy only ). 2. Clearly mention in all paras of QR/Specifications that you are complied with or otherwise. E.g :- S/No. Specifications Requirements Comment Remark 1 Power Supply 230 V + 5%, 50/60 Hz- Standard No Complied 2 Degausser System Capacitive Discharge No Complied 3 Duty Cycle Continuous No Complied 4 Cyclic Time 60 Seconds or less 50 Sec or more Not Complied 5 Display LCD Display to visually provide the user with erase, power & mode verification & other indications No Complied