Nokia Security Service Manager Installation Guide. Version 3.0.1

(1)

Installation Guide

Version 3.0.1

(2)

RESTRICTED RIGHTS LEGEND

Use, duplication, or disclosure by the United States Government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013.

Notwithstanding any other license agreement that may pertain to, or accompany the delivery of, this computer software, the rights of the United States Government regarding its use, reproduction, and disclosure are as set forth in the Commercial Computer Software-Restricted Rights clause at FAR 52.227-19.

IMPORTANT NOTE TO USERS

This software and hardware is provided by Nokia Inc. as is and any express or implied warranties, including, but not limited to, implied warranties of merchantability and fitness for a particular purpose are disclaimed. In no event shall Nokia, or its affiliates, subsidiaries or suppliers be liable for any direct, indirect, incidental, special, exemplary, or consequential damages (including, but not limited to, procurement of substitute goods or services; loss of use, data, or profits; or business interruption) however caused and on any theory of liability, whether in contract, strict liability, or tort (including negligence or otherwise) arising in any way out of the use of this software, even if advised of the possibility of such damage.

Nokia reserves the right to make changes without further notice to any products herein.

TRADEMARKS

Nokia is a registered trademark of Nokia Corporation.

Microsoft and Windows are trademarks or registered trademarks of Microsoft Corporation in the U.S. and/or other countries.

SecurID is a registered trademark of RSA Security INC.

SSH Certifier is either a registered trademark or trademark of SSH Communications Security Oyj in the United States and/or other countries.

Check Point, FireWall-1, and OPSEC are trademarks or registered trademarks of Check Point Software Technologies Ltd.

Other products mentioned in this document are trademarks or registered trademarks of their respective holders. 50110

(3)

Regional Contact Information

Nokia Customer Support Telephone 1-888-477-4566 or 1-650-625-2000 Fax 1-650-691-2170 Mail Address Nokia Inc. 313 Fairchild Drive Mountain View, California 94043-2215 USA

Americas Nokia Inc. 313 Fairchild Drive

Mountain View, CA 94043-2215 USA

Tel: 1-877-997-9199

Outside USA and Canada: +1 512-437-7089 email: [email protected]

Europe, Middle East, and Africa

Nokia House, Summit Avenue Southwood, Farnborough Hampshire GU14 ONG UK

Tel: UK: +44 161 601 8908 Tel: France: +33 170 708 166 email: [email protected]

Asia-Pacific 438B Alexandra Road

#07-00 Alexandra Technopark Singapore 119968

Tel: +65 6588 3364

email: [email protected]

Web Site: https://support.nokia.com/ Email: [email protected] Americas Europe Voice: 1-888-361-5030 or 1-613-271-6721 Voice: +44 (0) 125-286-8900 Fax: 1-613-271-8782 Fax: +44 (0) 125-286-5666 Asia-Pacific Voice: +65-67232999 Fax: +65-67232897 050113

(4)

(5)

About This Guide . . . 11

In This Guide . . . 11

Conventions This Guide Uses . . . 11

Notices . . . 12

Command-Line Conventions. . . 12

Text Conventions . . . 13

Menu Items . . . 13

In This Guide

This guide is organized into the following chapters:

Chapter 1, “Introducing Nokia Security Service Manager” provides an overview of the SSM components and functions and describes how to use SSM to set up automatic content delivery to mobile devices.

Chapter 2, “Installing Nokia Security Service Manager” describes how to install and initially configure SSM.

Chapter 3, “Configuring Nokia Security Service Manager” contains use cases that are examples of how to configure SSM to extend the enterprise network to mobile devices.

Conventions This Guide Uses

The following sections describe the conventions this guide uses, including notices, text conventions, and command-line conventions.

(12)

Notices

Caution

Cautions indicate potential equipment damage, equipment malfunction, loss of performance, loss of data, or interruption of service.

Note

Notes provide information of special interest or recommendations.

Command-Line Conventions

This section defines the elements of commands that are available in SSM. You might encounter one or more of the following elements on a command-line path.

Table 1 Command-Line Conventions

Convention Description

command This required element is usually the product name or other short word that invokes the product or calls the compiler or preprocessor script for a compiled Nokia product. It might appear alone or precede one or more options. You must spell a command exactly as shown and use lowercase letters.

Italics Indicates a variable in a command that you must supply. For example:

delete interface if_name

Supply an interface name in place of the variable. For example: delete interface nic1

Square brackets [ ] Indicates optional arguments. https://host_name[:port] For example:

https://company.com:443

-flag A flag is usually an abbreviation for a function, menu, or option name, or for a compiler or preprocessor argument. You must enter a flag exactly as shown, including the preceding hyphen.

( . , ; + * - / ) Punctuation and mathematical notations are literal symbols that you must enter exactly as shown.

(13)

Text Conventions

Table 2 describes the text conventions this guide uses.

Menu Items

The greater than sign (>), with spaces before and after the sign, separates items in menus. For example, Start > Programs > Nokia > Nokia Security Service Manager indicates that you first choose Start, then choose the Programs menu command, then choose Nokia, and finally choose Nokia Security Service Manager.

Table 2 Text Conventions

Convention Description

monospace font Indicates command syntax, or represents computer or screen output, for example:

Log error 12453

bold monospace font Indicates text you enter or type, for example: # configure nat

Key names Keys that you press simultaneously are linked by a plus sign (+): Press Ctrl + Alt + Del.

Menu commands Menu commands are separated by a greater than sign (>): Choose File > Open.

The words enter and type Enter indicates you type something and then press the Return or Enter key.

Do not press the Return or Enter key when an instruction says type.

Italics • Emphasizes a point or denotes new terms at the place where they are defined in the text.

• Indicates an external book title reference. • Indicates a variable in a command:

(14)

1

Introducing Nokia Security Service

Manager

Local and remote network users have the same requirements for quick, easy access to resources over their corporate networks. And yet, remote network traffic needs protection through encrypted VPN tunneling, antivirus scanning, and appropriate security policies. In addition, network transactions need privacy and integrity while remote users need to be authenticated and authorized for access to networks and network services.

Nokia Security Service Manager (SSM) addresses the initial deployment, subsequent

configuration management, and public-key infrastructure (PKI) related requirements of mobile devices in an Internet protocol security (IPSec) virtual private network (VPN). SSM provides a scalable solution for enterprises to extend their VPN to the mobile domain.

Figure 1 illustrates how SSM works in combination with other hardware, software, and services to create a mobile VPN.

Figure 1 Mobile VPN System Components

The components of a mobile VPN have the following roles: VPN gateway—enforces the security policy.

Nokia Mobile VPN Client—negotiates a secure tunnel with the VPN gateway.

Internet External CA SSM server and database SSM enrollment gateway SSM management station VPN policy management software External authentication server Mail gateway (SMTP) Nokia Mobile VPN Client DMZ Firewall/ VPN gateway Nokia SSM Web server Operator mobile network 00365

(16)

VPN policy management software—manages the VPN gateway. You use policy

management software to create VPN policies and profiles and export them to the SSM database.

Nokia Security Service Manager—delivers security policy and other files to large numbers

of authorized users.

External authentication server—authenticates access to SSM.

External certification authority (CA)—serves the certification requests that it receives

from Mobile VPN Client through SSM.

Mail gateway—uses the simple mail transfer protocol (SMTP) to send notifications to

users.

Nokia Security Service Manager Components

Nokia SSM consists of the following components: Server

Enrollment Gateway

Web Server

Management Station

You can install and run the SSM components either in one computer that is in the enterprise network or distribute them on several computers.

Server

The server component consists of server and database. The server implements the core functionality of SSM. The database is an embedded relational database that stores information about users, user groups, VPN policies, other files, and their properties.

Enrollment Gateway

The enrollment gateway (EGW) component provides online certificate enrollment for Mobile VPN Client. The EGW receives certification requests from Mobile VPN Client. The EGW uses

Server and database Enrollment gateway (EGW) Management station: GUI and CLI DMZ

Firewall/ VPN gateway

Nokia SSM Web server and Web site

00366

Nokia

(17)

the server to authenticate and authorize the certification requests and then forwards the certification requests to an internal or external CA.

You can specify that an EGW entity acts as an internal CA. The automatic content update service uses certificates that an internal CA issues. An internal CA stores certificates, certificate

revocation lists (CRL), and other data in the database.

You must obtain additional licenses to use internal CAs for other purposes than automatic content update.

Web Server

The Web server component acts as an external interface to SSM:

Mobile VPN Client sends certification requests to the Web server, which forwards them to the EGW through the server.

Mobile VPN Client connects to the Web server for automatic content updates from the database.

VPN policy management software exports VPN policies to the database through the Web server.

The VPN gateway might send CRL requests to the Web server, which forwards them to the EGW through the server.

Users access a Web site that the Web server hosts to download content.

Management Station

The management station component consists of a graphical user interface (GUI) and

command-line interface (CLI). You can use the GUI and CLI to manage SSM

.

You can install and run the management station on one or several computers.

For information about how to use the GUI and CLI to accomplish system administrator’s tasks, see the Nokia Security Service Manager Administration Guide.

Creating a Mobile VPN

Figure 2 describes how to use Nokia Mobile VPN Client to create VPN tunnels to corporate network resources through a VPN gateway. You can run Mobile VPN Client on mobile devices, such as Nokia communicators and imaging phones.

(18)

Figure 2 Creating VPN Tunnels with an IPSec VPN

Mobile VPN Client is an IPSec VPN application that allows mobile employees to use the wireless infrastructure to create encrypted connections from their mobile device to a corporate network. Once a mobile employee authenticates to the corporate VPN successfully, all data that travels between the mobile device and the corporate network is encrypted, no matter what the mobile application. Furthermore, the stringent security that is inherent in an IPSec VPN helps ensure that the recipient receives data exactly as the sender sent it. IPSec also helps protect against electronic data theft and man-in-the-middle attacks.

Deploying VPN Policies to Mobile Devices

Figure 3 describes how to use SSM and Mobile VPN Client to secure email access from mobile devices. You can use Mobile VPN Client to encrypt all data that travels between the mobile device and the corporate network, no matter what the mobile application.

VPN gateway SAP database Intranet Internet Mobile network Mail Web content Nokia Mobile VPN Client 00369

(19)

Figure 3 Securing Email Access from Mobile Devices

System administrators must accomplish the tasks that the following sections describe to extend an IPSec VPN to mobile devices:

Configuring Client Access to VPN Gateways

Managing Content

Managing Users and User Groups

Authenticating Users to Nokia Security Service Manager

Using Online Certificate Enrollment

Using Nokia Mobile VPN Client

To automate some of these steps, use example configuration scripts to specify settings for the automatic content update service. For more information about how to use example configuration scripts, see the Nokia Security Service Manager Getting Started Guide.

Configuring Client Access to VPN Gateways

To use Mobile VPN Client, users need a VPN policy that specifies the settings for a VPN tunnel. A VPN policy defines the method that a mobile device and the VPN gateway use to authenticate each other and the encryption algorithms that they use to help protect the integrity of the data. Content managers use VPN management software to create VPN policies and to export them to SSM.

The automatic content update service of SSM automatically installs the VPN policy on a mobile device from SSM. Mobile VPN Client refers to SSM as a VPN policy server.

Use VPN policy management software to configure client

access to VPN gateways

Specify settings for the automatic content update service Map client policies to user groups

Use the mobile device to: Install Nokia Mobile VPN Client Install VPN policies from SSM

Export client policies to the SSM database

Create a user group Specify authentication servers

Create an internal CA

Create VPN access points Select a VPN access point when you use Messaging to connect to intranet mailbox 1 4 5 2

Use the SSM GUI or CLI to:

Mobile Devices

3

6 Configure client access to a VPN gateway

(20)

Authenticating Remote Clients to VPN Gateways

VPN gateways support the following kinds of Internet key exchange (IKE) authentication: Certificate-based authentication—users must have certificates that a trusted CA issues.

Users can use online certificate enrollment to obtain the certificates.

Legacy authentication—usernames and passwords or passcodes authenticate users. You

can use RSA SecurID tokens to generate passcodes, for example.

XAUTH—users use either certificates or usernames and passwords or passcodes to

authenticate.

Certificate-Based Authentication

You can use one of two methods to allow users to use digital certificates as an authentication method. You can set up a VPN policy that:

Includes private keys and digital certificates.

Forces each user to generate their own key pair and use online certificate enrollment to request their own certificate from a CA.

Nokia recommends that you use online certificate enrollment to request certificates from an internal or external CA.

Legacy Authentication

A VPN gateway can support the following types of legacy authentication:

Shared secrets—usernames and fixed passwords authenticate users. More typically, VPN

gateways use shared secrets to authenticate each other in a site-to-site VPN.

Challenge-response authentication—during challenge-response authentication, the VPN

gateway authenticates with a certificate and the user authenticates with a legacy authentication method in an open-ended exchange until they satisfy the VPN gateway. The VPN client informs the VPN gateway that it will use challenge-response authentication and names a legacy authentication method. The VPN gateway responds with its certificate. The certificate authenticates the VPN gateway to the VPN client. The VPN client then uses the legacy authentication method to authenticate to the VPN gateway.

XAUTH

Cisco VPN 3000 Series Concentrator support extended authentication within IKE (XAUTH). XAUTH is a method to use unidirectional authentication mechanisms such as RADIUS, SecurID, and one-time passwords within IKE.

Accessing Nokia IP VPN

If you use Nokia IP VPN, use Nokia VPN Manager to create client policies and profiles and export them to SSM.

You can use VPN Manager to create two types of IPSec VPN policies: Client policy

(21)

A client policy contains all the information that a VPN client needs to establish VPN tunnels to a VPN gateway.

A generic profile lacks user-specific information, such as client certificates and private keys. To provide this information, users do the following:

Employ user names and passwords or certificates to authenticate to the VPN gateway. Use online certificate enrollment to acquire certificates and private keys.

After you create client policies or profiles, export them to the SSM database for installation to mobile devices.

For examples of how to configure client access to IP VPN Gateway, see Chapter 3, “Configuring Nokia Security Service Manager.” For more information about how to use VPN Manager, see the Nokia IP VPN Gateway Configuration Guide.

Accessing Nokia IP Security Platform

Use Check Point SmartDashboard to configure client access to the Nokia IP security platform. Create a Check Point VPN-1/FireWall-1 policy that consists of gateways and external user profiles that participate in remote access VPN communities.

Create an open platform for security (OPSEC) application to execute the vpn nssm_topology command or execute the command from the command line in the SmartCenter Server to export VPN policies to SSM. SSM converts the VPN policies to a format that Mobile VPN Client supports.

For examples of how to configure client access to the Nokia IP security platform, see the

Chapter 3, “Configuring Nokia Security Service Manager.” For more information about how to export VPN policies to SSM, see the Nokia Security Service Manager Administration Guide.

Accessing Cisco VPN 3000 Series Concentrator

Define VPN policy in Cisco VPN 3000 Series Concentrator. Then use the SSM policy push to create VPN policies in the SSM database.

You use a set of predefined templates to create VPN policies for each supported authentication method: certificate-based authentication, legacy authentication, or shared secrets. The templates define the method that a mobile device and the VPN gateway use to authenticate each other and the encryption algorithms that they use to help protect the integrity of the data. You use policy push to add information about the VPN gateway and networking options.

For examples of how to configure client access to the Cisco VPN 3000 Series Concentrator, see the Chapter 3, “Configuring Nokia Security Service Manager.”For more information about how to use policy push to generate VPN policies for Mobile VPN Client, see Nokia Security Service

(22)

Managing Content

You can use SSM to deliver content, such as a VPN policy or Mobile VPN Client software to large numbers of users. All content in the database has an associated multipurpose Internet mail

extensions (MIME) type that describes the content.

You do not use SSM to create content. Use VPN policy management software to configure VPN policies and export them to SSM. Use the SSM GUI or CLI to map the VPN policies to users and user groups. Mobile VPN Client connects to the SSM Web server, the automatic content update service checks for new, updated, or deleted VPN policies in the SSM database, and Mobile VPN Client installs VPN policies to the mobile device or removes them.

Use some other tool to create other types of content and then add the content to the database. Users can download the content that you map to them or to their user groups from the Web site. You cannot add identical content to the database under two different names. The following properties uniquely identify a content entry in the database:

Fingerprint that SSM generates from the content MIME type

Originator of the content

You can specify settings for VPN access points and renewing VPN certificates that are associated with a VPN policy and use the automatic content update service to deliver them to mobile devices.

Content properties authorize users to enroll certificates from a CA. To authorize users, SSM compares the properties of users and the content that you map to users in the database to the fields in the certification request. For more information about how to authorize certificate enrollment, see “Authorizing Certificate Enrollment” on page 26.

Managing Users and User Groups

You can use the GUI or CLI to add users and user groups. You can perform the following operations on users and user groups:

Create Search Modify Remove

Map users to user groups

Map a user group to another user group (form a group hierarchy) Map content (VPN policies and other files) to user groups and users

Use the CLI to import large numbers of users and user groups from an external database. The number of users that you can add to the database depends on the license you obtain.

To change the properties of large numbers of users at a time, use the CLI to export the users to a file. Modify the file with a text editor, save it as a new file, and import the new file to the database.

(23)

Granting Users Privileges

SSM authenticates all access. Once users authenticate, they can use SSM according to the privileges of their user group. Privileges specify the objects that the members of a user group can access and the actions that they can apply to the objects. The database contains predefined user groups for system, user, and content managers. In addition, you can create users groups to allow users to access content and enroll certificates.

The user groups have the following privileges:

System managers (system administrators)—can use all the SSM functions.

User managers—can use a subset of SSM functions to manage users and user groups.

Content managers—can export VPN policies from VPN policy management software to

the database and use policy push to create VPN policies in the SSM database.

System administrator-specified user groups—can access content and enroll certificates.

You create these user groups and give them names.

Any user can belong to only one managers group. Any user can belong to several user groups that you create.

Inheriting Content from User Groups

You can form a user group hierarchy, where one user group is the member of another group. Group membership determines how users access content, because when you map content to a group you indirectly map the content to the members of the group.

Figure 4 illustrates the network of a company that provides remote access to telecommuters who use laptops or mobile devices to access corporate resources, such as email, Web, and a SAP database.

(24)

Figure 4 Remote Access

Figure 5 illustrates the user groups that you can create in SSM to map VPN policies to users. Figure 5 User Groups

You map VPN policies to the user groups. Because users and groups inherit content, the users have access to different numbers of VPN policies. For example, users whom you map to the

MobileDevices user group have access to the content that you map to the MobileDevices user

group and to the Telecommuters user group.

Notifying Users

You can send notifications to users and user groups by email. SSM uses SMTP to deliver notifications. SSM can deliver notifications to users’ GSM phones, if their email addresses point to an SMS gateway that understands SMTP.

Internet Mobile Devices/ Mobile Devices Policy DMZ Firewall/ VPN gateway Nokia SSM Web server Operator mobile network 00371 SSM server and database SSM enrollment gateway SSM management station RADIUS or LDAP server SAP database Corporate email Corporate Web services Windows Clients/ Laptop Policy Telecommuters

(25)

Authenticating Users to Nokia Security Service Manager

SSM authenticates all access. Either logon names and passwords or certificates authenticate users. SSM verifies logon names and passwords against the local database or an external authentication server, such as a RADIUS or an LDAP server. Certificates authenticate users to the automatic content update service. SSM verifies that an internal CA issued the certificates and that they are valid.

To prevent brute-force attacks against username-password login, SSM delays the login process after failed login attempts. Specify settings for attack prevention in the SSM configuration file, server.properties, login.fail.threshold, and login.fail.delay settings.

Authentication Methods

You can use the following authentication methods to authenticate users to the SSM Web site and automatic content update service:

Local authentication—SSM checks the logon name and password of the user against a

local database. Only one local database can exist at a time.

One-time password authentication—Administrators use the GUI to generate passwords

for users whom they add to the database. Administrators set a predefined authentication server called One-time password as the users’ authentication server. SSM checks the logon name and password of the user against the database and removes the password from the database. Another authentication method, such as certificates, subsequently authenticates users.

RADIUS authentication—SSM checks the logon name and password of the user against a

RADIUS server. Optionally, SSM drops the domain name part of the user identifier before authentication. The passwords can be either normal passwords or one-time passwords that users generate with token cards, such as RSA SecurID. Several instances of this

authentication method can exist at the same time.

LDAP authentication—SSM searches for the user by logon name from an LDAP server.

Optionally, SSM drops the domain name part of the logon name before the search. When the user is found, an LDAP bind is done using the user’s distinguished name (DN) and

password. Several instances of this authentication method can exist at the same time. Certificate authentication—the user presents a certificate, which must be valid, and a

signature. The certificate is valid if it is signed by the CA that you define as the

authentication server, if it is within its validity period, and if it has not been revoked. If the signature was signed with the certificate, the user is considered authenticated. The

rfc822Name subject alternative name extension field in the certificate maps the user to an existing SSM logon name.

In SSM v3.0, certification authentication is only supported for the automatic content update service. The first time users log on to SSM with Mobile VPN Client, one of the other authentication methods authenticates users. During the first connection, Mobile VPN Client requests certification for the users from the SSM internal CA. Certificates subsequently authenticate users to the automatic content update service. Users might need to use the other authentication methods again if their certificates expire.

(26)

Selecting Authentication Methods

You can use more than one authentication method to authenticate users to SSM. For example, you can choose that SSM authenticates some users against the local database and some against an external authentication server. Or you can generate one-time passwords that authenticate users to SSM to enroll certificates for subsequent authentication to a VPN or to the SSM automatic content update service.

You define authentication servers and the users whom the servers authenticate. You specify additional settings for external authentication servers.

Using Self-Provisioning to Add Users Automatically

If you have an external authentication server, you can use self-provisioning to set up content delivery. You set self-provisioning rules that specify an authentication domain, an authentication server, and a user group. After successful authentication, SSM adds users to the database as members of the user group that you specify. Users can access content that you map to that user group.

You specify a logon name for each user in user properties. SSM enforces that you specify logon names in the following format: logonname@domain. The logon names do not need to be real email addresses.

When a user logs on to SSM, SSM performs the following tasks that can lead to self-provisioning:

1. If the logon name does not contain a domain name, SSM appends the default authentication

domain name to the logon name. You specify the default authentication domain name when you install SSM.

2. SSM searches for the user from the local database:

If SSM finds the user, SSM authenticates the user against the authentication server that you specify in the user properties.

If SSM does not find the user, SSM searches among self-provisioning rules for a matching authentication domain.

3. If SSM finds the authentication domain, and the external authentication server that you

specify in the self-provisioning rule authenticates the user, SSM adds the user to the database.

The server.properties file contains regular expressions that extract the first and last name correctly from the logon name. The default expressions match logon names in the

firstname.lastname@domain format. If you specify logon names in other formats, modify the self.provisioning.firstname and self.provisioning.lastname settings to match the logon name format.

4. When the user logs on again and enters the username and password, SSM searches for the

user in the local database and authenticates the user against the external authentication server.

Use the enable.self.provisioning setting in the server.properties file to temporarily disable self-provisioning.

(27)

Using Online Certificate Enrollment

When a VPN client receives a VPN policy that lacks a private key and client certificate, the VPN client must obtain them before it can establish a VPN tunnel. The VPN client can use online

certificate enrollment to obtain certificates.

The VPN client creates a public-private key pair and a PKCS #10 certification request and sends them to a CA. The CA uses a public-key algorithm to certify the public key and issues a certificate for a user. The CA signs a collection of information that includes the user’s

distinguished name (DN), subject alternative name, and public key. If the enrollment is

successful, the CA sends back a certificate and the VPN client is ready to establish a VPN tunnel.

The SSM enrollment gateway (EGW) authenticates and authorizes certification requests from Mobile VPN Client and automatically enrolls certificates from an internal or external CA if the authentication and authorization succeed.

Some certificate enrollment protocols support two modes, manual and automatic. You agree with the CA vendor on the mode to use.

In manual mode, the CA completes certificate enrollment after the CA administrator personally verifies the PKCS #10 certification request. For example, the administrator can call the user on the phone to provide verification.

In automatic mode, a preconfigured shared secret, or some other mechanism (for example, legacy authentication based on RADIUS or LDAP), verifies the certification requests.

Using Nokia Security Service Manager as an RA

For mass deployment of certificate clients to work smoothly, you must completely automate the CA. When the CA receives a certification request, it should automatically generate a new certificate and return it to the requestor. This process poses a security problem, however. The CA should issue certificates automatically only if it can verify that the requestor is legitimate. Most of the existing CAs cannot verify this automatically.

VeriSign and EuroTrust support certificate request syntax (CRS) in automatic administration mode to accomplish total automation. Users must first authenticate to SSM. If they are successful, the server forwards the certification request to the CA. This process moves the burden of authenticating certification requests from the CA to SSM, which acts as a registration

authority (RA). The CA needs to know and trust only one source of certification requests, SSM.

(28)

Figure 6 Enrollment Gateway as Registration Authority

Online certificate enrollment proceeds as follows:

1. Mobile VPN Client sends a certification request to SSM. 2. SSM authenticates the user.

3. SSM uses the protocol that the external CA specifies to send the request to the external CA. 4. The external CA signs a digital X.509v3 certificate for Mobile VPN Client and sends it, or a

certificate-pending reply, to SSM.

5. SSM forwards the reply to Mobile VPN Client.

From the Mobile VPN Client point of view, the whole operation consists of a single HTTP request-response pair.

Using Nokia Mobile VPN Client

Users can install several VPN policies on a mobile device to exchange data with multiple companies or service providers. To enable Mobile VPN Client to negotiate VPN tunnels with a specific VPN gateway, VPN policies are associated with VPN access points. A VPN access point combines a VPN policy and an Internet access point.

When users select a VPN access point to connect to the network, Mobile VPN Client performs the following tasks:

Connects to the Internet access point that is associated with the VPN access point. Loads the VPN policy that is associated with the VPN access point.

Connects to a VPN gateway to negotiate a VPN tunnel. Users update VPN policies in two ways:

Choose a Mobile VPN Client command.

Select a VPN access point to connect to the network.

When users select a VPN access point to connect to the network, they start the VPN policy update process with SSM in parallel to the logon process with a VPN gateway. Mobile VPN Client compares the VPN policies on the mobile device with the VPN policies in SSM. Mobile VPN Client installs new and updated VPN policies on the mobile device and removes obsolete VPN policies from the mobile device.

When users update an active VPN policy, they do not affect current VPN tunnels. Changes become effective the next time users select a VPN access point that is associated with the VPN policy. When users remove the current VPN policy they do not close the current VPN tunnels.

External CA 00372 2 3 4 5 1 SSM Nokia Mobile VPN Client

(29)

When certificates are about to expire, Mobile VPN Client enrolls new certificates. Specify the threshold for renewing certificates for the automatic content update service in the

client.properties configuration file, acu.cert.renewal setting.

Mobile VPN Client uses the automatic content update service to enroll VPN certificates for users. Mobile VPN Client enrolls new VPN certificates when they expire. The enrollment begins when users activate a VPN policy and the renewal period for the certificate that is associated with the VPN policy has expired. Use the SSM CLI to specify the certificate renewal period as a property of the VPN policy.

Note

Even if you remove users from an external authentication server, certificates grant users access to SSM until they expire. Remove users from SSM as well as from the external authentication server to deny them access to SSM.

For more information about how to use Mobile VPN Client, see the Nokia Mobile VPN Client

(30)

(31)

2

Installing Nokia Security Service

Manager

This chapter describes how to install Nokia Security Service Manager (SSM): Choosing an Installation Option

Minimum System Requirements

Preparing for the Installation

Using the Nokia Security Service Manager Installer

After the Installation

For information about how to configure SSM, see Chapter 3, “Configuring Nokia Security Service Manager.”

Choosing an Installation Option

You can install the SSM components on up to four computers. Install each component only once. The management station is an exception. You can install the management station on several computers to manage SSM remotely. You can install the management station also on Windows computers.

You can either install all the SSM components on one computer or you can install the following SSM components on separate computers:

Server

Web server—install the Web server separately from the server to improve performance and

security.

EGW—install the EGW on a dedicated computer to ensure security and improve

performance.

Management station—install the management station separately from the other

components to manage SSM remotely. You can install the management station on Windows workstations as well as on UNIX computers.

Note

Use the Nokia Security Service Manager Planning Sheet to plan your network topology before you install SSM.

(32)

Figure 7 illustrates an installation where the SSM components are installed on four separate computers. The Web server is in the demilitarized zone (DMZ) and the other SSM components are on the intranet. A firewall is placed between the Web server and SSM server.

Figure 7 Installing All SSM Components on Separate Computers

Security Considerations

The security of the SSM installation is affected by where you install the SSM components. The Web server component acts as an external interface to SSM, so applications and users must be able to access it. You have the following options to install the Web server:

Install the Web server in the DMZ and place a firewall between the Web server and server. Install the Web server on the intranet and use a proxy server between the intranet and the

public network.

Install the server and Web server on network segments that allow only the minimum network traffic to pass in and out. For example, place the Web server in Ethernet segments that do not contain any other servers.

Install the server and EGW on the intranet to help protect them from attacks. Preferably, use a firewall to separate the network segment from the rest of the intranet.

You can set up the EGW to connect to an external CA for online certificate enrollment. If the CA is in the public network, you can use a proxy server for communication between the EGW and CA.

If you do not use a proxy server, install the EGW in a part of the intranet where it can connect to the external CA. The EGW must be able to initiate TCP/IP communication to the CA over the public network.

Perform the following tasks on the server and Web server to prevent unauthorized access to SSM:

Install the most recent security patches.

Remove unnecessary services that might provide attackers with access to SSM.

Deny unauthorized operating system root-level access to the computers to which you install SSM. Server and database Enrollment gateway (EGW) Management station: GUI and CLI DMZ

Firewall/ VPN gateway

Nokia SSM Web server and Web site

00366

Nokia

(33)

Obtaining Valid Licenses

To install and run Nokia Security Service Manager, you must obtain valid licenses for the services that you need and the number of users you manage. You can add licenses as necessary. You can obtain an evaluation license that allows you to install and run SSM for a set period. You can upgrade the evaluation license to a permanent license

Installing and Running Several Nokia Security Service Manager

Instances on One Computer

In a service provider environment, for example, you can install several independent SSM instances on one computer. Note the following:

Obtain a separate license for each SSM instance. Install each SSM instance in a separate directory.

Use a different UNIX user account as the process owner of each SSM instance. Specify a different port base for each SSM instance.

The port numbers that you reserve for each SSM instance cannot overlap.

If you specify a different Web server host name for each SSM instance as a real or virtual IP interface address, you can use the default port numbers for the HTTP and HTTPS ports. This ensures that firewalls pass automatic content update traffic on the Internet. You can, however, use the same host name for all Web server instances if you specify different HTTP and HTTPS port numbers for each instance.

You can use a single management station to manage all the SSM instances. In Windows, install the management station several times to enter the host name, port base, and server certificate for each SSM instance. The installation program creates separate icons to start the GUI and CLI to manage each SSM instance.

In UNIX, you do not need to install the management station more than once, but you must use the mcs trustcert management command script to import the server certificate of each SSM instance to the trusted-key store, certs.jks, on the management station.

For more information about how to use management command scripts, see the Nokia Security

Service Manager Administration Guide

Minimum System Requirements

Table 3 describes the minimum system requirements, which depend on the type of installation that you choose.

(34)

Table 3 Minimum System Requirements Installation Option Requirements One computer Operating system:

• RedHat Enterprise Linux v3.0 AS, ES, or WS, Intel X86 compatible

• Sun SPARC Solaris 8 with patches • Sun SPARC Solaris 9

Other requirements:

• Java 2 Runtime Environment (J2RE) v1.4.2_04, 32-bit

• 250 MB of available hard disk space (for a database that contains the maximum number of users)

• 512 MB of RAM

• TLS/SSL certificate for the Web server. Optional.

Server Operating system:

Other requirements: • J2RE v1.4.2_04, 32-bit

• 180 MB of available hard disk space (for a database that contains the maximum number of users)

• 512 MB of RAM Management station Operating system:

• Microsoft Windows 2000 with Service Pack 2 or later or Windows XP Pro Other requirements:

• J2RE v1.4.2_04, 32-bit or J2RE 1.5

• 20 MB of available hard disk space, which does not include the disk space that J2RE requires

• 256 MB of RAM Web server Operating system:

Other requirements:

• J2RE v1.4.2_04_04, 32-bit • 95 MB of available hard disk space • 512 MB of RAM

(35)

Note

Content and logs require additional disk space on the server, Web server, and management station.

Preparing for the Installation

Before you can install SSM, you must perform some tasks, including: Installing Patches and Libraries on Solaris

Modifying System Specifications in Solaris

Installing J2RE

Synchronizing System Clocks

For important product information and known issues, see the Nokia Security Service Manager

Release Notes.

Installing Patches and Libraries on Solaris

The standard installations might not contain all the functionality that SSM requires. Install patches as described in the following sections:

Installing Sun Patches on Solaris

Installing SUNWzlib on Solaris 8

Installing Sun Patches on Solaris

If you install and run SSM on Solaris, install the latest patches from Sun. Install patches as root. To view the patches that are already installed, enter the following command:

showrev -p

EGW Operating system:

Other requirements:

• 30 MB of available hard disk space • 512 MB of RAM

Table 3 Minimum System Requirements Installation Option Requirements

(36)

On Solaris 8, install at least the following patches:

112438-02—improves performance and implements the /dev/random random number generator

111297—installs the libsendfile functionality. Patch cluster that Sun recommends you to install.

Installing SUNWzlib on Solaris 8

The SSM database requires that the Zip Compression Library package, SUNWzlib, is installed on the server computer. Since the SUNWzlib package is not part of the End User software group on Solaris 8, you might need to manually add the packages to your Solaris 8 system. You can find the packages on the Solaris 8 media.

Modifying System Specifications in Solaris

If you install and run SSM on Solaris, set new values for system modules in one-computer installations or on the server computer to ensure that SSM does not run out of resources.

To modify system specifications 1. Log on as root.

2. Edit the /etc/system file.

Add the following lines to the end of the file: set shmsys:shminfo_shmmax=0x2000000 set shmsys:shminfo_shmmin=1 set shmsys:shminfo_shmmni=256 set shmsys:shminfo_shmseg=256 set semsys:seminfo_semmap=256 set semsys:seminfo_semmni=512 set semsys:seminfo_semmns=512 set semsys:seminfo_semmsl=32

3. Save the file.

4. Restart the computer.

Installing J2RE

SSM server requires Java 2 Runtime Edition (J2RE) v1.4.2_04, 32-bit, which is not preinstalled on Windows or RedHat Enterprise Linux v3.0. The version that is preinstalled on Solaris might be older than the version that SSM requires. The SSM installer checks that the correct J2RE version is installed and prompts you to install v1.4.2_04, if necessary.

A separate management station installation also supports J2RE v1.5.

(37)

Note

J2RE 64-bit is not supported if you run SSM on Sun SPARC Solaris.

For the SSM CLI to support characters that the US-ASCII character set does not include, such as the Scandinavian characters, install J2RE in custom mode and select the additional languages support option.

Synchronizing System Clocks

CA operations require accurate clocks on the server and EGW. To synchronize clocks, use the

network time protocol (NTP), for example, which distributes accurate and current time

information.

Using the Nokia Security Service Manager Installer

You can install the SSM components on up to four computers. Install each component only once. The management station is an exception. You can install the management station on several computers to manage SSM remotely. You can install the management station also on Windows computers.

Choose from the following installation options:

Server installation—installs the server, database, and management station. Always install

this option first.

Web server installation—installs the Web server and Web site.

Enrollment gateway installation—installs the EGW.

Management station installation—installs the GUI and CLI.

Selecting the Installation Directory

If the installation directory already exists, grant write (w) access to the directory to the process owner and the group to which the process owner belongs. If the installation directory does not exist, grant the process owner write (w) access to its parent directory.

Nokia recommends that you use the mcs rootinstall command after the installation to set root as the owner of the installation directory. A setuid bit starts the SSM starter process as root even though you are logged on as the process owner. The processes that the SSM starter process starts set the user ID back to the process owner. The Web server process sets its HTTP request handlers to nobody.

Root should also own the directories between the root directory and the installation directory and only root should have write access to them. If you allow users other than root to modify files that root executes, you compromise root.

(38)

For more information about setting operating system file permissions, see “Setting File Permissions and Creating a Startup Script” on page 49.

Installation Settings

When you install or configure SSM, you specify values for the fields that Table 4 describes. Find out the values before you begin the installation.

The values are stored in the SSM configuration files, which are in the installation_directory/etc directory. Back up the configuration files after installation. Do not change the values manually. Use the GUI or CLI to modify the properties of the system manager account. For more information about how to modify user properties, see the Nokia Security Service Manager

Administration Guide or the SSM Help.

Table 4 Installation Settings Checklist

Field Description

Server

Directory name Select the directory in which to install SSM.

In a one-computer installation, install all the components of one SSM instance in the same directory.

By default, SSM is installed in the nssm directory in the current user’s home directory.

Note

Root must own the installation directory or you compromise root. In addition, only root can have write access to the directories between the root directory and the installation directory or you compromise root.

Host name The fully qualified host name or IP address of the server.

The other SSM components use this value to communicate with the server. Do not use the value localhost.

In Linux, the default value is the host name of the computer.

Port base Reserve this port number and the six following port numbers for SSM. By default, port numbers 26773 through 26779 are used.

You cannot use port numbers in the anonymous port range in the computer. By default the anonymous port range starts from port 32768.

For more information about protocols and port numbers, see the Nokia Security Service Manager Administration Guide.

Passphrase A text string at least eight characters long.

SSM uses this value to help protect private keys and the communication between the server, Web server, and EGW when you install them on different computers. Specify the same passphrase for all the SSM components.

(39)

Save passphrase Select this option to save the passphrase in the server.properties configuration file.

SSM uses the passphrase to encrypt private keys, so the passphrase must not be compromised. Save the passphrase in server.properties only if you can be sure that unauthorized persons cannot see it.

A more secure method to save the passphrase is to use the mcs rootproperties management command script that saves the server

passphrase in the root.properties configuration file in encrypted format. Only root can access root.properties.

If you do not save the passphrase in server.properties or root.properties, SSM asks you to enter it each time you start the server.

Subject DN Specify default values for the subject name of certificates that the internal CAs issue and the subject name of the Web server certificate.

Specify the following settings in the subject DN:

• C—Country (use the two-letter ISO 3166 country codes) • O—Organization

• OU—Organization unit (optional) Default authentication

domain

Default domain part of the logon names that authenticate users to SSM. For example, customer.com.

Do not include the at sign (@) in the value that you define, because SSM automatically adds it.

If a logon name does not contain a domain name, SSM appends the default domain name to the logon name when SSM adds the user to the database and when users log on to SSM.

For example, [email protected]. System manager account

Last name The last name of the system administrator.

The installer saves the system manager account in the database. You can use the GUI or CLI to modify it.

First name The first name of the system administrator.

Logon name The logon name authenticates the system administrator when he or she accesses the GUI or CLI.

You can decide the logon name format. Logon names are from 1 to 128 characters long.

Password A text string at least 8 characters long.

Passwords authenticate the system administrators against the server. Email The email address of the system administrator.

Mobile phone The mobile phone number of the system administrator. Use the international format: +country code phone number. Optional.

(40)

Web server

Host name The fully qualified host name or IP address of the Web server.

Use the first DNS address of the server in full format including the domain name.

In Linux, the default value is the host name of the computer.

The host name must be a routable IP address or resolvable host name, because Mobile VPN Client uses the host name to connect to the Web server. Mobile VPN Client can resolve the host name of the Web server only if the DNS server of the Internet service provider can resolve the host name. You cannot use a dynamic network address translation (NAT) address for the Web server. If you use a fixed NAT address, you must configure the public NAT address as a part of the address of the automatic content update service. For scalability, give different host names to the Web server and server even in a one-computer installation. This makes it possible to move the Web server to another computer to improve performance.

For more information about distributing SSM to several computers, see the Nokia Security Service Manager Administration Guide.

You cannot use the value localhost as the host name of the Web server. HTTP port A port number. By default, port 80 is used.

You cannot use port numbers in the anonymous port range in the computer. By default, the anonymous port range starts from port 32768.

HTTPS port A port number. By default, port 443 is used.

You cannot use port numbers in the anonymous port range in the computer. By default, the anonymous port range starts from port 32768.

Server certificate file The path to the server certificate and trusted certificate store that the installer or configuration script creates during the installation of the server component. By default, the installer or configuration script calls the certificate store certs.jks and creates it in the installation_directory/etc directory.

You need certs.jks when you install the Web server and management station on a separate computer. Copy certs.jks to the Web server or management station in a secure way.

(41)

Installing Nokia Security Service Manager in Solaris

You can use either graphical or text-based installation.

Note

If you distribute SSM to several computers, always install the server component first.

To install Nokia Security Service Manager in Solaris

1. Create a user account (called process owner in this guide) to install and run SSM. For

example, ssm.

2. Log on as the process owner.

Note

You cannot install SSM as root in Solaris.

3. The J2RE directory must be in the system path for the duration of the installation. To set the

path, enter the following command at the command prompt: JAVA_HOME=/J2RE_installation_directory

PATH=$JAVA_HOME/bin:$PATH export JAVA_HOME PATH

4. Enter the following command to start the SSM installer:

java -jar Setup.jar

java -cp Setup.jar run -console

5. Specify the installation directory.

The default directory is nssm in the current user’s home directory. Change the default directory to /opt/nssm, for example.

If you install several SSM instances in the same computer, install them in different directories.

6. Select the SSM components to install.

Table 4 explains the settings that you need to specify.

7. Follow the directions of the installer until the installation is complete.

8. If you install the server, copy SSM licenses to the installation_directory/etc/licenses

directory.

9. Set file permissions and create a startup script to enable automatic startup of SSM: a. Log on as root.

b. Change to the installation_directory/bin directory.

(42)

For more information, see “Setting File Permissions and Creating a Startup Script” on page 49.

10. Start SSM to check that the installation was successful and that all the services start up: a. Log on as the process owner.

b. Change to the installation_directory/bin directory.

c. At the command prompt, execute the following management command script to start

SSM:

./mcs start

d. Enter the passphrase that you specified when you installed the server component, unless

you saved the passphrase in the server.properties or root.properties configuration files.

e. At the command prompt, execute the following management command script to check

that all the SSM services started up: ./mcs status

f. Use a Web browser to access the URL of the Web site to verify the Web server

installation:

https://host_name[:port]

Note

If the Web server does not start, check that you executed the ./mcs rootinstall management command script to set file permissions.

11. If you install the Web server, the installer generates a private key and creates a PKCS #10

certification request and a signed certificate for the Web server. You can use the self-signed certificate to check that the SSM installation succeeds and that SSM starts up. The Web server certificate authenticates the Web server to:

VPN policy management applications and the SSM policy push command that create SSL connections to the Web server to export VPN policies to the SSM database Users who use the SSM Web site to download content.

Before you can export VPN policies to SSM, you must send the certification request to an internal or external CA to sign. For more information, see “To obtain a TLS/SSL certificate”

on page 51.

Installing Nokia Security Service Manager in Linux

Use installation scripts to install the SSM components from compressed tar packages in Linux. You can either use a quick installation script to install and configure all SSM components in one Linux computer in the DMZ for evaluation purposes or use the standard installation script and configuration scripts to install SSM in the production environment and to distribute the SSM components to several computers.

(43)

Installing All SSM Components in One Computer

Use the quick installation script to install all SSM components in one Linux computer in the DMZ. The quick installation script performs the following tasks:

Installs all SSM components in one computer using default values where possible. Runs the Linux configuration scripts that set parameters for the SSM components using

default values where possible.

Creates a system administrator with the logon name admin and the password that you define. Runs the SSM example configuration scripts that create a content manager, specifies settings

for the automatic content update service, and creates an internal CA.

Runs the ./mcs rootinstall script to set file permissions and creates a startup script to enable automatic startup of SSM.

To install all SSM components in one computer 1. Log on as root.

2. Create a user account (called process owner in this guide) to install and run SSM. For

example, ssm.

path, enter the following command at the command prompt: JAVA_HOME=/J2RE_installation_directory

PATH=$JAVA_HOME/bin:$PATH export JAVA_HOME PATH

4. Create an installation directory on the server, copy the installation tar files and SSM licenses

to the installation directory, and switch to the installation directory.

The quick installation script creates a subdirectory called ssm in the current working directory and installs SSM in the ssm directory.

The root needs at least execute (x) access rights to the installation script and read (r) access rights to the .tgz files.

The process owner needs the execute (x) access rights to all directories from the installation directory to the root.

5. To install SSM components, enter the following command:

./quickinstall.sh

6. Enter the name of the process owner whose account you create in step 2.

7. Follow the instructions of the quick installation script. Table 4 explains the settings that you need to specify.

Error messages might appear during the installation and configuration, because the scripts might try to access directories that the process owner does not have the rights to access:

bash: /root/.bashrc: Permission denied

(44)

8. Start SSM to check that the installation was successful and that all the services start up: a. Change to the installation_directory/bin directory.

b. At the command prompt, execute the following management command script to start

SSM:

./mcs start

9. At the command prompt, execute the following management command script to check that

all the SSM services started up: ./mcs status

10. Use a Web browser to access the URL of the Web site to verify the Web server installation:

https://host_name[:port]

Distributing SSM

to Several Computers

Use the standard installation script to distribute the SSM components to several computers. First run the installation script in each computer. Then run the following configuration scripts that the installation copies in the installation_directory/bin directory for the components that you install in the computer: server-config web-config egw-config management-config Note

If you distribute SSM to several computers, always install and configure the server component first.

During the installation, the process owner needs least execute (x) access rights to the installer file and read (r) access rights to the .tgz files.

To distribute SSM components to several computers 1. Log on as the process owner.

Note

You cannot run the ./installer script as root.

path, enter the following command at the command prompt: JAVA_HOME=/J2RE_installation_directory> PATH=$JAVA_HOME/bin:$PATH

Nokia Security Service Manager Installation Guide. Version 3.0.1

Installation Guide

Version 3.0.1

In This Guide

Conventions This Guide Uses

Notices

Command-Line Conventions

Text Conventions

Menu Items

Related Documentation

1

Introducing Nokia Security Service

Manager

Nokia Security Service Manager Components

Server

Enrollment Gateway

Web Server

Management Station

.

Creating a Mobile VPN

Deploying VPN Policies to Mobile Devices

Configuring Client Access to VPN Gateways

Authenticating Remote Clients to VPN Gateways

Accessing Nokia IP VPN

Accessing Nokia IP Security Platform

Accessing Cisco VPN 3000 Series Concentrator

Managing Content

Managing Users and User Groups

Granting Users Privileges

Inheriting Content from User Groups

Notifying Users

Authenticating Users to Nokia Security Service Manager

Authentication Methods

Selecting Authentication Methods

Using Self-Provisioning to Add Users Automatically

Using Online Certificate Enrollment

Using Nokia Security Service Manager as an RA

Using Nokia Mobile VPN Client

2

Installing Nokia Security Service

Manager

Choosing an Installation Option

Security Considerations

Obtaining Valid Licenses

Installing and Running Several Nokia Security Service Manager

Instances on One Computer

Minimum System Requirements

Preparing for the Installation

Installing Patches and Libraries on Solaris

Installing Sun Patches on Solaris

Installing SUNWzlib on Solaris 8

Modifying System Specifications in Solaris

Installing J2RE

Synchronizing System Clocks

Using the Nokia Security Service Manager Installer

Selecting the Installation Directory

Installation Settings

Installing Nokia Security Service Manager in Solaris

Installing Nokia Security Service Manager in Linux

Installing All SSM Components in One Computer

Distributing SSM

to Several Computers