IG 90 Deployment Guide-Iss20

Entrust
IdentityGuard 9.0
Deployment Guide
Document issue: 2.0
Date of Issue: November 2007
2
IdentityGuard 9.0 Deployment Guide
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.
Table of contents
About this guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 3
Documentation conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Note and Attention text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Related documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Obtaining documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Documentation feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Obtaining technical assistance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Technical support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Telephone numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Email address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Professional Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
CHAPTER 1
About Entrust IdentityGua rd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1
Why use Entrust IdentityGuard? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Challenges of first-factor authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Benefits of multifactor authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Identities become difficult to steal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Stolen identities become difficult to reuse . . . . . . . . . . . . . . . . . . . . . . . . 23
Authentication choices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
First-factor authentication choices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Second-factor authentication choices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Mutual authentication choices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Machine authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Risk-based authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Entrust IdentityGuard components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Entrust IdentityGuard Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Entrust IdentityGuard Authentication service . . . . . . . . . . . . . . . . . . . . . 28
Entrust IdentityGuard Administration service. . . . . . . . . . . . . . . . . . . . . . 29
Administration interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4
IdentityGuard 9.0 Deployment Guide Document issue: 1.0
Properties editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Master user shell. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
First-factor authentication application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Entrust IdentityGuard Radius proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Entrust IdentityGuard Desktop for Microsoft Windows . . . . . . . . . . . . . . . . . . 31
Entrust IdentityGuard Remote Access Plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Entrust IdentityGuard ISAPI filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Client applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Entrust IdentityGuard users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Microsoft Windows desktop users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Routing and Remote Access Service (RRAS) users. . . . . . . . . . . . . . . . . . 34
VPN users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Web users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
CHAPTER 2
Authentica tion methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 5
Overview of available authentication methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
First-factor authentication methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Password authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Radius server authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
External authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Second-factor authentication methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Token authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Grid authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Determining the grid challenge size . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Passcode lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Knowledge-based authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
One-time password authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
One-time password delivery systems . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Mutual authentication methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Grid serial number or grid location replay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Image and message replay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Machine authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Sources of application data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5
Risk-based authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Setting risk policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Setting authentication policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
IP geographic locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Blacklists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Temporary PIN authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Using personal verification numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
CHAPTER 3
Pla nning your deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3
Planning: initial considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Entrust IdentityGuard policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
People . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Backup and recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Other precautions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Planning administrative tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Assigning master users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Assigning administrators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Planning user requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Alias and user ID requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Aliases in a consumer deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Training users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Providing services to users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Locking out users based on authentication method . . . . . . . . . . . . . . . . . . . . . 72
Suspending users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Group requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Groups in a consumer deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Groups in an enterprise deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Analyzing your companys group needs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Group implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6
CHAPTER 4
Deployment considera tions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7
Application integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Web integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Microsoft Windows integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
VPN remote access integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Wireless Access Portal integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Application considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Integrating with existing user management systems . . . . . . . . . . . . . . . . . . . . . 81
Using shared secrets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Selecting a repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Directory repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Database repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Performance and maintainability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Performance testing strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Backing up, restoring and migrating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
High availability and disaster recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Entrust IdentityGuard Server failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Directory failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Local directory failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Geographically dispersed directory failover . . . . . . . . . . . . . . . . . . . . . . . 89
Database failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Radius server failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Switching over to Entrust IdentityGuard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
CHAPTER 5
Deploying grid a uthentica tion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5
Grid requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Grid size and format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Grid size impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Grid format impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Grid lifetime and replacement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Challenge requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Challenge size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
7
Varying the grid challenge size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Challenge algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Grid production models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Produce-and-assign model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Produce-and-assign grids for existing users . . . . . . . . . . . . . . . . . . . . . 102
Produce-and-assign grids for new users . . . . . . . . . . . . . . . . . . . . . . . . 104
Preproduction model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Forcing card activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Physical card security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Physical card production options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
In-house card production . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Typical characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Outsourced card production . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Typical Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Entrust IdentityGuard card production . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Typical characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Card production cost factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Secure file transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Secure Sockets Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Secure email . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Secure FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
End-to-end encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Automating processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
CHAPTER 6
Deploying token a uthentica tion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1 7
Using tokens for authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Token lifetime and replacement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Entering token values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
8
Token deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Assigning tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Token self-activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Forcing token activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Physical token security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
CHAPTER 7
Deploying know ledge-ba sed a uthentica tion . . . . . . . . . . . . . . . . . . . . . . . . 1 2 1
Question requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Sources of questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Creating good questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Sample questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Selecting a set of questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Challenge requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Challenge size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Challenge accuracy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Setting how many correct answers are required . . . . . . . . . . . . . . . . . . 126
Setting the accuracy of answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Security considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
APPENDIX A
User life cycle ma na gement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2 9
Life cycle management overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Enrollment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Renewal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Replacement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Delivery and activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
9
Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Remove cancelled cards and tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Remove inactive cards and tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Remove unassigned cards and tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Synchronize with the repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Update images used for mutual authentication . . . . . . . . . . . . . . . . . . . . . . . 140
Update personal verification numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Update IP geographical data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
APPENDIX B
Entrust IdentityGua rd ba seline a rchitectures. . . . . . . . . . . . . . . . . . . . . . . . 1 4 1
Architecture overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
High availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Web access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Web access - evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Web access - standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Web access - high availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
VPN remote access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
VPN remote access - evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
VPN remote access - standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
VPN remote access - high availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Wireless access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Wireless access - evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Wireless access - standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Wireless access - high availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
10
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Microsoft Windows remote access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Microsoft Windows remote access - evaluation . . . . . . . . . . . . . . . . . . . . . . . 156
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Microsoft Windows remote access - standard . . . . . . . . . . . . . . . . . . . . . . . . 157
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Microsoft Windows remote access - high availability . . . . . . . . . . . . . . . . . . . 158
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Generic remote access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Generic remote access - evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Generic remote access - standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Generic remote access - high availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Microsoft Windows desktop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Microsoft Windows desktop - evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Microsoft Windows desktop - standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Microsoft Windows desktop - high availability . . . . . . . . . . . . . . . . . . . . . . . . 165
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
APPENDIX C
Ca rd usa bility study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 6 7
Entrust IdentityGuard card usability study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Usability test summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Usability test results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
General guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Card design and layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Fonts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Use of color . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
11
Design of the grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Grid authentication implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Web login challenge method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Mutual authentication (through displaying a authentication secret) . . . . . . . . 173
Temporary PIN length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 7 5
12
13
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.
This chapter contains the following topics:
Documentation conventions on page 15
Related documentation on page 16
Obtaining documentation on page 17
Obtaining technical assistance on page 18
This guide contains the following sections:
About Entrust IdentityGuard on page 21 describes Entrust IdentityGuard
and what it does.
Authentication methods on page 35 describes and compares the
authentication methods and how to deploy them.
Planning your deployment on page 63 describes Entrust IdentityGuard
deployment planning considerations.
Deployment considerations on page 77 describes how to integrate Entrust
IdentityGuard into your existing applications.
Deploying grid authentication on page 95 describes, in detail, how to
deploy grid authentication.
Deploying token authentication on page 117 describes, in detail, how to
deploy token authentication.
Deploying knowledge-based authentication on page 121 describes, in
detail, how to deploy knowledge-based authentication.
User life cycle management on page 129 describes the life cycle for an
Entrust IdentityGuard user.
14
Feedback on guide
Entrust IdentityGuard baseline architectures on page 141 describes
various architectures for deploying Entrust IdentityGuard.
Card usability study on page 167 describes a study completed to examine
card usability aspects.
15
About this guide
Feedback on guide
Documentation conventions
Table 1 contains the typographic conventions that appear in this guide:
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.
Table 1: Typographic conventions
Convention Purpose Example
Bold text
(other than
headings)
Indicates graphical user
interface elements and
wizards
Click Next.
Italicized text Used for book or
document titles
Entrust TruePass 7.0 Deployment Guide
Blue text Used for hyperlinks to
other sections in the
document
Entrust TruePass supports the use of many types
of digital ID.
Underlined blue
text
Used for Web links For more information, visit our Web site at
www.entrust.com.
Courier type Indicates installation
paths, file names,
Windows registry keys,
commands, and text you
must enter
Use the entrust-configuration.xml file
to change certain options for Verification Server.
Angle brackets
< >
Indicates variables (text
you must replace with
your organizations
correct values)
By default, the entrust.ini file is located in
<install_path>/conf/security/entrust.
ini.
Square brackets
[courier type]
Indicates optional
parameters
dsa passwd [-ldap]
16
Feedback on guide
Related documentation
Entrust IdentityGuard is supported by a complete documentation suite:
For instructions about installing and configuring the Entrust IdentityGuard
Server, see the Entrust IdentityGuard Installation Guide.
For instructions about administering Entrust IdentityGuard users and groups,
see the Entrust IdentityGuard Administration Guide.
For information about deploying Entrust IdentityGuard, see the Entrust
IdentityGuard Deployment Guide.
For information about configuring Entrust IdentityGuard to work with a
supported LDAP repositoryMicrosoft Active Directory, Microsoft Active
Directory Application Mode, Critical Path InJoin Directory, IBM Tivoli
Directory, Novell eDirectory, Oracle Directory, or Sun ONE Directorysee
the Entrust IdentityGuard Directory Configuration Guide.
For information about configuring Entrust IdentityGuard to work with a
supported JDBC databaseIBM DB2 Universal Database, Microsoft SQL
Server, MySQL, PostgreSQL, or Oracle Databasesee the Entrust
IdentityGuard Database Configuration Guide.
For information about Entrust IdentityGuard error messages, see the Entrust
IdentityGuard Error Messages.
For information about new features, limitations and known issues in the
latest release, see the Entrust IdentityGuard Release Notes.
For information about 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 .NET).
For Entrust IdentityGuard product information and a data sheet, go to
http://www.entrust.com/strong-authentication/identityguard/index.htm
For information on identity theft protection seminars, go to
http://www.entrust.com/events/identityguard.htm
17
About this guide
Feedback on guide
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:
https://www.entrust.com/trustedcare
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 Feedback on guide link located in the footer of Entrusts PDF
documents (see bottom of this page).
following this link: http://www.entrust.com/products/feedback/index.cfm
Feedback concerning documentation can also be directed to the Customer Support
email address.
support@entrust.com
18
Feedback on guide
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:
http://www.entrust.com/
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:
https://www.entrust.com/trustedcare
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:
1-877-754-7878 in North America
1-613-270-3700 outside North America
Email address
The email address for Customer Support is:
support@entrust.com
19
About this guide
Feedback on guide
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:
http://www.entrust.com
20
Feedback on guide
21
Chapter 1
About Entrust IdentityGuard
Entrust IdentityGuard is a multifactor authentication product that enhances security
and verifiability by providing multifactor authentication methods. It allows 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 contains the following sections:
Why use Entrust IdentityGuard? on page 22
Authentication choices on page 24
Entrust IdentityGuard components on page 27
22
Feedback on guide
Why use Entrust IdentityGuard?
As online fraud and compliance regulations become more prevalent, standard user
name and password authentication no longer offers sufficient security for your
organizations sensitive resources.
Strong authentication is a tool that your organization likely uses in some form today.
Whether it is for VPN remote access, MicrosoftWindowssecurity, 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 use (with or without other 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 Figure 1 demonstrates, a company could apply Entrust IdentityGuard
grid authentication when a remote employee logs in using a VPN connection. The
system could include an existing user name and password authentication resource or
could use Entrust IdentityGuard to handle this first-factor authentication duty.
Figure 1: Multifactor authentication with Entrust IdentityGuard
This section contains the following topics:
Challenges of first-factor authentication on page 23
Benefits of multifactor authentication on page 23
Employee repository
Entrust IdentityGuard
Server
User name and password
authentication resource
Company VPN
device
Company
firewall
User that requires
multifactor
authentication
23
Feedback on guide
Challenges of first-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 first-factor authentication .
However, the widespread incidents of online identity theft shows that user names and
passwords alonewhich are easy to steal and easy to reuseare not much defense
against the ever-increasing sophistication of identity attacks. You need one or more
second-factor authentication methods to be safe.
Benefits of multifactor authentication
Multifactor authentication is a solution that adds as many authentication methods
as required based on the security context. For example, after employees log in using
a user name and password, you can require that they answer a grid challenge, while
at the same time, have the authentication application check the computers they use
to ensure they are registered.
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 methods in ways that make
the theft of a single factor useless to the attacker. Without the additional
authentication methods, the attacker has either no access to a users confidential
information or can only view trivial information. Also, authentication can be
performed at the transaction level using different authentication methods, depending
on the risk associated with the transaction.
24
Feedback on guide
Authentication choices
Entrust IdentityGuard offers several ways to set up first-factor authentication. Once
the user has logged in, you can apply one or more second-factor authentication
methods, and apply additional authentication steps for higher-risk transactions.
First-factor authentication choices
You can set up Entrust IdentityGuard to do first-factor authentication, or you can
integrate Entrust IdentityGuard with an existing authentication resource. Entrust
IdentityGuard supports the following types of first-factor authentication:
password authentication based on a user name and password stored by
Entrust IdentityGuard in the user entry of your repository
external authentication based on domain or directory credentials that a user
already has
In addition, Entrust IdentityGuard can integrate with other first-factor authentication
methods provided by Web, desktop, or VPN authentication applications. For
example, you can integrate Entrust IdentityGuard with Web authentication products
such as:
Entrust GetAccess
Entrust TruePass
IIS Web server and Internet Security and Acceleration (ISA) Server
You can also integrate Entrust IdentityGuard with Virtual Private Network (VPN)
authentication products such as:
Cisco ASA 5500 Series appliances
Nortel VPN Routers
Optionally, you can choose to skip first-factor authentication altogether. If you do so,
ensure that you have carefully examined the risks and benefits.
The first-factor authentication methods are described in more detail in First-factor
authentication methods on page 41.
Second-factor authentication choices
Entrust IdentityGuard provides several second-factor authentication methods,
including:
card (grid and passcode list) authentication
token authentication
one-time password authentication (typically delivered by an out-of-band
mechanism, such as voice message delivery)
25
Feedback on guide
knowledge-based (question and answer) authentication
temporary PIN authentication
The second-factor authentication methods are described in detail in Second-factor
authentication methods on page 43. For cards, tokens and one-time-passwords,
you can include the use of a personal verification number (PVN). See Using personal
verification numbers on page 64 for more information.
Mutual authentication choices
Mutual authentication (also called organization authentication) is a way to verify your
organization to users as legitimate. Entrust Identity Guard provides two methods of
verifying your organization to users:
grid serial number or grid location replay
image and message replay
The mutual authentication methods are described in detail in Mutual authentication
methods on page 54.
Machine authentication
Entrust IdentityGuard allows you to verify a user by comparing current properties of
the users machine against a previously-stored copy of those same properties.
Machine authentication is also a feature of risk-based authentication.
See Machine authentication on page 57 for a detailed description of machine
authentication.
Risk-based authentication
Entrust IdentityGuard allows you to determine situations where second-factor
authentication is applied, based on a users location or machine information. For
example, second-factor authentication may not be required when users log in from
the desktop computer they use all the time. However, if users log in from remote
locations or are using computers they have never used before, you may want Entrust
IdentityGuard to send them a second-factor challenge. Using risk-based
authentication allows you to choose when second-factor authentication is applied
based on risks relevant to your company.
There are two authentication features associated with risk-based authentication:
machine authentication
The risk is assessed based on the attributes associated with a particular
computer.
IP geolocation authentication
26
Feedback on guide
The risk is assessed based on the geographical location (derived from the IP
address) of the user.
See Risk-based authentication on page 60 for a detailed description of risk-based
authentication.
27
Feedback on guide
Entrust IdentityGuard components
The following diagrams show how Entrust IdentityGuard can fit into your existing
authentication system or become your sole authentication system.
Figure 2: Entrust IdentityGuard with an existing authentication system
Figure 3: Entrust IdentityGuard as the sole authentication system
Entrust IdentityGuard Server on page 28
Repository on page 30
First-factor authentication application on page 31
Entrust IdentityGuard Radius proxy on page 31
Server
Repository
User
First-factor
authentication
application
Server
Repository User
28
Feedback on guide
Entrust IdentityGuard Desktop for Microsoft Windows on page 32
Entrust IdentityGuard Remote Access Plug-in on page 33
Client applications on page 34
Entrust IdentityGuard users on page 35
Entrust IdentityGuard Server
The Entrust IdentityGuard Server is the main component of the Entrust IdentityGuard
system. It includes the following applications and interfaces:
authentication and administration Web services with Java Platform and C#
APIs
administration interface, properties editor, and master user shell
a sample Web application that demonstrates Entrust IdentityGuards
capabilities
These applications and interfaces are required to authenticate and manage users and
their authentication data.
Figure 4 illustrates the higher level Entrust IdentityGuard components and shows how
they integrate with your existing authentication application.
29
Feedback on guide
Figure 4: Entrust IdentityGuard components
Entrust IdentityGuard Authentication service
The Entrust IdentityGuard Authentication service (also referred to as the
Authentication API), is a set of Web services used for retrieving challenge requests
and authenticating user responses. It is designed to easily integrate with your existing
authentication applications to provide multifactor authentication.
You can create an application that calls the Authentication API using its Web service,
Java Platform or .NET interfaces to authenticate users. For more information, see the
Entrust IdentityGuard Programming Guide that applies to your programming
language (Java Platform or .NET).
Optionally, you can use the Secure Sockets Layer (SSL) protocol to secure user
responses between any Entrust IdentityGuard authentication client and the Entrust
IdentityGuard Authentication service.
Client
authentication
application
Client
administration
application
SOAP
(SSL is optional)
SOAP
(with SSL)
Desktop for Microsoft
Windows
SOAP
(SSL is optional)
Administration service
Master user shell
Authentication service
Radius proxy
SOAP
(SSL is optional)
Entrust
IdentityGuard
Administration
interface and
Properties
editor
HTML/
HTTPS
Web administration
application
Application server
Repository
Directory
Database
30
Feedback on guide
Entrust IdentityGuard Administration service
The Entrust IdentityGuard Administration service (also referred to as the
Administration API), is a servlet running on the Entrust IdentityGuard Server that
manages groups, policies, administrators, users, cards, tokens, PINs and other
authentication data.
You can create an application that calls the Administration API using its Web service,
Java Platform or .NET interfaces to automate Entrust IdentityGuard user
administration tasks. For more information, see the Entrust IdentityGuard
Programming Guide that applies to your programming language (Java Platform or
.NET).
Administration interface
Administrators use the Web-based Administration interface to perform system and
user administration operations that define how Entrust IdentityGuard will work in
your organization.
Properties editor
Administrators use the Properties editor to set or review the properties that govern
the behavior of Entrust IdentityGuard and its components.
Master user shell
The master user shell is a command line installed on the Entrust IdentityGuard Server.
Master users use the master user shell to perform many of the same tasks that the
Administration interface offers. A small number of tasks are available only through
the master user shell.
Repository
Entrust IdentityGuard uses your existing repository to store user data in an existing
LDAP-compliant directory, a JDBC-compliant database or both. When a grid or other
authentication data is generated for a user, sensitive data is written in encrypted form
to the repository. During second-factor authentication, data is retrieved from the
repository.
Users reside in groups. You can assign groups to one or more repositories, and those
repositories can be in databases, in directories, or both.
Each directory search base is treated as a separate repository, and has the capability
of using a different directory server and different directory user credentials. The
default configuration uses a single search base.
For grid or token authentication, unassigned token information and preproduced
grids are stored in the Entrust IdentityGuard repository. You can store this information
31
Feedback on guide
as a as a flat file on the Entrust IdentityGuard Server (default) or in a separate
database (if storing over 100,000 cards or tokens). For more information on the
file-based repository options, see the Entrust IdentityGuard Installation Guide. When
the grid or token is assigned to a user, the information is then copied into the user's
repository entry.
For more information on repositories, see Selecting a repository on page 83.
You can also set up all key connections in a failover scenario. For a database or
directory, you can use the Properties Editor to add multiple URLs to the Entrust
IdentityGuard properties file. Entrust IdentityGuard will attempt to connect to the
repositories in the order they are listed. In the same way, you can list multiple URLs
for Radius proxy connections and external authentication connections.
For more information on failover, see High availability and disaster recovery on
page 88.
First-factor authentication application
You have three choices for first-factor (user login) authentication:
You can integrate Entrust IdentityGuard with your existing authentication
application. This authentication application can be a Remote Authentication
Dial In User Service (Radius) server, a domain controller, a Web-based access
control product, the Microsoft Windows Login feature, an LDAP-compliant
directory, and so on. Depending on the type of application, you may need to
customize it. For more information, see Deployment considerations on
page 77.
You can configure Entrust IdentityGuard to manage user logins through the
password feature. In this case, the repository stores password credentials.
Administrators can manage the passwords through the Administration
interface.
You can configure Entrust IdentityGuard (when using the Radius proxy) to
skip first-factor authentication and move directly to second-factor
authentication.
Entrust IdentityGuard Radius proxy
The Entrust IdentityGuard Radius proxy component installs with the Entrust
IdentityGuard Server to enable multifactor authentication for Virtual Private Network
(VPN) users and users on Wireless Access Points (WAP).
The Radius proxy intercepts messages between the VPN server and the first-factor
authentication resource. That resource may be a Radius server, a Windows domain
controller, an LDAP-compliant directory, or Entrust IdentityGuard itself (using
password authentication). If the resource is a domain controller or directory, you must
32
Feedback on guide
use external authentication (see External authentication on page 42). For more
information, see the Entrust IdentityGuard Administration Guide.
In the case of the Radius proxy being used with a wireless access point, all you need
is Entrust IdentityGuardno Radius server or Windows domain controller is required.
The Radius proxy supports second-factor authentication using a grid, a token,
questions and answers (knowledge-based), and a one-time password (OTP). All of
these authentication methods, except knowledge-based authentication, can also
include a personal verification number (PVN). A PVN is similar to a PIN, except it is
not tied to one authentication method.
Entrust IdentityGuard Desktop for Microsoft
Windows
Entrust IdentityGuard Desktop for Microsoft Windows is a small-footprint client that
communicates with the Entrust IdentityGuard Server. Table 2 describes the features
of Entrust IdentityGuard Desktop for Windows.
Table 2: Features of Entrust IdentityGuard for Microsoft Windows
Feature Feature environment Feature description
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 grid
authentication when they log in to their
Microsoft Windows desktop computer.
Note: You can use only grid authentication
with the Windows Login feature.
Remote Access Network access through
dial-up, wireless, or VPN
remote access
The Microsoft Routing and Remote Access
Service (RRAS) feature of the Entrust
IdentityGuard Desktop for Microsoft
Windows 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.
Note: You can use only grid or token
authentication with the Remote Access
Plug-in for Microsoft Windows Server.
33
Feedback on guide
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 organizations policies and practices.
In this scenario, each user in your company has a card and may have a temporary PIN.
When the computer boots up, Microsoft Windows challenges each user for a
Windows user name and password. After the user responds correctly, Entrust
IdentityGuard Desktop for Windows pops up a challenge box.
If the user enters the correct response, the users is granted access to the
computer.
If the user enters several incorrect responses and exceeds the lockout limit,
the user is locked out of the computer.
If the user does not have a card (for example, the user lost the card), the user
can enter a temporary PIN, which Entrust IdentityGuard Desktop will
validate.
If the user is offline, the user can enter an offline temporary PIN, which
Entrust IdentityGuard Desktop will validate against the shared secret stored
(in encrypted format) in its repository.
For more information, see the Entrust IdentityGuard Desktop for Microsoft Windows
Administration Guide.
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 that 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 second-factor
authentication.
See the Entrust IdentityGuard Desktop for Microsoft Windows Administration Guide
for more information.
34
Feedback on guide
Entrust IdentityGuard ISAPI filter
Entrust IdentityGuard can also protect Web applications (such as Microsoft Outlook
Web Access) with the Entrust IdentityGuard ISAPI filter. You can install the ISAPI
(Internet Server Application Programming Interface) filter on an ISA server or an IIS
server.
The Entrust IdentityGuard ISAPI filter, combined with any Entrust IdentityGuard
authentication method, ensures that only valid users have access to the Web
application.
Client applications
Client applications use the Authentication API and the Administration API to access
Entrust IdentityGuards multifactor authentication abilities on behalf of your users. To
access these APIs, the client applications require appropriate administrative privileges.
Table 3 provides some examples of what client applications can do.
Table 3: Sample activities of client applications
Client applications can By
Register new users
(Administration API)
Obtaining user information (user ID, email address, image replay
information, and so on) from a user through a user registration
page
Setting other required attributes, such as group affiliation and
authentication method
Passing this information to Entrust IdentityGuard, which then
creates a user entry in the repository
Authenticate users
(Authentication API)
Presenting them with an initial authentication page (user name
and password) when they attempt to access your site
Challenging them with a second-factor authentication page,
using challenges created by Entrust IdentityGuard
Note: The client application is responsible for enforcing the limits for
a challenge response. This is especially important when using grid
authentication. Limits are set by Entrust IdentityGuard policies.
Providing the challenge response to Entrust IdentityGuard for
validation
Returning Entrust IdentityGuards response to the user
35
Feedback on guide
To create your own client applications, see the Entrust IdentityGuard Programming
Guide that applies to your programming language (Java Platform or .NET).
The Entrust IdentityGuard Administration interface, Entrust IdentityGuard Desktop
for Microsoft Windows, and the sample Web application included in the installation
package are all examples of client applications.
Entrust IdentityGuard users
Entrust IdentityGuard users are divided into different categories, based on how they
access your organizations resources. See Entrust IdentityGuard baseline
architectures on page 141 for diagrams showing how Entrust IdentityGuard
interacts with these users.
Microsoft Windows desktop users
Microsoft Windows desktop users are internal users who, after logging in to your
domain using their Windows user name and password, are then presented with a
second-factor authentication challenge (such as a grid challenge). For more
information about these users, see the Entrust IdentityGuard Desktop Client for
Microsoft Windows Administration Guide.
Routing and Remote Access Service (RRAS) users
RRAS users 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 presented with a second-factor authentication challenge (such as a grid
challenge). For more information about these users, see the Entrust IdentityGuard
Desktop Client for Microsoft Windows Administration Guide.
Allow self-administration
of users
Presenting a page that allows them to change user information
(for example, to change their email address or phone number)
Presenting a page that allows them to alter their questions and
answers, or image and text replay options
Passing the responses to Entrust IdentityGuard so that it can
update the user entry for the next time the user logs in
Table 3: Sample activities of client applications (continued)
Client applications can By
36
Feedback on guide
VPN users
VPN users are internal and external users who log into your domain using a VPN
connection. First-factor authentication (user name and password) can be provided
by:
an existing Radius server
an existing LDAP directory
an existing Windows domain controller
Entrust IdentityGuard password authentication
Entrust IdentityGuard then challenges these users for a second factor of
authentication. For more information, see VPN remote access integration on
page 79.
Web users
Web users are internal or external users to your organization who access your intranet
or Internet site by logging in through a Web browser. First-factor authentication (user
name and password) is completed by a Web access product or Entrust IdentityGuard
using password authentication. Entrust IdentityGuard can then provide additional
authentication methods as required by the sensitivity of the operation. For more
information, see Web integration on page 78.
35
Chapter 2
Authentication methods
Entrust IdentityGuard provides authentication methods for authenticating users,
performing mutual and risk-based authentication, and registering computers.
This chapter describes the implementation considerations for each method.
Note: While reading this chapter, consider the frequency of the authentication
events to which you want to add multifactor authentication. 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.
Overview of available authentication methods on page 36
First-factor authentication methods on page 41
Second-factor authentication methods on page 43
Mutual authentication methods on page 54
Machine authentication on page 57
Risk-based authentication on page 60
Temporary PIN authentication on page 63
Using personal verification numbers on page 64
36
Feedback on guide
Overview of available authentication
methods
This section describes and compares the authentication methods available through
Entrust IdentityGuard.
Entrust IdentityGuard divides the authentication methods into the following
categories:
first-factor authentication
In first-factor authentication, users must identify themselves, typically by
supplying a user name and password. You can rely on a separate application
to do this, such as a Remote Authentication Dial In User Service (Radius)
server, a domain controller, a Web-based access control product, or the
Microsoft Windows Login feature. Alternatively, you can use Entrust
IdentityGuards password feature.
Figure 5: First-factor authentication
second-factor authentication
In second-factor authentication, users verify their authenticity to your
organization, using one of the following methods:
grid authentication
passcode list authentication
knowledge-based authentication
one-time password authentication delivered through an out-of-band
mechanism
37
Feedback on guide
Figure 6: Second-factor authentication methods
For added security, a personal verification number can be used with cards
(grids and passcode lists), tokens, and one-time-passwords. For more
information, see Using personal verification numbers on page 64.
mutual authentication (organization authentication)
In mutual authentication, your organization proves itself as authentic.
Mutual authentication can involve different types of replay authentication.
Grid authentication
(grid location challenge
and response )
Out -of -band authentication
(one-time password by SMS
mail , email , or voice mail)
Knowledge-based
authentication
(questions and answers )
Token authentication
(dynamic password)
Passcode list
authentication
(often scratchpad)
38
Feedback on guide
Figure 7: Mutual authentication methods
machine authentication
In machine authentication, the users identity is verified based on various
properties of the users computer.
risk-based authentication
In risk-based authentication, the authentication method presented depends
on the risk. Risk varies based on user qualities, such as
the machine used
the users geographic location
Risk can be based on the nature of the transaction. Some examples which
might qualify as high-risk transactions include:
large money transfers
new account creation
large purchases
temporary PIN authentication
In temporary PIN authentication, the user enters a temporary PIN in place of
a temporarily unavailable card (grid or passcode list) or token.
Serial replay authentication
(grid card serial number )
Message replay
authentication
(user entered
message)
Grid location replay authentication
(grid locations shown specific to
user)
Image replay
authentication
(user selected image)
39
Feedback on guide
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
Entrust IdentityGuard Installation Guide includes a tutorial that describes the Web
application.
To deploy the authentication methods, Entrust IdentityGuard includes policies that
allow you to determine the characteristics of the authentication methods for groups
of users. For more information, see Entrust IdentityGuard policies on page 65 and
the Entrust IdentityGuard Administration Guide.
Table 4 provides a brief comparison of the Entrust IdentityGuard authentication
methods.
Table 4: Comparison of available authentication methods
Authentication
method
Physical
requirements for
users
Renewal options
1
Sample use
Token Token hardware When device is lost or
battery dies (6 years or
more)
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 Grid, passcode list, or
token is temporarily
unavailable
Knowledge-based None N/A Registering users and/or
machines
One-time password
delivered by an
out-of-band
mechanism
None
2
One-time use only One-time, highly sensitive
operation
Machine (can be part
of risk-based
authentication)
N/A Based on each login,
length of time, or when
users change computers
Users access site from
personally-owned
computers
IP geolocation
(risk-based)
N/A N/A Users access site from a
variety of locations
40
Feedback on guide
Replay (organization) Card, if using grid
location or serial
number replay
N/A Verification of
organization
1. An administrator or application can force a renewal at any time.
2. Users need a telephone number, SMS information, or email account in order to receive the one-time password.
Table 4: Comparison of available authentication methods (continued)
Authentication
method
Physical
requirements for
users
Renewal options
1
Sample use
41
Feedback on guide
First-factor authentication methods
You can use Entrust IdentityGuard to directly manage first-factor authentication; that
is, to check if a users first-factor credentials (user name and password) is valid.
Alternatively, you can configure Entrust IdentityGuard to use an external
authentication mechanism, such as a Windows domain controller. You can always
integrate Entrust IdentityGuard with your existing authentication application using
the Entrust IdentityGuard authentication and administration Web services.
Password authentication
Entrust IdentityGuard administrators with the applicable role permissions can set and
manage the passwords of Entrust IdentityGuard users through the Administration
interface. For new passwords, administrators can enter passwords of their choosing
or auto-generate random passwords. Administrators can also manage policy settings
related to passwords, such as the length, composition (letters, numbers, case, and
special characters), expiry date, and reuse history. The policy settings ensure that user
passwords conform to your organizations password requirements.
Radius server authentication
For first-factor authentication of your VPN users, Entrust IdentityGuard provides the
ability to use the Radius authentication protocol with a VPN server and optionally, a
Radius server.
When you integrate Entrust IdentityGuard with your VPN server, the Entrust
IdentityGuard Radius proxy intercepts messages between the VPN server and the
first-factor authentication resource.
Entrust IdentityGuard supports these first-factor authentication methods for VPN
users:
Entrust IdentityGuard forwards a request to a Radius server which completes
the first-factor authentication.
Entrust IdentityGuard forwards a first-factor authentication request to either
an LDAP-compliant directory or Windows domain controller. This is referred
to as external authentication. For more information on external
authentication, see External authentication on page 42.
Entrust IdentityGuard itself completes the password authentication.
Regardless of the method, the VPN server still believes it is communicating with a
Radius server. It is actually communicating with the Entrust IdentityGuard Radius
proxy.
You can configure your VPN servers to use different first-factor authentication
resources for first-factor authentication. For example, one VPN server can use a
Radius server, and another VPN server can use an LDAP-compliant directory.
42
Feedback on guide
Note: You can also configure the Radius proxy to skip first-factor authentication
entirely and present users with a second-factor authentication challenge
immediately.
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 through an LDAP
directory or Windows domain controller through Kerberos, without having to deploy
a Radius server.
Use external authentication when your users and their password information are
stored in an external resource (such as Active Directory or an LDAP-compliant
directory).
Also, in an environment where user password information is stored in an external
resource (for example, Active Directory) and Entrust IdentityGuard information
(grids, tokens, policies, and so on) is stored in a database, you can have Entrust
IdentityGuard forward first-factor authentication to the external resource if the
external authentication is through Kerberos.
Note: When using external authentication, users in the first-factor resource are
not automatically synchronized with the second-factor resource (the Entrust
IdentityGuard repository). You must manually synchronize all data between the
different resources.
For a sample architecture, see Web access - evaluation on page 144. Also see the
Entrust IdentityGuard Installation Guide for more information.
43
Feedback on guide
Second-factor authentication methods
Your organization can choose one or more second-factor authentication methods.
The choice of authentication method 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 second-factor authentication methods are available:
Token authentication on page 43
Grid authentication on page 44
Passcode lists on page 47
Knowledge-based authentication on page 49
One-time password authentication on page 51
Token authentication
Using tokens, your users can authenticate themselves using a dynamic password after
completing first-factor authentication.
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). Entrust IdentityGuard also supports tokens from other
vendors.
In addition, you can configure the Entrust IdentityGuard APIs to use any tokens from
any token vendor. Different token types can be assigned to your users, and a user can
have two tokens from different vendors, though the tokens cannot have the same
token state. For more on token states, see the Entrust IdentityGuard Administration
Guide.
Tokens represent a strong second-factor authentication method because they
combine possession (the token) and knowledge (the dynamic password or PIN).
Because the token 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 and tokens that
use challenge/response mode.
Table 5: Token authentication advantages and considerations
Advantages It is easy to use.
It is impossible for an attacker to reuse passwords, making it a
very secure second-factor authentication method.
44
Feedback on guide
Grid authentication
With grid authentication, you provide each user with a printed Entrust IdentityGuard
card that contains rows and columns of characters. Authentication works as follows:
1 The user completes first-factor authentication (user name and password)
successfully.
2 Entrust IdentityGuard presents the user with a challenge based on the grid on
their card, as illustrated in Figure 8.
3 The user enters the values from their card corresponding to the requested cell
locations in the challenge. In Figure 8, the challenge asks the user to enter the
numbers in grid coordinates B1, E4, and G5, which are 7 8 4 .
4 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.
Considerations It is not as cost efficient to buy, maintain, and renew as other
methods (such as grids). Entrust tokens are more cost efficient
than tokens from other vendors.
You need to determine how to roll out tokens and train users.
For time-based tokens, 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
Table 5: Token authentication advantages and considerations (continued)
45
Feedback on guide
Figure 8: Entrust IdentityGuard challenge sample
You can set up grid challenges in one of the following ways:
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 users identity 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 9.
Figure 9: One-step authentication example
******
******
IGuser1
46
Feedback on guide
In two-step authentication, the user logs in as usual and is then shown a
second dialog box containing the Entrust IdentityGuard grid challenge.
Because the user has already passed first-factor authentication, the users
identity is known. This lets you add other Entrust IdentityGuard features,
such as serial number replay or grid location replay (see Mutual
authentication methods on page 54). For an example, see Figure 10.
Figure 10: Two-step authentication example
Table 6 lists the advantages and considerations of grid authentication.
Table 6: Grid authentication advantages and considerations
Advantages It is easy to use (see Entrust IdentityGuard card usability study
on page 168).
It is inexpensive to set up, maintain and renew.
47
Feedback on guide
Determining the grid challenge size
There may be cases where you want to present a different number of grid coordinates
based on the type of access or transaction the user requires. For example, access to a
company information portal could require two grid coordinates while access to a
online investment site could require four coordinates.
You set the minimum and maximum number of required grid coordinates in Entrust
IdentityGuard policy, and then set the exact number of coordinates for each
authentication scenario in your application. The application must present a number
of coordinates between the minimum and maximum number of required coordinates.
Passcode lists
Passcode list authentication is a grid authentication that uses a list of passcodes or
transaction numbers (TANs) rather than a grid. Each passcode can be used just once.
With this approach, you provide users with a list of randomly generated passcodes
for second-factor authentication.
Considerations The standard size of a grid card is a 5 x 10 grid, which contains
19,600 three-cell challenge sets. This size provides both security
and usability. You can customize the grid size to meet your unique
deployment, usability, and security requirements.
Replace grid cards on a regular basis. Determine the frequency of
grid replacement based on your users needs and your security
requirements.
Determine whether you need one-step or two-step
authentication options (two-step is recommended).
VPN remote access
Microsoft Windows desktop
Deployment risks and
mitigation
Through mechanisms such as phishing or pharming, an attacker
can capture one or more grid authentications made by a user and
attempt to authenticate to the legitimate application. Replace
cards regularly to help mitigate this risk.
Grids must be processed and delivered securely to the user so that
no grid information is copied before the user obtains the grid.
Consider using Entrust IdentityGuard Card Production Service
(available through Entrust TrustedCare online) to ensure that card
security is maintained throughout the deployment process.
Table 6: Grid authentication advantages and considerations (continued)
48
Feedback on guide
Some organizations view passcode lists as easier for their users to use than cards,
though our usability study proved that card use is quick to learn. (See Card usability
study on page 167.)
Typically, you distribute these lists to users on a printed sheet of paper similar to
Figure 11. You can also distribute scratch-off cards that make it easy for users to see
what codes they have already used.
Figure 11: Sample passcode list
Then, when a passcode is required, you prompt for the passcode next to a number in
the list as in Figure 12.
Figure 12: Sample passcode prompt
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.
49
Feedback on guide
To help 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.
Knowledge-based authentication
A simple mechanism for identifying users is to challenge them to provide information
that an attacker likely cannot 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.
In turn, the users recognize the secret questions they set up during registration and
they know that they have reached a legitimate site.
Table 7: 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 grid production process, you need to produce and
distribute the passcode lists to your users. Unlike grids, however,
you will typically want 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 maintain a balance between security and
usability.
Choose between numeric or alphanumeric passcodes.
Deployment type Web access
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, or add another form of authentication (such as
machine authentication) along with a passcode list.
Alternatively, consider deploying grid authentication instead of a
passcode list.
50
Feedback on guide
During enrollment the user may select and provide answers to easily-remembered
questions, such as What year did you buy your first car?, Which historical figure do
you most admire?, Name your most memorable cartoon character?, and so on.
Questions can be drawn from previous user interactions with the organization. For
example: What was the balance on your last statement?. It is difficult for attackers to
harvest answers to these questions 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 of them to
increase second-factor authentication strength.
Figure 13: 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.
To make it easier on users, you can use questions and answers for additional
authentication rather than as your main second-factor authentication method. For
example, use machine authentication for the users normal login location and reserve
the questions for when the user logs in from a different machine.
Table 8: Knowledge-based authentication advantages and considerations
Advantages There are no physical requirements for users (such as cards or
tokens).
You can leverage previous interactions between the user and your
organization.
51
Feedback on guide
One-time password authentication
There are situations where you will want to provide users with an authentication
method that, for security reasons, must be outside of the users current online session.
For example, a user attempts to execute a high-risk transaction (such as transferring
funds to a foreign bank) and you want to provide extra authentication. By bypassing
the primary communication channel (the users computer), you make it harder for an
attacker or fraud attempt to succeed.
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
Considerations Consider how you will generate knowledge-based questions,
such as generated codes or pre-populated lists. See Sources of
questions on page 122.
Good questions will follow the criteria for privacy, security, and
usability. See Creating good questions on page 123.
Users do not like answering a large number of questions.
Allowing inexact answers by using a word map file can
compensate for users entering some incorrect values (such as
St. instead of Street ).
If the user must answer a large set questions to authenticate, you
may wish to allow a few incorrect responses.
Select how many questions a user must answer based on your
security needs. More sensitive activities may require more
questions.
VPN remote access
mitigation
User-generated question-and-answer sets are not always secure.
When prompted to create their own questions and answers, users
can enter questions and answers that are easy to guess or easy to
find. Consider providing the user with a stock list of questions
instead.
Users do not always enter secure answers to questions.
Even when providing the user with a stock list of questions to
answer, users can enter answers that are not secure (such as
sequential keyboard sequences or repeated answers). Be sure to
validate the answer set so it meets security needs. Alternately,
consider using a different method for generating questions
( Sources of questions on page 122).
Table 8: Knowledge-based authentication advantages and considerations (continued)
52
Feedback on guide
directly using email, text message (SMS), or by voice to a preregistered 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 is already stored about the user and is the information
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 previously collected information is not reliable enough for one-time
password authentication, you can register users. The online registration
process allows authenticated users to enter, validate, and correct their
delivery information (email address, voice phone number, and cell phone
number) and out-of-band authentication preferences. This also allow users
to personalize the way their confirmation number is delivered to them.
One-time password delivery systems
In a typical user registration process, your application should ask for an email address
and one or more phone numbers (home, work, cell). Once you have this information,
your application can deliver a one-time password by email, by text message to a cell
phone, or by an automated voice message to a standard phone or cell phone.
Table 9: 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 use channels that already exist, including telephone calls,
SMS to a cell phone, or email to a computer or mobile device.
These channels 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 your need for
security and the amount of time it would take for a user to receive
your message and enter the password.
VPN remote access
53
Feedback on guide
For an automated voice message, you need to interact with a third-party service, such
as Authentify. For information, visit http://www.authentify.com. For delivery by
email or a text message (SMS) to a cell phone, you can use Entrust IdentityGuard to
send the one-time password to one or more numbers.
54
Feedback on guide
Mutual authentication methods
Your organization needs to have confidence in the users identity. Likewise, users must
be confident that they are transacting with their organization or intended online site,
and not a fraudulent organization or spoofed site. Mutual authentication provides a
way for your organization and your users to prove themselves as legitimate. Entrust
IdentityGuard provides several mutual authentication methods.
Mutual authentication works as follows:
1 The user completes first-factor authentication successfully.
2 Entrust IdentityGuard presents the user with an authentication challenge.
3 The challenge presents an image or information to the user that only the valid
site could have.
4 The user recognizes the image or information, and responds to the challenge.
5 Entrust IdentityGuard validates the entered values and authenticates the user.
Mutual authentication is also called organization authentication. The following
options are available:
Grid serial number or grid location replay on page 54
Image and message replay on page 55
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.
Each grid card or passcode list has a unique serial number that is known only
to the user and the organization that issued it. During login, you can display
this number to the user before prompting for second-factor authentication.
Before entering a password or grid challenge response, users 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 know the grids contents and, therefore, you
must be legitimate.
Table 10: Grid serial number and location replay authentication advantages and considerations
Advantages Helps users determine if they are at a valid site before they
provide sensitive authentication data.
Easy to use when grid authentication is enabled.
55
Feedback on guide
Image and message replay
Another replay method supported by Entrust IdentityGuard is image and message
replay. As part of the registration process, the user selects an image from a gallery and
enters a custom image caption. During future logins, the user is shown the selected
image and their caption, as shown in Figure 14 on page 55.
Figure 14: Choosing a custom image and caption
Considerations It requires two-step authentication (See Grid authentication on
page 44 for more information on two-step authentication).
You can take additional security measures to make this
information difficult to harvest. For example, you can conceal
entries by avoiding machine-readable characters; that is, display
them as images instead of text.
VPN remote access
Table 10: Grid serial number and location replay authentication advantages and considerations
56
Feedback on guide
Whether the users choose 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 they are on a
legitimate site.
Table 11: Image and text replay authentication advantages and considerations
Advantages Allows a user to determine the sites legitimacy.
Not dependent on a specific authentication method.
Considerations Plan for image data size implications because 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.
Have many images available and let the users choose an image
they identify with.
If you decide to allow users to upload their own images, take
special care to manage the amount of disk space budgeted for
this feature. Entrust IdentityGuard includes policy settings for a
maximum file size that you can set to ensure that users dont
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).
57
Feedback on guide
Machine authentication
Machine authentication provides validation of a users computer to secure the user
against a variety of threats. It is an especially attractive authentication method when
users usually access their accounts from the same computer. It allows for seamless
authentication without any noticeable impact on the user experience.
To establish the computer identity, your application generates at least one of the
following (as specified by Entrust IdentityGuard policy):
Machine tag. A machine tag includes at least one of the following.
machine nonce
This is an arbitrary number generated only during machine registration.
sequence nonce
This is a number generated each time the machine is authenticated. A
sequence nonce ensures that the machine secret is only valid until the next
login attempt. The sequence nonce increases security by preventing an
attacker from authenticating with an older version of the machine secret.
A machine tag is stored in a persistent object (such as a cookie) in the users
Web browser.
Machine fingerprint.
This is a collection of machine data (called application data) specific to the
users computer, such as the browser version or operating system. The
application generates the machine fingerprint each time the user attempts to
authenticate.
Note: If the application does not generate a machine nonce, then the
application must generate a machine fingerprint.
After generating a machine tag or machine fingerprint (or both), Entrust
IdentityGuard stores a copy of the information in the repository as a machine secret.
For maximum security, it is recommended that your application generates both a
machine fingerprint and a machine tag (with both the machine nonce and sequence
nonce).
If your users do not allow persistent objects (such as cookies) to be stored on their
computers, your application can generate just the machine fingerprint. In this case, it
is recommended that the application collect as much application data as necessary to
differentiate between similar computers.
The computer registration process is similarly performed for all computers a user
wants to register. In Figure 15, selecting Remember me on this machine sets machine
authentication into action.
58
Feedback on guide
Figure 15: Login page with machine authentication
During subsequent logins:
1 The application retrieves the machine tag and regenerates the machine
fingerprint.
2 Entrust IdentityGuard compares the machine tag and machine fingerprint to the
machine secret stored in the repository.
3 If the machine tag and machine fingerprint match the machine secret, Entrust
IdentityGuard authenticates the user.
4 The application changes the sequence nonce and Entrust IdentityGuard stores an
updated version of the machine secret in the repository.
Entrust IdentityGuards machine authentication provides protection for users even if
they have had other authentication data stolen by attackers. Because it is unlikely that
an attacker would enter the stolen credentials from the users computer, the machine
authentication fails and the attacker cannot obtain access.
Sources of application data
There are several ways to add application data to the machine secret. The choice
depends on the method chosen to gather the data. For more information, see the
Entrust IdentityGuard Administration Guide.
59
Feedback on guide
Table 12: 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). Using machine authentication
on public computers is a security risk and is not recommended.
Determine how many machine secrets users can have. Users may
have more than one machine secret if they access your site from
more than one computer. For example, a user may access your
site from a work computer and from a laptop.
Determine whether your application will generate a machine tag
or machine fingerprint, or both.
Determine how to obtain the machine information (depending on
the browser type, a client-side application, and so on). See the
Entrust IdentityGuard Programming Guide for more information.
If generating machine fingerprints, determine what application
data you want to collect.
Determine how many elements in the machine fingerprint must
successfully match the machine secret for successful
authentication.
For example, if one of the elements is the browser version and in
a subsequent authentication that version has changed (the user
upgraded the browser), it may still make sense to allow that user
access.
60
Feedback on guide
Risk-based authentication
There are situations in which you will want to present users with an extra
authentication challenge or reject the users outright for security reasons.
Alternatively, you may want to automatically authenticate users who pose no risk.
Setting risk policies
You can set two risk assessment policiesnormal and enhancedin Entrust
IdentityGuard that determine how your application reacts in the five risk scenarios
below:
1 A user logs in from a different computer than usual and machine authentication
fails. For more information, see Machine authentication on page 57.
2 A user logs in from an IP address that is not in the users location history list (IP
addresses the user authenticated from recently). For more information, see IP
geographic locations on page 61.
3 A user logs in from two separate geographic locations in a suspiciously short
period of time. This is known as a velocity test. For more information, see IP
geographic locations on page 61
4 A user logs in from an IP address that is on the IP blacklist. For more information,
see Blacklists on page 61.
5 A user logs in from a country that is on the country blacklist. For more
information, see Blacklists on page 61.
For example, your normal security policy might reject the user in the case of 4 and 5,
and issue an authentication challenge in the other three cases. In comparison, the
enhanced security policy might reject the user in all cases but 1 and 2.
Setting authentication policies
For any user not rejected by the risk policies described above, you can set other
policies that determine when those users can enter a site without an authentication
challenge. The choices are:
1 If either machine authentication or IP authentication pass, automatically
authenticate the user.
2 If just IP authentication passes, automatically authenticate the user.
3 If just machine authentication passes, automatically authenticate the user.
4 If both IP authentication and machine authentication pass, automatically
authenticate the user.
5 Always present the user with a challenge.
61
Feedback on guide
These five choices are logically ordered in strength from weakest (1) to strongest (5).
The policy you set for the enhanced level must be equal to or stronger than the
normal policy.
The challenge or challenges presented to the user can be any of those described
previously in this chapter: grid, passcode list, token, knowledge-based (question-and-
answer) and one-time password.
IP geographic locations
Entrust IdentityGuard includes a mechanism to determine the approximate
geographical location of the IP address of any user who attempts to access your site.
The location data consists of the country, region, city, Internet service provider (ISP),
latitude, and longitude.
With this data, Entrust IdentityGuard determines if the user passes your risk and
authentication policies.
Compare the current location with the list of expected locations. If there is a
match, the user will pass an expected location test.
Compare the current location with the list of locations previously associated
with the user. If that location matches one on the list, the user will pass a
location history test.
Compare the current location with the last location associated with the user.
If the user changes locations faster than physically possible, the user will fail
the velocity test. For example, if the user logs in from Toronto at 10:00 a.m.
and then logs in from New York a few minutes later, it is likely that one of
the logins is not legitimate.
Compare the current location with all locations on the IP and country
blacklists. If a user's location is on a blacklist, the user is rejected.
Blacklists
Through the Administration interface or the master user shell, you can review and
update blacklists containing country codes and IP addresses.
You can have multiple country blacklists. This way, you can apply different lists to
different groups of users. A country blacklist consists of the two-character Internet
domain codes assigned to each country. The default list included with Entrust
IdentityGuard contains A1 codes, which are addresses that belong to anonymous
proxy services, and A2 codes, which relate to satellite-based Internet providers that
conceal the country of origin.
You can have a single, system-wide IP blacklist that applies to all users. To keep the
list compact and easy to maintain, each entry you add to the blacklist can specify a
range of IP addresses. For example the entry 100.1.1.1 100.1.1.10 represents 10
62
Feedback on guide
IP addresses. (The blacklist supports only version 4 IP addresses.) By default, the IP
blacklist has no entries.
Table 13: Risk-based authentication advantages and considerations
Advantages Provides a flexible risk-assessment mechanism.
Lets you block users from high-risk Internet domains or
geographic locations.
Lets you match the authentication methods to the risk level of the
user or groups of users.
Lets you automatically authenticate low-risk users.
Considerations The IP location data relies on third-party data sources. Entrust
IdentityGuard supports Maxmind. (For more information, visit
http://www.maxmind.com.) You can customize the interface to
support other data providers.
You need to update IP location data on a regular basisat least
monthly. Downloads are available on the Entrust TrustedCare
Online Web site.
Determine how many entries you want for the location history
list.
Set a standard for the velocity test.
Make sure your Web application can supply valid IP addresses to
Entrust IdentityGuard.
63
Feedback on guide
Temporary PIN authentication
In 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 card 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 card or token 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
card or token.
Considerations It is only available if using token or card authentication (either grid
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.
You should only use this method as a temporary second-factor
authentication solution and not as a permanent second-factor
authentication solution.
64
Feedback on guide
Using personal verification numbers
For additional security, you can require a user to enter a personal verification number
(PVN) during an authentication challenge. For example, when a user enters grid
coordinates, you can also prompt for their PVN number to validate the card user.
A PVN can be used with a card (grid or passcode list), token or one-time-password
authentication challenge.
Each user can have just one PVN. The PVN is a numeric value whose length is set by
policy. Users can pick their own PVNs or administrators can auto-generate random
PVNs and assign them to users.
63
Chapter 3
Planning your deployment
This chapter discusses items to address prior to, or during, the deployment of Entrust
IdentityGuard.
Planning: initial considerations on page 64
Planning administrative tasks on page 68
Planning user requirements on page 70
Group requirements on page 74
64
Feedback on guide
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 aspects can be
categorized into the following five areas:
authentication methods
This refers to the authentication methods supported by Entrust
IdentityGuard and that your organization requires to verify user identities.
Examples include considering the requirements for second-factor and mutual
authentication, and how to implement the methods into your existing
authentication structure.
See Authentication methods on page 35.
policies and practices
This refers to the specific security policies supported by Entrust IdentityGuard
and the practices used by your 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 factors,
the use of a personal verification number (PVN), the inclusion of blacklists,
and the number of incorrect attempts before lockout.
See Entrust IdentityGuard policies on page 65.
people
This refers to the personnel required to deploy, operate and support Entrust
IdentityGuard.
See People on page 66.
architecture and technology
This refers to the technical aspects of supporting Entrust IdentityGuard, such
as the networking environment, operating systems, hardware and software,
and application integration. Examples include the environment in which
Entrust IdentityGuard is deployed, and the applications that Entrust
IdentityGuard protects.
See Entrust IdentityGuard components on page 26 and Entrust
IdentityGuard baseline architectures on page 141.
operations
This refers to the ongoing operational aspects of Entrust IdentityGuard and
the procedures needed to support, administer, and operate Entrust
IdentityGuard. Examples include the initial deployment of cards or tokens,
and the distribution and activation of replacement cards or tokens.
See Operations on page 66.
65
Feedback on guide
Entrust IdentityGuard policies on page 65
People on page 66
Operations on page 66
Entrust IdentityGuard policies
Organizations generally have existing polices and practices around the identification
and authentication of users. The processes used for user identification and
authentication to the existing application will apply to Entrust IdentityGuard
configuration and deployment.
Entrust IdentityGuard, through its policy set, defines the permissible behavior of
users, administrators, and authentication methods. 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 different policies for your system, based on the different requirements of
different user groups ( Group requirements on page 74).
For example, Entrust IdentityGuard uses policies to determine:
password rules for administrators when logging into 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
authentication methods are available to them).
when to include a PVN with a challenge.
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 grids, passcode lists, or tokens out of
sight when not in use and memorizing PVNs, answers, and other
information.
Train users on 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 enrollment and for
card and token replacement. These requirements will be primarily driven by
the business value of the applications being protected with the Entrust
66
Feedback on guide
IdentityGuard authentication methods. Choosing to add Entrust
IdentityGuard authentication to the application indicates that there is a
substantial value involved.
For information on specific policies, see the Entrust IdentityGuard Administration
Guide.
People
As with any system, Entrust IdentityGuards deployment and ongoing operation
requires the participation of people from different parts of your organization.
Although many people are required only on a part-time basis, identifying them and
communicating their roles and responsibilities early in the planning process can help
avoid delays later.
Table 15: People required for the deployment and operation of Entrust IdentityGuard
Person or people Job description
Overall project manager
(recommended)
Act as a single point of contact for the project and have the authority
to secure additional resources.
Technical lead Bring knowledge of the organizations technical environment to the
project. Throughout deployment (along with other personnel), obtain
the necessary knowledge to support the production implementation
into the operational phase.
Directory administrator Administrate the directory (if integrating with an LDAP-compliant
directory).
Database administrator Administrate the database (if integrating with a JDBC-compliant
database).
Network and systems
administrators
Provide support during the planning and installation phases.
Application
development personnel
Provide support for the application integration.
Operations personnel Provide support for the operational requirements after deployment.
Customer Support and
Help Desk personnel
Integrate support services for Entrust IdentityGuard into the existing
support mechanisms.
Hardware procurement
personnel
Obtain any necessary hardware (such as servers, cards, and tokens).
System support
personnel
Carry some of the responsibility for the ongoing support of Entrust
IdentityGuard.
Note: These people may be representatives from other groups in your
organization.
67
Feedback on guide
Operations
Operation planning encompasses back-end operational aspects such as server
administration and operations, backup and recovery, and 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 are required.
Entrust IdentityGuard maintains log files to assist administrators in troubleshooting
activities. For more information on these logs, see the Entrust IdentityGuard
Backup and recovery
Update your regular backup and recovery procedures with new information about
the Entrust IdentityGuard Server and its operation.
If Entrust IdentityGuard is integrated with an existing directory or database,
repository backup and recovery 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 your organizations existing standards for data backup.
Update your organizations disaster recovery plan to include Entrust
IdentityGuard.
The Entrust IdentityGuard Administration Guide provides information about backing
up Entrust IdentityGuard Server application files, along with information about
recovery steps.
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 your organizations approach to deploying applications into
production, additional implementations of Entrust IdentityGuard into test or staging
environments may be required.
68
Feedback on guide
Planning administrative tasks
Besides the people required to deploy Entrust IdentityGuard (see People on
page 66), you need to plan for people who will administer Entrust IdentityGuard and
its users.
You must assign the following Entrust IdentityGuard roles:
Master User 1, Master User 2, and Master User 3. Assign a different person
to each of these three roles. These people are required during the initial
installation of Entrust IdentityGuard and after an upgrade or restore.
Administrators perform most other duties.
One or more administrators. Assign administrative privileges to people in
your organization so that they can manage the Entrust IdentityGuard system
and users. You should have one administrator super user, who can do
everything, and other administrators to manage groups and roles, configure
Entrust IdentityGuard, and manage policies.
Note: In Entrust IdentityGuard, any user can become an administrator if you
assign that user one or more roles.
Assigning master users on page 68
Assigning administrators on page 69
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:
initialize the system
export the master keys
create and manage administrators
Consider the following when assigning the three master user roles:
The master user role allows extensive administrative capabilities. Assigning
staff to these roles should be in compliance with existing policies on
administration staff.
Identify who your master users will be before installing Entrust
IdentityGuard. Ensure the master users are scheduled for the installation and
that they 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 a
69
Feedback on guide
minimum of eight characters in length, and contain upper and lowercase
characters and a numerical value.
For security reasons, master users do not have administrator privileges within
the Administration interface. An administrator who is also a master user
requires two identities. See the Entrust IdentityGuard Installation Guide and
the Entrust IdentityGuard Administration Guide for more information.
Once you identify the master users, provide appropriate training. Update
existing documents (such as operational procedures, administration guides,
and training materials) or create new documentation as required.
Assigning administrators
Administer Entrust IdentityGuard and its users through the Administration interface.
This interface allows administrators to manage Entrust IdentityGuard policies, groups,
users, cards, tokens, configuration, and so on, and to handle day-to-day interaction
with the 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:
Each administrator is assigned a particular role or set of roles, which defines
which operations they can perform. Roles include a set of permissions that
govern what actions an administrator can perform.
For example, you can restrict an administrator who works at your Help Desk
to
reset user accounts once theyve been locked out
manage temporary PINs
view user account information
For more information about roles, see the Entrust IdentityGuard
Administrators access the administration interface using password
authentication. You can optionally add grid or token authentication as well.
Each administrator is assigned a set of user groups to 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 74.
The Properties editor gives administrators with applicable permissions to
access all Entrust IdentityGuard properties. Only administrators with a very
good understanding of Entrust IdentityGuard should be given access to the
Properties editor.
70
Feedback on guide
Planning user requirements
Users 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
Alias and user ID requirements on page 70
Training users on page 71
Providing services to users on page 72
Locking out users based on authentication method on page 72
Suspending users on page 73
Alias and user ID requirements
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 email address. Entrust IdentityGuard allows a user to have a single
authentication method such as a card for authentication to all these applications.
To set this up, 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/username
format. For example, if the users 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 for all users with the given name as their user name or an alias
following these rules:
Search all repositories 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.
71
Feedback on guide
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.
If you are using groups, it is recommended that client applications send both the
group and user name to Entrust IdentityGuard. See Group requirements on
page 74.
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.
If you plan to allow aliases, consider the following:
Determine all user access points that will be protected by Entrust
IdentityGuard.
If the same user has multiple user names, determine the maximum number
of aliases each 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/username format.
Aliases in a consumer deployment
Related Web applications often use different user IDs for the same person, such as
banks with 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 user IDs for their checking and savings
accounts. When the user logs in to the banks Web site, users 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 means of authentication (such as
a card or token) for all these applications. It permits an administrator 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 users, the users can specify either their user
ID or an alias.
Training users
When deploying Entrust IdentityGuard, you must train your users to use the new
authentication methods and have them register as required. Also, if you have
Microsoft Windows desktop users, they must install the Entrust IdentityGuard
Desktop Client for Microsoft Windows.
When planning training for users, consider the following:
72
Feedback on guide
Inform users of Entrust IdentityGuard and your companys plans for
implementation before deployment.
Create a flash demo or similar video that illustrates how to use the 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 tokens, cards, and PVNs.
The interaction points with the users will vary depending on how the user life cycle
management processes are implemented. See Life cycle management overview on
page 130 for more information.
Providing services to users
An organization can implement any or all of the following approaches in providing
services to their Entrust IdentityGuard users:
over-the-counter
Users physically visit a Service Desk to request enrollment into Entrust
IdentityGuard, or to request a replacement card or token. All processes are
completed with the user present. This approach is useful during pilot phases
where a small number of users (for example, less than 100) will be enrolled
and enrollment can be automated in parallel with the pilot.
self-service
Users access an online application to request enrollment into Entrust
IdentityGuard, or to request a replacement card or token. Upon acceptance
of the request, one of the following can happen:
For grid or token authentication, the users are sent an Entrust
IdentityGuard grid or token (or pickup instructions) with activation
instructions.
For other authentication methods (such as knowledge-based
authentication), the application can automatically enroll the user or replace
the users authentication data.
central service
An administrator initiates enrollment into Entrust IdentityGuard, or replaces
cards or tokens, and issues Entrust IdentityGuard authentication data for
many users at once using bulk operations. This approach is strongly
recommended for rollout to a large user community.
73
Feedback on guide
Locking out users based on authentication
method
Entrust IdentityGuard includes a locking mechanism that preserves the usability of an
authentication method. Challenges are locked until correctly answeredthis 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 often use automated systems
to perform brute force attacks, so success can be accomplished effortlessly in a short
period of time, unless security precautions are built in.
When the lock out period expires, Entrust IdentityGuard presents users with the same
challenge they failed to answer before lock out. This makes it impossible for attackers
to cycle through a series of challenges until they guess a correct response.
Users can be rejected even before they attempt to authenticate if they fail established
risk-assessment policies. See Risk-based authentication on page 58.
Suspending users
Administrators with applicable permission can suspend users. Suspended users
cannot use any Entrust IdentityGuard authentication method to gain access to your
applications.
View suspension as a temporary measurean action taken while a problem with the
user is investigated and sorted out. To disable a user permanently, delete the user.
74
Feedback on guide
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 set of
authentication and security policies. See Entrust IdentityGuard policies on page 65
for more information.
You can also apply different levels of risk assessment (normal or enhanced) to groups
using a policy setting. See Risk-based authentication on page 58.
Attention: While you can change a groups policy settings after the creation of
the group, take care not to invalidate pre-existing cards or other authentication
data. For example, if the grid size 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 on page 74
Groups in an enterprise deployment on page 74
Analyzing your companys group needs on page 75
Group implementation on page 76
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.
Loyalty card users may be separated into regular, special, and elite classifications. The
policy for each group can include different authentication methods.
Configure the application to send both the group and user ID to Entrust
IdentityGuard. For example, if the users 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
75
Feedback on guide
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
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 companys group needs
Create a summary of Entrust IdentityGuard groups. Groups affect users,
administrators, and authentication data, so consider the following when defining
groups:
Table 16: Things to consider when creating Entrust IdentityGuard groups
Considerations Comments
What types of users do you
have that require multifactor
authentication?
Do you have users in defined groups connecting to your
company through VPN servers?
You will need to enable either the Entrust IdentityGuard
Radius proxy or another VPN server authentication method.
Do you have distinct groups of Windows users that require
multifactor authentication when logging in to their
computer?
You will need to install and configure the Entrust
IdentityGuard client for Windows.
Do you have users who access your site using a Web portal?
You can put these users in a separate group with mutual
authentication enabled.
Which applications will you create, and what types of users
will access each application?
You can group users by the applications they access.
How will you subdivide
these groups?
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?
76
Feedback on guide
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.
Cards and tokens are associated with specific groups. In order to assign the
card or token to a user, the user must belong to the same group as the card
or token.
If your system contains only unique user names, then your client applications do not
have to include group names in a user identification request.
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 all repositories for all users with the given user name. For an
LDAP-compliant directory, look in all search bases. See Repository on
page 29 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, see the Entrust IdentityGuard
Administration Guide for more information on how groups are implemented.
How will you administer
these groups?
Will each group have specific administrators?
Will one central group of administrators administer
everything?
Will some administrators administer multiple groups?
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?
Table 16: Things to consider when creating Entrust IdentityGuard groups (continued)
Considerations Comments
77
Chapter 4
Deployment considerations
This chapter provides information you should consider when deploying Entrust
IdentityGuard in your organization.
Application integration on page 78
Application considerations on page 81
Selecting a repository on page 83
Performance testing strategies on page 85
Backing up, restoring and migrating on page 87
High availability and disaster recovery on page 88
Switching over to Entrust IdentityGuard on page 93
78
Feedback on guide
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 18 for contact information.
Web integration on page 78
Microsoft Windows integration on page 79
VPN remote access integration on page 79
Wireless Access Portal integration on page 80
Web integration
The Entrust IdentityGuard Authentication API is used to retrieve challenge requests
and authenticate user responses. It is designed to easily integrate with your existing
authentication applications to provide multifactor authentication.
You can create a client application that calls the Authentication API using its Web
service, Java Platform, or .NET interfaces to authenticate users. For more information,
see the Entrust IdentityGuard Programming Guide for your programming language.
79
Feedback on guide
Figure 16: Web integration using Authentication API
Microsoft Windows integration
Entrust IdentityGuard Desktop for Microsoft Windows is a small-footprint client that
communicates with the Entrust IdentityGuard Server. It provides strong multifactor
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 43 on page 163)
for remote users (Figure 37 on page 156)
If your deployment includes remote users, you need to add the Remote Access
Plug-in. For more information, see Entrust IdentityGuard components on page 26.
VPN remote access integration
Entrust IdentityGuard supports integration with remote access VPN devices to
provide multifactor 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
80
Feedback on guide
Remote Authentication Dial In User Service (Radius) server, a Windows domain
controller, an LDAP-compliant directory, or Entrust IdentityGuard. You then use
Entrust IdentityGuard to provide multifactor authentication.
Regardless of the resource you use, the VPN server thinks it is communicating with a
Radius server. It is actually communicating with the Entrust IdentityGuard Radius
proxy. Figure 32 on page 150 illustrates the integration approach. No changes are
required for the VPN client.
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 Administration Guide for details on how to configure
the Radius proxy.
Wireless Access Portal integration
Entrust IdentityGuard supports integration with wireless access devices to provide
multifactor authentication. This is accomplished through integration with the Entrust
IdentityGuard Radius proxy. The Radius proxy manages communications between a
wireless access point and Entrust IdentityGuard. You then use Entrust IdentityGuard
to provide multifactor authentication.
Regardless of the resource you use, the wireless access point thinks it is
communicating with a Radius server. It is actually communicating with the Entrust
IdentityGuard Radius proxy. Figure 35 on page 154 illustrates the integration
approach.
See the Entrust IdentityGuard Administration Guide for details on how to configure
the Radius proxy.
81
Feedback on guide
Application considerations
Define a policy that addresses all 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
aspects affects the overall security of the system. To maximize resistance to attacks,
you can do the following to make it difficult to capture second-factor 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.
Machine-readable characters 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.
In two-step authentication, users must enter first-factor credentials on one
screen, then enter the grid coordinates on the second screen. Because the
identity of the user is known, Entrust IdentityGuard presents a set grid
challenge. This ensures the challenge remains constant until it is successfully
answered.
Add an extra challenge for the users personal verification number (PVN) to
make sure the card or token user is valid.
Use a mutual 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 Mutual authentication
methods on page 52.
Use temporary PINs when users have lost or not received their grid, token,
or passcode list.
Determine which authentication method Entrust IdentityGuard should use, if
the application doesnt 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 .NET API that you can use to integrate
your applications with the Administration service in Entrust IdentityGuard. The
82
Feedback on guide
Entrust IdentityGuard Administration interface is an example of an application using
the Administration API.
For more information about implementing the Entrust IdentityGuard Administration
API, see the Entrust IdentityGuard Programming Guide.
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, but you can
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 or machine
secrets (see Mutual authentication methods on page 52 and Machine
authentication on page 55).
83
Feedback on guide
Selecting a repository
Entrust IdentityGuard stores data in a repository. A repository is either an
LDAP-compliant directory or a JDBC-compliant database. An Entrust IdentityGuard
system can contain one or more repositories, including a combination of both
directories and databases.
Whenever an Entrust IdentityGuard operation requires a user's information, Entrust
IdentityGuard searches the repository. Entrust IdentityGuard updates user
information when required by administrative tasks, such as adding a new
authenticator (such as a grid), or during authentication events that involve a
challenge (such as grid coordinates).
When selecting a repository, consider where you currently store first-factor user
credentials (user name and password). Typically you install Entrust IdentityGuard to
augment first-factor user credentials for access to an application, such as a VPN or a
Web-based system. Entrust IdentityGuard is designed to extend the information
stored in existing repositories so you do not have to implement additional technology.
However, directories and databases operate differently and can affect your decision
about which type of repository to select for your system.
Entrust IdentityGuard provides a complete Administrative API that you can use (see
Entrust IdentityGuard Administration service on page 29), so any differences
between directories and databases can be hidden from users and administrators.
Directory repositories
User entries must exist in the directory before you can populate any Entrust
IdentityGuard attributes. Entrust IdentityGuard cannot create any user entries in a
directory. You must create users in the directory with your existing directory
management tool.
Entrust IdentityGuard cannot store unassigned grid patterns and token serial numbers
in a directory, but stores them in either a local file system or a local database. In a
configuration with a directory and a local file system, only a single Entrust
IdentityGuard server can host the local file system, and all assignments of grids or
tokens must be performed on that server. Availability of that server affects your
organization's ability to assign grids or tokens. Using a local database to store
unassigned grids and tokens supports a high availability configuration (see High
availability and disaster recovery on page 88).
Entrust IdentityGuard supports many widely-used directories. For more information,
see the Entrust IdentityGuard Directory Configuration Guide.
84
Feedback on guide
Database repositories
For databases, no existing user entries need to exist before you can populate any
Entrust IdentityGuard attributes. Entrust IdentityGuard can create new user entries in
a database for you.
Entrust IdentityGuard stores unassigned grid patterns and token serial numbers in
separate tables in a database. Using a database to store unassigned grids and tokens
supports a high availability configuration (see High availability and disaster
recovery on page 88).
Entrust IdentityGuard supports many widely-used databases. For more information,
see the Entrust IdentityGuard Database Configuration Guide.
Performance and maintainability
The performance of a repository can be a factor in environments with hundreds of
thousands of users, or in environments where the existing user system is already
heavily loaded. While your choice of repository does not affect Entrust
IdentityGuard's performance, you need to consider the impact of the additional load
on your repository.
You may have your own preferences for a repository based on the level of skill within
your organization to support and maintain it. You should choose a repository that
your organization is equipped to properly support and manage with the required
response timing.
Entrust IdentityGuard supports a combination of both databases and directories,
where each repository can support a different group of users. Your Entrust
IdentityGuard system can use the mix of technologies that best meets the needs of
your users and your organization.
85
Feedback on guide
Performance testing strategies
You can perform tests to validate the performance characteristics of Entrust
IdentityGuard in your environment. To perform these tests, use a commercial
automated testing tool that allows 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 of the required size on the Entrust IdentityGuard
Server.
To prepare the Entrust IdentityGuard Server for performance testing
1 Create test users.
2 Set up the test users with their appropriate authentication methods.
If you are testing performance with grids, ensure the grids are generated,
exported, and assigned to users. However, you do not need to print the grids.
The script needs to have the values from each grid loaded into an array so
that it can provide the correct response.
If you are testing performance with tokens, ensure the tokens are loaded.
After the Entrust IdentityGuard Server is ready for performance testing, you can run
the script. The script must perform the following steps:
1 Load the grid cells, one-time passwords, or tokens into an array.
2 Capture the start time for a transaction.
3 Send a request to the Entrust IdentityGuard Server requesting a challenge.
4 If you are using grids:
a Receive the challenge and parse it for the requested coordinates on the grid.
b Look up the correct values for the response in the grid cells.
c Optional. Pause for think time to simulate a person providing the response
to the challenge.
5 Send a request to the Entrust IdentityGuard Server with the values of the grid,
token, or one-time passwords.
6 Receive the response back from the server.
7 Capture the time that the transaction is completed and calculate the elapsed time
since the request.
8 Report the elapsed time of the request to the screen, printer or file, as required.
86
Feedback on guide
After 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.
For information about repository size requirements, see either the Entrust
IdentityGuard Directory Configuration Guide or the Entrust IdentityGuard Database
Configuration Guide.
87
Feedback on guide
Backing up, restoring and migrating
It is strongly recommended that you have a backup strategy in place before you install
or upgrade Entrust IdentityGuard. Backing up your Entrust IdentityGuard system
provides insurance in case something happens to the servers unexpected happens
(such as a hardware failure). You must use a separate server or separate physical disk
to host the backup files in case of a hard disk failure.
Your strategy should include the following:
Selecting the type of backup you will perform. In Entrust IdentityGuard,
there are two backup options: full backups and partial backups.
Full backups contain all information required to restore the configuration,
logs, and file-based repository.
Partial backups contain enough information to restore a replica system.
Backing up your repository on a regular basis, especially before installing or
upgrading Entrust IdentityGuard. Entrust IdentityGuard does not back up
your data repository for you.
Backing up and restoring all repositories together if the data is split over
multiple repositories.
Saving copies of the JDBC driver JAR files you used during installation, if you
use a database repository.
Backing up the masterkeys.enc file. This file contains the encryption keys
that protect the repository.
Backing up your logs on a regular basis.
A properly backed-up system can be successfully restored. See the Entrust
IdentityGuard Installation Guide for restore instructions.
The backup and restore mechanism built into Entrust IdentityGuard lets you migrate
from a UNIX platform to a Windows platform, or from a Windows platform to a UNIX
platform.
To perform a platform migration
1 Backup your system configuration using the existing backup mechanism.
2 Copy the backup file to the new platform.
3 Install Entrust IdentityGuard on the new platform and, as part of the
configuration steps, select to restore the configuration from a backup file.
4 Restore the configuration from the backup file.
Since this migration functionality was introduced in Entrust IdentityGuard 9.0. Older
versions of Entrust IdentityGuard must be upgraded before migrating to another
platform.
88
Feedback on guide
High availability and disaster recovery
Entrust IdentityGuard offers a failover scheme to ensure there are backup systems in
place in the event that a primary system fails. This scheme addresses high availability
and disaster recovery issues as described here:
Entrust IdentityGuard Server failover
Directory failover
Database failover
Radius server failover
For procedures about configuring these failover scenarios, see the Entrust
IdentityGuard Administration Guide.
Entrust IdentityGuard Server failover
All data sources (databases, directories, Radius servers, external authentication
sources) that Entrust IdentityGuard uses are listed in specific properties in the Entrust
IdentityGuard properties file. To set up a common failover mechanism, you use the
Properties Editor to list two or more URLs for each applicable property. The URLs
point to the data sources.
When Entrust IdentityGuard needs to access a data source, it tries the first URL in the
list (known as the primary source). If the connection succeeds, Entrust IdentityGuard
uses it until it fails. When the primary fails or is unavailable, Entrust IdentityGuard tries
the second URL in the list. If it fails or is unavailable, Entrust IdentityGuard tries the
next URL, and so on. In failure cases, Entrust IdentityGuard always restarts at the
primary source and traverses the URL list until it makes a valid connection. During the
traversal, the connection that caused the original failure is skipped.
Directory failover
You can configure LDAP-compliant directory failover to ensure there are backups if
the primary directory fails. To configure failover, use the Properties Editor to specify
multiple LDAP URLs in the Entrust IdentityGuard properties file.
To configure failover for a directory, see the Entrust IdentityGuard Administration
Guide.
There are two directory failover scenarios:
local
geographically dispersed
89
Feedback on guide
Local directory failover
In this scenario, the users are likely in one office or city. If the primary Entrust
IdentityGuard Server fails, the load-balancer will redirect users 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.
Figure 17: An example of a local directory failover scenario
Geographically dispersed directory failover
This scenario demonstrates how you can deploy failover for Entrust IdentityGuard
users in two different cities (for example, Los Angeles and New York). Each citys
Entrust IdentityGuard Server is connected to its own directory. If the directories in Los
Firewall
Client
Primary Entrust
IdentityGuard
Server
Replica Entrust
IdentityGuard
Server
Primary Master
Directory (with read /
write access)
Secondary
Master
Directory
(with read/
write access)
Synchronized
(Real -time
Replication)
Load -balancer
Shared
Disk
90
Feedback on guide
Angeles fail, the Entrust IdentityGuard Server in Los Angeles can connect to the New
York directories.
Figure 18: An example of a geographically dispersed failover scenario
Database failover
You can configure database failover to ensure there are backups if the primary
database fails. To configure failover, use the Properties Editor to specify multiple
database URLs in the Entrust IdentityGuard properties file. If the primary Entrust
IdentityGuard Server fails, the load-balancer will redirect users to the replica.
91
Feedback on guide
To configure failover for a database, see the Entrust IdentityGuard Administration
Guide.
Figure 19: An example of a database failover scenario
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 serverand Radius server failover is
configuredEntrust IdentityGuard Radius proxy uses the next URL address in a list
(for the next request that it receives) and the current request times out. When the
Entrust IdentityGuard Radius proxy reaches the end of the list of URL addresses, it will
start at the beginning of the list again.
To create the list of Radius server IP addresses, see the Entrust Administration Guide.
Firewall
Client
Primary
Entrust
IdentityGuard
Server
Replica
Entrust
IdentityGuard
Server
Database
Database
Load -balancer
Synchronized
92
Feedback on guide
Figure 20: An example of a Radius server failover scenario
Firewall
Primary
Entrust
IdentityGuard
Server
Replica Entrust
IdentityGuard Server
Entrust
IdentityGuard
Radius proxy
Entrust
IdentityGuard
Radius proxy
VPN device
Client
Primary
Radius server
Secondary
Radius server
Primary
Radius server
Secondary
Radius server
93
Feedback on guide
Switching over 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 with the additional authentication challenges.
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 organizations Intranet
or as an Interactive Voice Response (IVR) system.
94
Feedback on guide
95
Chapter 5
Deploying grid authentication
This chapter provides deployment information for grid authentication. Most of the
information applies to the deployment of grids, but you should also read this chapter
if you are deploying passcode list authentication.
Grid requirements on page 96
Challenge requirements on page 99
Grid production models on page 101
Physical card security on page 109
Physical card production options on page 110
Secure file transmission on page 115
Automating processes on page 116
96
Feedback on guide
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 users.
Grid size and format on page 96
Grid lifetime and replacement on page 97
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 organizations policies. Although both are configured, the
grid size has more impact on security than the format of cell contents. (Do not
confuse grid size with challenge sizethe number of cells presented to the user at
authentication.)
Grid size impact
The more cells in a grid, the better the resistance to an attacker who has gained some
knowledge of a users grid through impersonation.
For example, if an attacker successfully captures one successful login with three
coordinates, they are 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 167.
Note: It may be appropriate within a user population to deploy various grid sizes
depending on the frequency of use and the transaction risk. Entrust
IdentityGuard supports this approach by allowing you to set up users in groups.
See Group requirements on page 74.
Grid format impact
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.
97
Feedback on guide
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,
however if the grid uses single alphanumeric characters instead, 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.
Table 17 lists the policy considerations related to grid size and format.
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 grids effectiveness. Therefore, replace Entrust IdentityGuard grids
periodically to provide continuous protection of your users identities. 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 74). By configuring the grid lifetime and replacement
policies, you can configure Entrust IdentityGuard to address identity fraud risk on a
per group basis, where groups get new cards more or less frequently depending on
the risk.
Table 17: Policy considerations associated with grid size and format
Policy consideration Recommendations
Rows and columns in grid Maximize the number of rows and columns within physical
form and usability constraints.
Characters in grid Use single alphanumeric characters.
Characters per cell Use one character per cell for maximum usability.
Characters that can replace other
characters
Consider having replacement characters for:
characters that are easily confused with others (for
example, the letters U and V, or the letter O and the
number 0)
uppercase and lowercase characters (such as A and a)
98
Feedback on guide
Table 18 lists the policy considerations related to grid lifetime and replacement.
Table 18: Policy considerations associated with grid lifetime and replacement
Policy consideration Recommendations
Lifetime based on time or usage? If your users authenticate infrequently, base the
lifetime of the card on time.
In higher-risk or transaction-intensive situations,
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. Build automated
systems to scan the log file for replacement warnings,
or use the Administration interface to search for card
grids that are nearing expiry or usage thresholds and
initiate the replacement process.
Ensure your 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 users
identities when they call to report an expired card. For
more information, see Entrust IdentityGuard users
on page 33.
99
Feedback on guide
Challenge requirements
This section focuses on the factors to consider before determining what type of grid
challenge best suits your security needs and your users.
Challenge size on page 99
Challenge algorithm on page 100
Challenge size
You can configure the size of the Entrust IdentityGuard challenge (the number of cells
in a grid 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 attackers application, they would be giving away twice as much grid data
with a challenge size of six coordinates as with three coordinates. The more
data that is given away, the more quickly an attacker will gather enough data
to answer a challenge from the legitimate application.
The challenge needs to be of a minimum size to reduce the probability that
an attacker can guess some or all of the challenge coordinate responses.
For example, assume an attacker successfully captures 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 size of two, the attacker has a much better chance of obtaining the
remainder of the challenge by guessing than if the challenge size was four,
especially since the Entrust IdentityGuard lock-out feature limits the
authentication attempts.
Find a balance between the minimum and maximum constraints when you
set the optimal challenge size for a given grid size.
For most applications, the optimal challenge size is three. This number
provides the best overall resistance to an attacker guessing remaining
challenge coordinates across a range of observed authentications.
Varying the grid challenge size
Through policy settings, you can present a different number of grid challenges based
on the type of access or transaction the user requires and the risk associated with the
site. For example, access to an internal company intranet portal could require three
grid coordinates while access to an external Web-based investment site could require
four coordinates.
100
Feedback on guide
Challenge algorithm
Entrust IdentityGuard includes two types of challenge generation algorithms for grid
authentication:
Random picks cells randomly when creating a challenge (this is the default).
The process for creating one challenge does not depend on previous
challenges.
Least-used uses a configured number of least-used cells in every challenge.
You can set the policy to use one least-used cell per challenge up to the entire
challenge.
By generating challenges using the least-used cells from an users 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 97).
101
Feedback on guide
Grid production models
At a high level, Entrust IdentityGuard grid and passcode list production requires the
following activities:
In an LDAP directory environment, the user must already exist in the
directory.
Create the user in Entrust IdentityGuard.
Generate grid (or passcode list).
Assign grid (or passcode list) to user.
Produce a physical card containing the grid (or passcode list).
Entrust IdentityGuard provides two models for grid production: a produce-and-assign
model and a preproduction model.
The produce-and-assign model involves generating a grid for each user as
needed. The produce-and-assign model is suitable for situations where the
user is already known to the organization and already exists in the repository.
The preproduction model involves generating cards in bulk and then
assigning them 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 21, the order in which these activities occur varies between the
produce-and-assign model and the preproduction model.
Figure 21: Grid production models
These two models are not mutually exclusive. For example, an organization may use
the preproduction model for new users and use the produce-and-assign model for
1. User exists in
primary
application
2. User created
in Entrust
IdentityGuard
3. Grid
generated for
user
4. Card
produced
1. Grid
generated
2. Card
produced
3. User exists in
primary
application
4. User created
in Entrust
IdentityGuard
5. Grid assigned
to user
Produce-and-assign model
Preproduction model
102
Feedback on guide
existing users. The organization could also use the preproduction model for Entrust
IdentityGuard card replacement.
Produce-and-assign model on page 102
Preproduction model on page 106
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 Create
User 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 a grid has
already been created and assigned to a user 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 enrollment 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 102
Produce-and-assign grids for new users on page 104
Produce-and-assign grids for existing users
Follow this procedure if you are using the produce-and-assign model for existing
users.
103
Feedback on guide
Figure 22: Grid production for produce-and-assign model (existing users)
To produce-and-assign grids for existing users
1 Ensure the users already exist in the Entrust IdentityGuard repository.
2 Extract a list of the users from the repository who are to receive cards.
3 Import the list of users into Entrust IdentityGuard and generate the grids for those
users. For detailed instructions, see 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 115.
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 (Optional) Based on the list of user IDs exported, access other corporate
repositories to obtain the name and mailing information of the selected users.
7 (Optional) Export the user information into a second file.
7. Extract user
information into
second file
2. Extract list of
users
3. Generate
grids
4. Export
production file
8. Merge two
files to create
production file
9. Review and
deal with errors
5. Securely
transmit file to
card producer
Optional steps required
if user delivery
information is not in
Repository.
1. Entrust
IdentityGuard
Repository
6. Other repository
104
Feedback on guide
8 (Optional) Merge the two files together to create the Entrust IdentityGuard
production file containing the user information and associated grid information.
9 Report the exceptions in which user information cannot be found for a user, and
resolve them in a separate process.
10 Complete the enrollment process with Delivery and activation on page 137.
Produce-and-assign grids for new users
Implement the following steps if you are using the produce-and-assign model for
new users.
Figure 23: Grid production for produce-and-assign model (new users)
To produce-and-assign grids for new users
1 Ensure the user exists in the primary applications repository. This repository also
serves as the Entrust IdentityGuard repository.
2 Request the cards for the new users, using one of the following three methods:
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 enrollment process is
handled as an over-the-counter service, and 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.
2a. Administrator
requests card
3. Generate
grids
1. Entrust
IdentityGuard
Repository
2b. User logs in
and requests
card
2c. Cards
requested in bulk
4. Export
production file
5. Securely
transmit file to
card producer
105
Feedback on guide
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:
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.
c 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 to select users for
whom Entrust IdentityGuard cards will be issued. For each user, the extracted
information must contain the user name and delivery information. The
delivery information depends on the delivery method. For more information
see Delivery and activation on page 137.
3 Entrust IdentityGuard generates and assigns a grid to each user name.
4 An administrator exports the Entrust IdentityGuard production file. It contains:
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 into a single file.
5 Produce the cards.
Send a production file to an application for card production and subsequent
delivery. For details, see Physical card production options on page 110.
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 enrollment. The enrollment
process should take only a few minutes and the Entrust IdentityGuard card
would be handed to the user on the spot.
6 Complete the enrollment process with Delivery and activation on page 137.
106
Feedback on guide
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. A grid is assigned to a user at some
point during the user 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. See User life cycle management on page 129.
Figure 24 shows the steps involved in the generation of the Entrust IdentityGuard
production file for the preproduction model. In this model, anonymous grids are
created. Grid assignment happens later 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. At such a
Web site, you 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 the 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 in person. 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.
Figure 24: Grid production for preproduction model
To preproduce grids
1 Create a set of Entrust IdentityGuard grids and assign the grids to a particular user
group. For information about where preproduced grids are stored, see
Repository on page 29.
4. Card creation and delivery
6. Create user,
select card,
assign grid
2. Export
production file
3. Securely
transmit file to
card producer
1. Generate
grids and store in
repository
5. Entrust
IdentityGuard
Repository
107
Feedback on guide
The only information generated after 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.
For information on exporting grids, see the Entrust IdentityGuard Administration
Guide.
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 115.
4 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.
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 If you use an LDAP-compliant directory as the Entrust IdentityGuard repository,
ensure the user entry exists in the directory.
6 Create the user in Entrust IdentityGuard, select the card and assign the grid to the
new user, using one of the following methods:
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
enrollment process is 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) to register the grid. When registering the grid, the user
provides the cards serial number, which is used to assign the grid to the user.
Login to the Web application is performed using a current user name and
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 sent with the card.
108
Feedback on guide
Entrust IdentityGuard generates and assigns a grid to each user name regardless
of where the request originated.
Forcing card activation
When new Entrust IdentityGuard users are first assigned cards, they can continue to
log into your system using just their user name and password until they activate
through Entrust IdentityGuard. This gives users a grace period between the time the
cards are mailed and when they are received. However, users can ignore the card
enrollment process and continue to log in without using the cards even after they
arrive. This represents a way to avoid second-factor authentication.
Entrust IdentityGuard lets you specify through a policy setting that new users must
activate their new cards within a certain period of time. After the date implied by the
grace period, their first-factor authentication access is blocked until they activate their
card. Once they have activated the card, they can never use just first-factor
authentication again.
109
Feedback on guide
Physical card security
Entrust IdentityGuard can be deployed in several ways, although the majority of
deployments will use a standalone physical card for a unique grid.
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 dont
reduce usability).
Consider adding a feature to your application to display the users last
successful login time and date. If this information does not match the users
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.
110
Feedback on guide
Physical card production options
You can choose from two basic options for card production:
in-house ( In-house card production on page 110)
outsourced ( Outsourced card production on page 111)
If there is no existing card production process, or the existing process is unsuitable,
Entrust can help with its own card production service capability. See Entrust
IdentityGuard card production on page 112 for more information.
Note: For users who are visually impaired, you can produce the cards with Braille
characters. If you do produce cards with Braille characters, ensure that your
application does not conceal challenges (such as presenting challenges as
images), but presents the challenges in machine-readable text.
Also see Card production cost factors on page 113 and Delivery and activation
on page 137.
In-house card production
Use the in-house approach if you are 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):
used for Enterprise deployments where card production already exists
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 for users.
Ensure secure intra-departmental transmission capability
111
Feedback on guide
for Entrust IdentityGuard card generation information
for Entrust IdentityGuard card distribution (over-the-counter or internal
corporate mail)
Process
The following process steps are required with in-house Entrust IdentityGuard card
production. (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 in a secure manner. See Secure file transmission on page 115.
2 Analyze the Entrust IdentityGuard production file and select the appropriate card
or paper stock for printing.
3 Produce the Entrust IdentityGuard cards.
4 Notify the 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, you can use the companys internal mailing information.
5 Activate the grid in one of two ways:
Have an administrator authenticate the user face-to-face at the
over-the-counter service desk.
Have the user follow the activation instructions contained in the Entrust
IdentityGuard card mailing.
Outsourced card production
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 18).
For quantities up to 1000, you can use the Entrust IdentityGuard Card Production
Service. For more information on this service, see Entrust IdentityGuard card
production on page 112.
If you already use an outsourced card production facility, negotiate the contracts and
service level agreements, and update the facility with the new requirements and
procedures for transmitting card and user data.
Typical Characteristics
The following are general characteristics of deployments involving outsourced card
production:
112
Feedback on guide
The organization does not have an internal card production capability or
elects not to use the internal capability.
The organization is a large, geographically dispersed company.
Setup
The following areas need to be addressed prior to starting any outsourced Entrust
Select a card production facility for Entrust IdentityGuard card production
and distribution (Entrust can recommend a card production partner).
Create card production partner agreements.
Write a welcome letter and activation instructions for users.
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 production file and select the appropriate card or paper stock for
printing.
3 Analyze the production file for personalization information to be printed on the
individual Entrust IdentityGuard cards.
4 Analyze the production file for card shipping instructions.
5 Produce the cards and insert them into addressed envelopes for distribution.
6 Distribute the cards using the shipping instructions provided in the production
file. You can ship the cards to the user directly, or distribute the cards from a
central location (such as a service desk).
7 The user follows the activation instructions contained in the card mailing.
113
Feedback on guide
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
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
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 set up a quick pilot deployment.
The organization does not need many cards (1000 cards or less)
Setup
Before starting any Entrust IdentityGuard card production, you must select one of
three card options:
a generic card with a preproduced grid
a generic card with a customer-assigned grid
a customer card with a customer-assigned grid
For more information on this topic, see the Entrust IdentityGuard Card Production
Service User Guide.
Card production cost factors
There are many factors that influence the cost of Entrust IdentityGuard card
production. Table 19 describes a few of these factors.
Table 19: Factors that influence the cost of card production
Card/paper quality The cost increases as the card thickness increases.
Removable scratch covers increase cost.
Card volume Higher volumes cost less per card.
Branding detail (logos,
colors)
More colors and complex graphics increase costs.
114
Feedback on guide
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.
Personalization requires the protection of personal information,
which may increase the cost because 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 remote geographical locations all affect costs.
Table 19: Factors that influence the cost of card production (continued)
115
Feedback on guide
Secure file transmission
Ensure that the Entrust IdentityGuard production file and any personal information
(for example, name and address) of the user is transferred securely. The following
sections describe several transmission technologies.
Secure Sockets Layer
The Entrust IdentityGuard Card Production Service provides an SSL (Secure Sockets
Layer)-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 employ and uses well-understood technology.
Secure email
You can transmit the Entrust IdentityGuard production file as an attachment in a
secure email 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 email to
validate your identity. This technique is simple to employ and uses well-understood
technology, if you have a secure email 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 email, 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, email, or FTP), because 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 for the Entrust
IdentityGuard production file, but this technique 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).
116
Feedback on guide
Automating processes
To enhance the existing functionality of Entrust IdentityGuard and facilitate
deployment, the following list and highlights areas that are candidates for
automation. Actual implementation details will differ depending upon your specific
requirements and environment.
Entrust IdentityGuard provides a mechanism for exporting cards in XML or
CSV format for existing users. To automate this export, an application
exports the grid information to an XML file. The application could run
unattended as a batch job, and also encrypt the XML information for secure
transfer. Additional functionality to manipulate the format of the file or add
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, you could write a
generic application to extract user information 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 users full name and mailing
information.
Bulk user creation abilities and an automated application allows 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 detailing users with cards in different card states. You
can run this reporting application unattended as a batch job at any time. For
information on the card states, see the Entrust IdentityGuard Administration
Guide.
Entrust IdentityGuard provides interfaces for administrators to perform user
management activities, and APIs that you can use to build a self-service
application for users. User life cycle management on page 129 describes
the process models for user self-service; write a Web application to support
this model using the Entrust IdentityGuard Administration API. For more
information, see the Entrust IdentityGuard Programming Guide that applies
to your programming language (Java Platform or .NET).
117
Chapter 6
Deploying token authentication
This chapter provides deployment information for token authentication.
Using tokens for authentication on page 118
Token deployment on page 119
Physical token security on page 120
118
Feedback on guide
Using tokens for authentication
Users can authenticate to Entrust IdentityGuard using tokens. Once Entrust
IdentityGuard and users are set up to accept tokens, users must enter a dynamic
password (the random number generated by a token device) in response to an
Entrust IdentityGuard token challenge.
Your application is not limited to one type of token or one token vendor. You can
configure Entrust IdentityGuard to use a wide range of tokens. The default
installation of Entrust IdentityGuard supports Entrust tokens. Different token types
can be available to your users, though you cannot assign (current and pending)
tokens from two different vendors to an individual user at the same time.
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 with 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.
For more information on token states, see the Entrust IdentityGuard Administration
Guide.
Entering token values
The users token device generates the dynamic password (a number) that a user
enters at the challenge. Entrust IdentityGuard checks if the dynamic password is valid
and, if it is, authenticates the user.
A token response to a challenge always includes the dynamic password. When
supported by the token device, the challenge can also include a personal verification
number (PVN). See Using personal verification numbers on page 62.
A PVN consists of a string of numeric characters that users must enter with their
dynamic password when challenged by Entrust IdentityGuard. For example, if the
users PVN value is 1234, and the dynamic password value is 789789, the user must
enter 1234789789 as the authentication challenge response.
119
Deploying token authentication
Feedback on guide
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 data file. You add tokens to an Entrust IdentityGuard repository by
importing the token manufacturer's data file. Once the token data is loaded, you
supply token devices and assign token serial numbers to your users.
When the data file is loaded into the repository, the tokens are loaded as unassigned
tokens. Tokens must be assigned before they can be used for authentication.
Assigning tokens
A master user or administrator assigns tokens to users. Tokens have the same states
as cards (pending, hold_pending, current, hold and canceled). Only tokens that are
in the pending and current states are used for authentication. Token states have the
same transition behavior as for cards. For more information on token states, see the
Entrust IdentityGuard Administration Guide.
User tokens do not have an expiry date or a superseded date. Any token can be
unassigned and added back to the unassigned tokens list.
Token self-activation
Users can activate their own tokens. 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 activated. If the
authentication fails, the token is unassigned.
Forcing token activation
When new Entrust IdentityGuard users are first assigned tokens, they can continue to
log into your system through their VPN or other connection using just their user name
and password until they activate through Entrust IdentityGuard. This gives users a
grace period to allow time for tokens to arrive by mail. However, users can ignore the
activation process and continue to log in without using the tokens even after they
arrive. This is one way to avoid second-factor authentication.
Entrust IdentityGuard lets you specify through a policy setting that new users must
use their new tokens within certain period. After the date specified by the grace
period, their first-factor authentication access is blocked until they activate with the
token. Once they activate their tokens, they can never use just first-factor
authentication again.
120
Feedback on guide
Physical token security
Entrust IdentityGuard can be deployed in multiple forms, including a token
deployment.
When deploying tokens, it is recommended that you:
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 so that the application displays
the users last successful login time and date. If this information does not
match the users 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.
121
Chapter 7
Deploying knowledge-based
authentication
This chapter provides deployment information for knowledge-based authentication
(questions and answers). Typically, you integrate Entrust IdentityGuard with your
current knowledge-based authentication application.
To make it easier for users, you can use questions and answers for additional
authentication rather than for your main second-factor authentication method. For
Question requirements on page 122
Challenge requirements on page 126
Security considerations on page 128
Note: Many 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. 32-39, September-October, 2004.
122
Feedback on guide
Question requirements
This section provides you with information about how to create and select a set of
questions for your users to answer.
Sources of questions on page 122
Creating good questions on page 123
Selecting a set of questions on page 124
Sources of questions
There are several methods for developing the questions for knowledge-based
authentication. The methods are discussed in Table 20.
Table 20: Methods for generating knowledge-based questions
Method Considerations
Generated codes Examples include auto-generated PVNs, PINs, or TANs (transaction
numbers)
Represents a simple form of question
Applies to existing users and is extremely useful for encouraging
them to register for new services
Transaction data Examples include the date and balance of a recent statement.
Client applications must extract the data from an existing database
to form the questions
Permits an organization to use information that is already known
about users as a part of knowledge-based authentication.
Requires client applications to use Entrust IdentityGuards
Administration API (see the Entrust IdentityGuard Programming
Guide for more information). 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 18.
Prepopulated lists May be necessary to have users register their own questions and
answers. It is recommended that your application present users with
a stock list of questions from which they make selections and provide
answers.
Gives your organization control over the questions to ensure they
meet criteria for privacy, security, and usability. See Creating good
questions on page 123.
123
Deploying knowledge-based authentication
Feedback on guide
Creating good questions
The questions you choose have a direct impact on how successful your
knowledge-based authentication implementation will be. Measure the questions you
select against the criteria discussed in Table 21.
User-generated Allows users to enter their own question-and-answer challenges (not
recommended).
Users generally do not write well-formed questions.
Users tend to forget the answers to their own questions more
frequently than stock questions.
In a design that uses multiple question-and-answer sets, it may make
sense to allow one question and answer that is composed entirely by
the user.
Table 21: Knowledge-based authentication criteria
Criteria Considerations
Privacy Organizations are subject to legislation and regulations relating to
the collection, storage, control, and handling of personal
information.
It is prudent to avoid 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. Identity thieves regularly find
or steal personal information, rendering the reliability of personal
information almost useless.
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.
Table 20: Methods for generating knowledge-based questions (continued)
Method Considerations
124
Feedback on guide
Sample questions
The following are some examples of good questions:
Who did you go to the prom with?
Who did you want to go to the prom with?
What was the name of your childhood best friend?
What was the name of you childhood worst bully?
What was the name of your favorite childhood toy?
What was the name of your first girlfriend/ boyfriend?
What was your first car?
What was your first injury?
What was your high school mascot?
Which magazine do you read most often?
What was the name of your first roommate?
Which sports team did you like most as a child?
As a child, what did you want to be when you grew up?
As a child, what was your dream car?
Selecting a set of questions
A common practice is to interact with the user to create several question-and-answer
sets during the enrollment process, then use a randomly selected subset for
Usability Knowledge-based authentication must be simple and easy for users
to use.
The questions should have a wide applicability to the organizations
users. For example, the question What is the name of my first pet?
only applies to pet owners.
An answer must be easily recalled for the question to be useful.
Questions that reflect users habits, regular activities, or practices
generally meet this criteria.
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.
A user must be able to enter a correct response each time. This is
discussed under Challenge accuracy on page 126.
Table 21: Knowledge-based authentication criteria (continued)
Criteria Considerations
125
Feedback on guide
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.
For usability reasons, users will not tolerate answering a large number of questions
for enrollment 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
systems resistance to attack by making it more difficult for an attacker to anticipate
a given users questions. It is recommended that a user answer a minimum of five
questions (seven is better).
To make it easier on users, you can use questions and answers for additional
authentication rather than as your main second-factor authentication method. For
126
Feedback on guide
Challenge requirements
This section focuses on the items to consider before determining what type of
knowledge-based challenge best suits your security needs and your users.
Challenge size
You may want a different number of questions presented based on the type of access
or transaction the user requires. For example, access to a company information portal
could require two questions while access to a online investment site could require four
questions. It is recommended that a user answer at least three questions.
You set the minimum and maximum number of required questions in Entrust
IdentityGuard policy, and then set the exact number of questions for each
authentication scenario in your application. Your application must present a number
of questions between the minimum and maximum, and take into account the number
of wrong answers allowed (if applicable).
Challenge accuracy
Once you have determined how many questions a user must answer to authenticate,
you must determine how accurate a users answers must be.
Setting how many correct answers are required
Entrust IdentityGuard provides flexibility in the number of questions a user must
answer correctly. You can make it mandatory that all questions be answered correctly,
or you can allow room for error. For example, you can determine that three out of
four correct answers represents a successful authentication.
Setting the accuracy of answers
By default, Entrust IdentityGuard lets you compensate for close answers, common
abbreviations and misspellings of common words (for example, St. and Street )
with a word map file. You can edit this word map file over time. (For more information
on the word map file, see the Entrust IdentityGuard Administration Guide.)
However, you can also disable the use of a word map file and require exact answers.
In this case, the only leeway Entrust IdentityGuard allows is differences in
punctuation, letter case, and spacing. Entrust IdentityGuard also applies a character
map to support special characters (such as accented characters).
If you take the exact-answer approach, your application should employ the following
techniques to improve the chances of receiving an exact match:
Standardize responses.
127
Feedback on guide
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.
Allowing a word map (inexact answers) can eliminate most of these
problems.
Validate the answer set.
You should include rules-based post-processing of the answers given during
enrollment to ensure answer quality. Your application can reject answers that
do not fit your rules and prompt the user for a better answer. For example,
your application should reject:
sequential keyboard sequences (such as qwertyuiop)
repeated characters (such as aaaaaaaa)
answers that repeat the question
the same answer to different questions
128
Feedback on guide
Security considerations
Entrust IdentityGuard can be deployed in multiple ways, including a
knowledge-based deployment.
It is recommended that your organization employ the following security precautions:
Users should not save their questions and answers to an electronic file onto
their computers or a portable device (such as a compact disc or USB drive).
An attacker could use the answers in the file to impersonate the user.
Users should not write their questions and answers on a physical medium
(such as paper) where someone else can find the answers. An attacker could
memorize or steal the answers to impersonate the user.
Consider adding a feature to your application where the application displays
the users last successful login time and date. If this information does not
match the users personal experience, this will alert the user that some form
of attack may have occurred.
Define a user policy and educate users on appropriate knowledge-based
questions and answers to prevent users from unwittingly exposing their
authentication data to an attacker, both physically and electronically.
129
Appendix A
User life cycle management
This appendix provides information on the Entrust IdentityGuard user life cycle.
This appendix contains the following sections:
Life cycle management overview on page 130
Enrollment on page 132
Usage on page 133
Renewal on page 134
Replacement on page 135
Delivery and activation on page 137
Maintenance on page 139
130
Feedback on guide
Life cycle management overview
This section describes the high level processes for managing the life cycle of Entrust
IdentityGuard 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 the organizations
procedures for managing user accounts.
User life cycle management consists of the following stages and processes:
enrollment
This is the initial stage where users enroll for the Entrust IdentityGuard
service. See Enrollment on page 132.
usage
This is the normal operations stage where users login to your organization
through Entrust IdentityGuard. See Usage on page 133.
renewal
This is an ongoing stage where users are issued new Entrust IdentityGuard
grids (on new cards), tokens, one-time passwords, personal verification
numbers (PVN) or questions to replace older ones. See Renewal on
page 134.
replacement
This covers the handling of
lost, stolen, damaged, and left behind Entrust IdentityGuard cards,
passcode lists, or tokens
forgotten answers, PVNs, and one-time passwords
Users are issued temporary PINs (if using cards, lists, or tokens) or one-time
passwords, or receive replacement Entrust IdentityGuard cards, lists or
tokens. See Replacement on page 135.
delivery and activation
This describes the processes to physically deliver Entrust IdentityGuard cards,
passcode lists, or tokens and activate the authentication method for each
user. It does not apply to the nonphysical authentication methods, such as
knowledge-based questions and answers, or one-time passwords. See
Delivery and activation on page 137.
maintenance
This describes the processes to
Remove stale or idle cards or tokens from the Entrust IdentityGuard system.
This includes cards, lists or tokens that are cancelled, never activated, or
unassigned, as well as those assigned to terminated user accounts.
Update graphics or images used for organization authentication.
131
Feedback on guide
Update personal verification numbers (PVN).
Update IP geographical data.
See Maintenance on page 139.
132
Feedback on guide
Enrollment
Enrollment is the first stage of the life cycle. In this stage:
Users are registered in the Entrust IdentityGuard system.
Users are assigned and provided with an Entrust IdentityGuard
authentication method (such as a card or token).
Users activate the authentication method.
For enrollment, ensure you have processes and procedures in place to create and
manage user accounts and to issue the authentication credentials (such as user names
and passwords). Depending on the authentication methods assigned to users, the
following are examples of events that may occur:
Entrust IdentityGuard grids are assigned to users and Entrust IdentityGuard
cards are produced.
Microsoft Windows desktop users install Entrust IdentityGuard Desktop for
Microsoft Windows.
Tokens are assigned to users and mailed to them, along with activation
instructions.
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.
To make sure new card and token users enroll promptly, use the search function in
the Administration interface to find users whose activation grace period is about to
expire. See Forcing card activation on page 108 for more information. The same
mechanism applies to tokens.
If you are using cards, passcode lists, or tokens, complete the enrollment process with
Delivery and activation on page 137.
133
Feedback on guide
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 challenge (for example, three incorrect responses). This is
necessary to protect against a brute force attack in which an attacker attempts to log
in by repeatedly guessing 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
help desk procedures for this situation to ensure that proper identity verification is
performed before unlocking an users account.
134
Feedback on guide
Renewal
You should ensure users renew their authentication data (such as their passwords,
tokens, cards, PVNs, and knowledge-based information) on a regular basis. Once the
data expires or exceeds a usage period, make sure users are able to renew the data
promptly so that they 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
users are directed to change their PVN
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 25 illustrates the high level process steps for renewal.
Figure 25: Enterprise renewal
To renew a users authentication data
1 Extract 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 Generate and assign new authentication data.
For grids, one-time passwords, and passcode lists, Entrust IdentityGuard
generates and assigns new authentication data (such as a 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 95.
135
Feedback on guide
4 If you are using cards, passcode lists, or tokens, complete the renewal process
with Delivery and activation on page 137.
136
Feedback on guide
Replacement
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 provide users with the access
they need until replacement data is in their possession.
For lost cards, passcode lists, or tokens, you can use the Entrust
IdentityGuard system to provide a temporary PIN on an as-required basis.
For other types of authentication data (such as knowledge-based or
one-time passwords), your application needs to provide some means for a
user to request new passwords or hints to answers.
Figure 26 illustrates the high level process steps for replacement.
Figure 26: Enterprise replacement
To replace a users authentication data
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)
137
Feedback on guide
In the self-service approach, the user has access to a self-recovery
application. The application performs an identity verification procedure,
possibly using knowledge-based authentication, to ensure that the request is
legitimate. The questions and answers for recovery must have been created
by the user during the enrollment process or through a separate application
after enrollment.
central service recovery (identity verification)
In the central service approach, the user calls the service desk and requests
recovery of the authentication data. 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 a temporary
authentication method. If provided by an application, ensure that the
information is displayed in nonmachine-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 temporarily suspended.
Attention: The cancellation process is irreversible for cards, passcode lists or
tokens. They can never be used again.
For information on temporary PINS, see Temporary PIN authentication on
page 61.
If using out-of-band authentication, a one-time password should be
generated. Generating a new one-time password cancels the old one-time
password.
If using knowledge-based authentication, give hints that the user provided
during registration. If the hints dont help, issue a one-time password so 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 or image replay authentication, it is recommended
that, if the information is permanently forgotten, the user reset their
information through a secure Web page (such as one located on your
Intranet). Optionally, they can enter a one-time password in order to verify
138
Feedback on guide
their identity when accessing the page, or call 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 137.
139
Feedback on guide
Delivery and activation
Delivery and activation processes are common to the enrollment, renewal and
replacement life cycle stages for cards (grids and passcode lists) and tokens. After
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 delivery methods.
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 for managing inventory.
Figure 27 illustrates the high level process steps for delivery and activation.
Figure 27: Enterprise delivery and activation
To deliver and activate a users authentication data
1 Cards and tokens can be delivered in two ways:
using an over-the-counter service for immediate service
This involves 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.
using a central service that responds to user requests
Administrators can be given the option of mailing the card or token directly
to the user.
2 If you are using a central service, the user must visit the service desk where
personalization procedures are performed. You can require the service desk to
From
enrolment ,
replacement ,
or renewal
Deliver card or
token to user
Deliver card or
token to central
service desk
User pickup
(Verify identity,
personalization )
Activate
authentication
method
140
Feedback on guide
verify the persons identity to ensure that the card or token is delivered to its
rightful owner.
3 Activate the card or token using the authentication application. You can use an
over-the-counter approach or a self-activation approach.
In an over-the-counter approach, the administrator can activate the Entrust
IdentityGuard card or token immediately before handing it to the user.
In a self-activation approach, the user initiates the activation by using the
Entrust IdentityGuard card or token in an authentication transaction. This can
be as simple as using the Entrust IdentityGuard card or token on the next
login.
For the activation procedures you deploy, take into account the requirements for
capturing information for self-service card or token replacement (see
Replacement on page 135).
141
Feedback on guide
Maintenance
Maintenance procedures are required to remove stale or idle data from the Entrust
IdentityGuard system. Ensure that an Entrust IdentityGuard administrator regularly
performs the following maintenance tasks.
Remove cancelled cards and tokens
The renewal and replacement stages result in old Entrust IdentityGuard cards and
tokens being replaced by new ones. At the time the new card or token is activated,
the old one is cancelled.
Cancelled cards and 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 cards and tokens on a periodic basis
whether or not archives need to be retained and, if so, for how long
Remove inactive cards and tokens
Organizations should not encounter many Entrust IdentityGuard cards and tokens
that were never activated, although they can get lost in transit. Users are expected to
notify the service desk in such circumstances. A replacement card or token would be
issued and the inactive card or token cancelled.
The Entrust IdentityGuard administrator can check for items that were never
activated on a periodic basis to ensure that they are either activated by the rightful
owner or cancelled.
Remove unassigned cards and tokens
Tokens and cards 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 cards 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.
Synchronize with the repository
Coordinate maintenance activities between the Entrust IdentityGuard administrator
and the repository administrator. In particular, when user accounts are terminated,
the associated Entrust IdentityGuard information should be removed.
142
Feedback on guide
Update images used for mutual authentication
You should occasionally change the images users can select for image-replay mutual
authentication. This makes it harder for attackers to spoof your site.
Update personal verification numbers
Each personal verification number (PVN) includes a last-used date. You can check this
date to find a list of users whose PVNs need replacing. You should require users to
change their PVN on a regular basis.
Update IP geographical data
You can download new IP lists from Entrust on a monthly basis. New IP data files are
also included in each patch. See the Entrust IdentityGuard Administration Guide for
more information on updating IP data files.
141
Appendix B
Entrust IdentityGuard baseline
architectures
This section outlines some baseline architectures and complements the information
about architecture and deployment provided in the other guides in the Entrust
IdentityGuard documentation suite.
See the Entrust IdentityGuard Administration Guide for more information on the
authentication issues that influence the choice of architecture and configuration of
your Entrust IdentityGuard solution.
Architecture overview on page 142
Web access on page 144
VPN remote access on page 148
Wireless access on page 153
Microsoft Windows remote access on page 156
Generic remote access on page 160
Microsoft Windows desktop on page 163
Note: Entrust Professional Services can provide more information on an
architecture suitable to your requirements. For contact information, see
Obtaining technical assistance on page 18.
142
Feedback on guide
Architecture overview
There are three levels of baseline architecture in this section: evaluation, standard and
high availability.
Evaluation
Evaluation-level architecture:
suits test and proof-of-concept environments
is designed to be low cost to implement, by minimizing the required
equipment
represents a limited environment that you can set up quickly for
proof-of-concept, investigation of functionality, and so on
is not intended for production purposes
Assumptions:
generally very small, ranging from a few users up to a hundred users
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
Standard-level architecture:
suits production implementations from pilot phase through initial rollout
lacks equipment redundancy; any standard environment should be
implemented with robust equipment to provide a moderately high level of
availability and performance
represents production environments suitable for a medium volume
environment
is more complex to set up than the evaluation architectures because of
firewalls and other security provisions
uses separate servers for each function to support higher throughput
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
143
Entrust IdentityGuard baseline architectures
Feedback on guide
limited provision for failover
a backup strategy is in place to ensure that the data stores and system disks
can be rebuilt in the event of a hardware failure (add a disk mirroring strategy
to reduce recovery time in the event of a disk failure)
an NTP service, connected to a trusted time source (such as a Stratum 1 or
Stratum 2 time server), is available to ensure clock accuracy for tokens (some
downtime is acceptable; no provision is made for replicated systems)
network architecture already in place
High availability
High availability architecture:
suits large scale production implementations that demand the highest levels
of availability and performance
expands upon the standard configurations by adding redundancy for both
high availability and scalability
is intended for production purposes in a high volume environment, whether
supporting internal or external users
Assumptions:
offers higher throughput than standard baseline architectures
includes redundant systems, links, trusted time sources, and data stores
is more complex to set up because of the significant provision for security,
performance, and availability
deployments are generally large, supporting millions of users
uses 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
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. Since this feature eventually
becomes the second-factor authentication repository, consider scaling the
second-factor authentication repository. Entrust IdentityGuard supports
users in multiple repositories.
144
Feedback on guide
Web access
You can deploy the Web access baseline architecture in an evaluation, standard or
high availability environment.
You can use any Entrust IdentityGuard authentication method when your users
access your organization using their Web browsers.
Web access - evaluation
Figure 28 illustrates how you can set up Entrust IdentityGuard to provide multifactor
authentication for your Web resources.
Figure 28: Web authentication evaluation architecture
Requirements
directory or database with user repository
Web server or application server running an application that controls
first-factor authentication (user name and password) and manages the
repository
client with Web browser
145
Feedback on guide
Web access - standard
The standard architecture, shown in Figure 29, extends the evaluation architecture
( Web access - evaluation on page 144) by:
adding firewalls that provide network segmentation for the authentication
and application systems
adding separate servers for the Web server and application server (consistent
with best practice for security, availability and performance)
adding a separate computer containing the Entrust IdentityGuard
Administration interface where administrators manage users
Figure 29: Web access standard architecture
Requirements
directory and/or database on a dedicated server for the user repository
application server running an application that completes first-factor
authentication (user name and password) and manages the repository
(Entrust IdentityGuard can manage first-factor authentication if required)
hard and soft firewalls creating a DMZ (demilitarized zone) for the Web
server, and protecting internal resources
146
Feedback on guide
Web server located in DMZ that relays information between the client, the
application server, and Entrust IdentityGuard Server
an administrator to manage Entrust IdentityGuard users
Web access - high availability
The architecture shown in Figure 30, extends the standard architecture ( Web access
- standard on page 145) 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 to provide high availability and performance.
Figure 30: Web access high availability architecture
147
Feedback on guide
Requirements
replicated directories and/or databases for the user repository, set up in a
high availability or disaster recovery cluster
Entrust IdentityGuard Servers
load-balancers to divide the load among the various Entrust IdentityGuard
Servers
replicated application servers that complete first-factor authentication (user
name and password) and manage the repository (alternatively, Entrust
IdentityGuard can manage first-factor authentication if required)
hard and soft firewalls creating a DMZ (demilitarized zone) for the Web
servers, and protecting internal resources
replicated Web servers located in DMZ that relay information between the
client, the application server, and Entrust IdentityGuard Server
administrators to manage Entrust IdentityGuard users
148
Feedback on guide
VPN remote access
You can deploy the VPN remote access baseline architecture in an evaluation,
standard or high availability environment.
You can use any of the following Entrust IdentityGuard authentication methods when
your users access your organization through VPN:
grid authentication
Entrust IdentityGuard password (first-factor) authentication
one-time password authentication
knowledge-based authentication
risk-based authentication
VPN remote access - evaluation
Use this architecture to evaluate how Entrust IdentityGuard can integrate with your
current VPN solution to provide multifactor authentication to remote users.
Figure 31: VPN remote access evaluation architecture
149
Feedback on guide
Requirements
directory or database with user repository
If using a database, you can install it on the same computer as the one
hosting Entrust IdentityGuard Server.
Entrust IdentityGuard Radius proxy, configured on the same computer as the
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 41); optionally, Entrust
IdentityGuard can also manage first-factor authentication
VPN device (IPsec or SSL)
client with VPN connection (dial-up, wireless, and so on)
VPN remote access - standard
The standard architecture, shown in Figure 32 on page 150, extends the evaluation
baseline architecture by adding firewalls (which provide network segmentation for
the authentication systems) and user administration.
150
Feedback on guide
Figure 32: VPN remote access standard architecture
Requirements
directory and/or database on a dedicated server for the user repository
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 41); optionally, Entrust IdentityGuard can manage first-factor
authentication
VPN device (IPsec or SSL)
client with VPN connection (dial-up, wireless, and so on)
hard and soft firewalls creating a DMZ (demilitarized zone) for the VPN
device, and protecting internal resources
151
Feedback on guide
VPN remote access - high availability
The architecture in Figure 33 extends the standard VPN remote access configuration
( VPN remote access - standard on page 149) by adding load-balancers, replica
Entrust IdentityGuard Servers, and replicated user repositories.
The network components (for example, VPN devices, routers, firewalls, and so on)
and first-factor authentication resources must be configured to provide high
availability and performance.
Figure 33: VPN remote access high availability architecture
Requirements
replicated directories and/or databases for the user repository, set up in a
high availability or disaster recovery cluster
Servers
152
Feedback on guide
Entrust IdentityGuard Radius proxies, configured on the Entrust
IdentityGuard Servers
a cluster of first-factor authentication resources, such as Radius servers,
domain controllers, or LDAP directories (see External authentication on
page 41); optionally, Entrust IdentityGuard can manage first-factor
authentication
VPN devices (IPsec or SSL)
clients with VPN connection (dial-up, wireless, and so on)
administrators to manage Entrust IdentityGuard users
hard and soft firewalls creating a DMZ (demilitarized zone) for the VPN
devices, and protecting internal resources
153
Feedback on guide
Wireless access
This architecture is not dependent on a specific platform for the access server. It only
requires that you have a wireless access point. You can deploy the wireless access
baseline architecture in an evaluation, standard, or high availability environment.
Since this architecture includes the Radius proxy, you can use these second-factor
authentication methods: grid, token, temporary PIN, OTP, and one
question-and-answer challenge. The token method can include a personal
verification number (PVN) challenge.
See Entrust IdentityGuard Administration Guide for supported deployments and
implementation details.
Wireless access - evaluation
Use this architecture to evaluate how Entrust IdentityGuard can provide multifactor
authentication for wireless users.
Figure 34: Wireless access evaluation architecture
Requirements
wireless access point
LDAP directory or database user repository
LDAP or database
repository
Server with Radius
proxy
Wireless access
point
EAP supplicant
154
Feedback on guide
Entrust IdentityGuard Server and the Radius proxy
Wireless access - standard
The architecture shown in Figure 41 extends the evaluation architecture by adding
user administration so that you can provide multifactor authentication to wireless
users in your organization.
Figure 35: Wireless access standard architecture
Requirements
distributed LDAP directory or database user repository
Firewall
EAP supplicant
Administrator
Server with Radius
proxy
Access server
supporting RAS and
EAP
Distributed LDAP or
database repository
155
Feedback on guide
Wireless access - high availability
The architecture shown in Figure 42 adds load-balancers, replica Entrust
IdentityGuard Servers, and replicated user repositories. It is assumed that network
components (access servers, routers, firewalls, and so on) and first-factor
authentication resources are configured to provide high availability and performance.
Figure 36: Wireless access high availability architecture
Requirements
replicated and distributed LDAP directory or database user repository
multiple Entrust IdentityGuard Servers with the Radius proxy
Server with Radius
proxy
Administrator
Firewall
Server with Radius
proxy
Distributed LDAP or
database repository
Load-balancing
cluster
Wireless access
point
EAP supplicant
156
Feedback on guide
You can deploy the Microsoft Windows remote access baseline architecture in an
evaluation, standard or high availability environment.
You can use the grid, token or temporary PIN authentication methods when your
users access your organization remotely through Microsoft Windows.
Microsoft Windows remote access - evaluation
Use this architecture to evaluate how Entrust IdentityGuard can add multifactor
authentication for Microsoft Windows remote users.
Figure 37: Microsoft Windows remote access evaluation architecture
Requirements
Active Directory with user repository
Domain controller (you can install it on the same machine as the user
repository)
Microsoft Routing and Remote Access Service (RRAS) with Internet
Authentication Service (IAS)
157
Feedback on guide
Entrust IdentityGuard Remote Access Plug-in for Microsoft Windows Server
installed on RRAS computer
client with Microsoft Remote Access capabilities
Microsoft Windows remote access - standard
The Microsoft Windows remote access standard architecture, shown in Figure 38,
extends the evaluation architecture by adding firewalls and user administration so
that you can provide multifactor authentication to the Microsoft remote users in your
organization.
Figure 38: Microsoft Windows remote access standard architecture
Requirements
distributed domain configuration with user repository
Firewall Firewall
Microsoft Remote
Access Client
Administrator
Server
Microsoft RRAS with
Remote Access Plug-in
Distributed domain
with Active Directory
158
Feedback on guide
installed on the IAS computer
hard and soft firewalls creating a DMZ (demilitarized zone) for the RRAS, and
protecting internal resources
Microsoft Windows remote access - high
availability
The architecture in Figure 39 on page 159 extends the standard Microsoft Windows
remote access configuration ( Microsoft Windows remote access - standard on
page 157) by adding load-balancers, replica Entrust IdentityGuard Servers, and
replicated user repositories.
The network components (for example, access servers, routers, firewalls, and so on)
and first-factor authentication resources must be configured to provide high
availability and performance.
Note: In any remote-access configuration shown in this section, you can set up
an architecture in which the IAS is enabled on a different computer than the
RRAS is. In that instance, you need to install the Remote Access Plug-in on the
computer hosting the IAS.
159
Feedback on guide
Figure 39: Microsoft Windows remote access high availability architecture
Requirements
distributed domain configuration with replicated user repository
load-balancers to divide the load between the Entrust IdentityGuard Servers
installed on the IAS computer
hard and soft firewalls creating a DMZ (demilitarized zone) for the Remote
Access Server, and protecting internal resources
160
Feedback on guide
Generic remote access
This architecture is not dependent on a specific platform for the access server. It only
requires that your remote client and access server support the Extensible
Authentication Protocol (EAP). You can deploy the generic remote access baseline
architecture in an evaluation, standard or high availability environment.
Since this architecture includes the Radius proxy, you can use these second-factor
authentication methods: grid, token, temporary PIN, OTP, and one
question-and-answer challenge. The token method can include a personal
verification number (PVN) challenge.
Generic remote access - evaluation
Use this architecture to evaluate how Entrust IdentityGuard can provide multifactor
authentication for remote users.
Figure 40: Generic remote access evaluation architecture
Requirements
an LDAP directory or database user repository
access server supporting Remote Access Service (RAS) and EAP
LDAP or database
repository
Server with Radius
proxy
Access server
supporting RAS and
EAP
Windows EAP client
161
Feedback on guide
remote Microsoft Windows client supporting EAP
Generic remote access - standard
The architecture shown in Figure 41 extends the evaluation architecture by adding a
firewall and user administration so that you can provide multifactor authentication to
remote users in your organization.
Figure 41: Generic remote access standard architecture
Requirements
distributed LDAP directory or database user repository
hard and soft firewalls creating a DMZ (demilitarized zone) for the RAS, and
protecting internal resources
162
Feedback on guide
Generic remote access - high availability
The architecture shown in Figure 42 adds load-balancers, replica Entrust
IdentityGuard Servers, and replicated user repositories. It is assumed that network
components (access servers, routers, firewalls, and so on) and first-factor
authentication resources are configured to provide high availability and performance.
Figure 42: Generic remote access high availability architecture
Requirements
replicated and distributed LDAP directory or database user repository
multiple Entrust IdentityGuard Servers with the Radius proxy
load-balancers to divide the load among the Entrust IdentityGuard Servers
Server with Radius
proxy
Administrator
Firewall
Server with Radius
proxy
Distributed LDAP or
database repository
Load-balancing
cluster
Access server
supporting RAS and
EAP
Firewall
Windows EAP client
163
Feedback on guide
hard and soft firewalls creating a DMZ (demilitarized zone) for the Remote
Access Server, and protecting internal resources
164
Feedback on guide
You can deploy the Microsoft Windows desktop baseline architecture in an
evaluation, standard or high availability environment.
You can use the grid, token or temporary PIN authentication methods when your
users access your organization through their Microsoft Windows desktop.
Microsoft Windows desktop - evaluation
This architecture (shown in Figure 43) demonstrates how you can use Entrust
IdentityGuard to provide multifactor authentication to Microsoft Windows users
when they log in to their computer.
Figure 43: Microsoft Windows desktop authentication evaluation architecture
Requirements
Active Directory with user repository
domain controller (you can install it on the same machine as the user
repository)
165
Feedback on guide
Entrust IdentityGuard Desktop for Microsoft Windows installed on a
computer
Microsoft Windows desktop - standard
The Microsoft Windows desktop standard architecture, shown in Figure 44, extends
the evaluation architecture by adding a firewall and user administration so that you
can provide multifactor authentication to the desktop users in your organization.
Figure 44: Microsoft Windows desktop standard architecture
Requirements
distributed domain configuration with user repository
firewall
Entrust IdentityGuard Desktop for Microsoft Windows installed on users
computers
166
Feedback on guide
Microsoft Windows desktop - high availability
The high availability grade baseline architecture, shown in Figure 45, 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 to provide high availability and
performance.
Figure 45: Microsoft Windows desktop authentication high availability architecture
Requirements
distributed domain configuration with replicated user repository
Servers
firewall
Desktop for Microsoft
Windows
Administrator
Firewall
Distributed domain
with Active Directory
Load-balancing
cluster
167
Feedback on guide
Entrust IdentityGuard Desktop for Microsoft Windows installed on users
computers or laptops
168
Feedback on guide
167
Appendix C
Card usability study
Entrust IdentityGuard was introduced to the market in late 2004. Since inception, it
has generated significant interest in the market due to its ability to cost-effectively
combat identity theft (from phishing and pharming) as well as address enterprise
desktop and remote access security needs.
In May 2005, Design Interpretive conducted an independent usability study on
Entrust IdentityGuard grid authentication. The extremely positive results of the study
validate how easy Entrust IdentityGuard grid authentication is to use for both
consumer and enterprise application security.
Entrust IdentityGuard card usability study on page 168
Recommendations on page 171
Grid authentication implementation on page 173
168
Feedback on guide
Entrust IdentityGuard card usability
study
For organizations that want a strong authentication solution that is easy to use and
easy to 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.
Usability test summary on page 168
Objective on page 168
Methodology on page 169
Usability test results on page 169
Usability test summary
344 people participated in the study
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% of participants achieved unaided successful login in two attempts.
93% of participants were somewhat or very willing to use it once per day.
The temporary 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
169
Feedback on guide
For example, the number of cells and the visual delineation of rows and
columns.
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 experiences.
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:
Seventeen people from a medium sized enterprise were tested in a focus
group environment.
An Entrust IdentityGuard temporary PIN was used as an alternative to an
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 for both the consumer and the enterprise.
Key findings of the enterprise study:
1 Usability of Entrust IdentityGuard grid authentication was excellent and a very
high accuracy rate of grid number lookup was achieved.
Across the four different card designs and layouts (See Figure 46 on page 170),
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 171).
170
Feedback on guide
2 The procedure required to successfully complete the Entrust IdentityGuard
challenge is inherently simple and has high user acceptance.
Figure 46: Successful login attempts
100% of participants 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 temporary PIN login (for forgotten/lost cards) procedure was
straightforward and well understood by users.
100% achieved unaided successful login in two attempts.
Figure 3: Enterprise initial authentication attempts
2nd try
29%
1st try
71%
Figure 3: Enterprise initial authentication attempts
2nd try
29%
1st try
71%
171
Feedback on guide
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.
General guidelines on page 171
Card design and layout on page 171
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) describing 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
as other fonts.
Use a sufficient character point size to ensure readability. A minimum of
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:
Avoid color combinations that create a tendency to vibrate.
Assist users that may have some form of color blindness.
172
Feedback on guide
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.
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.
173
Feedback on guide
Grid authentication implementation
This section provides more information on what the study determined about
implementing grid authentication.
Web login challenge method on page 173
Mutual authentication (through displaying a authentication secret) on
page 173
Temporary PIN length on page 173
Web login challenge method
Given that the type of login challenge method did not affect usability, it is
recommended that organizations implement the method that is best suited to
organizational security requirements. However, there are inherent security benefits to
implementing a two-screen authentication process:
A two-screen approach delivers the ability to achieve mutual authentication
(as a way of addressing phishing).
A two-screen approach delivers the ability to lock a challenge for a user until
it is 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 an
image stored by Entrust IdentityGuard) is displayed on the login screen to achieve
mutual authentication (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 Mutual authentication methods on page 52.
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 to nine characters, depending on your security requirements.
Five elements is the minimum needed to ensure security.
Nine elements is the typical upper span limit of human memory. Going
beyond nine elements makes it very difficult for a user to remember.
174
Feedback on guide
175
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 137
Administration interface 69
Administration service 29
administrator 69
alias 70
alias in a consumer deployment 71
anonymous grids 106
application data 55
sources 56
application integration 78
architecture
evaluation 142
high availability 143
overview 142
standard 142
authentication
benefits 23
definition 23
first-factor 41
methods 42
multiple factors 23
password 40
skip first-factor 41
authentication API 78
authentication factor. See authentication methods
authentication methods 35
comparison 39
external 41
grid 43
grid replay 52
image or message replay 53
knowledge-based 48
machine 55
one-time password 50
passcode list 46
temporary PIN 61
token 42
authentication secret 81
Authentication service 28
automation 116
B
backup and recovery 67
baseline architectures 141
Braille 110
C
card
Braille 110
cost factors 113
production 110
production models 101
security 109
See also grid
See also token
usability study 167
card production
costs 113
Entrust IdentityGuard Card Production Service 112
in-house 110
outsourced 111
Card Production Service 112
card usability study
recommendations 171
results 169
challenge
grid 43, 52
least-used 100
locked 72
one-time password 47
random 100
challenge size
varying 99
client application 32
components 26
Entrust IdentityGuard Desktop 31
first-factor authentication application 30
ISAPI filter 32
Radius proxy 30
Remote Access Plug-in 32
repository 29
Index
176
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
Server 27
computer identity 55
cookie 55
Customer support 18
D
database 83
delivery 137
deployment
overview 64
planning 63
desktop architecture
evaluation 163
standard 164
Desktop for Microsoft Windows 31
directory 83
disaster recovery
failover scenarios 88
distribution 137
Document structure 17
E
email
secure 115
end user. See user
end-to-end encryption 115
enrolment 132
Administration service 29
Entrust IdentityGuard Desktop for Microsoft Windows 31
Entrust IdentityGuard ISAPI filter 32
Entrust IdentityGuard Radius proxy 30
Entrust IdentityGuard Remote Access Plug-in 32
Entrust IdentityGuard Server 27
Entrust tokens 42, 117
evaluation architecture 142
external authentication 41
F
failover 88
file transmission 115
with end-to-end encryption 115
with secure email 115
with secure FTP 115
with SSL 115
first-factor authentication 23, 41
first-factor authentication application 30
FTP 115
G
Getting help
Technical Support 18
grid
automating 116
cell entropy 97
cell format 96
challenge 43, 52
challenge algorithm 100
challenge size 99
deployment risks 46
distribution 102
format 96
lifetime 46, 97
location replay 52
one-step authentication 44
replacement 97
security 109
serial number 52
size 46, 96
two-step authentication 45
grid authentication 43
deploying 95
group 74
H
high availability
architectures 143
failover scenarios 88
I
image replay
disk space 54
integrating 78
considerations 81
Microsoft Windows 79
VPN 79
Web 78
wireless access portal 80
inventory 137
177
Index
S
T U V W X Y Z
-
-
A
ISAPI filter 32
K
Kerberos 41
knowledge-based authentication 48
challenge size 126
exact answers 126
question sources 122
questions qualities 123
security 128
selecting questions 124
word map 126
L
least-used challenge 100
life cycle 129
delivery and activation 137
enrollment 132
maintenance 139
overview 130
renewal 134
replacement 135
usage 133
lock out
reset 133
M
machine authentication 55
application data 55
machine fingerprint 55
machine nonce 55
machine secret 55
machine tag 55
sequence nonce 55
with questions 49, 121, 125
machine fingerprint 55
application data 55
machine nonce 55
machine secret 55
machine tag 55
machine nonce 55
sequence nonce 55
maintenance 139
master user 68
master user shell 68
methods
authentication 23
Microsoft Windows desktop user 34
Microsoft Windows remote architecture
evaluation 156
standard 157
migrating 93
migration 87
model
card production 101
produce-and-assign 102
multifactor authentication 23
mutual authentication 37
grid replay 52
how it works 52
image or message replay 53
O
one-time password authentication 50
operations 66
organization authentication
See mutual authentication
out-of-band 51
P
passcode list
deployment risks 48
length 48
production 48
sample 47
passcode list authentication 46
passwords 40
people 66
performance
repository 84
testing 85
performance testing 85
pharming 46
phishing 46
physical security 67
planning deployment 63
policies 65
preproduction model
grids 106
178
S
T U V W X Y Z
-
-
A
produce-and-assign model 102
producing cards 110
production file
pre-production model 106
transmitting 115
Professional Services 19
Q
question and answer. See knowledge-based authentication
R
Radius proxy 30, 80
overview 40
random challenge 100
recovery 67
remote access architecture
evaluation 160
standard 161
Remote Access Plug-in 32
renewal 134
replacement 135
replay
grid values 52
image 53
message 53
serial number 52
repository 29
database 83
directory 83
failover 30
performance and maintainability 84
selecting 83
synchronization 139
RRAS user 34
S
sample Web application 39
scratch cards 48
search bases 76
second-factor authentication 36
secure email 115
secure FTP 115
sequence nonce 55
shared secrets 82
SSL 28
transmitting files 115
standard architectures 142
strong authentication 22
Structure of guide 17
study summary 168
T
TANs. See passcode list
Technical Support 18
technology 64
temporary PIN 61
length 173
testing performance 85
token
assigning 119
deployment 119
entering values 118
lifetime and replacement 118
security 120
self-registration 119
token authentication 42
deploying 117
tokens
challenge/response mode 42
response-only mode 42
troubleshooting 67
typographic conventions 15
U
usability study 167
summary 168
usage 133
user 33
enrollment 132
groups 74
life cycle 129
locking out 72
Microsoft Windows 34
requirements 70
RRAS 34
services 72
suspending 73
training 71
usage 133
VPN 34
Web 34
user ID 70, 71
V
VPN architecture
evaluation 148
standard 149
VPN user 34
W
Web architecture
evaluation 144
standard 145
Web services 28
Web user 34
wireless access architecture
evaluation 153
standard 154
wireless architecture
word map 126

IG 90 Deployment Guide-Iss20

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

IG 90 Deployment Guide-Iss20

Încărcat de

Drepturi de autor:

Formate disponibile

Entrust

S-ar putea să vă placă și