System Administration Guide: IP Services

IKE Tasks

This section provides procedures that enable you to automatically manage the keys that secure traffic between two systems with IPv4 addresses. 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.

How to Configure IKE With Pre-Shared Keys

Become superuser on the system console.

Note –
Logging in remotely exposes security-critical traffic to eavesdropping. Even if you somehow protect the remote login, the total security of the system is reduced to the security of the remote login session.

On each system, create an /etc/inet/ike/config file with global parameters and rules that permit the IPsec policy in ipsecinit.conf to succeed. For example,

### ike/config file on enigma, 192.168.66.1

## 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 "Enigma-Partym"
  localid 192.168.66.1
  remoteid 192.168.55.2
  p1_xform
	  { auth_method preshared  oakley_group 5  auth_alg md5  encr_alg des }
  p2_pfs 5
	}

### ike/config file on partym, 192.168.55.2
## 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 "Partym-Enigma"
  localid 192.168.55.2
  remoteid 192.168.66.1
  p1_xform
    { auth_method preshared  oakley_group 5  auth_alg md5  encr_alg des }
  p2_pfs 5
}

Note –

These machine names are examples only. Use the names and addresses of your machines when securing traffic between them.

On each machine, check the validity of the file:

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

Generate random keys.

On a Solaris system, you can use the od command. For example,

# od -x </dev/random | head -4
0000000 df97 6d2f 4ef5 2c28 02d5 02aa f9de 481d
0000020 2ae8 b949 67e6 b9b0 dd16 e6d4 b7ea 7278
0000040 ac07 7cc6 99c1 7055 848a 3cf3 4377 980a
0000060 5ad7 5b40 b428 9f3a da20 7daa 65a4 83fe

Create the file /etc/inet/secret/ike.preshared on each system and put the pre-shared key in each file.

The encryption algorithm in this example (see Step 2) is DES, so the pre-shared key must be at least 64 bits. However, a longer key length is a good idea. For example,

# ike.preshared on enigma, 192.168.66.1
{ localidtype IP
	  localid 192.168.66.1
	  remoteidtype IP
	  remoteid 192.168.55.2
	  # enigma and partym's shared key in hex (128 bits)
	  key ac077cc699c17055848a3cf34377980a
	}

# ike.preshared on partym, 192.168.55.2
{ localidtype IP
	  localid 192.168.55.2
	  remoteidtype IP
	  remoteid 192.168.66.1
	  # partym and enigma's shared key in hex (128 bits)
	  key ac077cc699c17055848a3cf34377980a
	}

Note –

The pre-shared keys must be identical.

On each system, add the address and host name for the other system in the /etc/hosts file. For example,

On a system named partym:
# Secure communication with enigma 192.168.66.1 enigma
On a system named enigma:
# Secure communication with partym 192.168.55.2 partym

On each system, edit the /etc/inet/ipsecinit.conf file by adding the following lines:

On enigma:

{laddr enigma raddr partym} ipsec {auth_algs any sa shared}

On partym:

{laddr partym raddr enigma} ipsec {auth_algs any sa shared}

Enable secure communication by rebooting each system.
# /usr/sbin/reboot

How to Refresh Existing Pre-Shared Keys

This procedure assumes that you want to replace an existing pre-shared key. If you use a strong encryption algorithm, such 3DES, AES, or Blowfish, you may be able to schedule key replacement for when you reboot both machines. This procedure is for machines using an algorithm like DES to secure traffic.

Become superuser on the system console.

Note –
Logging in remotely exposes security-critical traffic to eavesdropping. Even if you somehow protect the remote login, the total security of the system is reduced to the security of the remote login session.

Generate random keys and choose one.

On a Solaris system, you can use the od command.

# od -x </dev/random | head -2
0000000 305e c563 69ca 62c2 ae80 4690 c571 3e18
0000020 be43 9533 d50f ec49 c7fe cf3c 8f13 91c0

Edit the /etc/inet/secret/ike.preshared file on each system, and replace the current key with a new key.

For example, on the hosts enigma and partym, you would replace the value of key with a new number, like be439533d50fec49c7fecf3c8f1391c0.

Check that the in.iked daemon permits you to change keying material.
# /usr/sbin/ikeadm get priv Current privilege level is 0x2, access to keying material enabled
You can change keying material if the command returns a privilege level of 0x1 or 0x2. Level 0x0 does not permit keying material operations. By default, the in.iked daemon runs at the 0x0 level of privilege.

If the in.iked daemon permits you to change keying material, read in the new version of the ike.preshared file.

For example,
# ikeadm read preshared

If the in.iked daemon does not permit you to change keying material, kill the daemon and then restart it.

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

For example,
# pkill in.iked # /usr/lib/inet/in.iked

How to Add New Pre-Shared Keys

On a system running the in.iked daemon, you can add pre-shared keys for interfaces that you have added to the ipsecinit.conf file after the daemon was invoked. This procedure assumes that you have already added the new interfaces to the /etc/hosts file and the /etc/inet/ipsecinit.conf file on both systems, and that you have not yet read the ipsecinit.conf file into each system.

Become superuser on the system console.

Note –
Logging in remotely exposes security-critical traffic to eavesdropping. Even if you somehow protect the remote login, the total security of the system is reduced to the security of the remote login session.

Check that the in.iked daemon permits you to change keying material.
# /usr/sbin/ikeadm get priv Current privilege level is 0x2, access to keying material enabled
You can change keying material if the command returns a privilege level of 0x1 or 0x2. Level 0x0 does not permit keying material operations. By default, the in.iked daemon runs at the 0x0 level of privilege.

If the in.iked daemon does not permit you to change keying material, kill the daemon and then start it with the correct privilege level.

For example,
# pkill in.iked # /usr/lib/inet/in.iked -p 2 Setting privilege level to 2!

Generate random keys and choose one.

On a Solaris system, you can use the od command.

# od -x </dev/random | head -2
0000000 2d86 b6f6 eb7a e8a9 3d83 58b2 cd17 4164
0000020 8be4 fea4 b456 933a 46dd 149a 0a10 b2e4

Type the ikeadm command on each system to add the new keying material.

For example, if you are on enigma, and add the key for host nemesis, 192.163.55.8:

# ikeadm
ikeadm> add preshared { localidtype ip localid 192.168.66.1
remoteidtype ip remoteid 192.163.55.8 ike_mode main
key 2d86b6f6eb7ae8a93d8358b2cd174164 }
ikeadm: Successfully created new preshared key.

On host nemesis, the administrator would add the identical key, as in:

# ikeadm
ikeadm> add preshared { localidtype ip localid 192.163.55.8
remoteidtype ip remoteid 192.168.66.1 ike_mode main
key 2d86b6f6eb7ae8a93d8358b2cd174164 }
ikeadm: Successfully created new preshared key.

Note –

A message of the form Error: invalid preshared key definition indicates that you have mistyped or omitted a parameter to the add preshared command. Retype the command correctly to add the key.

Exit the ikeadm command mode.
ikeadm> exit #

On each system, lower the privilege level of the in.iked daemon.
# ikeadm set priv base

On each system, activate the ipsecinit.conf file to secure the added interfaces.
# ipsecconf -a /etc/inet/ipsecinit.conf
Note –
Read the warning when you execute the command. A socket that is already in use (latched) provides an unsecured back door into the system.

How to Configure IKE With Self-Signed Public Certificates

Become superuser on the system console.

Note –
Logging in remotely exposes security-critical traffic to eavesdropping. Even if you somehow protect the remote login, the total security of the system is reduced to the security of the remote login session.

Use the ikecert certlocal -ks command to add a self-signed certificate to the ike.privatekeys database. For example,

# ikecert certlocal -ks -m 1024 -t rsa-md5 \
-D "C=US, O=ExampleCompany, OU=US-Example, CN=Example" \
-A IP=192.168.10.242
Generating, please wait...
Certificate: 
Certificate generated.
Certificate added to database.
-----BEGIN X509 CERTIFICATE-----
MIICLTCCAZagAwIBAgIBATANBgkqhkiG9w0BAQQFADBNMQswCQYDVQQGEwJVUzEX
…
6sKTxpg4GP3GkQGcd0r1rhW/3yaWBkDwOdFCqEUyffzU
-----END X509 CERTIFICATE-----

Send the certificate to the communicating system's administrator.

You can cut-and-paste the certificate into an email, as in:

To: root@us.example.com
From: root@un.example.com
Message: -----BEGIN X509 CERTIFICATE-----
MIICLTCCAZagAwIBAgIBATANBgkqhkiG9w0BAQQFADBNMQswCQYDVQQGEwJVUzEX
…
6sKTxpg4GP3GkQGcd0r1rhW/3yaWBkDwOdFCqEUyffzU
-----END X509 CERTIFICATE-----

Edit the /etc/inet/ike/config file to recognize the public keys from a communicating system. For example,

# Explicitly trust the following self-signed certs
# Use the Subject Alternate Name to identify the cert

cert_trust "192.168.10.242"
cert_trust "192.168.11.241"

## Parameters that may also show up in rules.

p1_xform { auth_method preshared oakley_group 5 auth_alg sha encr_alg 3des }
p2_pfs 5

{
 label "UN-Example to US-Example"
 local_id_type dn
 local_id "C=US, O=ExampleCompany, OU=UN-Example, CN=Example"
 remote_id_type dn
 remote_id "C=US, O=ExampleCompany, OU=US-Example, CN=Example"

 local_addr 192.168.10.242
 remote_addr 192.168.11.241

 p1_xform
  { auth_method rsa_encrypt oakley_group 2  auth_alg md5  encr_alg des }
}

Do the following substeps to add the communicating system's public key.
1. Copy the public key from the administrator's email.
2. Type the ikecert certdb –a command and type <Return>.
  # ikecert certdb -a <Return>
3. Paste the public key and type <Return>.
  -----BEGIN X509 CERTIFICATE----- MIICL… … KgDid/nxWPlWQU5vMAiwJXfa0sw/A12w448JVkVmEWaf -----END X509 CERTIFICATE----- <Return>
4. End the entry by typing <Control-D>.
  <Control-D>

Verify with the other administrator that the keys have not been tampered with.

For example, you can phone the other administrator to compare the values of the public key hash, as in,

# ikecert certdb -l
        Certificate Slot Name: 0   Type: if-modn
        Subject Name: <C=US, O=ExampleCo, OU=UN-Example, CN=Example>
        Key Size: 1024
        Public key hash: 2239A6A127F88EE0CB40F7C24A65B818

other system # ikecert certlocal -l
Local ID Slot Name: 1   Type: if-modn
        Key Size: 1024
        Public key hash: 2239A6A127F88EE0CB40F7C24A65B818

Note –

The public key hash above is different from the one that your systems generate.

How to Configure IKE With Public Keys Signed by a Certificate Authority

Become superuser on the system console.

Note –
Logging in remotely exposes security-critical traffic to eavesdropping. Even if you somehow protect the remote login, the total security of the system is reduced to the security of the remote login session.

Use the ikecert certlocal -kc command to add a trusted root certificate to the ike.privatekeys database.

For example,

# ikecert certlocal -kc -m 1024 -t rsa-md5 \
-D "C=US, O=ExampleCompany\, Inc., OU=US-Example, CN=Example" \
-A "DN=C=US, O=ExampleCompany\, Inc., OU=US-Example"
Generating, please wait...
Certificate request generated.
-----BEGIN CERTIFICATE REQUEST-----
MIIByjCCATMCAQAwUzELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFEV4YW1wbGVDb21w
…
lcM+tw0ThRrfuJX9t/Qa1R/KxRlMA3zckO80mO9X
-----END CERTIFICATE REQUEST-----

Submit the request to the outside Certificate Authority or PKI.

The vendor issues you two certificates and a CRL that you enter into the respective databases.
- Your publickeys certificate – This certificate is based on the request you submitted to the vendor. The certificate uniquely identifies you.
- A Certificate Authority – This is the vendor's signature. The CA verifies that your publickeys certificate is legitimate.
- A Certificate Revocation List – This is the latest list of certificates that the vendor has revoked.

Enter the three certificates as the argument to ikecert commands.
1. Become superuser on the system console.
2. Type the ikecert certdb –a command and type <Return>.
  # ikecert certdb -a <Return>
3. Paste your certificate that you received from the vendor and type <Return>.
  -----BEGIN X509 CERTIFICATE----- … -----END X509 CERTIFICATE-----<Return>
4. End the entry by typing <Control-D>.
  <Control-D>
5. Type the ikecert certdb –a command and type <Return>.
  # ikecert certdb -a <Return>
6. Paste the vendor's CA and type <Return>, then <Control-D> to end the entry.
  -----BEGIN X509 CERTIFICATE----- … -----END X509 CERTIFICATE-----<Return> <Control-D>
7. Type the ikecert certrldb –a command and type <Return>.
  # ikecert certrldb -a <Return>
8. Paste the vendor's CRL and type <Return>, then <Control-D> to end the entry.

Edit the /etc/inet/ike/config file to recognize the vendor.

Use the name that the vendor tells you to use. For example,

# Trusted root cert
# This certificate is from Example PKI
# This is the X.509 distinguished name for the CA that it issues.

cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example, CN=Example PKI"

## Parameters that may also show up in rules.

p1_xform { auth_method rsa_sig oakley_group 1 auth_alg sha1 encr_alg 3des }
p2_pfs 2

{
 label "UN-Example to US-Example - Example PKI"
 local_id_type dn
 local_id "C=US, O=ExampleCompany, OU=UN-Example, CN=Example"
 remote_id_type dn
 remote_id "C=US, O=ExampleCompany, OU=US-Example, CN=Example"

 local_addr 192.168.10.242
 remote_addr 192.168.11.241

 p1_xform
  { auth_method rsa_encrypt oakley_group 2  auth_alg md5  encr_alg des }
}

The communicating system does the same operations as you have done.

Following the example, the "C=US, O=ExampleCompany, OU=US-Example, CN=Example" system runs the ikecert commands as above. Its ike.config file uses its local information for local parameters, and your system's information for the remote parameters.

For example,

# Trusted root cert
# This certificate is from Example PKI

cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example, CN=Example PKI"

## Parameters that may also show up in rules.

p1_xform { auth_method rsa_sig oakley_group 1 auth_alg sha1 encr_alg 3des }
p2_pfs 2

{
 label "US-Example to UN-Example - Example PKI"
 local_id_type dn
 local_id "C=US, O=ExampleCompany, OU=US-Example, CN=Example"
 remote_id_type dn
 remote_id "C=US, O=ExampleCompany, OU=UN-Example, CN=Example"

 local_addr 192.168.11.241
 remote_addr 192.168.10.242

 p1_xform
  { auth_method rsa_sig oakley_group 2  auth_alg md5  encr_alg des }
}

When the /etc/hosts file and /etc/inet/ipsecinit.conf file have been modified to include the protected interfaces and the machines are rebooted, the IKE daemon authenticates itself with the public keys and the CA.

Note –

The RSA encryption authentication method hides identities in IKE from eavesdroppers, so IKE does not retrieve the peer's certificate. As a result, the method requires that the IKE peers know each other's public keys. Therefore, when you use auth_method rsa_encrypt in the ike.config file, you must add the peer's certificate to the public-keys database.

How to Update a Certificate Revocation List

Become superuser on the system console.

Note –
Logging in remotely exposes security-critical traffic to eavesdropping. Even if you somehow protect the remote login, the total security of the system is reduced to the security of the remote login session.

Follow the instructions from the vendor about how to extract the revoked certificates.

Use the following procedure to add the revoked certificate to the CRL database.
1. Type the ikecert certrldb -a command and type <Return>.
  # ikecert certrldb -a <Return>
2. Paste the revoked certificate from the PKI vendor and type <Return>, then <Control-D> to end the entry.

Repeat for every CRL in the revocation list.