sun.com docs.sun.com My Sun Worldwide Sites

Previous Previous     Contents     Index     Next Next
Chapter 23

Configuring IKE (Tasks)

This chapter describes how to configure IKE for your systems. After IKE is configured, it automatically generates keying material for IPsec on your network. This chapter contains the following information:

For overview information about IKE, see Chapter 22, Internet Key Exchange (Overview). For reference information about IKE, see Chapter 24, Internet Key Exchange (Reference). For more procedures, see the Examples sections of the ikeadm(1M), ikecert(1M), and ike.config(4) man pages.

Configuring IKE (Task Map)

You can use preshared keys, self-signed certificates, and certificates from a Certificate Authority (CA) to authenticate IKE. A rule links the particular IKE authentication method with the end points that are being protected. Therefore, you can use one or all IKE authentication methods on a system. A pointer to a PKCS #11 library enables certificates to use an attached hardware accelerator.

After configuring IKE, complete the IPsec task that uses the IKE configuration. The following table refers you to task maps that focus on a specific IKE configuration.

Task

Description

For Instructions

Configure IKE with preshared keys

Protects communications between two systems by having the systems share a secret key.

Configuring IKE With Preshared Keys (Task Map) 

Configure IKE with public key certificates

Protects communications with public key certificates. The certificates can be self-signed, or they can be vouched for by a PKI organization.

Configuring IKE With Public Key Certificates (Task Map) 

Cross a NAT boundary

Configures IPsec and IKE to communicate with a mobile system

Configuring IKE for Mobile Systems (Task Map) 

Configure IKE to generate and store public key certificates on attached hardware

Enables a Sun Crypto Accelerator 1000 board or a Sun Crypto Accelerator 4000 board to accelerate IKE operations. Also enables the Sun Crypto Accelerator 4000 board to store public key certificates.

Configuring IKE to Find Attached Hardware (Task Map) 

Tune Phase 1 key negotiation parameters

Changes the timing of IKE key negotiations.

Changing IKE Transmission Parameters (Task Map) 

Configuring IKE With Preshared Keys (Task Map)

The following table points to procedures to configure and maintain IKE with preshared keys.

Task

Description

For Instructions

Configure IKE with preshared keys

Creates an IKE policy file and one key to be shared.

How to Configure IKE With Preshared Keys 

Refresh preshared keys on a running IKE system

Adds fresh keying material for IKE on communicating systems.

How to Refresh IKE Preshared Keys 

Add preshared keys to a running IKE system

Adds a new IKE policy entry and new keying material to a system that is currently enforcing IKE policy.

How to Add an IKE Preshared Key for a New Policy Entry in ipsecinit.conf 

Check that preshared keys are identical

Displays the preshared keys on both systems to see that the keys are identical.

How to Verify That IKE Preshared Keys Are Identical 

Configuring IKE With Preshared Keys

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. Preshared keys cannot be used with mobile systems or systems that might be renumbered. Also, when you use preshared keys, you cannot offload IKE computations to attached hardware.

ProcedureHow to Configure IKE With Preshared Keys

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.

These procedures use the system names enigma and partym. Substitute the names of your systems for the names enigma and partym.

  1. On the system console, assume the Primary Administrator role or become superuser.

    The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, "Working With the Solaris Management Console (Tasks)," in System Administration Guide: Basic Administration.


    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.


  2. On each system, copy the file /etc/inet/ike/config.sample to the file /etc/inet/ike/config.

  3. Enter rules and global parameters in the ike/config file on each system.

    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.

    1. For example, modify the /etc/inet/ike/config file on the enigma system:

      ### 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 md5 encr_alg 3des }
        p2_pfs 5
      }


      Note - All arguments to the auth_method parameter must be on the same line.


    2. Modify the /etc/inet/ike/config file on the partym system:

      ### 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 md5 encr_alg 3des }
      p2_pfs 5
      }

  4. On each system, check the validity of the file.

    # /usr/lib/inet/in.iked -c -f /etc/inet/ike/config

  5. Generate random numbers for use as keying material.

    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 23-1.


  6. From the output of Step 5, construct one key.

    f47cb0f432e14480951095f82b735ba80a9467d08f92c88068b6a40e

    The authentication algorithm in this procedure is MD5, 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 MD5 algorithm is 128 bits, or 32 characters. The example key is 56 characters long, which provides additional keying material for IKE to use.

  7. Create the file /etc/inet/secret/ike.preshared on each system.

    Put the preshared key in each file.

    1. For example, on the enigma system, the ike.preshared file would appear similar to the following:

      # 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
      	}

    2. On the partym system, the ike.preshared file would appear similar to the following:

      # 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 23-1   Generating Identical Key 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, ASCII and hexadecimal.

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.

Previous Previous     Contents     Index     Next Next
Company Info Contact Terms of Use Privacy Copyright 1994-2007 Sun Microsystems, Inc.