IPsec and IKE Administration Guide

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.

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

How to Configure IKE With Pre-Shared Keys

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 total 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 /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"
  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 auth_method must be on the same line.

Modify the 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"
  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
}

Note –

These system names are examples only. Use the names and addresses of your systems when securing traffic between your systems.

On each system, 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, 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 command, see How to Generate Random Numbers and the od(1) man page.

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

The authentication algorithm in this example 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 pre-shared key. The output of the MD5 algorithm is 128 bits, or 32 characters. Since a longer key length is a good idea, the example key is 56 characters long.

For example, on the enigma system, ike.preshared would look like 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, ike.preshared would look like 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 pre-shared keys must be identical.

IKE is now configured for use with IPsec.

Example—Check That the Pre-Shared Keys are Identical

If the pre-shared keys on the communicating systems are not identical, you get the following error message:

# rup system2
system2: RPC: Rpcbind failure

To view the pre-shared key, the in.iked daemon must be running at privilege level 0x2. On each system, use the ikeadm command to dump the pre-shared key information:

# /usr/sbin/ikeadm get priv
Current privilege level is 0x2, access to keying material enabled
# ikeadm dump preshared
PSKEY: Pre-shared 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 pre-shared keys are not identical, replace one key with the other key in the /etc/inet/secret/ike.preshared file.

How to Refresh Existing Pre-Shared Keys

This procedure assumes that you want to replace an existing pre-shared 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 total security of the system is reduced to the security of the remote login session.

Generate random keys and choose one of the keys.

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 03efe016 216e60ac e316f663 a2f073e0 7f90d069 316d99b5 00f8384c 2142610a
For an explanation of the command, see How to Generate Random Numbers and the od(1) man page.

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.

For example,
# ikeadm read preshared

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

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

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

How to Add a New Pre-Shared Key

If you are using pre-shared keys, you must have one pre-shared key for every policy entry in the ipsecinit.conf file. If you add new policy entries while IPsec and IKE are running, the in.iked daemon can read in new keys. This procedure assumes the following:

The in.iked daemon is running
The interface that you want to protect with IPsec is an entry in the /etc/hosts file on both systems, for example:
192.168.15.7 ada
You have added a new policy entry to the /etc/inet/ipsecinit.conf file on both systems. For example, the entry on enigma looks something like the following:
{laddr enigma raddr ada} ipsec {auth_algs any encr_algs any sa shared}
For example, the entry on ada looks something like the following:
{laddr ada raddr enigma} ipsec {auth_algs any encr_algs any sa shared}

You have created a rule for the interface on ada in the /etc/inet/ike/config file on both systems. For example, the rule on enigma looks something like the following:

### ike/config file on enigma, 192.168.116.16
…
## The rule to communicate with partym-15
{ label "Enigma-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
	}

For example, the rule on ada looks something like 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
}

Note –

All arguments to auth_method must be on the same line.

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 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. After killing the daemon, restart the daemon 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 combine the output to create a key of 64 to 448 bits.

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

# od -X -A n /dev/random | head -4
        0fb834c5 8d1fb4ee 500e2bea 071deb2e
        781cb483 74411af5 a9671714 672bb174
        9ad9364d 53574f27 4aacea56 c34861bb
        b4509514 145c1845 f857ff2b 6e5e3766

For an explanation of the command, see How to Generate Random Numbers and the od(1) man page.

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

You are both going to add the same pre-shared key at the same time.

Add the new keying material with the add preshared subcommand in the ikeadm command mode.

ikeadm> add preshared { localidtype id-type localid id
remoteidtype id-type remoteid id ike_mode mode key key }

`id-type`	The type of the `id`.
`id`	IP address when `id-type` is IP.
`mode`	The IKE mode. `main` is the only accepted value.
`key`	The pre-shared key in hexadecimal format.

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

# 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, the administrator would add the identical key, as in:

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

Note –

A message of the form Error: invalid preshared key definition indicates that you gave incorrect arguments to the add preshared command. You might have mistyped a parameter. You might have omitted a parameter. 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 interface.
# ipsecconf -a /etc/inet/ipsecinit.conf
Note –
Read the warning when you execute the command. A socket that is already latched, that is, the socket is in use, provides an unsecured back door into the system.

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

A sample of the new rules for ada and enigma are 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.
# ikeadm read rules

To ensure that IKE pre-shared keys are available at reboot, edit the /etc/inet/secret/ike.preshared file.

Enter the arguments to the add preshared command into the file on each system, as shown in the following substeps.

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 04413a3e68854b732742024d19995f7972136a2f33e5d302bdd7b2624e4c6429
	}

On the ada system, you would add the following keying information to the ike.preshared file:

# ike.preshared for the ada interface, 192.168.15.7
#…
{ 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 04413a3e68854b732742024d19995f7972136a2f33e5d302bdd7b2624e4c6429
	}

How to Configure IKE With Self-Signed Public 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 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.

# ikecert certlocal -ks -m keysize -t keytype \
-D dname -A altname[ ... ] [-f output]

`-ks`	Creates a self-signed certificate
`keysize`	The size of the key. `keysize` can be 512, 1024, 2048, 3072, or 4096.
`keytype`	The type of algorithm to use. `keytype` can be rsa-sha1, rsa-md5, or dsa-sha1.
`dname`	The X.509 distinguished name for the certificate subject. `dname` typically has the form: C=country, O=organization, OU=organizational unit, CN=common name. Valid tags are C, O, OU, and CN.
`altname`	The alternate name for the certificate. `altname` should be in the form of `tag=value`. Valid tags are `IP`, `DNS`, `EMAIL`, `URI`, `DN`, and `RID`.
`output`	The format of the encoding output. The possible values are `pem` for PEM Base64, and `ber` for ASN.1 BER. If `-f` is not specified, `pem` is assumed.

For example,

# ikecert certlocal -ks -m 1024 -t rsa-md5 \
> -D "C=US, O=ExampleCompany, OU=US-Example, CN=Example" \
> -A IP=192.168.116.16
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-----

On the sending system, 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.116.16"
cert_trust "192.168.13.213"

## 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 "UN-Example to US-Example"
 local_id_type dn
 local_id "C=US, O=ExampleCompany, OU=UN-Example, CN=Example"
 remote_id "C=US, O=ExampleCompany, OU=US-Example, CN=Example"

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

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>.
  
  No prompts display when you type the <Return> key.
  # ikecert certdb -a <Type the Return key>
3. Paste the public key. Then type <Return>.
  -----BEGIN X509 CERTIFICATE----- MIICL… … KgDid/nxWPlWQU5vMAiwJXfa0sw/A12w448JVkVmEWaf -----END X509 CERTIFICATE-----<Type the Return key>
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. The public key hash on one system should be identical to the public key hash on the communicating system.

For example, on enigma, type the ikecert certdb -l command.

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

On partym, type theikecert certlocal -l command.

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

Note –

The public key hash in this example is different from the public key hash that your systems generate.

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

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

The arguments to the command should be the same arguments that you would use for a ikecert certlocal -ks command.

# ikecert certlocal -kc -m keysize -t keytype \
-D dname -A altname[ ... ] [-f output]

`-kc`	Creates a public and private key pair. Also, `-kc` creates a certificate request that is based on the public key that was generated.
`keysize`	The size of the key. `keysize` can be 512, 1024, 2048, 3072, or 4096.
`keytype`	The type of algorithm to use. `keytype` can be rsa-sha1, rsa-md5, or dsa-sha1.
`dname`	The X.509 distinguished name for the certificate subject. `dname` typically has the form: C=country, O=organization, OU=organizational unit, CN=common name. Valid tags are C, O, OU, and CN.
`altname`	The alternate name for the certificate. `altname` should be in the form of `tag=value`. Valid tags are `IP`, `DNS`, `EMAIL`, `URI`, `DN`, and `RID`.
`output`	The format of the encoding output. The possible values are `pem` for PEM Base64, and `ber` for ASN.1 BER. If `-f` is not specified, `pem` is assumed.

For example, the following command creates a certificate request:

# 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 certificate request to an organization that handles PKI.

The organization might be an outside Certificate Authority or PKI. Also, a company might run its own PKI. The PKI 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 two or three certificate objects:
- Your publickeys certificate – This certificate is based on the request you submitted to the organization. The certificate that you submitted is part of this publickeys certificate. The certificate uniquely identifies you.
- A Certificate Authority – The organization's signature. The CA verifies that your publickeys 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 publickeys certificate.
  
  When a URI for the CRL is embedded in the publickeys certificate, IKE can automatically retrieve the CRL for you. Similarly, when a DN entry is embedded in the publickeys certificate, IKE can automatically retrieve the CRL from an LDAP server that you specify.
  
  See How to Access a Certificate Revocation List for an example of an embedded URI and an embedded DN entry in a publickeys certificate.

Enter each certificate as the argument to one of three ikecert commands.

The commands use the -a option. The -a option adds the pasted object to the appropriate certificate database on your system. For more information, see Using Public Key Certificates.
1. On the system console, become superuser or assume an equivalent role.
2. Type the ikecert certdb –a command and type <Return>.
  # ikecert certdb -a <Type the Return key>
3. Paste the publickeys certificate that you received from the organization and type <Return>.
  -----BEGIN X509 CERTIFICATE----- … -----END X509 CERTIFICATE----<Type the Return key>
4. End the entry by typing <Control-D>.
  <Control-D>
5. Type the ikecert certdb –a command and type <Return>.
  # ikecert certdb -a <Type the Return key>
6. Paste the organization's CA. Type <Return>. Then type <Control-D> to end the entry.
  -----BEGIN X509 CERTIFICATE----- … -----END X509 CERTIFICATE-----<Type the Return key> <Control-D>
7. If the organization has sent a CRL object, type the ikecert certrldb –a command and type <Return>.
  # ikecert certrldb -a <Type the Return key>
8. Paste the organization's CRL. Type <Return>. Then type <Control-D> to end the entry.

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

Use the name that the organization 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 des }
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 "C=US, O=ExampleCompany, OU=UN-Example, CN=Example"

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

Note –

All arguments to auth_method must be on the same line.

If the PKI organization does not provide a CRL, add the keyword ignore_crls to the ike/config file.

ignore_crls tells IKE not to search for CRLs. For example,
# Trusted root cert … cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example, CN=Example PKI" ignore_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 Access a Certificate Revocation List for examples.

Repeat Step 1 through Step 7 on the communicating system.

Following the example, the “…OU=UN-Example…” system runs the ikecert commands as you have done. The /etc/inet/ike/config file of the “…OU=UN-Example…” system uses its local information for local parameters. The system uses 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"
ignore_crls

## 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 "UN-Example to US-Example - Example PKI"
 local_id_type dn
 local_id "C=US, O=ExampleCompany, OU=UN-Example, CN=Example"
 remote_id "C=US, O=ExampleCompany, OU=US-Example, CN=Example"

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

Because auth_method is rsa_encrypt, add the peer's certificate to the publickeys database.

Note –

The following substeps are necessary only if the p1_xform in the /etc/inet/ike/config file uses the rsa_encrypt authentication method.

Send the certificate to the communicating system's administrator.

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

To: root@un.example.com
From: root@us.example.com
Message: -----BEGIN CERTIFICATE REQUEST-----
MIIByjCCATMCAQAwUzELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFEV4YW1wbGVDb21w
…
lcM+tw0ThRrfuJX9t/Qa1R/KxRlMA3zckO80mO9X
-----END CERTIFICATE REQUEST-----

On each system, add its peer's certificate to the local publickeys database.

For example, on the un.example.com system, type the following and paste the contents of the email:

# ikecert certdb -a <Type the Return key>
-----BEGIN CERTIFICATE REQUEST-----
MIIByjCCATMCAQAwUzELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFEV4YW1wbGVDb21w
…
lcM+tw0ThRrfuJX9t/Qa1R/KxRlMA3zckO80mO9X
-----END CERTIFICATE REQUEST-----

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, the method requires that the IKE peers know each other's public keys. Therefore, when you use auth_method 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. The database holds your publickeys certificate, the CA certificate, and the peer's certificate. The CRL database still holds any revoked certificates.

The IKE daemon authenticates itself with the public keys and with the CA when the following completes:

The /etc/hosts file on each system has been modified to include the protected interfaces
The /etc/inet/ipsecinit.conf file on each system has been modified to include the protected interfaces
Both systems are rebooted.

How to Access a Certificate Revocation List

A Certificate Revocation List (CRL) handles 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 was shown in How to Configure IKE With Public Keys Signed by a Certificate Authority.
IKE can access the CRLs from a URI whose address is embedded in the publickeys certificate from the CA.
IKE can access the CRLs from an LDAP server whose DN entry is embedded in the publickeys certificate from the CA. You specify the LDAP server as an argument to the ldap-list keyword in the /etc/inet/ike/config file.
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 PKI organization by using the ikecert certdb –lv certspec command.

`-l`	Lists certificates in the IKE certificate database.
`-v`	Lists the certificates in verbose mode. Use this option with care.
`certspec`	Match the `certspec` pattern to a pattern in the certificate.

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: if-modn
   (Private key in certlocal slot 0)
 Subject Name: <O=Sun Microsystems Inc, CN=example-protect.sun.com>
 Issuer Name: <CN=Sun Microsystems Inc CA (Class 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 (Class 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 Certificate Revocation List 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, put the keyword use_http in the host's /etc/inet/ike/config file.

For example, the ike/config file would look like the following:
# Use CRL from organization's URI use_http …
IKE retrieves the CRL and caches the CRL until the certificate expires.

You can also use a web proxy by putting the keyword proxy in the ike/config file. proxy takes a URL as an argument, as in the following:
proxy "http://proxy1:8080"

To use LDAP, enter 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 look something like 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

The example shows how to use a CRL that is not available from a central distribution point.

If your organization's certificate does not contain a central distribution point, you can add the organization's CRL manually to the local crls database. You follow the organization's instructions for extracting the CRL, then add the CRL to the database with the ikecert certrldb –a command.

# ikecert certrldb -a<Type the Return key>
<Paste the CRL from the PKI organization.>

<Type the Return key.>
<Type <Control-D> to enter the CRL into the database.>

How to Use the Sun Crypto Accelerator 1000 Card With IKE

Note –

The following procedure assumes that a Sun Crypto Accelerator 1000 card is attached to the system. The procedure also assumes that the software for the card 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 total 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 pathname 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 1000 card. When the card 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 Phase 1 data. Keys that are accelerated by PKCS #11 are part of Phase 1 data.

IKE Tasks

How to Configure IKE With Pre-Shared Keys

Example—Check That the Pre-Shared Keys are Identical

How to Refresh Existing Pre-Shared Keys

How to Add a New Pre-Shared Key

How to Configure IKE With Self-Signed Public Certificates

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

How to Access a Certificate Revocation List

Example—Pasting a CRL Into the Local certrldb Database

How to Use the Sun Crypto Accelerator 1000 Card With IKE

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