Establish the security needs for your installation. Set
up key required applications, modify default IP filter policy if necessary,
configure the IKE daemon, configure the NSS daemon and additional
encryption products as needed, and create IP security policy configuration
files.
Procedure
Perform the following steps to prepare the z/OS® system for IP security.
- Develop a site policy to address the security needs of
your installation. Consider the following questions before
beginning to build a robust IP security policy:
- Do you want a default-allow or default-deny policy?
- If you want a default-deny policy, what traffic is allowable as
critical to the correct functioning of the system?
- What hosts are allowed to send data to the secure host?
- Do you understand the network topology, and where the communicating
hosts are located within the network?
- Are there network address translation (NAT) devices in the network
topology?
- What type of traffic is allowable from those hosts?
- What general network services that rely on well-known ports do
you want to allow?
- Will you forward any packets you receive that are not destined
for you?
- Who is allowed to configure the IP security policy?
- Are you running with one TCP/IP stack, or more than one TCP/IP
stack?
- Are you running IPv6 traffic?
- Will all TCP/IP stacks share the same policy definitions, or will
they have unique differences?
- Will traffic that is sent or received by the secure host traverse
the Internet?
- Do you want to participate in a VPN? (If so, IPSec is required.)
- If IPSec is required:
- What are the IPSec capabilities of the remote endpoints?
- How do you want to authenticate participating hosts:
- Pre-shared key?
- Digital signature? (requires digital certificates)
- What type of authentication is needed for the data that is involved?
- Is encryption needed for the data that is involved, and how strong
should the encryption algorithms be?
- Will all participating hosts use the same level of data encryption
and authentication, or do you need to define unique policies for individual
hosts?
- Identify the resources to be secured. Create
a worksheet for each TCP/IP stack you will enable for IP security.
This information aids in determining which interfaces and connected
networks are secured. You can later use the information from the worksheets
to provide values for IP security policy configuration statements. Figure 1 includes a sample worksheet:
Figure 1. Sample worksheet for stack securityHost name of z/OS system _____________________________________
Complete for each TCP/IP stack on this host:
TCP/IP stack name ______________IPSECURITY-enabled (Y/N)______
Network interface(s)
IPv4 address/Mask______________________Security Class_________
IPv4 address/Mask______________________Security Class_________
IPv4 address/Mask______________________Security Class_________
IPv4 address/Mask______________________Security Class_________
IPv6 address/Prefix____________________Security Class_________
IPv6 address/Prefix____________________Security Class_________
Virtual IPv4 address/Mask____________________
Virtual IPv4 address/Mask____________________
Virtual IPv4 address/Mask____________________
Virtual IPv4 address/Mask____________________
Virtual IPv6 address/Prefix__________________
Virtual IPv6 address/Prefix__________________
Identities, other than IP address, by which the IKE daemon will be known
(e.g., X500dn, Fqdn, UserAtFqdn, KeyID)
___________________
___________________
___________________
___________________
___________________
Security class is an optional designation for a network interface.
You can assign network interfaces a security class (1-255) that is
used to group interfaces with similar security requirements. This
concept is an extension of the traditional notion of secure and nonsecure
interfaces, to allow for more than two classes. The secure and nonsecure
model can still apply if only two security classes are defined.
Complete
a table of remote hosts and subnetworks with which this host needs
to transfer data, as shown in Table 1.
The remote hosts can optionally be grouped in a user-defined zone
to simplify the number of IP filter rules that are required. For instance,
you might want to define an internal, external, trusted, Internet,
partner company, or other zone that has meaning to your site.
Rule: If the remote IKE peer is on a security
gateway to the remote host, the IP address of the remote host might
not match the IP address of the remote IKE peer. If this is the case,
tunnel-mode encapsulation of IPSec traffic is required.
Table 1. Table of remote hosts and subnetworks| Remote IP address
or subnet |
User-defined zone
of remote hosts |
Identity of remote
IKE peer (IpAddr, X500dn, KeyID, Fqdn, or UserAtFqdn) |
IP address of remote
IKE peer |
Allowed list of services
(Telnet, FTP, web, EE, ALL, or other) |
Security action (permit,
deny, ipsec) |
IPSec security level,
if applicable |
|---|
| |
|
|
|
|
|
|
| |
|
|
|
|
|
|
- Modify the default IP filter policy (optional). After
the site policy is established, you can modify the default IP filter
policy if necessary. For a description and examples of how to modify
the default IP filter policy, see Default IP filter policy and IP security policy.
Guideline: You should define IPSECRULE and
IPSEC6RULE statements that permit access from at least one administrative
machine. In the event that Policy Agent is unavailable, or the IP
security configuration files contain errors, the active default policy
would deny access to the IP security-enabled stack. Should this situation
occur, if you have added the appropriate IPSECRULE and IPSEC6RULE
statements to the default policy, you can still access the secure z/OS host and make the necessary
administrative changes to correct the problem.
- Set up the key required applications:
- TCP/IP
To enable IP security on a z/OS stack, make the following changes in the
TCP/IP profile:
For information on the IPCONFIG, IPCONFIG6, GLOBALCONFIG, and PORT statements, see z/OS Communications Server: IP Configuration
Reference.
- Policy Agent
For information on configuring the Policy Agent,
see Policy-based networking.
- TRMD
For information on configuring TRMD, see TRMD.
- Syslogd
For information on configuring the syslog daemon, see Configuring the syslog daemon.
- IKED
The IKED can be started from a z/OS UNIX command
line or as an MVS™ procedure.
The iked.conf file controls the overall function of the IKE daemon,
such as the following settings:
- The logging level of the IKE daemon
- The logging level of the Policy Agent when performing IP security-related
tasks on behalf of the IKE daemon
- The name of the RACF® key
ring that is owned by the IKE daemon
- Whether IKE messages are echoed to STDOUT when the daemon is started
for the UNIX System services
shell
- How long to wait when attempting to connect to the Policy Agent
- The list of certificate authorities that are acceptable for RSA
signature negotiation when the IKED is using the native certificate
service (when the Network Security Services (NSS) server is providing
the certificate service, this list is not used)
Most of the configuration parameters have a default value
and do not require modification.
Rule: If
the RSA signature method is to be used in any IKE phase 1 negotiation
and the IKED is using the native certificate service, the name of
the IKE key ring must be included in the iked.conf file. If the NSS
server is providing the certificate service, the IKE key ring name
is not needed.
Tip: If the RSA signature method
is used and the IKED is using the native certificate service, including
a list of supported certificate authorities enhances the performance
of certificate searches.
Guideline: You should not change the logging
levels of the IKE daemon (IkeSyslogLevel) and Policy Agent (PagentSyslogLevel)
from their default values for normal day-to-day operation. Higher
logging levels can affect performance and should be used for temporary
diagnostic purposes only. The default PagentSyslogLevel value 0 prevents
the IKE daemon from logging diagnostic information about its interactions
with Policy Agent. The default IkeSyslogLevel value 1 provides basic
informational and error messages. You can set the IkeSyslogLevel value
to 0 to disable IKE syslog messages entirely (for both the IKE daemon
and Policy Agent; to collect PagentSyslogLevel tracing, the IkeSyslogLevel
value must also be a nonzero value). You can set the IkeSyslogLevel
value to a higher value to identify the source of an error; for example,
if you experience problems with Security Association negotiations
that are caused by a configuration error, you might enable IkeSyslogLevel
4 (debugging information for Security Association negotiations).
For
detailed syntax and a description of the iked.conf file, and details
on starting the IKE daemon as an MVS procedure,
see z/OS Communications Server: IP Configuration
Reference.
- Define access controls for key required applications:
- TRMD
TRMD runs as an authorized program and requires RACF setup. TRMD must be able to
run as a started task and have superuser authority. For sample RACF commands, see the EZARACF
member of SEZAINST.
- Policy Agent
Policy Agent runs as an authorized program and
requires RACF setup. Policy
Agent must be able to run as a started task and have superuser authority.
For sample RACF commands, see
the EZARACF member of SEZAINST and Step 1: Configure general information.
- IKED
For the steps to prepare for running the IKE daemon, see Steps for preparing to run IP security.
- Configure the IKE daemon. See Steps for preparing to run IP security.
- (Optional) Configure the NSS daemon. If the
IKED is using the NSS certificate service for any IKEv1 or IKEv2 Security
Association negotiation, then configure the NSS daemon. The IKED must
use the NSS certificate service for any IKEv2 negotiation that uses
certificates for authentication. The IKED can use either the native
certificate service or the NSS certificate service for an IKEv1 negotiation
that uses certificates for authentication.
For more information
about the NSS daemon, see Network security services.
- (Optional) Configure additional encryption products.
- 3DES support
For 3DES (triple DES), the IP security level 3
feature, FMID JIP614K, is required.
- AES support (including AES-CBC, AES-GCM and AES-GMAC)
For AES,
the Communications Server Security Level 3 feature and the z/OS Security Level 3 feature are
required and ICSF must be started.
- FIPS 140
For IKED, NSSD, and TCP/IP to run in FIPS 140 mode,
you must first choose one of several modes of FIPS operation for ICSF
and start ICSF.
- ICSF
There are several options available on z/OS to perform encryption in hardware. The
ICSF product is required to support these various options. For a description
and information about how to configure these options, see z/OS Cryptographic Services ICSF Administrator's
Guide.
For the RACF commands that authorize ICSF, see Steps for preparing to run IP security.
- SHA2 support (including SHA2-256, SHA2-384, and SHA2-512, as well
as all corresponding HMAC-SHA2 algorithms) and AES authentication
(AES-XCBC)
For SHA2 and AES-XCBC authentication, ICSF must be started.
- Create IP security policy configuration files. After
the security needs of your installation are established, the next
step is to create one or more IP security policy configuration files.
There are two main configuration files in which IP security policy
configuration is stored:
- Stack-specific IP security configuration file
- Configured on a per-stack basis and contains only IP security
policy configuration that applies to the stacks for which it is configured.
- Common IP security configuration file
- Contains IP security policy configuration that applies to every
stack on the system and can be used to hold shared definitions.
The stack-specific file can refer to various definitions
in the common file, and can override policy definitions in the common
file.
Although Policy Agent uses LDAP to store policy for some
other policy types, IP security policy configuration is stored exclusively
in human-readable text files, either in the z/OS UNIX file
system or in an MVS data set.
These configuration files are then read by Policy Agent when it initializes
and before being installed into the stack.