System Administration Guide: IP Services

Chapter 21 Internet Key Exchange

Managing the keying material that IPsec SAs require for secure transmission of IP datagrams is called key management. Automatic key management requires a secure channel of communication for the creation, authentication, and exchange of keys. The Solaris operating environment uses Internet Key Exchange (IKE) to automate key management. IKE easily scales to provide a secure channel for a large volume of traffic. IPsec SAs on IPv4 packets can take advantage of IKE.

This chapter contains the following information:

IKE Overview

The Internet Key Exchange (IKE) daemon, in.iked(1M), negotiates and authenticates keying material for security associations in a protected manner. The daemon uses random seeds for keys from internal functions provided by the SunOS^TM. IKE provides Perfect Forward Secrecy (PFS), that is, the keys that protect data transmission are not used to derive additional keys, and seeds used to create data transmission keys are not reused.

When the IKE daemon discovers a remote host's public encryption key, the local system can then encrypt messages destined for the remote host whose public key it has discovered. The IKE daemon performs its job in two phases called exchanges.

Phase 1 Exchange

The Phase 1 exchange is known as Main Mode. In the Phase 1 exchange, IKE uses public-key encryption methods to authenticate itself with peer IKE entities. The result is an ISAKMP (Internet Security Association and Key Management Protocol) Security Association, which is a secure channel for IKE to negotiate keying material for the IP datagrams. Unlike IPsec SAs, the ISAKMP security associations are bidirectional, so only one is needed.

How IKE negotiates keying material in the Phase 1 exchange is configurable. IKE reads the configuration information from the /etc/inet/ike/config file. Configuration information includes the interfaces that are affected, the algorithms that are used, the authentication method, and if PFS is used. The two authentication methods are pre-shared keys and public key certificates The public key certificates can be self–signed, or they can be issued by a Certificate Authority (CA) from a PKI (Public Key Infrastructure) vendor. Vendors include iPlanet^TM Certificate Management System, Entrust, and Verisign.

Phase 2 Exchange

The Phase 2 exchange is known as Quick Mode. In the Phase 2 exchange, IKE creates and manages the IPsec SAs between hosts running the IKE daemon. IKE uses the secure channel that was created in Phase 1 to protect the transmission of keying material. The IKE daemon creates the keys from a random number generator (/dev/random), refreshes them at a configurable rate, and provides the keying material to algorithms specified in the IPsec policy configuration file.

Negotiating IKE

For two IKE daemons to authenticate each other requires a valid IKE configuration policy file, ike.config(4), and keying material. The policy file contains IKE policy entries that determine whether pre-shared keys or public key certificates are to be used to authenticate the Phase 1 exchange.

The key pair auth_method preshared indicates that pre-shared keys are used. Values for auth_method other than preshared are one indication that public key certificates are to be used. Public key certificates can be self-signed, or they can be installed from a PKI vendor.

Using Pre–Shared Keys

Pre-shared keys are created by an administrator on one system, and shared out of band with administrators of communicating systems. The administrator should take care to create large random keys and to protect the file and the out-of-band transmission. The keys are placed in the /etc/inet/secret/ike.preshared file on each system. The ike.preshared(4) file is for IKE as the ipseckeys file is for IPsec. Compromise of the keys in the ike.preshared file compromises all keys derived from them.

One system's pre-shared key must be identical to its communicating system's key. The keys are tied to a particular IP address, and are most secure when one administrator controls the communicating systems.

Using Public Key Certificates

Public key certificates eliminate the need for communicating systems to share secret keying material out of band. Public keys use the Diffie-Helman method of authenticating and negotiating keys. Public key certificates come in two flavors, self-signed, and certified by a Certificate Authority (CA).

Self-signed public key certificates are created by an administrator. The ikecert local -ks command creates the private part of the public-private key pair for the system. The administrator then gets the self-signed certificate output in X.509 format from the communicating system. The communicating system's certificate is input to the ikecert certdb command for the public part of the key pair. The self-signed certificates reside in the /etc/inet/ike/publickeys directory on the communicating hosts.

Self-signed certificates are a halfway point between pre-shared keys and CAs. Unlike pre-shared keys, a self-signed certificate can be used on a mobile machine, or a machine that may be renumbered. To do this, the administrator uses a DNS (www.example.org) or EMAIL (root@domain.org) alternative name.

Public keys can be delivered by a PKI or a CA vendor. The public keys and their accompanying CAs are installed in the /etc/inet/ike/publickeys directory by the administrator. Vendors also issue certificate revocation lists (CRLs). Along with installing the keys and CAs, the administrator is responsible for installing the CRLs in the /etc/inet/ike/crls directory.

CAs have the advantage of being certified by an outside vendor, rather than by the administrator of the site. In a sense, CAs are notarized certificates. Like self-signed certificates, they can be used on a mobile machine, or one that may be renumbered. Unlike self-signed certificates, they very easily scale to protecting a large number of communicating systems.

IKE Utilities and Files

This section describes the IKE configuration files and various commands that implement IKE. For instructions about how to implement IKE for your IPv4 network, see Implementing IKE Task Map.

Table 21–1 List of IKE Files and Commands


File or Command	Description
in.iked(1M) daemon	Internet Key Exchange (IKE) daemon. Activates automated key management.
ikeadm(1M)	IKE administration command. For viewing and modifying IKE policy.
ikecert(1M)	Certificate database management command. For manipulating local public-key certificate databases.
`/etc/inet/ike/config` file	IKE policy configuration file. Contains the site's rules for matching inbound IKE requests and preparing outbound IKE requests. If this file exists, the `in.iked` daemon starts automatically at boot time.
`/etc/inet/secret/ike.preshared` file	Pre-shared keys file. Contains secret keying material for Phase 1 authentication.
`/etc/inet/secret/ike.privatekeys` file	Private keys directory. Contains the private keys that are part of a public-private key pair.
`/etc/inet/ike/publickeys` directory	Directory to hold public keys and certificate files. By default, includes Sun certificates. Contains the public key part of a public-private key pair.
`/etc/inet/ike/crls` directory	Directory to hold revocation lists for public keys and certificate files.

IKE Daemon

The in.iked(1M) daemon automates the management of cryptographic keys for IPsec on a Solaris host. The daemon negotiates with a remote host running the same protocol to provide authenticated keying materials for security associations in a protected manner. The daemon must be running on all hosts that plan to communicate securely. The IKE daemon is automatically loaded at boot time if the IKE configuration policy file /etc/inet/ike/config exists.

When the IKE daemon runs, the system authenticates itself to its peer IKE entity (Phase 1). The peer is defined in the IKE policy file, as are the authentication methods. The daemon then establishes the keys for the session (Phase 2). At an interval specified in the policy file, the IKE keys are refreshed automatically. The in.iked daemon listens for incoming IKE requests from the network and for requests for outbound traffic via the PF_KEY socket. See the pf_key(7P) man page for more information.

Two programs support the IKE daemon. The ikeadm(1M) command enables the administrator to view IKE policy and modify it. The ikecert(1M) command enables the administrator to view and manage the public-key databases, ike.privatekeys and publickeys.

IKE Policy File

The IKE configuration policy file, /etc/inet/ike/config, provides the keying material for the IKE daemon itself, and for the IPsec SAs that it manages. The IKE daemon itself requires keying material in the Phase 1 exchange. Rules in the ike/config file establish the keying material. A valid rule in the policy file contains a label, identifies the hosts or networks that the keying material is for, and specifies the authentication method. See IKE Tasks for examples of valid policy files. See the ike.config(4) man page for examples and descriptions of its parameters.

The IPsec SAs are used on the IP datagrams that are protected according to policies set up in the IPsec configuration policy file, /etc/inet/ipsecinit.conf. The IKE policy file determines if PFS is used when creating the IPsec SAs.

The security considerations for the ike/config file are similar to those for the ipsecinit.conf file. See Security Considerations for details.

IKE Administration Command

The ikeadm command can check the syntax of the IKE configuration file, view aspects of the IKE daemon process, and change the parameters passed to the IKE daemon. The command can also gather statistics and debug IKE processes. See the ikeadm(1M) man page for examples and a full description of its options. The privilege level of the running IKE daemon determines what aspects of the IKE daemon can be viewed and modified. There are three levels of privilege.

0x0, or base level — At the base level of privilege, you cannot view or modify keying material. The base level is the default level at which the in.iked daemon runs.
0x1, or modkeys level — At the modkeys level of privilege, you can remove, change, and add pre-shared keys.
0x2, or keymat level — At the keymat level of privilege, you can view the actual keying material with the ikeadm command.

The security considerations for the ikeadm command are similar to those for the ipseckey command. See Security Considerations for details.

Pre-Shared Keys Files

The /etc/inet/secret/ directory contains the pre-shared keys for ISAKMP SAs and IPsec SAs. The ike.preshared file contains the pre-shared keys for ISAKMP SAs, and the ipseckeys file contains the pre-shared keys for IPsec SAs, when the administrator creates these keys manually. The secret directory is protected at 0700 and its files are protected at 0600.

The ike.preshared file is created by an administrator when the ike.config file requires pre-shared keys. The file contains keying material for ISAKMP SAs, that is, for IKE authentication. Because IKE uses the pre-shared keys to authenticate the Phase 1 exchange, the ike.preshared file must be valid before the in.iked daemon starts.
The ipseckeys file contains keying material for IPsec SAs. For IPv6 hosts, the administrator manually creates and updates the keys in this file. See IPsec Tasks for examples of manually managing the file. The IKE daemon does not use this file. The keying material that IKE generates for IPsec SAs is stored in the kernel.

IKE Public Key Databases and Commands

The ikecert(1M) command manipulates the local host's public-key databases. Because IKE uses these databases to authenticate the Phase 1 exchange when the ike.config file requires public key certificates, the directories must be populated before activating the in.iked daemon. Three subcommands handle each of the three databases: certlocal, certdb, and certrldb.

`ikecert certlocal` Command

The certlocal subcommand manages the private-key database in the /etc/inet/secret/ike.privatekeys directory. Options to the subcommand enable you to add, view, and remove private keys. The command also creates either a self-signed certificate or a certificate request. The -ks option creates a self-signed certificate, and the -kc option creates a certificate request.

Parameters that you pass to the certlocal subcommand when you create a private key must be reflected in the ike.config file, as shown in the following table.

Table 21–2 Correspondences Between ike certlocal and ike.config Values


`certlocal` options	`ike.config` entry	Notes
`-A` `Subject Alternate Name`	`cert_trust` `Subject Alternate Name`	A nickname that uniquely identifies the certificate. Possible values are IP address, email address, and domain name.
`-D` `X.509 Distinguished Name`	`cert_root` `X.509 Distinguished Name`	The full name of the certificate authority that includes Country, Organization name, Organizational Unit, and Common Name.
`-t dsa-sha1`	`auth_method dss_sig`	Slightly slower than RSA. Is not patented.
`-t rsa-md5` `-t rsa-sha1`	`auth_method rsa_sig`	Slightly faster than DSA. Patent expired in September 2000. The RSA public key must be large enough to encrypt the biggest payload, Typically, an identity payload, such as Distinguished Name, is the biggest.
`-t rsa-md5` `-t rsa-sha1`	`auth_method rsa_encrypt`	RSA encryption hides identities in IKE from eavesdroppers, but requires that the IKE peers know each other's public keys.

If you issue a certificate request with the ikecert certlocal –kc command, you send the output of the command to your vendor. The vendor then creates keying material. You use the vendor's keying material as input to the certdb and certrldb subcommands.

`ikecert certdb` Command

The certdb subcommand manages the public-key database, /etc/inet/ike/publickeys. Options to the subcommand enable you to add, view, and remove public keys and certificates. The command accepts, as input, certificates that were generated by the ikecert certlocal –ks command on a communicating system. See How to Configure IKE With Self-Signed Public Certificates for the procedure. The command also accepts the certificate that you receive from a PKI or CA as input. See How to Configure IKE With Public Keys Signed by a Certificate Authority for the procedure.

`ikecert certrldb` Command

The certrldb subcommand manages the certificate revocation list (CRL) database, /etc/inet/ike/crls. The crls database maintains the revocation lists for public keys. Certificates that are no longer valid are on this list. When PKIs provide you with CRLs, you install them in the CRL database with the ikecert certrldb command. See How to Update a Certificate Revocation List for the procedure.

`/etc/inet/ike/publickeys` Directory

The /etc/inet/ike/publickeys directory contains the public part of a public-private key pair and its certificate in files, or “slots”. The /etc/inet/ike directory is protected at 0755. The public-key databases that are stored under it are world-readable (0644). You use the ikecert certdb command to populate the directory.

The files contain, in encoded form, the X.509 distinguished name of a certificate that was generated on another system. If you are using self-signed certificates, you use the certificate that you receive from the administrator of the communicating system as input to the command. If you are using certificates from a PKI, you install two pieces of keying material from the vendor into this database — a certificate based on material you sent to the vendor, and a CA from the vendor.

An evaluation copy of the iPlanet CMS, a PKI, is available on the Media Kit in the installation package.

`/etc/inet/secret/ike.privatekeys` Directory

The ike.privatekeys directory holds private key files that are part of a public-private key pair, keying material for ISAKMP SAs. The directory is protected at 0700. The private key in this database must have a public key counterpart in the publickeys database.The ikecert certlocal command populates this directory. Private keys are not effective until their public key counterparts, self-signed certificates or CAs, are installed in the /etc/inet/ike/publickeys directory.

`/etc/inet/ike/crls` Directory

The /etc/inet/ike/crls directory contains certificate revocation list (CRL) files. Each file corresponds to a public certificate file in the /etc/inet/ike/publickeys/ directory. PKI vendors provide the CRLs for their certificates. You use the ikecert certrldb command to populate the database.

Implementing IKE Task Map

The ikeadm(1M), ikecert(1M), and ike.config(4) man pages contain useful procedures in their respective Examples sections.

Table 21–3 Implementing IKE Task Map


Task	Description	For Instructions, Go To …
Configure IKE with pre-shared 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 Pre-Shared Keys
Refresh pre-shared keys on a running IKE system	Involves checking the IKE privilege level and editing the `ipseckeys` file with fresh keying material on communicating systems.	How to Refresh Existing Pre-Shared Keys
Add pre-shared 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 New Pre-Shared Keys
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 communicating system with the `ikecert certdb` command.	How to Configure IKE With Self-Signed Public Certificates
Configure IKE with a PKI Certificate Authority	Involves sending output from the `ikecert certlocal –kc` command to a PKI, and installing the public key, CA, and CRL from the vendor.	How to Configure IKE With Public Keys Signed by a Certificate Authority
Update the CA revocation lists	Involves installing a PKI vendor's CRL with the `ikecert certrldb` command.	How to Update a Certificate Revocation List

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.

Chapter 21 Internet Key Exchange

IKE Overview

Phase 1 Exchange

Phase 2 Exchange

Negotiating IKE

Using Pre–Shared Keys

Using Public Key Certificates

IKE Utilities and Files

IKE Daemon

IKE Policy File

IKE Administration Command

Pre-Shared Keys Files

IKE Public Key Databases and Commands

ikecert certlocal Command

ikecert certdb Command

ikecert certrldb Command

/etc/inet/ike/publickeys Directory

/etc/inet/secret/ike.privatekeys Directory

/etc/inet/ike/crls Directory

Implementing IKE Task Map

IKE Tasks

How to Configure IKE With Pre-Shared Keys

How to Refresh Existing Pre-Shared Keys

How to Add New Pre-Shared Keys

How to Configure IKE With Self-Signed Public Certificates

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

How to Update a Certificate Revocation List

`ikecert certlocal` Command

`ikecert certdb` Command

`ikecert certrldb` Command

`/etc/inet/ike/publickeys` Directory

`/etc/inet/secret/ike.privatekeys` Directory

`/etc/inet/ike/crls` Directory