Skip Navigation Links | |
Exit Print View | |
System Administration Guide: IP Services Oracle Solaris 11 Express 11/10 |
1. Planning an IPv4 Addressing Scheme (Tasks)
2. Planning an IPv6 Addressing Scheme (Overview)
3. Planning an IPv6 Network (Tasks)
4. Configuring TCP/IP Network Services and IPv4 Addressing (Tasks)
5. Enabling IPv6 on a Network (Tasks)
6. Administering a TCP/IP Network (Tasks)
8. Troubleshooting Network Problems (Tasks)
9. TCP/IP and IPv4 in Depth (Reference)
12. Planning for DHCP Service (Tasks)
13. Configuring the DHCP Service (Tasks)
14. Administering DHCP (Tasks)
15. Configuring and Administering the DHCP Client
16. Troubleshooting DHCP (Reference)
17. DHCP Commands and Files (Reference)
18. IP Security Architecture (Overview)
20. IP Security Architecture (Reference)
21. Internet Key Exchange (Overview)
How to Display Available Groups and Algorithms for Phase 1 IKE Exchanges
Configuring IKE With Preshared Keys (Task Map)
Configuring IKE With Preshared Keys
How to Configure IKE With Preshared Keys
How to Refresh IKE Preshared Keys
How to View IKE Preshared Keys
How to Add an IKE Preshared Key for a New Policy Entry in ipsecinit.conf
Configuring IKE With Public Key Certificates (Task Map)
Configuring IKE With Public Key Certificates
How to Configure IKE With Self-Signed Public Key Certificates
How to Configure IKE With Certificates Signed by a CA
How to Generate and Store Public Key Certificates on Hardware
How to Handle a Certificate Revocation List
Configuring IKE for Mobile Systems (Task Map)
Configuring IKE for Mobile Systems
How to Configure IKE for Off-Site Systems
Configuring IKE to Find Attached Hardware (Task Map)
Configuring IKE to Find Attached Hardware
How to Configure IKE to Find the Sun Crypto Accelerator 1000 Board
How to Configure IKE to Find the Sun Crypto Accelerator 4000 Board
Changing IKE Transmission Parameters (Task Map)
Changing IKE Transmission Parameters
How to Change the Duration of Phase 1 IKE Key Negotiation
23. Internet Key Exchange (Reference)
24. IP Filter in Oracle Solaris (Overview)
Part IV Networking Performance
26. Integrated Load Balancer Overview
27. Configuration of Integrated Load Balancer Tasks
28. Virtual Router Redundancy Protocol (Overview)
29. VRRP Configuration (Tasks)
30. Implementing Congestion Control
Part V IP Quality of Service (IPQoS)
31. Introducing IPQoS (Overview)
32. Planning for an IPQoS-Enabled Network (Tasks)
33. Creating the IPQoS Configuration File (Tasks)
34. Starting and Maintaining IPQoS (Tasks)
35. Using Flow Accounting and Statistics Gathering (Tasks)
Preshared keys is the simplest authentication method for IKE. If you are configuring two systems to use IKE, and you are the administrator for both of the systems, using preshared keys is a good choice. However, unlike public key certificates, preshared keys are tied to particular IP addresses. You can associate preshared keys with subnets or ranges of IP addresses. Preshared keys cannot be used with mobile systems or systems that might be renumbered, unless the renumbering is within the previously determined range of IP addresses. Also, when you use preshared keys, you cannot offload IKE computations to attached hardware.
The IKE implementation offers algorithms whose keys vary in length. The key length that you choose is determined by site security. In general, longer keys provide more security than shorter keys.
In this procedure, you generate keys in hexadecimal format. You can translate a hexadecimal key into ASCII format to interoperate with other vendors, as shown in Example 22-1. Alternatively, you can use an ASCII passphrase, as shown in Example 22-2. Also, you can use one key with a range of systems by using an IP prefix in the IKE rule. For an example, see Example 22-3.
These procedures use the system names enigma and partym. Substitute the names of your systems for the names enigma and partym.
Note - To use IPsec with labels on a Trusted Extensions system, see the extension of this procedure in How to Apply IPsec Protections in a Multilevel Trusted Extensions Network in Oracle Solaris Trusted Extensions Configuration and Administration.
For more information, see How to Obtain Administrative Rights in System Administration Guide: Security Services.
Note - Logging in remotely exposes security-critical traffic to eavesdropping. Even if you somehow protect the remote login, the security of the system is reduced to the security of the remote login session. Use the ssh command for a secure remote login. For an example, see Example 19-1.
The rules and global parameters in this file should permit the IPsec policy in the system's ipsecinit.conf file to succeed. The following ike/config examples work with the ipsecinit.conf examples in How to Secure Traffic Between Two Systems With IPsec.
### ike/config file on enigma, 192.168.116.16 ## Global parameters # ## Phase 1 transform defaults p1_lifetime_secs 14400 p1_nonce_len 40 # ## Defaults that individual rules can override. p1_xform { auth_method preshared oakley_group 5 auth_alg sha encr_alg des } p2_pfs 2 # ## The rule to communicate with partym # Label must be unique { label "enigma-partym" local_addr 192.168.116.16 remote_addr 192.168.13.213 p1_xform { auth_method preshared oakley_group 5 auth_alg sha1 encr_alg aes } p2_pfs 5 }
Note - All arguments to the auth_method parameter must be on the same line.
### ike/config file on partym, 192.168.13.213 ## Global Parameters # p1_lifetime_secs 14400 p1_nonce_len 40 # p1_xform { auth_method preshared oakley_group 5 auth_alg sha encr_alg des } p2_pfs 2 ## The rule to communicate with enigma # Label must be unique { label "partym-enigma" local_addr 192.168.13.213 remote_addr 192.168.116.16 p1_xform { auth_method preshared oakley_group 5 auth_alg sha1 encr_alg aes } p2_pfs 5 }
# /usr/lib/inet/in.iked -c -f /etc/inet/ike/config
If your site has a random number generator, use that generator. On a Solaris system, you can use the od command. For example, the following command prints two lines of hexadecimal numbers:
% od -X -A n /dev/random | head -2 f47cb0f4 32e14480 951095f8 2b735ba8 0a9467d0 8f92c880 68b6a40e 0efe067d
For an explanation of the od command, see How to Generate Random Numbers on a Solaris System and the od(1) man page.
Note - Other operating systems can require ASCII keying material. To generate the identical key in hexadecimal and ASCII formats, see Example 22-1.
f47cb0f432e14480951095f82b735ba80a9467d08f92c88068b6a40e
The authentication algorithm in this procedure is SHA–1, as shown in Step 3. The size of the hash, that is, the size of the authentication algorithm's output, determines the minimum recommended size of a preshared key. The output of the SHA–1 algorithm is 160 bits, or 40 characters. The example key is 56 characters long, which provides additional keying material for IKE to use.
Put the preshared key in each file.
# ike.preshared on enigma, 192.168.116.16 #… { localidtype IP localid 192.168.116.16 remoteidtype IP remoteid 192.168.13.213 # enigma and partym's shared key in hex (192 bits) key f47cb0f432e14480951095f82b735ba80a9467d08f92c88068b6a40e }
# ike.preshared on partym, 192.168.13.213 #… { localidtype IP localid 192.168.13.213 remoteidtype IP remoteid 192.168.116.16 # partym and enigma's shared key in hex (192 bits) key f47cb0f432e14480951095f82b735ba80a9467d08f92c88068b6a40e }
Note - The preshared keys on each system must be identical.
Example 22-1 Generating Identical Keying Material for Two Systems With Different Operating Systems
Solaris IPsec interoperates with other operating systems. If your system is communicating with a system that requires ASCII preshared keys, you need to generate one key in two formats, hexadecimal and ASCII.
In this example, the Solaris system administrator wants 56 characters of keying material. The administrator uses the following command to generate a hexadecimal key from an ASCII passphrase. The option -tx1 prints the bytes one at a time on all Solaris systems.
# /bin/echo "papiermache with cashews and\c" | od -tx1 | cut -c 8-55 | \ tr -d '\n' | tr -d ' ' | awk '{print}' 7061706965726d616368652077697468206361736865777320616e64
By removing the offsets and concatenating the hexadecimal output, the hexadecimal key for the Solaris system is 7061706965726d616368652077697468206361736865777320616e64. The administrator places this value in the ike.preshared file on the Solaris system.
# Shared key in hex (192 bits) key 7061706965726d616368652077697468206361736865777320616e64
On the system that requires ASCII preshared keys, the passphrase is the preshared key. The Solaris system administrator telephones the other administrator with the passphrase, papiermache with cashews and.
Example 22-2 Using ASCII Keying Material for IKE Preshared Keys
In this example, the Solaris system administrator wants to use a passphrase to create the keying material for the IKE preshared key. The administrator uses special characters to complicate the passphrase. The string is typed on one line. The backslash escapes the double quotation mark that is part of the passphrase.
First, the administrator places the passphrase in the preshared rule on the enigma system.
#… { localidtype IP localid 192.168.116.16 remoteidtype IP remoteid 192.168.13.213 # enigma and partym's shared passphrase for keying material key "LOooong key Th@t m^st Be Ch*angEd \"reguLarLy." }
Then, the administrator places the passphrase in the preshared rule on the partym system.
#… { localidtype IP localid 192.168.13.213 remoteidtype IP remoteid 192.168.116.16 # partym and enigma's shared passphrase for keying material key "LOooong key Th@t m^st Be Ch*angEd \"reguLarLy." }
Example 22-3 Using an IKE Preshared Key to Protect a Range of Systems
In this example, the Solaris system administrator wants to use one IKE preshared key to protect a range of hosts. The administrator uses a passphrase to generate the keying material as well as subnet addresses to specify the range of hosts that use the IKE preshared key.
First, the administrator places the following IKE rule on every host in the 192.168.116.0/24 subnet.
#… { localidtype IP localid 192.168.116.0/24 remoteidtype IP remoteid 192.168.13.0/24 # enigma and partym's shared passphrase for keying material key "LOooong key Th@t m^st Be Ch*angEd \"reguLarLy." }
The administrator places the following IKE rule on every host in the 192.168.13.0/24 subnet.
#… { localidtype IP localid 192.168.116.0/24 remoteidtype IP remoteid 192.168.13.0/24 # partym and enigma's shared passphrase for keying material key "LOooong key Th@t m^st Be Ch*angEd \"reguLarLy." }
This procedure assumes that you want to replace an existing preshared key at regular intervals.
For more information, see How to Obtain Administrative Rights in System Administration Guide: Security Services.
Note - Logging in remotely exposes security-critical traffic to eavesdropping. Even if you somehow protect the remote login, the security of the system is reduced to the security of the remote login session. Use the ssh command for a secure remote login. For an example, see Example 19-1.
For details, see How to Generate Random Numbers on a Solaris System. If you are generating a preshared key for a Solaris system that is communicating with an operating system that requires ASCII, see Example 22-1.
For example, on the hosts enigma and partym, you would replace the value of key in the /etc/inet/secret/ike.preshared file with a new number of the same length.
# svcadm refresh ike
By default, the ikeadm command prevents you from viewing the actual keys in a dump of a Phase 1 SA. Viewing the keys is useful during debugging.
To view the actual keys, you must increase the privilege level of the daemon. For a description of the privilege levels, see IKE Administration Command.
IKE is configured and the ike service is running.
# ikeadm ikeadm> dump preshared
# svcprop -p config/admin_privilege ike base # svccfg -s ike setprop config/admin_privilege=keymat
# svcadm refresh ike ; svcadm restart ike
# svcprop -p config/admin_privilege ike keymat
# svccfg -s ike setprop config/admin_privilege=base
# svcadm refresh ike ; svcadm restart ike
If you add IPsec policy entries while IPsec and IKE are running, you restart the policy service and refresh the ike service after you add the new keys.
This procedure assumes the following:
The enigma system is set up as described in How to Configure IKE With Preshared Keys.
The enigma system is going to protect its traffic with a new system, ada.
The in.iked daemon is running on both systems.
The systems' interfaces are included as entries in the /etc/hosts file on both systems. The following entry is an example.
192.168.15.7 ada 192.168.116.16 enigma
This procedure also works with an IPv6 address. IPv6 addresses are placed in the /etc/hosts file.
You have added a new policy entry to the /etc/inet/ipsecinit.conf file on both systems. The entries appear similar to the following:
# ipsecinit.conf file for enigma {laddr enigma raddr ada} ipsec {auth_algs any encr_algs any sa shared}
# ipsecinit.conf file for ada {laddr ada raddr enigma} ipsec {auth_algs any encr_algs any sa shared}
You have verified the syntax of the /etc/inet/ipsecinit.conf file on both systems by using the following:
# ipsecconf -c -f /etc/inet/ipsecinit.conf
For more information, see How to Obtain Administrative Rights in System Administration Guide: Security Services.
Note - Logging in remotely exposes security-critical traffic to eavesdropping. Even if you somehow protect the remote login, the security of the system is reduced to the security of the remote login session. Use the ssh command for a secure remote login. For an example, see Example 19-1.
For details, see How to Generate Random Numbers on a Solaris System. If you are generating a preshared key for a Solaris system that is communicating with an operating system that requires ASCII, see Example 22-1.
You both need to add the same preshared key at the same time. Your key is only as safe as the safety of your transmission mechanism. An out-of-band mechanism, such as registered mail or a protected fax machine, is best. You can also use an ssh session to administer both systems.
### ike/config file on enigma, 192.168.116.16 ## The rule to communicate with ada {label "enigma-to-ada" local_addr 192.168.116.16 remote_addr 192.168.15.7 p1_xform {auth_method preshared oakley_group 5 auth_alg sha1 encr_alg blowfish} p2_pfs 5 }
### ike/config file on ada, 192.168.15.7 ## The rule to communicate with enigma {label "ada-to-enigma" local_addr 192.168.15.7 remote_addr 192.168.116.16 p1_xform {auth_method preshared oakley_group 5 auth_alg sha1 encr_alg blowfish} p2_pfs 5 }
Note - If you created an ASCII key, place it in quotation marks as the argument to the key parameter.
# ike.preshared on enigma for the ada interface # { localidtype IP localid 192.168.116.16 remoteidtype IP remoteid 192.168.15.7 # enigma and ada's shared key in hex (32 - 448 bits required) key 8d1fb4ee500e2bea071deb2e781cb48374411af5a9671714672bb1749ad9364d }
# ike.preshared on ada for the enigma interface # { localidtype IP localid 192.168.15.7 remoteidtype IP remoteid 192.168.116.16 # ada and enigma's shared key in hex (32 - 448 bits required) key 8d1fb4ee500e2bea071deb2e781cb48374411af5a9671714672bb1749ad9364d }
# svcadm restart policy
# svcadm refresh ike
Example 22-4 Adding an IKE Preshared Key for a New IPsec Policy Entry
In the following example, the administrator is adding preshared key to a Solaris system that is not running the current Solaris release. The administrator follows the preceding procedure to modify the ike/config and ike.preshared files, and to generate keys and contact the remote system. The administrator uses different commands to read the new IPsec policy and IKE rules into the kernel.
Before generating the new key, the administrator sets the privilege level of the in.iked daemon to 2.
# pkill in.iked # /usr/lib/inet/in.iked -p 2 Setting privilege level to 2
After sending the key to the other system and adding the new key to the system, the administrator lowers the privilege level.
# ikeadm set priv base
Then, the administrator reads the new IPsec policy into the kernel.
# ipsecconf -a /etc/inet/ipsecinit.conf
Finally, the administrator reads the new IKE rules into the kernel.
# ikeadm read rules
If the preshared keys on the communicating systems are not identical, the systems cannot authenticate.
IPsec has been configured and is enabled between the two systems that you are testing.
# svcprop -p config/admin_privilege ike base
Then, refresh and restart the ike service.
# svccfg -s ike setprop config/admin_privilege=keymat # svcadm refresh ike ; svcadm restart ike # svcprop -p config/admin_privilege ike keymat
# ikeadm dump preshared PSKEY: Preshared key (24 bytes): f47cb…/192 LOCIP: AF_INET: port 0, 192.168.116.16 (enigma). REMIP: AF_INET: port 0, 192.168.13.213 (partym).
If the preshared keys are not identical, replace one key with the other key in the /etc/inet/secret/ike.preshared file.
# svccfg -s ike setprop config/admin_privilege=base # svcadm restart ike