Configuring IPSec between z/OS and Windows
This appendix describes the steps that are used for our IPSec scenarios between z/OS and Windows.
This appendix contains the following topics:
For more information about our IPSec scenarios between z/OS systems, see 8.6, “Configuring IPSec between two z/OS systems: Pre-shared key mode using IKEv2” on page 287 and 8.7, “Configuring IPSec between two z/OS systems: RSA signature mode using IKEv1” on page 306.
C.1 IPSec between z/OS and Windows: Pre-shared Key Mode
Figure C-1 shows the setup that we implemented in this scenario.
Figure C-1 VPN between z/OS and Windows
The following steps are used to configure a VPN between z/OS image and Windows XP using Dynamic Tunnels with pre-shared keys:
1. Set up the IKE daemon
2. Set up the z/OS IPSec policy
3. Set up a Windows IPSec policy for pre-shared key mode
4. Verify that things are working
These steps are described next.
C.1.1 Setting up the IKE daemon
In terms of procedure, user ID, and other configuration choices, the IKE daemon in our case was set up using the same principles that are described in 8.5.8, “Setting up the IKED” on page 275.
Because we built our test environment using a Windows XP station, our IPSec tunnel will be implemented with IKEv1.
|
Tip: Internet Key Exchange version 2 (IKEv2) support was added in Windows Server 2008 R2 and Windows 7. Windows XP does not support it.
|
C.1.2 Setting up the z/OS IPSec policy
We used z/OSMF Configuration Assistant to create our IPSec policy file for SC33 z/OS image.
To configure the test connection, we completed the following steps:
1. We create requirement map objects called All_Traffic_PFS and Basic_Services.
2. For the TCPIPE stack of the z/OS image SC33, we assign the requirement maps to the connectivity rules: All_Traffic_PFS_Rule and Basic_Services_Rule. We created these rules for the following purposes:
– All_Traffic_PFS: A rule that creates a dynamic IPSec tunnel for all other traffic types between the z/OS image IP address (192.168.1.40) and the Windows XP IP address (10.1.100.222).
– Basic_Services: A rule that permits Resolver, DNS, Ping, and OMPROUTE-IP_V4 traffic between all IPv4 addresses to all IPv4 addresses.
3. We verified that the IKE daemon settings are correct.
4. We updated the IPSec policy of the z/OS image.
For the All_Traffic_PFS connectivity rule, we choose the security level that we created as described in “Creating a security level for PFS” on page 271.
Creating requirement map objects
To create requirement map objects using IBM Configuration Assistant, complete the following steps:
1. Start the IBM Configuration Assistant. In the Main Perspective panel, select IPSec technology. Then, click Select Action and click Configure. In the IPSec Perspective panel, click Requirement Maps. Then, click Select Action and click Add.
2. In the New Requirement Map panel, enter a name and description for the object (we entered All_Traffic_PFS). In addition, select PFS to be the IPSec - Security Level of the All_other_traffic traffic descriptor, which you can do by selecting the All_other_traffic button and selecting PFS in the Security Level drop-down menu, as shown in Figure C-2 on page 862. Click OK.
|
Tip: The PFS Security level we used in this scenario is the same level that was created in “Creating a security level for PFS” on page 271.
|
Figure C-2 New Requirement Map panel: Adding All_Traffic_PFS requirement map object
3. In the IPSec Perspective panel, click Requirement Maps. Then, click
Select Action → Add.
Select Action → Add.
4. In the New Requirement Map panel, complete the following steps:
a. Enter a name and description for the object (we used Basic_Services).
b. In the Mappings table, traffic descriptor list, click the Select a traffic descriptor option. From the drop-down menu, select Ping-IP_V4 and then set the security level to Permit.
c. Repeat the same procedure for the following traffic descriptor objects: Resolver, OMPROUTE-IP_V4, and DNS. To add extra rows to the Mappings table, click Select Action then Add Row. The final configuration of this panel should look like the configuration that is shown in Figure C-3 on page 863.
Figure C-3 Requirement Map panel: Adding Basic_Services object
d. Click OK.
The Requirement Maps panel should now include the new objects, as shown in Figure C-4.
Figure C-4 Requirement Map panel: including All_Traffic_PFS and Basic_Services objects
Creating the connectivity rules
To create the connectivity rules by using IBM Configuration Assistant, complete the following steps:
1. Navigate by clicking IPSec → z/OS Images → Image - image_name → Stack - stack_name.
2. After you select the stack name (ours is TCPIPE), add connectivity rules by clicking Select Action → Add (or click Yes if a pop-up window opens). The connectivity rule wizard - Welcome panel opens. Click Next.
3. In the Connectivity Rule: Network Topology panel, select Filtering only. This connectivity rule contains only Permit and Deny security levels. Click Next.
4. In the Connectivity Rule: Data Endpoints panel, enter a name to the rule (in our configuration, we entered Basic_Services, as shown in Figure C-5). Select both Address group buttons. For the address group on the left, select All IP V4 addresses as the local data endpoint; for the address group on the right, select All IP V4 addresses as the remote data endpoint. Click Next.
Figure C-5 New Connectivity Rule - Data Endpoints
5. In the Connectivity Rule: Requirement Map panel, click the Select an existing requirement map option, select Basic_Services from the drop-down menu, and click Next.
6. In the Connectivity Rule: Finish panel, select No, do not log filter matches. Click Finish.
Complete the following steps to add the next connectivity rule, All_Traffic_PFS:
1. Click Select Action and Add in Rules tab of the IPSec perspective panel. Click Next in the Connectivity Rules wizard - Welcome panel.
2. In the Connectivity Rule: Network Topology panel, select This connectivity rule will contain a security level using IPSec tunnels, and then, select Host to Host. Click Next.
3. In the Connectivity Rule: Data Endpoints panel, enter a name for the rule. In our configuration, we entered All_Traffic_PFS, as shown in Figure C-6. Then, enter the z/OS image IP address as the local data endpoint (in our configuration, 192.168.1.40) and the Windows XP IP address as the remote data endpoint (in our configuration, 10.1.100.222). Click Next.
Figure C-6 Connectivity Rule - Data Endpoints
4. In the Connectivity Rule: Requirement Map panel, click the Select an existing requirement map option, select All_Traffic_PFS from the drop-down menu, and click Next.
5. In the Connectivity Rule: Local Security Endpoint panel, click Next to accept the default value of using the local IP address as the local IKE identity.
6. In the Connectivity Rule: Remote Security Endpoint panel, enter the remote IKE identity. We chose to use IP address as the remote identity type and entered the Windows XP IP address (10.1.100.222). Select Shared key as the authentication method for remote IKE peers. Select ASCII and enter your shared key (in our configuration, abcde), as shown in Figure C-7. Click Next.
Figure C-7 Connectivity Rule - Remote Security Endpoint
7. In the Connectivity Rule: Finish panel, select Yes, log all filter matches. Click Finish.
The IPSec Perspective panel should now include the new rules in the Connectivity Rules table, as shown in Figure C-8.
Figure C-8 IPSec perspective panel with the All_Traffic_PFS rule included
|
Tip: Verify that the rules are in the correct order; use Select Action and then, use Move Up if necessary to change the order of the rules. Packets are compared to the connectivity rules in the order that they are listed in the table. If there is a match with the definition of this first rule, it is used. If there is no match, the second rule is checked, and so on.
For performance, order the rules to ensure that the majority of the traffic will match the first rules listed, if possible.
|
Inherent in the rules described next is the default rule that always exists for the policy agent, which is to deny everything. If no matching rule is found, the packet will be denied by this default rule.
Updating the IPSec policy of the z/OS image
Install the new policy to the z/OS image as described in 8.6.2, “Installing the configuration files” on page 298.
Run the MODIFY PAGENT,REFRESH console command to update the policy agent and IKED with the new configuration.
Checkpoint
To summarize the situation at this point in the scenario, the policy agent (PAGENT) and IKE daemons should both be running. The GUI was used to configure a set of policies that direct the z/OS host to send all traffic through a dynamic IPSec VPN using pre-shared key mode. The next step is to ensure that an equivalent setup is handled on the Windows XP workstation.
C.1.3 Setting up a Windows IPSec policy for pre-shared key mode
This section describes how to set up the Microsoft Management Console (MMC). Using MMC, we add one snap-in: IP Security Management (see Figure C-26 on page 889). IP Security Management Snap-in is used to configure the VPN connection between the Windows XP client and the z/OS server. Complete the following steps:
1. Click Start → Run from the Windows XP task bar.
2. Enter mmc in the Open field. Click OK to start the MMC.
3. In the Console 1 window, click File from the menu bar. From the menu, click Add/Remove Snap-in.
4. In the Add/Remove Snap-in window, click Add.
5. In the Add Standalone Snap-in window, select IP Security Policy Management and click Add.
6. In the Select Computer window, select Local computer and click Finish.
7. In the Add Standalone Snap-in window, click Close.
8. In the Add/Remove Snap-in window, verify that one snap-in has been added: IP Security Policies on Local Machine. Click OK.
This process completes the required settings for the MMC when implementing IPSec with pre-shared key mode.
Creating the IP security policy
Complete the following steps to create the IP Security policy on your Windows XP workstation for the VPN connection between z/OS and the Windows XP client:
1. In the MMC - IP Security Policies on Local Computer window, right-click IP Security Policies on Local Computer. In the menu, click Create IP Security Policy, as shown in Figure C-9.
Figure C-9 MMC: IP Security Policies on Local Computer
2. In the IP Security Policy Wizard - Welcome to the IP Security Policy Wizard window, click Next.
3. In the IP Security Policy Wizard - IP Security Policy Name window, enter the name for the z/OS VPN connection. (In this example, we entered zOSVPN for the VPN connection name.) Enter a description, if required. Click Next.
4. In the IP Security Policy Wizard - Requests for Secure Communication window, clear the Activate the default response rule option. Click Next.
5. In the IP Security Policy Wizard - Completing the IP Security Policy Wizard window, ensure that the Edit properties option is selected. Click Finish.
6. In the IP Policy Properties window (in this example, the zOSVPN Properties window), select the Use Add Wizard option, as shown in Figure C-10. Click Add.
Figure C-10 IP policy properties window
7. In the IP Security Wizard - Welcome to the IP Security Policy Wizard window, click Next.
8. In the Security Rule Wizard - Tunnel Endpoint window, select This rule does not specify a tunnel and click Next. By selecting this issue, the z/OS image is the endpoint of the VPN tunnel with Windows XP, and the VPN tunnel is defined as transport mode.
9. In the Security Rule Wizard - Network Type window, select All network connections. Click Next. In this example, z/OS image and Windows XP are connected with the Ethernet LAN.
|
Tip: If you want to limit the remote access connection, select Remote Access.
|
10. In the IP Security Policy Wizard - Authentication Method window, select Use this string to protect the key exchange (preshared key) and enter your shared key, as shown in Figure C-11. In this example, our shared key is abcde. Click Next.
|
Tip: Generally, do not use a shared key authentication method in a production environment. In a production environment, you should configure RSA signature as the authentication method of the IKE peers. For more information, see z/OS Communications Server: IP Configuration Guide, SC27-3650, and the sections about RSA signature mode in Chapter 8, “IP Security” on page 245.
|
Figure C-11 Authentication Method window: Using a shared key
11. In the Security Rule Wizard - IP Filter List window, click the circle for All IP Traffic, as shown in Figure C-12. Click Edit.
Figure C-12 Security Rule Wizard: IP filter list
|
Important: This IP filter works as a trigger event to establish the VPN tunnel. In this example, we choose All IP Traffic for the protocol and 192.168.1.40 for the Destination IP address. Therefore, if any IP datagram is about to issue from the Windows XP to 10.1.100.222, this IP filter detects the event and creates a VPN tunnel between the Windows XP and 192.168.1.40.
|
Figure C-13 IP filter list
13. In the Filter Properties window (see Figure C-14), select A specific IP Address in the Destination address column. Enter the IP address of the z/OS image (this IP address also represents the VPN endpoint). Select the Mirrored. Also match packets with the exact opposite source and destination addresses option. In this example, we entered 192.168.1.40 for the Destination IP address. Click OK.
Figure C-14 Filter properties
14. In the IP Filter List window, click OK.
15. In the Security Rule Wizard - IP Filter list window, click Next.
16. In the Security Rule Wizard - Filter Action window, select Require Security, as shown in Figure C-15. Click Edit.
Figure C-15 Security Rule Wizard: Filter Action
– Negotiate security, Accept unsecured communication, but always respond using IPSec
– Session key Perfect Forward Security.
Figure C-16 Require Security Properties
Use of Session key Perfect Forward Security is optional. In this example, we must select this option because the matching sample configuration in z/OS specifies to use the Session key Perfect Forward Security. Choose the topmost security method and click Edit.
18. In the Modify Security Method window (see Figure C-17), select Custom (for expert users), and click Settings.
Figure C-17 Modify security method
19. In the Custom Security Method Settings window, ensure that the Data and address integrity without encryption (AH) option is not selected.
Select Data integrity and encryption (ESP), and select SHA1 for integrity algorithm. Select 3DES for encryption algorithm. Clear the Generate a new key every Kbytes option. Select the Generate a new key every seconds option and enter 7200 in the seconds column, as shown in Figure C-18. Click OK.
Figure C-18 Custom Security Method Settings
20. In the Modify Security Method window, click OK.
21. In the Require Security Properties window, click OK.
22. In the Security Rule Wizard - Filter Action window, click Next.
23. In the Security Rule Wizard - Completing the New Rule Wizard window, clear the Edit properties option and click Finish.
24. In the zOSVPN Properties window (see Figure C-19), ensure that the All IP Traffic option is selected. Click Close.
Figure C-19 zOSVPN properties
25. Verify that the IP Security Policies on Local Computer list now includes the zOSVPN policy.
26. Right-click the zOSVPN policy and select Assign from the menu.
Figure C-20 IP Security Policies on Local Computer window with zOSVPN policy assigned
C.1.4 Verifying that things are working
Complete the following steps to verify that things are working:
1. Verify that IKED is running.
2. Verify that the policy agent has read the new policy.
3. Verify that you can run the ping command from Windows XP to the z/OS image.
4. Verify that phase 1 of the security association started.
5. Verify that phase 2 of the security association started.
6. If you encounter errors, review the syslogd messages.
Checking that IKED is running
Check the IKED procedure is running and you receive the following syslog messages:
EZD0967I IKE RELEASE CS V1R13 SERVICE LEVEL CS110518 CREATED ON May 18 2011
EZD0911I IKE CONFIG PROCESSING COMPLETE USING FILE /etc/iked.sc33.conf
EZD1061I IKE CONNECTING TO PAGENT
EZD1059I IKE CONNECTED TO PAGENT
EZD1058I IKE STATUS FOR STACK TCPIPE IS UP
EZD1068I IKE POLICY UPDATED FOR STACK TCPIPE
EZD1046I IKE INITIALIZATION COMPLETE
Checking that the policy agent read the new policy
Check that the policy agent read in the current policies. After you use FTP to move the configuration file to the z/OS image, run the following command to refresh the PAGENT (where pagent is the started task name for the policy agent):
MODIFY PAGENT,REFRESH
If no changes have been made since the last time the polices were read, you should receive a message that is similar to the message that is shown in the following example:
EZZ8771I PAGENT CONFIG POLICY PROCESSING COMPLETE FOR TCPIPE : NONE
If changes were made, you should receive a message that is similar to the message that is shown in the following example:
EZZ8771I PAGENT CONFIG POLICY PROCESSING COMPLETE FOR TCPIPE : IPSEC
Checking that the ping command is working
To verify that IP security is working, run the following ping command from Windows XP to the z/OS image:
ping 192.168.1.40
You receive output that is similar to the output that is shown in Example C-1.
Example C-1 The ping command
C:Documents and SettingsRESIDENT>ping 192.168.1.40
Pinging 192.168.1.40 with 32 bytes of data:
Negotiating IP Security.
Reply from 192.168.1.40: bytes=32 time<1ms TTL=63
Reply from 192.168.1.40: bytes=32 time<1ms TTL=63
Reply from 192.168.1.40: bytes=32 time<1ms TTL=63
Ping statistics for 192.168.1.40:
Packets: Sent = 4, Received = 3, Lost = 1 (25% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
Verifying that security association phase 2 started
To verify that a dynamic tunnel was created, run the following ipsec -y command:
ipsec -p tcpipe -y display
You should receive output that is similar to the output that is shown in Example C-2.
Example C-2 The ipsec -y command after the ping command from XP to z/OS
CS02 @ SC33:/u/cs02>ipsec -p tcpipe -y display
CS V1R13 ipsec Stack Name: TCPIPE Mon Jul 18 16:54:15 2011
Primary: Dynamic tunnel Function: Display Format: Detail
Source: Stack Scope: Current TotAvail: 1
TunnelID: Y11
Generation: 1
IKEVersion: 1.0
ParentIKETunnelID: K10
VpnActionName: PFS
LocalDynVpnRule: n/a
State: Active
HowToEncap: Transport
LocalEndPoint: 192.168.1.40
RemoteEndPoint: 10.1.100.222
LocalAddressBase: 192.168.1.40
LocalAddressPrefix: n/a
LocalAddressRange: n/a
RemoteAddressBase: 10.1.100.222
RemoteAddressPrefix: n/a
RemoteAddressRange: n/a
HowToAuth: ESP
...
PassthroughDSCP: n/a
***********************************************************************
1 entries selected
Checking the syslogd for messages
In our test environment, syslogd is the repository for all policy agent and IKE daemon messages. Enter the UNIX System Services environment by running the following command:
tso omvs
From the UNIX System Services environment, browse the log file that you defined for IKED in the SYSLOGD configuration file, as shown in the following example:
obrowse /SC33/var/syslog/2011/07/18/iked.log
Look for messages that can help you to solve the problem. If the log is empty, verify that TRMD is running and that syslogd is running with the right configuration file.
|
Tip: The IKED log file has an important role in problem determination. When implementing the IP security for the first time, ensure that the following conditions exist:
•IKED is configured to write log messages.
•TRMD is running.
•syslogd is running with the updated configuration file.
|
Verifying the security association on Windows
To verify that a dynamic tunnel is created, complete the following steps:
Figure C-21 Event Viewer Security option
2. Double-click an event. The window that is shown in Figure C-22 opens.
Figure C-22 Detailed Security event
Example C-3 shows a sample description of a Failure Audit case.
Example C-3 Description of Failure Audit
IKE security association establishment failed because peer sent invalid proposal.
Mode:
Key Exchange Mode (Main Mode)
Filter:
Source IP Address 10.1.100.222
Source IP Address Mask 255.255.255.255
Destination IP Address 192.168.1.40
Destination IP Address Mask 255.255.255.255
Protocol 0
Source Port 0
Destination Port 0
IKE Local Addr 10.1.100.222
IKE Peer Addr 192.168.1.40
Attribute:
Phase I Diffie-Hellman Group
Expected value:
2
Received value:
1
C.2 IPSec between z/OS and Windows: RSA mode
Figure C-23 shows the setup that we implemented for Dynamic Tunnels with RSA mode.
Figure C-23 VPN between z/OS and Windows
To configure a VPN between z/OS image and Windows XP using Dynamic Tunnels with RSA signature mode, complete the following steps:
1. Set up the IKE daemon.
2. Set up the x.509 certificates for RSA mode.
3. Export the Certificates from RACF Database.
4. Set up the z/OS IPSec policy for RSA.
Although we do not show you the details for every step that are necessary to implement this scenario using RSA signature mode, we include the processes that are necessary to implement the RSA.
You can implement the steps that we describe here because we introduced the minor changes that RSA mode requires on z/OS and Windows in other sections in this book. You can verify the implementation just as it was for pre-shared key mode.
We explain these steps in more detail where necessary in the following sections.
C.2.1 Setting up the IKE daemon
In terms of procedure, user ID, and other configuration choices, we set up the IKE daemon in our scenario using the same principles as described in 8.5.8, “Setting up the IKED” on page 275.
We used the _CEE_ENVFILE environment variable to set up a STDENV DD card for controlling the environment variables, as shown in Example C-4.
Example C-4 IKE daemon cataloged procedure
//IKED PROC
//IKED EXEC PGM=IKED,REGION=0K,TIME=NOLIMIT,
// PARM='ENVAR("_CEE_ENVFILE=DD:STDENV")/'
//STDENV DD PATH='/etc/iked.sc&SYSCLONE..env',PATHOPTS=(ORDONLY)
//SYSPRINT DD SYSOUT=*
//SYSOUT DD SYSOUT=*
We did not need to specify a resolver configuration file in our scenario because, as is the case with the policy agent, one server should be used for all stacks within the image.
Example C-5 shows the contents of our STDENV file, /etc/iked.sc33.env.
Example C-5 /etc/iked.sc33.env contents
IKED_FILE=/etc/iked.sc33.conf
IKED_CTRACE_MEMBER=CTIIKE00
We used the configuration file at /etc/iked.sc33.conf, as shown in Example C-6.
Example C-6 IKE daemon configuration file, /etc/iked.sc33.conf
IkeConfig
{
IkeSyslogLevel 255
PagentSyslogLevel 255
KeyRing IKED/IKED33_keyring
IkeRetries 6
IkeInitWait 2
FIPS140 no
Echo no
PagentWait 0
SMF119 ikeALL
}
The configuration file includes the following variables:
•IkeSyslogLevel and PagentSyslogLevel: We set these levels to 255 during testing to obtain helpful messages. After a successful configuration, you need to use a minimum value to avoid over-filling of the syslogd file.
•KeyRing: This variable defines the RACF key ring name that is used to hold the certificate authority certificate that is required for ISAKMP/IKE authentication. This key ring was created using the user ID for the IKED started task, IKED. If the key ring was created under any other user ID, then this user ID needs to be prepended to the key ring name using the syntax USERID/keyring. Note, however, that accessing a key ring that is owned by another user ID requires UPDATE access to IRR.DIGTCERT.LISTRING.
C.2.2 Setting up the x.509 certificates for RSA mode
Next, you must establish a certificate environment for the key exchange. Both the z/OS host and the Windows XP host must have valid certificates configured in order for the IKE exchange to establish a security association successfully.
Because the key exchange mechanism of IKE involves a direct request of the CA that is required, self-signed certificates were not an option. Instead, a CA certificate (CERTAUTH) was created using RACF, and then this certificate was used to sign a personal certificate. Then a key ring was created and both certificates were connected. The personal certificate was connected as the default. Example C-7 shows the JCL that we used.
Example C-7 JCL for defining our key ring and digital certificates
//CERTAUTH JOB MSGCLASS=X,NOTIFY=&SYSUID
//CERTAUTH EXEC PGM=IKJEFT01,DYNAMNBR=30,REGION=4096K
//*********************************************************************
//* Step 1: *
//* Create Certificate Authority Certificate for ITSO *
//*********************************************************************
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD *
SETROPTS CLASSACT(DIGTCERT,DIGTNMAP)
RACDCERT ID(IKED) addring(IKED33_keyring)
RACDCERT CERTAUTH GENCERT SUBJECTSDN(CN('SC33 CA') -
O('I.B.M Corporation') OU('ITSO') C('us')) -
NOTAFTER(DATE(2012-11-11)) -
keyusage(certsign) -
WITHLABEL('SC33 CA')
RACDCERT ID(IKED) GENCERT SUBJECTSDN(CN('WINXP RSA Conn') -
O('I.B.M Corporation') OU('ITSO') C('us')) -
WITHLABEL('WINXP RSA Conn') -
NOTAFTER(DATE(2012-11-11)) -
KEYUSAGE(HANDSHAKE) ALTNAME(IP(10.1.100.222)) -
SIGNWITH(CERTAUTH Label('SC33 CA'))
RACDCERT ID(IKED) GENCERT SUBJECTSDN(CN('SC33 RSA Conn') -
O('I.B.M Corporation') OU('ITSO') C('us')) -
NOTAFTER(DATE(2012-11-11)) -
WITHLABEL('SC33 RSA Conn') -
KEYUSAGE(HANDSHAKE) ALTNAME(IP(192.168.1.40)) -
SIGNWITH(CERTAUTH Label('SC33 CA'))
SETROPTS RACLIST(DIGTCERT,DIGTNMAP) REFRESH
RACDCERT ID(IKED) CONNECT(ID(IKED) LABEL('SC33 RSA Conn') -
RING(IKED33_keyring) USAGE(personal))
RACDCERT ID(IKED) CONNECT(ID(IKED) LABEL('WINXP RSA Conn') -
RING(IKED33_keyring) USAGE(personal))
RACDCERT ID(IKED) CONNECT(CERTAUTH LABEL('SC33 CA') -
RING(IKED33_keyring) USAGE(CERTAUTH))
PERMIT IRR.DIGTCERT.LISTRING CLASS(FACILITY) ID(IKED) ACCESS(READ)
PERMIT IRR.DIGTCERT.GENCERT CLASS(FACILITY) ID(IKED) ACCESS(READ)
setropts raclist(DIGTRING) refresh
setropts raclist(DIGTCERT) refresh
racdcert listring(IKED33_keyring) ID(IKED)
/*
C.2.3 Exporting the Certificates from RACF Database
To keep the configuration scenario simple, we used the same CA and personal certificate on the XP workstation. To do this, we exported the certificates from the RACF database into the MVS data sets using the commands that are shown in Example C-8.
Example C-8 Export job JCL
//EXPORT JOB MSGCLASS=X,NOTIFY=&SYSUID
//EXPORT EXEC PGM=IKJEFT01,DYNAMNBR=30,REGION=4096K
//*********************************************************************
//* Export the Self-signed Certificate Authority certificate *
//* from the RACF database in base-64 encoded format. This is *
//* then FTP'd to the clients so that they can verify the server *
//* certificiates when passed in the SSL exchange. *
//*********************************************************************
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD *
RACDCERT CERTAUTH EXPORT(LABEL('SC33 CA')) -
DSN('CS02.CERT.CACERT') -
FORMAT(PKCS12DER) -
PASSWORD('security')
RACDCERT ID(IKED) EXPORT(LABEL('WINXP RSA Conn')) -
DSN('CS02.CERT.XPCERT') -
FORMAT(PKCS12DER) -
PASSWORD('security')
/*
The CA (signing) certificate does not require a private key. However, the personal certificate should include the private key. Thus, we used the PKCS12DER format along with a password.
These exported files are used later during the windows IPSec implementation.
C.2.4 Setting up the z/OS IPSec policy for RSA
To simplify our RSA scenario, we used the IPSec definitions that we created earlier in this appendix and changed our IPSec connectivity rule to use RSA. For more information about the IPSec definitions, see “Setting up the z/OS IPSec policy” on page 861.
To implement RSA, we renamed and changed an IPSec Connectivity rule name to All_Traffic_RSA using the z/OSMF Configuration Assistant. Complete the following steps:
1. Open the z/OSMF Configuration Assistant.
2. In the Main Perspective window, z/OS Communications Server technologies table, select IPSec technology. Click Select Action → Configure.
3. In the IPSec Perspective window, in the IBM Configuration Assistant Navigation tree, select z/OS Images → Image - image_name → Stack - stack_name.
4. In the Connectivity Rules table, select the rule that is named All_Traffic_PFS. Click Select Action. Then, click Modify to change this connectivity rule.
5. In the Connectivity Rule: Data Endpoints window, change the name of the rule. In our configuration, we entered All_Traffic_RSA.
6. Select the Remote Security Endpoint tab. For our scenario, we used the x.500 distinguished name identity to identify the peers and used this identity for our scenario with RSA mode. In the Indicate how to authenticate the IKE peers section, select Digital signature.
7. Select the X.500 distinguished name identity in the Remote identity type field, as shown in Figure C-24. This name can be retrieved from the RACF database using the contents of the Subject’s Name field in the display output of the following command:
racdcert id(IKED) list(label('WINXP RSA Conn'))
|
Important: The racdcert display command separates the individual fields (also known as relative distinguished names (RDN) of the distinguished name (DN) with periods as delimiters. The following display pattern is used:
RDN<period>RDN<period>RDN<period>RDN
However, the syntax that is required in the IKE definition window (see Figure C-24) requires a comma (,) as a delimiter. The following coding pattern in this case is used:
RDN<comma>RDN<comma>RDN<comma>RDN
Therefore, the display output of Subject’s Name is used:
CN=WINXP RSA Conn.OU=ITSO.O=I.B.M Corporation.C=us
This line must be converted to the following (using commas instead of periods) when it is defined as an IKE identity in the IBM Configuration Assistant, as shown in the following example:
CN=WINXP RSA Conn,OU=ITSO,O=I.B.M Corporation,C=us
The IBM Configuration Assistant GUI builds the iked.conf file from these definitions.
|
Figure C-24 Connectivity Rule: Remote Security Endpoint window
8. Click the Connectivity Rule: Additional Settings tab and select Yes, log all filter matches. Click OK.
9. Back in the IPSec perspective window, select the rule named All_Traffic_RSA. Click Select Action → Modify. Then, click the Local Security Endpoint tab. Select the X.500 distinguished name identity type, and write the local identity as shown in the following example:
CN=SC33 RSA Conn,OU=ITSO,O=I.B.M Corporation,C=us
Click OK. Click Apply Changes, and then, click the Rules tab.
The IPSec Perspective window now includes the new rules in the Connectivity Rules table, as shown in Figure C-25.
Figure C-25 IPSec perspective window with the All_Traffic_RSA rule included
|
Tip: Verify that the rules are in the correct order; click Select Action and click Move Up if necessary to change the order of the rules. Packets are checked against the connectivity rules in the order they appear in the table. If there is a match with the definition of this first rule, it is used. If there is no match, the second rule is checked, and so on.
For performance, order the rules to ensure the majority of the traffic will match the first rules listed if possible.
|
Inherent in the rules that we describe next is the default rule that always exists for the policy agent, which is to deny everything. If no matching rule is found, the packet is denied by this default rule.
Updating the IPSec policy of the z/OS image
Install the new policy to the z/OS image as described in 8.4, “Working with the z/OS Communications Server Network Management Interface” on page 263. Run the MODIFY PAGENT,REFRESH console command to update the policy agent and IKED with the new configuration.
Checkpoint
To summarize the situation at this point in the scenario, the policy agent (PAGENT) and IKE daemons should both be running. The GUI was used to configure a set of policies that direct the z/OS host to send all traffic through a dynamic IPSec VPN. A set of certificates was created and IKE is pointing to the key ring that contains those certificates in the RACF database. The next step is to ensure that an equivalent setup is handled on the Windows XP workstation.
C.3 Setting up a Windows IPSec policy for RSA mode
This section describes how to set up the MMC. The MMC has the following snap-ins added:
•Certificates
The Certificates Snap-in is used to import the certificates that are created by z/OS RACF.
•IP Security Management
The IP Security Management Snap-in is used to configure the VPN connection between the Windows XP client and the z/OS server.
To set up a Windows IPSec policy for RSA mode, complete the following steps:
1. Click Start → Run from the Windows XP task bar.
2. Enter mmc in the Open field. Click OK to start the MMC.
3. In the Console 1 window, click File → Add/Remove Snap-in.
4. In the Add/Remove Snap-in window, click the Standalone tab and then, click Add.
5. In the Add Standalone Snap-in window, select Certificates, and click Add.
6. In the Certificates Snap-in window, select Computer account, and click Next.
7. In the Select Computer window, select Local computer, and click Finish.
8. In the Add Standalone Snap-in window, select IP Security Policy Management, and click Add.
9. In the Select Computer window, select Local computer, and click Finish.
10. In the Add Standalone Snap-in window, click Close.
11. In the Add/Remove Snap-in window, click OK.
12. In the Console1 window, verify that the following snap-ins are added, as shown in Figure C-26:
– (Certificates (Local computer)
– IP Security Policies on Local Machine)
Figure C-26 Console1 window with the new snap-ins added
C.3.1 Importing the z/OS certificates into Windows XP
This section describes how to import the following certificates that are created by z/OS RACF:
•Trusted Root CA certificate
•Client certificate
Before installing the client certificate on the Windows XP client, Windows XP needs to entrust the Trusted Root CA. In this case, z/OS RACF acts as a Trusted Root CA to provide certificates to the clients. After Windows XP entrusts the CA, the client certificate can be installed on the Windows XP client. This client certificate is used for identity authentication in the IKE phase 1 negotiation.
z/OS RACF creates an individual client certificate for each client because the client certificate includes the client IP address information. This IP address information is used to verify the required authority on each client to connect to z/OS.
We transferred the certificate files in z/OS image that we exported earlier in this scenario as described in “Exporting the Certificates from RACF Database” on page 885 using FTP, as shown in Example C-9.
Example C-9 Transfer the certificates to the Windows XP client
C:Documents and SettingsRESIDENT>ftp wtsc33.itso.ibm.com
Connected to wtsc33.itso.ibm.com.
220-FTPMVS1 IBM FTP CS V1R13 at wtsc33.ITSO.IBM.COM, 16:16:48 on 2011-07-19.
220 Connection will close if idle for more than 5 minutes.
User (wtsc33.itso.ibm.com:(none)): cs02
331 Send password please.
Password:
230 CS02 is logged on. Working directory is "CS02.".
ftp> bin
200 Representation type is Image
ftp> get cert.xpcert xpclient.p12
200 Port request OK.
125 Sending data set CS02.CERT.XPCERT
250 Transfer completed successfully.
ftp: 2492 bytes received in 0.04Seconds 62.30Kbytes/sec.
ftp> get cert.cacert racfca.p12
200 Port request OK.
125 Sending data set CS02.CERT.CACERT
250 Transfer completed successfully.
ftp: 1718 bytes received in 0.01Seconds 171.80Kbytes/sec.
ftp>.
|
Tip: You must change the representation type of the FTP to image before running the get commands.
|
To import the z/OS certificates into Windows XP, complete the following steps:
1. In the MMC Console1 window, click the plus sign (+) next to Certificates (Local Computer) to show the list of available tasks.
2. Right-click Trusted Root Certification Authorities and select All Tasks from the menu. Select Import from the next menu and click it.
3. In the Certificate Import Wizard window, click Next.
4. In the Certificate Import Wizard - File to Import window, specify the Trusted Root CA file name (in this example, we choose C:
acfca.p12 for the Trusted Root CA file). Click Next.
5. Complete the following steps in the Certificate Import Wizard:
a. Enter the password that you gave to the CA certificate. We entered security as the password.
b. Do not select the Mark this key as exportable option.
c. Select Place all certificates in the following store.
d. Indicate that Trusted Root Certification Authorities is shown in the certificate store column.
e. Click Finish in the Completing the Certificate Import Wizard window.
You receive a message that indicates that the import was successful.
6. In the MMC window (see Figure C-27), click the plus sign (+) that is next to Trusted Root Certification Authorities, and then, click Certificates. Scroll down and verify that your Trusted Root CA is installed in the list. In our scenario, SC33 CA is installed as a Trusted Root CA.
Figure C-27 The Certificates list with the new SC33 CA certificate
7. Right-click Personal and choose All Tasks from the menu. Choose Import from the next menu and select it.
8. In the Certificate Import Wizard, click Next.
9. In the Certificate Import Wizard - File to Import window, click Browse and specify the client certificate file name (in this example, we choose C:xpclient.p12 for the client certificate file). Click Next.
10. Complete the following steps in the Certificate Import Wizard:
a. Enter the password you gave to the certificate. We entered security as the password. Do not select the Mark the private key as exportable option.
b. Ensure that the Place all certificates in the following store option is selected and that Personal is shown in the certificate store column. Click Next.
c. Click Finish in the Completing the Certificate Import Wizard window.
You receive a message that indicates that the import was successful.
11. In the MMC window (see Figure C-28), click the plus sign (+) that is next to Personal, and then, click Certificates. Scroll down and verify that your client certificate is installed in the list. In this example, WinXP RSA Conn is installed as a client certificate.
Figure C-28 Personal certificates list with WINXP RSA Conn certificate
C.3.2 Creating the IP security policy
To create the IP Security policy on the Windows XP workstation for the VPN connection between z/OS and the Windows XP client, complete the following steps:
1. In the MMC - IP Security Policies on Local Computer window (see Figure C-29), right-click IP Security Policies on Local Computer. In the menu, click Create IP Security Policy.
Figure C-29 MMC: IP Security Policies on Local Computer
2. In the IP Security Policy Wizard - Welcome to the IP Security Policy Wizard, click Next.
3. In the IP Security Policy Wizard - IP Security Policy Name window, enter the name for the z/OS VPN connection. In this example, we entered zOSVPN for the VPN connection name. Enter a description (optional). Click Next.
4. In the IP Security Policy Wizard - Requests for Secure Communication window, clear the the Activate the default response rule option. Click Next.
5. In the IP Security Policy Wizard - Completing the IP Security Policy Wizard, ensure that Edit properties is selected. Click Finish.
6. In the IP Policy Properties window (in this example, the zOSVPN Properties window), select Use Add Wizard. Click Add.
7. In the IP Security Wizard - Welcome to the IP Security Policy Wizard window, click Next.
8. In the Security Rule Wizard - Tunnel Endpoint window, select the This rule does not specify a tunnel option and click Next. This selection means that the z/OS image is the endpoint of the VPN tunnel with Windows XP, and the VPN tunnel is defined as transport mode.
9. In the Security Rule Wizard - Network Type window, select All network connections. Click Next. In this example, z/OS image and Windows XP are connected with the Ethernet LAN.
|
Tip: If you want to limit the remote access connection, select Remote Access.
|
10. In the IP Security Policy Wizard - Authentication Method window (see Figure C-30), select the Use a certificate from this certificate authority (CA) option. Click Browse and then, select the CA certificate that signed the z/OS server certificate. Click Next.
Figure C-30 Authentication Method window: using a certificate option
11. In the Security Rule Wizard - IP Filter List window, select All IP Traffic. Click Edit.
|
Important: Notice that this IP filter works as a trigger event to establish the VPN tunnel. In this example, we choose All IP Traffic for the protocol and 192.168.1.40 for the Destination IP address. This means that if any IP datagram is about to issue from the Windows XP to 10.1.100.222, this IP filter detects the event and creates a VPN tunnel between the Windows XP and 192.168.1.40.
|
12. In the IP filter List window, click Edit.
13. In the Filter Properties window (see Figure C-31), select A specific IP Address in the Destination address column. Enter the IP address of the z/OS image. (This IP address also means the VPN endpoint.) Select the Mirrored. Also match packets with the exact opposite source and destination addresses option. (In this example, we entered 192.168.1.40 for the Destination IP address.) Click OK.
Figure C-31 Filter properties
14. In the IP Filter List window, click OK.
15. In the Security Rule Wizard - IP Filter list window, click Next.
16. In the Security Rule Wizard - Filter Action window, select Require Security. Click Edit.
17. In the Require Security Properties window (see Figure C-32 on page 895), make the following selections:
– Negotiate security
– Accept unsecured communication, but always respond using IPSec
– Session key Perfect Forward Security.
Use of Session key Perfect Forward Security is optional. In this example, we must select it because the matching sample configuration in z/OS specifies to use the Session key Perfect Forward Security. Select the topmost security method and click Edit.
Figure C-32 Require Security Properties
18. In the Modify Security Method window, choose Custom (for expert users). Click Settings.
19. In the Custom Security Method Settings window, ensure that the Data and address integrity without encryption (AH) option is not selected.
20. Select Data integrity and encryption (ESP), and select SHA1 for integrity algorithm. Select 3DES for encryption algorithm. Clear the Generate a new key every Kbytes option. Select the Generate a new key every seconds option and enter 7200 in the seconds column. Click OK.
21. In the Modify Security Method window, click OK.
22. In the Require Security Properties window, click OK.
23. In the Security Rule Wizard - Filter Action window, click Next.
24. In the Security Rule Wizard - Completing the New Rule Wizard window, clear the Edit properties option and click Finish.
25. In the zOSVPN Properties window, ensure that the All IP Traffic option is selected. Click Close.
26. Verify that the IP Security Policies on Local Computer list now includes the zOSVPN policy.
27. Right-click the zOSVPN policy and select Assign from the menu.
Figure C-33 IP Security Policies on Local Computer window with zOSVPN policy assigned
C.3.3 Verifying that IPSec tunnel is working
To verify the IPSec tunnel is working as expected, complete the following steps as was done for the IPSec tunnel with pre-shared key mode:
1. Verify that IKED is running.
2. Verify that the policy agent includes read the new policy.
3. Verify that you succeed in running the ping command from the Windows XP to the z/OS image.
4. Verify that phase 1 of the security association started.
5. If you have problems, check the syslogd messages.
For more information about the verification steps, see “Verifying that things are working” on page 879.
Checking that IKED is running
Verify that the IKED procedure is running and you are receiving syslog messages, as shown in the following messages:
EZD0967I IKE RELEASE CS V1R13 SERVICE LEVEL CS110518 CREATED ON May
18 2011
EZD0911I IKE CONFIG PROCESSING COMPLETE USING FILE /etc/iked.sc33.conf
EZD1061I IKE CONNECTING TO PAGENT
EZD1059I IKE CONNECTED TO PAGENT
EZD1058I IKE STATUS FOR STACK TCPIPE IS UP
EZD1068I IKE POLICY UPDATED FOR STACK TCPIPE
EZD1046I IKE INITIALIZATION COMPLETE
Checking that the policy agent has read the new policy
First, check that the policy agent has read in the current policies. After you move the configuration file by using FTP to the z/OS image, use the following command to refresh the PAGENT (where pagent is the started task name for the policy agent):
MODIFY PAGENT,REFRESH
If no changes were made since the last time that the polices were read, you receive the following message:
EZZ8771I PAGENT CONFIG POLICY PROCESSING COMPLETE FOR TCPIPE : NONE
If changes were made, then you receive the following message:
EZZ8771I PAGENT CONFIG POLICY PROCESSING COMPLETE FOR TCPIPE : IPSEC
Checking that the ping command is working
To verify that IP security is working, use the following ping command in Windows XP to the z/OS image:
ping 192.168.1.40
You receive output similar to the output that is shown in Example C-10.
Example C-10 Using the ping command
C:Documents and SettingsRESIDENT>ping 192.168.1.40
Pinging 192.168.1.40 with 32 bytes of data:
Negotiating IP Security.
Reply from 192.168.1.40: bytes=32 time<1ms TTL=63
Reply from 192.168.1.40: bytes=32 time<1ms TTL=63
Reply from 192.168.1.40: bytes=32 time<1ms TTL=63
Ping statistics for 192.168.1.40:
Packets: Sent = 4, Received = 3, Lost = 1 (25% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
Verifying that security association phase 1 has started
To verify that an IPSec tunnel was created, run the ipsec -k command, as shown in Example C-11:
ipsec -p tcpipe -k display
Example C-11 Using the ipsec -k command after the ping command from XP to z/OS
CS02 @ SC33:/u/cs02>ipsec -p tcpipe -k display CS V1R13 ipsec Stack Name: TCPIPE Tue Jul 19 13:17:39 2011
Primary: IKE tunnel Function: Display Format: Detail
Source: IKED Scope: Current TotAvail: n/a
TunnelID: K1
Generation: 1
IKEVersion: 1.0
KeyExchangeRuleName: All_Traffic_RSA~5
KeyExchangeActionName: All_Traffic_RSA
LocalEndPoint: 192.168.1.40
LocalIDType: ID_DER_ASN1_DN
LocalID: CN=SC33 RSA Conn,OU=ITSO,O=I.B.M Corporation,C=us
RemoteEndPoint: 10.1.100.222
RemoteIDType: ID_DER_ASN1_DN
RemoteID: CN=WINXP RSA Conn,OU=ITSO,O=I.B.M Corporation,C=us
ExchangeMode: Main
State: DONE
AuthenticationAlgorithm: HMAC-SHA1
EncryptionAlgorithm: 3DES-CBC
KeyLength: n/a
PseudoRandomFunction: HMAC-SHA1
DiffieHellmanGroup: 2
LocalAuthenticationMethod: RsaSignature
RemoteAuthenticationMethod: RsaSignature
InitiatorCookie: 0x6790104CA1ED3750
ResponderCookie: 0xF8067AB04635BA94
Lifesize: 0K
CurrentByteCount: 608b
Lifetime: 480m
LifetimeRefresh: 2011/07/19 19:53:51
LifetimeExpires: 2011/07/19 20:03:30
ReauthInterval: 480m
ReauthTime: 2011/07/19 19:53:51
Role: Responder
AssociatedDynamicTunnels: 0
NATTSupportLevel: None
NATInFrntLclScEndPnt: No
NATInFrntRmtScEndPnt: No
zOSCanInitiateP1SA: Yes
AllowNat: No
RmtNAPTDetected: No
RmtUdpEncapPort: n/a
***********************************************************************
Checking the syslogd for messages
With TRMD running, syslogd is the repository for all policy agent and IKE daemon messages. Enter the UNIX System Services environment by running the following command:
tso omvs
From the UNIX System Services environment, browse the log file that you defined for IKED in the IKED configuration file, as shown in the following example:
obrowse /SC33/var/syslog/2011/07/19/iked.log
Look for messages that can help you to solve the problem. If the log is empty, verify that TRMD is running and that syslogd is running with the correct configuration file.
|
Tip: The IKED log file has an important role in problem determination. When implementing IP security for the first time, verify the following items:
•IKED is configured to write log messages.
•TRMD is running.
•The syslogd is running with the correct configuration file.
|
Verifying the security association on Windows
To verify that a dynamic tunnel was created. In the Event Viewer window (see Figure C-34), select Security.
Figure C-34 Event Viewer - Security option
Double-click the first event in the list. A window opens, as shown in Figure C-35.
Figure C-35 Detailed security event
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.