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.
# 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.
Copy the public key from the administrator's email.
Type the ikecert certdb -a command and type <Return>.
# ikecert certdb -a <Return>
Paste the public key and type <Return>.
-----BEGIN X509 CERTIFICATE----- MIICL... ... KgDid/nxWPlWQU5vMAiwJXfa0sw/A12w448JVkVmEWaf -----END X509 CERTIFICATE----- <Return>
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: 2239A6A127F88EE0CB40F7C24A65B818other system # ikecert certlocal -l Local ID Slot Name: 1 Type: if-modn Key Size: 1024 Public key hash: 2239A6A127F88EE0CB40F7C24A65B818Note - The public key hash above is different from the one that your systems generate.