Entrust. Entrust IdentityGuard 8.1. Deployment Guide. Document issue: 2.0. Date of Issue: April 2007

Transcription

1 Entrust Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0 Date of Issue: April 2007

2 Copyright 2007 Entrust. All rights reserved. Entrust is a trademark or a registered trademark of Entrust, Inc. in certain countries. All Entrust product names and logos are trademarks or registered trademarks of Entrust, Inc. in certain countries. All other company and product names and logos are trademarks or registered trademarks of their respective owners in certain countries. This information is subject to change as Entrust reserves the right to, without notice, make changes to its products as progress in engineering or manufacturing methods or circumstances may warrant. Export and/or import of cryptographic products may be restricted by various regulations in various countries. Export and/or import permits may be required. 2 Entrust IdentityGuard 8.1 Deployment Guide

3 Table of contents *About this guide Revision information Documentation conventions Note and Attention text Related documentation Obtaining documentation Documentation feedback Obtaining technical assistance Technical support Telephone numbers address Professional Services CHAPTER 1 About Entrust IdentityGuard Why use Entrust IdentityGuard? Challenges of single-factor authentication Benefits of multilayer authentication Entrust IdentityGuard users Entrust IdentityGuard components Entrust IdentityGuard Server Repository First-factor authentication application Entrust IdentityGuard Radius proxy Entrust IdentityGuard Desktop for Microsoft Windows Entrust IdentityGuard Remote Access Plug-in

4 CHAPTER 2 Authentication choices Overview of available authentication methods Authentication choices for users Token authentication Entrust tokens Other tokens Grid authentication Passcode lists Knowledge-based authentication Sources of questions Creating good questions Ensuring answer consistency Selecting a set of questions Out-of-band authentication Machine authentication Sources of machine information Authentication choices for deploying organizations Grid serial number or grid location replay Image and message replay Temporary PIN authentication External authentication CHAPTER 3 Planning your deployment Planning: initial considerations Entrust IdentityGuard policies People Operations Backup and recovery Other precautions Planning administrative tasks Assigning master users Assigning administrators Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

5 Planning end user requirements Alias and user ID requirements Aliases in a consumer deployment Locking out users Training end users Providing services to end users Group requirements Groups in a consumer deployment Groups in an enterprise deployment Analyzing your company s group needs Group implementation CHAPTER 4 Deployment considerations Application integration Web integration Microsoft Windows integration VPN remote access integration Application considerations Integrating with existing user management systems Using shared secrets Performance testing strategies High availability and disaster recovery Directory failover Local Directory failover Geographically dispersed Directory failover Database failover Radius server failover Migrating to Entrust IdentityGuard CHAPTER 5 Deploying grid authentication Grid requirements Grid size and format Grid lifetime and replacement

6 Challenge requirements Challenge length Challenge size Challenge algorithm Grid production models Produce-and-assign model Produce-and-assign grids for existing users Produce-and-assign grids for new users Preproduction model Physical card security Physical card production options In-house card production Typical characteristics Setup Process Outsourced card production Typical Characteristics Setup Process Entrust IdentityGuard card production Typical characteristics Setup Card production cost factors Secure file transmission Automating processes CHAPTER 6 Deploying token authentication Using tokens for authentication Token lifetime and replacement Token PINs Token deployment Assigning tokens Token self-registration Physical token security Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

7 APPENDIX A User life cycle management Life cycle management overview Enrolment Usage Renewal Replacement Delivery and activation Maintenance APPENDIX B Entrust IdentityGuard baseline architectures Architecture overview Evaluation Standard High availability Web access Web access - evaluation Requirements Available Entrust IdentityGuard authentication methods Web access - standard Requirements Available Entrust IdentityGuard authentication methods Web access - high availability Requirements Available Entrust IdentityGuard authentication methods VPN remote access VPN remote access - evaluation Requirements Available Entrust IdentityGuard authentication methods VPN remote access - standard Requirements Available Entrust IdentityGuard authentication methods VPN remote access - high availability Requirements

8 Available Entrust IdentityGuard authentication methods Microsoft Windows remote access Microsoft Windows remote access - evaluation Requirements Available Entrust IdentityGuard authentication methods Microsoft Windows remote access - standard Requirements Available Entrust IdentityGuard authentication methods Microsoft Windows remote access - high availability Requirements Available Entrust IdentityGuard authentication methods Microsoft Windows desktop Microsoft Windows desktop - evaluation Requirements Available Entrust IdentityGuard authentication methods Microsoft Windows desktop - standard Requirements Available Entrust IdentityGuard authentication methods Microsoft Windows desktop - high availability Requirements Available Entrust IdentityGuard authentication methods APPENDIX C Card usability study Entrust IdentityGuard card usability study Usability test summary Objective Methodology Usability test results Recommendations General guidelines Card design and layout Fonts Use of color Design of the grid Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

9 Grid authentication implementation Web login challenge method Mutual authentication (through displaying a authentication secret) Temporary PIN length Index

10 10 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

11 *About this guide This guide discusses how to deploy Entrust IdentityGuard in an enterprise or consumer environment. Note: The guide is not intended to be an exhaustive list of all the activities and tasks required to deploy Entrust IdentityGuard. It acts as a guide for the team responsible for deployment. Topics in this chapter: Revision information on page 13 Documentation conventions on page 14 Related documentation on page 15 Obtaining documentation on page 16 Obtaining technical assistance on page 17 This guide contains the following sections: About Entrust IdentityGuard on page 19 describes Entrust IdentityGuard and what it does. Authentication choices on page 27 describes and compares the authentication methods and how to deploy them. Planning your deployment on page 57 describes Entrust IdentityGuard deployment planning considerations. Deployment considerations on page 73 describes how to integrate Entrust IdentityGuard into your existing applications. Deploying grid authentication on page 87 describes, in detail, how to deploy grid authentication. Deploying token authentication on page 109 describes, how to deploy token authentication. User life cycle management on page 113 describes the life cycle for an Entrust IdentityGuard user. 11

12 Entrust IdentityGuard baseline architectures on page 123 describes various architectures for deploying Entrust IdentityGuard. Card usability study on page 145 describes a study completed to examine card usability aspects. 12 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

13 Revision information The following sections include updated information. Table 1: Revisions in this document Revision Section Description Document issue 2.0 Token authentication on page 31 Using tokens for authentication on page 110 Updates the information on token authentication. *About this guide 13

14 Documentation conventions Following are typographic conventions which appear in this guide: Table 2: Typographic conventions Convention Purpose Example Bold text (other than headings) Italicized text Blue text Underlined blue text Courier type Angle brackets < > Square brackets [courier type] Indicates graphical user interface elements and wizards Used for book or document titles Used for hyperlinks to other sections in the document Used for Web links Indicates installation paths, file names, Windows registry keys, commands, and text you must enter Indicates variables (text you must replace with your organization s correct values) Indicates optional parameters Click Next. Entrust TruePass 7.0 Deployment Guide Entrust TruePass supports the use of many types of digital ID. For more information, visit our Web site at Use the entrust-configuration.xml file to change certain options for Verification Server. By default, the entrust.ini file is located in <install_path>/conf/security/entrust. ini. dsa passwd [-ldap] Note and Attention text Throughout this guide, there are paragraphs set off by ruled lines above and below the text. These paragraphs provide key information with two levels of importance, as shown below. Note: Information to help you maximize the benefits of your Entrust product. Attention: Issues that, if ignored, may seriously affect performance, security, or the operation of your Entrust product. 14 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

15 Related documentation Entrust IdentityGuard is supported by a complete documentation suite: For instructions on installing and configuring Entrust IdentityGuard Server, see the Entrust IdentityGuard Installation Guide. For instructions on administering Entrust IdentityGuard users and groups, see the Entrust IdentityGuard Administration Guide. For information on deploying Entrust IdentityGuard, refer to the Entrust IdentityGuard Deployment Guide. For information on configuring Entrust IdentityGuard to work with a supported LDAP repository Microsoft Active Directory, Microsoft Active Directory Application Mode, Critical Path InJoin Directory, IBM Tivoli Directory, Novell edirectory, or Sun ONE Directory see the Entrust IdentityGuard Directory Configuration Guide. For information on configuring Entrust IdentityGuard to work with a supported database IBM DB2 Universal Database, Microsoft SQL Server, or Oracle Database see the Entrust IdentityGuard Database Configuration Guide. For information on Entrust IdentityGuard error messages, see the Entrust IdentityGuard Error Messages. For information on new features, limitations and known issues in the latest release, see the Entrust IdentityGuard Release Notes. For information on integrating the authentication and administration processes of your applications with Entrust IdentityGuard, see the Entrust IdentityGuard Programming Guide that applies to your development platform (either Java Platform or C#). For Entrust IdentityGuard product information and a data sheet, go to For information on identity theft protection seminars, go to *About this guide 15

16 Obtaining documentation Entrust product documentation, white papers, technical notes, and a comprehensive Knowledge Base are available through Entrust TrustedCare Online. If you are registered for our support programs, you can use our Web-based Entrust TrustedCare Online support services at: Documentation feedback You can rate and provide feedback about Entrust product documentation by completing the online feedback form. You can access this form by clicking the link located in the footer of Entrust s PDF documents (see bottom of this page). following this link: Feedback concerning documentation can also be directed to the Customer Support address. [email protected] 16 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

17 Obtaining technical assistance Entrust recognizes the importance of providing quick and easy access to our support resources. The following subsections provide details about the technical support and professional services available to you. Technical support Entrust offers a variety of technical support programs to help you keep Entrust products up and running. To learn more about the full range of Entrust technical support services, visit our Web site at: If you are registered for our support programs, you can use our Web-based support services. Entrust TrustedCare Online offers technical resources including Entrust product documentation, white papers and technical notes, and a comprehensive Knowledge Base at: If you contact Entrust Customer Support, please provide as much of the following information as possible: your contact information product name, version, and operating system information your deployment scenario description of the problem copy of log files containing error messages description of conditions under which the error occurred description of troubleshooting activities you have already performed Telephone numbers For support assistance by telephone call one of the numbers below: in North America outside North America address The address for Customer Support is: [email protected] *About this guide 17

18 Professional Services The Entrust team assists e-businesses around the world to deploy and maintain secure transactions and communications with their partners, customers, suppliers and employees. We offer a full range of professional services to deploy our e-business solutions successfully for wired and wireless networks, including planning and design, installation, system integration, deployment support, and custom software development. Whether you choose to operate your Entrust solution in-house or subscribe to hosted services, Entrust Professional Services will design and implement the right solution for your e-business needs. For more information about Entrust Professional Services please visit our Web site at: 18 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

19 Chapter 1 About Entrust IdentityGuard Entrust IdentityGuard is a multifactor authentication product that enhances the security and verifiability provided by a first-factor authentication system. It allows end users to prove their identity when accessing sensitive resources from their Microsoft Windows desktop, remotely through a VPN connection, or over the Web. This chapter includes the following sections: Why use Entrust IdentityGuard? on page 20 Entrust IdentityGuard users on page 22 Entrust IdentityGuard components on page 23 19

20 Why use Entrust IdentityGuard? As online fraud and compliance regulations become more prevalent, standard user name and password authentication no longer offers sufficient security to your organization s sensitive resources. Strong authentication is a tool that your organization likely uses in some form today. Whether it is for VPN remote access, Microsoft Windows security, or Web-based applications, you need to provide strong and flexible authentication to a wide range of users and transactions, based on the risk associated with those transactions. Entrust IdentityGuard provides multiple authentication factors (also referred to as methods ) which your organization can add to its initial user name and password authentication methods to increase security. The various authentication methods Entrust IdentityGuard offers allows you to adjust the strength of the authentication to the sensitivity of the resource or transaction. For example, as the following diagram demonstrates, a company could add Entrust IdentityGuard grid authentication to the user name and password authentication when a remote employee logs in using a VPN connection. User name and password authentication resource End user that requires multifactor authentication Company VPN device Entrust IdentityGuard Server Company firewall Employee repository Topics in this section: Challenges of single-factor authentication on page 21 Benefits of multilayer authentication on page Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

21 Challenges of single-factor authentication Authentication is the process of determining whether someone or something is, in fact, who or what it presents itself as. In private and public computer networks, authentication is commonly done through the use of a user name and password. The user enters their password to authenticate to the application. This method is referred to as single-factor authentication. However, the rapid increase in online identity theft shows that user names and passwords alone which are easy to steal and easy to reuse are not much defense against the ever-increasing sophistication of identity attacks. You need one or more second-factor authentication methods. Benefits of multilayer authentication Multilayer authentication is a solution that adds as many authentication methods as required based on the security context. For example, you can require an employee to log in using a user name and password, a grid challenge, and at the same time, have the authentication application check the computer they are using to ensure it is registered. By adding multiple layers of authentication, an organization accomplished two things: Identities become difficult to steal. With multifactor authentication, it is difficult, if not impossible, for an attacker to steal login data in large numbers. While it is possible to physically steal some authentication data on an individual basis, attackers are usually interested in mass theft. They will get frustrated by the effort. Also, an organization can authenticate itself to its users, making it easier for users to detect redirection to a fraudulent site. The user can then take immediate countermeasures against the likely theft. Stolen identities become difficult to reuse. Your organization can combine multiple authentication factors in ways that make the theft of a single factor useless to the attacker. Without the additional authentication factors, the attacker has either no access to a user s confidential information or can only view trivial information. Also, authentication can be performed at the transaction level making use of different authentication factors depending on the risk associated with the transaction. About Entrust IdentityGuard 21

22 Entrust IdentityGuard users Entrust IdentityGuard users are divided into different categories, based on how they access your organization s resources. See Entrust IdentityGuard baseline architectures on page 123 for diagrams on how Entrust IdentityGuard interacts with these users. The user categories are: Microsoft Windows desktop users These are internal users who, after logging in to your domain using their Windows user name and password, are then challenged for a second factor of authentication (grid authentication). For more information on these users, refer to the Entrust IdentityGuard Desktop Client for Microsoft Windows Administration Guide. Routing and Remote Access Service (RRAS) users These are Microsoft Windows users internal to your organization who access your domain remotely through a dial-up, wireless, or VPN connection and use the Microsoft Routing and Remote Access Service. After logging in to your domain, they are then challenged for a second factor of authentication (grid authentication). For more information on these users, refer to the Entrust IdentityGuard Desktop Client for Microsoft Windows Administration Guide. VPN users These are internal or external users who log into your domain using a VPN connection. The first-factor of authentication (usually a user name and password) can be provided by an existing Remote Authentication Dial In User Service (Radius) server, or Entrust IdentityGuard can leverage Directory or Domain-based authentication information to complete the first-factor authentication itself. Entrust IdentityGuard then challenges these users for a second factor of authentication (either grid or token). For more information, refer to VPN remote access integration on page 75. Web users These are internal or external users to your organization who access your intranet or Internet site by logging in through a Web browser. The first-factor of authentication is completed by a Web access product, and Entrust IdentityGuard can then provide different multi-factor authentication methods as required by the sensitivity of the operation the user wishes to perform. For more information, refer to Web integration on page Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

23 Entrust IdentityGuard components The following diagram shows how Entrust IdentityGuard fits into your existing authentication system. The Entrust IdentityGuard Server and optional components are further described in this section. End user First-factor authentication application Entrust IdentityGuard Server Repository Topics in this section: Entrust IdentityGuard Server on page 23 Repository on page 24 First-factor authentication application on page 25 Entrust IdentityGuard Radius proxy on page 25 Entrust IdentityGuard Desktop for Microsoft Windows on page 25 Entrust IdentityGuard Remote Access Plug-in on page 26 Entrust IdentityGuard Server Entrust IdentityGuard Server is the main component of the Entrust IdentityGuard system. It includes the applications and interfaces required to authenticate and manage users and their authentication data: authentication and administration Web services with Java Platform and C# APIs administration interface and master command shell About Entrust IdentityGuard 23

24 sample Web application that demonstrates Entrust IdentityGuard s capabilities Repository Entrust IdentityGuard uses your existing repository to store user data. When a grid or other authentication data is generated for a user, sensitive data is written in encrypted form to the repository. During user authentication, data is retrieved from the repository. User data is stored in an existing LDAP-compliant Directory (including Active Directory) or a database. If you are using an LDAP-compliant Directory as your repository, consider the following: If your user population is split over multiple search bases in separate directories, you need to set up search bases in Entrust IdentityGuard. Entrust IdentityGuard has combined the support for user groups (see Group requirements on page 69) with support for multiple search bases. It can support multiple search bases for a single group and has the capability to use a single search base to cover multiple groups. Each search base has the capability of using a different Directory server and Directory user credentials. The default configuration uses a single search base. If you are using grid or token authentication, and will be pre-producing the grids or are loading the unassigned token information into the Entrust IdentityGuard system, this information is stored: as a flat file on the Entrust IdentityGuard Server (default) in a separate database, if storing over a 100,000 cards or tokens For more information on the file-based repository options, refer to the Entrust IdentityGuard Installation Guide. When the grid or token is assigned to a user, the information is then populated into their Directory entry. You can set up your repository in a failover scenario. For example: If you are using Active Directory or an LDAP-compliant Directory, you can add multiple URLs to the Entrust IdentityGuard property file. Entrust IdentityGuard will then attempt to connect to the directories in the order you have listed them. If you are using a database, you can set up automatic DNS updates, so that, should the primary database fail, the DNS entry of the database host changes to a secondary entry. This method requires database drivers that support automatic updates and disabling of Java network caching in Entrust IdentityGuard. For more information on failover, refer to High availability and disaster recovery on page Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

25 First-factor authentication application Entrust IdentityGuard integrates with your existing authentication application using the Entrust IdentityGuard authentication and administration Web services, which are used for retrieving challenge requests, authenticating user responses, and managing users and authentication data. This application can be a Radius server, a domain controller, a Web-based access control product, the Microsoft Windows Login feature, and so on. Depending on the type of application, you may need to customize it. For more information, see Deployment considerations on page 73. Entrust IdentityGuard Radius proxy The Entrust IdentityGuard Radius proxy component installs with the Entrust IdentityGuard Server to enable second-factor authentication (either grid or token) for VPN users. It intercepts messages between the VPN server and the first-factor authentication resource. That resource may be a Radius server, a Windows domain controller or an LDAP-compliant Directory. If the resource is a domain controller or Directory, you must use external authentication. For more information, see External authentication on page 56. Once your VPN server uses the Radius proxy for first-factor authentication, you can configure Entrust IdentityGuard to add second-factor authentication methods to the first-factor authentication performed by the Radius proxy. Entrust IdentityGuard Desktop for Microsoft Windows The purpose of the Entrust IdentityGuard Desktop for Microsoft Windows is to be a small-footprint client that communicates with the Entrust IdentityGuard Server. It provides strong second-factor authentication to the following: Windows Login - Microsoft Windows 2000 or Windows XP desktop (online or offline). The Windows Login feature of the Entrust IdentityGuard Desktop for Microsoft Windows allows users to use second-factor grid authentication when they log in to their Microsoft Windows desktop computer. Remote Access - Network access through dial-up, wireless, or Virtual Private Network (VPN) remote access. The Microsoft Routing and Remote Access Service (RRAS) feature enables users to remotely access a network through dial-up or VPN connectivity. When RRAS is installed on the Microsoft Windows desktop computer, a separate product called the Remote Access Plug-in for Microsoft Windows Server must be installed on a Microsoft Server machine. About Entrust IdentityGuard 25

26 Entrust IdentityGuard Desktop Manager is deployed using a Windows installer (.msi) file. You can customize the installer file by applying a transform (.mst file), which is a collection of changes applied to a base.msi file. A central administrator creates a custom installation file and configures the Entrust IdentityGuard options in accordance with your organization s policies and practices. Refer to the Entrust IdentityGuard Desktop for Microsoft Windows Administration Guide for more information. Entrust IdentityGuard Remote Access Plug-in The Entrust IdentityGuard Remote Access Plug-in for Microsoft Windows Server communicates with the Entrust IdentityGuard Desktop for Microsoft Windows Remote Access feature. For the Remote Access feature to connect to a Remote Access Server, the Entrust IdentityGuard Remote Access Plug-in for Microsoft Windows Server must be installed on one of the following supported servers: Microsoft Routing and Remote Access Service (RRAS) Microsoft Internet Authentication Service (IAS) Usually, the RRAS and IAS are on the same computer. If your setup requires these to be on separate computers, it is recommended you install the Remote Access Plug-in on the computer hosting the IAS. When the Remote Access Plug-in for Microsoft Windows Server is installed, an Entrust IdentityGuard Desktop for Microsoft Windows Remote Access client has the ability to connect to the Entrust IdentityGuard Server for user authentication. Refer to the Entrust IdentityGuard Desktop for Microsoft Windows Administration Guide for more information. 26 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

27 Chapter 2 Authentication choices Entrust IdentityGuard provides several authentication choices for your organization to authenticate your users, perform mutual authentication, and register computers. This chapter provides information that describes the implementation considerations for each method. Note: While reading this chapter, consider the frequency of authentication events to which you want to add multifactor authentication. Ensure you gather statistics from your authentication applications and resources, and develop a usage profile for each of the transactions. You can then find an appropriate balance between user convenience, resistance to attack, and the administrative overhead for managing multifactor authentication. Topics in this chapter: Overview of available authentication methods on page 28 Authentication choices for users on page 31 Authentication choices for deploying organizations on page 51 Temporary PIN authentication on page 55 External authentication on page 56 27

28 Overview of available authentication methods This section describes and compares the authentication methods available through Entrust IdentityGuard, and the advantages and considerations of each. Entrust IdentityGuard divides the authentication methods into two categories: User authentication means the user verifies their authenticity to your organization. Examples of user authentication are: token authentication grid authentication passcode list authentication knowledge-based authentication out-of-band authentication machine authentication 28 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

29 Organization authentication means your organization proves itself as authentic. Examples of organization authentication involve different types of replay authentication. Serial replay authentication (grid card serial number ) Image replay authentication (user selected image ) Grid location replay authentication (grid locations shown specific to user) Message replay authentication (user entered message) Combining user and organization authentication methods allows you to set up mutual authentication. Mutual authentication means both the user and your organization verify themselves as legitimate. Mutual authentication works as follows: The user completes first-factor authentication successfully. Entrust IdentityGuard presents the user with a challenge based on the authentication method. The user enters the requested values. Entrust IdentityGuard validates the entered values and authenticates the user. The Entrust IdentityGuard Server installs with a sample Web application that demonstrates how the various authentication methods work, and how you can set up your own applications to integrate with the Entrust IdentityGuard system. The Authentication choices 29

30 Entrust IdentityGuard Installation Guide includes a tutorial that describes what the sample Web application does. To deploy the authentication methods, Entrust IdentityGuard includes policy attributes that allow you to determine the characteristics of the authentication method for groups of users. For more information, see Entrust IdentityGuard policies on page 59 and the Entrust IdentityGuard Administration Guide. The following table provides a brief comparison of the Entrust IdentityGuard authentication methods. Table 3: Comparison of available authentication methods to each other Authentication method Physical requirements for end users Renewal options 1 Token Token hardware when battery dies (expected 6 to 8 years) Sample use Requiring strong second-factor authentication Grid Card Based on use or time Requiring strong second-factor authentication Passcode list Printed List Based on use or time Requiring infrequent one-time authentication Temporary PIN None Based on use or time Card, passcode list, or token is unavailable Knowledge-based None N/A Registering users and/or machines Out-of-band None 2 One-time use only Machine N/A Based on each login, time, or when users change computers Replay (mutual) Card, if using grid N/A location or serial number replay One-time highly sensitive operation Users access organization from personally-owned computers Verification of organization 1. An administrator or application can force a renewal at any time. 2. Users need a telephone number, SMS information, or account in order to receive the one-time password. 30 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

31 Authentication choices for users From a single deployed solution, your organization can choose one or more second-factor methods of authenticating users. The choice depends on the risk of a given transaction or the sensitivity of your resources. The greater the risk of misrepresentation and fraud, the greater the need for additional authentication. The following user authentication methods are available: Token authentication on page 31 Grid authentication on page 32 Passcode lists on page 37 Knowledge-based authentication on page 38 Out-of-band authentication on page 43 Machine authentication on page 44 Considerations for each are described in the following sections. Token authentication Entrust IdentityGuard supports Entrust tokens and some third-party tokens. With tokens, your end users can authenticate themselves using a token dynamic password after completing first-factor authentication. Tokens represent a stronger method of user authentication than knowledge factors alone because they combine possession (the token) and knowledge (the dynamic password). Because the password changes frequently, it is impossible for a hacker to record it and use it later to log in to the system. Entrust IdentityGuard supports tokens that use response-only mode: a single call validates the user-entered password. It does not support challenge/response mode. Entrust tokens Entrust offers robust, competitively priced token devices (and the accompanying token data file) designed to easily integrate with Entrust IdentityGuard applications. Entrust tokens do not require a token PIN (also known as a static PIN). Order Entrust tokens directly from Entrust. (For more information, see Using tokens for authentication on page 110.) Other tokens Entrust IdentityGuard supports tokens from some third-party vendors. For details, refer to the Entrust TrustedCare Online Web site. Authentication choices 31

32 Table 4: Token authentication advantages and considerations Advantages It is easy for end users to use. It is impossible for a hacker to re-use password, making it a very secure second-factor authentication method. Considerations You need to determine whether to use static token PINs, if available. You need to determine how to roll out tokens and train users. Tokens are time synchronous, and therefore the Entrust IdentityGuard Server clock must be accurate to UTC within a 30-second range. Deployment types Web access Microsoft Windows remote access VPN remote access Grid authentication With grid authentication, you provide each user with a printed Entrust IdentityGuard card that contains an assortment of characters in a row and column format. Authentication works as follows: The user completes first-factor authentication successfully. Entrust IdentityGuard presents the user with a challenge based on the grid on their card, as illustrated in Figure 1. The user enters the values from their card corresponding to the requested cell locations in the challenge. In Figure 1, the challenge asks the user to enter the numbers in grid coordinates B1, E4, and G5, which are Entrust IdentityGuard validates the entered values and authenticates the user. By entering the correct response, users demonstrate that they possess the card, thus providing a second factor of authentication. 32 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

33 Figure 1: Entrust IdentityGuard challenge sample John Smith ****** You can set up grid challenges in one of the following ways: One-step authentication In one-step authentication, you combine first and second-factor authentication on a single page. For example, you include the prompt for a user name, a password and a grid challenge on one page. In this approach, the application does not know the identity of the user until after login and authentication; that is, the user is anonymous until both first and second-factor authentication are complete. For an example, see Figure 2 on page 34. Authentication choices 33

34 Figure 2: One-step authentication example Two-step authentication In two-step authentication, the user logs in as usual and is then shown a second dialog containing the Entrust IdentityGuard grid challenge. Because the user has already passed first-factor authentication, the user s identity is known. This lets you add other Entrust IdentityGuard features, such as serial number replay or grid location replay (see Authentication choices for deploying organizations on page 51). For an example, see Figure 3 on page Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

35 Figure 3: Two-step authentication example Authentication choices 35

36 The following table lists some of the advantages and considerations of grid authentication. Table 5: Grid authentication advantages and considerations Advantages It is easy for end users to use (see Entrust IdentityGuard card usability study on page 146). It has a low cost to set up and maintain. If an attacker manages to observe several completed logins including the grid authentication challenge and response, they gain only a fraction of the total grid data. Considerations Consider grid size. For example, a 5 x 10 grid contains 16,000 three-cell challenge sets. Since Entrust IdentityGuard selects the challenge sets randomly or on a least used basis, knowing a few possible challenge-and-response combinations is useless to an attacker because the next challenge is certain to request different cells. Consider grid lifetime. Given that it is unlikely that the attacker would receive the same challenge set captured from an earlier attack, the attacker would be forced to guess at the coordinates. As the attacker obtains more and more of a user s grid contents, less guessing is required. Regular replacement of cards with newly generated grids can help mitigate this risk. Determine whether you need one-step or two-step authentication options (two-step is recommended). Deployment types Web access Microsoft Windows remote access VPN remote access Microsoft Windows desktop Deployment risks and mitigation The most likely form of attack is verifier impersonation or man-in-the middle combined with online guessing. Through mechanisms such as phishing or pharming, an attacker can capture one or more grid authentications made by the user and thus capture some information on their card. Subsequently, an attacker could use this information to attempt to authenticate to the legitimate application. A very important aspect of these attacks is that they are generally short lived. Typical phishing and pharming incidents last only a few days. According to the Anti-Phishing Working Group (APWG) as of March 2005 the average life of a phishing site is 5.8 days. 36 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

37 Passcode lists Passcode list authentication is a type of grid authentication that uses a list of passcodes or transaction numbers (TANs) rather than a card. Each number can be used just once. With this approach, you provide users with a list of randomly generated passcodes for second-factor authentication. Some organizations view passcode lists as easier for their users to use than cards, though our usability study proved card use is quick to learn. (See Card usability study on page 145.) Typically, you distribute these to users on a printed sheet of paper similar to Figure 4. Figure 4: Sample passcode list Then, when a passcode is required, you prompt for the passcode next to a number in the list as in Figure 5. Figure 5: Sample passcode prompt Authentication choices 37

38 The user types the passcode printed on the paper next to the requested number. To reduce susceptibility to phishing or malware attacks, each passcode is used just once. This renders the entered passcode useless should it be captured by an attacker. To help end users remember the one-time use restriction, recommend that they strike used passcodes from the list. Alternatively, create your passcode list as a scratch card, which only reveals the passcode once a covering is scratched off. Table 6: Passcode list authentication advantages and considerations Advantages One-time use of a password makes it impossible for attackers to reuse authentication data. You can create multiple one-time passwords at once, lowering overhead. Considerations Much like the production of a grid, you need to produce and distribute the passcode lists to your users. Unlike grids, however, you will typically wish to send users more than one list at a time. Research your past authentication histories to determine how fast the average user will exhaust a list and send an appropriate number of lists to ensure that users can always authenticate. Additional consideration should be given to the way a passcode list is produced, such as whether it will be a simple list of uncovered passcodes or a covered list much like a lottery scratch card. Cost will be the primary difference between these two options. The number of characters in each passcode should be between five and nine to ensure security and to maintain usability. Choose between numeric or alphanumeric passcodes. Deployment type Web access Deployment risks and mitigation Some phishing attacks target this form of authentication. There are simple ways to increase the security of a passcode list. For example, prompt for passcodes in a random order instead of from first to last. Consider adding another form of authentication, such as machine authentication in conjunction with a passcode list. Alternatively, consider deploying grid authentication instead of a passcode list. Knowledge-based authentication One of the simplest mechanisms for gaining additional confidence in the identity of users is to challenge them to provide information that an attacker likely cannot 38 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

39 provide. The organization can present questions to the user based on information (referred to as authentication secrets) that was supplied by the user at registration or based on previous transactions or relationships. The users in turn recognize the secret questions they set up during registration; so, they know they are at a legitimate site. For example: During enrolment the user may select and provide answers to easily-remembered questions, such as Your most memorable cartoon character, Which historical figure do you most admire, and so on. Questions can be drawn from previous user interactions with the organization. Examples include: What was the balance on your last statement and How often do you make mortgage payments. These have the advantage of being harder for attackers to harvest through other information sources. Entrust IdentityGuard allows organizations to select a number of such authentication secrets or facts for each user and prompt for all answers or just a subset to increase user authentication strength. Figure 6: Sample question-and-answer prompt By maintaining a large set of authentication secrets, organizations can select a subset that makes it more difficult for an attacker to gather impersonating information based on previous authentications. Topics in this section: Sources of questions on page 40 Creating good questions on page 41 Ensuring answer consistency on page 42 Selecting a set of questions on page 42 Authentication choices 39

40 Note: Many of the concepts discussed in the following sections were first presented by Mike Just, in Designing and Evaluating Challenge-Question Systems, IEEE Security & Privacy, vol. 02, no. 5, pp , September-October, Sources of questions There are a variety of methods for developing the questions for knowledge-based authentication. Here are some ideas: Generated codes One of the most common approaches is to generate PINs and TANs for users and deliver them to a known address ( or postal). These numbers represent a simple form of question. This approach applies to existing users and is extremely useful for encouraging them to register for new services. Transaction data One approach for existing users is to use transaction data, such as the date and balance of a recent statement. In this approach, the application extracts the data from an existing database to form the questions. This ability to import data into Entrust IdentityGuard permits an organization to leverage information that is already known about users as a part of knowledge authentication. Organizations wanting to import data need to use Entrust IdentityGuard s Administration API through an application written for each customer environment. This custom application executes the necessary Entrust IdentityGuard calls to import and manage the data on a per user basis. Entrust Professional Services can help organizations with this type of customizing task. For contact information, see Obtaining technical assistance on page 17. Prepopulated lists It may be necessary to have users register their own question-and-answer response sets. To do this, present them with a stock list of questions from which they make selections and provide answers. This approach gives the organization control over the questions to ensure they meet criteria for privacy, security, and usability. (See also Creating good questions.) User-generated While you can allow users to enter their own question-and-answer challenges, this approach is not recommended. In general, users do not write well formed questions or provide well crafted clues that meet criteria for privacy, security, and usability. Also, users tend to forget the answers to their own questions more frequently than stock questions. However, in a design 40 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

41 that makes use of multiple question-and-answer sets, it may make sense to allow one question and answer that is composed entirely by the user. Creating good questions Your choice of questions has a direct impact on the success of knowledge-based authentication. Measure the questions you select against the following criteria: Privacy Organizations are subject to legislation and regulations relating to the collection, storage, control, and handling of personal information. It is prudent to avoid the use of personal information when building a knowledge-based authentication system. Construct the information collected for question-and-answer sets so that it is used exclusively for authentication purposes. Security Construct questions so that the answers are both difficult to obtain and difficult to guess. For privacy reasons, do not rely on personal information such as names, family histories and birth dates. Also, identity thieves regularly find or steal personal information. This renders the reliability of this information almost nil. A question such as What is your mother s maiden name? is less secure than asking a more difficult personal question, such as What is your father s middle name? Avoid questions that have a limited number of realistic answers. For example, What is my eye color? would not require many attempts to guess a correct answer. Usability Knowledge-based authentication must be simple and easy for users to use. Consider these ease-of-use criteria: Applicability The questions should have a wide applicability to the organization s users. For example, the question What is the name of my first pet? only applies to pet owners. Memorability An answer must be easily recalled for the question to be useful. Questions that reflect user s habits, regular activities, or practices generally meet this criteria. Repeatability Answers need to remain constant for the question to be of value. Questions that prompt for a favorite may have different responses over time, while those that ask for a first should not change. Repeatability also deals with Authentication choices 41

42 consistency the ability to enter an identical response each time. This is discussed next under Ensuring answer consistency. Ensuring answer consistency Knowledge-based authentication relies on an exact match between the stored answer and the response at the time of authentication. (The mechanism actually involves secure hash values, although the effect is the same the original and subsequent answers must be identical.) Employ the following techniques to improve the chances of receiving an exact match: Normalize the data. The application should process response data to ensure consistent presentation. This can involve removing white space, converting all alphabetic characters to lowercase, ignoring punctuation and special characters, and so on. Standardize responses. Questions that require answers formatted in a standard way, especially dates, should include drop-down lists or other mechanisms that enforce a standardized response. Avoid syntactic representations. What do you expect the answer to look like; for example, having to process St. as Street? This requires thoughtful creation of the question. Validate the answer set. You should include rules-based post-processing of the answers given during enrolment to ensure answer quality. You don t want the same response to each question, nor sequential keyboard sequences, nor repeated characters, and so on. Many of the rules that apply to good password quality also apply to good answer quality. Your application can reject answers that don t fit your rules and prompt for a better answer. Selecting a set of questions A common practice is to create several question-and-answer sets during the enrolment process, then use a randomly selected subset for subsequent knowledge-based authentication. In addition, your application can use dynamic transaction data not stored by Entrust IdentityGuard to supplement the knowledge authentication. Answers to questions such as When was your last mortgage payment? or What was your last transaction value? could be presented and validated outside of Entrust IdentityGuard. Such questions incrementally add to the overall security of the deployment. 42 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

43 For usability reasons, users will not tolerate answering a large number of questions for enrolment and especially not at the time of authentication. Although you may require the user to select and answer only a few questions during authentication, it is recommended that you have a large selection of questions available. This increases the odds that each user will find an appropriate set of questions and it increases the system s resistance to attack by making it more difficult for an attacker to anticipate a given user s questions. To make it easier on users, you can use questions and answers for additional authentication rather than your main second-factor authentication. For example, use machine authentication for the user s normal login location and reserve the questions if the user logs in from a different machine. Out-of-band authentication Out-of-band authentication uses an independent means to communicate with the end user to protect against attacks that have compromised the primary channel. Entrust IdentityGuard supports this capability by generating a one-time password you can send with a transaction summary to the user. You can send this information directly using or SMS, or by voice to a registered phone number. The user gets the confirmation number by one of these means, enters it, and the transaction is approved. To decide how to send the one-time password, consider the following: What information you already store about the end user and consider reliable. For example, a cell phone service provider would likely use SMS with its digital cell service users. This way, the service provider can manage any service level agreement (SLA). If you do not consider previously collected information to be reliable enough for out-of-band authentication, you can register users. For example, SLAs may also play a role in the use of SMS, as it is not always 100% reliable. The registration process allows users to enter, validate, and correct their delivery information ( address, voice phone number, and cell phone number) and out-of-band authentication preferences. This also allow users to Authentication choices 43

44 personalize the way that their confirmation number is delivered to them a definite user benefit. Table 7: Out-of-band authentication advantages and considerations Advantages It is effective at guarding against attacks such as man-in-the-middle, where a legitimate session may be used to piggy-back fraudulent transactions. It can leverage channels that already exist and are easy for users to access. These include telephone calls, SMS to a cell phone, or to a computer or mobile device. All these allow the user to confirm a particular transaction using a channel already registered with the organization. Considerations When sending the password, ensure that you also provide a context as to what the user is getting the password for. Consider the sensitivity of the transaction details, as users may not always delete the message immediately, and it may be sent unprotected. The expiry time for the password should balance the amount of time it would take a user to receive your message and enter the password with your need for security. Deployment type Web access Machine authentication Machine authentication provides validation of the user s computer to secure the user against a variety of threats. It is an especially attractive method where end users typically access their accounts from the same computer. It allows for seamless authentication without any noticeable impact to the user experience. This section describes ways of gathering machine fingerprint information (also called the machine secret) and the implications of storing and validating the information gathered. It also discusses requirements for machine authentication that may influence how machine authentication is used. To establish the computer identity: Entrust IdentityGuard first generates a fingerprint of the user s computer. This fingerprint is based on the following configured set of machine parameters that can be transparently read from the user s computer: Machine nonce: This is an arbitrary number generated by Entrust IdentityGuard for authentication purposes when Entrust IdentityGuard registers the machine. Optional sequence nonce: Entrust IdentityGuard generates and changes the sequence nonce each time authentication occurs. A sequence nonce 44 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

45 assures that the machine secret is only valid until the next login attempt. This increases security by reducing the validity period of the machine information, and by making it more difficult for an attacker to use the cookies without being detected. Optional application data: This is a list of name and value pairs specified by a client application and set when Entrust IdentityGuard first creates the machine secret. A client application can provide Entrust IdentityGuard with application data specific to the user s computer. This can include operating system and browser versions gathered through simple methods that do not require client-side software. Entrust IdentityGuard generates a computer identity reference and stores it on the computer for future authentication. This computer registration process is similarly performed for all computers a user wishes to register. In Figure 7, the simple action of selecting the option Remember me on this machine sets machine authentication into action. Figure 7: Login page with machine authentication During subsequent logins, Entrust IdentityGuard: retrieves the computer identity transparently authenticates it recalculates the computer fingerprint compares it to the one stored for that computer Entrust IdentityGuard s machine authentication thus provides protection for users even if they have had their authentication data stolen by attackers. Because an attacker would not likely try to enter the stolen credentials from the user s computer, the machine authentication fails and the attacker can t obtain access. Authentication choices 45

46 Sources of machine information There are several ways to create a fingerprint of a particular computer. The choice depends on the method chosen to gather fingerprint data. Basic Web browser without client-side software: This requires a Web browser only. From the user s perspective, it is the least invasive method of gathering the information for a machine fingerprint. Your program needs to set a cookie within the browser for subsequent authentication comparisons of the user s machine fingerprint. Take this into consideration when deploying machine authentication. There are two ways of gathering data from a Web browser without requiring client-side software. You can use the browser Get request or Javascript. Through a Web browser Get request, the application can identify a browser using the HTTP headers present in the browser s request to the server. Unfortunately, all data returned is quite predictable, even to an attacker who has never seen a particular browser s request. Figure 8 shows a sample Get request. Figure 8: Sample browser Get request GET /cgi-bin/inputdump.exe HTTP/1.1 Accept: */* Accept-Language: en-us Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1;.NET CLR ;.NET CLR ) Host: anyserver.anybank.com Connection: Keep-Alive Cookie: intranetredirecturl=; GA_SHOW_TABS=; LASTSITE=intranet Due to the predictability of standard Get requests from a browser, we recommend not to use these fields on their own. Some fields (such as user-agent) may be useful as part of a broader machine fingerprint. Use other methods described below to create a unique machine fingerprint. Instead of Get requests, your Web application can use standard Javascript calls to gather information. This involves a minor modification to the application s login page to collect the wider range of data needed for the machine fingerprint. All the following pieces of information are available through standard Javascript calls without requiring any client-side software. 46 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

47 Note: The properties in Table 8 were collected using JavaScript on an Internet Explorer browser running on Windows. Similar properties will be available on other browsers, but their names and values will vary. Table 8: General properties Property Value navigator.appcodename Mozilla navigator.appname Microsoft Internet Explorer navigator.appminorversion ;SP2; navigator.cpuclass x86 navigator.platform Win32 navigator.systemlanguage en-us navigator.userlanguage en-us navigator.appversion 4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1;.NET CLR ;.NET CLR ) navigator.useragent Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1;.NET CLR ;.NET CLR ) navigator.online true navigator.cookieenabled true screen.availheight 1170 screen.availwidth 1600 screen.bufferdepth 0 screen.colordepth 32 screen.devicexdpi 96 screen.deviceydpi 96 screen.fontsmoothingenabled true screen.height 1200 screen.logicalxdpi 96 screen.logicalydpi 96 Authentication choices 47

48 Table 8: General properties Property Value navigator.appcodename Mozilla screen.updateinterval 0 screen.width 1600 Note: The properties in Table 9 and Table 10 show just a portion of the MIME and plug-in information available. They were collected using JavaScript on a Firefox browser running on Windows. Similar properties will be available on other browsers, but their names and values will vary. Table 9: MIME properties (partial list). Property Value navigator.mimetypes[0].description Mozilla Default Plug-in navigator.mimetypes[0].suffixes * navigator.mimetypes[0].type * navigator.mimetypes[1].description Java navigator.mimetypes[1].enabledplugin. NPOJI610.dll filename Table 10: Plug-in information (partial list) Property Value navigator.plugins[0].description Default Plug-in navigator.plugins[0].filename npnul32.dll navigator.plugins[0].length 1 navigator.plugins[0].name Mozilla Default Plug-in navigator.plugins[1].description Java Plug-in for Netscape Navigator (DLL Helper) Given the wide range of information available, some of which may be too common to be useful, we recommend that organizations consider the use of a combination of elements gathered through Javascript such as: browser version. 48 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

49 browser plug-ins present. browser language being used. browser platform (user s operating system). screen size of user s computer (height and width). screen color depth. Basic Web browser with client-side software: Organizations can deploy signed Java applets or ActiveX controls that can go beyond basic browser security. This involves the user seeing and accepting security notifications on a regular basis. While more secure, it is less than ideal for large-scale consumer deployments. However, there may be instances where this is the best practice since it allows organizations to gather more detailed physical machine data for use in a machine fingerprint. Elements that could be gathered in this scenario include: media access control (MAC) address of the user s Ethernet card. exact operating system (OS) information including the service pack and patch level. system information including native byte order and number of available processors. hardware information (manufacturer, model, version, and so on) of various hardware devices (network card, video card, hard drive, CD reader/writer, processor type). CPU processor ID (if enabled). user information (account name and home Directory). The above elements can be combined with other available elements to create the machine fingerprint. Web application (server-side): The information available through Javascript and client-side software can be augmented by data available from the Web application. Figure 9 shows information gathered by a simple server-side CGI. Figure 9: Sample Web application data HTTP_USER_AGENT=Mozilla/5.0 (Windows; U; Windows NT 5.1; en-us; rv:1.7.10) Gecko/ Firefox/1.0.6 HTTP_ACCEPT=text/xml,application/xml,application/xhtml+xml,text/ht ml;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 HTTP_ACCEPT_LANGUAGE=en-us,en;q=0.5 HTTP_ACCEPT_ENCODING=gzip,deflate HTTP_ACCEPT_CHARSET=ISO ,utf-8;q=0.7,*;q=0.7 HTTP_KEEP_ALIVE=300 HTTP_CONNECTION=keep-alive HTTP_COOKIE=LASTSITE=anybank; intranetredirecturl=https%3a//anyserver.anybank.com/download/cnbc. htm; GA_SHOW_TABS=0%2C1%2C2%2C4 Authentication choices 49

50 REMOTE_ADDR= REMOTE_PORT=1294 This information is similar to that found in a Get request (see Figure 8 on page 46). This list includes a port and IP address. Port information may change each time and is not a useful property for a machine fingerprint. A user s IP address can be used to look up geolocation information, but shouldn't be used directly. Entrust IdentityGuard can store additional application data specified by your organization, including data that may be gathered with standard APIs through external data sources. (For example, geolocation services can estimate the geographic location of the user based on their PC s IP address.) Table 11: Machine authentication advantages and considerations Advantages It provides users with a seamless login experience. Considerations Determine whether users ever access your site through a public computer (such as from a library) Determine how to obtain the machine information (depending the browser type, a client-side application, and so on). See the Entrust IdentityGuard Programming Guidefor further information. Determine how many properties in the machine secret must be successfully matched for successful authentication. Failure may depend on the property in question. If one of the properties captured is the browser version and in subsequent authentications that version changes (perhaps the user upgraded the browser), it may still make sense to allow that user access. It is recommended that organizations examine their user base carefully before configuring this option in order to maximize security and overall usability. Determine whether to use a sequence nonce to update the machine secret each time the user logs in. Determine whether to add application data to the machine secret. Deployment type Web access 50 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

51 Authentication choices for deploying organizations End users must be confident that they are transacting with their organization, and not a fraudulent organization. Likewise, you need to have confidence in the identity of the user. Entrust IdentityGuard provides several methods of user authentication and organization authentication, which lets you configure ways for both parties to authenticate each other. This two-way check is called mutual authentication. The following organization authentication options are available: Grid serial number or grid location replay on page 51 Image and message replay on page 52 Grid serial number or grid location replay Grid authentication not only provides a secure, low cost and easy way to authenticate users, it also includes built in mechanisms for mutual authentication. One mechanism is based on the serial number of the grid itself. Each grid card or passcode list has a unique serial number that is known only to the organization that issued it and the user. During login, you can display this number to the user before prompting for user authentication. Before entering a password or grid challenge response, users simply confirm that the serial number displayed on the screen matches the one on their card or list. If it does, users can be confident they are accessing the legitimate site. Another mechanism available with the card is to replay or show specific grid coordinates. That is, you tell users what values are in specific cells on their cards. This confirms that you have specific knowledge of the contents of the grid and, therefore, must be legitimate. Table 12: Grid serial number and location replay authentication advantages and considerations Advantages Help users determine if they are at a valid site before they provide sensitive authentication data. Easy to use when grid authentication is enabled. Authentication choices 51

52 Table 12: Grid serial number and location replay authentication advantages and considerations Considerations It requires two-step authentication (See Grid authentication on page 32 for definition). You can take additional security measures to make this information difficult to harvest. For instance, you can obfuscate entries by avoiding machine-readable characters; that is, display them as images instead of text. Deployment types Web access Microsoft Windows remote access VPN remote access Microsoft Windows desktop Image and message replay Another replay method supported by Entrust IdentityGuard is image and message replay. In this case, as part of the registration process, a user selects an image from a gallery and enters a custom image caption that is later shown during login. By personalizing the login with the image and message, as in Figure 10 on page 53, the user recognizes that only the legitimate organization is able to replay this information. 52 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

53 Figure 10: Choosing a custom image and caption Authentication choices 53

54 Whether the users pick a picture from a collection or upload one of their own, it will be familiar. Image and text replay makes it easy for users to know if they are on a fraudulent site. Table 13: Image and text replay authentication advantages and considerations Advantages Versatile for use: verifies users if they forget a password, allows a user to determine the legitimacy of the site. Does not require you to enable grid authentication. Considerations Plan for the implications of image data size. Images require lots of storage space. Images in your collection should be highly optimized and limited in size to manage space requirements in the Entrust IdentityGuard repository. Make a number of images available for identifying the organization to users. Let the users choose an image they identify with. If you plan to allow users to upload their own images, take special care to manage the amount of disk space for this feature. Entrust IdentityGuard includes policy settings for a maximum file size that you can set to ensure that users don t upload high-resolution images. Your organization can also deploy a conversion utility to convert high resolution images into an appropriate size (both file size and pixel size). Deployment type Web access 54 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

55 Temporary PIN authentication In certain situations where the user does not have their card, token, or passcode list, you can issue a temporary PIN, either for a specific number of uses or for a limited period of time. Examples of this situation include lost cards or tokens, or a newly registered user waiting for their card or token to arrive. Temporary PINs are only available for grid or token authentication. Temporary PINs are issued with limits on the number of uses and expiry dates to limit exposure to attacks. These values are configured by administrators, who need to take into consideration how long it will take to deliver a replacement Entrust IdentityGuard card to the user. Table 14: Temporary PIN authentication advantages and considerations Advantages It allows users to log in even if they have forgotten or lost their token device or card. Considerations It is only available if using token or grid authentication (either card or passcode list). It requires policy considerations such as: expiry mode (either time or use-based), minimum length, characters to use, character replacements, challenge size, and automatic deletion when a user begins using their card or token. Deployment type Web access Authentication choices 55

56 External authentication The external authentication feature, provided with Entrust IdentityGuard, is useful when deploying in a Remote Access or VPN environment. This feature lets you use Entrust IdentityGuard to manage first-factor authentication using the Windows domain controller or information from an LDAP-compliant Directory. Typically, you would use external authentication as the first layer of a multifactor Entrust IdentityGuard authentication regime. When enabling Entrust IdentityGuard to forward the first-factor authentication request to either a Directory or the domain controller, you configure the external authentication feature. If you are considering applying second-factor authentication to your VPN users, you need to determine how first-factor authentication (user name and password) is completed. Entrust IdentityGuard supports two methods: Entrust IdentityGuard forwards a request to a Remote Authentication Dial In User Service (Radius) server which completes the first-factor authentication. Entrust IdentityGuard forwards a first-factor authentication request to either an LDAP-compliant Directory or Microsoft Windows domain controller (referred to as external authentication). Use external authentication when your users and their password information are stored in a Directory or domain. For a sample architecture, see Web access - evaluation on page 126. Also refer to the Entrust IdentityGuard Installation Guide for further information. 56 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

57 Chapter 3 Planning your deployment This chapter discusses items to address prior to, or during, the deployment of Entrust IdentityGuard. This chapter includes the following points to consider: Planning: initial considerations on page 58 Planning administrative tasks on page 62 Planning end user requirements on page 65 Group requirements on page 69 57

58 Planning: initial considerations This section identifies, at a high-level, both the technical and nontechnical aspects that need to be addressed for a successful deployment. These can be categorized into the following five areas: Authentication methods Refers to the authentication methods supported by Entrust IdentityGuard and which your organization requires in order to verify user identities. Examples include considering the requirements for user and mutual authentication, and how to implement the methods into your existing authentication structure. See Authentication choices on page 27. Policies and practices Refers to the specific security policies supported by Entrust IdentityGuard and the practices used by the organization to implement these polices. Examples of policies for Entrust IdentityGuard include the size of the grid or passcode list, the length of a challenge, the number of authentication steps or layers, or the number of incorrect attempts before lockout. See Entrust IdentityGuard policies on page 59. People Refers to the personnel required to deploy, operate and support Entrust IdentityGuard. See People on page 60. Architecture and technology Refers to the technical aspects you require to support Entrust IdentityGuard. This can be the networking environment, operating systems, hardware and software, and application integration. These include the environment in which Entrust IdentityGuard is deployed and the applications that Entrust IdentityGuard protects. See Entrust IdentityGuard components on page 23 and Entrust IdentityGuard baseline architectures on page 123. Operations Refers to the ongoing operational aspects of Entrust IdentityGuard and the procedures needed to support, administer, and operate Entrust IdentityGuard. These include the initial deployment of cards or passcode lists, as well as the distribution and activation of their replacements. See Operations on page 60. Topics in this section: Entrust IdentityGuard policies on page Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

59 People on page 60 Operations on page 60 Entrust IdentityGuard policies Organizations generally have existing polices and practices around the identification and authentication of end users. The processes used for the identification and authentication of users to the existing application will apply to Entrust IdentityGuard configuration and deployment. Entrust IdentityGuard defines the permissible behavior of end users, administrators, and authentication methods using its policy set. When deploying an Entrust IdentityGuard system, you need to decide what types of policies you need and how many you need based on user and authentication requirements. Policies are associated with groups in Entrust IdentityGuard. This means you can create any number of policies for your system, based on the different requirements of different user groups ( Group requirements on page 69). For example, Entrust IdentityGuard uses policies to determine: password rules for administrators when authenticating to the administration interface what cards should look like (for grid authentication) how users interact with Entrust IdentityGuard (for example, how many invalid password attempts users can make before being locked out, and what sorts of authentication methods are available to them) temporary PIN rules (for grid, passcode list or token authentication only you can assign a temporary PIN to a user when a card or token is lost or forgotten) Organizations should: Set up security policies that contain statements regarding appropriate user security measures, such as keeping Entrust IdentityGuard cards, tokens, or passcode lists out of sight when not in use and memorizing PINs, answers, and other information. Train users of the importance of protecting their Entrust IdentityGuard authentication information and keeping it confidential. This can be done through security awareness training and internal communications. Consider the requirements for identity verification during enrolment and for card, list, and token replacement. These requirements will be primarily driven by the business value of the applications being protected with the Entrust IdentityGuard authentication method. Choosing to add a second factor of authentication to the application is in itself an indicator that there is substantial value involved. Planning your deployment 59

60 For information on specific policy attributes, see the Entrust IdentityGuard Administration Guide. People Like any other system, deployment and ongoing operation of Entrust IdentityGuard will require the participation of people from different parts of the organization. Although most of these will be required only on a part-time basis, identifying them and communicating their roles and responsibilities early on in the planning process can help avoid later delays. Identify the following people: overall project manager (recommended) as single point of contact for project and to secure additional resources technical lead to bring knowledge of the organization s technical environment to the project Throughout deployment, the technical lead and other personnel will obtain the necessary knowledge to support the production implementation into the operational phase. Directory administrator (if integrating with LDAP-compliant Directory or Active Directory). database administrator (if integrating with a database) network and systems administrators for support during the installation planning and actual installation application development for support of the application integration operations for support of the operational requirements after deployment Customer Support or Help Desk to integrate support services for Entrust IdentityGuard into the existing mechanisms hardware procurement group representatives from other groups in the organization who may carry some of the responsibility for the ongoing support of Entrust IdentityGuard Operations The operation planning encompasses back-end operational aspects such as server administration and operations, backup and recovery, maintenance and upgrades. It also includes the systems required for customer support. Entrust IdentityGuard is added to an existing application infrastructure; in most cases, only minor updates to existing system administration procedures will be required. 60 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

61 Entrust IdentityGuard maintains log files to assist administrators in troubleshooting activities. Configuration options exist for these logs; refer to the Entrust IdentityGuard Installation Guide for more information. Backup and recovery Update your regular backup and recovery procedures with new information on the Entrust IdentityGuard Server and its operation: If Entrust IdentityGuard is integrated with an existing Directory or database, backup and recovery of the repository will be handled through the existing processes for these repositories. If a new repository is implemented for Entrust IdentityGuard, backup and recovery processes should be established and documented in accordance with existing standards for data backup. The Entrust IdentityGuard Installation Guide provides information on backing up Entrust IdentityGuard Server application files, along with information on recovery steps. Amend your organization s disaster recovery plan to include Entrust IdentityGuard. Other precautions Locate the Entrust IdentityGuard Server and related systems in a secure facility designed and constructed to support the hosting of IT systems infrastructure. Such hosting facilities are typically equipped with perimeter security barriers, surveillance, air conditioning, uninterrupted power supply and fire protection. Implement physical access controls to ensure that only those authorized to perform operations or support services are allowed to enter the Entrust IdentityGuard region, which may be a separate room or a lockable cabinet. Depending on the organization s approach to deploying applications into production, additional implementations of Entrust IdentityGuard into test or staging environments may be required. Planning your deployment 61

62 Planning administrative tasks Besides the people required to deploy Entrust IdentityGuard (see People on page 60), you need to plan for people who will administer Entrust IdentityGuard and its users. You must assign the following Entrust IdentityGuard administrative roles: Master User 1, Master User 2, and Master User 3: Assign a different person to each of these three roles. One or more administrators: Master users create these using the Entrust IdentityGuard Administration interface. Topics in this section: Assigning master users on page 62 Assigning administrators on page 63 Assigning master users Assign one of the master user roles to the deployment project technical lead. Master users can perform the following activities using the Entrust IdentityGuard master user shell: initializing the system exporting master keys creating and managing policy and group information creating and managing administrator accounts creating and managing users, cards, tokens, and so on Consider the following when assigning the three master users: The master user role allows extensive administrative capabilities. Assignment of staff to these roles should be in compliance with existing policies on administration staff. Identity the master users prior to installation, and ensure they are scheduled for installation and have a password ready. During the initialization process, Entrust IdentityGuard prompts the three master users to enter their passwords for the user names Master1, Master2, and Master3. The passwords must be over eight characters in length, contain upper and lowercase characters and a numerical value. Because master users do not have administrator privileges within the administration interface for security purposes, users with dual roles require two identities. Refer to the Entrust IdentityGuard Installation Guide and the Entrust IdentityGuard Administration Guide for more information. 62 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

63 Once you identify these users, provide appropriate training for each group. As well, make updates to existing documents, such as operational procedures, administration guides, and training materials, or create new documentation as required. Assigning administrators Administration of Entrust IdentityGuard and its users is handled through the administration interface. This interface allows administrators to manage Entrust IdentityGuard users, cards, tokens, and so on, and to handle day-to-day interaction with the end users (for example, requests for temporary PINs). You can enter user information individually or by importing a file of user IDs. Consider the following when determining the number and levels of administrators you require: Master users create and configure administrator accounts. Administrators access the administration interface using a password. You can optionally add grid or token authentication as well. Each administrator is assigned a particular role or set of roles, which defines which operations they can perform. For example, you can restrict an administrator who works at your Help Desk to: reset user accounts once they ve been locked out manage temporary PINs view user account information For more information about available roles, see the Entrust IdentityGuard Administration Guide. Each administrator is assigned a grouplist, which is the set of user groups the administrator can manage. Administrators belong to a group, which determines their policy settings. This group does not have to be a group they manage. See Group requirements on page 69. The following table lists the Entrust IdentityGuard policy attributes you need to consider when planning for administrators. Table 15: Policy considerations associated with administrators Policy consideration Length and characteristics of the administrator password. Lifetime of password. Recommendations Set to your organization s password requirements. Set to your organization s password requirements. Planning your deployment 63

64 Table 15: Policy considerations associated with administrators (continued) Policy consideration Lockout count, time, and idle timeout values. Whether to enable second-factor authentication (grid or token). Recommendations Set to your organization s password requirements. Enable if an administrator will access the interface from an unsecured computer or location. For example, through your company s firewall. 64 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

65 Planning end user requirements End user requirements are separated into different categories: the authentication methods you require they use how they are accessing your site how they are grouped the number of user names they have Topics in this section: Alias and user ID requirements on page 65 Locking out users on page 67 Training end users on page 67 Providing services to end users on page 67 Alias and user ID requirements End users must have a user ID (usually their user name in the first-factor authentication system) and can have one or more aliases (additional user names) so that different applications can share one Entrust IdentityGuard authentication method. For example, one may use a Windows domain user name while another may use the user's Distinguished Name or address. Entrust IdentityGuard allows a user to have a single authentication method such as a card for authentication to all these applications. To do so, an administrator can specify a list of aliases as well as a user ID for a user. When performing authentication or administration operations on the user, your application can return either the user ID or an alias. A user ID consists of the user name and group name, written in group\user name format. For example, if the user s name is alicel who is in the group gold, the information passed from the application to Entrust IdentityGuard can be in the form gold\alicel. Entrust IdentityGuard processes it as follows: If the user ID contains the group name, Entrust IdentityGuard has a unique match and uses the associated user account. If the user name does not contain the group name, Entrust IdentityGuard searches the repository for all users with the given name as their user name or an alias following these rules: Search the repository for all users with the given user name. For an LDAP-compliant Directory, look in all search bases. If no user entries are found, return an error. If one user entry is found, use that entry. Planning your deployment 65

66 If multiple user entries are found, check if one of those entries is in the default group. If it is, return that entry. If not, return an error. It is recommended, if you are using groups, that client applications send both the group and user name to Entrust IdentityGuard. See Group requirements on page 69. Aliases are implemented in the following manner: User names and aliases must be unique within a group. For example, two users in the same group cannot use the same alias, even if the alias is used with different applications. Aliases are only supported for users, not for administrators. Table 16: Policy considerations for aliases Policy considerations The number of aliases required by the different users in a particular group. Recommendations Determine all access points for your users that will be protected by Entrust IdentityGuard. If the same user has multiple user names, determine the maximum number of aliases a user requires. Ensure that, when dividing users into groups, the user names and aliases are different in each group. If you have similar user names and aliases across different groups, ensure that your applications return the user ID in group\user name format. Aliases in a consumer deployment Consumers can have one or more aliases (additional user IDs) so that different applications can share one Entrust IdentityGuard card or other authentication method. In the real world, related Web applications often use different user IDs for the same person. For example, banks that include brokerage and credit card divisions. Users typically have different identifying credentials for their bank account, online broker, and bank-issued credit card. In some cases, they have different IDs for their checking and savings accounts. But when the user logs in to the bank s Web site, they want a seamless interface to all their financial records and transactions. They want to flip between their bank accounts, credit card purchase list, and stock portfolio. Entrust IdentityGuard allows a user to have a single card for authentication to all these applications. It permits a master user to specify more than one ID for a user. This consists of the primary user ID and a list of aliases. When performing authentication operations on the user, the user can be specified by either user ID or alias. 66 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

67 Locking out users Entrust IdentityGuard includes a locking mechanism that preserves the usability of an authentication method. Challenges are locked until correctly answered this is to prevent attackers from requesting new challenges until they see one they can answer. Users are locked out after a defined number of failed authentication attempts (the default is three). This prevents a brute force attack whereby the attackers keep guessing until they get the correct response. Attackers use automated systems to perform brute force attacks, so success can be accomplished effortlessly in a short period of time. The following table lists the policy considerations related to challenge locking. Table 17: Policy considerations associated with challenge locking Policy consideration Lockout count, timeouts, and idle timeout values. Recommendations Set to your organization s security requirements. Training end users When deploying Entrust IdentityGuard, you must train your end users to use the new authentication methods and register as required. Also, if you have Microsoft Windows desktop users, they need to install the Entrust IdentityGuard Desktop Client for Microsoft Windows. When considering training for end users, consider the following: Inform users of Entrust IdentityGuard and your company s plans for implementation in advance of deployment. Create a flash demonstration that illustrates how to use their new authentication methods. Ensure that the login page that includes the Entrust IdentityGuard challenge is visually clear and uncluttered, with easy-to-navigate help links. Educate users on appropriate handling of their tokens, cards, and passcode lists. The interaction points with the end user will vary depending on how the user life cycle management processes are implemented. Refer to Life cycle management overview on page 114 for more information. Providing services to end users There are multiple ways organizations can provide service to their Entrust IdentityGuard users. An organization can implement any or all of the following approaches: Planning your deployment 67

68 Over-the-counter: Users physically visit a Service Desk to request enrolment or replacement. All processes are completed with the user present, so responsiveness is important. This approach is useful during pilot phases where a small number of users (for example, <100) will be enrolled and enrolment automation can be developed in parallel with the pilot. Self-service: Users access an online application to request enrolment or replacement. Upon acceptance of the request, they are sent an Entrust IdentityGuard card, token, or passcode list (or pickup instructions) and activation instructions. Central service: An administrator initiates enrolment or replacement and Entrust IdentityGuard authentication data issuance for many users at once using bulk operations. This approach is strongly recommended for rollout of a deployment to a large user community and for renewal, once the number of Entrust IdentityGuard users has reached a significant size. 68 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

69 Group requirements Entrust IdentityGuard incorporates the concept of groups into the management of users and policies. Groups are used to subdivide the population of users and administrators into smaller units, where each unit shares a common policy. Refer to Entrust IdentityGuard policies on page 59 for more information. Attention: While you can change a group s policy settings after the creation of the group, take care not to invalidate preexisting cards, or other authentication data. For example, if the size of the grid is increased from five rows to 10 rows after cards have been issued, subsequent challenges might include cell coordinates from the additional five rows that do not exist on the original cards. Groups in a consumer deployment There are many ways groups apply to classes of users in consumer environments. Credit card holders may be separated into bronze, silver, or gold classifications. Users of loyalty cards may be separated into regular, special, and elite classifications. The policy for each group can include different layers and methods of authentication. While you can change a group s policy settings after the creation of the group, take care not to invalidate pre-existing cards. For example, if the size of the grid is increased from five rows to 10 rows after cards have been issued, subsequent challenges might include cell coordinates from the additional five rows that do not exist on the original cards. Configure the application to send both the group and user ID to Entrust IdentityGuard. For example, if the user s ID is alicel who is in the group gold, the information passed from the application to Entrust IdentityGuard should be in the form gold\alicel. Groups in an enterprise deployment There are many ways groups apply to users in enterprise environments: how they access your site (Windows desktop users or Web users) what privileges they have to sensitive information, and therefore, what authentication methods they require functional or geographical similarities which resources or applications they access how they are administered For example, a business with offices in Tokyo, New York, London and Ottawa may decide to divide their users into four geographical groups. Within those groups, the Planning your deployment 69

70 business may divide the users further into remote or office employees. Or, as another example, you may want to provide only some users with tokens, and group them accordingly. Analyzing your company s group needs Create a summary of Entrust IdentityGuard groups. Groups affect users, administrators, tokens, and cards, so consider the following when defining groups: What types of users do you have that require multifactor authentication? For example: Table 18: Sample summary of users that require multifactor authentication User type 1 Do you have users in defined groups connecting to your company through VPN servers? 2 Do you have distinct groups of Windows users that require second-factor authentication when logging in to their computer? 3 Do you have users who access your site using a Web portal? Comments You will need to enable either the Entrust IdentityGuard Radius proxy or another VPN server authentication method. You will need to install and configure the Entrust IdentityGuard client for Windows. You can put these users in a separate group with mutual authentication enabled. 4 Which clients will you create, and what types of users will access each client? Consider ways of subdividing these groups. For example: What sorts of multifactor authentication do these users need? Do some users who access your applications require stronger multifactor authentication than others? Do some require step-up authentication? Should users be grouped across functions, within departments, or both? How will you administer these groups? For example: Will each group have specific administrators? Will one central group of administrators administer everything? Will some administrators administer multiple groups (using the grouplist feature)? Will you have different levels of administration? For example, will help desk administrators unlock passwords and assign temporary PINs, and full administrators set up authentication methods, and so on. 70 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

71 Group implementation Entrust IdentityGuard implements groups in the following way: Groups are defined for both users and administrators. A single group is defined as default using a default flag. This group is used whenever a group is not explicitly defined. Tokens can be optionally added to specific groups. In order to assign the token to a user, the token and user must belong to the same group, or the token must have no group association. When setting up your client applications, you do not need to include group names as part of a user identification request if your system contains only unique user names. When Entrust IdentityGuard needs to verify a user and the application does not return the group information, Entrust IdentityGuard tries to match the user with the correct group following these rules: First search the repository for all users with the given user name. For an LDAP-compliant Directory, look in the search bases defined by the group. If no search bases are defined, search all search bases. See Repository on page 24 for more information on the connection between search bases and groups. If no user entries are found, return an error. If one user entry is found, use that entry. If multiple user entries are found, check if one of those entries is in the default group. If it is, return that entry. If not, return an error. Note: If you are using groups with VPN users, refer to the Entrust IdentityGuard Installation Guide for further information on how groups are implemented. Planning your deployment 71

72 72 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

73 Chapter 4 Deployment considerations This section deals with deployment considerations. Topics in this section include: Application integration on page 74 Application considerations on page 77 Performance testing strategies on page 79 High availability and disaster recovery on page 80 Migrating to Entrust IdentityGuard on page 85 73

74 Application integration You can integrate Entrust IdentityGuard with many applications, including Web portal applications, remote access applications and Microsoft Windows login. Several of these applications have already been integrated, tested and documented by Entrust with more to be added over time. For the latest information on integrated solutions, contact Entrust. See Obtaining technical assistance on page 17 for contact information. Topics in this section: Web integration on page 74 Microsoft Windows integration on page 75 VPN remote access integration on page 75 Web integration The Entrust IdentityGuard Authentication API is used for retrieving challenge requests and authenticating user responses. It is designed to easily integrate with your existing authentication applications to provide layered authentication. You can create a client application that calls the Authentication API using its Web service, Java Platform or C# (.NET) interfaces to authenticate users. For more information, refer to the Entrust IdentityGuard Programming Guides. 74 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

75 Figure 11: Web integration using Authentication API Firewall Firewall Client Web application Application server Authentication API Application server Portal server Content management Entrust IdentityGuard Server Directory or Database Microsoft Windows integration Entrust IdentityGuard Desktop for Microsoft Windows is a small-footprint client that communicates with the Entrust IdentityGuard Server. It provides strong second-factor authentication to the Microsoft Windows desktop (online, offline and remote) and the network. You can set up integration with Microsoft Windows in two ways: for local desktop users (Figure 31 on page 141) for remote users (Figure 28 on page 136) If your deployment includes remote users, you need to add the Remote Access Plug-in. For more information, see Entrust IdentityGuard components on page 23. VPN remote access integration Entrust IdentityGuard supports integration with remote access VPN devices to provide second-factor authentication. This is accomplished through integration with the Entrust IdentityGuard Radius proxy. The Radius proxy manages communications between a VPN server and a first-factor authentication resource, which can be a Deployment considerations 75

76 Remote Authentication Dial In User Service (Radius) server, a Windows domain controller or an LDAP-compliant Directory. You then add an Entrust IdentityGuard second-factor authentication step. Regardless of the resource you use, the VPN server still thinks it is communicating with a Radius server. It is actually communicating with the Entrust IdentityGuard Radius proxy. Figure 26 on page 132 illustrates the integration approach. Since the integration occurs on the back end, no changes to the VPN client are required. With the Entrust IdentityGuard Radius proxy, you can configure some of your VPN servers to use a Radius server and some to use a different first-factor authentication resource. You can direct different groups of users to different first-factor authentication resources. Users who do not exist in Entrust IdentityGuard are authenticated by the first-factor authentication mechanism only. See the Entrust IdentityGuard Installation Guide for details on how to configure the Radius proxy. 76 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

77 Application considerations Define a policy regarding the security aspects of the Entrust IdentityGuard authentication data (whether tokens, grids, passwords, or replay information). These security aspects need to be defined as a whole, since changing any one of these influences the overall security of the system. To maximize resistance to attacks, consider the following steps (all focused on making it difficult to capture user authentication data): Implement strong session security using SSL or TLS to protect the transmission of challenges and responses. Do not display the challenge values as machine-readable characters. These can be easily read by text sniffers and other attacker tools. Consider converting challenges to images instead of text. If you are using grid authentication, implement two-step authentication to prevent an attacker from cycling through different challenges to find one corresponding to captured data. This ensures the challenge remains constant until successfully answered. Use an organization authentication method to provide the user with a visual cue that the site being accessed is legitimate. For example, display an authentication secret (for example, grid serial number or image) to the user during login. The absence of the number or image would suggest the site is fraudulent. See Authentication choices for deploying organizations on page 51. Use temporary PINs in the situations when users are waiting for their card, token, or passcode list or if they have lost it. Determine which authentication method Entrust IdentityGuard should use, if the application doesn t specify. Integrating with existing user management systems If you already have an existing user management system, you can incorporate Entrust IdentityGuard administration tasks into the application using the Administration API. The Administration API is the Java Platform or C# API that applications can use to integrate with the Administration service in Entrust IdentityGuard. The Entrust IdentityGuard Sever also includes administration Web services APIs. Detailed information on how to implement the Entrust IdentityGuard Administration API is found in the Entrust IdentityGuard Programming Guide. To service incoming calls from users, the Customer Support group may have automated systems that require updated information on the status of Entrust Deployment considerations 77

78 IdentityGuard users and their authentication methods. Identify and address these requirements during the deployment phase. Using shared secrets Entrust IdentityGuard includes a feature called shared secrets. Shared secrets are name and value pairs associated with an Entrust IdentityGuard user and used by a client application. Shared secrets are not used by Entrust IdentityGuard though you manage them through Entrust IdentityGuard interfaces. They are stored in encrypted format in the repository. There are several uses for shared secrets. For example, Entrust IdentityGuard Desktop for Microsoft Windows uses shared secret information to store the offline temporary PIN. Note: Do not confuse shared secrets with authentication secrets (see Authentication choices for deploying organizations on page 51). 78 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

79 Performance testing strategies You can choose to carry out performance tests to validate the performance characteristics of Entrust IdentityGuard in their own environment. To do so, you use any number of commercial automated testing tools that allow for the creation of custom scripts that drive the testing process. To perform Entrust IdentityGuard performance testing, create a script that simulates a user receiving a challenge and responding with the appropriate Entrust IdentityGuard response. The testing tool can then run this script as many times as needed to create a simulated load on the Entrust IdentityGuard Server. To prepare the Entrust IdentityGuard Server for performance testing: Create test users. Set up the test users with their appropriate authentication methods. If you are testing performance with cards, ensure the grids are generated, exported, and assigned to users. However, you do not need to print the cards. The script needs to have the values from each card loaded into an array so that it can provide the correct response. If you are testing performance with tokens, ensure the tokens are loaded. The script must perform the following steps: Load the card cells, one-time passwords, or tokens into an array. Capture the start time for a transaction. Send a request to the Entrust IdentityGuard Server requesting a challenge. If you are using cards: Receive the challenge and parse it for the requested coordinates on the card. Look up the correct values for the response in the card cells. Optionally, pause for think time to simulate a person providing the response to the challenge. Send a request to the Entrust IdentityGuard Server with the values of the card, token, or one-time password. Receive the response back from the server. Capture the time that the transaction is completed and calculate the elapsed time of the request. Report on the elapsed time of the request. Once this script has been run a number of times and under different levels of load, you can tabulate the results into a report showing the performance of the overall Entrust IdentityGuard authentication system. Deployment considerations 79

80 High availability and disaster recovery Entrust IdentityGuard offers several solutions to high availability and disaster recovery issues to ensure that there are backup systems in place in the event that a primary system fails. Three failover scenarios for Entrust IdentityGuard are described here: Directory failover Database failover Radius server failover For procedures on how to configure these failover scenarios, refer to the Entrust IdentityGuard Installation Guide. Directory failover You can configure LDAP-compliant Directory failover to ensure there are backups if the primary Directory fails. To do so, specify multiple LDAP URLs in the identityguard.properties file. For instructions on configuring failover for a Directory, see the Entrust IdentityGuard Installation Guide. There are two Directory failover scenarios: local geographically dispersed Local Directory failover In this scenario, the users are likely in one office or city. If the primary Entrust IdentityGuard Server fails from an authentication perspective the load-balancer will redirect users to the replica. Note: From an administration Web services perspective, there is no load-balancer. Administration Web services connect to the primary Entrust IdentityGuard Server, and if the primary fails, Web services will switch over to the replica. There is a primary Directory and a secondary Directory. Both directories are masters, and both have read/write access. These directories must also be synchronized with real-time replication. If the primary master Directory fails, traffic is redirected to the secondary master Directory. 80 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

81 Figure 12: An example of a local Directory failover scenario Firewall Primary Entrust IdentityGuard Server Client Load -balancer Shared Disk Primary Master Directory (with read/ write access) Synchronized (Real-time Replication) Secondary Master Directory (with read/ write access) Replica Entrust IdentityGuard Server Geographically dispersed Directory failover This scenario demonstrates how you can deploy failover for Entrust IdentityGuard users in two different cities (for example, LA and New York). Each city s Entrust IdentityGuard Server is connected to it s own Directory. If the directories in LA fail, the Entrust IdentityGuard Server in LA can connect to the New York directories. Deployment considerations 81

82 Firewall Figure 13: An example of a geographically dispersed failover scenario Client Primary Entrust IdentityGuard Server Primary Master Directory Web servers Synchronized (Real-time Replication) Secondary Master Directory Client Web servers Replica Entrust IdentityGuard Server Primary Master Directory Secondary Master Directory Database failover To provide failover for a database, you may have a mechanism that updates the DNS information so that the database host name points to the IP address of the new database when the original database fails. If so, you must make configuration changes to Entrust IdentityGuard so that it will use the IP address. You can configure database failover to ensure there are backups if the primary database fails. To do so, modify the default behavior of Entrust IdentityGuard to permanently cache the IP address of a DNS lookup. This changes the DNS lookup to 82 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

83 expire after a period of time, rather than permanently caching the IP address from a DNS lookup. For instructions on configuring failover for a database, see the Entrust IdentityGuard Installation Guide. Figure 14: An example of a database failover scenario Firewall Primary Entrust IdentityGuard Server Database Client Load -balancer Synchronized Replica Entrust IdentityGuard Server Database Radius server failover Configure Radius server failover on the Entrust IdentityGuard Radius proxy to ensure that there are backup Radius servers if the primary system fails. If a timeout occurs while waiting for a response from the Radius server and Radius server failover is configured Entrust IdentityGuard Radius proxy uses the next IP address in a list (for the next request that it receives) and the current request times out. When Entrust IdentityGuard Radius proxy reaches the end of the list of IP addresses, it will start at the beginning of the list again. For instructions on creating the list of Radius server IP addresses, see the Entrust IdentityGuard Installation Guide. Deployment considerations 83

84 Figure 15: An example of a Radius server failover scenario Firewall Entrust IdentityGuard Radius proxy Primary Entrust IdentityGuard Server Primary Radius server Client VPN device Entrust IdentityGuard Radius proxy Secondary Radius server Replica Entrust IdentityGuard Server Primary Radius server Secondary Radius server 84 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

85 Migrating to Entrust IdentityGuard During migration of an application from single-factor authentication to multifactor authentication, there will be a mix of users with and without Entrust IdentityGuard authentication methods. In this case, only users with Entrust IdentityGuard credentials should be prompted for the second-factor. Optionally, you can use an out-of-band or alternate activation channel something that is separate from the first-factor authentication application. You can implement this alternate channel as a Web application on the organization s Intranet or as an Interactive Voice Response (IVR) system. Deployment considerations 85

86 86 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

87 Chapter 5 Deploying grid authentication This chapter provides deployment information for grid authentication. Most of the information is card-centric; however, you should also read this chapter if you are deploying passcode list authentication. Topics in this chapter: Grid requirements on page 88 Challenge requirements on page 91 Grid production models on page 94 Physical card security on page 102 Physical card production options on page 103 Secure file transmission on page 107 Automating processes on page

88 Grid requirements This section focuses on the items you need to consider before determining what type of grid best suits your security needs and your end users. Topics in this section: Grid size and format on page 88 Grid lifetime and replacement on page 89 Grid size and format You can configure the size (the number of cells) and format (the contents of cells) of a grid according to your organization s policies. Although both are configured, the size of the grid itself has more impact than the format of cell contents. Grid size and format impact security in the following ways: The greater the number of cells in a grid, the better the resistance to an attacker who has gained some knowledge of a user s grid through impersonation. For example, if an attacker successfully captures one successful login with three coordinates, they will be less likely to receive a subsequent challenge with those coordinates using a 5 x 10 card as compared to a 3 x 8 card. To minimize the probability that an attacker can use captured cells in subsequent challenges, the grid size should be maximized within the constraints of usability. Regarding usability, Entrust commissioned independent studies that show equal usability for a 5 x 10 card and a 7 x 12 card. This means organizations can deploy larger grids to users for scenarios that require higher security. For more details on this and other recommendations, see Card usability study on page 145. Note: It may be appropriate within a user population to deploy various sizes of grids depending on frequency of use and transaction risk. Entrust IdentityGuard supports this approach by allowing you to set up users in groups. See Group requirements on page 69. Cell format has a direct impact on cell value unpredictability (also called cell entropy ), or how difficult it is for someone to guess cell values. Cell format choices include using alphanumeric characters instead of numeric only, and using more than one character per cell. Cell entropy is related to the number of potential characters for each cell in the grid. If a grid uses only single numeric digits, there are just 10 potential entries per cell, but if the grid uses single alphanumeric characters instead, 88 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

89 each cell has 36 possibilities. The greater the number of possibilities, the more difficult it is for an attacker to overcome the randomness of the challenges. The following table lists the policy considerations related to grid size and format. Table 19: Policy considerations associated with grid size and format Policy consideration Row and columns in grid. Characters to use in grid. Number of characters in each cell. Characters that can replace other characters in the grid. Recommendations Maximize the size of grids within the constraints of the physical form and usability. Use single alphanumeric characters due to the significant increase in cell value possibilities. The use of two or more characters per cell is not recommended because it decreases usability Consider having replacement characters for: characters that are easily confused with others (U and V, or the letter O and the number 0) upper and lower-case characters (A and a) Grid lifetime and replacement Grids provide a strong defense against short-lived phishing attacks; however, a long-term pharming attack could obtain sufficient information over time to gradually reduce a grid s effectiveness. Therefore, periodically replace Entrust IdentityGuard grids to provide continuous protection of your users identities. Due to the richness of features and flexible configuration of Entrust IdentityGuard, there is no single replacement period that will work for all applications. You can configure grid lifetime and replacement based on: time (for example, one year) usage (for example, when over 50% of the grid is used at least once) This enables you to fit the renewal cycles to specific risk scenarios or user groups (see Group requirements on page 69). By using grid freshness options in the policies, you can configure Entrust IdentityGuard to address identity fraud risk on a per group basis where some groups get new cards more or less frequently. Deploying grid authentication 89

90 The following table lists the policy considerations related to grid lifetime and replacement. Table 20: Policy considerations associated with grid format Policy consideration Recommendations Lifetime based on time or usage? If your users will authenticate infrequently, base the lifetime of the card on time. In higher-risk or transaction-intensive situations, it may be more appropriate to renew a grid based on usage. Lifetime of card if based on time Given the short window of opportunity for specific attacks, a life span of one year or more is recommended. Replacement and warning thresholds Scan the logs regularly for warning messages regarding replacement thresholds. Do so by building automated systems to scan the log file for replacement warnings and initiate the replacement process, or by having administrators perform queries against the repository to identify grids that are nearing expiry or usage thresholds and initiate the replacement process. Ensure your end users have sufficient time to obtain a new card when their current one is about to expire. If a grid expires before a replacement card is received, you can issue temporary PINs. You can use knowledge-based authentication to validate the end users identities when they call to report an expired card. For more information, see Entrust IdentityGuard users on page Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

91 Challenge requirements This section focuses on the items to consider before determining what type of grid challenge best suits your security needs and your end users. Topics in this section: Challenge length on page 91 Challenge size on page 92 Challenge algorithm on page 92 Challenge length You can configure the length of the Entrust IdentityGuard challenge, and this has an impact on the security of the solution. The greater the number of cells used in a challenge, the more data is given away with each observation by an attacker. For example, should users be tricked into entering a single authentication to an attacker s application, they would be giving away twice as much grid data with a challenge length of six coordinates as with three coordinates. The more data that is given away, the more likely an attacker can answer a challenge from the legitimate application. At the same time, the challenge needs to be of a minimum length to reduce the probability that an attacker can guess some or all of the challenge coordinate responses. For example, assume an attacker successfully captured some card data and then attempts to authenticate. The attacker receives a challenge in which one of the challenge coordinates is already known to the attacker. With a challenge length of two, the attacker would have a much better chance of obtaining the remainder of the challenge by guessing than if the length was four, especially since the Entrust IdentityGuard lock-out feature would limit the authentication attempts. Deploying grid authentication 91

92 The following table lists the policy considerations related to grid challenge length. Table 21: Policy consideration associated with grid challenge length Policy consideration Number of cells in a challenge Recommendations Find a balance between the minimum and maximum constraints when you set the optimal challenge length for a given grid size. For most applications, the optimal challenge length is three. This number provides the best overall resistance to an attacker guessing remaining challenge coordinates across a range of observed authentications. Challenge size When you are considering how many cells should be included in a challenge request, aim to achieve a balance between requesting enough cells to protect against an attacker guessing the contents, and requesting so many cells that it adds complexity for the user. Attention: Challenging for more cell locations may actually increase the risk of a successful attack on a user because it allows an attacker to capture more cell locations faster. Given the marginal increase in security gained by increasing the number of cells, organizations should carefully consider going beyond three cells on a given challenge. The following table lists the policy considerations related to grid challenge size. Table 22: Policy considerations associated with grid challenge size Policy consideration Size of a challenge Recommendations Use three cells per challenge to balance grid usage with challenge security. Challenge algorithm Entrust IdentityGuard includes two types of challenge generation algorithms for grid authentication: Random challenge picks cells randomly when creating a challenge (this is the default). The process for creating one challenge does not depend on previous challenges. 92 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

93 Least-used challenge uses a configured number of least-used cells in every challenge. It can be from one cell per challenge up to the entire challenge. By generating challenges using the least-used cells from an end user s grid, it becomes more difficult for an attacker who has previously viewed some successful authentications to correctly respond to the challenge. However, it limits the useful life of the grid, depending on the least-used threshold (see Grid lifetime and replacement on page 89). Deploying grid authentication 93

94 Grid production models At a high-level, Entrust IdentityGuard card and passcode list production requires the following activities: The user has been created in the first-factor authentication application. The user is made known to the Entrust IdentityGuard Server using the Create User function within Entrust IdentityGuard. This creates the required Entrust IdentityGuard attributes for the user. Grids are generated. A grid is associated with a user. A physical card or passcode list containing the printed version of the Entrust IdentityGuard grid is produced. Entrust IdentityGuard provides two models for grid production: produce-and-assign model, in which the grid is generated for a particular user entry The produce-and-assign model is suitable for situations where the user is already known to the organization and already exists in the repository. preproduction model, in which grids are generated in bulk, and assigned to users later The preproduction model is suitable when the user is not known to the organization or when the grids are assigned to users after generation. As illustrated in Figure 16, the order in which these activities occur varies between the produce-and-assign model and the preproduction model. Figure 16: Grid production models Produce -and-assign model 1. User exists in primary application. 2. User created in Entrust IdentityGuard. 3. Grid generated for user. 4. Card produced. Preproduction model 1. Grid generated. 2. Card produced. 3. User exists in primary application. 4. User created in Entrust IdentityGuard. 5. Grid assigned to user. 94 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

95 These two models are not mutually exclusive. For example, an organization may use the preproduction model for new end users and use the produce-and-assign model for existing end users. The organization could also use the preproduction model for Entrust IdentityGuard card replacement. Topics in this section: Produce-and-assign model on page 95 Preproduction model on page 99 Produce-and-assign model In the produce-and-assign model, the user (who will receive an Entrust IdentityGuard card) must be known in advance of grid creation. The user is created within the first-factor authentication application. Then use the Entrust IdentityGuard user create function to populate the user entry in the repository with the Entrust IdentityGuard attributes. During the user creation process, a grid is generated for the user. In this model, card production and distribution must take into account that users and grids have already been associated within Entrust IdentityGuard. Therefore, the physical card containing the grid must be distributed to the correct recipient. This approach is manageable for small-scale usage (a few cards a day), where the entire enrolment process is handled as an over-the-counter service, completed in a few minutes. One advantage to this process is that it easily supports Entrust IdentityGuard card personalization, such as printing a photograph on the card. The following subsections provide more detail on how to produce and assign grids when enrolling existing and new users: Produce-and-assign grids for existing users on page 95 Produce-and-assign grids for new users on page 97 Produce-and-assign grids for existing users Implement the following steps if you are using the produce-and-assign model for existing users. Deploying grid authentication 95

96 Figure 17: Grid production for produce-and-assign 1. Entrust IdentityGuard Repository 6. Other repository 7. Extract user information into second file. Optional steps required if user delivery information is not in Entrust IdentityGuard Repository. 2. Extract list of users. 8. Merge two files to create production file. 9. Review and deal with errors. 3. Generate grids. 4. Export production file. 5. Securely transmit file to card producer. To produce-and-assign grids for existing users 1 Ensure the users already exist in the primary application s repository. This repository also serves as the Entrust IdentityGuard repository. 2 Extract a list of the users who are to receive cards from the repository. 3 Import the list of users into Entrust IdentityGuard and generate the grids for those users. Detailed information can be obtained from the Entrust IdentityGuard Administration Guide. 4 Export the selected users grids, user IDs, and delivery information into an Entrust IdentityGuard production file. 5 Securely transmit the Entrust IdentityGuard production file to the card production facility where grids are printed on cards or another appropriate medium. See Secure file transmission on page 107. Each user ID and grid combination must include the associated user ID and delivery information. If this information is located in the Entrust IdentityGuard repository, it is exported along with the user ID and grid. If the information is located elsewhere, it must be extracted and matched or merged with the user IDs and grids. The optional process steps are listed below. 6 Based on the list of user IDs exported, access other corporate repositories to obtain the name and mailing information of the selected users. 96 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

97 7 Export the user information into a second file. 8 Match and merge the two files together to create the Entrust IdentityGuard production file containing the user information and associated grid. 9 Report the exceptions where user information cannot be found for a user and deal with them in a separate process. Complete the enrolment process with Delivery and activation on page 120. Produce-and-assign grids for new users Implement the following steps if you are using the produce-and-assign model for new users. 2a. Administrator requests card. 1. Entrust IdentityGuard Repository 2b. User logs in and requests card. 3. Generate grids. 2c. Cards requested in bulk. 4. Export production file. 5. Securely transmit file to card producer. To produce-and-assign grids for new users 1 Ensure the user exists in the primary application s repository. This repository also serves as the Entrust IdentityGuard repository. 2 Request the cards for the new users, using one of the following three ways: a Have the administrator request the card. In an over-the-counter approach, the request for an Entrust IdentityGuard card is submitted by the administrator. This approach is manageable for small-scale usage (a few cards a day), where the entire enrolment process is handled as an over-the-counter service, completed in a few minutes. One advantage to this process is that it easily supports Entrust IdentityGuard card personalization, such as printing a photograph on the card. Deploying grid authentication 97

98 b Have the user log in to a Web application (or something similar) and request the card. This login is performed using a current user name and password. For example: c An organization implements the application on an internal Web site accessible to anyone on the network with a valid user name and password. The application authenticates the user. The user creates a request, using the user name for which the Entrust IdentityGuard card is being requested. This user name must either exist in the repository or the application must create a new user account at this time. For example, the user name might be obtained or derived from the network login user ID to simplify the request for the user. Create a central service that uses a bulk operation to generate Entrust IdentityGuard cards for many users at once. An administrator extracts information from the repository which is used to select users for which Entrust IdentityGuard cards will be issued. For each user, the extracted information must contain the user name and delivery information (for example, name and address for individual mailing or Service Desk location). The delivery information depends on the delivery method. For more information see Delivery and activation on page Entrust IdentityGuard generates and assigns a grid to each user name regardless of where the request originated. 4 An Entrust IdentityGuard production file is exported by an administrator, containing: the user name and grid information personalization and delivery information extracted from the repository Using the user name as a key, the extracted information is merged with the grid data and any information required to print the grid on a physical card. The output of this process is an Entrust IdentityGuard production file. Variations will occur in the process. Depending on the service approach, the Entrust IdentityGuard production file may consist of a single grid or many grids. An over-the-counter service will produce cards one at a time, while the other approaches produce cards in quantity. The processes to produce the Entrust IdentityGuard production file may merge the request information for new cards, renewal cards and replacement cards in a single file. 5 Produce the cards. To do so, Send a production file to an application for card production and subsequent delivery. For details, see Physical card production options on page 103. If you are using the over-the-counter approach, keep a stock of blank cards at the Service Desk for printing at the time of enrolment. The enrolment 98 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

99 process should take only a few minutes and the Entrust IdentityGuard card would be handed to the user on the spot. Complete the enrolment process with Delivery and activation on page 120. Preproduction model In the preproduction model, users are not necessarily known in advance. A set of grids is generated, but not assigned to specific users. The users are created after the grids. A grid is assigned to a user at some point during the registration and activation process. How and when the assignment occurs depends on the user administration processes in place. How the card production models are used plays a significant role in user life cycle management. Refer to User life cycle management on page 113. Figure 18 shows the steps involved in the generation of the Entrust IdentityGuard production file for the preproduction model. In this model, anonymous grids are created, but not immediately assigned to users. Assignment of grids to users happens later on in the registration process. Anonymous grids can be sent to users in the mail. When the user receives a card in the mail, they assign the card to themselves at a self-enrollment Web site that leverages the Entrust IdentityGuard Administration API. At such a Web site, can configure Entrust IdentityGuard to challenge the user to prove that they have the card, rather than just ask for the serial number. For example, after the user enters their serial number, they are presented with a grid challenge. If the grid challenge fails, the card stays in an unassigned state. This is to ensure that the user does not assign the wrong card to themselves by entering the wrong serial number. Also, users can receive their anonymous grids by hand. For example, a bank teller can pull a card out of a box to give to a customer in a bank branch. In this model, cards should have a tamper evident sticker that covers the grid, but not the serial number. Deploying grid authentication 99

100 Figure 18: Grid production for preproduction model 1. Generate grids, store in repository. 2. Export production file. 3. Securely transmit file to card producer. Card creation and delivery 4. Entrust IdentityGuard Repository 5. Create user, select card, assign grid. To preproduce grids 1 Create a set of Entrust IdentityGuard grids. Assign the grids a particular group in order to specify the policy. For information on where generated grids are stored, see Repository on page 24. The only information required at this step is the serial number and contents of the grid. 2 Export the unassigned grids by writing the serial numbers and grid configurations to an Entrust IdentityGuard production file. You can select various export constraints based on the Entrust IdentityGuard export command. As an alternative, you can set up batch jobs to export cards at regular intervals. 3 Securely transmit the Entrust IdentityGuard production file to the card production facility where grids are printed on cards or another appropriate medium. See Secure file transmission on page Produce the cards using one of the following methods: Send the Entrust IdentityGuard export file to an application for card production and shipment back to the organization, which stores the unassigned cards until needed. Optionally, you can append the file with additional information relevant to the card production facility. For example, if card production is outsourced, then the outsourcer will need billing information from the requesting organization. The remaining steps are completed once the cards are created and delivered. 5 Ensure the user exists in the primary application s repository. This repository also serves as the Entrust IdentityGuard repository. 100 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

101 6 Create the user, select the card and assign the grid to the new users, using one of the following three ways: Have the administrator select the card and assign the grid. In an over-the-counter approach, the administrator assigns the cards when the user is present and hands the card to the user at that time. This approach is manageable for small-scale usage (a few cards a day), where the entire enrolment process is handled as an over-the-counter service, completed in a few minutes. One advantage to this process is that it easily supports Entrust IdentityGuard card personalization, such as printing a photograph on the card. Deliver the card to the user, and have the user log in to a Web application (or something similar) and, as part of their registration process, provide the card s serial number, which then is used to assign the grid to the user. This login is performed using a current user name/password. For example: An organization implements the application on an internal Web site accessible to anyone on the network with a valid user name and password. The application authenticates the user. The user creates a request to set up their Entrust IdentityGuard account, using the serial number of the Entrust IdentityGuard card. This serial number must be made available to the user either on the card itself, or in documentation surrounding the card. Entrust IdentityGuard generates and assigns a grid to each user name regardless of where the request originated. Deploying grid authentication 101

102 Physical card security Entrust IdentityGuard can be deployed in multiple forms, although the majority of deployments will leverage a standalone physical card for a unique grid. The following is recommended: Do not put specific information or branding on the card that will identify your site as a potential attack point if a card is lost or stolen. Include anti copying measures such as using hard-to-duplicate color combinations or reflective card materials (though make sure the colors don t reduce accessibility). Consider adding a feature to your application where the application displays the user s last successful login time and date. If this information does not match the user s personal experience, this will alert the user that some form of attack may have occurred. Define a user policy and educate users on appropriate card handling to prevent users from unwittingly exposing their grid data to an attacker, both physically and electronically. 102 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

103 Physical card production options You can choose from two basic options for card production: in-house ( In-house card production on page 103) outsourced ( Outsourced card production on page 104) Note: If there is no existing card production process, or the existing process is unsuitable, Entrust can help through its own card production service capability. See Obtaining technical assistance on page 17 for contact information. Also see Card production cost factors on page 106 and Delivery and activation on page 120. In-house card production Use the in-house approach if leveraging existing card production capability (for things such as security badges) to produce and distribute Entrust IdentityGuard cards. Typical characteristics The following are general characteristics of deployments involving in-house card production (note that these characteristics do not exclude an outsource approach for deployment): The in-house option is generally used for Enterprise deployments where card production already exists. Entrust IdentityGuard cards are distributed at either over-the-counter service locations or through existing corporate mailing facilities. Setup The following areas need to be addressed prior to starting any in-house Entrust IdentityGuard card production: Review internal departmental agreements and process. Check the inventory of existing card stock (for example, letter stock, card artwork, logo, branding). Create a welcome letter and activation instructions. Ensure secure intra-departmental transmission capability: for Entrust IdentityGuard card generation information. for Entrust IdentityGuard card distribution (over-the-counter or internal corporate mail). Deploying grid authentication 103

104 Process The following process steps are involved with in-house Entrust IdentityGuard card production (note these steps may vary based on corporate procedures and policy): To produce cards in-house 1 Securely send the Entrust IdentityGuard production file to the card production location using tools such as encrypted or file encryption. See Secure file transmission on page Analyze the Entrust IdentityGuard production file and select the appropriate card or paper stock for printing. 3 Have the Entrust IdentityGuard cards produced. 4 Notify the end user about card pick-up and activation, or mail the card based on user address information included in the Entrust IdentityGuard production file; for example, the company s internal mailing information. 5 Authenticate the end user either face-to-face in the over-the-counter service desk scenario or follow the activation instructions contained in the Entrust IdentityGuard card mailing. Outsourced card production Take the outsourced approach if using an external card production partner to produce and distribute Entrust IdentityGuard cards. For quantities greater than 1000, Entrust can assist in sourcing an appropriate card production partner. For information on outsourced card production options, contact Entrust ( Obtaining technical assistance on page 17). If you use an outsourced card production facility, negotiate the contracts and service level agreements. In the case of an existing relationship, update them with the new requirements and procedures for transmitting card and user data. For quantities up to 1000, see Entrust IdentityGuard card production on page 105. Typical Characteristics The following are general characteristics of deployments involving outsourced card production: The organization using Entrust IdentityGuard cards does not have an internal card production capability or elects not to use the internal capability. The organization using Entrust IdentityGuard is a large scale geographically dispersed company. 104 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

105 Setup The following areas need to be addressed prior to starting any outsource Entrust IdentityGuard card production: Select a card production facility for Entrust IdentityGuard card production and distribution. (Entrust can recommend a card production partner.) Create card production partner agreements. Inventory existing card stock (letter stock, card artwork, logo, branding). Write a welcome letter or activation instructions. Secure inter-organization transmission capability: for Entrust IdentityGuard card generation information for Entrust IdentityGuard card distribution Send cards to users or deliver cards to the service desk for internal distribution. Process The following steps are involved in outsourcing Entrust IdentityGuard card production. To outsource card production 1 Securely send the Entrust IdentityGuard production file to the card production facility in either an encrypted file format or a secure FTP arrangement. 2 Analyze the Entrust IdentityGuard production file and select the appropriate Entrust IdentityGuard user/card/paper stock for printing. 3 Analyze the Entrust IdentityGuard production file for personalization information to be printed on the individual Entrust IdentityGuard cards. 4 Analyze the Entrust IdentityGuard production file for Entrust IdentityGuard card shipping instructions. 5 Produce the Entrust IdentityGuard cards and insert them into addressed envelopes for distribution. 6 Distribute the cards using the shipping instructions provided in the Entrust IdentityGuard production file. You can ship the cards to the end user directly, or handle the distribution yourself. 7 The end user follows the activation instructions contained in the card mailing. Entrust IdentityGuard card production For quantities up to 1000, the Entrust IdentityGuard Card Production Service, available from Entrust TrustedCare Online, provides a convenient and secure way to Deploying grid authentication 105

106 order Entrust IdentityGuard cards over the Web. Administrators can order cards online against a previously issued purchase order. Administrators also have the flexibility to modify the card template to meet their requirements. Typical characteristics The following are general characteristics of deployments involving Entrust IdentityGuard card production: The organization using Entrust IdentityGuard cards does not have an internal card production capability or elects not to use the internal capability. The organization would like to setup at quick pilot deployment. Setup The following areas must be addressed prior to starting any Entrust IdentityGuard card production: Select one of three card options: a generic card with a preproduced grid a generic card with customer assigned grid a customer card with a customer assigned grid For more information on this topic, refer to the Entrust IdentityGuard Card Production Service User Guide. Card production cost factors The following are factors which influence the cost of Entrust IdentityGuard card production: Card/paper quality: Cost increases with the thickness of the card material. Removable scratch covers cost more. Card volume: Discounts apply to higher volumes. Branding detail (logos, colors): More colors and complex graphics increase costs. Personalization detail: Bulk production of unassigned cards is cheaper. Personalization requires creating and matching the insert letter and envelope with the correct card for each user. It also requires protection of personal information, which may increase the cost of secure file transmission. Distribution requirements: Where and how the cards are shipped influences costs. Bulk mailing versus individual distribution, standard post versus courier, and geographical locations all affect costs. 106 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

107 Secure file transmission Ensure that the Entrust IdentityGuard production file and any personal information (for example, name and address) of the end user is transferred securely. To do so, consider the following: SSL: The Entrust IdentityGuard Card Production Service provides an SSL-protected Web site with electronic forms that accepts the Entrust IdentityGuard production file as an attachment. This protects the data by encrypting it in transit. This technique is simple to deploy and uses well understood technology. Secure You can transmit the Entrust IdentityGuard production file as an attachment in a secure using S/MIME or PGP. This ensures that only the intended recipient can open the file for subsequent processing. You can also digitally sign the to validate your identity. This technique is simple to deploy and uses well understood technology, if you have a secure system. Secure FTP: You can transmit the Entrust IdentityGuard production file using an encrypted FTP session. The data is encrypted in transit and, depending on the implementation, may also be digitally signed for integrity. It requires the receiving organization to set up a secure FTP server and to provide access to the sending organization. While the setup may take longer than SSL or secure , secure FTP allows for automated transmission, which is important in very large deployments. End-to-end encryption: An alternative to secure FTP is to encrypt and digitally sign the Entrust IdentityGuard production file prior to transmission. You can then transmit the file by any available means (for example, HTTP, , or FTP), as only the intended recipient can open the file for subsequent processing. The recipient can be a person, who will submit the file for processing, or an application, which decrypts the file immediately before processing it. This technique provides the broadest security over the Entrust IdentityGuard production file, but requires careful planning to implement. Consideration needs to be given to the management of the encryption keys, which can be assisted with the use of a public key infrastructure (PKI). Deploying grid authentication 107

108 Automating processes To enhance the existing functionality of Entrust IdentityGuard and facilitate deployment, the following points list and discuss areas that are candidates for automation. Actual implementation details will vary depending on your specific requirements and environment. Entrust IdentityGuard provides a mechanism for exporting grids for cards in XML and CSV format for all existing users. To automate this export, an application would run that exports the grid information to an XML file. The application could run unattended as a batch job and would also encrypt the XML information for secure transfer. Additional functionality to manipulate the format of the file or add in user information may also be required, depending on the requirements of the card producer. Depending on the card production and distribution model chosen, there may be a requirement to extract user information, such as name and address, from other corporate information sources. In this case, write a generic application to extract end user information from a single repository and make it available in an encrypted XML or CSV file. The application would use the Entrust IdentityGuard user name as a key to extract the user s full name and mailing information. The LDAP attributes or database table name and fields would all be configured parameters. Bulk user creation abilities and an automated application would allow an administrator to extract information from the Entrust IdentityGuard repository and put it into the correct format for input into bulk operations. Meet reporting and auditing requirements by developing an application that will generate reports of users in different card states (active, expired, nonactivated and idle). You can run this reporting application unattended as a batch job at any time. Entrust IdentityGuard provides interfaces for administrators to perform user management activities and APIs that you can use to build a user self-service application. User life cycle management on page 113 describes the process models for user self-service; write a Web application to support this model using the Entrust IdentityGuard Administration API. 108 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

109 Chapter 6 Deploying token authentication This chapter provides deployment information about token authentication. Topics in this chapter: Using tokens for authentication on page 110 Token deployment on page 111 Physical token security on page

110 Using tokens for authentication Users can authenticate to Entrust IdentityGuard using tokens. By default, Entrust IdentityGuard supports the Entrust IdentityGuard Mini Token and the Entrust IdentityGuard Pocket Token (response-only mode). The Mini Token is available in an AT version (a time+event synchronous token) and an OE version (an OATH compliant token). Note: Entrust IdentityGuard does not support ActivIdentity tokens. You can configure Entrust IdentityGuard to accept tokens from some third-party token vendors. (See the Entrust TrustedCare Online Web site for details on supported tokens.) Once Entrust IdentityGuard and users are set up to accept tokens, users can enter a dynamic password (the random number generated by a token device) in response to an Entrust IdentityGuard challenge. Entrust IdentityGuard checks if the dynamic password is valid and, if it is, authenticates the user. To set up Entrust IdentityGuard to accept tokens, a master user must first load the tokens into an Entrust IdentityGuard repository. Once the token data is loaded, you supply users with token devices and assign matching token serial numbers. Token lifetime and replacement Each user can use one token device at a time. However, a user entry can have a current token and a token in pending state. For example, if the current token has low batteries, you can associate a pending token to the user entry to replace the existing token. Once the user authenticates with the new token, the state changes from pending to current. The old token is canceled by Entrust IdentityGuard. Token PINs Some third-party tokens can require that users enter token PINs as part of token authentication. Entrust IdentityGuard supports token PINs and provides features to support the changing and updating of token PINs. Entrust tokens do not use token PINs. 110 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

111 Token deployment Token deployment is similar to preproduced grid card deployment. The main difference is in the method used to add tokens to the repository. A box of tokens comes with a token data file. You add tokens to an Entrust IdentityGuard repository by importing the token data file supplied by the token vendor. Once the token data is loaded, you supply token devices and assign token serial numbers to your users. Tokens are initially loaded as unassigned tokens. Unassigned tokens cannot be used for authentication until assigned to users. Assigning tokens A master user or administrator assigns tokens to users. Tokens have the same states as cards (pending, pending_hold, current, hold and canceled). Only tokens that are in the pending and current states are used for authentication. A user can have a single token in the pending/pending_hold state and the current/hold state. These states have the same transition behavior as cards. User tokens will not have an expiry or superseded date. Any token can be unassigned which will add it back to the list of unassigned tokens. Token self-registration You can send tokens to users so that they can register their tokens themselves. When the user receives the token, they must activate it. The user authenticates (with for example, a user name and password) to a self-registration Web site. The user enters the serial number of the token, however they must also authenticate using the token to demonstrate that they possess the physical device. After successful authentication, the token is changed from unassigned to pending, or current. If the authentication fails, the token is unassigned. Deploying token authentication 111

112 Physical token security Entrust IdentityGuard can be deployed in multiple forms, including a token deployment. The following is recommended: Do not put specific information or branding on the token that will identify your site as a potential attack point if a token is lost or stolen. Consider adding a feature to your application where the application displays the user s last successful login time and date. If this information does not match the user s personal experience, this will alert the user that some form of attack may have occurred. Define a user policy and educate users on appropriate token handling to prevent users from unwittingly exposing their token data to an attacker, both physically and electronically. 112 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

113 Appendix A User life cycle management This appendix provides information on the Entrust IdentityGuard user life cycle. Sections in this appendix: Life cycle management overview Enrolment on page 115 Usage on page 116 Renewal on page 117 Replacement on page 118 Delivery and activation on page 120 Maintenance on page

114 Life cycle management overview This section describes the high-level processes for managing the life cycle of Entrust IdentityGuard end users. Since Entrust IdentityGuard is a multifactor authenticator, a user account must already exist in the first-factor authentication application (for example, user name and password). No assumptions are made about organizations procedures for managing user accounts. User life cycle management consists of the following stages and processes: 1 Enrolment is the initial stage where users enroll for the Entrust IdentityGuard service. 2 Usage is the normal operations stage where users are authenticated with their Entrust IdentityGuard authentication methods. 3 Renewal is an ongoing stage where users are issued new Entrust IdentityGuard grids (on new cards), tokens, one-time passwords, or questions to replace older ones. 4 Replacement covers the handling of: lost, stolen, damaged, and left behind Entrust IdentityGuard cards, passcode lists, or tokens forgotten answers and one-time passwords End users are issued temporary PINs (if using cards, lists, or tokens) or a one-time passwords, and, if necessary, receive a replacement Entrust IdentityGuard card, list or token. 5 Delivery and activation describes the processes to physically deliver the Entrust IdentityGuard cards, lists, or tokens (as applicable) and activate the authentication method. It does not apply to other authentication methods. 6 Maintenance describes the processes to: Remove stale or idle cards or tokens from the Entrust IdentityGuard system. This includes cards or tokens that are cancelled, deactivated or unassigned as well as cards or tokens assigned to terminated user accounts. Update machine registration. Remove old one-time passwords. Update any graphics or images used for mutual authentication. 114 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

115 Enrolment Enrolment is the first stage of the life cycle whereby: Users are registered in the Entrust IdentityGuard system. Users are provided with an Entrust IdentityGuard authentication method and associated data (such as a card or passcode list). The authentication method is activated. For the enrolment processes, ensure you have processes and procedures in place to create and manage user accounts and to issue the authentication credentials (such as user name and password). Depending on the authentication methods assigned to users, the following are examples of events that may occur: Entrust IdentityGuard grids are assigned to end users and Entrust IdentityGuard cards are produced. Microsoft Windows desktop users install Entrust IdentityGuard Desktop. Tokens are assigned to end users and mailed to them, along with instructions on activation. Users are directed to a Web page where they go through a registration process that sets up the questions and answers specific to them. Computers are registered. If you are using cards, passcode lists, or tokens, complete the enrolment process with Delivery and activation on page 120. User life cycle management 115

116 Usage During the usage stage, users are actively logging into your system using the authentication methods available to them. The Entrust IdentityGuard system locks out a user after a configured number of incorrect responses to a prompt (for example, three incorrect responses). This is necessary to protect against a brute force attack whereby an attacker attempts to log in by simply guessing the correct response to an Entrust IdentityGuard challenge. However, a legitimate user can be locked out by making consecutive errors. The Entrust IdentityGuard system will release the lock out after a defined time period (for example, 20 minutes), but this may be inconvenient to the user. The Entrust IdentityGuard administrator can also release a lock. Organizations should design their customer service procedures for this situation to ensure that proper identity verification is performed before unlocking an end user s account. 116 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

117 Renewal You should ensure users renew their authentication data (such as their passwords, tokens, cards, and knowledge-based information) on a regular basis. Once the data has reached an expiry date or usage amount, it is important that users are not denied service. Ensure you put a process in place that completes the following actions (when applicable) before expiry: a new card, passcode list, or token is issued and delivered to the user a new one-time password is generated and delivered to the user a user is redirected to a page that requests new knowledge-based information An automated central renewal service is recommended so that you do not have to burden your staff with the overhead of administering routine renewals. Figure 19 on page 117 illustrates the high level process steps for renewal. Figure 19: Enterprise renewal Select users (bulk operation ) Generate and assign new authentication data If applicable, produce cards, lists, order tokens To delivery and activation To renew 1 An administrator extracts information from the Entrust IdentityGuard repository, selecting users whose Entrust IdentityGuard authentication data will expire within a specified time frame. This should be done on a regularly scheduled basis. 2 To generate and assign new authentication data: for grids, one-time passwords, and passcode lists, Entrust IdentityGuard generates and assigns new authentication data (such as the grid) for each selected user name for tokens, administrators assign a new token to the user for knowledge-based information or image/graphic replay authentication, an application requests new information from a user when they log in 3 If applicable, produce new cards and passcode lists or order more tokens. Card production is discussed in detail in the section Deploying grid authentication on page 87. If you are using cards, passcode lists, or tokens, complete the renewal process with Delivery and activation on page 120. User life cycle management 117

118 Replacement It is natural that Entrust IdentityGuard authentication data may be misplaced, lost, stolen, forgotten, damaged or left behind. Therefore, to ensure users are not inconvenienced, it is important to have contingency measures in place to continue to provide users with the access they need until replacement data is in their possession. For cards, passcode lists, or tokens, the Entrust IdentityGuard system provides a temporary PIN on an as-required basis. For other types of authentication data (such as knowledge-based or one-time password), your application needs to provide some means for a user to request new passwords or hints to answers. Figure 20 illustrates the high level process steps for replacement. Figure 20: Enterprise replacement Over-the-counter recovery (verify identity) Self-service recovery (verify identity) Provide temporary authentication means Recover/replace authentication data To delivery and activation Central service recovery (verify identity) To replace 1 A user needs to verify their identity and start the recovery process. There are three approaches: Over-the-counter recovery (identity verification): In the over-the-counter approach, the user visits the service desk and requests replacement authentication data. The service desk performs in-person identity verification to ensure that the request is legitimate. This approach is useful where a visit to the service desk is mandatory (for example, the Entrust IdentityGuard grid is printed on the back of an employee ID card). Self-Service recovery (identity verification): In the self-service approach, the user has access to a self-recovery application. The application performs an 118 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

119 identity verification procedure, possibly using a question and answer system, to ensure that the request is legitimate. The questions and answers for recovery must have been created by the user during the enrolment process or through a separate application after enrolment. Central service recovery (identity verification): In the central service approach, the user calls the service desk and requests a recovery. The service desk performs identity verification over the phone to ensure that the request is legitimate. 2 The application or service desk administrator provides a user with temporary authentication means. If provided by an application, ensure the information is displayed in non-machine readable format. If using grid or token authentication, the administrator or application should suspend or cancel the current card or token, and provide the user with a temporary PIN. Cancellation is recommended for lost, stolen and damaged cards and tokens. A left behind card or token (for example, the user knows where the card is and it is safe from attack) can be suspended. Attention: The cancellation process is irreversible for cancelled cards, lists or tokens. They can never be used again. For information on temporary PINS, see Temporary PIN authentication on page 55. If using out-of-band authentication, another one-time password should be generated. Generating a new password cancels the old one. If using knowledge-based authentication, present hints to the user that were provided during registration, or, if that doesn t help, issue a one-time password until the user can complete the recovery process. 3 Determine whether you need to replace or recover the authentication data. For cards, passcode lists, or tokens, the user may indicate whether replacement or re-activation is necessary. If you cancel the card, list, or token, then you must replace it. Ensure the temporary PIN is cancelled when the user has successfully authenticated using a re-activated or new card, list, or token. If using knowledge-based authentication or image and graphic replay authentication, it is recommended that, if the information is permanently forgotten, the user reset their information by accessing a secured Web page (such as one located on your Intranet). Optionally, you can ensure that they enter a one-time password in order to verify their identity when accessing the page, or call up an administrator to complete the process. If you are using cards, passcode lists, or tokens, complete the replacement process with Delivery and activation on page 120. User life cycle management 119

120 Delivery and activation Delivery and activation processes are common to the enrolment, renewal and replacement life cycle stages for cards, passcode lists, and tokens. Once Entrust IdentityGuard authentication data (new, renewal or replacement) has been produced, it must be delivered to the rightful owner and activated. The physical distribution of authentication data will require both distribution and inventory management processes. The specific requirements depend on whether the cards or tokens will be picked up in person, mailed out, delivered by courier, or a combination of these. For each of these options, distribution may be centralized into one location, to a few locations such as regional offices, or many locations such as branch or retail centers. Appropriate security and tracking processes should be in place for physical distribution and managing inventory. Figure 21 on page 120 illustrates the high level process steps for delivery and activation. Figure 21: Enterprise delivery and activation From enrolment, replacement, or renewal Deliver card, passcode list, or token to user Deliver card, passcode list, or token to central service desk User pickup (Verify identity, personalization ) Activate authentication method To deliver and activate 1 There are two ways cards, passcode lists, and tokens can be delivered: Use an over-the-counter service that hands the Entrust IdentityGuard card, list, or token to the user immediately. This may involve an in-person pickup. For example, the Entrust IdentityGuard grid may be printed on the back of an employee ID badge that requires a recent photo on the front. Use a central service that produces or assigns Entrust IdentityGuard cards, lists, or tokens one at a time in response to user requests. Administrators can be given the option of mailing the card, list or token directly to the user. 2 If you are using a central service, the user must visit the service desk and any personalization procedures are performed. You can require the service desk to 120 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

121 perform an identity verification procedure to ensure that the card, list or token is delivered to the rightful owner. 3 Activate the card, list or token using the authentication application. You can use one of two approaches: In the over-the-counter approach, the administrator can activate the Entrust IdentityGuard card, list, or token immediately before handing it to the user. Have the user initiate the activation by using the Entrust IdentityGuard authentication method in an authentication transaction. This can be as simple as using the Entrust IdentityGuard grid or token on the next login to the first-factor authentication application. The activation procedures need to consider the requirements for capturing information for self-service card, list, or token replacement (see Replacement on page 118). User life cycle management 121

122 Maintenance Maintenance procedures are required to remove stale or idle data from the Entrust IdentityGuard system. Ensure the Entrust IdentityGuard administrator performs the following tasks regularly: Remove cancelled cards, lists, and tokens: The renewal and replacement stages result in old Entrust IdentityGuard cards, lists and tokens being replaced by new ones. At the time the new card, list or token is activated, the old card, list or token is cancelled. This process is irreversible cancelled cards, lists or tokens can never be used again. However, the associated information is retained in the repository. You should establish policies for: the archival and removal of cancelled grids or tokens on a periodic basis whether or not archives need to be retained and, if so, for how long Remove inactivated cards, lists and tokens: Enterprise deployments should not encounter many Entrust IdentityGuard cards, lists, and tokens that fail to be activated, although they can get lost in transit. Users are expected to notify the service desk in such circumstances. A replacement card, list or token would then be issued and the inactivated card, list of token cancelled. The Entrust IdentityGuard administrator can check for inactivated items on a periodic basis to ensure that other circumstances are identified and actions are taken to ensure they are either activated by the rightful owner or cancelled. Remove unassigned grids and tokens: Like tokens, grids added in the preproduction model are initially unassigned. The Entrust IdentityGuard administrator, in conjunction with the service desk, should perform an inventory check on a periodic basis to identify any lost grids and tokens and cancel them. It is expected that the service desk will maintain proper inventory control and that few unassigned cards or tokens, if any, will be lost. Synchronization with repository: The first-factor authentication application repository has user maintenance activities that need to be synchronized with the Entrust IdentityGuard system. In particular, when user accounts are terminated, the associated Entrust IdentityGuard information should be removed. Coordinate maintenance activities between the Entrust IdentityGuard administrator and the repository administrator. 122 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

123 Appendix B Entrust IdentityGuard baseline architectures This section outlines some baseline architectures and complements the information regarding architecture and deployment provided in the other guides in the Entrust IdentityGuard documentation suite. Refer to the Administration Guide for more information on the architectural and deployment issues that influence the choice of architecture and configuration of your Entrust IdentityGuard solution. Topics in this appendix: Architecture overview on page 124 Web access on page 126 VPN remote access on page 131 Microsoft Windows remote access on page 136 Microsoft Windows desktop on page

124 Architecture overview There are three levels of baseline architectures in this section: Evaluation suitable for test and Proof of Concept (POC) environments designed to be low cost to implement by minimizing the required equipment and are not suitable for production environments represent a limited environment that you can set up quickly for proof-of-concept, investigation of functionality, and so on not intended for production purposes Assumptions: generally very small, ranging from a few users up to a hundred used for test purposes only no firewalls no NTP service; clock is set manually typically resides within a development environment or on an isolated network segment Standard suitable for production implementations from pilot phase through initial rollout lack equipment redundancy; any standard grade environment should be implemented with robust equipment to provide a moderately high level of availability and performance standard grade baseline architectures are production environments suitable for medium volume environment Assumptions: support for internal or external users generally moderate in size, supporting tens of thousands of users multiple firewalls create zones for increasing levels of security limited provision for failover and continued operation in the case of component failure more complex to set up than the evaluation grade architectures due to the use of firewalls and other security provisions, as well as the use of separate servers for each function to support higher throughput an NTP service, connected to a trusted time source (for example, a Stratum 1 or Stratum 2 time server), is available to ensure clock accuracy for tokens 124 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

125 some downtime is acceptable; no provision is made for replicated systems a backup strategy to ensure that the data stores and system disks can be rebuilt in the event of a hardware failure you can complement this backup strategy with a disk mirroring strategy that would reduce recovery time in the event of a disk failure network architecture already in place, adding Entrust IdentityGuard High availability suitable for large scale production implementations that demand the highest levels of availability and performance expand upon the standard grade configurations by adding redundancy for both high availability and scalability high availability grade baseline architectures are intended for production purposes in a high volume environment, whether supporting internal or external users Assumptions: higher throughput than standard grade baseline architectures high availability for these architectures includes the use of redundant systems, links, trusted time sources, and data stores more complex to set up because of the significant provision for security, performance, and availability deployments are generally large, supporting millions of users use of load-balancers to achieve high availability for Entrust IdentityGuard user session stickiness configured on load balancers to provide the ability to consistently bring a user back to the same Entrust IdentityGuard Server this can be based on SSL session ID, IP address, cookie, or HTTP redirection. This feature is required in a multiple Entrust IdentityGuard Server architecture where challenge/response caching is used. limiting factor would eventually become the user authentication repository. Therefore, scaling of the user authentication repository must be taken into consideration. Note: Entrust Professional Services can provide more information on an architecture suitable to your requirements. For contact information, refer to Obtaining technical assistance on page 17. Entrust IdentityGuard baseline architectures 125

126 Web access You can deploy the Web access baseline architecture in an evaluation, standard or high availability environment. Web access - evaluation The following diagram (Figure 22 on page 126) demonstrates how you can set up Entrust IdentityGuard to provide multifactor authentication for your Web resources. Figure 22: Web authentication evaluation architecture Directory or Database Client Web server or Application server Entrust IdentityGuard Server Requirements Directory or database with user repository Entrust IdentityGuard Server Web server or application server running an application that completes first-factor authentication (user name and password) and manages the repository client with Web browser 126 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

127 Available Entrust IdentityGuard authentication methods You can evaluate all Entrust IdentityGuard authentication methods when you have users accessing your organization using their Web browsers. Web access - standard The standard architecture, shown in Figure 23 on page 127, extends the evaluation architecture ( Web access - evaluation on page 126) by: adding firewalls, which provide network segmentation for the authentication and application systems separate servers for the Web server and application server (consistent with best practice for security, availability and performance) a separate computer for user administration An administrator will use the Entrust IdentityGuard Administration interface on this computer for user management tasks. Figure 23: Web access standard architecture Firewall Firewall Application server Client Web server Directory or Database Administrator Entrust IdentityGuard Server Requirements Directory or database with user repository on a dedicated server Entrust IdentityGuard baseline architectures 127

128 Entrust IdentityGuard Server application server running an application that completes first-factor authentication (user name and password) and manages the repository Web server located in DMZ that relays information between the client, the application server, and Entrust IdentityGuard Server client with Web browser hard and soft firewalls creating a DMZ for the Web server, and protecting internal resources an administrator to manage Entrust IdentityGuard users Available Entrust IdentityGuard authentication methods You can use all Entrust IdentityGuard authentication methods when you have users accessing your organization using their Web browsers. Web access - high availability The architecture shown in Figure 24 on page 129, extends the standard architecture ( Web access - standard on page 127) by adding load balancers, replica Entrust IdentityGuard Servers, and replicated user repositories. It is expected that the network components (for example, routers, firewalls, and so on), Web servers and application servers are configured so as to provide high availability and performance. 128 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

129 Figure 24: Web access high availability architecture Firewall Firewall Application server cluster Entrust IdentityGuard Server Client Web server cluster Load -balancing cluster Directory or Database cluster Administrator Entrust IdentityGuard Server Requirements replicated directories or databases with the user repository set up in a high-availability or disaster recovery cluster Entrust IdentityGuard Servers load-balancers to divide the load between the various Entrust IdentityGuard Servers replicated application servers running the application that completes first-factor authentication (user name and password) and manages the repository replicated Web servers located in DMZ that relay information between the client, the application server, and Entrust IdentityGuard Server client with Web browser Entrust IdentityGuard baseline architectures 129

130 hard and soft firewalls creating a DMZ for the Web servers, and protecting internal resources administrators to manage Entrust IdentityGuard users Available Entrust IdentityGuard authentication methods You can use all Entrust IdentityGuard authentication methods when you have users accessing your organization using their Web browsers. 130 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

131 VPN remote access You can deploy the VPN remote access baseline architecture in an evaluation, standard or high availability environment. VPN remote access - evaluation Use this architecture to evaluate how Entrust IdentityGuard can integrate with your current VPN solution to provide second-factor authentication to remote users. Figure 25: VPN remote access evaluation architecture Entrust IdentityGuard Radius proxy First-factor authentication resource : Radius server, domain controller, LDAP directory VPN client VPN device Entrust IdentityGuard Server Directory or Database Requirements Directory or database with user repository If using a database, you can optionally install it on the same computer as the one hosting Entrust IdentityGuard Server. Entrust IdentityGuard Server Entrust IdentityGuard Radius proxy, configured on the Entrust IdentityGuard Server computer a first-factor authentication resource, such as a Remote Authentication Dial In User Service (Radius) server, a domain controller, or an LDAP-compliant Directory (see External authentication on page 56) Entrust IdentityGuard baseline architectures 131

132 VPN device (IPsec or SSL) Client with VPN connection (dial up, wireless, and so on) Available Entrust IdentityGuard authentication methods grid authentication token authentication VPN remote access - standard The standard architecture, shown in Figure 26 on page 132, extends the evaluation grade baseline architecture by adding firewalls, which provide network segmentation for the authentication systems, and user administration. An administrator will use the Entrust IdentityGuard Administration interface on this computer for user management tasks. Figure 26: VPN remote access standard architecture Firewall Firewall Entrust IdentityGuard Radius proxy VPN client VPN device Entrust IdentityGuard Server First-factor authentication resource : Radius server, domain controller, LDAP directory Administrator Directory or Database Requirements Directory or database with user repository on a dedicated server 132 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

133 Entrust IdentityGuard Server Entrust IdentityGuard Radius proxy, configured on the Entrust IdentityGuard Server computer a first-factor authentication resource, such as a Radius server, a domain controller, or an LDAP-compliant Directory (see External authentication on page 56) VPN device (IPsec or SSL) client with VPN connection (dial up, wireless, and so on) hard and soft firewalls creating a DMZ for the VPN device, and protecting internal resources an administrator to manage Entrust IdentityGuard users Available Entrust IdentityGuard authentication methods grid authentication token authentication VPN remote access - high availability The architecture in Figure 27 on page 134 extends the standard VPN remote access diagram ( VPN remote access - standard on page 132) by adding load balancers, replica Entrust IdentityGuard servers, and replicated user repositories. It is expected that the network components (for example, VPN devices, routers, firewalls, and so on), and first-factor authentication resources are configured so as to provide high availability and performance. Entrust IdentityGuard baseline architectures 133

134 Figure 27: VPN remote access high availability architecture Firewall Firewall Entrust IdentityGuard Radius proxy Entrust IdentityGuard Server VPN client VPN device Load-balancing cluster Entrust IdentityGuard Radius proxy First-factor authentication resource cluster : Radius servers, domain controllers, LDAP directories Administrator Entrust IdentityGuard Server Directory or Database cluster Requirements replicated directories or databases with the user repository set up in a high-availability or disaster recovery cluster Entrust IdentityGuard Servers load-balancers to divide the load between the various Entrust IdentityGuard Servers Entrust IdentityGuard Radius proxies, configured on the Entrust IdentityGuard Server computers a cluster of first-factor authentication resources, such as Radius servers, a domain controllers, or LDAP directories (see External authentication on page 56) VPN devices (IPsec or SSL) clients with VPN connection (dial up, wireless, and so on) 134 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

135 administrators to manage Entrust IdentityGuard users hard and soft firewalls creating a DMZ for the VPN devices, and protecting internal resources Available Entrust IdentityGuard authentication methods grid authentication token authentication Entrust IdentityGuard baseline architectures 135

136 Microsoft Windows remote access You can deploy the Microsoft Windows remote access baseline architecture in an evaluation, standard or high availability environment. Microsoft Windows remote access - evaluation Use this architecture to evaluate how Entrust IdentityGuard can add second-factor authentication to Microsoft Windows remote users. Figure 28: Microsoft Windows remote access evaluation architecture Active Directory and domain controller Microsoft Remote Access Client Microsoft RRAS with Entrust IdentityGuard Remote Access Plug-in Entrust IdentityGuard Server Requirements Active Directory with user repository Domain controller (you can install it on the same machine as the user repository) Entrust IdentityGuard Server Microsoft Routing and Remote Access Service (RRAS) with Internet Authentication Service (IAS) Entrust IdentityGuard Remote Access Plug-in for Microsoft Windows Server installed on RRAS computer 136 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

137 client with Microsoft Remote Access capabilities Available Entrust IdentityGuard authentication methods grid authentication Microsoft Windows remote access - standard The Microsoft Windows remote access standard architecture, shown in Figure 29 on page 137, extends the evaluation architecture by adding a firewall and user administration so that you can provide second-factor authentication to the Microsoft remote users in your organization. Figure 29: Microsoft Windows remote access standard architecture Firewall Firewall Distributed domain with Active Directory Microsoft Remote Access Client Microsoft RRAS with Entrust IdentityGuard Remote Access Plug-in Administrator Entrust IdentityGuard Server Requirements distributed domain configuration with user repository Entrust IdentityGuard Server Entrust IdentityGuard baseline architectures 137

138 Microsoft Routing and Remote Access Service (RRAS) with Internet Authentication Service (IAS) Entrust IdentityGuard Remote Access Plug-in for Microsoft Windows Server installed on the IAS computer client with Microsoft Remote Access capabilities hard and soft firewalls creating a DMZ for the RRAS, and protecting internal resources an administrator to manage Entrust IdentityGuard users Note: Optionally, you can set up an architecture in which the IAS is enabled on a different computer than the RRAS. In that instance, you need to install the Remote Access Plug-in on the computer hosting the IAS. Available Entrust IdentityGuard authentication methods grid authentication token authentication Microsoft Windows remote access - high availability The architecture in Figure 30 on page 139 extends the standard Microsoft Windows remote access diagram ( Microsoft Windows remote access - standard on page 137) by adding load balancers, replica Entrust IdentityGuard Servers, and replicated user repositories. It is expected that the network components (for example, access servers, routers, firewalls, and so on), and first-factor authentication resources are configured so as to provide high availability and performance. 138 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

139 Figure 30: Microsoft Windows remote access high availability architecture Firewall Firewall Distributed domain with Active Directory Entrust IdentityGuard Microsoft Remote Access Client Microsoft RRAS with Entrust IdentityGuard Remote Access Plug-in Load-balancing cluster Entrust IdentityGuard Administrator Requirements distributed domain configuration with replicated user repository Entrust IdentityGuard Servers load-balancers to divide the load between the various Entrust IdentityGuard Servers Microsoft Routing and Remote Access Service (RRAS) with Internet Authentication Service (IAS) Entrust IdentityGuard Remote Access Plug-in for Microsoft Windows Server installed on the IAS computer client with Microsoft Remote Access capabilities hard and soft firewalls creating a DMZ for the Remote Access Server, and protecting internal resources an administrator to manage Entrust IdentityGuard users Entrust IdentityGuard baseline architectures 139

140 Note: Optionally, you can set up an architecture in which the IAS is enabled on a different computer than the RRAS. In that instance, you need to install the Remote Access Plug-in on the computer hosting the IAS. Available Entrust IdentityGuard authentication methods grid authentication 140 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

141 Microsoft Windows desktop You can deploy the Microsoft Windows desktop baseline architecture in an evaluation, standard or high availability environment. Microsoft Windows desktop - evaluation This architecture (shown in Figure 31 on page 141) demonstrates how you can use Entrust IdentityGuard to provide second-factor authentication to Microsoft Windows users when they log in to their computer. Figure 31: Microsoft Windows desktop authentication evaluation architecture Active Directory and domain controller Entrust IdentityGuard Desktop for Microsoft Windows Entrust IdentityGuard Server Requirements Active Directory with user repository domain controller (you can install it on the same machine as the user repository) Entrust IdentityGuard Server Entrust IdentityGuard Desktop for Microsoft Windows installed on a computer or laptop Entrust IdentityGuard baseline architectures 141

142 Available Entrust IdentityGuard authentication methods grid authentication Microsoft Windows desktop - standard The Microsoft Windows desktop standard architecture, shown in Figure 32 on page 142, extends the evaluation architecture by adding a firewall and user administration so that you can provide second-factor authentication to the desktop users in your organization. Figure 32: Microsoft Windows desktop standard architecture Firewall Entrust IdentityGuard Desktop for Microsoft Windows Distributed domain with Active Directory Administrator Entrust IdentityGuard Server Requirements distributed domain configuration with user repository Entrust IdentityGuard Server firewall Entrust IdentityGuard Desktop for Microsoft Windows installed on end users computers or laptops 142 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

143 an administrator to manage Entrust IdentityGuard users Available Entrust IdentityGuard authentication methods grid authentication Microsoft Windows desktop - high availability The high availability grade baseline architecture, shown in Figure 33 on page 143, extends the standard grade baseline architecture by adding load balancers and replica Entrust IdentityGuard Servers, and replicated user repositories. It is expected that the network components (for example, routers, firewalls, and so on), and domain controllers will be configured so as to provide high availability and performance. Figure 33: Microsoft Windows desktop authentication high availability architecture Firewall Entrust IdentityGuard Desktop for Microsoft Windows Distributed domain with Active Directory Entrust IdentityGuard Administrator Load -balancing cluster Entrust IdentityGuard Entrust IdentityGuard baseline architectures 143

144 Requirements distributed domain configuration with replicated user repository Entrust IdentityGuard Servers load-balancers to divide the load between the various Entrust IdentityGuard Servers firewall Entrust IdentityGuard Desktop for Microsoft Windows installed on end users computers or laptops an administrator to manage Entrust IdentityGuard users Available Entrust IdentityGuard authentication methods grid authentication 144 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

145 Appendix C Card usability study Entrust IdentityGuard was introduced to the market in late Since inception, it has generated significant interest in the market due to its ability to cost-effectively combat identity theft (using phishing and pharming) as well as address enterprise desktop and remote access security needs. In order to validate its assumed ease of use in both consumer and enterprise environments, an independent usability assessment for its grid authentication method was conducted by Design Interpretive with a total of 344 people in May The extremely positive results of the study validate how easy Entrust IdentityGuard grid authentication is to use for both consumer and enterprise application security. Sections in this appendix: Entrust IdentityGuard card usability study on page 146 Recommendations on page 149 Grid authentication implementation on page

146 Entrust IdentityGuard card usability study For organizations who want a strong authentication solution that is easy to use and deploy, the results of this study show that Entrust IdentityGuard grid authentication is an ideal candidate. Built and supported by security experts from Entrust, Entrust IdentityGuard delivers a highly secure way of strongly authenticating users, whether in a consumer situation that demands increased protection against identity theft, or an enterprise situation that is looking to strengthen security for applications like remote access or desktop authentication. Topics in this section: Usability test summary on page 146 Objective on page 146 Methodology on page 147 Usability test results on page 147 Usability test summary Usability of Entrust IdentityGuard grid authentication was excellent and received a very high accuracy rate for authentication. There were no statistical performance differences across the card designs (varying sizes/layouts). The procedure required to successfully complete the Entrust IdentityGuard challenge is inherently simple and has high user acceptance. 100% achieved unaided successful login in two attempts. 93% of participants were somewhat or very willing to use it once per day. The PIN login procedure for forgotten or lost cards was straightforward and well understood by users. 100% achieved unaided successful login in two attempts. Objective The objective of the study was to assess the overall usability of Entrust IdentityGuard grid authentication in both consumer and enterprise deployment scenarios. In addition, the study looked to maximize the usability of Entrust IdentityGuard grid authentication by formally testing various design implementations of: the coordinates table, for example number of cells and the visual delineation of rows and columns 146 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

147 the login screen design and challenge process flow, for example, whether the challenge is consolidated into one screen or spread across two screens The objective of these formal tests was to provide recommendations based on testing, as well as gather user feedback on their experience. Methodology The test had two separate execution phases, focusing independently on a consumer environment through Web testing and an enterprise environment for desktop authentication. It should be noted that although desktop authentication was tested only for enterprise users, the expectation is that similar excellent results would be achieved for using Entrust IdentityGuard grid authentication for remote access applications like IP-SEC or Enterprise methodology: The enterprise test was conducted using a face-to-face interview technique. Desktop authentication with Entrust IdentityGuard cards was used as the method of understanding the usability in the enterprise, with the assumption that usability of Entrust IdentityGuard cards for remote access would be similar. The same Entrust IdentityGuard grid options that were used for the consumer testing were used for the enterprise testing. Key details of the testing include: 17 people from a medium sized enterprise were tested in a focus group environment. The test also included the use of an Entrust IdentityGuard temporary PIN as an alternative to Entrust IdentityGuard challenge in order to assess usability in situations where a user has lost or forgotten their Entrust IdentityGuard card. Usability test results The results of the independent testing for Entrust IdentityGuard grid authentication were extremely positive, both for consumer usage as well as for the enterprise. Key findings of the enterprise study include: 1 Usability of Entrust IdentityGuard grid authentication was excellent and a very high accuracy rate of grid number lookup was achieved. Across the 4 different card designs and layouts (See Figure 34 on page 148), no statistical difference was found. This shows that organizations have the flexibility to deploy the grid size and layout that is best for them within the bounds of the recommendations found here (see Recommendations on page 149 section). 2 The task and procedure required to successfully complete the Entrust IdentityGuard challenge is inherently simple and has high user acceptance. Card usability study 147

148 Figure 34: Successful login attempts 2nd try 29% 1st try 71% Figure 3: Enterprise initial authentication attempts 100% achieved unaided successful login in two attempts; 71% of users on the first attempt and the other 29% on the second attempt. 93% of participants were somewhat or very willing to use it once per day. 3 The PIN login (for forgotten/lost cards) procedure was straightforward and well understood by users. 100% achieved un-aided successful login in two attempts. 148 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

149 Recommendations Based on the results of the study, the following recommendations should be considered when deploying Entrust IdentityGuard grid authentication to ensure a high degree of usability. Topics in this section: General guidelines on page 149 Card design and layout on page 149 General guidelines You can increase probability of initial successful grid challenge response if you: provide first time users with written instructions that graphically depict how to use the card and login procedure provide access (using a corporate Intranet or training center) to instruction materials (such as a multimedia demonstration of how to use the grid for that particular application) on how to use an Entrust IdentityGuard card Card design and layout Consider the following recommendations for card design and layout. Fonts Given that the different fonts used in the test did not affect usability, it is recommended that you choose the font within the following guidelines to ensure a high level of usability: Use fonts that people are generally familiar with (Arial, Verdana, Helvetica, and Times lend themselves to better readability) At small sizes, Verdana offers bigger looking characters at the same point size of other fonts. Ensure a sufficient character point size to ensure readability; minimum 11 point is recommended. Use of color Given that the different fonts used in the test did not affect usability, it is recommended that customers choose the font within the following guidelines to ensure a high level of usability: Ensure a sufficient contrast ratio between the font color and the background color and avoid color combinations that create a tendency to vibrate Card usability study 149

150 To assist users that may have some form of color blindness: Do not rely on color alone to convey information Avoid using only red and green in the grid design Maintain a high contrast between text and background Design of the grid Given that grid sizes tested here did not affect usability, it is recommended that you choose the grid size that is best suited to your security requirements (noting that increased grid size can deliver increased security) according to the following guidelines: Do not use more than seven rows or columns in the grid - adding more rows or columns compromises size of text and readability. Do not use multiple characters within an individual grid cell as this tends to compromise the size of text and readability. Use table row and column highlighting. Although it was not a factor in this study, tables with both row and column grid lines typically enable users to process data faster than tables with only row or only column highlighting. Format column and row titles with emphasis (bold or a background color) to assist in the immediate understanding of the table contents. Titles should be sufficiently different than the data in the table to assist in distinguishing between the table data and the row and column titles with color or value. Eliminate the top, left empty cell to emphasize the matrix with two titles. It is essential that all contents of the grid be precisely aligned and that each column appear to the eye to be in virtual alignment with neighboring elements. 150 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

151 Grid authentication implementation This section provides more information on what the study determined about implementing grid authentication. Topics in this section Web login challenge method on page 151 Mutual authentication (through displaying a authentication secret) on page 151 Temporary PIN length on page 151 Web login challenge method Given that the type of login challenge method did not affect usability, it is recommended to: Implement the method that is best suited to organizational security requirements, noting that there are inherent security benefits to implementing a two screen authentication process A two-screen approach with Entrust IdentityGuard delivers the ability to achieve mutual authentication (as a way of addressing phishing) as well as the ability to lock a challenge for a user until successfully completed (to limit the ability to brute-force attack a web site by cycling through challenges) Mutual authentication (through displaying a authentication secret) If the Entrust IdentityGuard serial number (or another authentication secret like a graphic stored by Entrust IdentityGuard) is to be displayed on the login screen to achieve mutual authentication (for example used to help address phishing attacks), it is recommended that any documentation sent to the user reinforces the security implications of that authentication secret. For more information, see Authentication choices for deploying organizations on page 51. Temporary PIN length When using a temporary PIN (for instances where the user has forgotten or lost their grid and needs access to applications until a new grid is issued), it is recommended to use a PIN with five and nine characters, depending on the customer s security requirements: Five elements is the minimum needed to ensure security. Card usability study 151

152 Nine elements is the typical upper span limit of human memory. Going beyond this will make it very difficult for a user to remember. 152 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

153 Index - A B C D E F G H I J K L M N O P Q R S T U V W X Y Z- A activation 120 ActiveX 49 administration interface 63 administrator 63 alias 65 alias in a consumer deployment 66 anonymous grids 99 application integration 74 architecture 124 evaluation 124 high availability 125 standard 124 authentication benefits 21 definition 21 how it works 29 machine 44 methods 31 multiple factor 21 mutual 29 second factor 31 authentication API 74 authentication factor. See authentication methods authentication methods 27 comparison 30 external 56 grid 32 grid replay 51 image or message replay 52 knowledge-based 38 machine 44 out-of-band 43 passcode list 37 temporary PIN 55 token 31 authentication secret 77 automation 108 B backup and recovery 61 baseline architectures 123 browser 46 properties 46 C card cost factors 106 production 103 production models 94 security 102 See also grid See also token usability study 145 card production costs 106 Entrust IdentityGuard Card Production Service 105 in-house 103 outsourced 104 Card Production Service 105 card usability study recommendations 149 results 147 challenge grid 29, 32 least-used 93 locked 67 one-time password 37 random 92 components 23 Entrust IdentityGuard Desktop 25 first-factor authentication application 25 Radius proxy 25 Remote Access Plug-in 26 repository 24 Server 23 computer identity 44 Customer support

154 - A B C D E F G H I J K L M N O P Q R S T U V W X Y Z- D delivery 120 deployment overview 58 planning 57 desktop architecture evaluation 141 high availability 143 standard 142 Desktop for Microsoft Windows 25 disaster recovery failover scenarios 80 distribution 120 Document structure 16 E end user 22 enrollment 115 groups 69 life cycle 113 locking out 67 Microsoft Windows 22 requirements 65 RRAS 22 services 67 training 67 usage 116 VPN 22 Web 22 enrolment 115 Entrust IdentityGuard Desktop for Microsoft Windows 25 Entrust IdentityGuard Radius proxy 25 Entrust IdentityGuard Remote Access Plug-in 26 Entrust IdentityGuard Server 23 evaluation architecture 124 external authentication 56 F failover 80 file transmission 107 file-based repository 24 fingerprint 44 first-factor authentication 56 first-factor authentication application 25 G Get call 46 Getting help Technical Support 17 grid automating 108 cell entropy 88 cell format 88 challenge 29, 32 challenge algorithm 92 challenge length 91 challenge size 92 deployment risks 36 distribution 95 format 88 lifetime 36, 89 location replay 51 one-step authentication 33 replacement 89 security 102 serial number 51 size 36, 88 two-step authentication 34 grid authentication 32 deploying 87 group 69 H high availability architectures 125 failover scenarios 80 I image replay disk space 54 integrating 74 considerations 77 Microsoft Windows 75 VPN 75 Web 74 inventory 120 J Javascript Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

155 - A B C D E F G H I J K L M N O P Q R S T U V W X Y Z- K knowledge-based authentication 38 question mechanisms 42 question sources 40 questions qualities 41 selecting questions 42 L least-used challenge 93 life cycle 113 delivery and activation 120 enrollment 115 maintenance 122 overview 114 renewal 117 replacement 118 usage 116 lock out reset 116 M machine authentication 44 with questions 43 machine secret 44 maintenance 122 master user 62 master user shell 62 Microsoft 136 Microsoft Windows desktop user 22 Microsoft Windows remote architecture evaluation 136 high availability 138 standard 137 migrating 85 model card production 94 produce-and-assign 95 multilayer authentication 21 mutual authentication 29 grid replay 51 image or message replay 52 O operations 60 organization authentication 29 out-of-band authentication 43 P passcode list deployment risks 38 length 38 production 38 sample 38 passcode list authentication 37 people 60 Performance 79 performance testing 79 pharming 36 phishing 36 physical security 61 planning deployment 57 policies 59 preproduction model grids 99 produce-and-assign model 95 producing cards 103 production file pre-production model 99 transmitting 107 Professional Services 18 Q question and answer. See knowledge-based authentication R Radius proxy 25, 76 random challenge 92 recovery 61 Remote Access Plug-in 26 renewal 117 replacement 118 replay grid values 51 image 52 message 52 serial number 51 repository 24 failover 24 Index 155

156 - A B C D E F G H I J K L M N O P Q R S T U V W X Y Z- file-based 24 synchronization 122 RRAS user 22 S sample Web application 29 scratch cards 38 search bases 24, 71 shared secrets 78 single-factor authentication 21 standard architectures 124 strong authentication 20 Structure of guide 16 study summary 146 T TANs. See passcode list Technical Support 17 technology 58 temporary PIN 55 length 151 testing performance 79 toke deployment 111 token assigning 111 lifetime and replacement 110 PINs 110 security 112 self-registration 111 token authentication 31 deploying 109 tokens response-only mode 31 troubleshooting 61 typographic conventions 14 V VPN architecture evaluation 131 high availability 133 standard 132 VPN user 22 W Web architecture evaluation 126 high availability 128 standard 127 Web user 22 U usability study 145 summary 146 usage 116 user authentication 28 user ID 65, 66 user. See end user 156 Entrust IdentityGuard 8.1 Deployment Guide Document issue: 2.0

157

158