JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Securing the Network in Oracle Solaris 11.1     Oracle Solaris 11.1 Information Library
search filter icon
search icon

Document Information

Preface

1.  Using Link Protection in Virtualized Environments

2.  Tuning Your Network (Tasks)

3.  Web Servers and the Secure Sockets Layer Protocol

4.  IP Filter in Oracle Solaris (Overview)

5.  IP Filter (Tasks)

6.  IP Security Architecture (Overview)

7.  Configuring IPsec (Tasks)

8.  IP Security Architecture (Reference)

9.  Internet Key Exchange (Overview)

10.  Configuring IKE (Tasks)

Displaying IKE Information

How to Display Available Groups and Algorithms for Phase 1 IKE Exchanges

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 Update IKE for a New Peer System

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

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

11.  Internet Key Exchange (Reference)

Glossary

Index

Configuring IKE With Preshared Keys

Preshared keys is the simplest authentication method for IKE. If you are configuring peer system to use IKE, and you are the administrator of these systems, using preshared keys is a good choice. However, unlike public key certificates, preshared keys are tied to IP addresses. You can associate preshared keys with specific IP addresses 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 specified range of IP addresses.

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.

In this procedure, you generate keys in ASCII format.

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 Trusted Extensions Configuration and Administration.


Before You Begin

You must become an administrator who is assigned the Network IPsec Management rights profile, in addition to the solaris.admin.edit/etc/inet/ike/config authorization. The root role has all of these rights. For more information, see How to Use Your Assigned Administrative Rights in Oracle Solaris 11.1 Administration: Security Services.

If you log in remotely, use the ssh command for a secure remote login. For an example, see Example 7-1.

  1. On each system, create an /etc/inet/ike/config file.

    You can use the /etc/inet/ike/config.sample as a template.

  2. 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 configuration 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
      #
      ## 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 sha256 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_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 sha256 encr_alg aes }
      p2_pfs 5
      }
  3. On each system, verify the syntax of the file.
    # /usr/lib/inet/in.iked -c -f /etc/inet/ike/config
  4. 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
          # The preshared key can also be represented in hex
      # as in 0xf47cb0f432e14480951095f82b
      # key "This is an ASCII Cqret phrAz, use str0ng p@ssword tekniques"
      }
    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
          # The preshared key can also be represented in hex
      # as in 0xf47cb0f432e14480951095f82b
          key "This is an ASCII Cqret phrAz, use str0ng p@ssword tekniques"
          }
  5. Enable the IKE service.
    # svcadm enable ipsec/ike

Example 10-1 Refreshing an IKE Preshared Key

When IKE administrators want to refresh the preshared key, they edit the files on the peer systems and restart the in.iked daemon.

First, the administrator adds a preshared key entry, valid for any host on the 192.168.13.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)"
    }

Then, the administrator restarts the IKE service on every system.

# svcadm enable ipsec/ike

Next Steps

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

How to Update IKE for a New Peer System

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.

Before You Begin

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

You must become an administrator who is assigned the Network IPsec Management rights profile, in addition to the solaris.admin.edit/etc/inet/ike/config authorization. The root role has all of these rights. For more information, see How to Use Your Assigned Administrative Rights in Oracle Solaris 11.1 Administration: Security Services.

If you log in remotely, use the ssh command for a secure remote login. For an example, see Example 7-1.

  1. Create a rule for IKE to manage the keys for the new system that is using IPsec.
    1. For example, 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 sha256 encr_alg aes}
       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 sha256 encr_alg aes}
       p2_pfs 5
      }
  2. Create an IKE preshared key for the peer systems.
    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
        key "Twas brillig and the slivey toves did *s0mEtHiNg* be CareFULL hEEEr"
      }
    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
        key "Twas brillig and the slivey toves did *s0mEtHiNg* be CareFULL hEEEr"
      }
  3. On each system, refresh the ike service.
    # svcadm refresh ike

Next Steps

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