Go to main content

Securing the Network in Oracle® Solaris 11.3

Exit Print View

Updated: September 2018
 
 

How to Configure IKEv2 With Preshared Keys

Substitute the names of your systems for the names host1 and host2 in this procedure. You configure both IKE endpoints.

Before You Begin

You must become an administrator who is assigned the Network IPsec Management rights profile. You must be typing in a profile shell. For more information, see Using Your Assigned Administrative Rights in Securing Users and Processes in Oracle Solaris 11.3.

If you administer remotely, see Example 31, 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.3 for secure remote login instructions.

  1. On each system, edit the /etc/inet/ike/ikev2.config file.
    # pfedit /etc/inet/ike/ikev2.config
  2. In the file, create a rule that uses preshared keys.

    Note -  You will create the keys in Step 5.

    The rules and global parameters in this file must manage the keys in the IPsec policy in the system's ipsecinit.conf file. The following IKEv2 configuration examples manage the keys of the ipsecinit.conf examples in How to Secure Network Traffic Between Two Servers With IPsec.

    1. For example, modify the ikev2.config file on the host1 system:

      Note - This example shows two transforms in the global parameters section. A peer can be configured with either of these transforms. To require a particular transform, include that transform in the rule.
      ### ikev2.config file on host1, 192.0.2.16
      
      ## Global parameters
      # This default value will apply to all transforms that follow
      #
      ikesa_lifetime_secs 3600
      #
      # Global transform definitions.  The algorithm choices are
      # based on RFC 4921.
      #
      ## Two transforms are acceptable to this system, Group 20 and Group 19.
      ## A peer can be configured with 19 or 20.
      ## To ensure that a particular peer uses a specific transform,
      ## include the transform in the rule.
      ## 
      # Group 20 is 384-bit ECP - Elliptic Curve over Prime
      ikesa_xform { encr_alg aes(256..256) auth_alg sha384 dh_group 20 }
      # Group 19 is 256-bit ECP
      ikesa_xform { encr_alg aes(128..128) auth_alg sha256 dh_group 19 }
      #
      ## The rule to communicate with host2
      ##  Label must be unique
      { label "host1-host2"
        auth_method preshared
        local_addr  192.0.2.16
        remote_addr 192.0.2.213
      }
    2. Modify the ikev2.config file on the host2 system:
      ## ikev2.config file on host2, 192.0.2.213
      ## Global Parameters
      #
      ...
      ikesa_xform { encr_alg aes(256..256) auth_alg sha384 dh_group 20 }
      ikesa_xform { encr_alg aes(128..128) auth_alg sha256 dh_group 19 }
      ...
      ## The rule to communicate with host1
      ##  Label must be unique
      { label "host2-host1"
        auth_method preshared
        local_addr  192.0.2.213
        remote_addr 192.0.2.16
      }
  3. On each system, verify the syntax of the file.
    # /usr/lib/inet/in.ikev2d -c
  4. Create a preshared key for IKEv2 to use.
  5. Put the preshared key in the /etc/inet/ike/ikev2.preshared file on each system.

    Caution

    Caution  -  This file has special permissions and is owned by ikeuser. Never delete or replace this file. Instead, use the pfedit -s command to edit its contents so that the file retains its original properties and the contents do not appear in the audit log.


    1. For example, on the host1 system, the ikev2.preshared file would appear similar to the following:
      # pfedit -s /etc/inet/ike/ikev2.preshared
      ## ikev2.preshared on host1, 192.0.2.16
      # ...
      ## label must match the rule that uses this key
      { label "host1-host2"
         key  "1011e1f2d1fd..."
      }

      For information about the options to the pfedit command, see the pfedit(1M) man page.

    2. On the host2 system, the ikev2.preshared file is similar except for its unique label:
      ## ikev2.preshared on host2, 192.0.2.213
      # ...
      ## label must match the label of the rule that uses this key
      { label "host2-host1"
         key  "1011e1f2d1fd..."
      }
  6. Enable the IKEv2 service instance.
    # svcadm enable ipsec/ike:ikev2

    When replacing the preshared key, edit the preshared key files on the peer systems and restart the ikev2 service.

    # svcadm restart ikev2
Example 40  Generating a Preshared Key for IKEv2

In the following example, the administrator manually creates the keying material for two systems that are protected by IKE, local1 and remote1. The label of the preshared key entry matches the label in a rule in the ikev2.config file. Then, the administrator copies the key to the /etc/ike/ikev2.preshared file and destroys the original key file.

  1. First, the administrator creates and displays the preshared key.

    local1$ pktool genkey keystore=file outkey=ike2psk keytype=aes keylen=256 print=y
    Key Value ="2b823670b5aa1a..."
  2. The administrator adds the key to the ikev2.preshared file on local1.

    { label "local1-remote1"
       key  "2b823670b5aa1a..."
    }
  3. The administrator destroys the original key file.

    $ rm ike2psk
  4. The administrator copies the ikev2.preshared file to the communicating system by using the ssh command or another secure mechanism.

  5. On remote1, the administrator appends the ikev2.preshared file to an existing /etc/inet/ike/ikev2.preshared file, or creates a new file.

    Then, the administrator changes the label to match the rule in the ikev2.config file.

    { label "remote1-local1"
       key "2b823670b5aa1a..."
    }
Example 41  Using Different Local and Remote IKEv2 Preshared Keys

In this example, the IKEv2 administrators create a preshared key per system, exchange them, and add each key to the /etc/inet/ike/ikev2.preshared file. The label of the preshared key entry matches the label in a rule in the ikev2.config file. Then, they restart the in.ikev2d daemons.

  1. On host1, the administrator generates two keys.

    $ pktool genkey keystore=file outkey=ikemykey keytype=aes keylen=256 print=y
    Key Value ="e6fc5402efd08..."
    $ pktool genkey keystore=file outkey=ikeotherkey keytype=aes keylen=256 print=y
    Key Value ="01ca0f4d32923..."
  2. The administrator places the keys in the ikev2.preshared file.

    ##...
    { label "host1-host2"
    ## local and remote preshared keys 
      local_key  "e6fc5402efd08..."
      remote_key "01ca0f4d32923..."
    }
  3. The administrator destroys the original keys files.

    $ rm ikemykey ikeotherkey
  4. The administrator copies the ikev2.preshared file to host2 by using the ssh command or another secure mechanism.

  5. After receiving the other system's preshared key, the administrator edits the ikev2.preshared file. The file on host2 is the following:

    ##...
    { label "host2-host1"
    ## local and remote preshared keys 
      local_key  "01ca0f4d32923..."
      remote_key "e6fc5402efd08..."
    }
  6. The administrators restart the IKEv2 service instance on each system.

    # svcadm restart ikev2

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.

For more examples, see the ikev2.config(4) and ikev2.preshared(4) man pages.