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 ASCII format.
These procedures use the system names host1 and host2. Substitute the names of your systems for the names host1 and host2.
Before You Begin
You must become an administrator who is assigned the Network IPsec Management rights profile. For more information, see Using Your Assigned Administrative Rights in Securing Users and Processes in Oracle Solaris 11.4.
If you administer remotely, see Example 19, Configuring IPsec Policy Remotely by Using an ssh Connection and How to Remotely Administer ZFS With Secure Shell in Managing Secure Shell Access in Oracle Solaris 11.4 for secure remote login instructions.
You can use the /etc/inet/ike/config.sample as a template.
The rules and global parameters in this file should permit the IPsec policy in the system's ipsecinit.conf file to succeed. The following IKEv1 configuration examples work with the ipsecinit.conf examples in How to Secure Network Traffic Between Two Servers With IPsec.
### ike/config file on host1, 192.0.2.16 ## Global parameters # ## Defaults that individual rules can override. p1_xform { auth_method preshared oakley_group 14 auth_alg sha encr_alg 3des } p2_pfs 14 # ## The rule to communicate with host2 # Label must be unique { label "host1-host2" local_addr 192.0.2.16 remote_addr 192.0.2.213 p1_xform { auth_method preshared oakley_group 14 auth_alg sha256 encr_alg aes } p2_pfs 14 }
### ike/config file on host2, 192.0.2.213 ## Global Parameters # p1_xform { auth_method preshared oakley_group 14 auth_alg sha encr_alg 3des } p2_pfs 14 ## The rule to communicate with host1 # Label must be unique { label "host2-host1" local_addr 192.0.2.213 remote_addr 192.0.2.16 p1_xform { auth_method preshared oakley_group 14 auth_alg sha256 encr_alg aes } p2_pfs 14 }
# /usr/lib/inet/in.iked -c -f /etc/inet/ike/config
An AES key of at least 256 bits is a good choice. For a full description of how to create a key, see How to Generate a Symmetric Key by Using the pktool Command in Managing Encryption and Certificates in Oracle Solaris 11.4. For examples of key generation, see Example 28, Generating a Preshared Key for IKEv2 and Example 29, Using Different Local and Remote IKEv2 Preshared Keys.
## ike.preshared on host1, 192.0.2.16 #... { localidtype IP localid 192.0.2.16 remoteidtype IP remoteid 192.0.2.213 # The two subnet's shared hex key key "1011e1f2d1fd..." }
## ike.preshared on host2, 192.0.2.213 #... { localidtype IP localid 192.0.2.213 remoteidtype IP remoteid 192.0.2.16 # The two subnet's shared hex key key "1011e1f2d1fd..." }
# svcadm enable ipsec/ike:default
When IKEv1 administrators want to refresh the preshared key, they edit the files on the peer systems and restart the in.iked daemon.
First, on every system in the two subnets that uses the preshared key, the administrator changes the preshared key entry.
# pfedit -s /etc/inet/secret/ike.preshared ... { localidtype IP localid 192.0.2.0/27 remoteidtype IP remoteid 192.0.2.32/27 # The two subnet's shared hex key key "f8be7576851573..." }
Then, the administrator restarts the IKEv1 service on every system.
For information about the options to the pfedit command, see the pfedit(8) man page.
# svcadm enable ipsec/ike:default
Next Steps
If you have not completed establishing IPsec policy, return to the IPsec procedure to enable or refresh IPsec policy. For examples of IPsec policy protecting VPNs, see Protecting a VPN With IPsec. For other examples of IPsec policy, see How to Secure Network Traffic Between Two Servers With IPsec.