JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle Solaris Administration: IP Services     Oracle Solaris 10 1/13 Information Library
search filter icon
search icon

Document Information

Preface

Part I Introducing System Administration: IP Services

1.  Oracle Solaris TCP/IP Protocol Suite (Overview)

Part II TCP/IP Administration

2.  Planning Your TCP/IP Network (Tasks)

3.  Introducing IPv6 (Overview)

4.  Planning an IPv6 Network (Tasks)

5.  Configuring TCP/IP Network Services and IPv4 Addressing (Tasks)

6.  Administering Network Interfaces (Tasks)

7.  Configuring an IPv6 Network (Tasks)

8.  Administering a TCP/IP Network (Tasks)

9.  Troubleshooting Network Problems (Tasks)

10.  TCP/IP and IPv4 in Depth (Reference)

11.  IPv6 in Depth (Reference)

Part III DHCP

12.  About DHCP (Overview)

13.  Planning for DHCP Service (Tasks)

14.  Configuring the DHCP Service (Tasks)

15.  Administering DHCP (Tasks)

16.  Configuring and Administering the DHCP Client

17.  Troubleshooting DHCP (Reference)

18.  DHCP Commands and Files (Reference)

Part IV IP Security

19.  IP Security Architecture (Overview)

20.  Configuring IPsec (Tasks)

21.  IP Security Architecture (Reference)

22.  Internet Key Exchange (Overview)

23.  Configuring IKE (Tasks)

Configuring IKE (Task Map)

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

How to Verify That IKE Preshared Keys Are Identical

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 in 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

How to Configure IKE to Find the Sun Crypto Accelerator 6000 Board

Changing IKE Transmission Parameters (Task Map)

Changing IKE Transmission Parameters

How to Change the Duration of Phase 1 IKE Key Negotiation

24.  Internet Key Exchange (Reference)

25.  IP Filter in Oracle Solaris (Overview)

26.  IP Filter (Tasks)

Part V IPMP

27.  Introducing IPMP (Overview)

28.  Administering IPMP (Tasks)

Part VI IP Quality of Service (IPQoS)

29.  Introducing IPQoS (Overview)

30.  Planning for an IPQoS-Enabled Network (Tasks)

31.  Creating the IPQoS Configuration File (Tasks)

32.  Starting and Maintaining IPQoS (Tasks)

33.  Using Flow Accounting and Statistics Gathering (Tasks)

34.  IPQoS in Detail (Reference)

Glossary

Index

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.

How 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 Oracle Solaris Administration: 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. Use the ssh command for secure remote login.


  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 3des }
      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
      }
    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 3des }
      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
      }
  4. On each system, verify the syntax 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 an Oracle Solaris 10 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 an Oracle 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 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.

  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 Keying Material for Two Systems With Different Operating Systems

The IPsec feature of Oracle Solaris interoperates with IPsec on 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 Oracle 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 Oracle 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 Oracle Solaris system is 7061706965726d616368652077697468206361736865777320616e64. The administrator places this value in the ike.preshared file on the Oracle 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 Oracle Solaris system administrator telephones the other administrator with the passphrase, papiermache with cashews and.

How to Refresh IKE Preshared Keys

This procedure assumes that you want to replace an existing preshared key at regular intervals.

  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 Oracle Solaris Administration: 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. Use the ssh command for secure remote login.


  2. Generate random numbers and construct a key of the appropriate length.

    For details, see How to Generate Random Numbers on an Oracle Solaris System. If you are generating a preshared key for an Oracle Solaris: system that is communicating with an operating system that requires ASCII, see Example 23-1.

  3. Replace the current key with a new key.

    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.

  4. Read the new key into the kernel.
    • Starting in the Solaris 10 4/09 release, restart the ike service.
      # svcadm enable ike
    • If you are running a release prior to the Solaris 10 4/09 release, kill and restart the in.iked daemon.
      1. Check the privilege level of the in.iked daemon.
        # /usr/sbin/ikeadm get priv
        Current privilege level is 0x0, base privileges enabled

        You can change the keying material if the command returns a privilege level of 0x1 or 0x2. Level 0x0 does not permit operations to modify or view keying material. By default, the in.iked daemon runs at the 0x0 level of privilege.

      2. If the privilege level is 0x0, kill and restart the daemon.

        When the daemon restarts, it reads the new version of the ike.preshared file.

        # pkill in.iked
        # /usr/lib/inet/in.iked
      3. If the privilege level is 0x1 or 0x2, read in the new version of the ike.preshared file.
        # ikeadm read preshared

How to View IKE Preshared Keys

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 ikeadm Command.


Note - To perform this procedure on a release prior to the Solaris 10 4/09 release, see Example 23-2.


Before You Begin

IKE is configured and the ike service is running.

  1. View the IKE preshared keys.
    # ikeadm
    ikeadm> dump preshared
  2. If you get an error, increase the privilege level of the in.iked daemon.
    1. Increase the privilege level of the in.iked daemon in the SMF repository.
      # svcprop -p config/admin_privilege ike
      base
      # svccfg -s ike setprop config/admin_privilege=keymat
    2. Increase the privilege level of the running in.iked daemon.
      # svcadm refresh ike ; svcadm restart ike
    3. (Optional) Confirm that the privilege level is keymat.
      # svcprop -p config/admin_privilege ike
      keymat
    4. View the keys by running Step 1 again.
  3. Return the IKE daemon to the base privilege level.
    1. After you view the keys, return the privilege level to the default.
      # svccfg -s ike setprop config/admin_privilege=base
    2. Refresh and then restart IKE.
      # svcadm refresh ike ; svcadm restart ike

Example 23-2 Verifying IKE Preshared Keys in a Release Prior to the Solaris 10 4/09 Release

In the following example, the administrator is viewing keys on a Solaris system that is not running the current Oracle Solaris 10 release. The administrator wants to verify that the keys on this system are identical to the keys on the communicating system. After verifying that the keys on the two systems are identical, the administrator restores the privilege level to 0.

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

If you add IPsec policy entries to a working configuration between the same peers, you need to refresh the IPsec policy service. You do not need to reconfigure or restart IKE.

If you add a new peer to the IPsec policy, in addition to the IPsec changes, you must modify the IKE configuration.


Note - To perform this procedure on a release prior to the Solaris 10 4/09 release, see Example 23-3.


Before You Begin

You have updated the ipsecinit.conf file and refreshed IPsec policy for the peer systems.

  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 Oracle Solaris Administration: 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. Use the ssh command for secure remote login.


  2. On this system, generate random numbers and construct a key of 64 to 448 bits.

    For details, see How to Generate Random Numbers on an Oracle Solaris System. If you are generating a preshared key for an Oracle Solaris: system that is communicating with an operating system that requires ASCII, see Example 23-1.

  3. By some means, send the key to the administrator of the remote system.

    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.

  4. Create a rule for IKE to manage the keys for enigma and the new peer, ada.
    1. On the enigma system, add the following rule to the /etc/inet/ike/config file:
      ### 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
          }
    2. On the ada system, add the following rule:
      ### 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
      }
  5. Ensure that IKE preshared keys are available at reboot.
    1. On the enigma system, add the following information to the /etc/inet/secret/ike.preshared file:
      # 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
      }
    2. On the ada system, add the following information to the ike.preshared file:
      # 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
      }
  6. On each system, refresh the ike service.
    # svcadm refresh ike
  7. Verify that the systems can communicate.

    See How to Verify That IKE Preshared Keys Are Identical.

Example 23-3 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 Oracle Solaris 10 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.

Next Steps

If you have not completed establishing IPsec policy, return to the IPsec procedure to enable or refresh IPsec policy.

How to Verify That IKE Preshared Keys Are Identical

If the preshared keys on the communicating systems are not identical, the systems cannot authenticate.

Before You Begin

IPsec has been configured and is enabled between the two systems that you are testing. You are running the current Oracle Solaris 10 release.


Note - To perform this procedure on a release prior to the Solaris 10 4/09 release, see Example 23-2.


  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 Oracle Solaris Administration: 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. Use the ssh command for secure remote login.


  2. On each system, check the privilege level of the in.iked daemon.
    # svcprop -p config/admin_privilege ike
    base
    • If the privilege level is keymat, continue with Step 3.
    • If the privilege level is base or modkeys, increase the privilege level.

      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
  3. On each system, view the preshared key information.
    # 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).
  4. Compare the two dumps.

    If the preshared keys are not identical, replace one key with the other key in the /etc/inet/secret/ike.preshared file.

  5. When the verification is complete, return the privilege level to the default on each system.
    # svccfg -s ike setprop config/admin_privilege=base
    # svcadm restart ike