sun.com docs.sun.com My Sun Worldwide Sites

Previous Previous     Contents     Index     Next Next

ProcedureHow to Verify That IKE Preshared Keys Are Identical

If the preshared keys on the communicating systems are not identical, the systems cannot authenticate.

Before You Begin

IPsec has been configured and is enabled between the two systems that you are testing.

  1. On the system console, assume the Primary Administrator role or become superuser.

    The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, "Working With the Solaris Management Console (Tasks)," in System Administration Guide: Basic Administration.


    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.


  2. Check the privilege level of the in.iked daemon.

    # /usr/sbin/ikeadm get priv
    Current privilege level is 0x0, base privileges enabled

    • If the privilege level is 0x1 or 0x2, continue with the next step.

    • If the privilege level is 0x0, stop the daemon. Then, restart the daemon with the appropriate privilege level.

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

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

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

  5. When the verification is complete, lower the privilege level of the in.iked daemon on each system.

    # ikeadm set priv base

Configuring IKE With Public Key Certificates (Task Map)

The following table provides pointers to procedures for creating public key certificates for IKE. The procedures include how to accelerate and store the certificates on attached hardware.

Task

Description

For Instructions

Configure IKE with self-signed public key certificates

Creates and places two certificates on each system:

  • A self-signed certificate

  • The public key certificate from the remote system

How to Configure IKE With Self-Signed Public Key Certificates 

Configure IKE with a PKI Certificate Authority

Creates a certificate request, and then places three certificates on each system:

  • The certificate that the Certificate Authority (CA) creates from your request

  • The public key certificate from the CA

  • The CRL from the CA

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 then adding the public key from a remote system to the hardware.

  • Generating a certificate request on the local hardware and then adding the public key certificates from the CA to the hardware.

How to Generate and Store Public Key Certificates on Hardware 

Update the certificate revocation list (CRL) from a PKI

Accesses the CRL from a central distribution point.

How to Handle a Certificate Revocation List 

Configuring IKE With Public Key Certificates

Public key certificates eliminate the need for communicating systems to share secret keying material out of band. Unlike preshared keys, a public key certificate can be used on a mobile machine or on a system that might be renumbered.

Public key certificates can also be stored on attached hardware. For the procedure, see Configuring IKE to Find Attached Hardware (Task Map).

ProcedureHow to Configure IKE With Self-Signed Public Key Certificates

Self-signed certificates require less overhead than public certificates from a CA, but do not scale very easily.

  1. On the system console, assume the Primary Administrator role or become superuser.

    The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, "Working With the Solaris Management Console (Tasks)," in System Administration Guide: Basic Administration.


    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.


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

    # ikecert certlocal -ks|-kc -m keysize -t keytype \
    -D dname -A altname \
    [-S validity-start-time] [-F validity-end-time] [-T token-ID

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

    -m keysize

    Is the size of the key. The keysize can be 512, 1024, 2048, 3072, or 4096.

    -t keytype

    Specifies the type of algorithm to use. The keytype can be rsa-sha1, rsa-md5, or dsa-sha1.

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

    -A altname

    Is the alternate name for the certificate. The altname is in the form of tag=value. Valid tags are IP, DNS, email, and DN.

    -S validity-start-time

    Provides an absolute or relative valid start time for the certificate.

    -F validity-end-time

    Provides an absolute or relative valid end time for the certificate.

    -T token-ID

    Enables a PKCS #11 hardware token to generate the keys. The certificates are then stored in the hardware.

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

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

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

    You can paste the certificate into an email.

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

      To: [email protected]
      From: [email protected]
      Message: -----BEGIN X509 CERTIFICATE-----
      MIICLTCCAZagAwIBAgIBATANBgkqhkiG9w0BAQQFADBNMQswCQYDVQQGEwJVUzEX
      ...
      6sKTxpg4GP3GkQGcd0r1rhW/3yaWBkDwOdFCqEUyffzU
      -----END X509 CERTIFICATE-----

    2. The enigma administrator would send you the following enigma certificate:

      To: [email protected]
      From: [email protected]
      Message: -----BEGIN X509 CERTIFICATE-----
      MIICKDCCAZGgAwIBAgIBATANBgkqhkiG9w0BAQQFADBJMQswCQYDVQQGEwJVUzEV
      ...
      jpxfLM98xyFVyLCbkr3dZ3Tvxvi732BXePKF2A==
      -----END X509 CERTIFICATE-----

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

    1. List the stored certificate on your system.

      For example, on the partym system, the public certificate is in slot 1, and the private certificate is in slot 0.

      partym # ikecert certdb -l
      Certificate Slot Name: 0   Type: rsa-md5 Private Key
          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 Public Certificate
          (Private key in certlocal slot 0) Points to certificate's private key
          Subject Name: <C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax>
          Key Size: 1024
          Public key hash: 2239A6A127F88EE0CB40F7C24A65B818

    2. Compare this value with the public key hash on the enigma system.

      You can read the public key hash over the phone.

      enigma # ikecert certdb -l
      Certificate Slot Name: 4   Type: rsa-md5 Private Key
          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 Public Certificate
          (Private key in certlocal slot 4)
          Subject Name: <C=US, O=PartyCompany, OU=US-Partym, CN=Partym>
          Key Size: 1024
          Public key hash: 2239A6A127F88EE0CB40F7C24A65B818

  5. On each system, trust both certificates.

    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.

    1. 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
      
      # Verified remote address and remote ID
      # Verified public key hash per phone call from administrator
      cert_trust "192.168.13.213" Local system's certificate Subject Alt Name
      cert_trust "192.168.116.16" Remote system's certificate Subject Alt Name
      
      ## 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_sig oakley_group 2 auth_alg md5 encr_alg 3des}
      }

    2. 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. This 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
      ...

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

Example 23-2   Giving a Start Time and an End Time to a Certificate

The administrator on the machine partym establishes dates within which the certificate is valid. The certificate is backdated by 2 1/2 days, and is valid for 4 years and 6 months from the date of creation.

# ikecert certlocal -ks -m 1024 -t rsa-md5 \
-D "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" \
-A IP=192.168.13.213 \
-S -2d12h -F +4y6m

The administrator on the machine enigma establishes dates within which the certificate is valid. The certificate is backdated by 2 days, and is valid until midnight of December 31, 2010.

# ikecert certlocal -ks -m 1024 -t rsa-md5 \
-D "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax" \
-A IP=192.168.116.16 \
-S -2d -F "12/31/2010 12:00 AM"

Previous Previous     Contents     Index     Next Next
Company Info Contact Terms of Use Privacy Copyright 1994-2007 Sun Microsystems, Inc.