Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com
Answertopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

System Administration Guide: IP Services
Previous Next

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.

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

How to Refresh IKE Preshared Keys

This procedure assumes that you want to replace an existing preshared key at regular intervals without rebooting. If you use a strong encryption algorithm, such 3DES or Blowfish, you might want to refresh keys just before you reboot both 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 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. Generate random numbers and construct a key of the appropriate length.

    For details, see How to Generate Random Numbers on a Solaris System. If you are generating a preshared key for a 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. 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.

    • 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
    • If the privilege level is 0x1 or 0x2, read in the new version of the ike.preshared file.
      # ikeadm read preshared

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

You must have one preshared key for every policy entry in the ipsecinit.conf file. If you add a new policy entry while IPsec and IKE are running, the in.iked daemon can read in new keys.

Before You Begin

This procedure assumes the following:

  • The enigma system is set up as described in How to Configure IKE With Preshared Keys.

  • The enigma system is going to protect its traffic with a new system, ada.

  • The in.iked daemon is running on both systems.

  • The systems' interfaces are included as entries in the /etc/hosts file on both systems. The following entry is an example.

    192.168.15.7 ada
    192.168.116.16 enigma

    This procedure also works with an IPv6 address. In Solaris Express, Developer Edition 2/07, IPv6 addresses are placed in the /etc/hosts file.

  • You have added a new policy entry to the /etc/inet/ipsecinit.conf file on both systems. The entries appear similar to the following:

    # ipsecinit.conf file for enigma
    {laddr enigma raddr ada} ipsec {auth_algs any encr_algs any sa shared}
    # ipsecinit.conf file for ada
    {laddr ada raddr enigma} ipsec {auth_algs any encr_algs any sa shared}
  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. Create a rule for IKE to manage the keys for enigma and ada.
    1. For example, the rule in the /etc/inet/ike/config file on the enigma system appears similar to the following:
      ### 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 md5 encr_alg blowfish}
       p2_pfs 5
          }
    2. The rule in the /etc/inet/ike/config file on the ada system appears similar to the following:
      ### 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 md5 encr_alg blowfish}
       p2_pfs 5
      }
  3. Check the privilege level of the in.iked daemon.
    # /usr/sbin/ikeadm get priv
    Current privilege level is 0x0, base privileges enabled
    • If the privilege level is 0x1 or 0x2, continue with the next step.
    • If the privilege level is 0x0, stop the daemon. Then, restart the daemon with the appropriate privilege level.
      # pkill in.iked
      # /usr/lib/inet/in.iked -p 2
      Setting privilege level to 2!
  4. Generate random numbers and construct a key of 64 to 448 bits.

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

  5. 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.

  6. Add the new keying material with the add preshared subcommand in ikeadm command mode.
    ikeadm> add preshared { localidtype id-type localid id
    remoteidtype id-type remoteid id ike_mode mode key key }
    id-type

    Specifies the type of the id.

    id

    Specifies the IP address when id-type is IP.

    mode

    Specifies the IKE mode. The only accepted value is main.

    key

    Specifies the preshared key in hexadecimal format.

    1. For example, on host enigma, you would add the key for the remote system, ada, and exit the ikeadm interactive mode.
      # ikeadm
      ikeadm> add preshared { localidtype ip localid 192.168.116.16
      remoteidtype ip remoteid 192.168.15.7
      key 8d1fb4ee500e2bea071deb2e781cb48374411af5a9671714672bb1749ad9364d }
      ikeadm: Successfully created new preshared key.
      ikeadm> exit
      #
    2. On host ada, you would add the identical key for the remote system, enigma, and exit the interactive mode.
      # ikeadm
      ikeadm> add preshared { localidtype ip localid 192.168.15.7
      remoteidtype ip remoteid 192.168.116.16
      key 8d1fb4ee500e2bea071deb2e781cb48374411af5a9671714672bb1749ad9364d }
      ikeadm: Successfully created new preshared key.
      ikeadm> exit
      #
  7. On each system, lower the privilege level of the in.iked daemon.
    # ikeadm set priv base
  8. On each system, activate the ipsecinit.conf file to secure the added interface.
    # ipsecconf -a /etc/inet/ipsecinit.conf

    Caution - Read the warning when you execute the ipsecconf command. The same warning applies to restarting the in.iked daemon. A socket that is already latched, that is, the socket is in use, provides an unsecured back door into the system. For more extensive discussion, see Security Considerations for ipsecinit.conf and ipsecconf.


  9. On each system, read in the new rules by using the ikeadm command.
    # ikeadm read rules

    You created the rules in Step 2. Because the rules are in the /etc/inet/ike/config file, the name of the file does not have to be specified to the ikeadm command.

  10. Ensure that IKE preshared keys are available at reboot.

    Add the keys to the /etc/inet/secret/ike.preshared file.

    1. For example, on the enigma system, you would add the following keying information to the 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, you would add the following keying 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
      }
  11. Verify that the systems can communicate.

    See How to Verify That IKE Preshared Keys Are Identical.

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.

  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. Check the privilege level of the in.iked daemon.
    # /usr/sbin/ikeadm get priv
    Current privilege level is 0x0, base privileges enabled
    • If the privilege level is 0x1 or 0x2, continue with the next step.
    • If the privilege level is 0x0, stop the daemon. Then, restart the daemon with the appropriate privilege level.
      # pkill in.iked
      # /usr/lib/inet/in.iked -p 2
      Setting privilege level to 2!
  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, lower the privilege level of the in.iked daemon on each system.
    # ikeadm set priv base
Previous Next

 
 
  Published under the terms fo the Public Documentation License Version 1.01. Design by Interspire