IPsec and IKE Administration Guide

Chapter 4 Administering 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. Configuring IKE (Task Map) lists the tasks in this chapter.

For overview information about IKE, see Chapter 3, Internet Key Exchange (Overview). The ikeadm(1M), ikecert(1M), and ike.config(4) man pages contain useful procedures in their respective Examples sections.

Configuring IKE (Task Map)

Task	Description	For Instructions
Configure IKE with preshared keys	Protects communications between two systems by having them 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)
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.	Using Hardware With IKE (Task Map)

For information on how to use roles to configure IKE, see “Role-Based Access Control (Tasks)” in System Administration Guide: Security Services.

Configuring IKE With Preshared Keys (Task Map)

Task	Description	For Instructions
Configure IKE with preshared keys	Involves creating a valid IKE policy file and `ike.preshared` file. IPsec files are also set up before booting the system to use the IKE-generated keys.	How to Configure IKE With Preshared Keys
Refresh preshared keys on a running IKE system	Involves checking the IKE privilege level and adding fresh keying material to the `ipseckeys` file on communicating systems.	How to Refresh Existing Preshared Keys
Add preshared keys to a running IKE system	Involves checking the IKE privilege level and running the `ikeadm` command with fresh keying material on communicating systems.	How to Add a New Preshared Key
Check that preshared keys are identical	Involves dumping the preshared keys on both systems.	How to Verify That the Preshared Keys Are Identical

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.

On the system console, become superuser or assume an equivalent role.

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.

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

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.

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 "enigma-partym"  Label must be unique
  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.

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 "partym-enigma" Label must be unique
  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
}

On each system, check the validity of the file.

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

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 and the od(1) man page.

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 is longer than the recommended minimum.

Create the file /etc/inet/secret/ike.preshared on each system. Put the preshared key in each file.

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
	}

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.

How to Refresh Existing 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 schedule key replacement for when you reboot both machines.

On the system console, become superuser or assume an equivalent role.

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.

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

For details, see How to Generate Random Numbers.

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 of the same length.

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.
# ikeadm read preshared

If the in.iked daemon does not permit you to change keying material, kill the daemon and then restart the daemon.
# pkill in.iked # /usr/lib/inet/in.iked
When the daemon restarts, the daemon reads the new version of the ike.preshared file.

How to Add a New Preshared Key

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. This procedure assumes the following:

The systems are named enigma and ada. Substitute your system names for these names.
The in.iked daemon is running on both systems.
The interface that you want to protect with IPsec is included as an entry in the /etc/hosts file on both systems. The following entry is an example.
192.168.15.7 ada
This procedure also works with an IPv6 address in the /etc/inet/ipnodes file.
You have added a new policy entry to the /etc/inet/ipsecinit.conf file on both systems. For example, the new entry on the enigma system appears similar to the following:
{laddr enigma raddr ada} ipsec {auth_algs any encr_algs any sa shared}
The entry on the ada system appears similar to the following:
{laddr ada raddr enigma} ipsec {auth_algs any encr_algs any sa shared}

You have created a rule for the enigma and ada systems to communicate securely in the /etc/inet/ike/config file on both systems. For example, the rule 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
	}

The rule 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
}

On the system console, become superuser or assume an equivalent role.

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.

Check that the in.iked daemon permits you to change keying material.
# /usr/sbin/ikeadm get priv Current privilege level is 0x0, base privileges 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. Then, restart the daemon with the correct privilege level.
# pkill in.iked # /usr/lib/inet/in.iked -p 2 Setting privilege level to 2!

Generate random numbers and construct a key of 64 to 448 bits.

For details, see How to Generate Random Numbers.

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.

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.

For example, on host enigma, you would add the key for the new interface, ada.

# ikeadm
ikeadm> add preshared { localidtype ip localid 192.168.116.16
remoteidtype ip remoteid 192.168.15.7 ike_mode main
key 8d1fb4ee500e2bea071deb2e781cb48374411af5a9671714672bb1749ad9364d }
ikeadm: Successfully created new preshared key.

On host ada, you would add the identical key.

# ikeadm
ikeadm> add preshared { localidtype ip localid 192.168.15.7
remoteidtype ip remoteid 192.168.116.16 ike_mode main
key 8d1fb4ee500e2bea071deb2e781cb48374411af5a9671714672bb1749ad9364d }
ikeadm: Successfully created new preshared 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 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.

On each system, read in the new rules by using the ikeadm command.
# ikeadm read rules
A sample of the new rules for the ada and enigma systems is available at the start of the procedure. 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.

To ensure that IKE preshared keys are available at reboot, add the keys to the /etc/inet/secret/ike.preshared file.

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
}

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
}

Verify that the systems can communicate. See How to Verify That the Preshared Keys Are Identical.

How to Verify That the Preshared Keys Are Identical

If the preshared keys on the communicating systems are not identical, you see the following error message:

# rup system2
system2: RPC: Rpcbind failure

On the system console, become superuser or assume an equivalent role.

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.

Check that the in.iked daemon permits you to change keying material.
# /usr/sbin/ikeadm get priv Current privilege level is 0x0, base privileges enabled
You can view keying material if the command returns a privilege level of 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 view keying material, kill the daemon. Then, restart the daemon with the correct privilege level.
# pkill in.iked # /usr/lib/inet/in.iked -p 2 Setting privilege level to 2!

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

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.

When the verification is complete, lower the privilege level of the in.iked daemon.
# ikeadm set priv base

Configuring IKE With Public Key Certificates (Task Map)

Task	Description	For Instructions
Configure IKE with self-signed public key certificates	Involves creating self–signed certificates with the `ikecert certlocal -ks` command, and adding the public key from a remote system with the `ikecert certdb` command.	How to Configure IKE With Self-Signed Public Key Certificates
Configure IKE with a PKI Certificate Authority	Involves sending output from the `ikecert certlocal –kc` command to a PKI organization, and adding the public key, CA, and CRL from the organization.	How to Configure IKE With Certificates Signed by a CA
Configure public key certificates on local hardware	Involves one of: Generating a self-signed certificate on the local hardware, and adding the public key from a remote system to the hardware. Generating a certificate request on the local hardware, and adding the public key certificates from the PKI organization to the hardware.	How to Generate and Store Public Key Certificates on Hardware
Update the certificate revocation list (CRL) from the PKI organization	Involves accessing the CRL from a central distribution point.	How to Handle a Certificate Revocation List

How to Configure IKE With Self-Signed Public Key Certificates

On the system console, become superuser or assume an equivalent role.

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.

Add a self-signed certificate to the ike.privatekeys database.

# ikecert certlocal -ks|-kc -m keysize -t keytype \
-D dname -A altname

-ks: Creates a self-signed certificate.
-kc: Creates a certificate request. For the procedure, see How to Configure IKE With Certificates Signed by a CA.
keysize: Is the size of the key. The keysize can be 512, 1024, 2048, 3072, or 4096.
keytype: Specifies the type of algorithm to use. The keytype can be rsa-sha1, rsa-md5, or dsa-sha1.
dname: Is the X.509 distinguished name for the certificate subject. The dname typically has the form: C=country, O=organization, OU=organizational unit, CN=common name. Valid tags are C, O, OU, and CN.
altname: Is the alternate name for the certificate. The altname is in the form of tag=value. Valid tags are IP, DNS, EMAIL, URI, DN, and RID.

For example, the command on the partym system would appear similar to the following:

# ikecert certlocal -ks -m 1024 -t rsa-md5 \
> -D "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" \
> -A IP=192.168.13.213
Creating software private keys.
  Writing private key to file /etc/inet/secret/ike.privatekeys/0.
Enabling external key providers - done.
Acquiring private keys for signing - done.
Certificate: 
 Proceeding with the signing operation.
 Certificate generated successfully (…/publickeys/0)
Finished successfully.
Certificate added to database.
-----BEGIN X509 CERTIFICATE-----
MIICLTCCAZagAwIBAgIBATANBgkqhkiG9w0BAQQFADBNMQswCQYDVQQGEwJVUzEX
…
6sKTxpg4GP3GkQGcd0r1rhW/3yaWBkDwOdFCqEUyffzU
-----END X509 CERTIFICATE-----

The command on the enigma system would appear similar to the following:

# ikecert certlocal -ks -m 1024 -t rsa-md5 \
> -D "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax" \
> -A IP=192.168.116.16
Creating software private keys.
  …
Certificate added to database.
-----BEGIN X509 CERTIFICATE-----
MIICKDCCAZGgAwIBAgIBATANBgkqhkiG9w0BAQQFADBJMQswCQYDVQQGEwJVUzEV
…
jpxfLM98xyFVyLCbkr3dZ3Tvxvi732BXePKF2A==
-----END X509 CERTIFICATE-----

Save the certificate, and send it to the remote system.

You can paste the certificate into an email.

For example, you would send the following partym certificate to the enigma administrator:

To: admin@ja.enigmaexample.com
From: admin@us.partyexample.com
Message: -----BEGIN X509 CERTIFICATE-----
MIICLTCCAZagAwIBAgIBATANBgkqhkiG9w0BAQQFADBNMQswCQYDVQQGEwJVUzEX
…
6sKTxpg4GP3GkQGcd0r1rhW/3yaWBkDwOdFCqEUyffzU
-----END X509 CERTIFICATE-----

The enigma administrator would send you the following enigma certificate:

To: admin@us.partyexample.com
From: admin@ja.enigmaexample.com
Message: -----BEGIN X509 CERTIFICATE-----
MIICKDCCAZGgAwIBAgIBATANBgkqhkiG9w0BAQQFADBJMQswCQYDVQQGEwJVUzEV
…
jpxfLM98xyFVyLCbkr3dZ3Tvxvi732BXePKF2A==
-----END X509 CERTIFICATE-----

On each system, edit the /etc/inet/ike/config file to recognize the certificates.

The administrator of the remote system provides the values for the cert_trust, remote_addr, and remote_id parameters.

For example, on the partym system, the ike/config file would appear similar to the following:

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

cert_trust "192.168.13.213"
cert_trust "192.168.116.16"

## Parameters that may also show up in rules.

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

{
 label "US-partym to JA-enigmax"
 local_id_type dn
 local_id "C=US, O=PartyCompany, OU=US-Partym, CN=Partym"
 remote_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax"

 local_addr  192.168.13.213
 remote_addr 192.168.116.16

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

On the enigma system, add enigma values for local parameters in the ike/config file.

For the remote parameters, use partym values. Ensure that the value for the label keyword is unique. The value must be different from the remote system's label value.

…
{
 label "JA-enigmax to US-partym"
 local_id_type dn
 local_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax"
 remote_id "C=US, O=PartyCompany, OU=US-Partym, CN=Partym"

 local_addr  192.168.116.16
 remote_addr 192.168.13.213
…

On each system, add the certificate that you received.
1. Copy the public key from the administrator's email.
2. Type the ikecert certdb –a command and press the Return key.
  
  No prompts display when you press the Return key.
  # ikecert certdb -a Press the Return key
3. Paste the public key. Then press the Return key. To end the entry, press Control-D.
  -----BEGIN X509 CERTIFICATE----- MIIC… … ----END X509 CERTIFICATE----- Press the Return key <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. The public key hash for the shared certificate should be identical on the two systems.

For example, on the partym system, list the stored certificates.

partym # ikecert certdb -l
Certificate Slot Name: 0   Type: rsa-md5
    Subject Name: <C=US, O=PartyCompany, OU=US-Partym, CN=Partym>
    Key Size: 1024
    Public key hash: B2BD13FCE95FD27ECE6D2DCD0DE760E2

Certificate Slot Name: 1   Type: rsa-md5
    (Private key in certlocal slot 0)
    Subject Name: <C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax>
    Key Size: 1024
    Public key hash: 2239A6A127F88EE0CB40F7C24A65B818

On the enigma system, list the stored certificates.

enigma # ikecert certdb -l
Certificate Slot Name: 4   Type: rsa-md5
    Subject Name: <C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax>
    Key Size: 1024
    Public key hash: DF3F108F6AC669C88C6BD026B0FCE3A0

Certificate Slot Name: 5   Type: rsa-md5
    (Private key in certlocal slot 4)
    Subject Name: <C=US, O=PartyCompany, OU=US-Partym, CN=Partym>
    Key Size: 1024
    Public key hash: 2239A6A127F88EE0CB40F7C24A65B818

Note –

In this example, the public key hash is different from the public key hash that your systems generate.

How to Configure IKE With Certificates Signed by a CA

On the system console, become superuser or assume an equivalent role.

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 ikecert certlocal -kc command to create a certificate request.

For a description of the arguments to the command, see Step 2 in How to Configure IKE With Self-Signed Public Key Certificates.

# ikecert certlocal -kc -m keysize -t keytype \
-D dname -A altname

For example, the following command creates a certificate request on the partym system:

# ikecert certlocal -kc -m 1024 -t rsa-md5 \
> -D "C=US, O=PartyCompany\, Inc., OU=US-Partym, CN=Partym" \
> -A "DN=C=US, O=PartyCompany\, Inc., OU=US-Partym"
Creating software private keys.
  Writing private key to file /etc/inet/secret/ike.privatekeys/2.
Enabling external key providers - done.
Certificate Request: 
  Proceeding with the signing operation.
  Certificate request generated successfully (…/publickeys/0)
Finished successfully.
-----BEGIN CERTIFICATE REQUEST-----
MIIByjCCATMCAQAwUzELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFEV4YW1wbGVDb21w
…
lcM+tw0ThRrfuJX9t/Qa1R/KxRlMA3zckO80mO9X
-----END CERTIFICATE REQUEST-----

The following command creates a certificate request on the enigma system:

# ikecert certlocal -kc -m 1024 -t rsa-md5 \
> -D "C=JA, O=EnigmaCo\, Inc., OU=JA-Enigmax, CN=Enigmax" \
> -A "DN=C=JA, O=EnigmaCo\, Inc., OU=JA-Enigmax"
Creating software private keys.
…
Finished successfully.
-----BEGIN CERTIFICATE REQUEST-----
MIIBuDCCASECAQAwSTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDFBhcnR5Q29tcGFu
…
8qlqdjaStLGfhDOO
-----END CERTIFICATE REQUEST-----

Submit the certificate request to a PKI organization.

The PKI organization can tell you how to submit the certificate request. Most organizations have a web site with a submission form. The form requires proof that the submission is legitimate. Typically, you paste your certificate request into the form. When your request has been checked by the organization, the organization issues you the following two certificate objects and a list of revoked certificates:
- Your public key certificate – This certificate is based on the request that you submitted to the organization. The request that you submitted is part of this public key certificate. The certificate uniquely identifies you.
- A Certificate Authority – The organization's signature. The CA verifies that your public key certificate is legitimate.
- A Certificate Revocation List (CRL) – The latest list of certificates that the organization has revoked. The CRL is not sent separately as a certificate object if access to the CRL is embedded in the public key certificate.
  
  When a URI for the CRL is embedded in the public key certificate, IKE can automatically retrieve the CRL for you. Similarly, when a DN (directory name on an LDAP server) entry is embedded in the public key certificate, IKE can retrieve and cache the CRL from an LDAP server that you specify.
  
  See How to Handle a Certificate Revocation List for an example of an embedded URI and an embedded DN entry in a public key certificate.

Add each certificate to your system by using the ikecert certdb -a command.

The -a option adds the pasted object to the appropriate certificate database on your system. For more information, see IKE With Public Key Certificates.
1. On the system console, become superuser or assume an equivalent role.
2. Add the public key certificate that you received from the PKI organization.
  # ikecert certdb -a Press the Return key Paste the certificate: -----BEGIN X509 CERTIFICATE----- … -----END X509 CERTIFICATE---- Press the Return key <Control>-D
3. Add the CA from the PKI organization.
  # ikecert certdb -a Press the Return key Paste the CA: -----BEGIN X509 CERTIFICATE----- … -----END X509 CERTIFICATE---- Press the Return key <Control>-D
4. If the PKI organization has sent a list of revoked certificates, add the CRL to the certrldb database:
  # ikecert certrldb -a Press the Return key Paste the CRL: -----BEGIN CRL----- … -----END CRL---- Press the Return key <Control>-D

Edit the /etc/inet/ike/config file to recognize the PKI organization.

Use the name that the PKI organization provides.

For example, the ike/config file on the partym system might appear similar to the following:

# 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 des }
p2_pfs 2

{
 label "US-partym to JA-enigmax - Example PKI"
 local_id_type dn
 local_id  "C=US, O=PartyCompany, OU=US-Partym, CN=Partym"
 remote_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax"

 local_addr  192.168.13.213
 remote_addr 192.168.116.16

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

Note –

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

On the enigma system, use enigma values for local parameters and partym values for remote parameters.

Ensure that the value for the label keyword is unique. The value must be different from the remote system's label value.

…
{
 label "JA-enigmax to US-partym - Example PKI"
 local_id_type dn
 local_id   "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax"
 remote_id  "C=US, O=PartyCompany, OU=US-Partym, CN=Partym"
 
 local_addr  192.168.116.16
 remote_addr 192.168.13.213
…

If the PKI organization does not provide a CRL, add the keyword ignore_crls to the ike/config file.
# Trusted root cert … cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example, CN=Example PKI" ignore_crls …
The ignore_crls keyword tells IKE not to search for CRLs.

If the PKI organization provides a central distribution point for CRLs, you can modify the ike/config file to point to that location.

See How to Handle a Certificate Revocation List for examples.

Note –
The following steps are necessary only if rsa_encrypt is the auth_method in the /etc/inet/ike/config file.

Because the auth_method parameter is set to rsa_encrypt, add the peer's certificate to the publickeys database.
1. Send the certificate to the remote system's administrator.
  
  You can paste the certificate into an email.
  1. For example, the partym administrator would send the following email:
    To: admin@ja.enigmaexample.com From: admin@us.partyexample.com Message: -----BEGIN X509 CERTIFICATE----- MII… ----END X509 CERTIFICATE-----
  2. The enigma administrator would send the following email:
    To: admin@us.partyexample.com From: admin@ja.enigmaexample.com Message: -----BEGIN X509 CERTIFICATE----- MII … -----END X509 CERTIFICATE-----
2. On each system, add the emailed certificate to the local publickeys database.
  # ikecert certdb -a Press the Return key -----BEGIN X509 CERTIFICATE----- MII… -----END X509 CERTIFICATE----- Press the Return key <Control>-D
The authentication method for RSA encryption hides identities in IKE from eavesdroppers. Because the rsa_encrypt method hides identities, IKE does not know the peer. Therefore, IKE cannot retrieve the peer's certificate. As a result, this method requires that the IKE peers know each other's public keys. Therefore, when you use an auth_method of rsa_encrypt in the /etc/inet/ike/config file, you must add the peer's certificate to the publickeys database. So, the publickeys database then holds three certificates for each communicating pair of systems:
- Your public key certificate
- The CA certificate
- The peer's public key certificate

How to Generate and Store Public Key Certificates on Hardware

Prerequisites for generating and storing public keys and public key certificates on hardware include the following:

The hardware must be configured.
The /etc/inet/ike/config file must point to a library that is implemented according to the following standard: RSA Security Inc. PKCS #11 Cryptographic Token Interface (Cryptoki), that is, a PKCS #11 library.

See How to Use the Sun Crypto Accelerator 4000 Board With IKE for setup instructions.

Generating and storing public key certificates on hardware is similar to generating and storing public key certificates on your system. There are two differences:

The ikecert certlocal and ikecert certdb commands must identify the hardware. The -T option with the token ID identifies the hardware to the commands.
The /etc/inet/ike/config file must point to the hardware with the pkcs11_path keyword.

On the system console, become superuser or assume an equivalent role.

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.

Generate a self-signed certificate or a certificate request, and specify the token ID. Choose one of the following options:

Note –

The Sun Crypto Accelerator 4000 board supports keys up to 2048 bits for RSA. For DSA, this board supports keys up to 1024 bits.

For a self-signed certificate, use this syntax.

# ikecert certlocal -ks -m 1024 -t rsa-md5 \
> -D "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" \
> -a -T SUN-4000-stor IP=192.168.116.16
Creating hardware private keys.
Enter PIN for PKCS#11 token: Type user:password
-----BEGIN X509 CERTIFICATE-----
MIIBwjCCASsCBD9bz5swDQYJKoZIhvcNAQEEBQAwKDELMAkGA1UEBhMCVVMxGTAX
…
PiktCuvURc1TXswaFyftzmLKWafUOQ==
-----END X509 CERTIFICATE-----

The argument to the -T option is the token ID from the attached Sun Crypto Accelerator 4000 board.

For a certificate request, use this syntax.

# ikecert certlocal -kc -m 1024 -t rsa-md5 \
> -D "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" \
> -a -T SUN-4000-stor IP=192.168.116.16
Creating hardware private keys.
Enter PIN for PKCS#11 token: Type user:password
-----BEGIN X509 CERTIFICATE-----
MIIBuDCCASECAQAwSTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDFBhcnR5Q29tcGFu
…
oKUDBbZ9O/pLWYGr
-----END X509 CERTIFICATE-----

For a description of the arguments to the ikecert command, see the ikecert(1M) man page

At the prompt for a PIN, type the Sun Crypto Accelerator 4000 user, a colon, and the user's password.

If the Sun Crypto Accelerator 4000 board has a user ikemgr whose password is rgm4tigt, you would type the following:
Enter PIN for PKCS#11 token: ikemgr:rgm4tigt
Note –
The PIN response is stored on disk as clear text.

Send your certificate for use by the other party. Choose one of the following options:
- Send the self-signed certificate to the remote system. You can paste the certificate into an email.
- Send the certificate request to an organization that handles PKI. Follow the instructions of the PKI organization to submit the certificate request. For a more detailed discussion, see Step 3 of How to Configure IKE With Certificates Signed by a CA.

On your system, edit the /etc/inet/ike/config file to recognize the certificates. Choose one of the following options.

For a self-signed certificate, use the values that the administrator of the remote system provides for the cert_trust, remote_id, and remote_addr parameters.

For example, on the enigma system, the ike/config file would appear similar to the following:

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

cert_trust "192.168.116.16"  Local system's certificate
cert_trust "192.168.13.213"  Remote system's certificate

pkcs11_path "/opt/SUNWconn/lib/libpkcs11.so" Hardware connection
…
{
 label "JA-enigmax to US-partym"
 local_id_type dn
 local_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax"
 remote_id "C=US, O=PartyCompany, OU=US-Partym, CN=Partym"

 local_addr  192.168.116.16
 remote_addr 192.168.13.213

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

For a certificate request, enter the name that the PKI organization provides as the value for the cert_root keyword.

For example, the ike/config file on the enigma system might appear similar to the following:

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

pkcs11_path "/opt/SUNWconn/lib/libpkcs11.so" Hardware connection
…
{
 label "JA-enigmax to US-partym - Example PKI"
 local_id_type dn
 local_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax"
 remote_id  "C=US, O=PartyCompany, OU=US-Partym, CN=Partym"

 local_addr  192.168.116.16
 remote_addr 192.168.13.213

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

Place the certificates from the other party in the hardware.

Respond to the PIN request as you responded in Step 3.

Note –
You must add the public key certificates to the same attached hardware that generated your private key.
- For a self-signed certificate, add the remote system's self-signed certificate.
  # ikecert certdb -a -T SUN-4000-stor Press the Return key Paste the self-signed certificate <Control>-D Enter PIN for PKCS#11 token: Type user:password
  If you used rsa_encrypt as the value for the auth_method parameter for a self-signed certificate, add the peer's certificate to the hardware store.
  # ikecert certdb -a -T SUN-4000-stor Press the Return key Paste the peer's certificate <Control>-D Enter PIN for PKCS#11 token: Type user:password
- For certificates from a PKI organization, add the certificate that the organization generated from your certificate request, and add the certificate authority (CA).
  # ikecert certdb -a -T SUN-4000-stor Press the Return key Paste the returned certificate <Control>-D Enter PIN for PKCS#11 token: Type user:password
  # ikecert certdb -a -T SUN-4000-stor Press the Return key Paste the CA certificate <Control>-D Enter PIN for PKCS#11 token: Type user:password
  To add a certificate revocation list (CRL) from the PKI organization, see How to Handle a Certificate Revocation List.

How to Handle a Certificate Revocation List

A certificate revocation list (CRL) contains outdated or compromised certificates from a Certificate Authority. You have four ways to handle CRLs.

If your CA organization does not issue CRLs, you can instruct IKE to ignore CRLs in your /etc/inet/ike/config file. This option is shown in Step 6 in How to Configure IKE With Certificates Signed by a CA.
IKE can access the CRLs from a URI (uniform resource indicator) whose address is embedded in the public key certificate from the CA.
IKE can access the CRLs from an LDAP server whose DN (directory name) entry is embedded in the public key certificate from the CA.
You can provide the CRL as an argument to the ikecert certrldb command.

The following procedure describes how to instruct IKE to use CRLs from a central distribution point.

Display the certificate that you received from the CA.

# ikecert certdb -lv certspec

-l: Lists certificates in the IKE certificate database.
-v: Lists the certificates in verbose mode. Use this option with care.
certspec: Is a pattern that matches a certificate in the IKE certificate database.

For example, the following certificate was issued by Sun Microsystems. Details have been altered.

# ikecert certdb -lv example-protect.sun.com
Certificate Slot Name: 0   Type: dsa-sha1
   (Private key in certlocal slot 0)
 Subject Name: <O=Sun Microsystems Inc, CN=example-protect.sun.com>
 Issuer Name: <CN=Sun Microsystems Inc CA (Cl B), O=Sun Microsystems Inc>
 SerialNumber: 14000D93
   Validity:
      Not Valid Before: 2002 Jul 19th, 21:11:11 GMT
      Not Valid After:  2005 Jul 18th, 21:11:11 GMT
   Public Key Info:
      Public Modulus  (n) (2048 bits): C575A…A5
      Public Exponent (e) (  24 bits): 010001
   Extensions:
      Subject Alternative Names:
              DNS = example-protect.sun.com
      Key Usage: DigitalSignature KeyEncipherment
      [CRITICAL]
   CRL Distribution Points:
      Full Name:
         URI = #Ihttp://www.sun.com/pki/pkismica.crl#i
         DN = <CN=Sun Microsystems Inc CA (Cl B), O=Sun Microsystems Inc>
      CRL Issuer: 
      Authority Key ID:
      Key ID:              4F … 6B
      SubjectKeyID:        A5 … FD
      Certificate Policies
      Authority Information Access

Notice the CRL Distribution Points data. The URI entry indicates that this organization's CRL is available on the web. The DN entry indicates that the CRL is also available on an LDAP server. You can use one of these two options.

To use the URI, add the keyword use_http to the host's /etc/inet/ike/config file.

For example, the ike/config file would appear similar to the following:
# Use CRL from organization's URI use_http …
You can also use a web proxy by adding the keyword proxy in the ike/config file. The proxy keyword takes a URL as an argument, as in the following:
proxy "http://proxy1:8080"
IKE retrieves the CRL and caches the CRL until the certificate expires.

To use LDAP, use the LDAP server as an argument to the ldap-list keyword in the host's /etc/inet/ike/config file.

Your organization provides the name of the LDAP server. The entry in the ike/config file would appear similar to the following:
# Use CRL from organization's LDAP ldap-list "ldap1.sun.com:389,ldap2.sun.com" …
IKE retrieves the CRL and caches the CRL until the certificate expires.

Example—Pasting a CRL Into the Local `certrldb` Database

If the PKI organization's CRL is not available from a central distribution point, you can add the PKI organization's CRL manually to the local certrldb database. Follow the PKI organization's instructions for extracting the CRL, then add the CRL to the database with the ikecert certrldb –a command.

# ikecert certrldb -a
Press the Return key
Paste the CRL from the PKI organization
Press the Return key
Press <Control>-D to enter the CRL into the database

Using Hardware With IKE (Task Map)

Task	Description	For Instructions
Off-load IKE key operations to the Sun Crypto Accelerator 1000 board	Involves setting the path to the PKCS#11 library.	How to Use the Sun Crypto Accelerator 1000 Board With IKE
Off-load IKE key operations and store the keys on the Sun Crypto Accelerator 4000 board	Involves setting the path to the PKCS#11 library, and listing the available token IDs.	How to Use the Sun Crypto Accelerator 4000 Board With IKE

How to Use the Sun Crypto Accelerator 1000 Board With IKE

Note –

The following procedure assumes that a Sun Crypto Accelerator 1000 board is attached to the system. The procedure also assumes that the software for the board has been installed and that the software has been configured. For instructions, see the Sun Crypto Accelerator 1000 Board Version 1.1 Installation and User's Guide.

On the system console, become superuser or assume an equivalent role.

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.

Add the PKCS #11 library path to the /etc/inet/ike/config file.
pkcs11_path "/opt/SUNWconn/lib/libpkcs11.so"
The path name must point to a 32-bit PKCS #11 library. If the library is present, IKE uses the library's routines to accelerate IKE public key operations on the Sun Crypto Accelerator 1000 board. When the board handles these expensive operations, operating system resources are free for other operations.

Close the file and reboot.

After rebooting, check that the library has been linked. Type the following command to determine whether a PKCS #11 library has been linked:

# ikeadm get stats
Phase 1 SA counts:
Current:   initiator:          0   responder:          0
Total:     initiator:          0   responder:          0
Attempted: initiator:          0   responder:          0
Failed:    initiator:          0   responder:          0
           initiator fails include 0 time-out(s)
PKCS#11 library linked in from /opt/SUNWconn/lib/libpkcs11.so
#

Unlike other parameters in the /etc/inet/ike/config file, the pkcs11_path keyword is read only when IKE is started. If you use the ikeadm command to add or reload a new /etc/inet/ike/config file, the pkcs11_path persists. The path persists because the IKE daemon does not clobber data from the Phase 1 exchange. Keys that are accelerated by PKCS #11 are part of Phase 1 data.

How to Use the Sun Crypto Accelerator 4000 Board With IKE

Note –

The following procedure assumes that a Sun Crypto Accelerator 4000 board is attached to the system. The procedure also assumes that the software for the board has been installed and that the software has been configured. For instructions, see the Sun Crypto Accelerator 4000 Board Installation and User's Guide. The guide is available from the Sun Hardware Documentation web site, under Network and Security Products.

On the system console, become superuser or assume an equivalent role.

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.

Add the PKCS #11 library path to the /etc/inet/ike/config file.
pkcs11_path "/opt/SUNWconn/lib/libpkcs11.so"
The path name must point to a 32-bit PKCS #11 library. If the library is present, IKE uses the library's routines to handle key generation and key storage on the Sun Crypto Accelerator 4000 board.

Close the file and reboot.

After rebooting, check that the library has been linked. Type the following command to determine whether a PKCS #11 library has been linked:
$ ikeadm get stats … PKCS#11 library linked in from /opt/SUNWconn/lib/libpkcs11.so $
Unlike other parameters in the /etc/inet/ike/config file, the pkcs11_path keyword is read only when IKE is started. If you use the ikeadm command to add or reload a new /etc/inet/ike/config file, the pkcs11_path persists. The path persists because the IKE daemon does not clobber Phase 1 data.

Note –
The Sun Crypto Accelerator 4000 board supports keys up to 2048 bits for RSA. For DSA, this board supports keys up to 1024 bits.

Find the token ID for the attached Sun Crypto Accelerator 4000 board.
$ ikecert tokens Available tokens with library "/opt/SUNWconn/lib/libpkcs11.so": "SUN-1000-accel " "SUN-4000-stor "
The library returns a token ID, also called a keystore name, of 32 characters. In this example, you could use the SUN-4000-stor token with the ikecert commands to store IKE keys

For instructions on how to use the token, see How to Generate and Store Public Key Certificates on Hardware.

The trailing spaces are automatically padded by the ikecert command.

Chapter 4 Administering IKE (Tasks)

Configuring IKE (Task Map)

Configuring IKE With Preshared Keys (Task Map)

How to Configure IKE With Preshared Keys

How to Refresh Existing Preshared Keys

How to Add a New Preshared Key

How to Verify That the Preshared Keys Are Identical

Configuring IKE With Public Key Certificates (Task Map)

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 on Hardware

How to Handle a Certificate Revocation List

Example—Pasting a CRL Into the Local certrldb Database

Using Hardware With IKE (Task Map)

How to Use the Sun Crypto Accelerator 1000 Board With IKE

How to Use the Sun Crypto Accelerator 4000 Board With IKE

Example—Pasting a CRL Into the Local `certrldb` Database